Subject: [nfsv4] review of draft-dnoveck-nfsv4-security-03

From: Chuck Lever III <[email-masked]>
Date: Wed, 24 Nov 2021 17:21:45 +0000

General comments:

Editorial bugaboo: the overuse of commas in this document, especially where a speaker might pause for emphasis but the comma does not serve a proper grammatical purpose. The RFC Editor will be merciless in removing these.

Example:

   This document describes the security features of the NFSv4 protocol
   and is unable to address security threats that are, inherently
   outside the control of the protocol implementors.

Or:

   [Author Aside]: Giving servers a general freedom to to not support
   the masks defined in this section, creates an unacceptable level of
   potential interoperability problems.

Document organization: The increasing size and scope of this document is concerning. In general I prefer to see nfsv4-security focus on security architecture and threat analysis, and leave protocol details to other documents. A good guideline might be: if you don't normally see this type of text in a Security Considerations section, then it doesn't belong in this document.

For example, Section 5 is indeed security related, but it specifies protocol elements, thus IMO it should remain in 5661bis.  Or put another way: the protocol elements that define ACLs are an implementation of the security architecture. The protocol implementation details belong in 5661bis, while the architecture can be described in this document. It is perfectly acceptable for 5661bis to cite this document as explaining the security considerations for ACLs.

As an alternative, a complete discussion of access control is substantial and perhaps should be a separate document.

I also propose that Sections 13 through 15 be moved to a separate document. I explain the reasons below.

Section 6:

There might be more going on within a server filesystem's authorization decisions than the NFS service can present to NFS clients. MAC security labels, file capabilities, and per-file data integrity checking policies are typically not visible via client access, yet can block access to file content. Is Section 6 stating that NFS servers MUST NOT use other authorization methods except those that are visible to clients via the NFS protocol?

Sections 7 and 8:

These sections should discuss the authorization models in terms of discretionary (ie, user-directed) and mandatory (ie, system-controlled) authorization models, as is the industry norm.

I would like to see an expansion of the discussion of the "superuser" concept, as that is a POSIX holdover concept and needs detailed coverage as part of, for example, user identity squashing. This level of privilege is also key to discussing MAC security, or remotely setting other privileged attributes on files and directories. And POSIX-like clients need guidance on how to emulate superuser privileges via the facilities provided within NFS.

Section 9:

   The current NFSv4.0 and NFSv4.1 descriptions of this share one
   unfortunate characteristic in that they both are written to give
   server implementations a broad latitude in implementation choices
   while neglecting entirely the need for the clients and users to have
   a reliable description of what servers are to do in this area.

   As a result, one of the goals of this new combined treatment will be
   to limit this excessive freedom, while taking proper account of the
   possibility of compatibility issues that a more tightly drawn
   specification might give rise to.

I don't see any rationale given explaining why the existing "broad latitude" is inadequate. What real world problems have arisen from it? What are the consequences of not coordinating updates to mode bits and ACLs? Why is it necessary that all NFS servers and filesystems do this the same way? These two paragraphs make a lot of assumptions which need to be explicitly included here.

It's been emphasized to me over the years that over-specifying will either limit innovation or prompt implementers to ignore the specification. There needs to be clear justification for making significant constrictions in this area.

As above, it could be impossible to crisply describe ACL-to-mode translation in the face of other, non-standard authorization mechanisms that might restrict server security policy. I prefer that this section retain the "broad latitude" approach and instead work to make clients operate properly in the face of client-invisible authorization mechanisms on the server (a la ACCESS). But I agree that the use of BCP14 keywords could be improved in this area, especially with regard to explaining in the context of SHOULD when alternative approaches are appropriate.

Is there a treatment in the POSIX standard or within Microsoft Windows protocols publications of ACL-to-mode translation? Would any of that be helpful to review or adopt?

I missed the introduction and definition of the terms "forward-slope" and "reverse-slope".

The discussion in this section needs to avoid using lowercase "must" and "should" as these are easily confused with BCP14 terms.

Generally speaking, it's not clear to me that "cleaning up the ACL specification" is part of the original scope for nfsv4-security, which was to provide a Security Considerations section and threat analysis for NFSv4.x. As it is a substantial piece of work, perhaps it needs its own charter mandate.

Section 13.1:

I don't understand the motivation for replacing the historical term "RPC authentication flavor". Also, the term "RPC flavor" is generic enough to unhelpfully obscure its meaning and purpose. I don't currently have an alternative term, but subsequent discussion in this section is able to successfully distinguish between identification and authentication and state plainly which authentication flavors provide one, both, or neither. I don't see a problem with keeping the traditional terminology.

Section 13.4:

I find the linking of "connection type" with "RPC flavor" to be deeply problematic and without precedent. First, and I cannot stress this enough, TLS IS NOT A CONNECTION TYPE. For example, QUIC, which is a connection type, uses TLS just like TCP does, though with QUIC TLS happens to always be enabled.

We will be better served if the RPC layer simply tells the upper layer: yes I can authenticate the peer (eg: GSS or transport layer security is in use), or no I can't; yes I can provide confidentiality (eg: GSS, IPsec, or TLS is in use), or no I can't.

