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

[David Noveck <[e-mail]>]

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 <[e-mail]>
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:
>
>    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.
>

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.

>
> I also propose that Sections 13 through 15 be moved to a separate
> 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:*
>
>    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.
>

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
> "reverse-slope".
>

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.

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

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

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