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>