Kerberos Support in OpenSSH

[Marshall Vale]

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>