Kerberos Support in OpenSSH

Jeffrey Altman jaltman at columbia.edu
Mon Jun 30 20:43:16 EDT 2003


The letter has found its way to SlashDot
 
  
http://developers.slashdot.org/article.pl?sid=03/06/30/116222&mode=thread&tid=122&tid=126&tid=172&tid=185&tid=190&tid=93

The feedback is interesting although hardly positive.  Most of it is of 
course based on misconceptions and rumor.

Jeff



Marshall Vale wrote:

> Dear Sir and Madam:
>
> I'm writing to you on behalf of the MIT Kerberos team and several 
> other parties interested in the availability of Kerberos 
> authentication for the SSH protocol.
>
> We recently noticed that the OpenSSH developers had added support for 
> the kerberos-2 at ssh.com user authentication mechanism.  We are 
> delighted but we believe additional steps are necessary, as explained 
> below.  We are happy that OpenSSH is looking at Kerberos for SSH 
> protocol version 2.  It has been our experience that the combination 
> of Kerberos and SSH provides an excellent method for sites to have 
> secure login access while centrally managing keys and avoiding the 
> problems of maintaining  known_hosts files.
>
> We do have two concerns that we would like to discuss with you. We 
> will briefly describe our concerns and then discuss them in detail.
>
> First, we would like to ask you to commit to implementing 
> draft-ietf-secsh-gsskeyex in addition to any other Kerberos mechanisms 
> you decide to ship for protocol version 2.  We believe the mechanisms 
> described in this draft better meet the needs of the Kerberos 
> community, will have wider long-term acceptance and have undergone 
> more comprehensive review in the standards community than previous 
> methods.
>
> Secondly, we would like to find a way to reduce the user confusion 
> associated with all of the different options for Kerberos and SSH. 
> Ideally everyone will eventually migrate to the IETF standards track 
> approach, but even then, we will need to help people understand 
> differences between Kerberos used for key exchange, Kerberos used for 
> userauth, and Kerberos used behind the scenes for password 
> authentication.  If there are any ways we could help you address these 
> concerns please feel free to ask us.
>
> The primary reason we want to see OpenSSH adopt an implementation of 
> the IETF draft is that we believe it better meets the needs of the 
> Kerberos community.  In addition to an SSH userauth method, the IETF 
> draft includes a key exchange mechanism.  Previous methods only used 
> Kerberos to authenticate the client to the server and still relied on 
> the SSH known_hosts file to authenticate the server to the client. 
> Especially in large sites this is undesirable because updating known 
> hosts files when machines are rekeyed is difficult. Many users always 
> accept new keys without question and thus are vulnerable to a 
> man-in-the-middle attack.  The GSSAPI key exchange mechanism in the 
> IETF draft uses Kerberos to authenticate both parties to each other, 
> avoiding man-in-the-middle attacks.  This allows Kerberos sites to 
> gain the same level of security with ssh that they have enjoyed for 
> years with rlogin and ftp.
>
> There has been significant interest in the Kerberos community ever 
> since Simon Wilkinson first released his GSSAPI patches to OpenSSH. A 
> broad range of customer sites have adopted the IETF draft and deployed 
> Simon's patches in production.  Several major Unix vendors have chosen 
> to adopt the GSSAPI protocol to provide Kerberos authentication.  At 
> least two Windows implementations of SSH (Secure CRT and Kermit95) 
> implement GSSAPI support.  Patches are available for Putty.  The 
> GSSAPI framework also supports mechanisms other than Kerberos V, such 
> as SPKM, which could be used to add x.509 support to SSH.  For 
> example, Simon's patches include support for the Globus GSI mechanism.
>
> The IETF GSSAPI draft has been more thoroughly reviewed within the 
> IETF community than any previous Kerberos solution. Authors of the 
> draft include both implementers and interested third parties.  At 
> least three independent and interoperable implementations have been 
> written from this draft, so the quality of the spec is good.
>
> Significant parts of the spec were motivated by a presentation of the 
> kerberos-1 at ssh.com spec at the IETF.  The ssh.com spec received a 
> strong negative reaction from both the Kerberos working group and the 
> Secure Shell working group.  People were concerned about the lack of 
> mutual authentication, the way tickets were passed from client to 
> server and  how Kerberos interacted with password authentication. For 
> this reason, the Secure Shell working group did not accept the 
> kerberos-1 at ssh.com mechanism but instead started work on the GSSAPI 
> draft. Although improved, the kerberos-2 at ssh.com mechanism retains 
> many of the operations that caused working group participants to be 
> concerned.
>
> The MIT Kerberos team may be able to help OpenSSH add support for 
> draft-ietf-secsh-gsskeyex.  In particular, we would be happy to answer 
> any questions you might have regarding either Simon's patches or the 
> the protocol.  If you would accept help auditing Simon's patches or 
> another implementation of the draft, we would be happy to assist.
>
> Once the IETF draft is implemented, the Kerberos and SSH communities 
> will then need to deal with user education.  The experience with the 
> many incompatible methods of implementing Kerberos for SSH protocol 
> version 1 has shown that users will be confused.  Over the longer term 
> we prefer people to use either the GSSAPI key exchange or the GSSAPI 
> userauth method.  Thus the Kerberos and SSH communities will need to 
> work not only to find ways to make it clear in what direction we are 
> heading but also that the other options are only being provided to 
> address the issue of compatibility with deployed implementations.
>
> Signed,
> Marshall Vale, on behalf of the MIT Kerberos Development Team 
> <krbcore at mit.edu>
> Jeffrey Altman <jaltman at kermit-project.org>
> Douglas E. Engert <deengert at anl.gov>
> Joseph Galbraith <galb at vandyke.com>
> Jeffrey Hutzelman <jhutz at cmu.edu>
> Joseph Salowey <jsalowey at cisco.com>
> Von Welch <welch at mcs.anl.gov>
> Simon Wilkinson <sxw at inf.ed.ac.uk>
> _______________________________________________
> kerberos-announce mailing list
> kerberos-announce at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos-announce
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3590 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20030630/176361bb/attachment.bin


More information about the krbdev mailing list