Re: gssapi host key algorithm usage

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

On Tue, Jun 24, 2003 at 04:10:11PM -0400, Joel N. Weber II wrote:
> > On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote:
> >
> > 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.

I don't see how this could be called more elegant, or even as elegant as
the current draft.  And it's clear that it is much, much too late to
change the draft should we all agree that this is approach is better.

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

Why so complicated?  The current approach to negotiating GSS-API
mechanisms is simple, it works, it's elegant.

And the GSS-API is not about "host key types" - it's about mechanisms.
Why conflate the two?

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

Why bother?

Cheers,

Nico
--