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

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

On Wednesday, July 16, 2003 11:28:05 +0200 Jeffrey Hutzelman 
<jhutz%cmu.edu@localhost> 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