Re: [nfsv4] Agenda items for virtual interim

[David Noveck <[e-mail]>]

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" ?


>
> 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.


> 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 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


> ----
>
> 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.

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

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.


> 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.  The lack of an
demonstration of effectiveness was not a problem then and should not be one
now


> 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.

>
> 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.


> 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.

>
> 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.


> ----
>
>    *  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.

>
> ----
>
> 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

>
> 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.   If you
do, I'd like to see you do that.


>
> --
> Chuck Lever
>
>
>
>