Re: gssapi host key algorithm usage

[Nicolas Williams <Nicolas.Williams%sun.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.

> 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.

> It may well be too late to change now for gss-group1-sha1 (on the
> other hand, sxw's patches seem to have survived a change in the
> OID->string conversion), but if gss-group-exchange-sha1 gets defined,
> I hope it will use the host key field to specify which GSS mechanism
> to use.

Why would you want to make such a change?  What would you gain?

Simon Wilkinson's patches for OpenSSH are not the only implementation of
draft-ietf-secsh-gsskeyex-06, so changing the spec now sure would hurt,
and there'd be nothing to gain from what you suggest.

Cheers,

Nico
--