KEX problems

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Sat, Jul 19, 2003 at 01:29:16PM -0400, Bill Sommerfeld wrote:
> So, I'd like to call for a general moratorium on such proposals until
> such time as we have a clear statement of why anything NEEDS to be
> changed, and a clear understaning of the requirements of any such
> change so we can figure out the path of least resistance.

There are two, well, three problems that we've been discussing.  These
are all related only in that they have something to do with key
exchanges.

The problem statement:

A.  Key Exchange and Host Authentication Preference Expressibility

   This is a very unlikely problem that occurs under the following
   circumstances:

      - the client can support the use of three or more host
	authentication infrastructures

      and

      - at least two of those host authentication infrastructures are
	based on public key based using the dh-group1-sha1 or
	dh-group-exchange-sha1 key exchange methods

      and

      - at least one of those host authentication infrastructures is not
	based on host public keys usable with the dh-group1-sha1 or
	dh-group-exchange-sha1 key exchange methods

   The problem then is that some preferences cannot be expressed with
   the current KEXINIT message and algorithm negotiation algorithm.

   One example given to the list was one where the client wishes to
   offer the following preference:

      - diffie-hellman-group1-sha1 w/ pgp-* host keys
      - gss-group1-sha1-*
      - diffie-hellman-group1-sha1 w/ ssh-* host keys

   IMO, the proximate causes of this problem is the conflation of raw
   key exchange methods (DH) with host authentication methods (e.g.,
   ssh-rsa, pgp-dss, x509v3-sign-rsa, ...) and the expectation that all
   host authentication methods would be based on public key
   cryptosystems.

   Thus draft-ietf-secsh-gsskeyex defines its own key exchange method
   which is based on DH because the ones defined in the transport I-D
   are not appropriate since there is no way to fit in the GSS-API to
   authenticate the server.  A separate gss-group-exchange-sha1-* key
   exchange method will eventually be needed also, adding more
   duplication This too is a result of the conflation of key exchange
   and host authentication methods in draft-ietf-secsh-transport.

   A generic key exchange method based on DH plus a generic message
   exchange for server authentication would have allowed both, the use
   of public keys and the use of the GSS-API to authenticate the server
   to the client and prove that there's no man-in-the-middle.  It is
   years too late to consider this in any way other than academically.

   I do not propose that we solve this problem by starting from scratch.  In
   fact, I do not propose solving this problem unless we also want to
   solve (B) - see below.

B.  Key Exchange Should be Re-Triable

   SSHv2 clients and servers must commit to undertaking a single initial
   key exchange method per-connection and disconnect if that method
   fails.

   In the case of public key / certificate based host authentication
   algorithms the client might well refuse to accept the server's keys
   once the client knows what they are, but by then the key exchange
   cannot be re-tried.

   This problem too is unlikely (though I myself have experienced it
   plenty, mostly in situations where a server had multiple identities
   but the server's GSS-API implementation did not support the full
   range of GSS_C_NO_CREDENTIAL/GSS_C_NO_NAME semantics and the SSHv2
   server software did not fully support virtualization).

C.  Distribution of Authenticated Servers' Other Keys

   Draft-ietf-secsh-gsskeyex allows servers to send one, and only one
   public host key to clients protected by the gss-group1-sha1-... key
   exchange.  The I-D should have allowed for hosts to tell clients of
   all their host keys - but then, this feature should be not be
   specific to the GSS key exchange method, it should be available in
   all cases after key exchange succeeds.


IMO, problem (B) is the problem most worth solving, but it requires
extending the key exchange phase of the protocol, one way or another.

IMO, problem (C) is the simplest to solve and does not require modifying
the key exchange part of the protocol.

IMO, problem (A) is the problem least worth solving, but if we solve (B)
then we should consider solving (A) as well.

IMO, problems (A) and (B) can be solve backwards compatibly through
extensions to the KEXINIT message (see its 'reserved' field).  For this
we'd need draft-ietf-secsh-transport to have some text describing the
meta-semantics KEXINIT extensions and their negotiation so that problems
(A) and (B) can be solved in a separate I-D.  I will submit a last call
comment on this point.


Cheers,

Nico
--