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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mechanism but instead started work on the GSSAPI draft. Although improved, the [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Jeffrey Altman <[EMAIL PROTECTED]> Douglas E. Engert <[EMAIL PROTECTED]> Joseph Galbraith <[EMAIL PROTECTED]> Jeffrey Hutzelman <[EMAIL PROTECTED]> Joseph Salowey <[EMAIL PROTECTED]> Von Welch <[EMAIL PROTECTED]> Simon Wilkinson <[EMAIL PROTECTED]> _______________________________________________ kerberos-announce mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos-announce ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
