Subject: RE: [nfsv4] More on CCM

From: [email-masked]
Date: Tue, 11 Mar 2003 18:30:27 -0500

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 5:18 PM
> To: Nicolas Williams
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] More on CCM
> 
> 
> 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.
> 
> >
> > - 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.
> 
> >
> > - 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.
> 
> >
> > - 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
> 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.
> 

ONC RPC did not specify a network model to begin with. Instead,
it is completely up to the ULPs to choose transport protocols
and do connection management. For a particular ULP, requiring
CCM/TCP binding may not always be the right thing to do.

It makes more sense to bind the CCM to the IPSec phase-2 association.
This way, the CCM can be used for multiple TCP connections as long
as they are over the same IPSec association. It offers the same
secure binding at the network level without impacting the transport.

> (If it is good enough for iSCSI, it is good enough for ONC RPC).
> 
>     -mre
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4