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

[Chuck Lever III <[e-mail]>]

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