Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Thu, 17 Jul 2003, Joel N. Weber II wrote:

> I'm likely to submit an individual draft soon describing an
> SSH_MSG_KEXINIT2 message real soon now.  (Existing implementations
> will see it as a reserved message and send a message back saying that
> they don't recognize SSH_MSG_KEXINIT2, at least if they follow the
> IETF spec.)  Specific things I want to change vs SSH_MSG_KEXINIT:
>
> 1) You iterate primarily over the host key list, rather than the
>    algorithm list.  Once you find a host key type that's in common
>    between the client and the server, you then iterate over the key
>    exchange algorithm list looking for the first algorithm on the
>    client's list that's also in the server's list that works with the
>    host key type you picked.

Eh.  I don't see a particular problem with this, but I don't see that it
really solves anything either.  This negotiation directly affects the
fundamental security of the protocol, and getting it wrong would really
suck badly.

> 2) Each gss mechanism becomes a host key type, so that if your order
>    of preference is kerberos, pgp, gsi, x.509, bare ssh key, in that
>    order, you can actually express that preference (which you just
>    can't do in that order with the way SSH_MSG_KEXINIT and the gssapi
>    draft are currently specified).

I don't think it's a good idea to try to treat GSS mechanisms as "host
keys".

The gsskeyex draft effectively defines a way to generate an independent
key exchange algorithm for any GSS mechanism.  Such algorithms use a
number of common components, but they are not one key exchange algorithm
with multiple "host key algorithms"; they are different key exchange
algorithms and should be treated as such.  Note that this approach was
adopted in large part to specifically avoid the sort of multi-level
negotiation problem that you appear to be trying to fix in item 1.

I also think that such a change is completely orthogonal to the question
of whether to select first the keyex algorithm or the host key algorithm.
GSS key exchange algorithms work with _any_ host key, so the selection of
host key type is not relevant to whether you want to use GSS, nor does it
affect what GSS mechanism will be used.  Similarly, neither the decision
to use GSS nor the selection of mechanism should affect what host key
algorithm is used.


> 3) The language optional field as it exists goes away.
>
> 4) Any optional fields after the standard set of required fields each
>    start out with a name indicating what they are negotiating.  So,
>    you could have, for example
>
> secondary-host-key,ssh-dss,ssh-rsa
>
> if you wanted to negotiate public key algorithms for a secondary host
> key.  The functionality of the optional language field in
> SSH_MSG_KEXINIT would also have a name added to the front of it.

Hm.  I'm sort of neutral on this.  An extension mechanism is probably
useful, but we should be careful that it does not get overused.

> Perhaps the multi type you're proposing should be defined for
> secondary-host-key but not for use with a key exchange algorithm to
> actually verify the host's identity?

Actually, I think we can punt this part entirely; I think I prefer Nico's
approach of doing host key transfer in a separate message after key
exchange is complete.

> 5) In order to prevent downgrade attacks, an implementation that would
>    prefer to use SSH_MSG_KEXINIT2 lists SSH_MSG_KEXINIT2 as a keyex
>    algorithm if it ends up sending an SSH_MSG_KEXINIT message, and if
>    the SSH_MSG_KEXINIT from the peer includes SSH_MSG_KEXINIT2 as a
>    key exchange algorithm when you also included SSH_MSG_KEXINIT2 as a
>    key exchange algorithm, you abort.

Yes, something like this is definitely necessary, and I think what you
describe will work.

> Does this seem like it would help with solving the problems you're
> interested in solving?



So, I was going to start this message by suggesting that I think the goal
of solving the multi-level negotiation mechanism would be better solved by
the mechanism I proposed.  Unfortunately, I realized first that I hadn't
actually yet proposed the mechanism in question.  So I will do so now....

Basically, the general idea is to create a new series of "magic" keyex
algorithm names (hm.. I see a theme here).  These would look something
like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant
defined in the spec.  There are some problems with this approach, which I
haven't yet had time to fully research; that's why I hadn't yet brought up
the idea.  But I'd much rather see a mechanism that allows negotiation of
{ keyex, host-key } tuples rather than simply switching the order, which
doesn't eliminate the existence of a multi-level negotiation.

Perhaps we could come up with a solution that incorporates both ideas, by
adding a new message type that results in selection of algorithm and host
key type at the same time.  I'm not sure what the right answer is here,
exactly, but I would not mind seeing a solution to the multi-level
problem.


-- Jeff