This section needs analysis of specific use cases and explicit rationale for why negotiating connection types is necessary. Since this is a proposed new feature, that analysis and rationale is paramount.

Burying this proposal in a large document with a broad scope will prevent adequate discussion IMO. I prefer to see these three sections split into their own document that can proceed to publication as soon as possible rather than being chained to the completion of the other potentially lengthier tasks in nfsv4-security.

Section 14:

Since authentication and confidentiality are handled by RPC, why is this section necessary to include in a document about NFS? The NFS layer should simply ask for a particular security service; the RPC layer then provides that service -- the actual mechanism can and should be opaque to NFS.

Yes, the introduction of transport layer security is as revelatory as suggested. But I think this document is too specific about how it works in the one instance we have today (RPC-with-TLS). NFS should request abstract security services -- that's exactly what it does for GSS -- and the RPC layer should provide those without exposing mechanism.

Section 15:

I strongly urge reconsideration of adding connection types to security negotiation. NFS should state the security services that are required, and let the local RPC implementation figure out the mechanisms.

  *   SECINFO and SECINFO_NO_NAME both return arrays of pseudoflavors. I don't see a provision in RFC 8178 to permit changing these procedures to exchange something that is not defined in the RPC protocol documents and number registries as a pseudoflavor.
  *   Especially XPT_TCP does not make sense; as stated above, QUIC has TLS built in. Do we really want to add a new connection type pseudoflavor for every new RPC transport?
  *   The discussion in this section is necessarily NFS-centric, but a complete discussion of security for all RPC transport types would need to include datagram transports. Such a discussion needs to start at the RPC layer, not as something grafted onto an upper layer protocol.

Section 15.4 and 15.4.1 belong in section 15.5. And again, because this subsection is specifying protocol elements, it does not belong in an architectural document, but instead should be either a separate smaller document that will be replaced eventually by rfc5661bis, or this material should appear in rfc5661bis's SECINFO and SECINFO_NO_NAME implementation guidance subsections.

Section 15.4.2 and .3 -- may be incomplete, but I fail to see the purpose of including these details.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 26 Nov 2021 10:43:47 -0500

Before we get to the details, I'd like to thank you for your comments and
indicate how they will be addressed:
- Many of these can easily be addressed in -04, which I expect to be out by
the end of the year.
- In other cases, I hope I can address your concerns but am not sure I can
do so.  To deal with those cases, I will provide you a pre-draft in the
next few weeks with text that I hope will address your issues so that we
can discuss and work on the text to make sure that -04 is not a problem for
you.

There are a set of comments that I am unable to respond to positively and I
like to explain why that is.  I am speaking of comments that propose major
changes in the content or function of this document or propose a major
reorganization of it.  While I explain the specifics in the responses
below, I hope it will be helpful for me to explain my own view of the
appropriate goals and content for a later draft-ietf-nfsv4-security and
eventual RFC.

This document is, for me, a part of the rfc5661bis effort.  The original
motivation for doing it as a separate document was the desire to make the
individual documents within the rfc5661bis document suite smaller and more
manageable.  The special role of the security document as an NFSv4-wide
document derives from the fact that, like internationalization, it is the
same for all minor versions.

At no point did I ever intend that this document had a special status as an
architectural document, even though it will, of necessity, discuss the
architecture, just as other parts of the rfc5661bis document suite will
do.  While the lack of an adequate Security Considerations section was an
important issue that needed to be addressed, it was never intended that the
document be limited to doing those things.

On Wed, Nov 24, 2021 at 12:22 PM Chuck Lever III <[email-masked]>
wrote:

> *General comments:*
>
> Editorial bugaboo: the overuse of commas in this document, especially
> where a speaker might pause for emphasis but the comma does not serve a
> proper grammatical purpose. The RFC Editor will be merciless in removing
> these.
>
> Example:
>

Good point.  Will fix these in -04.

>
>
> Document organization: The increasing size and scope of this document is
> concerning.
>

I don't have the same concern at this point.   If it gets past 150 pages, I
will look at a split-up.

> In general I prefer to see nfsv4-security focus on security architecture
> and threat analysis, and leave protocol details to other documents. A good
> guideline might be: if you don't normally see this type of text in a
> Security Considerations section, then it doesn't belong in this document.
>

That wasn't my approach.   I looked to include things that were:

   1. security-related
   2. common to both RFCs 7530 and 8881.

The goal was to avoid writing the same stuff twice, when, as with
internationalization, the same approach was used in two different NFSv4
protocols.

> For example, Section 5 is indeed security related, but it specifies
> protocol elements, thus IMO it should remain in 5661bis.
>

Not in my opinion.   Also, I don't see how one could write a threat
analysis without referring to the specific protocol elements that an
attacker might exploit..

> Or put another way: the protocol elements that define ACLs are an
> implementation of the security architecture.
>

If we took that approach, we would be deriving  the "architecture"  from
the implementation.   Distinguishing these two has a practical purpose if
it allows multiple implementations of a single architecture.    In the
current case we have a single
set of protocol elements shared by two protocols and I don't see that
dividing these into architecture and implementation really makes sense.
Also, I don't see how one could write a threat analysis of a protocol
architecture without protocol elements.

> The protocol implementation details belong in 5661bis, while the
> architecture can be described in this document.
>

