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

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

On Mon, 21 Jul 2003, Joel N. Weber II wrote:

> I don't think that's true.  I even mentioned a hypothetical example
> involving an srp kex algorithm when I said ``here's a list of possible
> kex algorithms and ``host key'' algoithms; if we invert the order of
> negotiation, why won't my proposal work?''

Because your proposal depends on the thing in the second slot being
something that uses a "fake" host key algorithm instead of a real one.
Note that GSSAPI-based and SRP keyex mechanisms currently negotiate a
_real_ hostkey algorithm; if you change the process out from under them
then this functionality goes away.

> What sort of new requirements do you think we'd get using a new host
> key algorithm with an existing key exchange algorithm that provide
> different problems than negotiating PGP vs X.509 vs a bare ssh host
> key?  As far as I can guess, while the future is very much open to new
> host key algorithms in this space, the problems in negotiating them
> shouldn't be any different than what we have with the current
> algorithms.

That's probably true, which is why I prefer to concentrate on the case of
potential new key exchange algorithms, which may be significantly
different from what we know about now.  However, the point is not that new
host key algorithms might have particular requirements as that people
might be willing to use certain keyex algorithms only with a suitably
"strong" host key algorithm.


> I think at some point in the past I may have also pointed out that
> the current multilevel approach doesn't do the right thing if you
> introduce key exchange algorithms that support encryption rather than
> signing keys, and pgp-encrypt-dss, ssh-encrypt-dss, etc, and that
> switching the host key vs key exchange algorithm order ought to fix
> the problems with that, too.

I'm not sure I see how it's a problem.  Can you elaborate on why the
current model causes a problem here?

> Of course, I'm assuming that the thing
> you care about primarily is being able to pick the most trusted
> trusted-third-party scheme, since in practice host key verification
> seems to be the weak link.

Ah, but I think you're making an invalid assumption.  While host key
verification is important, so is selection of a key exchange algorithm
that is suitably secure (and here by "key exchange", I mean it in the ssh
sense, where it includes the method used to bind a host's authentication
to the exchanged key).  Back when people assumed all keyex algorithms
would do basically the same thing (do an exchange and sign it with a
host's public key), the two seemed independent.  But in reality they are
not, as algorithms like the GSS and SRP ones have taught us.  I don't
think reversing the order makes anything better; it means we still have a
multi-layer negotiation problem; we have just inverted the order of the
layers.


> I just got thinking that another question we might consider is what
> happens when you have an ssh server that wants to provide multiple
> X.509 keys, each signed by a different CA.  (Last time I dealt with a
> well-known CA, I distintively remember them not handling the private
> key, but let's hypothetically assume a world where the CA hands you
> the private key and the public key; it's probably a good thought
> experiment for understanding what problem we're trying to solve if
> we're going for generalization.  And I'm also not sure if the X.509
> standard allows you to get your cert signed by more than one CA.)  I
> could imagine solutions involving an extra field to negotiate which CA
> to use; or creating x509v3-sign-rsa-verisign, x509v3-sign-rsa-thawte,
> x509v3-sign-rsa%joelweber.com@localhost, etc, though I don't think either of
> these schemes is necessarily ideal.  The latter at least could be done
> in a way that doesn't require any changes to the negotiating
> infrastructure.

Hm; this is an interesting problem.  I think the current theory is that
the host sends you its key along with all the signatures.  But if it has
to select which key to send you on the basis of what CA's you'll accept,
then it won't work.  There's also an identity problem here, in that a
host may need to decide which key and certs to send you based on what
identity you think it has.  TLS has this problem today...

> I'm starting to think that the last paragraph may be an argument in
> favor of doing a KEXFAIL message with a reason code, where the reason
> code indicates what kind of retry to do.  Because for some failure
> modes, retrying the same thing with a different key is an option.  In
> the extreme case, consider a GSSAPI mechanism where both the client
> and the server have alternate credentials.  I don't think that KEXINIT
> has much hope of being the right way to efficiently negotiate what to
> retry when in that case.

I think I agree that if we handle the retry problem at all, there is some
complexity in deciding at what level to retry.  Probably we should put
that off until the WG has decided whether the problem is worth solving.

> > Currently, solutions to (1) and (2) are defined by every "key exchange"
> > algorithm, which results in a lot of duplication.  For example, it means
> > that group exchange needs to be defined separately for every algorithm, as
> > does the exchange hash.  I agree that this is an unfortunate situation,
> > and that it would be better had these operations been separate.  However,
> > I also feel that, for those host authentication algorithms which require
> > the use of public-key encryption, it would be as inappropriate to bind the
> > key type to the host authentication algorithm as it is to bind key
> > exchange to that algorithm, or the symmetric cipher used for the session
> > to the particular key exchange method used.
>
> Why is it inappropriate to bind the public key algorithm to the key
> exchange algorithm, yet appropriate to bind a GSSAPI mechanism to a
> key exchange algorithm?

I think you misunderstood my intent.  In Nico's ideal world where "key
exchange" and "host authentication" are separate steps, there's no reason
that any particular key exchange and host authentication algorithms should
be bound together.  What I was suggesting above was that while it would be
good for "key exchange" and "host auth" to be separate, that doesn't mean
that for "host auth" types that use a public key, the public key algorithm
should be a function of the "host auth" type, any more than the symmetric
key algorithms we negotiate today are a function of the algorithm we use
to exchange them, or vice versa.

Please note that GSSAPI is not magically interchangeable with other host
key types.  Even in your hypothetical world where GSS mechanisms are
represented as host key types, you couldn't use one with
dffie-hellman-group1-sha1 -- GSS requires context establishment, which
could potentially take multiple round trips, before you can sign or
encrypt anything.

I guess what I'm saying is that it's not appropriate to bind GSSAPI to a
"key exchange" in the sense of the independent anonymous-DH-or-whatever
that would exist in Nico's ideal world.  But in the world we have today,
where key exchange and host authentication happen in the same place, it is
impossible not to bind key exchange and host authentication together.  And
GSS-API must be bound to a particular host authentication method, because
that is what defines the wire protocol bits that allow for GSS context
establishment.


So, I think we've argued on this issue more than enough.  Let's take a
step back and answer the question of whether the multi-level negotiation
problem is worth solving at all.  I don't think I know the answer to that
yet.  If the concensus is that it should be solved, then we can discuss
how.


So...  Do we believe this problem is worth solving?
If so, how simple does the solution need to be to be worthwhile?
Does an alias-based solution meet our needs?
If not, are new messages the only alternative?
If so, is that solution acceptable, or too complex to be worthwhile?






> Yes, a transport message to deal with that is acceptable to me, but it
> was fairly recently that I realized that it was a valid option.
> Indeed, I believe that I will end up wanting to define such a message
> for PGP regardless of what GSSAPI ends up doing, though if it's
> possible to use the same message for both (and I believe it is) I'd
> like to do so.

GSSAPI has a mechanism for dealing with this within the key exchange, for
a single key.  I think we're talking about a general solution now.