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

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 14 Nov 2004 20:47:57 -0500

On Wednesday, July 16, 2003 11:28:05 +0200 Jeffrey Hutzelman 
<[email-masked]> wrote:

> On Wed, 16 Jul 2003, Sam Hartman wrote:
>
>> 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.
>
>> 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.
>
>
> I agree that both of these changes would be useful.

And yet, I haven't done anything about them. :-(

Quite some time ago, I came to some conclusions about "none":

- It is probably a good idea to have some mechanism along these lines
  to allow rekeying in the absence of whatever credentials allowed the
  original key exchange to happen.

- "none" has significantly different semantics from "null", and combining
  them is not only inappropriate but potentially dangerous.

  "null" is a host key algorithm which does not claim to provide signing
  or encryption operations, and which therefore cannot be used with any
  keyex algorithm which requires such operations.  For example, it cannot
  be used with the mandatory DH-based algorithms, because those require a
  host key algorithm which supports signing.  This algorithm is valuable
  any time a keyex algorithm like gss-* might be used and no other host
  key is available.

  By contrast, "none" is an algorithm which _claims_ to provide both
  signing and encryption operations, but for which those operations don't
  actually do anything.  That is, the encrypt/decrypt operations are the
  identity mapping, and the verify-signature operation always succeeds.
  This algorithm would really be better named "noop".  This algorithm is
  intened to be used only during rekeys, when it can be assumed that
  confidentiality and integrity are provided by the ssh transport layer.
  Its use during initial key exchange is prohibited, and with good reason.

  These algotithms are quite different, and combining them under a single
  name would be quite a bad idea.  Doing so would introduce a single name
  which must describe one set of behaviours during initial key exchange,
  and a different set during a rekey.  The set of key exchange algorithms
  that could be used with this host key algorithm would differ depending
  on the context.  It would be easy to screw this up and end up with an
  insecure result.

- Given that "none" and "null" are distinct algorithms and should not be
  combined, I do not believe that "none" belongs in the GSS document at
  all.  I would like to see this work proceed, and am willing to take up
  editorship of Joel's document if he is no longer available to work on
  it.  I suspect it can be completed fairly quickly.  But I don't think
  it belongs in the GSS document.

I sent mail to Joel about this quite some time ago, but I can't find any 
indication that I've brought it up on the list previously.  Of course I 
will roll the definition of "none" into the GSS document if that is the 
consensus of the WG, but I don't believe it is appropriate to do so, and
I'd rather get the document finished in something close to its current 
state.

Sam also proposed some text recommending handling for host keys received 
via the GSS mechanism.  I agree these changes are a good idea; assuming 
there is agreement I will make them in the next rev.

-- Jeff