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

From: Nicolas Williams <[email-masked]>
Date: Sat, 1 Mar 2003 00:34:59 -0600

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.

Fortunately GSS-API provides a mechanism for dealing with channel
bindings.  CCM has to ensure that GSS contexts established through it
are correctly bound to the underlying network layer security.  I think
it will; there's certainly nothing to impede it.

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.

One very neat side effect of having CCM channel bindings for binding to
the underlying network is that you can have anonymous IPsec/whatever
connections and still use CCM - Secure NFS over anonymous IPsec if you
wish.

[*] Sam Hartman, Tom Yu, Mike Eisler, myself.

Cheers,

Nico
--