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 Sat, Jul 19, 2003 at 01:55:07AM -0400, Joel N. Weber II wrote:
> > 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.
> 
> What problem do you believe would actually be solved by the solution
> you're proposing that isn't solved by the solution I'm proposing?  I
> can see where you're proposing to introduce more generality, but I
> don't see why anyone will ever benefit from that generality.

Whoever designed KEXINIT did not foresee the problems we're running into
now.  Thus the desire to get the model right the second time.  Though
that may be moot since I am actually arguing that we ought to work with
what we got anyways.

> As I think I've said, it seems that you and jhutz think that someone
> someday is going to have a burning desire to use group-exchange with
> pgp and group1 with ssh-*, and I really don't see why that is going to
> be especially useful.

No, I'm thinking that the distinction between kex and host key is
artificial and what we need is a distinction between kex method and kex
authentication method.

> > 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.
> 
> So, stating that something is ``obviously [not] the same kind of
> thing'' is not a useful way to communicate after we've had as many
> round trips as we have establishing that we see things differently.
> Can you explain why you believe this?

I will have to sleep on it.  Right now my thought is that we have a
separate kex alg for gss and so separating the kex name from the gss
mechanism name doesn't really change much (though taken with the change
in alg selection that you propose it would).

I think my argument boils down to this: if we're to introduce KEXINIT2
then we might as well fix it right, and that includes separating kex
from kex auth, because even adding KEXINIT2 would be a lot of work and
wouldn't be sufficiently general as proposed; the alternative is to
hack, if you wish, around the limitations of KEXINIT in a backwards
compatible way.

> > Alternatively, we could break the key exchange and the key exchange
[...]
> 
> One of my goals was to avoid changing the actual key exchange
> protocols, and change only the KEXINIT message itself.
> 
> I also suspect you'd end up adding a round trip or two in the GSSAPI
> case if you did this.

No - the two exchanges could be done in parallel, with the MIC coming
last.  For 1-round-trip GSS mechanisms this means you can do the DH
exchange and the GSS-API exchange and the exchange of the signature of
the session ID all in one round-trip.  Cool, eh?

> >    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.
> 
> Ugh, but I suppose that could solve the problem.  (If I end up with a
> client that does all of krb5, X.509, pgp, and bare host keys, I'll end
> up listing 8 distinct algorithms, probably, assuming each of those
> four types does both group1 and group-exchange.  Plus at the end I'll
> end up listing diffie-hellman-group1 and
> diffie-hellman-group-exchange, for a total of ten.  While this is
> ugly, it is difficult to argue that it is a problem; I don't know of
> any reason why listing ten algorithms will fail.)

Exactly.  It ain't elegant, but it's not wasteful either, either of
network resources or of WG reasources :)

> >    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.
> 
> Right now, each kex method just includes the packet that negotiated
> the algorithm usage in the hash.  The amount of code required to use
> KEXINIT2 when KEXINIT2 is used is almost certainly less than this
> chaining proposal.  And this bogus algorithm name also strikes me as
> likely to add complexity.

Why?  If both the client and the server propose that bogus alg they know
that if the first kex selected fails then they can retry and that the
second try will have an extension field to the KEXINIT where the hash of
the failed kex's messages will be included, or something to that effect.
The point here is to avoid changing the definition of the channel ID
hash, of which there are three currently, in three separate I-Ds.

> > > > 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.
> 
> Because I want to treat it as just another optional field that has a
> field name label, rather than having its mere presence there imply
> that it is what it is.

Ok, I can live with that.

> I certainly want the language field content to remain just as
> expressible as it is now.  (And shifting to only one field rather than
> two was a mistake that came from not reading the draft carefully
> enough to realize there were two, not from intending a change.)

Yes, but I'm afraid that having two was a mistake anyways, and the
semantics of language negotiation are much too underspecified.

> > > 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.
> 
> How does this interact with key exchange mechanisms and host key
> mechanisms that contain at signs?

I don't know what Jeff had in mind, but in my proposal these would be
aliases of existing kex methods - taken to be limited to subsets of the
host key algorithms - so any implementors of non-standard kex methods
would not be affected (and to take advantage of this they'd have to
define their own aliases).

> I think we need to figure out whether the problem of having extra
> optional fields available is actually worth solving.  At one point I
> thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key
> algorithm negotiation, but I no longer believe it is needed for that.
> This leaves me feeling like I understand how to solve some problem
> that might exist, without knowing what problem it solves.

You mean by adding "named" fields?

Nico
--