Re: applying AES-GCM to secure shell: proposed "tweak"

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Apr 15, 2009 at 08:06:07PM +0200, Niels Möller wrote:
> I'm strongly against adding new general option or negotiation
> frameworks just to support aead. That's simply not worth the effort.

+1

For me that goes for Mouse's and Jeff's proposals both.

> If we can't come up with a reasonable way to "shoehorn" it into the
> current algorithm selection precedures, I'd prefer to say "Sorry,
> aead-style algorithms were not envisioned when the ssh protocols were
> designed. It can't be supported. Maybe it'll be supported in ssh
> protocol version 3 in the very distant future.".

I agree, but it won't come to that.  The reason is that we _can_
shoehorn AEAD into SSHv2.

We already have a number of things shoehorned into the SSHv2 kex, such
as:

 - GSS-API (which is not like the host authentication algorithms
   originally envisioned)

    - not only is there the whole GSS-API token exchange and the MIC
      sent by the server to authenticate the key exchange, but also

    - there's the need for a "null" or "none" host key alg to support
      re-keys without re-authentication, but only re-keys.

 - negotiation of compression only post-authentication (a very useful
   and awesome OpenSSH extension)

AEAD is trivial by comparison to the GSS-API: the MAC algs are
irrelevant when AEAD ciphers are negotiated, for the obvious reason that
the MAC is subsumed into the cipher mode.  There's no need to agonize
over "none".

What else might we shoehorn into kex?  Well:

 - Key transport instead of key agreement.  This one right and truly
   screws with the idea of separate key exchange and host auth algs.  So
   what?  It can still be shoehorned in in exactly the same way as AEAD:
   if you pick a key transport key exchange alg then the host auth alg
   negotiation becomes irrelevant.  (Oh, I suppose one could sign a key
   transport with a separate signature key, thus allowing one to
   separate key exchange and host auth even in the key transport case,
   but that just seems silly as it adds a public key op that should be
   unnecessary.)

 - Retriable initial kex, for example (this is so that GSS-API auth
   failure need not lead to the connection being closed).  For this I'd
   use the reserved unsigned 32-bit int in the KEXINIT as a flags field
   -- if both the client and the server have the flag set for re-triable
   kex then GSS-API failure should not lead to connection closure.

Nico
--