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 08:30:30PM +0200, Jeffrey Hutzelman wrote:
> I agree.  Let's drop the 'multi' pseudo-algorithm proposal, and consider a
> new global request instead.  Ideally, we'd find a way to do this not as
> part of a particular connection service, since it really relates directly
> to the transport protocol.

Agreed.  Unfortunately, there is no method for negotiating the use of
features not present in the transport I-D.  This problem has come up in
the "gssapi host key algorithm usage" and "retrying keyex" threads.

To solve the multi host public key advertisement issue elegantly we'd
have to add a post-keyex, pre-userauth message and response.  And we'd
have to negotiate support for this during keyex.

To negotiate new features in keyex elegantly we must either make use of
the reserved uint32 field in the SSH_MSG_KEXINIT packet or rev the
protocol minor version.  Making use of that reserved field without
revving the protocol minor version is problematic because the transport
I-D does not discuss its semantics (do we have time to fix that?  I
guess I'd better comment on that before the last call ends).  And
revving the protocol minor version is a non-starter at the moment and
probably won't come to pass for quite some time.

(I'm ignoring, too, the issue of how v1 vs. v2 negotiation would happen
 if the v2 minor version is revved - let's not go there).

To negotiate new features in keyex without revving the protocol minor
version or without extending the SSH_MSG_KEXINIT may not be elegant but
it is doable.  I have suggested the use of bogus alg names for this
purpose in earlier threads.

We should explore the semantics of SSH_MSG_KEXINIT extensibility.

Cheers,

Nico
--