Kerberos Support in OpenSSH
jaltman at columbia.edu
Mon Jun 30 20:43:16 EDT 2003
The letter has found its way to SlashDot
The feedback is interesting although hardly positive. Most of it is of
course based on misconceptions and rumor.
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
> 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
> 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.
> 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
> krbdev mailing list krbdev at mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
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