Subject: RE: What do we want from sshv2?

From: Joe Salowey <[email-masked]>
Date: Mon, 23 Oct 2000 12:42:52 -0700

I recently posted a draft on using kerberos as a key exchange  method for
SSH.   There are two modes of the key exchange, one that uses kerberos to
authenticate Diffie-Hellman exchange and one that uses kerberos to do the
key exchange.  I also define a User Auth method that references the
authentication done in the key exchange.  I've had several converstions
about using GSSAPI instead of raw kerberos.  If there is interest in
persuing Kerberos as a key exchange instead of just user auth then I'd be
interested in reworking the draft to use GSSAPI ( and incorporate other
modifications as well).

http://search.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt

ABSTRACT

This memo describes two methods for using Kerberos [KRB5] for 
authentication and key exchange in the Secure Shell protocol.  The first 
method uses Kerberos as a means to authenticate the Diffie-Hellman 
exchange described in [SSH-TRANSPORT].  The second method uses Kerberos 
for authentication and key-exchange.  This memo also defines a new user 
authentication method which allows an authorization name and optional 
credentials to build upon the underlying authenticated key exchange.

Joe 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 3:34 PM
> To: [email-masked]; [email-masked]
> Subject: What do we want from sshv2? 
> 
> 
> At the Pittsburgh IETF meeting in August, Tatu Ylonen gave a 
> presentation
> in the secsh and krbwg working group sessions describing one 
> proposal for
> incorporating Kerberos support in SSH v2.  Those present at the krbwg
> session found a number of problems with that proposal.
> 
> Most notably, it was basically assumed that hosts would continue to be
> authenticated using only ssh's Diffie-Hellman key exchange and SHA1
> signatures, and that users would always have a trusted copy 
> of each host's
> public key.  As a result, Kerberos mutual authentication was 
> not used, and
> one user authentication method described would hand the 
> user's TGT to the
> remote host before completing Kerberos authentication.
> 
> There was also the issue of using the user name field in password
> authentication to pass a principal name, instead of the name 
> of the local
> user to authenticate as.  At a minimum, this makes life 
> annoying for users
> who expect to be able to log in using either a local password or a
> Kerberos password.  It also assumes the existence on the 
> server of a way
> to map arbitrary Kerberos principal names to local accounts, which is
> generally not possible.            
> 
> Due to the problems described above and various others, 
> several of us have
> come to believe that the proposal presented in August doesn't 
> meet the needs
> of sites that have adopted Kerberos as their primary 
> authentication system.
> So, Sam Hartman and I have been working on an alternate 
> proposal that we
> hope will meet those needs, without requiring changes to the 
> ssh protocol.
> 
> To that end, we have developed a preliminary requirements 
> document which
> purports to describe what the Kerberos community wants and/or 
> needs from
> Kerberos support in sshv2.  Before proceeding further, we want to get
> comments from the Kerberos community, to be sure we're on the 
> right track.
> Following is our current list of requirements...
> 
> What does the Kerberos community want from ssh?
> 
>  1. To use existing Kerberos infrastructure to authenticate 
> ssh clients.
> 
>  2. To use existing Kerberos infrastructure to authenticate 
> ssh servers to
>     clients.  We already have one key-management mechanism in 
> place, we
>     should be able to leverage this for ssh host 
> authentication instead of
>     having to set up a parallel structure to manage ssh host 
> public keys.
> 
>  3. To be able to forward krb5 credentials across an ssh 
> connection, so
>     that the single sign-on concept is extended across multiple hosts.
> 
>  4. Kerberos mutual authentication should be used.
> 
>  5. SSH key exchange must be tied to host authentication, or 
> there is a
>     possible man-in-the-middle attack.
> 
>  6. Credentials MUST NOT be forwarded until the identity of 
> the server has
>     been verified.  Otherwise, a rogue server can do 
> malicious things on
>     behalf of a user.
> 
>  7. Some separation of user authentication and host authentication is
>     desirable, so that a connection may use different methods 
> for each.
> 
>  8. Separation of credential delegation is desirable, so that 
> users may
>     delegate any arbitrary subset of their credentials, 
> instead of only
>     the exact set supported by the authentication mechanism currently
>     in use.
> 
>  9. Perfect forward secrecy is desirable, but probably not essential.
> 
> 10. The authorization name passed in the ssh protocol is 
> associated with
>     an account on the remote host which the client wishes to access.
>     One proposal suggested passing a Kerberos principal name and then
>     requiring the remote host to map this onto an account.  
> We think this
>     is backwards; the correct behavior is to pass an account name as
>     always, and let the remote host perform standard 
> authorization checks
>     to determine whether the credentials presented may be 
> used to access
>     the specified account.
> 
> 11. Use of GSSAPI and support of arbitrary GSS mechanisms is 
> desirable.
> 
> 12. Minimizing the number of round trips required by GSSAPI in general
>     and Kerberos in particular is desirable.
> 
> 
> As always, any comments or discussion are welcome...
> 
> 
> -- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Oct 2000 16:40:50 -0400 (EDT)

