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

From: Mike Eisler <[email-masked]>
Date: Mon, 3 Mar 2003 21:30:48 -0800 (PST)

> 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.

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.

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