Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[David Noveck <[e-mail]>]

On Wed, Apr 1, 2020, 4:27 AM Magnus Westerlund <magnus.westerlund=
[e-mail]> wrote:

> NFSv4 WG,
>
>
>
> Sorry my AD review took longer time than it was supposed to. Anyway here
> are my comments. And as usual I am not an expert on NFS or RPC.
>

True but you noticed something important (re channel binding) that the
> members of the working group, more knowledgeable about RPC, did not notice.
>


So don’t hesitate to push back or educate me with relevant context if what
> I comment appears to be just strange.
>

We're used to AD'S sounding strange to us.
 Its clear you have issues with some of the strange things we say.

>
>
>
>
>
>
>  2. Section 3:
>
>
>
>    Note also that the NFS community uses the term "privacy" where other
>    Internet communities use "confidentiality".  In the current document
>    the two terms are synonymous.
>

But it doesn't say what this common meaning is :-(


>
> Can this usage of privacy be avoided.
>

Not totally. A lot of it is embedded in existing hard-to-update documents.


>
> 3. Section 4.1:
>
>
>
>   <CODE BEGINS>
>
> enum auth_flavor {
>            AUTH_NONE       = 0,
>            AUTH_SYS        = 1,
>            AUTH_SHORT      = 2,
>            AUTH_DH         = 3,
>            AUTH_KERB       = 4,
>            AUTH_RSA        = 5,
>            RPCSEC_GSS      = 6,
>            AUTH_TLS        = 7,
>
> /* and more to be defined */
>    };
>
> <CODE ENDS>
>
>
>
> In this particular case it might not be a major issue, but it is
> recommended that not put the numbers from the IANA registry into to the
> document until it has been assigned to the document. In cases where one
> need a number for testing during development, one can in many registries
> actually issue an early assignment.
>
>
>
> To me the right way of doing this table would have been to replace the 7
> on the AUTH_TLS line with a [IANA_TBA]. And add an RFC-editor note in this
> section, and the necessary IANA sub-section requesting assignment. And if
> an number would have been needed for the implementation an early assignment
> request could have been done,
>

This was needed but wasn't done then.

 then converted to a permanent one using the IANA section.
>

Not sure what our options are now, given the wide use of 7.


>
>
> 5. Section 4.2.1:
>
>
>
>    A TLS-capable RPC implementation uses
>    GSS channel binding to determine when GSS integrity or privacy is
>    unnecessary.  See Section 2.5 of [RFC7861] for details.
>
>
>
>    RFC 7861 Section 2.5 says:
>
>
>
>    2.5.  RPCSEC_GSS_BIND_CHANNEL Operation
>
>
>
>    RPCSEC_GSSv3 provides a channel-binding assertion that replaces the
>
>    RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation.
>
>
>
>    The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS
>
>    version 3 handles.  If a server receives an RPCSEC_GSS_BIND_CHANNEL
>
>    operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of
>
>    MSG_ACCEPTED with an accept_stat of PROC_UNAVAIL [RFC5531].
>
>
>
> I don't see how the details in 2.5 provides an answer to how each peer can
> determine that TLS Is present by using the GSS channel binding.
>

I don't either.
>

Maybe this is understandable by someone that understands GSS in detail.
>

And maybe not.


>
>  Howeverr, I think some more details are needed.
>

The alternative, which I do not recommend, is to update the sentence to say
"See Section 2.5 of [RFC7861] to be totally mystified" :-)

I think the place to start in addressing this is to consider what existing
implementations do about this issue.


>
> 13. Requirement on implementation
>
>
>
> Should this document actually update any or all of the versions of NFS 4
> to mandate implementation support?
>

No.  I think we are trying to move in a direction in which there are fewer,
ideally one, document to look at to tell you what you have to do to
implement a minor version.  This document defines an RPC-level facility and
should not reach up the stack in that way.

Fromm the WG's perspective doesn't it make sense to start demand
> implementation support.
>

We don't want to "demand" things and be ignored.  I think we can, without
demanding it, encourage it's use.

The mechanism is clearly opportunistic in its establishment, however the
> goal here needs to be to get support in as many places is as possible.
>

Yes.

Thus, sending a clearer signal that NFS 4.x servers and client are expected
> to support this should be sent.
>

I think we can figure out how to send a clearer signal.


If not can you clarify what the concerns are? Because we are going to get
> this question again in the IESG evaluation.
>
>
>
> To me the reasonable plan towards always used transport security
> (something I expect the full updates, for example of NFS v4.1 to require)
> is to require implementation but not usage now. Then next step to require
> its usage.
>

Maybe I'm getting upper and lower case mixed up but I don't see that you
can reasonably update the specification of a particular minor version, in a
way that defines a significant number of existing implementations as
non-compliant post facto.

Adding  a new recommendation is different. Saying this "SHOULD" be
implemented makes sense, as defined by RFC2119.  (Often "SHOULD" is used as
a "MUST" without a whole lot of conviction. Sigh!).  In this context, the
time to implement, test, and deploy support are valid reasons it might not
be implemented but the text will need to explain clearly the unfortunate
consequences for security.

Regarding staging, we need to treat encryption and client authentication
separately.  For encryption, If the client and server implement this, it
will be used.  There is no need for two stages.  With regard to client
authentication, not sure what we will do, given the issues about
fingerprinting recently discussed on the list.  If those are satisfactorily
addressed before draft-ietf-nfsv4-security is ready, it might make sense to
recommend implementation by client and server, especially where use of
AUTH_SYS is anticipated.  If they aren't, we might see if a phased approach
makes sense.

We will discuss this on 4/22 as part of the rfc5661bis effort.

>
>
>
>
> Cheers
>
>
>
> Magnus Westerlund
>
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>