Re: GSSAPI

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Thu, Jul 17, 2014 at 10:21 PM, Karl O. Pinc <kop@xxxxxxxx> wrote:
> On 07/17/2014 08:33:17 PM, Nico Kadel-Garcia wrote:
>> On Thu, Jul 17, 2014 at 9:01 PM, Coy Hile <coy.hile@xxxxxxxxxxx>
>> wrote:
>> >
>> > On Jul 17, 2014, at 7:59 PM, Damien Miller <djm@xxxxxxxxxxx> wrote:
>> >
>> >> On Thu, 17 Jul 2014, Douglas E Engert wrote:
>> >>
>> >>> I too am personally baffled why OpenSSH does not include the
>> patch.
>> >>
>> >> We don't trust the attack surface the Kerberos/GSSAPI provides.
>> >
>> > What’s your justification for that?  I don’t see a larger attack
>> surface in a kerberized environment compared to the wild west.
>
>> Especially compared to the "oh, let me just leave my SSH private keys
>> without passphrases so I don't have to unlock them" practice that is
>> the commonplace in every environment I've dealt with since 1996, when
>> I first tried to compile ssh-1. This is re-inforced by the default
>> acceptance of ssh-keygen of passphrase keys, and *every environment*
>> I've ever audited has at least 20% passphrase free SSH private keys.
>> Often it approaches 90%. The technology of OpenSSH is pretty robust,
>> but the commonplace practices are often utterly, utterly horrid.
>> Educating user communities is too often seen as "not on task", and
>> "not part of the priorities", especially because it's often the CTO
>> and architects at a company who are most likely to ignore basic
>> security practices as a matter of policy.
>>
>> The Kerberos tokens are a tremendous win over this, for robust
>> single-sign-on, for the ability to invalidate or reject keys at a
>> central access point, and for their ease of integration with SSL and
>> other technologies.
>
> FWIW, an alternative approach with similar benefits is to
> use hardware tokens such as yubikeys.  This has some
> advantages when it comes to the social aspects involved in
> fixing poor security practices.  The hardware cost is low enough
> that the risk/reward ratio can be good, especially as -- as
> noted above -- dealing with people is often the hardest part.

Those are different patches!!!!

And I wish hardware tokens worked out well. I've had to manage up to
20 distinct environments, simultaneously, each with their own
credentials system. Tokens would have become unwieldy, especially in
today's tablet based computing where the computer itself is so light
and small.

I realize this is the devel mailing list, and most of us would know
this, but perhaps a few newer UNIX or Linux admins don't realize how
ubituitious Kerberos based authentication has become, especially in
environments that use Active Directory, or modern Samba. Linux or UNIX
environments can activate just the Kerberos part and use local account
management and reduce the setup costs for Kerberos ticket handling
profoundly, far more stably and reliably than using AD for account
management. So it's very useful indeed for complex environments that
are already running AD.

I was a happy camper when GSSAPI was enabled in Putty: it turned one
of my complex and awkward environments into a genuine SSO, or "Single
Sign-On" environment.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev





[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux