Subject: [nfsv4] Agenda items for virtual interim

From: David Noveck <[email-masked]>
Date: Sat, 16 Oct 2021 09:28:00 -0400

I need to provide a real agenda for our virtual interim meeting and so I'm
primarily turning to the Usual Suspects to help but would like to hear from
anyone in the working group who has an idea for something to discuss.

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 also want to hear from Tom T about a number of RDMA-related topics:

   - His 'push-mode" work.
   - Possible approaches to a secure RDMA protocol taking advantage of
   either TLS or Quic.

There has been some discussion on the mailing list concerning a missing
error in ALLOCATE.  Tom H has said he doesn't know how hard it would be to
fix that and I don't know either. I'd like Tom's help in finding out.  It
used to be that you could simply create a new document obsoleting the
previous one with the fix.   Not much work but a lot of patience required.
 Lately the IESG has taken to insisting on bis documents in situations like
this, which I feel is inappropriate for v4.2 which is a bunch of unrelated
optional features.  I think we need to discuss this issue and make the case
that any bis would have to be for a specific v4.2 feature rather than for
v4.2 as a whole.  I'd like this discussion to happen at a wg meeting so we
can get Zahed's input, especially since, if we convince him, he will wind
up having to make the case to the IESG.  Tom, could you lead a discussion
on this issue?

---

From: Chuck Lever III <[email-masked]>
Date: Sat, 16 Oct 2021 21:25:03 +0000

> On Oct 16, 2021, at 9:28 AM, David Noveck <[email-masked]> 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.

After that, I think I'd like to huddle with Rick to discuss
how NFSv3 should work. Once we have something, we can present
options or discuss it on the mailing list.

In short, I agree this is something that needs to be discussed
at some point, but I'm not confident I'll be ready by Oct 27.
I'd prefer to see some discussion on list about this before
we bring it to a WG meeting.

(Given the limited degree of interactivity available during a
virtual meeting, I'd say we should consider restricting the
agenda to slides plus a couple of executive WG decisions for
each chosen topic, at least until the virtual meeting
technology improves).

> 	• His 'push-mode" work.
> 	• Possible approaches to a secure RDMA protocol taking advantage of either TLS or Quic.

This might not be a popular opinion, but DDP/MPA over QUIC in
my opinion would be a more straightforward option than plumbing
a bespoke authentication protocol into RPC/RDMA. A transport
level approach could also help resolve the authentication issues
that came up last time we considered a pNFS/RDMA layout type.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Sat, 16 Oct 2021 22:33:56 +0000

Chuck Lever III 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.
>
Well, for the implementation I did for FreeBSD, it just worked. All the changes were in the kernel
RPC layer used by all versions of NFS,
--> I suppose there is the question of crossing server mount point boundaries, where the
      requirement for RPC-with-TLS changes, but at least for FreeBSD, NFSv3 exports individual
      file systems, so there is no issue.

Having said that, I have done nothing w.r.t. the ancillary protocols (Mount, NLM, NSM). To do
Mount and NSM on FreeBSD, the userland RPC library functions would need to be modified to
support RPC-with-TLS. This wouldn't be hard to do, but  might be hard to deploy, since it means
that all RPC programs would need to link to the OpenSSL libraries, and that might not be
acceptable to the FreeBSD collective.

Not sure if support should be required for the ancillary protocols and not sure who would decide?
(Does Oracle claim NFSv3 as theirs or is it just an orphan now?;-)

>we bring it to a WG meeting.
I'll be interested in hearing what others think? Chuck, if you want to email off-list, that's fine with me,
but I'll admit the above is all I can think of right now.

rick

--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: David Noveck <[email-masked]>
Date: Sat, 16 Oct 2021 22:26:10 -0400

On Sat, Oct 16, 2021, 5:25 PM Chuck Lever III <[email-masked]>
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.
>

It's 118 pages so it would be best to start soon.

> we bring it to a WG meeting.

I think I should publish an agenda by 10/20 so let me know by then if you
have an item to present.  I can specify a period of general discussion for
miscellaneous items

> virtual meeting,

I don't think we will face the interactivity issues that we saw with
meetecho, given that we will use WebEx.

I'd say we should consider restricting the
> each chosen topic, at least until the virtual meeting

I don't see all that many decisions being made anyway..  in any case, any
decisions made have to be confirmed on the list.

This is not really a technology issue.  I don't remember large numbers of
decisions being made when we were meeting with everybody in the same room.

> a bespoke authentication protocol into RPC/RDMA.

It's not unpopular with me.  If you want to avoid the work of putting
authentication into RPC/RDMA v2 by talking this approach, I'm OK with it
but you might want to send a message to the wg list to inform the group
about this decision.

A transport
> that came up last time we considered a pNFS/RDMA layout type.

As I recall things, the issues we were dealing with were related to ofed's
approach to authorization rather than being due to authentication issues
per se.

---

From: David Noveck <[email-masked]>
Date: Sat, 16 Oct 2021 22:38:34 -0400

On Sat, Oct 16, 2021, 6:33 PM Rick Macklem <[email-masked]> wrote:

> addressing use of RPC-with-TLS for NFSv3 and >>how that might or might not

Since these are described, if described  at all, in informational
documents, I think each implementer gets to decide.

(Does Oracle claim NFSv3

as theirs

It doesn't/can't claim the protocol.

or is it just an orphan now?;-)

I think the IETF is now the step-parent. Since it is informational, the
relationship is not a close one ;-)

---

From: Chuck Lever III <[email-masked]>
Date: Sun, 17 Oct 2021 04:42:50 +0000

> On Oct 16, 2021, at 10:26 PM, David Noveck <[email-masked]> wrote:
> 
> On Sat, Oct 16, 2021, 5:25 PM Chuck Lever III <[email-masked]> wrote:
> 

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

---

From: David Noveck <[email-masked]>
Date: Sun, 17 Oct 2021 08:10:25 -0400

> have more to say once I'm more awake.

Ok

> steer us around.

I'll try to deal better with this in -03.

>       transports such as RPC-over-TLS.

How about "by security services such as those provided by RPC-with-TLS" ?

> have a confusing effect on less-experienced readers.

Fair enough.

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

> 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

> Considerations section for the NFSv4 standards documents,

That is your misunderstanding.

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

> analysis, but then left new and revised protocol to other

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

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

> 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

> organization at a later time.

It isn't.

>       The security considerations section of rfc5661bis will deal with

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.

> appropriate candidate for inclusion in this document.

For reasons we might well agree on, it's candidature has been rejected.

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

> details placed in another document (such as RFC 5661bis).

We have come full circle here. I want to stop before I get dizzy.

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

> First, I suggest starting with "The OPTIONAL pNFS feature

Will address in -03.

> 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

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

---

From: Chuck Lever III <[email-masked]>
Date: Sun, 17 Oct 2021 21:10:56 +0000

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 <[email-masked]> wrote:
> 
>> On Sun, Oct 17, 2021, 12:42 AM Chuck Lever III <[email-masked]> wrote:
>> 

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.

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

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

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

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

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

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

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

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

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

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

> 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

---

From: Chuck Lever III <[email-masked]>
Date: Sun, 17 Oct 2021 21:45:40 +0000

> On Oct 16, 2021, at 6:33 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:

I was thinking that the MNT procedure would have to provide
the same list of pseudoflavors that SECINFO deals with, and
the server's kernel would need to enforce the administrator's
policy of which ones are permitted.

I'll have to study the MOUNT protocol Appendix to see if adding
unexpected flavors to the result of MNT will be a problem for
existing implementations.

> acceptable to the FreeBSD collective.

FedFS on Linux used to require LDAP and still requires libxml2.
For FedFS support, the Linux mountd does a dynamic module
load. If that library happens not to be available then FedFS
junctions are not available on that server. The same approach
could be taken to handle RPC-with-TLS support in Linux's
libtirpc, but I don't have a plan to do that yet.

Linux handles NLM and NFSACL in the kernel, so these could
reasonably be modified to use the kernel's RPC-with-TLS
support. NFSACL will probably get TLS anyway because it is
conveyed on the same transport as NFS.

> Not sure if support should be required for the ancillary protocols and not sure who would decide?

Implementers decide, of course. The Linux NFS community has
so far decided not to protect these sideband protocols with
RPCSEC GSS, for instance. (IIRC Solaris is the same).

> (Does Oracle claim NFSv3 as theirs or is it just an orphan now?;-)

NFSv3 is not an orphan. Sun Microsystems contributed NFSv3 to
the IETF back in the 1990s, so Oracle does not have any
unilateral say regarding what happens to it today.

I don't believe the nfsv4 WG is willing to publish any updates
to RFC 1813, however, so NFSv3 is effectively moribund (tm).

> but I'll admit the above is all I can think of right now.

Well then we might be pretty close to having a cohesive plan
for NFSv3 in-transit encryption. Only WG decision being where
to document the conventions and changes, if any are needed.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Mon, 18 Oct 2021 00:41:13 +0000

Chuck Lever III wrote:
[lots of stuff snipped]
>        AUTH_SYS_PA_ENC         410003  /* authentication and encryption */
I think this sounds reasonable. There is another case that might be worth
considering. I am thinking of a rather specific case where an X.509
certificate provided by a client is pinned to a fixed IP address/DNS name.
--> The server expects that the X.509 certificate will have a DNS or IP component
       in subjectAltName that matches the IP address used by the client to connect
       to the server. (There is an RFC that discusses this for the case where a client is
       checking a server's certificate.)

Maybe a generic term for it could be something like:
          AUTH_xxx_PEERAUTH_FIXED_IPADDR

Btw, there are a couple of things that I don't recall being in the draft I read (an
earlier one). If they are there now, please just ignore the following...

machine credential - It seems that a TLS handshake and/or verification of a
    client's X.509 peer certificate establishes a "client machine credential".
    However, there is no "machine principal" that can be used by the client
    for RPCs that must be done with a "machine principal" (such as EXCHANGE_ID...)
    --> One possibility I can think of is adding a new authentication flavor called
          something like "AUTH_MACHINE_PRINCIPAL" that would indicate
          "use the machine credential established via TLS handshake and/or X.509
            certificate verification" as the credentials for this RPC.

Then there is the case of the NFSv4.0 callback TCP connection.
Should the server attempt to use RPC-with-TLS if the client-->server TCP connection is doing so?
And, should the server stop doing callbacks if the RPC-with-TLS probe or handshake fails?
RFC 7530 Sec. 3.3.3 addresses the use of the credentials in the callback RPCs, but I don't
think it answers the above questions.
If an NFSv4.0 server were to do a successful TLS handshake and/or provide an appropriate
X.509 certificate to the client, it could use the AUTH_MACHINE_PRINCIPAL described above.
--> Although you could argue this is a server implementation choice, interoperability will be
      impacted negatively if there is no guidance in this (or a companion) document, I think?

rick

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 18 Oct 2021 07:09:44 -0400

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 <[email-masked]>
wrote:

> 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
>
> > 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.
>
> > Yes, but a pNFS security discussion also has to deal with protocols
> whose security is very different, such as block and object.
>

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 18 Oct 2021 13:52:03 +0000

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 <[email-masked]> 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 <[email-masked]> wrote:

--
Chuck Lever

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 18 Oct 2021 14:12:14 +0000

> On Oct 17, 2021, at 8:41 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:
> [lots of stuff snipped]

I'm not understanding why a server would need to communicate
this to a client during security negotiation. Wouldn't it
just be a matter of setting up this policy on the server?
Does a client choose a special certificate to use in this
case?

But also, I think we have some leeway here to introduce a
narrow basic set of pseudoflavors now and then expand them
as needs arise, via additional documents.

>            certificate verification" as the credentials for this RPC.

I had forgotten about that!

Again, not sure there needs to be a unique p-flavor, but
I agree there needs to be some documentation about
promoting a client's peer credential for authenticating
lease management operations.

> And, should the server stop doing callbacks if the RPC-with-TLS probe or handshake fails?

IMO those are (reasonable) security policy choices.

> X.509 certificate to the client, it could use the AUTH_MACHINE_PRINCIPAL described above.

Or the client and server could be required to use the same
certificate pair that was used to establish the forward
channel? I recall there is a similar restriction on which
GSS service principals are used for callback operation.

Establishing a TLS-protected callback channel would
necessitate that the client have a certificate/PSK. The
server-only encryption mode would not work at all.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Mon, 18 Oct 2021 15:03:24 +0000

>Does a client choose a special certificate to use in this
No. To be honest, I do not see a reason for a client to not present a certificate to
the server during TLS handshake, if it has one.

I think the only decision the client will make is whether or not to do TLS
at all. (It might choose not to for performance reasons.)

If more pseudo-flavors are useful, I think it would be to tell the client that
security negotiation is not going to work unless the client can do X,
which would allow the client to log why security negotiation cannot
be completed (if it cannot do X). (Some security types prefer "security
via obscurity", but that can make it difficult for sysadmins to determine
why a failure is occurring.)

I would be fine with just a pseudo-flavor for TLS or similar is required,
since I think that is the only case where the client might optionally choose
to not do it.

>as needs arise, via additional documents.
Of course, although it can take a long time for a document to get
published, plus implementation get deployed.

>lease management operations.
Yes, I'm fine with anything that works. Maybe just saying that,
when done with TLS, the RPC credential should be ignored for these operations
and "same principal" should be assumed?

>GSS service principals are used for callback operation.
Yes, I think that "if TLS with certificates is required, using the same certificates makes sense".

>server-only encryption mode would not work at all.
Yes, that is one reason why requiring this may not be appropriate.
Another might be that an NFS server may not know how to do the TLS-probe and client
end of TLS handshake, due to lack of implementation.

The question really comes down to "is TLS security on the callback TCP connection needed?"
or is it better to just advise against it and allow extant rules from RFC7530 Sec. 3.3.3 to be
applied?

rick

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 19 Oct 2021 11:36:23 -0400

Just wanted to let everyone know that I will put together an agenda for the
interim meeting tomorrow, so if anyone does want to add an agenda item,
please let me know soon.

On Sat, Oct 16, 2021, 9:28 AM David Noveck <[email-masked]> wrote:

>  I need to provide a real agenda for our virtual interim meeting and so
> I'm primarily turning to the Usual Suspects to help but would like to hear
> from anyone in the working group who has an idea for something to discuss.
>