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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Sat, 19 Jul 2003, 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.

OK; that's fair enough.  I think we have been discussing four basic
problems, and have even come to agreement on solutions for two of them.
Allow me to recap somewhat, and then we can decide where to go from here.

(1) It is desirable for GSS-API key exchange to be able to proceed
    even when the server has no host key and the user's credentials have
    expired.  This is particularly important in the case of a rekey,
    where a failure means the session will be disconnected.  Ken Hornstein
    reports that this problem is causing difficulties for him in deploying
    ssh in his environment.

    Joel Weber proposed a solution to this, in the form of an individual
    internet-draft submission, draft-weber-secsh-pkalg-none-00.txt.  This
    proposal defines a new hostkey algorithm, to be used only during
    rekey, whose semantics amount to not actually performing any signature
    checking or encryption operations.  While there was some initial
    concern, people eventually realized that the rekey operation would be
    protected by the existng encryption.  It was then agreed, at least
    among those who spoke up, that this should be rolled into the gsskeyex
    draft.

(2) Currently, when key exchange fails for any reason, the session is
    disconnected and a client which wishes to try another key exchange
    method must reconnect and try again.  This has the disadvantage that
    any negotiation performed as part of the first connection is lost,
    and particularly that the sequence of negotiations and failures that
    lead to the ultimate selection of a key exchange algorithm and host
    key are not properly authenticated.

    To solve this problem, it has been proposed that key exchange be
    allowed to fail and be retried without disconnection, using a method
    that would allow the complete process to be properly authenticated.
    Exactly how to do this is under discussion, but it would likely
    involve a new message to be used when keyex fails, combined with one
    of (a) a rev in the protocol version, (b) a backward-compatible change
    to the format of the SSH_MSG_KEXINIT message, or (c) a new message to
    be used in place of SSH_MSG_KEXINIT.  I believe it is generally
    agreed that (a) is not acceptable.

(3) There is a multi-level negotiation issue involving the negotiation of
    keyex and host key algorithms.  These are currently listed and
    selected almost as if they were independent, when in fact that are
    not; in particular, a client must choose and express its order of
    preference for key exchange algorithms without regard to what host key
    algorithm will be used.  This makes it impossible to express cases
    like that described by Joel Weber, in which one would prefer to use a
    traditional DH algorithm (either group1 or group exchange) with a
    pgp-* host key, but failing that, to try a mechanism like GSS-krb5
    before falling back on DH using an ssh-* host key.

    IMHO, this is clearly the issue with the most contention with regard
    to finding a solution.  There are three separate proposals under
    discussion:
    (a) Joel Weber's proposal of turning GSSAPI key exchange into a single
        keyex algorithm with multiple host key types, and simultaneously
        reversing the order of selection such that the host key type is
        selected before keyex algorithm.  This involves a change in
        semantics which would be signalled by one of the methods described
        in (2)(a), (b), or (c) above; again, I believe it is generally
        agreed that (2)(a) is not acceptable.
    (b) Nico Williams' proposal of inventing "alias" names for keyex
        algorithms, which would be negotiated in the usual way but would
        carry with them the semantics of being restricted to particular
        host key types.  I expanded on this to propose a general way of
        constructing alias names, rather than requiring them to be
        registered individually for each { keyex, host key } tuple for
        which they are to be used.
    (c) The third proposal (whose origin I can't recall, but it might have
        been myself or Nico Williams) is to exchange a list of { keyex,
        restrictions } tuples, where restrictions might include host key
        algorithms or other parameters.  This would involve a change in
        the way in which this information is exchanged, using one of the
        methods described in (2)(b) or (2)(c) above.


(4) It is desirable under certain circumstances to securely transmit to
    the client a host key which was not used to authenticate the key
    exchange; particularly, a key not known to the client in advance.
    This is useful for bootstrapping a client's host key database using
    a preexisting authentication infrastructure (PGP, PKI, Kerberos,
    DNSSEC, etc), and also for allowing "rollover" when a host decides
    to change its long-term key (Ken Hornstein points out that some sites
    have policies which require long-term keys to be changed on a regular
    basis).

    The GSSAPI-based key exchange algorithms provide an optional mechanism
    for this, by allowing the transport of a host key belonging to the
    algorithm selected in the first steps of key exchange, and including
    that key in the exchange hash.  However, a more general solution is
    desired, which would allow multiple keys to be transported, as well
    as allowing the transport of additional host keys when using keyex
    algorithms other than the GSSAPI-based ones.

    My original proposal was to create a host key pseudo-algorithm which
    would actually carry a list of keys, and perform encryption and
    signature operations as with the first key.  I have since withdrawn
    that proposal, in favor of one proposed by Nico Williams, in which
    a new message type is defined which can be used to transport arbitrary
    host keys once the key exchange has been completed and new keys have
    been taken into use.


I believe the problem described in (1) is well-understood, and the
solution is fairly clean.  Barring any further discussion or objections
from the working group (which has been mostly silent on this), I will be
incorporating Joel's solution into the description of the 'null' host key
algorithm in the next version of the gsskeyex document.

I also believe the problem described in (4) is well-understood, and the
solution is again appropriate and fairly clean.  However, I think some
further work is required to nail down the details.  I will probably
contact Nico offline about preparing an internet-draft to document this
proposal.


(2) and (3) both involve significant changes to the protocol.  I believe
these can both be done as backward-compatible extensions without holding
up the core drafts.  However, I also agree that we should carefully
consider whether these problems are worth solving, particularly given the
amount of work required to specify them properly, evaluate the security
implications, and implement and test the changes.


-- Jeff