Subject: Re: [nfsv4] Comments on CCM draft

From: Mike Eisler <[email-masked]>
Date: Mon, 19 May 2003 09:26:39 -0700 (PDT)

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

> No, we can't, because users should be allowed to consciously choose to
> have GSS-API authentication but no cryptographic protection of sessions

I think David meant implementation support versus use.

The NFS philosophy, perhaps as an unintended outcome of crappy
AUTH_SYS, is that users (sys admins) are permitted to select
their poison.

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

Put another way, the way CCM is now packaged, it is a suite of
four mechanisms. I can't think of the right weasal words in an NFSv4.x
spec that that would say, if you support CCM-NULL, you MUST also
support CCM-KEY and still stay with the letter or spirit of the
minor versioning rules.

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

Looks like the argument has started. :-)

> 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

I think it is easy, iff party that controls the IP stack is the
same one that controls the NFS stack. I'm not worried about
EMC, IBM, NetApp, Sun, etc. supporting this stuff in their
proprietary kernels.

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

I think a step toward resolving the availability question is
a proposal for API extensions to the socket layer, the OpenSSL library,
and the moral equivalent in OpenSSH.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 May 2003 09:46:12 -0700

> support CCM-KEY and still stay with the letter or spirit of the

*shrug* It seems doable.

> Looks like the argument has started. :-)

Well, we've been having this argument all along.

The compromise you and I are trying to sell here is that the argument
should not be had in the context of the CCM draft but in the context of
any draft(s) that discuss/describe/recommend/mandate/... CCM use by
NFSv4.x.

> EMC, IBM, NetApp, Sun, etc. supporting this stuff in their

Yes.  Other implementors will either have to bother their OS vendors or
they will have to hack their way through.  I don't think we should lock
them out, nor do I think that requiring support for use of CCM-KEY
would.

> and the moral equivalent in OpenSSH.

Yes, but do you suppose that such API design work should be done in some
open forum?  That might slow down adoption of CCM-KEY.

Cheers,

Nico
--