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:

> The interface between the key exchange
> algorithm and the host key algorithm is well defined

And does not match the interface between a GSSAPI application protocol and
a GSSAPI mechanism.

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

No, it's not.  Please note that the problem you describe exists _whether
or not_ the intervening mechanism is GSS-KRB5.  krb5 is not a "host key"
that you want to use in preference to ssh-rsa; it's a key exchange that
you want to use in preference to using a DH exchange signed by a non-PGP
RSA key.  The problem would exist for some other key exchange, too.

The method in which GSS mechanisms are named doesn't make this problem go
away, since the scope of the problem goes beyond GSS.  However, it doesn't
make it worse, either.


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

No, I'm not confused.  I know what the sshv2 protocol defines as a host
key.  GSS mechanisms are not host keys.

I don't think we're going to make any progress on this issue, and I
haven't heard any comments on this from the rest of the working group.  At
the moment, I'm disinclined to make a sweeping change of the sort you
describe, because

(1) I don't believe that it is either necessary or sufficient to solve
    the multi-level negoitation problem.
(2) I don't believe it's the appropriate abstraction.
(3) I don't see a working group concensus for a change.  Actually, I don't
    see much of any response, but you need a concensus to make a change.
(4) We have a fair bit of implementation experience with the current
    approach, including multiple implementations some of which support
    several GSSAPI mechanisms.  It does work.
(5) It's late in the process, which IMHO raises the bar for changes.
(6) Again, lack of concensus to make the change.

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

What problem are you trying to solve that treating GSSAPI mechanisms as
host keys will solve?  The multi-layer negotiation problem (keyex must be
selected before host keys) is not unique to GSSAPI, and treating GSSAPI
mechanisms as host keys makes the problem _WORSE_, not better.

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

I think you're limiting your vision to the mechanisms you happen to see
today, and what you can think of yourself using.  All of the algorithms
are replaceable, which can lead to arbitrary combinations, including
algorithms not presently in use.  For example, you'd have exactly the same
problem if you substituted the SRP algorithm that was discussed in another
thread instead of one of the GSS algorithms.

The problem is a general problem; let's use a general solution.

-- Jeff