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

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

On Thu, Jul 17, 2003 at 09:54:05PM +0200, Jeffrey Hutzelman wrote:
> On Thu, 17 Jul 2003, Joel N. Weber II wrote:
> > 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.

I do have a problem with it.  The reason the current KEXINIT sucks is
that it negotiates two important aspects of the ultimate kex method
independently.  While reversing the order of algorithm matching and
treating the GSS-API mechanisms as "host key algorithms" would solve one
problem we're dealing with I don't believe it to be a general solution.

The kex negotiation should negotiate kex method tuples where there's a
method name and some method-specific data, e.g.,

 - "diffie-hellman-group1-sha1 w/ ssh-dss host keys"
 - "diffie-hellman-group-exchange-sha1 w/ pgp-sign-dss host keys"
 - "gss-group1-sha1 w/ Kerberos mech [OID]"

And then too, the selection of cipher algorithm maybe ought to have an
impact on the selection of kex method - or else we should deprecate
fixed-group dh kex methods (at the cost of an extra 1/2 round-trip or
having the client always pick the group that satisfies the needs of the
cipher with largest key size).

I'm with Jeff - we gotta get this right; let's not have to repeat this
later.  But, see below - I want to fix KEXINIT rather than add KEXINIT2.

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

Me either.

> 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 don't mind separating the one part from the other - I just mind
treating that second aspect of kex methods (the host key or gss mech) as
the same thing when they aren't obviously the same kind of thing.

I'd much rather treat the host key alg / gss mech as kex-specific
"arguments" and then negotiate {kex, kex-specific-args} tuples.

Alternatively, we could break the key exchange and the key exchange
authentication parts of kex apart and have a generic DH key exchange and
a generic message exchange for signing the DH key resulting from the DH
key exchange.  That way we'd need but a single key exchange method (or
two, if the fixed-group (1 round-trip) vs. negotiated group (1.5
round-trips) distinction is worth keeping) and a bunch of kex signature
exchange methods (ssh-*, pgp-*, ... gss-*).  This may sound suspiciously
like Joel's proposal, but the innovation here lies in changing the
actual kex messages for the dh methods and getting rid of the gss kex
name.

All of this is way too complicated anyways.  So let's see first if we
can't just cut through and simplify:

   Earlier I proposed the use of "alias" alg names to cure some of the
   ills with KEXINIT that would solve the preference expression problem
   that Joel had.  We could also negotiate KEXINIT extensions through
   the use of a bogus alg name.

   If we then define the semantics of the reserved field of KEXINIT we
   could add a field to KEXINIT (w/o revving the protocol version) for
   chaining hashes of failed kex messages through to the next KEXINIT so
   that the resulting session ID is bound to all kex messages and bingo,
   we've got secure re-triable kex w/ downgrade attack detection and w/o
   having to go back and modify the way each kex method defines the
   session ID hash.

> > 3) The language optional field as it exists goes away.

Why?  I agree that we don't need two sets of lang fields
(server-to-client and client-to-server).  But we need a language
negotiation for G11N.  And it has to happen _before_ userauth, and if it
can be piggy-backed onto the kex then you save a round-trip - funny,
that's how it is now, and it works too.

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

See above.  I'd rather not do a KEXINIT2 - I think we can fix most of
the problems, albeit not very elegantly, w/o such a drastic step.


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

Hey, you're stealing my idea!  Except that what I'd poposed was to use
aliases like "diffie-hellman-group1-sha1:ssh" and
"diffie-hellman-group1-sha1:pgp" (i.e., leave the actual signature alg
out, but leave the "cert" type in).  Plus a "re-triable-kex" bogus alg
name to indicate, well, that and the use extended kexinit for kex hash
chaining in subsequent kexinit messages.

This way we've got a backwards compatible set of kex extensions.

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

KISS.

Cheers,

Nico
--