> http://search.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt

Hm.  We seem to have a case of parallel invention.  The key exchange
method you describe in section 1 (kerberos-diffie-hellman-group1-sha1)  is
pretty much exactly what Sam Hartman and I discussed the week of the
August IETF meeting.  The only significant problem I see with that section
is that it does not clearly require the AP_REQ generated in the first step
to have the mutual-required flag set.  It should be obvious that such a
requirement is necessary in order to authenticate the host. 

The kerberos-sha1 method described in section 2 is workable, but it lacks
a couple of features that I suspect the ssh community considers to be very
important.  First, it lacks the property that neither client nor server
has complete control over the session key.  Second, and perhaps more
important, it does not provide perfect forward secrecy.  An attacker who
obtains the service key after the fact can then decrypt the contents of
a previously-recorded session.  I would suggest dropping this method
entirely.

As before, the external-keyx user auth method described in section 4 is
pretty much exactly the sort of thing we were considering.  I do have a
couple of comments...

There appears to be an error in the generic description of the message
format used when additional credentials are provided.  The format shown
has a boolean with value FALSE; I think you meant TRUE in this case.  In
any case, I'm not sure this feature belongs here.  The way I see it, there
are three possibile uses for the extra credentials, and none of them
really belongs here:

- Extra credentials may be provided for further authentication.  If this
  is the case, then the client should be using some other appropriate
  user authentication method instead of external-keyx.

- Extra credentials may be provided for authorization, without additional
  authentication information.  Kerberos already provides support for this
  using proxy tickets, so a Kerberos-specific solution isn't needed here.
  Generic support for additional authorization data may be interesting to
  someone, but I don't think it should require the use of external-keyx.
  Instead, if this is important, there should be some sort of generic
  support.

- Finally, extra credentials may be provided for the purpose of credential
  delegation, such as forwarded TGT's or proxy tickets allowing the server
  to do things on behalf of the user.  I believe this is important, but
  again, it shouldn't require the use of external-keyx.  Instead, I would
  suggest either including it in the keyx and user auth methods, or
  (better) defining some generic credential delegation mechanism that does
  not depend on which user auth method is being used.

Finally, this may seem like a nit, but the title of section 7 uses a
character not in the 7-bit US-ASCII character set.

I also have some thoughts on a family of GSSAPI-based key exchange methods
similar in spirit to the kerberos-diffie-hellman-group1-sha1 method
described in this draft.  I'll follow up with those in a separate message.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 24 Oct 2000 09:22:49 -0500

