Re: [nfsv4] More on CCM

[Nicolas Williams <[e-mail]>]

On Tue, Mar 11, 2003 at 02:18:03PM -0800, Mike Eisler wrote:
> Nicolas Williams wrote:
> 
> > CCM should have three variations, each with their own OID, each being a
> > trivial wrapper around an underlying GSS mechanism. The three
> > variations should be:
> 
> These might be too many variations. Offering a wide array
> of choices to the customer is just too confusing. And
> even if we can design a way to remove confusion, requiring
> all this array of choices reduces the chances of a particular
> implementation supporting them and reduces chances of
> interoperability. (An example of this is action was the
> surprise at the last Connectathon, where several of us found that
> 3DES keys were being created by the KDC, and as a result,
> most of us NFS/krb5 implementors couldn't interoperate).
> The goal is to minimize difficulty of implementation.

See below.

The 3DES issue you refer to is a configuration issue, perhaps a
maddening one to you, but still not an interop issue.

> >
> > - CCM-with-network-address-channel-bindings
> >
> > For use with IPsec and without NAT. Initiators and acceptors would
> > be required to verify that an IPsec SA exists for the network
> > addresses referenced in the channel bindings.
> 
> Given the lack of  NAT support, I can't see why implementors with
> limited resources would bother. I'm certainly not inclined to
> lobby my management to fund this.

The reason I offer this is that this is trivial to implement today and
secure.  It won't work through NAT though.

> >
> > - CCM-with-session-hash-channel-bindings
> >
> > For use with IPsec, SSHv2, etc.. without regard to NAT.
> 
> I think hash-key bindings are very slick. I also think the API
> support to retrieve them is far from ubiquitous. And there's no
> existing GSS-API or krb5 infrastructure for them either, and
> not even a specification.

The GSS-API certainly supports channel bindings, though they are
optional.  Your implementation may not, but if you want CCM to work
securely then you'll have to add channel binding support.

The specification of the IPsec, SSHv2, etc... hashes has to be done.
I already know what that specification is for IKEv1 (IPsec) and SSHv2;
only IKEv2 remains.  Specifying these hashes is not difficult.

I will contribute text if you wish.

Since CCM-with-session-hash-channel-bindings is the only secure form of
CCM that will work through NAT I think that this form has to be
specified.  Between this form and the first one above we have two forms
of CCM, and if I had to choose only one I'd choose this one.

> >
> > - CCM-with-no-channel-bindings
> >
> > For debugging use; not to be used in production.
> >
> >
> > The reason that separate pseudo-mechanisms are needed for the network
> > address channel bindings and session hash channel bindings is so as to
> > make it possible to negotiate which one to use.
> 
> Following Dai Peng's and David Black's comments, and considering
> that useful (NAT-less) GSS channel bindings don't really exist, my thinking
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
They are trivial to define.  To repeat:

 - For IKEv1 (IPsec) the channel bindings consists of: the concatenation
   of the HASH_I and HASH_R for the SA as defined in IKEv1 (rfc2409)

 - For SSHv2 the channel bindings consists of: the key exchange hash as
   defined in draft-ietf-secsh-transport-15 and
   draft-ietf-secsh-gsskeyex-06

 - IKEv2 I've not researched yet; but surely it too can have channel
   bindings specified

> is to specify the use of RPCSEC_GSS over CCM to limit its use
> for the duration of the ULP's session. Most ULPs that use ONC RPC don't
> have a session, but most ONC RPC ULPs do work over
> connection oriented transports. So this effectively means that
> sessionless ONC RPC ULPs must bind a particular CCM context to
> a particular TCP or SCTP (whenever the wg gets around to
> defining ONC RPC semantics for SCTP) connection.

ULP?

> (If it is good enough for iSCSI, it is good enough for ONC RPC).

Wrong.  If some other protocol's spec has it wrong that is no excuse for
us to get it wrong also, particularly now that we've had this discussion
in public (years from now others will be able to point the finger at us
and say "they knew of the problem and chose to ignore it").  I don't
find that acceptable.  Furthermore the IETF security ADs, or the IESG
may also find it unacceptable; if, OTOH, they're ok with this, then
fine, it won't be my fault :) :)

Cheers,

Nico
-- 
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4