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

From: [email-masked]
Date: Mon, 3 Mar 2003 17:53:35 -0500

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, March 03, 2003 4:40 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> On Mon, Mar 03, 2003 at 04:09:25PM -0500, [email-masked] wrote:
> > 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.
> 
> 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,
> 

If channel (address-base, session-based, or else) can be derived from the
local network layer alone, then no modifications to RPCSEC_GSS
(protocol-wise) would be required. Otherwise, Ugh...

> 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

Would be interesting to see other uses than in the particular case of
RPCSEC_GSS.

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

Agreed.

> 
> > 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
> 
> GSS mechanisms can do this already; it's what GSS channel 
> bindings are for.

One is passed from client, the other is derived from the local network
layer. Both are network address based though, if that's your definition of
the current GSS channel binding.

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

Peng

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Mar 2003 15:47:36 -0600

> > On Mon, Mar 03, 2003 at 04:09:25PM -0500, [email-masked] wrote:

[...]

> (protocol-wise) would be required. Otherwise, Ugh...

I believe it can be done, it just has to be specified and has to work
within the current framework of RFC2744 and RFC1964.  I believe it can
be done and I will write up an I-D about this.

> Would be interesting to see other uses than in the particular case of

SSHv2 w/ GSS key exchange, for example.  Using CCM in that case would
allow the client and server to use the "none" encryption/mac algorithms.

> the current GSS channel binding.

RFC2743 leaves the details to the C bindings RFC (!) and to the
mechanisms.

RFC1964, the Kerberos mech, can work as it is provided that new channel
bindings can be described in gss_channel_bindings_struct (rfc2744),
regardless of whether that is gross or not.

RFC2025 (SPKM) is another matter.  It provides an OCTECT STRING for the
channel bindings and does not specify its content or how to use it;
clearly that's not enough and so SPKM will require a [small] update.

Cheers,

Nico
--