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

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> > 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.
Now, I'm not claiming we can arrange it at this late data, but it seems like
maybe the correct way to address your concern would be to seperate key
exchange and server authentication.

Putting aside how to do this without a significant rewrite of the core 
drafts,
doing this might have several advantages.

1. I believe the problem you have would be resolved.  Rather than
'publickey' algorithms in our key exchange, you would instead
have 'server-authentication' methods.  Gssapi would not be a
key exchange method, it would be a server-authentication method.

2. Gssapi would have been a simpler draft because it would have had
to define diffie-hellman key exchange as well, and we would be
wondering whether we should do gssapi-group-exchange as well.

Now, on the half-serious, we could, but I'm not sure we want to, side of 
things, we
could introduce a new service, called authentication, instead of 
userauth, and make
it responsible for handling both host and user authentication.

We could do this in conjuction with the new KEX2 message you are proposing.

On the brighter side, it wouldn't hold up the core drafts, we could 
address other userauth
problems that have come up, and we would be world famous :-)

On the darker side, it is a lot of work, will take time, and we might be 
world infamous for
even suggesting it :-)

At any rate, I was hoping perhaps some clarity would be brought by the 
realization that
it is the tying of host authentication and key exchange that is the root 
of the problem.

Joseph