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

From: [email-masked] (Sam Hartman)
Date: Wed, 16 Jul 2003 04:56:45 -0400 (EDT)

One desire in writing the GSSAPI draft was to allow sites to
optionally deploy GSS without any host keys specific to ssh.  It was
our belief that the mechanism introduced inht,in the draft to allow
gssapi key exchange to transport a host key and thus to allow hosts to
easily rekey met this need.

At least one integrator has chosen to select encrypted telnet as a
technology instead of ssh because our support for null host keys in
GSSAPI was weak.

After looking more closely at the situation I believe that we can and
should improve our support for this configuration.

First, I propose that the GSSAPI draft fold in
draft-weber-secsh-pkalg-none-00.  The none key type should be combined
with the null host key type already in the GSSAPI draft.  The intent
would be that you would use the null key type with GSSAPI key exchange
if you had no host key for the initial setup.

If later, you find that you cannot perform GSSAPI key exchange because
you do not have credentials, or gss_init_sec_context failed for some
other reason, you can engage in some other key exchange with the null
host key tipe.  This exchange would be integrity protected by the
existing channel, so the fact that you would effectively be doing
anonymous DH is acceptable.

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.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Jul 2003 11:28:05 +0200 (CEST)

On Wed, 16 Jul 2003, Sam Hartman wrote:

> with the null host key type already in the GSSAPI draft.

> possible ways of handling the host key transmitted by the GSSAPI key

I agree that both of these changes would be useful.  I'm going to wait a
little longer for comments, and then I'll produce a new version of the
document containing these changes and the other wording improvements we've
discussed recently, plus a better securit considerations section.

-- Jeff