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>