Re: gssapi host key algorithm usage

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote:
> > The secsh transport draft suggests that there can be different kinds
> > of host key algorithms, and that some key exchange operations may
> > support different host key algorithms than others.
> > 
> > The idea that GSS mechanisms don't have host keys strikes me as
> > confused.  As far as I can tell, if I have a Kerberos 5 principal
> > named host/foo.example.com%EXAMPLE.COM@localhost and I store that encryption key
> > in /etc/krb5.keytab on the host foo.example.com, it is very much the
> > case that that krb5.keytab is a form of a host key.  As far as I know,
> > all GSS mechanisms that anyone cares about for use with ssh do support
> > host keys, albeit abstracted away to the point where ssh protocol
> > designers and implementers don't directly deal with them.
>
> You're confused.  When using the GSS-API for SSHv2 key-exchange what you
> don't need is "SSHv2 host keys" - you know, RSA and DSA host keys, the
> keys that go into the known_hosts public keys file.

The implementation of pgp-sign-{dss,rsa} that I wrote uses things that
I guess you are calling ``SSHv2 host keys'' which don't go into the
known_hosts file.  It certainly uses the same key exchange algorithms
that ssh-rsa uses.  (Of course, it should make a known_hosts file
entry, so that a MitM who offers a bare ssh-rsa or ssh-dss key doesn't
cause prompting about a brand new host with an unknown key, but sxw's
GSS patches have the same problem.)

> > On furthur thought, I don't really understand why gss-group1-sha1-*
> > has to be defined as gss-group1-sha1-*.  Wouldn't it have been cleaner
> > to define it as gss-group1-sha1 and then put information on which gss
> > mechanism is being used in the host key algorithm field?
>
> No, it wouldn't because a client and server might first both agree that
> they can use the GSS-API and then realize that they have no mechanisms
> in common, by which time the key exchange has to fail because the SSHv2
> keyex phase cannot be re-tried in one connection.  By putting the
> mechanism name into the keyex method name the client and server can
> fully negotiate between all the keyx methods, including GSS-API
> mechanism available.

I think you're confused.  Consider this part of the transport draft:

         Choose the first algorithm that satisfies the following
         conditions:
         +  the server also supports the algorithm,
         +  if the algorithm requires an encryption-capable host key,
            there is an encryption-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client, and
         +  if the algorithm requires a signature-capable host key,
            there is a signature-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client.
         +  If no algorithm satisfying all these conditions can be
            found, the connection fails, and both sides MUST disconnect.

It's clearly the case that you ignore a key exchange algorithm and
pick the next one if the subnegotiation on the host key finds that
there's no compatible key.  So if GSS defined one keyex method and
used the host key type to specify which GSS mechanism to use, the
problem you describe doesn't really exist, near as I can tell.

But I've realized another potential problem: there is no way to
specify that your first preference is to use a pgp-sign-{dss,rsa} key,
your second preference is a GSSAPI method, and your third perference
is ssh-{dss,rsa}.

A cleaner algorithm would be:

Choose the first host key type on the client's list that is also on
the server's list.  Choose the first host key algorithm on the
client's list that's also on the server's list that supports the host
key type choosen.  (Actually, this will work regardless of which field
you use to encode which GSS mechanism you're using, but if you want it
all in the key exchange field you'd have to define gssapi as a host
key type, and then you'd lose the ability to mix non-GSS methods in
between the GSS methods in the priority list.)

The ssh v2.1 protocol could be defined to negotiate in this new
fashion if both client and server claimed to have a version of at
least 2.1, otherwise using the old method.  And maybe we could define
a 1.991 protocol version value for those people who want to support
v2.1, v2, and v1, or something.