Re: draft-ietf-secsh-gss-keyex and null host keys

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

On Wed, 16 Jul 2003, Sam Hartman wrote:

> Second, I believe we should add text to the GSSAPI draft proposing two
> possible ways of handling the host key transmitted by the GSSAPI key
> exchange.
>
> 1) We clarify that environments may update their ssh keys much more
>    frequently if they typically use GSSAPI auth, and that user
>    interfaces should take this into account when noting that GSSAPI
>    key exchange has proposed a host key that would update a host key
>    the client already knows about.  In particular, strong warnings
>    about man in the middle attacks normally presented when a host key
>    has changed are probably not appropriate if the host key change is
>    authenticated by GSSAPI.
>
> Second we should say that implementations SHOULD store any host key
> sent via GSSAPI for the duration of the session so it can be used for
> rekeing, even if the key was not stored for long-term use.

I'm adding the following text to the next version of the draft:

    <t>In traditional SSH deployments, host keys are normally expected
    to change infrequently, and there is often no mechanism for validating
    host keys not already known to the client.  As a result, the use of
    a new host key by an already-known host is usually considered an
    indication of a possible man-in-the-middle attack, and clients often
    present strong warnings and/or abort the connection in such cases.</t>

    <t>By contrast, when GSSAPI-based key exchange is used, host keys
    sent via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as
    part of the GSSAPI key exchange, even when previously unknown to the
    client.  Further, in environements in which GSSAPI-based key exchange
    is used heavily, it is possible and even likely that host keys will
    change much more frequently and/or without advance warning.</t>

    <t>Therefore, when a new key for an already-known host is received
    via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue
    strong warnings or abort the connection, provided the GSSAPI-based
    key exchange succeeds.</t>

    <t>In order to facilitate key re-exchange after the user's GSSAPI
    credentials have expired, client implementations SHOULD store host
    keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the
    session, even when such keys are not stored for long-term use.</t>

-- Jeff