> interested in reworking the draft to use GSSAPI ( and incorporate other

I would suggest that the GSSAPI is the way to go. Rather then reinventing
a authentication protocol, the GSSAPI already provides this. The GSSAPI can 
also be used to verify any SSH host keys, using wrap/unwrap and the session keys.
I believe that this is very important, as all to many people do not distribute
the host keys out of band, but allow SSH to prompt them the first time of
when the key changes, thus leading to possible MITM attacks. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 24 Oct 2000 14:01:10 -0400

>when the key changes, thus leading to possible MITM attacks. 

Stupid question time; if we're using Kerberos/GSSAPI, why do we need
the SSH host key _at all_?  Doesn't it become completely redundant?
I'd personally prefer not having to generate a SSH host key.  I think
the D-H exchanges described previously don't require a host key (unless
I misread those documents, which is completely possibly).

--Ken

---

From: [email-masked] (Niels M�ller)
Date: 25 Oct 2000 18:26:16 +0200

[ Note: I'm not on the kerberos list; I got this discussion forwarded
  by [email-masked]. So please keep my mailbox on the To or Cc line. ]

Jeffrey Hutzelman <[email-masked]> writes:

> > SSH. [...]

I'm very happy that people more familiar with Kerberos than I look
into this.

> As before, the external-keyx user auth method described in section 4
> is pretty much exactly the sort of thing we were considering.

When I first encountered the problem (which was with SRP exchange, not
Kerberos), I thought that the best way to deal with key exchange
methods that provides user authentication as a side-effect was to
skipthe ssh-userauth sub-protocol completely. I.e. have the cliet send
an SSH_SERVICE_REQUEST message that asks for "ssh-connection" rather
than "ssh-userauth".

But perhaps something like external-keyx is better. One potential
advantage is that it makes it possible for a server to require both
Kerberos authentication *and* authentication using a public key, a
hardware token or any other mechanism incorporated in the ssh-userauth
framework.

I don't understand why the "extra credentials" are added to the
same message, though. 

>   user authentication method instead of external-keyx.
                               ^^^^^^^
Note that several userauth mechanism can be used, even for a single
connection.

/Niels (LSH author, http://www.lysator.liu.se/~nisse/lsh)

---

From: Ken Raeburn <[email-masked]>
Date: 26 Oct 2000 20:00:19 -0400

> http://search.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt

One thing jumped out at me when reading this draft.  In section 3
("Naming Conventions"), the description of the Realm field is Just
Wrong.  The realm of a server is often a trailing substring of the
FQDN of the server hostname, but not always.  The description you give
(and the matching description in RFC 2712) would not work for
dcl.mit.edu (correct realm name is ATHENA.MIT.EDU) or
r93aag001418.sbo-smr.ma.cable.rcn.com (realm RAEBURN.ORG).

Determining the realm(s) for a given host is one of the weak points of
Kerberos at the moment.  (No, the Microsoft additions to the protocol
don't fix the problem, they just move it from all the clients in the
world to all the KDCs in the world.)  But from the point of view of
the ssh protocol, I'd say you should just leave that determination to
the Kerberos implementation (which may use config files, or name
canonicalization, or something entirely different).  Or the GSSAPI
mechanism, if you want to switch to that, and just specify
"host@<hostname>".  The Kerberos GSSAPI mechanism already needs to be
able to figure out the realm name from the host name for host-based
services, though this is not addressed in RFC 1964.

In section 1, is there any reason not to permit and use a subkey in
the AP_REQ?

Ken

---

From: Ken Raeburn <[email-masked]>
Date: 26 Oct 2000 20:35:02 -0400

Jeffrey Hutzelman <[email-masked]> writes:

>   The only significant problem I see with that section

What does this flag mean other than "AP_REP required"?  There's no
AP_REP message in the section 1 protocol.  However, if a spoofing
server cannot decode the message from the client, it cannot determine
the correct encryption key to use for E_H in the response.

>  Second, and perhaps more

This does seem to make the first method preferable....

Perhaps we should someday look at modified versions of the AP_REQ
exchange that don't simply send subkeys, but instead build in a DH
exchange to generate the subsession key(s).