Re: [nfsv4] Agenda items for virtual interim

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

> On Oct 16, 2021, at 10:26 PM, David Noveck <[e-mail]> wrote:
> 
> On Sat, Oct 16, 2021, 5:25 PM Chuck Lever III <[e-mail]> wrote:
> 
>> > On Oct 16, 2021, at 9:28 AM, David Noveck <[e-mail]> wrote:
>> > 
>> > I'd be interested in hearing from Chuck about his thoughts about addressing use of RPC-with-TLS for NFSv3 and how that might or might not interact with the v4 security work now going on.
>> 
>> I haven't had a chance to read nfsv4-security yet. That is at
>> the top of my to-do list.
> 
> It's 118 pages so it would be best to start soon.

I browsed the document this evening to get a head start.
Clearly this is a lot of work. Thanks for taking it on.

I have some initial impressions, and I might probably
have more to say once I'm more awake.

----

After months of me stating very clearly that the term to
use is "RPC-with-TLS" and not "RPC-over-TLS" precisely
because people were confusing RPC-over-TLS with an actual
transport, you have constructed a novel "transport-based
security model" with RPC-over-TLS at its core, essentially
building on the exact confusion that I have been trying to
steer us around. For example, from Section 3.2:

      The protection of state data from unauthorized modification is
      discussed in Section 11) is the same in all minor versions
      together with the identification/ authentication infrastructure
      supporting it (discussed in Section 13) provided by secure
      transports such as RPC-over-TLS.


RPC-over-TLS no longer exists because we specified a
new security mode, not a new transport -- we use UDP and
TCP as the actual network transport service. To wit,
RPC-with-TLS does not have its own assigned netid.

"Network transport service" is a term that has a pretty
widely recognized meaning. To avoid confusion, let's try
to stick with that meaning, and keep the security services
that might be offered by a network transport service as a
separate issue.

I see a mix of RPC-with/over-TLS throughout, so I'll assume
the mix of terminology is merely an artifact of incomplete
editing. However, the conceptual confusion still concerns
me because it impacts the document's organization and will
have a confusing effect on less-experienced readers.

----

The use of "transport-based security" IMHO is problematic.
For one, we have had TI-RPC for many years that has attempted
to divide transports into a set of separate functional
categories, and it's proven difficult to use, has not
been broadly adopted, and has not aged well.

The introduction of multiple new authentication flavors to
represent connection types or transport feels like a
layering violation to me that I'm still trying to get
comfortable with. I'd rather not mix transport- and security-
negotiation this way until we have a much stronger motivation
laid out in this document. (I might have missed it, but that
motivation seems to be only implied in the current text).

We might find it illuminating to consider alternatives
to RPC-with-TLS. IPsec has been suggested, and we already
know that some installations deploy NFS only on SSH
tunnels. The document might compare and contrast these
technologies to help clarify our design motivation.

----

Perhaps it is my own misunderstanding, but I had thought
this document was supposed to serve as a Security
Considerations section for the NFSv4 standards documents,
but it appears that Security Considerations are just a tiny
part of this document and the bulk of it appears to specify
a bunch of new protocol.

IMO it would be more usable for implementers and easier to
review as well if this document remained fully Informational
and covered just the high-level items such as threat
analysis, but then left new and revised protocol to other
Normative documents.

For instance, I would separate the bulk of the discussion
of ACLs and mode bits into a separate document; an
additional document would also be appropriate for handling
new security negotiation features.

Additionally, the new protocol elements need to be driven
by threat analysis, which is not yet part of this document,
otherwise there is no possible way to demonstrate whether
or not the new elements are effective.

I realize that the document is in very early stages, and
it might already be your intent to follow my suggested
organization at a later time.

----

I struggle with the decision described in this text:

      The definitive description of pNFS security will remain in RFC8881
      and its successors (i.e. the rfc5661bis document suite).  However,
      because pNFS security relies heavily on the infrastructure
      discussed here, it is anticipated that the new treatment of pNFS
      security will deal with many matters by referencing the overall
      NFS security document.

      The security considerations section of rfc5661bis will deal with
      pNFS security issues.

pNFS is unsupported in only one of the existing NFSv4
minor versions. That makes it a common element of the
majority of minor versions, and thus to me seems like an
appropriate candidate for inclusion in this document.

Any general discussion of network file system security
applies to protocols that might be adopted as part of a
pNFS layout type, and the considerations for those
protocols are essentially the same as the ones for NFSv4
itself (at least when NFSv4 is doing I/O operations).

Here it seems like an ideal example of leaving the high
level approach outlined in this document, and the protocol
details placed in another document (such as RFC 5661bis).

----

   *  The availability of RPC-with-TLS (described in [12]) provides
      facilities that NFSv4 clients and servers will need to use to
      provide security for data in flight and mitigate the lack of
      authentication when AUTH_SYS is used.

This text should make clear whether you are referring to peer or
user authentication, and that you mean strong (ie cryptographic)
authentication throughout the document.

----

This one is more of a nit, but it caught my eye:

      The pNFS optional feature added in NFSv4.1 has its own security
      needs which parallel closely those of non-pNFS access but are
      distinct, especially when the storage access protocol used are not
      RPC protocols.  As a result, these needs and the means to satisfy
      them are not discussed in this document.

First, I suggest starting with "The OPTIONAL pNFS feature
added".

Second, you refer to storage access protocols that "are not RPC
protocols." Is it the use of RPC that is the distinction here,
or is it something else? Some storage access protocols might
already have sufficient user and peer authentication as well as
access to encryption and integrity services, even though they
do not use ONC RPC or RPCSEC_GSS.

Having a comprehensive threat analysis to refer to would identify
exactly what is required of a secure storage access protocol.


--
Chuck Lever