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

From: [email-masked]
Date: Mon, 3 Mar 2003 16:09:25 -0500

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

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

GSS channel binding, IMHO, is not well suited for the problem we have at
hand. I think a channel binding derived from the local network layer is more
appropriate.

The GSS channel binding passed from the client during context initialization
is the client's view of the channel, which may not be quite the same as what
the server sees. For example, if the channel binding were to include IP
address, NAT would cause different views of the channel. For this reason, it
is more reliable for the server to derive the channel binding from the local
network layer.

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.

The channel binding is set and remembered during context initialization and
referenced during subsequent data exchanges. The binding seems to be best
kept by the RPCSEC_GSS layer than by the GSS mechanism merely because there
is no way to get it from GSS-API.

For example, something like the following might work,

1. Client sends GSS context initialization token over secure channel
2. Server receives the token and accepts it; if successful, will inquire the
channel info (from server's network layer) and record the binding between
the result context and the channel
3. Client sends data request referencing the context over the a secure
channel (without crypto for the purpose of authentication as required if
over a non-secure channel)
4. Server receives the request, extracts the context handle to look up the
context, inquire the channel info, and verifies the channel binding

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

Peng

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Mar 2003 15:40:00 -0600

> is no way to get it from GSS-API.

1) GSS-API does allow for channel bindings based on "transformed
   representations of keys", so GSS channel bindings are applicable to
   IPsec.

   Unfortunately, some work has to be done to specify such channel
   bindings.

2) I don't know if changing RPCSEC_GSS is something we can do now; I'll
   have to think about that.  Regardless,

3) IPsec and other cryptographic channel bindings may have uses in other
   areas, so I think that a general way of binding GSS contexts to
   underlying network (other than binding network addresses) would be
   useful.  I'd rather not introduce an extra-GSS mechanism for channel
   bindings when we can make the GSS channel binding mechanism work (it
   works already anyways, for network-address type bindings).

4) Channel binding types that represent IPsec sessions will not be
   affected by NAT; NAT affects network address channel bindings.

> context, inquire the channel info, and verifies the channel binding

GSS mechanisms can do this already; it's what GSS channel bindings are for.

We can introduce new channel binding types in such a way that they will
work with the Kerberos GSS mech and SPKM, though the latter is
underspecified with respect to channel bindings and so will require an
update (I doubt anyone implements SPKM channel bindings; I'd like to
know though, so if you do, please let the WG know).

Cheers,

Nico
--