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

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

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

I don't understand why not.  A ``host key algorithm'' is a
subcomponent that is called by a key exchange algorithm in order to
verify the identity of a host.  The interface between the key exchange
algorithm and the host key algorithm is well defined, creating a
certain sort of interchangability.  The key exchange mechanisms
described by draft-ietf-secsh-gsskeyex all make the same GSSAPI calls;
the only difference is which GSSAPI mechanism is being used.

Also, the reason that I use the krb5 GSSAPI mechanism is because I
have a keytab, and I want to verify that that keytab matches up
properly.  The purpose of using the GSSAPI mechanism is to verify the
host's identity using a cryptographic key.

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

Yes, but it's the wrong way to avoid that problem, precisely because
if I want to use pgp-sign-rsa if that's available, and then use
Kerberos, and then use ssh-rsa, there is no way to specify that.

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

I think you're confused on the definition of a host key.  You seem to
be assuming that a host key is always a public signing key.  But
draft-secsh-transport already allows for the possibility that you can
have a public encryption key, which would require a different sort of
key exchange algorithm.

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

What problem are you trying to solve that switching the order and
treating GSSAPI mechanisms as host keys can't solve?

I can't think of any reason why I'd want to use one key exchange
mechanism with pgp-sign-rsa and a different one with ssh-rsa, which
seems to be the problem you're trying to solve, so I'm wondering why
you're trying to solve that problem.