Subject: [nfsv4] More on CCM

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 13:36:14 -0600

CCM should have three variations, each with their own OID, each being a
trivial wrapper around an underlying GSS mechanism.  The three
variations should be:

 - CCM-with-network-address-channel-bindings

   For use with IPsec and without NAT.  Initiators and acceptors would
   be required to verify that an IPsec SA exists for the network
   addresses referenced in the channel bindings.

 - CCM-with-session-hash-channel-bindings

   For use with IPsec, SSHv2, etc.. without regard to NAT.

 - CCM-with-no-channel-bindings

   For debugging use; not to be used in production.

The reason that separate pseudo-mechanisms are needed for the network
address channel bindings and session hash channel bindings is so as to
make it possible to negotiate which one to use.

Cheers,

Nico
-- 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Mar 2003 14:18:03 -0800

> trivial wrapper around an underlying GSS mechanism. The three

These might be too many variations. Offering a wide array
of choices to the customer is just too confusing. And
even if we can design a way to remove confusion, requiring
all this array of choices reduces the chances of a particular
implementation supporting them and reduces chances of
interoperability. (An example of this is action was the
surprise at the last Connectathon, where several of us found that
3DES keys were being created by the KDC, and as a result,
most of us NFS/krb5 implementors couldn't interoperate).
The goal is to minimize difficulty of implementation.

> addresses referenced in the channel bindings.

Given the lack of  NAT support, I can't see why implementors with
limited resources would bother. I'm certainly not inclined to
lobby my management to fund this.

> For use with IPsec, SSHv2, etc.. without regard to NAT.

I think hash-key bindings are very slick. I also think the API
support to retrieve them is far from ubiquitous. And there's no
existing GSS-API or krb5 infrastructure for them either, and
not even a specification.

> make it possible to negotiate which one to use.

Following Dai Peng's and David Black's comments, and considering
that useful (NAT-less) GSS channel bindings don't really exist, my thinking
is to specify the use of RPCSEC_GSS over CCM to limit its use
for the duration of the ULP's session. Most ULPs that use ONC RPC don't
have a session, but most ONC RPC ULPs do work over
connection oriented transports. So this effectively means that
sessionless ONC RPC ULPs must bind a particular CCM context to
a particular TCP or SCTP (whenever the wg gets around to
defining ONC RPC semantics for SCTP) connection.

(If it is good enough for iSCSI, it is good enough for ONC RPC).

    -mre

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Mar 2003 17:20:17 -0600

> The goal is to minimize difficulty of implementation.

See below.

The 3DES issue you refer to is a configuration issue, perhaps a
maddening one to you, but still not an interop issue.

> lobby my management to fund this.

The reason I offer this is that this is trivial to implement today and
secure.  It won't work through NAT though.

> not even a specification.

The GSS-API certainly supports channel bindings, though they are
optional.  Your implementation may not, but if you want CCM to work
securely then you'll have to add channel binding support.

The specification of the IPsec, SSHv2, etc... hashes has to be done.
I already know what that specification is for IKEv1 (IPsec) and SSHv2;
only IKEv2 remains.  Specifying these hashes is not difficult.

I will contribute text if you wish.

Since CCM-with-session-hash-channel-bindings is the only secure form of
CCM that will work through NAT I think that this form has to be
specified.  Between this form and the first one above we have two forms
of CCM, and if I had to choose only one I'd choose this one.

> that useful (NAT-less) GSS channel bindings don't really exist, my thinking
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
They are trivial to define.  To repeat:

 - For IKEv1 (IPsec) the channel bindings consists of: the concatenation
   of the HASH_I and HASH_R for the SA as defined in IKEv1 (rfc2409)

 - For SSHv2 the channel bindings consists of: the key exchange hash as
   defined in draft-ietf-secsh-transport-15 and
   draft-ietf-secsh-gsskeyex-06

 - IKEv2 I've not researched yet; but surely it too can have channel
   bindings specified

> defining ONC RPC semantics for SCTP) connection.

ULP?

> (If it is good enough for iSCSI, it is good enough for ONC RPC).

Wrong.  If some other protocol's spec has it wrong that is no excuse for
us to get it wrong also, particularly now that we've had this discussion
in public (years from now others will be able to point the finger at us
and say "they knew of the problem and chose to ignore it").  I don't
find that acceptable.  Furthermore the IETF security ADs, or the IESG
may also find it unacceptable; if, OTOH, they're ok with this, then
fine, it won't be my fault :) :)

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Mar 2003 19:12:41 -0500

Why do you need or want either the CCM varient without channel
bindings or the network address channel bindings.

I am very uncomfortable standardizing the no channel bindings variant
because I think it may be used.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Mar 2003 09:53:44 -0600

Because it struck me that it could be a useful way to negotiate no
crypto for the purpose of debugging (packet sniffers have an easier time
with cleartext; yes, there are other ways).

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Mar 2003 10:59:33 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Because it struck me that it could be a useful way to
    Nicolas> negotiate no crypto for the purpose of debugging (packet
    Nicolas> sniffers have an easier time with cleartext; yes, there
    Nicolas> are other ways).

I think if you want to add this after the major implementers already
have CCM working that might be OK.  BUt I'm significantly concerned
that people would implement this and then tell their users to use it
rather than getting channel bindings working whenever they ran into
problems with channel bindings.