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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 Mar 2005 14:51:21 -0500 (EST)

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

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 31 Mar 2005 14:54:38 -0700

>     session, even when such keys are not stored for long-term use.</t>

Sounds good to me.

Thanks,

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 31 Mar 2005 18:42:57 -0500

>     key exchange succeeds.</t>

I think we need to provide additional guidance about hostkey update
acceptance..

one extreme:

In general, manually-exchanged-via-trusted-path hostkeys should not be
replaced by GSSAPI-authenticated ones; the former may be considered akin
to trust anchors.

the other: 

if you learned the hostkey via gssapi, you can learn the new one via
gssapi, too..

							- Bill

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Mar 2005 22:22:15 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> one extreme:

    Bill> In general, manually-exchanged-via-trusted-path hostkeys
    Bill> should not be replaced by GSSAPI-authenticated ones; the
    Bill> former may be considered akin to trust anchors.

I'm not actually sure I believe this is true.  In practice the fact
that there is no good rekeying mechanism for manual keys suggests that
you want to be relatively open in accepting mechanisms to rekey.  For
example I'd sort of like to see a dialogue asking if I wanted to
replace a manual key with a gssapi key if there was one.