Re: IESG feedback on core drafts.

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

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
>