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 Thu, Jul 17, 2003 at 02:48:18PM -0600, Joseph Galbraith wrote:
> 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.

Correct.  And that's how it should have been from the get go.  But I do
think it's too late and I do think we have a not-elegant-but-bacwards-
compatible way of solving the problems with kex/key preference
expression and kex re-triability - I just posted on that.

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

But each of these would have its own kex method too - to separate the
two now would be too much work and not backwards compatible -> a big PITA.

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

Yup - kex and kex auth should have been separate all along.

> 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 :-)

Yes it would hold up the core drafts.  We'd have to define a KEX1 vs.
KEX2 negotiation mechanism and all that.

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

We've been discussing it already, and I can imagine that the chair might
be getting gloomy :)

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

I think so.

Cheers,

Nico
--