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'm likely to submit an individual draft soon describing an
SSH_MSG_KEXINIT2 message real soon now.  (Existing implementations
will see it as a reserved message and send a message back saying that
they don't recognize SSH_MSG_KEXINIT2, at least if they follow the
IETF spec.)  Specific things I want to change vs SSH_MSG_KEXINIT:

1) You iterate primarily over the host key list, rather than the
   algorithm list.  Once you find a host key type that's in common
   between the client and the server, you then iterate over the key
   exchange algorithm list looking for the first algorithm on the
   client's list that's also in the server's list that works with the
   host key type you picked.

2) Each gss mechanism becomes a host key type, so that if your order
   of preference is kerberos, pgp, gsi, x.509, bare ssh key, in that
   order, you can actually express that preference (which you just
   can't do in that order with the way SSH_MSG_KEXINIT and the gssapi
   draft are currently specified).

3) The language optional field as it exists goes away.

4) Any optional fields after the standard set of required fields each
   start out with a name indicating what they are negotiating.  So,
   you could have, for example

secondary-host-key,ssh-dss,ssh-rsa

if you wanted to negotiate public key algorithms for a secondary host
key.  The functionality of the optional language field in
SSH_MSG_KEXINIT would also have a name added to the front of it.

Perhaps the multi type you're proposing should be defined for
secondary-host-key but not for use with a key exchange algorithm to
actually verify the host's identity?

5) In order to prevent downgrade attacks, an implementation that would
   prefer to use SSH_MSG_KEXINIT2 lists SSH_MSG_KEXINIT2 as a keyex
   algorithm if it ends up sending an SSH_MSG_KEXINIT message, and if
   the SSH_MSG_KEXINIT from the peer includes SSH_MSG_KEXINIT2 as a
   key exchange algorithm when you also included SSH_MSG_KEXINIT2 as a
   key exchange algorithm, you abort.

Does this seem like it would help with solving the problems you're
interested in solving?