Re: gssapi host key algorithm usage

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Jun 24, 2003 at 07:42:56AM -0700, Nicolas Williams wrote:
> On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote:
> > 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.

Also, I happen to find the way GSS-API mechanism negotiation for keyex
is specified in draft-ietf-secsh-gsskeyex is quite elegant.  It is
simple (simpler than SPNEGO, for example), it fits right into the SSHv2
keyex model and it is secure (because of the way the session ID is
derived as a hash of data that includes the KEXINIT messages) without
suffering from the unfortunate problems that have arisen with SPNEGO[1].

There really is no alternative if you wish for clients and servers with
non-overlapping supported GSS-API mechanisms[2] to be able to
successfully complete key exchanges without user input; the only
alternative would have been to have the basic SSHv2 keyex protocol
modified so that keyex could be re-tried without having to restart the
connection.

[1] Long story.  Suffice it to say that it is not currently possible to
    implement SPNEGO correctly and also interoperate with deployed
    implementations without also fixing the deployed SPNEGO
    implementations.

[2] And note that what matters is not so much what GSS-API mechs are
    supported by the client and server implementations as which ones
    they have initiator and acceptor credentials for, respectively.

Nico
--