Subject: RE: draft-eisler-nfsv4-ccm-00.txt

From: [email-masked]
Date: Tue, 4 Mar 2003 15:07:24 -0500

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2003 12:31 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> > From [email-masked]  Mon Mar  3 13:09:13 2003
> 
> > > -----Original Message-----
> > > From: Nicolas Williams [mailto:[email-masked]]
> > > Sent: Saturday, March 01, 2003 1:35 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: draft-eisler-nfsv4-ccm-00.txt
> > > 
> > > 
> > > On Fri, Feb 28, 2003 at 10:42:25AM -0500, [email-masked] wrote:
> > > > This is prevented by ensuring the binding between the CCM 
> > > context and the
> > > > secure channel is legit, as outlined in 2a. Additional 
> > > crypto is not needed
> > > > here to achieve authentication because of IPSec.
> > > 
> > > Yes, you're right, this is crucial.
> 
> > Glad we are on the same page regarding this.
> 
> I'm on a different page. Correct me if I'm wrong, but
> channel bindings are absent in
> several standards track protocols (e.g. SASL, iSCSI) that have an
> authentication phase. It is nice to have, but the specifications
> for doing channel bindings that including network layer
> keying material hashes are absent.
> 

I think the answer to your question lies in that there is no tying between
RPC and the underlying TCP connection, unlike in iSCSI. In RPCSEC_GSS, the
initiator authenticates once (user authentication) and is able to use the
context handle in a subsequent request over any TCP connection, existing or
new. As David pointed out, the channel binding is implicitly done in iSCSI
because the network/auth model there is each TCP connection has to be
individually authenticated.

> It is the responsibility of the people deploying NFS, Kerberos, IPsec,
> SSH (or any other connection protection scheme), and CCM
> to use god key management.
> 
> (This problem seems similar to the problem of getting applications
> to behaving properly when using mandatory locking).
> 
> > > We[*]'ve had some conversations about this here at 
> > > Connectathon '03 and
> > > the upshot is that CCM has to have channel bindings 
> binding CCM GSS
> > > contexts to the underlying network security mechanisms.  
> IPsec, IKEv2,
> > > SSHv2, etc... must each have a CCM channel binding type.  
> The channel
> > > bindings in question will have to bind to cryptographically secure
> > > channel identifiers.  GSS channel bindings can be 
> optional, of course,
> > > at the accpeptor's discretion.  In practice this means that the
> > > initiator's tokens must provide for the optional inclusion of 
> > > typed CCM
> > > channel binding data and the acceptor's tokens must 
> provide for the
> > > optional inclusion of a MIC of the typed CCM channel binding data.
> 
> Why isn't this a problem for mechanism under CCM to provide?
> RFC1964 specifies channel bindings for Kerberos V5, albeit,
> with no keying material from IPsec et. al.
> 
> > The GSS channel binding is not included in RPCSEC_GSS data 
> requests. In
> > order to verify data requests being sent over specific 
> channel, the server
> > must be able to derive channel binding from local network layer.
> 
> Well, the Solaris rpcsec_gss API allows for channel bindings,
> and gss_init_sec_context/gss_accept_sec_context
> does to. The channel bindings are to 
> supposed to be carried by the mechanism. CCM is trivial mechanism,
> so again, it is the problem of the underlying mechanism.
> I don't think any changes to the RPCSEC_GSS specification are 
> required.
> 

We need a way to derive channel info for each RPCSEC_GSS data request. And
we won't be able to get it from the GSS mechanism because the GSS channel
binding is limited to context initialization. My hope is that we can get it
from the host's network layer alone.

> To do channel bindings that are useful requires API changes
> to IPsec implementations. It also requires specifying
> what IPsec, SSH, etc. channel bindings look like. It
> may even require a revision to RFC1964 and RFC2025.
> 
> These aren't things that are going to happen soon.
> Meanwhile, 10 gbit networks are coming sooner.
> My proposal gives implementors and users tools to make
> choices with reasonable, and neglible tradeoffs in security.
> The same tradeoffs iSCSI makes (apparently, because I
> can't find any mandatory or even option per message integrity
> checking in iSCSI). 
> 
> 	-mre
> 

Peng