Re: IESG feedback on core drafts.

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

Note: this was merely an attempt to illustrate a possible future use of
the SSHv2 "none" crypto alg.

Perhaps there should be text explicitly allowing the use of "none" when
the key exchange and/or userauth cryptographically binds authentication
at the SSHv2 layer to integrity/confidentiality services at a lower
layer:

   "
   The "none" encryption algorithm MAY be used where authentication at
   the SSHv2 layer is cryptographically bound to the cryptographic
   integrity and/or confidentiality services provided by a lower layer,
   such as IPsec.  Other uses of the "none" encryption algorithm are NOT
   RECOMMENDED.
   "

For more details on this proposed GSS pseudo-mechanism look at the NFSv4
WG list archives.  And note that it's a trivial wrapper around an
underlying non-pseudo mechanism (almost like an OID prefix, if you
wish).

Cheers,

Nico

On Fri, Apr 04, 2003 at 01:29:16PM -0800, Nicolas Williams wrote:
> Another legit use of "none" would be with GSS keyex and a channel
> bindings that cryptographically bind the GSS context to some underlying
> secure channel (e.g., IPsec).
> 
> Don't laugh.  Exactly this sort of thing is being discussed on the NFSv4
> list.  The current approach is to define a new, trivial GSS
> pseudo-mechanism for the purpose of negotiating channel bindings - if you
> use this mechanism then channel bindings[*] must be used[**].
> 
> So, SSHv2 w/ GSS key exchange + this new GSS pseudo-mechanism + channel
> bindings to IPsec + SSH "none" crypto alg == SSH w/ crypto at IPsec
> layer only.
> 
> This is much more useful in the context of NFSv4 than in the context of
> SSHv2, but it sure seems applicable to SSHv2.
> 
> Cheers,
> 
> Nico
> 
> [*] GSS-API supports two kinds of channel bindings: network address,
>     which are useless in this context, and "transformations of
>     encryption keys" [rfc2743].
> 
> [**] GSS channel bindings are opitonal and generally not used, therefore
>      a way to force their use is needed and by making it a
>      pseudo-mechanism any protocols that can negotiate GSS mechanisms
>      can negotiate the use of this pseudo-mech and so the use of channel
>      bindings.
> 
> 
> On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote:
> > On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
> > >    The "none" cipher is provided for debugging and should never be used
> > >    except for that purpose.  It's cryptographic properties are
> > >    sufficiently described in RFC 2410.
> > 
> > I believe the "none" cipher has legitimate uses besides debugging.  You
> > may want the authentication mechanisms provided by SSH, but not the data
> > confidentiality.  EG: you are copying already encrypted data between
> > machines that have such low CPU power that encryption is a significant
> > overhead.  Even if you disagree, *it goes without saying* that you
> > wouldn't use the "none" cipher where integrity/privacy matters.
> > 
> > If you /were/ to keep this text, shouldn't 'should' be in caps?
> > 
> > RFC 2410 seems too humorous to be referenced in a security considerations
> > section.  Maybe I'm just in a bad mood though.
> > 
> > /fc
> >