Subject: Re: [nfsv4] Comments on CCM draft

From: Mike Eisler <[email-masked]>
Date: Sun, 18 May 2003 12:33:39 -0700 (PDT)

> From: Sam Hartman <[email-masked]>

> I believe that CCM must require implementation of channel bindings for
> any transport for which it is used.  I wish we were in a situation
> where we could require the use of channel bindings, but we are not.

Sam,

In CCM -02 that I submitted to the i-d editor today,
key-based channel bindings are REQUIRED.

As for NFSv4.1, the minor revisioning guidelines for
NFSv4 state that we can't introduce a new features as
REQUIRED. We'd have to wait until NFSv4.2 to do so.

As a wg we can revisit that, but I hope we don't. It is too
risky to mandate features that aren't battle tested.

> [arguments for channel bindings deleted]

> Is that consistent with your understanding of my position?

Yes.

> So how do we move along from here?

I think we should proceed with making CCM a RECOMMENDED feature
of NFSv4.1. I propose that the NULL, and KEY-based bindings
be RECOMMENDED for v4.1.

As for v4.2, when we have a chance to promote CCM KEY-based bindings
from RECOMMENDED to REQUIRED in NFSv4, I don't know, but my opinion
will depend on the availability of APIs to access IPsec channel
bindings across multiple platforms.

> Well, regardless of the channel bindings issue, I believe that CCM
> could use significantly more review from the GSSAPI community and
> possibly from the larger security community.  I propose that we seek
> that review and as part of the review we ask people to look at the
> channel bindings issue.  Clearly input will have to be carefully
> considered.  If we get a bunch of security folks who claim that we
> protocol should be maximally secure without considering the issues and
> tradeoffs that is not very useful.  However if we get people to read
> the document, consider the implementation details and come up with an
> informed opinion about the channel bindings issues, that should be
> useful in determining WG consensus?

> Does this seem like a reasonable way to move forward?

Sure. I suggest after the Ann Arbor meeting, and after
-02 of the document is ready, that we notify all such 
interested parties.

I don't know if it is going to change wg consensus as
to whether key-based bindings should be a MUST in NFSv4.1.

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

---

From: David Robinson <[email-masked]>
Date: Mon, 19 May 2003 02:46:52 -0500

> REQUIRED. We'd have to wait until NFSv4.2 to do so.

I am not an expert on minor versioning rules (some
I really don't like), but we should be clear to
distinguish between a feature being REQUIRED,
not possible in a minor release, and when
someone chooses to use the optional feature,
what components are REQUIRED.

We can't make CCM REQUIRED, but can't
we make channel bindings REQUIRED *if* CCM is used?

	-David

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 May 2003 08:33:51 -0700

> we make channel bindings REQUIRED *if* CCM is used?

No, we can't, because users should be allowed to consciously choose to
have GSS-API authentication but no cryptographic protection of sessions
in environments where that makes sense.  Perhaps you meant mandating
that apps that support the use of CCM also support the use of CCM-KEY.

We're mandating that CCM implementations MUST support CCM-KEY (w/ key
bindings); of course, that's not a burden on implementors since each
variant of CCM-BIND is as trivial to implement as the others.

So we're left to decide whether applications that use CCM "MUST" support
the use of CCM with true (or "key") bindings.  I'm not sure that we can
reasonably make such a demand in the CCM draft, but what is clear is
that we cannot mandate CCM support in NFSv4.1 - we could make CCM
support in NFSv4.1 *optional* but with CCM-KEY support being required of
those implementations that support CCM at all (a position which I would
support, but see below).

The compromise that Mike and I have reached is that the CCM draft won't
mandate that applications that use it also support the use of CCM-KEY,
and that NFSv4.1 and NFSv4.2 requirements wrt CCM will be hashed out
separately, thus deferring the actual argument.

IIUC Mike thinks we need to see that implementing application use of
CCM-KEY is not particularly difficult.  How many OSs provide an API for
retrieval of the IKEv1 HASH_I and HASH_R values of the IPsec SA that
protects some connected TCP (or UDP) socket?  I don't believe that
Solaris does, for example - but I do believe that implementing such APIs
is not (or should not be) so difficult for OS vendors.  The unavailability
of such APIs, is not a sticking point for me - but I think it's
reasonable for Mike to be bothered by it.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 May 2003 10:00:41 -0400

I completely understand the desire to avoid adding new must-implement
features to NFS 4.1.  I have no objections to your proposal and think
this will be an excellent compromise.

I look forward to reading the revised draft.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4