Re: [nfsv4] Agenda items for virtual interim

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

Thanks for your response. (btw Gmail does have a well-hidden
plain text mode that might be helpful).

I'd like to consider this:

> With regard to the independence of transport and security services, I agree that this is desirable  but the fact is that today and maybe forever, what services are available depend on what transport is used, since RDMA is lagging in that area.


It is true that some transports do not have security services.
But I don't understand why that means we have to require
the pseudoflavors to include connection type information.

If the server says "I need ENCRYPTION" and the connection type
that is in use does not support that, then the client either
retries with another connection type that does, it chooses
another suitable security flavor in the list (eg GSS_KRB5P),
or it fails the mount/filesystem transition.

What am I missing?


> On Oct 18, 2021, at 7:09 AM, David Noveck <[e-mail]> wrote:
> 
> The  email quoting was not due to outlook.  It was Gmail.  In this response, I'm going to avoid quotation and simply state where things stand on the points you raised. I don't want to get into the whole rebuttal/surrebuttal/rerebuttal paradigm.
> 
> Regarding use of the term "transport" I am now in the process of comprehensively revising the document to address the issue.  I will have a predraft that you can rfcdiff against -02 within the next week.
> 
> With regard to pseudo flavors I will look at the ones you cited and get back to you.  
> 
> With regard to the independence of transport and security services, I agree that this is desirable  but the fact is that today and maybe forever, what services are available depend on what transport is used, since RDMA is lagging in that area.
> 
> With regard to other terminology issues I intend to reference the NIST document and add a terminology section but that work will not be done until -03.
> 
> With regard to the length of the document, I continue to be reluctant to split off pieces but will consider them if they become necessary.  While there is additional material to add, there are reasons to expect deletions as well.  There are lots of author Asides that will go away and cases where we have both old and proposed treatments of various issues.  I intend to revisit the issue of splitting out some the ACL stuff once -03 is done.
> 
> With regard to the whole pNFS thing, I was misunderstanding you but there are some short-term obstacles to going where I think you want to go, which is to have requirements in this documents with details to satisfy them in RFC5661bis or delegated to the mapping types.  The difficulty has to do with "requirements". Given where NFSv4 is now, any requirements would be ignored.  I do have recommendations in -02 but they are now part of an unresolved consensus item.  Once that consensus item is discussed and generally accepted, we will be in a position to generalize the needs behind it.  This cannot be a requirement. It is really an aspiration but that sounds too wishy-washy.  Maybe "need" could be used?
> 
> 
> 
> On Sun, Oct 17, 2021, 5:11 PM Chuck Lever III <[e-mail]> wrote:
> I've corrected the strange e-mail quoting from your
> client (I assume it's Outlook). Otherwise it would
> be impossible to tell who is saying what in this
> thread.
> 
> 
> > On Oct 17, 2021, at 8:10 AM, David Noveck <[e-mail]> wrote:
> > 
> >> On Sun, Oct 17, 2021, 12:42 AM Chuck Lever III <[e-mail]> wrote:
> >> 
> >> > 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.
> > 
> > Ok
> > 
> > 
> >> ----
> >> 
> >> 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. 
> > 
> > I'll try to deal better with this in -03.
> > 
> >> 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.
> > 
> > How about "by security services such as those provided by RPC-with-TLS" ?
> 
> That's OK.
> 
> Ditto for other uses of RPC-with/over-TLS in other areas
> of the document: the text needs to treat RPC-with-TLS as
> a security mechanism, not as a network transport. To
> provide feedback with specific examples, I've reviewed
> the nfsv4 mail archive to refresh myself on the problem
> statement for Section 15 of this document. I'm looking
> specifically at
> 
> https://mailarchive.ietf.org/arch/msg/nfsv4/F2xWYvtZ-QPQaH32J8RTwLbnNzY/
> 
> Now Section 15 has:
> 
>    The use of SECINFO, possibly with SECINFO_NONAME, remains the primary
>    means by which the security parameters are determined.  The addition
>    of transports to flavors in providing security has resulted in the
>    following changes:
> 
>    *  Transport-related security choices are typically decided at
>       connection-establishment so there needs to be provision for
>       negotiation at this point.
> 
>    *  Despite the above, because the choices of flavor and transport
>       affect one another, SECINFO has been extended by the addition of
>       pseudo-flavors, while retaining the existing XDR, to allow
>       negotiation of transport choices and accompanying connection
>       establishment options, in addition to selection of flavors and
>       accompanying services.  This allows server policies for such
>       matters to be different for different portions of the namespace.
> 
> and later:
> 
>    The flavor AUTH_TLS, which is not used as part of issuing requests is
>    not included in this list and is treated as a connection-type-
>    specifying pseudo-flavor.
> 
> IMHO conflating security flavors and connection types is
> problematic and will eventually lead to tears and sadness.
> 
> QUIC is a network transport service that provides security.
> TLS is a security mechanism that is overlaid on insecure
> network transport services like TCP. I think Section 15
> needs to deal coherently with both situations.
> 
> Selecting a security mechanism does not need to involve
> selecting a connection type. The upper layer should specify
> what kind of security service it needs (eg, "GSS with
> privacy") and let the lower layers handle the rest. Today,
> we don't specify "GSS with privacy on TCP" for example.
> 
> So expose the security mechanisms but not the transport
> types here. The pseudoflavors should work just like GSS
> in Appendix B of RFC 5531. The pseudoflavor numbers here
> are just examples.
> 
>         AUTH_NONE               0       /* plain old NONE */
>         AUTH_SYS                1       /* plain old SYS */
> 
>         AUTH_NONE_PEERAUTH      400001  /* peer authentication */
>         AUTH_NONE_ENC           400002  /* encryption */
>         AUTH_NONE_PA_ENC        400003  /* authentication and encryption */
> 
>         AUTH_SYS_PEERAUTH       410001  /* peer authentication */
>         AUTH_SYS_ENC            410002  /* encryption */
>         AUTH_SYS_PA_ENC         410003  /* authentication and encryption */
> 
> The connection type is then chosen separately: these three
> pseudoflavors can work on RPC/RDMA v2, or QUIC, or TCP, or
> any connection type in the future that might or might not
> provide these security mechanisms by itself.
> 
> Note that RFC 2623 Section 4.2 assigns OIDs and text names
> as well as pseudoflavor numbers for the GSS pseudoflavors.
> I'm not certain OIDs will be needed for these new
> pseudoflavors.
> 
> Interestingly, Section 5 of rpc-tls requires encryption to
> be enabled:
> 
>       Negotiation of a ciphersuite providing confidentiality as well as
>       integrity protection is REQUIRED.
> 
> Thus the PEERAUTH pseudoflavors could never be used when
> TLS alone provides transport layer security); only ENC
> or PA_ENC would be valid.
> 
> 
> >> 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.
> > 
> > Fair enough.
> > 
> >> ----
> >> 
> >> 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).
> > 
> > I'll try to make the motivation clearer in -03.
> > 
> > With regard to the layering angst you feel, I sympathize but feel that, given our inability to modify existing XDR, there was no alternative to walking through the open door that SECINFO provided.
> 
> Changing the language of the document to treat security
> as independent from network transport would go a long way.
> 
> 
> >> 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.
> >> 
> > I feel this is more likely to result in added confusion.  The goal has always been secure use on the internet
> 
> The goal is to help implementers and WG members understand
> the security issues at hand. We need to have examples of
> how other commonly used security mechanisms can address the
> basic generic security issues. Otherwise, the advice boils
> down to "use RPC-with-TLS" and no-one understands why.
> 
> This is not a hill to die on, however.
> 
> 
> > and I don't want to risk changing the discussion to one about secure use on other networks that might happen to be built on top of the internet
> 
> Um. RPC-with-TLS is /exactly/ secure use on top of a service
> that is built on top of the internet, and it uses /exactly/
> the same mechanisms as an SSH tunnel, and much of the same
> cryptography as IPsec. Not to be argumentative, but I don't
> understand your reticence to provide reasonable examples
> to help readers understand general concepts and principals.
> 
> The "other networks built on top of the internet" is actually
> very common in cloud scenarios as well as work-from-home. Not
> sure why you wouldn't want to consider those carefully.
> 
> 
> >> ----
> >> 
> >> 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,
> > 
> > That is your misunderstanding.
> > 
> >> but it appears that Security Considerations are just a tiny
> >> part of this document 
> > 
> > I do intend to fix that in -03 and -04.
> > 
> >> and the bulk of it appears to specify
> >> a bunch of new protocol.
> > 
> > There is some new protocol but a lot of the new work is just cleanup of stuff that is no longer reasonable such as the excessive focus on authentication flavors and the ACL handling text that led Bruce to use the word "despair".   The only way for me to help deal with that situation is to clean up the troublesome spec text.
> 
> So the document mission seems to have changed somewhat.
> The Abstract says:
> 
>    This document describes the core security features of the NFSv4
>    family of protocols, applying to all minor versions.
> 
> I wasn't expecting that the mechanics of the protocol
> would appear in this document. Again, somehow I thought
> this was going to be a focused Security Considerations
> document that covered all NFSv4 minor versions. At some
> point in the past, that's exactly how this document was
> billed.
> 
> 
> >> 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.
> > 
> > I disagree.  This was always intended to be a normative document and I can't really imagine writing a threat analysis of what exists now.   Whatever length you chose would boil down to "It really sucks".
> 
> Let's not focus on Normative/Informative, that was a poor
> word choice on my part. But we do need to have a high-level
> framework to evaluate existing and changed protocol from a
> security perspective. The Abstract says that's part of what
> this document is supposed to be doing.
> 
> 
> > I don't want to publish that so I am stuck fixing it first, which is now possible given the work you've done in RPC-preposition-TLS.  That gives me the possibility of a threat analysis that looks reasonable.🙂
> > 
> >> 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.
> > 
> > Trying to tease these apart is extra work that I'm not prepared to take on, since the document, exclusive of appendices is about one hundred pages.
> 
> It's 118 pages now, and you've already committed to adding
> more substance to the Security Considerations section in
> this document. My concern is that it will soon grow to 200
> or more pages, making it difficult to review and a challenge
> for implementers to use.
> 
> It doesn't hurt to look for opportunities to shorten it as
> you go along.
> 
> 
> >> 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.
> > 
> > ???.  You did RPC-with-TLS without a threat analysis.
> 
> Please look at the Security Considerations section of
> rpc-tls again. For example, the whole of Appendix A is
> a threat analysis of AUTH_SYS (albeit possibly not a
> complete one). Note also that the Security Considerations
> section of rpc-tls relies on several other documents that
> have full-throated threat analyses (TLS and x.509).
> 
> Even if you want to argue that there was no existing
> threat model for RPC-with-TLS, that doesn't mean that
> going forward we should not put the horse in front of
> the cart.
> 
> 
> > The lack of an demonstration of effectiveness was not a problem then and should not be one now
> 
> Honestly, I don't understand this statement on its face.
> The point of this work was to address the lack of threat
> analysis for NFSv4 as part of updating RFC 5661. It
> does not make sense to now say we don't need a threat
> model to assess effectiveness of proposed NFSv4 security
> facilities -- that's the reason SecDir is insisting on
> having an analysis in the first place.
> 
> 
> >> 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.
> >> 
> > It isn't.
> > 
> > 
> > ----
> > 
> >> 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.
> > 
> > I'm confused.  You seem to be objecting to doing this in 5661bis which I intend to do but just below you recommend that very thing.
> 
> I think you misread what I wrote below.
> 
> 
> >> 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.
> > 
> > For reasons we might well agree on, it's candidature has been rejected.
> 
> I don't understand why, for example, security labels are
> appropriate to discuss in this document, but pNFS security
> is not. Both are missing in at least one NFSv4 minor
> version.
> 
> In any event, if you continue with the current document
> organization, you need to revisit the rationale for excluding
> pNFS that you provide early in the document. Leaving it out
> simply because it's not in all NFSv4 minor versions is not
> a justifiable or consistent reason.
> 
> 
> >> 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).
> > 
> > Yes, but a pNFS security discussion also has to deal with protocols whose security is very different, such as block and object.
> 
> All of those need to have clearly stated common security
> requirements, no matter how they are implemented in those
> protocols.
> 
> The Security Considerations section of RFC 8434 ("Requirements
> for Parallel NFS (pNFS) Layout Types") is just three
> paragraphs. The middle paragraph states:
> 
>    The layout type specification must ensure that only data access
>    consistent with the NFSV4.1 security model is allowed.
> 
> At the time RFC 8434 was published, I think you'll agree that
> "the NFSv4.1 security model" was ill-defined.
> 
> All I'm saying is write the protocol security requirements
> here, get consensus on those and publish them; then update
> or clarify the particular protocol elements in other
> documents and cite this one.
> 
> 
> > 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).
> > 
> > We have come full circle here. I want to stop before I get dizzy.
> 
> You might have misunderstood.
> 
> Some document (maybe this one) needs to specify the general
> security requirements for pNFS layout types. The specific
> protocol changes or clarifications should then be made in
> other places (like RFC 5661bis). This does not seem
> inconsistent with anything I've said so far.
> 
> 
> >> ----
> >> 
> >>    *  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, 
> > 
> > I will say "user authentication" in -03.
> > 
> >> and that you mean strong (ie cryptographic)
> >> authentication throughout the document.
> > 
> > I don't know of any other form of authentication.  You pointed out to me the difference between identification (provided  by AUTH_SYS) and authentication (not provided by AUTH_SYS) and I have adopted that approach.  I hope the result is clear but if you have specific suggestions, will consider them for -03.
> 
> Define the terms in a glossary, and be sure that your
> glossary's definition of "authentication" includes
> /cryptographic/ proof of identity.
> 
> 
> >> ----
> >> 
> >> 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".
> >> 
> > Will address in -03.
> > 
> > 
> >> 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.
> > 
> > They might indeed but I don't know enough to say.  However, since NFS security is   built on RPC I really can't discuss the matter in a general NFSv4 security document
> 
> You seem to be saying that it is the former: the lack of the
> use of RPC makes it difficult to discuss other storage access
> protocols in detail in this document. That feels again like
> you're putting the cart first. pNFS needs to define its
> security requirements, and then use RPC and other protocols
> to meet those requirements.
> 
> 
> >> Having a comprehensive threat analysis to refer to would identify
> >> exactly what is required of a secure storage access protocol.
> > 
> > I don't know how to write such a comprehensive threat analysis.
> 
> Have a look at NIST SP 800-209 and ISO/IEC 27040. These describe
> storage security and provide a taxonomy of the kind of threats
> this document needs to address. We will not need to address
> every type of threat described therein (for example, SAN storage
> is covered at length), but some of that material is on point
> and the WG's publications should at least not contradict what
> is contained in those documents.
> 
> After all, implementations need to comply with those other
> standards in order to be competitive in markets that include
> storage for cloud, health care, and government contracts.
> 
> 
> > If you do, I'd like to see you do that.
> 
> I assumed you were already attempting to do that in nfsv4-security.
> It would help me to understand how the scope of this document has
> shifted since we first discussed the RFC 5661bis work. The Abstract
> says:
> 
>    This document describes the core security features of the NFSv4
>    family of protocols, applying to all minor versions.  The discussion
>    includes the use of security features provided by the RPC transport.
> 
>    This preliminary version of the document, is intended, in large part,
>    to result in working group discussion regarding existing NFSv4
>    security issues and to provide a framework for addressing these
>    issues and obtaining working group consensus regarding necessary
>    changes.
> 
>    When a successor document is eventually published as an RFC, it will
>    supersede the description of security appearing in existing minor
>    version specification documents such as RFC 7530 and RFC 8881.
> 
> It says right here that the document provides a framework
> for addressing these issues. That would include a threat
> analysis, would it not?
> 
> And, I assumed "a successor document" meant the WG version of
> this document. Does it mean something else?
> 
> 
> --
> Chuck Lever
> 
> 
> 

--
Chuck Lever