I don't think so.

> It is perfectly acceptable for 5661bis to cite this document as explaining
> the security considerations for ACLs.
>
>
Formally, it could.  However, it is better to put these two closely related
elements in the same document so that they could be reviewed, published and
read together.

As an alternative, a complete discussion of access control is substantial
> and perhaps should be a separate document.
>

I would consider that if the document gets much bigger. As it is, I would
prefer to avoid the extra work and complexity for the reader.

> document. I explain the reasons below.

Will address below.

>
> *Section 6:*
>
> There might be more going on within a server filesystem's authorization
> decisions than the NFS service can present to NFS clients. MAC security
> labels, file capabilities, and per-file data integrity checking policies
> are typically not visible via client access, yet can block access to file
> content
>

I agree with that.

> . Is Section 6 stating that NFS servers MUST NOT use other authorization
> methods except those that are visible to clients via the NFS protocol?
>

*No!  *It does say that NFS servers MUST NOT allow access where the NFS
protocol would deny it.  In a number of instances, the previous text listed
those cases (which raise important security issues) together with the
complementary cases that you are concerned about (which really don't).
If that is not made sufficiently clear, we can address the issue as part of
the discussion of Consensus Item #22.

>
> *Sections 7 and 8:*
>
> These sections should discuss the authorization models in terms of
> discretionary (ie, user-directed) and mandatory (ie, system-controlled)
> authorization models, as is the industry norm.
>

OK.  Will address in -04.

>
> I would like to see an expansion of the discussion of the "superuser"
> concept, as that is a POSIX holdover concept and needs detailed coverage as
> part of, for example, user identity squashing.
>

I'm not sure what you are asking for.  Plese suggest what you would like to
see.

> This level of privilege is also key to discussing MAC security,
>

I don't see how.  Please elaborate.

> or remotely setting other privileged attributes on files and directories.
>

We currently don't have any definitions of "privileged attributes".
 Perhaps we should.   I'm open to suggestions.

> And POSIX-like clients need guidance on how to emulate superuser
> privileges via the facilities provided within NFS.
>

I'm not sure  what such guidance would consist of.  Do you have suggestions?

I think I need to clarify how this document proposes to deal with superuser
credentials, also part of Consensus Item #22.

The acceptance of superuser credentials for NFS mounts makes it possible
for a privilege elevation on a client machine to be converted into a vastly
more troubling privilege escalation on a server used by many users. If this
were retained as part of the NFSv4 protocol, a threat analysis would have
to point to this as a major threat, and conclude, however one wants to put
it, that it renders NFSv4 insecure.  The spec recommends that this not be
allowed, although we might well expect this recommendation to be ignored.
 What is called "root squashing" is mentioned as a possible way of doing
that, although that specific phrase is not used.

> *Section 9:*
> I don't see any rationale given explaining why the existing "broad
> latitude" is inadequate.
>

Basically because it doesn't perform the function of a
standards-track document , of telling the server what to do, in terms of
behavior that the client can see.   This tells the client what he can
expect when he does certain things, and, by implication, how to get done
what he wants to have done.  I will try to clarify this in the pre-draft
and -04

What real world problems have arisen from it?

It depends what you mean by "real-world" problems.   I haven't heard any
complaints about the issue but I assume that is because, many people don;t
read the spec or only read the part they agree with ignoring the
contradictory text in another section.   It also might be that because of
the fact that  because of limited client-side implementations
interoperability expectations were low, as I indicated in my slides
presented at the meeting.

Given that background, iit might be that, depending on one's definition
of  "real-world problems"there might be none but I didn'y approach the
matter in that way.   As with erratta reports, there is no requirement that
one make sure that an error/gap actually result in an actual problem or
that a lack of a meaningful interoperability be perceived as a problem by
users.   I took the approach that if I couldbn't figure out what the spec
expected servers to do that was a problem that needed to be addressed.
All of the instances of this are listed as Consensus item and we can
discuss the specfic issues in that context.

> What are the consequences of not coordinating updates to mode bits and
> ACLs?
>

> Why is it necessary that all NFS servers and filesystems do this the same
> way?
>

It depends what you mean by "the same way"   NfFSv4 servers and file
systems do READs in different ways, but the client can expect the same
behavior so that different server and clients can interoperate successfully.

For internationalization we allow multiple ways but list them so clients
are not blindsided.

These two paragraphs make a lot of assumptions which need to be explicitly
> included here.

OK. Will try to explain more clearly in the predraft and -04.

>
> It's been emphasized to me over the years that over-specifying will either
> limit innovation or prompt implementers to ignore the specification.
>

I don't think I am overspecifying.   I tell people what is to be done but
don't tell them how to do it.

> There needs to be clear justification for making significant constrictions
> in this area.
>

I'll try to provide that in the predraft and -04.

> As above, it could be impossible to crisply describe ACL-to-mode
> translation in the face of other, non-standard authorization mechanisms
> that might restrict server security policy.
>

Could you give me an example of the difficulty you see? I see these issues
as orthogonal.

> I prefer that this section retain the "broad latitude" approach and
> instead work to make clients operate properly in the face of
> client-invisible authorization mechanisms on the server (a la ACCESS).
>

ACCESS tells you the result of the authorization decision.   That;s a
good thing but it doesn't dispose of the problem.  Clients and users need
the converse:  Given the policy they want from file authorization, they
need to know how to construct the attributes (modes and/or ACLs) to effect
it.

But I agree that the use of BCP14 keywords could be improved in this area,
> especially with regard to explaining in the context of SHOULD when
> alternative approaches are appropriate.
>
> There are consensus Items associated with those that the working group
can  discuss.

> Is there a treatment in the POSIX standard or within Microsoft Windows
> protocols publications of ACL-to-mode translation?
>

I don't know.

> Would any of that be helpful to review or adopt?
>

Could be.

> I missed the introduction and definition of the terms "forward-slope" and

It's in section 7.3.1.  The Associated Consensus Item is #21.

>
> The discussion in this section needs to avoid using lowercase "must" and
> "should" as these are easily confused with BCP14 terms.
>

Will address in -04.  Thanks for point this out.   This could be annoying
when dealing with the IESG.

> Generally speaking, it's not clear to me that "cleaning up the ACL
> specification" is part of the original scope for nfsv4-security, which was
> to provide a Security Considerations section and threat analysis for
> NFSv4.x.
>

I don't see things that way.  This is part of the rfc5661 bis effort and,
as part of that effort, one needs to clean up stuff that does not clearly
define expected protocol behavior.

Furthermore, it is not possible to write a threat analysis, for a protocol
with security- related features, whose specification is unclear.

> As it is a substantial piece of work, perhaps it needs its own charter
> mandate.
>

I don't think so.  As part of the rfc5661bis effort, it fits under
maintenance, just as internaiona;ization is.

>
> *Section 13.1:*
>
> I don't understand the motivation for replacing the historical term "RPC
> authentication flavor".
>

It is because most of the "RPC 'authentication' flavors" don't do
authentication.

> Also, the term "RPC flavor" is generic enough to unhelpfully obscure its
> meaning and purpose.
>

:-(

I don't currently have an alternative term,

I'll look for one and address in -04.

> but subsequent discussion in this section is able to successfully
> distinguish between identification and authentication and state plainly
> which authentication flavors provide one, both, or neither.
>

Right but I'm afraid the repetition of  "authentication flavor"  would
undercut that.   "RPC 'authentication' flavor" is kind of ugly.  Sigh!  I
think I will introduce the term "RPC auth-flavor", explain why
"authentication flavor" is inaccurate, and proceed from there.

I don't see a problem with keeping the traditional terminology.

I still feel it would contribute to confusion.

>
> *Section 13.4:*
>
> I find the linking of "connection type" with "RPC flavor" to be deeply
> problematic
>

I don't understand why.

The sentence in question says;

   Depending on the connection type used, RPC may provide additional
   means of authentication.  In contrast with the case of RPC flavors,
   any authentication happens once, at connection establishment, rather
   than on each RPC request.  As a result, it is the client and server
   peers, rather than individual users that are authenticated

Could you explain what is problematic about that?

> and without precedent.

 Perhaps so but, given the innovation that you and trond have provided,
there will be many occasions to say things that were not said before.  *stare
decisus *does not apply here.

> First, and I cannot stress this enough, TLS IS NOT A CONNECTION TYPE.
>

You have already made that point and I believe it is addressed in -03,
although it is possible there were some editing slip-ups.

If you know of any, please point that out.

> For example, QUIC, which *is* a connection type, uses TLS just like TCP
> does, though with QUIC TLS happens to always be enabled.
>

that is true but, given that there is no RPC-over-QUIC spec (even an
individuaI-D), there are limits in what I can say about that in an I-D that
is intended to morph into a standards-track RFC.

>
> We will be better served if the RPC layer simply tells the upper layer:
> yes I can authenticate the peer (eg: GSS or transport layer security is in
> use), or no I can't; yes I can provide confidentiality (eg: GSS, IPsec, or
> TLS is in use), or no I can't.
>

We might be better off but that would have required an  RPC
connection-flavor abstraction paralleling the RPC auth-flavor abstraction.
 We don't have that and the benefits of doing so, while real, do not
justify  the substantial work do so now.

As far as confidentiality goes, there have to be three choices, rather than
two:

   1. Yes you get this automatically for the connection (RPC-with-TLS and
   eventually QUIC)  --> use this if you can.
   2. You can get this, if you ask for it on a per request basis. (GSS when
   connection-based encryption is not available) --> Needed if 1. not available
   3. No you can't get this (e.g. AUTH_SYS in the clear) --> run away as
   fast as you can

This section needs analysis of specific use cases and explicit rationale
> for why negotiating connection types is necessary.
>

I'll provide that in the predraft and -04.

> Since this is a proposed new feature, that analysis and rationale is
> paramount.
>

It is not a new feature.  It is the adaptation of an existing feature to be
useful in the new environment in which the RPC auth-flavor is no longer the
sole determinant of security services, but the role of the connection
characteristics is of equal or greater importance.

> Burying this proposal in a large document with a broad scope will prevent
> adequate discussion IMO.
>

We are having a discussion of this now.  I hope it is productive.  If it is
inadequate, I don't see how putting it in a separate document would remedy
that.

I prefer to see these three sections split into their own document that can
> proceed to publication as soon as possible rather than being chained to the
> completion of the other potentially lengthier tasks in nfsv4-security.
>

I presume that you are referring here to sections 13-15.   Regarding these;

   - Sections 13 and 14, which deal respectively with authentication and
   the security of data  in flight are an integral part of the security
   provided by  NFSv4.  They have a  critical role in the new security
   architecture intended to take proper advantage of the work you and trond
   did in RPC-with-TLS.   I don't understand the motivation for putting these
   three pages anywhere other than draft-dnoveck-nfsv4-security or its
   successor documents.
   - Section 15 is made necessary is made necessary by the changes in
   sections 13 and 14 so might make sense to deal with all these together,
   except for the following considerations:
      - these sections are a total of eleven pages.
      - While 13 and 14 are tightly bound to 15, they are also
      tightly bound to the rest of the spec, making any proposed surgery
      difficult.
      -  With regard to the suggestion that this will somehow accelerate
      adoption I am inclined to be skeptical.   this is not only
because you seem
      to to feel theses changes not worth doing but also because you find some
      matters now in section 13 to be deeply problematic.

I don't see what is wrong with keeping these eleven pages with the rest of
the security document.

>
> *Section 14:*
>
> Since authentication and confidentiality are handled by RPC, why is this
> section necessary to include in a document about NFS?
>

It is necessary to make the point that these services are now provided by
RPC in two different ways, rather than solely using the auth-flavor, as
previous documents said.

The NFS layer should simply ask for a particular security service; the RPC
> layer then provides that service -- the actual mechanism can and should be
> opaque to NFS.
>

I don't see how it can be opaque to the NFSv4 implementation.

>
> Yes, the introduction of transport layer security is as revelatory as
> suggested. But I think this document is too specific about how it works in
> the one instance we have today (RPC-with-TLS). NFS should request abstract
> security services -- that's exactly what it does for GSS -- and the RPC
> layer should provide those without exposing mechanism.
>

It does not expose all that much mechanism.  All of that is, quite
properly, in RPC-with-TLS.   All it does is point out that these services
are provided by that RPC-layer document.

> *Section 15:*
>
> I strongly urge reconsideration of adding connection types to security
> negotiation. NFS should state the security services that are required, and
> let the local RPC implementation figure out the mechanisms.
>

It needs to be noted that SECINFO's job is to allow the NFS server to tell
the client what services to request. It could have been designed around
abstract services, but it was designed around auth-flavors, which made
sense then.   The problem is that, given the more limited role of
auth-flavors, some chane is needed.

With regard to a possible reconsideration of the inclusion of this
material, it is unclear whether you are asking for:

   1. To leave secinfo as it was without addressing connections at all.   I
   don't think this is viable but the working group is free to consider it.
    I would hope that it does so soon.
   2. To eliminate transport types while retaining negotiation.   This
   might be possible and i intend to explore the option in the predraft.

>    - SECINFO and SECINFO_NO_NAME both return arrays of pseudoflavors. I
>    don't see a provision in RFC 8178 to permit changing these procedures to
>    exchange something that is not defined in the RPC protocol documents and
>    number registries as a pseudoflavor.
>
> There is text in the IANA section adding these to the registries.

>
>    - Especially XPT_TCP does not make sense; as stated above, QUIC has
>    TLS built in.
>
>  TCP leaves these as an option while RDMA currently does not but could be
extended to provide this if we can find someone to do the work.   QUIC,
when it is made an RPC transport, will have these automatically.

These three sharply different cases are what led to the description in 03.
 However, as noted above, I  intend to explore the option of removing
connection types per se and focus instead on connection characteristics.
 Stay tuned.

>
>    - Do we really want to add a new connection type pseudoflavor for
>    every new RPC transport?
>
>
I don't see a problem with that given that we only have two, and are
thinking about a third.   It is not as if we have dozens of connection
types or ever expect to.

>
>    - The discussion in this section is necessarily NFS-centric,
>
> Yes.

but a complete discussion of security for all RPC transport types would
need to include datagram transports. Such a discussion needs to start at
the RPC layer, not as something grafted onto an upper layer protocol.

All we would need is a volunteer/victim to do this work.   Given your
experience waiting for DTLS  specs for RPC-with-TLS, I expect getting a
volunteer would be difficult.

>
> Section 15.4 and 15.4.1 belong in section 15.5. And again, because this
> subsection is specifying protocol elements, it does not belong in an
> architectural document, but instead should be either a separate smaller
> document that will be replaced eventually by rfc5661bis,
>

I don't see the point of a separate, temporary document.

or this material should appear in rfc5661bis's SECINFO and SECINFO_NO_NAME
> implementation guidance subsections.
>

Since the same changes would be made for v4.0, this would mean making the
same changes twice and adding rfc7530 to our agenda. I'm not up for that
and I wouldn't expect the working to want to do that either.

> of including these details.

I hope this is clearer in the predraft and -04.

>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 29 Nov 2021 16:35:12 +0000

My immediate concerns are with the discussion of security flavors / connection types, so permit me to redact the other parts of this thread in the interest of clarity, and address your responses only in that area, with one quick detour into the ACL part of the thread.

On Nov 26, 2021, at 10:43 AM, David Noveck <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 24, 2021 at 12:22 PM Chuck Lever III <[email-masked]<mailto:[email-masked]>> wrote:

As above, it could be impossible to crisply describe ACL-to-mode translation in the face of other, non-standard authorization mechanisms that might restrict server security policy.

Could you give me an example of the difficulty you see? I see these issues as orthogonal.

How do you propose to deal with a situation where a server uses multiple MAC labels (SMACK64, for example) or file capabilities ? https://linux.die.net/man/7/capabilities (and note that other OSes have their own flavors of capabilities).

There is a class of servers (eg OnTAP) that enable only remote access to files, and have only one physical file system implementation. The security document seems designed to address that case.

There is a class of servers (eg Linux, Solaris) that enable remote and local access to files, and have multiple independently-implemented file system types. Not all shares on such servers are guaranteed to implement the same set of access controls. Here, local users (or the server administrator) can set up additional access controls like capabilities, which are not visible to users on clients, and are not reflected in either the ACL or in the mode bits. Are you proposing that the nfsv4 WG mandate how these file systems update mode bits when those other access control mechanisms are put into place?

Some access control mechanisms, such as Linux IMA, are policy-based rather than controlled by settings on individual files. The policy is specified by the administrator in control of the file system where files are stored (ie, the server's file systems). IMO the text at least needs to recognize the presence of overriding security policy that is not modifiable from NFS clients.

What I meant was: perhaps these terms could be added to the document's forward glossary. I did browse the text looking for these, and still missed their definitions.

As it is a substantial piece of work, perhaps it needs its own charter mandate.

I don't think so.  As part of the rfc5661bis effort, it fits under maintenance, just as internaiona;ization is.

I don't recall a discussion of rewriting the ACL sections from the ground up when the WG was considering the scope of the rfc5661bis effort. Also, as you have carefully identified areas where a consensus discussion is needed, let me tactfully point out that we are possibly veering outside the realm of simple maintenance. AFAIK there have been no errata filed against the ACL section of RFC 5661.

Mainly I want to keep this effort contained and feasible, as I'm sure you do also. As I stated in the introduction to my review, I'm concerned that the scope of the rfc5661bis effort is continuing to broaden without any WG discussion regarding whether that's a desirable thing to do given currently available resources.

Section 13.1:

I don't understand the motivation for replacing the historical term "RPC authentication flavor".

It is because most of the "RPC 'authentication' flavors" don't do authentication.

Also, the term "RPC flavor" is generic enough to unhelpfully obscure its meaning and purpose.

:-(

but subsequent discussion in this section is able to successfully distinguish between identification and authentication and state plainly which authentication flavors provide one, both, or neither.

Right but I'm afraid the repetition of  "authentication flavor"  would undercut that.   "RPC 'authentication' flavor" is kind of ugly.  Sigh!  I think I will introduce the term "RPC auth-flavor", explain why "authentication flavor" is inaccurate, and proceed from there.

"RPC auth flavor" seems like a fine abbreviation with plenty of precedent.

Section 13.4:

I find the linking of "connection type" with "RPC flavor" to be deeply problematic

I don't understand why.

We already have RPC auth flavors that provide mutual peer authentication.

We already have a mechanism by which the NFS server can request particular security services such as mutual peer authentication.

We already have a mechanism by which the RPC layer can tell an upper layer "I can't perform the requested security service".

We already have channel binding, by which an upper layer can determine whether a security service is provided by an underlying transport layer.

Therefore, there is no clear use case that requires more than extending AUTH_SYS to include:

"AUTH_SYS with mutual peer authentication is OK"
"AUTH_SYS with encryption is OK"
"AUTH_SYS with both is OK"

Negotiating these does not require the server to stipulate the use of a specific connection type. The client and server's RPC layers can figure out which types to use. If the NFS layer needs to butt in, the channel binding API is available.

and without precedent.

 Perhaps so but, given the innovation that you and trond have provided, there will be many occasions to say things that were not said before.  stare decisus does not apply here.

"many occasions" -- OK, let's see some specific real world examples. I'm not seeing any possible case where we need more than what I outlined above (Rick's additional exception noted).

I believe strongly that we should narrowly define new protocol based on real needs, not expectations about what might happen. Expectations are almost always short-sighted or incorrect.

The framework provided by the current IANA registration of RPC auth flavors is entirely adequate to do what we need for NFSv4 SECINFO and NFSv3 MNT. It is up to new proposals to affirmatively demonstrate that the current framework is not adequate.

You have already made that point and I believe it is addressed in -03, although it is possible there were some editing slip-ups.

For example, QUIC, which is a connection type, uses TLS just like TCP does, though with QUIC TLS happens to always be enabled.

that is true but, given that there is no RPC-over-QUIC spec (even an individuaI-D), there are limits in what I can say about that in an I-D that is intended to morph into a standards-track RFC.

You're making my point for me. A missing spec should be enough to give you pause before defining something more complicated than we know how to use today.

Incidentally we do have a nascent personal draft for RPC-with-QUIC, but it has not been officially submitted to the IETF. We are waiting to understand the use cases for QUIC (over and above what is provided by existing technologies), as requested during the most recent previous WG meeting.

https://github.com/chucklever/i-d-rpc-over-quicv1

We might be better off but that would have required an  RPC connection-flavor abstraction paralleling the RPC auth-flavor abstraction.   We don't have that and the benefits of doing so, while real, do not justify  the substantial work do so now.

As far as confidentiality goes, there have to be three choices, rather than two:

  1.  Yes you get this automatically for the connection (RPC-with-TLS and eventually QUIC)  --> use this if you can.
  2.  You can get this, if you ask for it on a per request basis. (GSS when connection-based encryption is not available) --> Needed if 1. not available
  3.  No you can't get this (e.g. AUTH_SYS in the clear) --> run away as fast as you can

A simpler set of flavors will give us this flexibility. I don't see anything here that can't be done via what I proposed above.

This section needs analysis of specific use cases and explicit rationale for why negotiating connection types is necessary.

Since this is a proposed new feature, that analysis and rationale is paramount.

It is not a new feature.  It is the adaptation of an existing feature to be useful in the new environment in which the RPC auth-flavor is no longer the sole determinant of security services, but the role of the connection characteristics is of equal or greater importance.

Your proposal changes the operation of SECINFO to include BREAK and other control flow operations IIUC. This is no longer a matter of adding a pseudoflavor or new protocol element. You are changing the behavior of the operation, perhaps in ways that are not backwards compatible. That is why I bring up RFC 8178.

And I wonder how pleased NFSv3 implementers will be that they would need to handle XPT_BREAK in a moribund MNT implementation.

Burying this proposal in a large document with a broad scope will prevent adequate discussion IMO.

We are having a discussion of this now.  I hope it is productive.  If it is inadequate, I don't see how putting it in a separate document would remedy that.

I prefer to see these three sections split into their own document that can proceed to publication as soon as possible rather than being chained to the completion of the other potentially lengthier tasks in nfsv4-security.

  *   Sections 13 and 14, which deal respectively with authentication and the security of data  in flight are an integral part of the security provided by  NFSv4.  They have a  critical role in the new security architecture intended to take proper advantage of the work you and trond did in RPC-with-TLS.   I don't understand the motivation for putting these three pages anywhere other than draft-dnoveck-nfsv4-security or its successor documents.
  *   Section 15 is made necessary is made necessary by the changes in sections 13 and 14 so might make sense to deal with all these together, except for the following considerations:
     *   these sections are a total of eleven pages.
     *   While 13 and 14 are tightly bound to 15, they are also tightly bound to the rest of the spec, making any proposed surgery difficult.
     *    With regard to the suggestion that this will somehow accelerate adoption I am inclined to be skeptical.   this is not only because you seem to to feel theses changes not worth doing but also because you find some matters now in section 13 to be deeply problematic.

I don't see what is wrong with keeping these eleven pages with the rest of the security document.

Implementers want a TLS flavor negotiation capability in a standard yesterday, and they want it to include NFSv3 (MNT). The WG has the ability to meet that goal by writing a document that simply defines the new AUTH_SYS pseudoflavors, and get it published ASAP.

Section 15:

It needs to be noted that SECINFO's job is to allow the NFS server to tell the client what services to request. It could have been designed around abstract services, but it was designed around auth-flavors, which made sense then.   The problem is that, given the more limited role of auth-flavors, some chane is needed.

I don't agree: it gives us everything we need. IMO your proposal needs to adequately justify the need to go outside the boundaries of what we have today. The document needs to explain why we can't get to where we need to go with channel binding and a handful of AUTH_SYS pseudoflavors.

Section 15.4 and 15.4.1 belong in section 15.5. And again, because this subsection is specifying protocol elements, it does not belong in an architectural document, but instead should be either a separate smaller document that will be replaced eventually by rfc5661bis,

We need something that covers more than just NFSv4.x, and we need it quickly.

It might be helpful to have a contrasting proposal on the table. I can assemble a small document that makes an IANA request for the new AUTH_SYS - related RPC auth flavors.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 30 Nov 2021 09:49:01 -0500

On Mon, Nov 29, 2021 at 11:35 AM Chuck Lever III <[email-masked]>
wrote:

> My immediate concerns are with the discussion of security flavors /
> connection types, so permit me to redact the other parts of this thread in
> the interest of clarity, and address your responses only in that area, with
> one quick detour into the ACL part of the thread.
>
>
> On Nov 26, 2021, at 10:43 AM, David Noveck <[email-masked]> wrote:
>
> How do you propose to deal with a situation where a server uses multiple
> MAC labels (SMACK64, for example) or file capabilities ?
> https://linux.die.net/man/7/capabilities (and note that other OSes have
> their own flavors of capabilities).
>

Not all.  It is out of scope.

>
>
> There is a class of servers (eg OnTAP) that enable only remote access to
> files, and have only one physical file system implementation. The security
> document seems designed to address that case.
>

I don't think "designed" is the right word.  It is just that:

   - Discussion of local file access is out-of-scope in an NFSv4 spec.
   - Discussion of physical file systems is also out-of-scope.

> There is a class of servers (eg Linux, Solaris) that enable remote and
> local access to files, and have multiple independently-implemented file
> system types. Not all shares on such servers are guaranteed to implement
> the same set of access controls. Here, local users (or the server
> administrator) can set up additional access controls like capabilities,
> which are not visible to users on clients, and are not reflected in either
> the ACL or in the mode bits. Are you proposing that the nfsv4 WG mandate
> how these file systems update mode bits when those other access control
> mechanisms are put into place?
>

No I am not.   It is just that they affect modes and acls equally, and so
the mapping between these two is orthogonal.

> Some access control mechanisms, such as Linux IMA, are policy-based rather
> than controlled by settings on individual files. The policy is specified by
> the administrator in control of the file system where files are stored (ie,
> the server's file systems). IMO the text at least needs to recognize the
> presence of overriding security policy that is not modifiable from NFS
> clients.
>

It already does that in describing read-only fs's.  I'm open to suggestions
for expansion.

> What I meant was: perhaps these terms could be added to the document's
> forward glossary. I did browse the text looking for these, and still missed
> their definitions.
>

will try to do this in -04.

> I don't recall a discussion of rewriting the ACL sections from the ground
> up when the WG was considering the scope of the rfc5661bis effort. Also, as
> you have carefully identified areas where a consensus discussion is needed,
> let me tactfully point out that we are possibly veering outside the realm
> of simple maintenance. AFAIK there have been no errata filed against the
> ACL section of RFC 5661.
>
> Mainly I want to keep this effort contained and feasible, as I'm sure you
> do also. As I stated in the introduction to my review, I'm concerned that
> the scope of the rfc5661bis effort is continuing to broaden without any WG
> discussion regarding whether that's a desirable thing to do given currently
> available resources.
>
>
> *Section 13.1:*
>>

I don't think the client peer is included :-(

>
> We already have a mechanism by which the NFS server can request particular
> security services such as mutual peer authentication.
>
> We already have a mechanism by which the RPC layer can tell an upper layer
> "I can't perform the requested security service".
>
> We already have channel binding, by which an upper layer can determine
> whether a security service is provided by an underlying transport layer.
>
> Negotiating these does not require the server to stipulate the use of a
> specific connection type.
>

True.

> The client and server's RPC layers can figure out which types to use. If
> the NFS layer needs to butt in, the channel binding API is available.
>

Right, but the spec needs to describe how that is to be used.

> "many occasions" -- OK, let's see some specific real world examples. I'm
> not seeing any possible case where we need more than what I outlined above
> (Rick's additional exception noted).
>
> I believe strongly that we should narrowly define new protocol based on
> real needs, not expectations about what might happen. Expectations are
> almost always short-sighted or incorrect.
>
> The framework provided by the current IANA registration of RPC auth
> flavors is entirely adequate to do what we need for NFSv4 SECINFO and NFSv3
> MNT. It is up to new proposals to affirmatively demonstrate that the
> current framework is not adequate.
>
>
> You're making my point for me. A missing spec should be enough to give you
> pause before defining something more complicated than we know how to use
> today.
>
> Incidentally we do have a nascent personal draft for RPC-with-QUIC, but it
> has not been officially submitted to the IETF. We are waiting to understand
> the use cases for QUIC (over and above what is provided by existing
> technologies), as requested during the most recent previous WG meeting.
>
>    2. You can get this, if you ask for it on a per request basis. (GSS
>    when connection-based encryption is not available) --> Needed if 1. not
>    available
> A simpler set of flavors will give us this flexibility. I don't see
> anything here that can't be done via what I proposed above.
>
>
> It is not a new feature.  It is the adaptation of an existing feature to
> be useful in the new environment in which the RPC auth-flavor is no longer
> the sole determinant of security services, but the role of the connection
> Your proposal changes the operation of SECINFO to include BREAK and other
> control flow operations IIUC. This is no longer a matter of adding a
> pseudoflavor or new protocol element. You are changing the behavior of the
> operation, perhaps in ways that are not backwards compatible. That is why I
> bring up RFC 8178.
>
> And I wonder how pleased NFSv3 implementers will be that they would need
> to handle XPT_BREAK in a moribund MNT implementation.
>
>
> We are having a discussion of this now.  I hope it is productive.  If it
> is inadequate, I don't see how putting it in a separate document would
> remedy that.
>
> I prefer to see these three sections split into their own document that
>> can proceed to publication as soon as possible rather than being chained to
>> the completion of the other potentially lengthier tasks in nfsv4-security.
>>
>
>       adoption I am inclined to be skeptical.   this is not only because you seem
> Implementers want a TLS flavor negotiation capability in a standard
> yesterday, and they want it to include NFSv3 (MNT). The WG has the ability
> to meet that goal by writing a document that simply defines the new
> AUTH_SYS pseudoflavors, and get it published ASAP.
>
>
> *Section 15:*
>>
> I don't agree: it gives us everything we need. IMO your proposal needs to
> adequately justify the need to go outside the boundaries of what we have
> today. The document needs to explain why we can't get to where we need to
> go with channel binding and a handful of AUTH_SYS pseudoflavors.
>
>
> It might be helpful to have a contrasting proposal on the table. I can
> assemble a small document that makes an IANA request for the new AUTH_SYS -
> related RPC auth flavors.
>

If you do that, I think I could remove (or cut it way back) in a
subsequent draft.