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