Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt

From: Chuck Lever III <[email-masked]>
Date: Sun, 5 Dec 2021 20:07:40 +0000

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> Date: December 5, 2021 at 2:41:27 PM EST
> To: "Charles Lever" <[email-masked]>, "Chuck Lever" <[email-masked]>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> has been successfully submitted by Chuck Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpc-tls-pseudoflavors
> Revision:	00
> Title:		Pseudo-flavors for Remote Procedure Calls with Transport Layer Security
> Document date:	2021-12-05
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-pseudoflavors/
> Html:           https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
> 
> 
> Abstract:
>   Recent innovations in Remote Procedure Call (RPC) transport layer
>   security enable broad deployment of encryption and mutual peer
>   authentication when exchanging RPC messages.  These security
>   mechanisms can protect peers who continue to use the AUTH_SYS RPC
>   auth flavor, which is not cryptographically secure, on open networks.
>   This document introduces several RPC auth pseudo-flavors and other
>   mechanisms that an RPC service can use to indicate transport layer
>   security requirements for accessing that service.
> 
> 
> 
> 
> The IETF Secretariat

I've submitted this personal draft to provide a fleshed-out version of
a proposal I have outlined in the recent past:

https://mailarchive.ietf.org/arch/msg/nfsv4/tU1WfkYQUm2AbiZUA3L2uX56uR4/
https://mailarchive.ietf.org/arch/msg/nfsv4/7psVqBBY8uhP9L9bMfF7hUbVXK0/

among other places.

This document provides a similar but contrasting approach to the one
described in Sections 13 through 15 of draft-dnoveck-nfsv4-security-03.
In addition to covering NFSv4, my document also addresses NFSv2/3 and
other RPC services that might wish to employ transport layer security.
I'm hoping that comparing and contrasting these two approaches will
sharpen our vision and thinking as the WG comes to a rough consensus.

Another important reason for a separate document is there seems to be
palpable demand for a standards-based NFS in-transit encryption solution.
The RPC protocol changes put forth in draft-ietf-nfsv4-rpc-tls are
necessary but not sufficient to accomplish this goal. I would like to
see a vehicle for moving the remaining components through WG consensus
and into the publication queue as quickly as possible. This document
might serve as that vehicle.

An -00 is, as always, a rough cut. There are likely to be significant
gaps in this proposal, which at this point is still quite malleable.
Thanks in advance for your time and attention to this work.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Mon, 6 Dec 2021 02:06:54 +0000

In section 3.2:
If an RPC client sends an RPC Call using one of these pseudo-flavors
   and the underlying transport does not provide the required additional
   security services as indicated above, the RPC server MUST reject the
   RPC Call and respond with a reply_stat of MSG_DENIED, a reject_stat
   of AUTH_ERR, and an auth_stat of AUTH_TOOWEAK.

For NFSv4, wouldn't NFS4ERR_WRONGSEC be a more natural fit than
AUTH_ERR with auth_stat AUTH_TOOWEAK?
--> I understand you wanted to cover NFSv3 as well, but since NFSv4
      clients will need to do a SecInfo/SecInfo_Noname, then it seems weird
      that it will be triggered by a RPC level error and not NFS4ERR_WRONGSEC.

Is it possible to allow either AUTH_ERR/AUTH_TOOWEAK or NFS4ERR_WRONGSEC
as a server reply?

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Chuck Lever III <[email-masked]>
Sent: Sunday, December 5, 2021 3:07 PM
To: NFSv4
Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email-masked]

among other places.

--
Chuck Lever

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

---

From: David Noveck <[email-masked]>
Date: Mon, 6 Dec 2021 05:29:48 -0500

>       that it will be triggered by a RPC level error and not

That's true but given that this is an RPC document, Chuck really can't
refer to NFSv4 errors.

> Is it possible to allow either AUTH_ERR/AUTH_TOOWEAK or NFS4ERR_WRONGSEC

I think we have to distinguish using AUTH_SYS_MPA handled as above and
using AUTH_SYS on a connection on which MPA is not in effect.  The RPC
document could make clear that this latter is a security issue with the
specific response left up to ULP.

Chuck and I have to work together to make sure that these documents fit
together appropriately.   I expect that security-04 will be able to
reference this document.

> Subject: [nfsv4] Fwd: New Version Notification for
> draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> [email-masked]
>
>
> > Begin forwarded message:
> >
> > Subject: New Version Notification for
> draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> > URL:
> https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-pseudoflavors/
> > Html:
> https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
> >
> >
> > Abstract:

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 6 Dec 2021 15:38:18 +0000

Hi Rick, thanks for taking a look.

> On Dec 5, 2021, at 9:06 PM, Rick Macklem <[email-masked]> wrote:
> 
> In section 3.2:

In addition to Dave's observation that this is an RPC layer document,
not all NFSv4 operations permit an NFS4ERR_WRONGSEC result. Plus, there
is a "MUST" here: we can't say "MUST" and then say the server is allowed
to send either this or that in response.

IMO there is a reasonable distinction between these two server responses.

* WRONGSEC reports an NFS security policy violation -- for instance,
  the user credential doesn't have authorization to access to a file
  handle.

* AUTH_TOOWEAK reports a mismatch between the caller's RPC auth flavor
  and the transport layer security capabilities -- for instance, the
  flavor is AUTH_SYS_ENC but it's being sent on a connection without TLS.

In the case of crossing a filesystem boundary, as long as AUTH_SYS_ENC
is used and the transport connection is protected, the RPC is accepted.
It is then up to the NFSv4 server to authorize that a particular
AUTH_SYS_ENC-flavored caller is permitted to access that filesystem.

In other words, it's perfectly fine for a server to return only
AUTH_SYS_ENC in a SECINFO response, and then the client to try to
access that filesystem with AUTH_SYS. The server should respond
NFS4ERR_WRONGSEC in that case.

However, if the client sends that AUTH_SYS_ENC request to access that
filesystem on a TCP connection with no TLS session, the proper server
response is AUTH_TOOWEAK.

"You can't access that NFS object" versus "you formed the RPC request
incorrectly".

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Mon, 6 Dec 2021 22:34:05 +0000

> to send either this or that in response.
Ok, I can accept this, but see below...
>   the user credential doesn't have authorization to access to a file
At least at this time, the decision w.r.t. whether or not encryption or
whether or not the client provided a X.509 certificate that verifies is
a NFS security policy decision in the FreeBSD server.
It is done on a per server file system basis using exports (any requirement
for Kerberized access is controlled there, too).

I can see NFS servers having "public" file systems where security is not an
issue and other file systems where security does matter.

>   flavor is AUTH_SYS_ENC but it's being sent on a connection without TLS.
It is the RPC protocol (NFS in our case) that will decide what RPC auth flavors
are acceptable. But they may choose to do so based on file handle and not just
globally for all file handles and all clients.

> AUTH_SYS_ENC-flavored caller is permitted to access that filesystem.
Not on the FreeBSD server, at least as implemented now.

I do not have a problem with always using AUTH_ERR/AUTH_TOOWEAK
to indicate problems with "machine credentials" (or whatever terminology
fits?) vs NFS4ERR_WRONGSEC for problems with "user credentials".
However I do have a problem with the assumption that "machine credential"
requirements are invariant across the RPC protocol.

> NFS4ERR_WRONGSEC in that case.
I think the SECINFO reply should indicate whether or not "peer
authentication" is required, for this client to access this file system.

> "You can't access that NFS object" versus "you formed the RPC request
As you can see, I would have worded this as "You can't access that NFS
object because you formed the RPC request incorrectly".

rick

--
Chuck Lever

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 6 Dec 2021 23:52:44 +0000

Hi Rick-

> On Dec 6, 2021, at 5:34 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:
>> 

AUTH_TOOWEAK is not an NFS-level protocol error, and is
not there to indicate that the NFS server policy does
not support a particular RPC auth flavor.

You have to send an AUTH_SYS_XYZZY-flavored request on a
properly-protected channel. This is not an authorization or
policy decision, it's how the protocol maintains security.

Let me try an example.

Sending AUTH_SYS_ENC to a server on an unencrypted connection
is just wrong. The upper layer server (NFS) should not even
see that request because the client sent a message that is
insecure and cannot be trusted.

The point of AUTH_TOOWEAK is to forbid clients from sending
AUTH_SYS_XYZZY requests on unprotected connections. If that
happens, the server is supposed to bat that request down
immediately. The transport layer security has to match the
pseudo-flavor. Nothing more than that is going on.

> requirements are invariant across the RPC protocol.

I'm not talking about machine credentials v. user credentials.

AUTH_SYS_XYZZY carries a traditional AUTH_SYS user and group
credential. It does not make any requirement of the peer
credential that was used to establish the protected channel.

If the FreeBSD server squashes that AUTH_SYS user and group
into something else based on the peer credential, that's
totally independent of whether the client has sent the RPC
Call properly. I don't see how my proposal interferes with
that security policy in any way.

Or, if the FreeBSD server happens to restrict the set of
RPC auth flavors a client may use when sending a SECINFO,
there is a different mechanism for indicating an authorization
failure there. AUTH_TOOWEAK would be returned only if the
client tried to send AUTH_YADA_XYZZY on a channel that did
not match that flavor's transport layer security requirements.

> authentication" is required, for this client to access this file system.

I think my proposal does exactly that.

Say SECINFO returns "AUTH_SYS AUTH_SYS_ENC AUTH_SYS_MPA_ENC".

That means the client can send requests using AUTH_SYS on any
connection, or using AUTH_SYS_ENC on a connection that uses at
least encryption, or using AUTH_SYS_MPA_ENC on a connection that
has done peer authentication and is using encryption.

But using AUTH_SYS_MPA (as long as the client constructs the RPC
request properly and sends it on a properly protected connection)
will get NFS4ERR_WRONGSEC.

That's a contrived example, but the server clearly indicates
which RPC auth flavors can be used to access that filesystem.

If SECINFO returns a list containing only "AUTH_SYS_MPA_ENC",
then the client must use only AUTH_SYS_MPA_ENC RPC credentials
on a connection that has done peer authentication and is using
encryption. Everything else (as long as it is constructed
correctly and sent on a properly protected connection) will get
NFS4ERR_WRONGSEC.

In this case, the server requires peer authentication and
encryption before it will let a client use AUTH_SYS user and
group credentials to access that filesystem. The client forms
those requests by using the AUTH_SYS_MPA_ENC RPC auth flavor,
an AUTH_SYS credential and verifier, and it sends them on any
channel that is peer authenticated and encrypted.

> object because you formed the RPC request incorrectly".

That might describe the end result seen by a user, but the
protocols aren't layered that way, so the specification has
to express the distinction just as I did it.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Tue, 7 Dec 2021 00:56:05 +0000

Chuck Lever III wrote:
Hi Rick-
[stuff snipped]
> is just wrong.
Ok, so now you've completely confused me.
I thought that these pseudo-flavors were meant to be used in the reply
to SECINFO/SECINFO_NONAME (and in the reply to the MNT RPC for NFSv3)
to indicate what the NFS server required.

> The upper layer server (NFS) should not even
So, how does the RPC layer know that AUTH_SYS_ENC is required,
unless the RPC program server (NFS server for our case) tells it
that that is the case?
--> And as I noted before, I think the NFS server will want to look
      at the RPC request before it decides what it requires.
      (per file system via file handle or NFSv4 state operation not
       associated with a file handle)

> pseudo-flavor.
Again, what do you mean by "match the pseudo-flavor"?
Or, put another way, how does the RPC layer know what this
pseudo-flavor is supposed to be?

> Nothing more than that is going on.
It seems that you are assuming some pseudo-flavor will apply to all
NFS server access from all clients.
And, as I already stated, I do not think that is going to be the case.

rick

--
Chuck Lever

---

From: Chuck Lever III <[email-masked]>
Date: Tue, 7 Dec 2021 02:29:10 +0000

Hi Rick-

> On Dec 6, 2021, at 7:56 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:
> Hi Rick-
> [stuff snipped]
>> Let me try an example.
>> 

Yes, they are exactly for that purpose. Those procedures return
a result that contains a list of RPC auth flavors (and for SECINFO,
there is also some extra metadata that goes along with each GSS-
related list entry).

But then the client has to use those pseudo-flavors properly.
There has to be some mechanism at the RPC layer, just as there is
with GSS pseudo-flavors, that makes the new pseudo-flavors secure.
Listing them in SECINFO would be pointless if the RPC protocol
can't enforce the basic security requirements of each pseudo-flavor.

So, the spec has to explain how the client forms requests with
these pseudo-flavors, how the server verifies that the client has
met the pseudo-flavor's security requirements, and what to do if
the client hasn't met those requirements.

Only after all that is said and done can the NFS server accept
and trust an RPC Call using one of these new pseudo-flavors
and decide whether it wants to authorize the request.

The fundamental purpose of the new pseudoflavors is to ensure that
if the client presents AUTH_SYS user and group credentials, it is
doing so on a protected channel whenever the server requires that
level of security.

If the server doesn't care, it can still add plain old AUTH_SYS
to the flavor list, and the client can send AUTH_SYS credentials
on any channel it likes.

> unless the RPC program server (NFS server for our case) tells it

Consider how Kerberos 5 works today. The RPC layer doesn't know
if the local security policy requires GSS. It knows only how to
ensure a message is sent with integrity. When an integrity-
protected RPC message gets to the NFS layer, that layer knows
the message was transmitted correctly, and then decides whether
it accepts requests using that security level (and replies
WRONGSEC if not).

I'm not adding anything new here except the ability to convey
an AUTH_SYS user and group credential and ensure that it was
sent from a trusted client over an encrypted channel.

>      at the RPC request before it decides what it requires.

I don't understand this remark. The RPC layer has to parse the
incoming network bytes to ensure that they form a sensible message
before it passes the message along to the NFS server, who then
applies appropriate policy to determine whether that user and
client are permitted to use the filehandle that the operation is
bearing.

XDR decoding and security checking come first, right?

> pseudo-flavor is supposed to be?

The pseudo-flavor value is placed in the RPC header, just like
with GSS flavors. RFC 5531 Section 8.2 defines this part of
the RPC header:

enum auth_flavor {
	AUTH_NONE	= 0,
	AUTH_SYS	= 1,
	AUTH_SHORT	= 2,
	AUTH_DH		= 3,
	RPCSEC_GSS	= 6
	/* and more to be defined */
};

struct opaque_auth {
	auth_flavor	flavor;
	opaque		body<400>;
};

We're adding additional items to the auth_flavor enum.

To send an AUTH_SYS_ENC request, the flavor field of the
opaque_auth structure would contain a value to be assigned
by IANA, let's say 400001, and the body field would contain
this structure:

struct authsys_parms {
	unsigned int	stamp;
	string		machinename<255>;
	unsigned int	uid;
	unsigned int	gid;
	unsigned int	gids<16>;
};

This is the same structure as AUTH_SYS. But the pseudo-flavor
would require that the receiving end verify that this message
is arriving via an encrypted transport channel.

In this way, when SECINFO tells a client "I want AUTH_SYS_ENC",
the RPC layer can guarantee for the NFS server that the RPC
message was delivered on an encrypted transport. If it wasn't,
the RPC layer rejects the message with AUTH_TOOWEAK.

So if the client sends an AUTH_SYS_ENC request on a plain TCP
connection with no transport layer security, the RPC layer on
the server can see immediately that the pseudo-flavor's
security requirements have not been met.

> And, as I already stated, I do not think that is going to be the case.

I don't really understand this remark, sorry.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 7 Dec 2021 06:30:37 -0500

On Mon, Dec 6, 2021, 9:29 PM Chuck Lever III <[email-masked]> wrote:

> a result that contains a list of RPC auth flavors .

A list of flavors and pseudo-flavors.

(and for SECINFO,
> can't enforce the basic security requirements of each pseudo-flavor.

I disagree.  The NFS server can determine when its policy is violated and
return WRONGSEC if it is.

It is the same with the GSS pseudo-flavors.  They don't appear in the
flavor field of any request and RPC does not have an enforcement role since
it is unaware of the server's policy which may differ based on the location
in the namespace.

> these pseudo-flavors,

I don't think client should form requests with pseudo-flavors but only with
the already defined flavors.

how the server verifies that the client has
> and decide whether it wants to authorize the request.

I don't think that's necessary.

> doing so on a protected channel whenever the server requires that

That would be the purpose of turning these pseudo-flavors into flavors.

I think the client should be allowed (by RPC) of sending an RPC request
using the  AUTH_SYS *flavor* and with the server free to reject it using
WRONGSEC.

> to the flavor list, and the client can send AUTH_SYS credentials

it can but it SHOULD NOT.

> XDR decoding and security checking come first, right?

I'm not sure what you mean by "security checking". For AUTH_SYS, there is
not much checking to be done at the RPC layer.

> the RPC layer rejects the message with AUTH_TOOWEAK.

I don't see the value of moving this logic to the RPC layer, effectively
turning these pseudo-flavors into flavors.

> security requirements have not been met.

I think it should be rejected no matter what channel is used, since
AUTH_SYS_ENC  is *not a flavor*.

---

From: Chuck Lever III <[email-masked]>
Date: Tue, 7 Dec 2021 15:58:46 +0000

On Dec 7, 2021, at 6:30 AM, David Noveck <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Dec 6, 2021, 9:29 PM Chuck Lever III <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rick-

> On Dec 6, 2021, at 7:56 PM, Rick Macklem <[email-masked]<mailto:[email-masked]>> wrote:
>
> Chuck Lever III wrote:
> Hi Rick-
> [stuff snipped]
>> Let me try an example.
>>

(and for SECINFO,

I disagree.  The NFS server can determine when its policy is violated and return WRONGSEC if it is.

It is the same with the GSS pseudo-flavors.  They don't appear in the flavor field of any request and RPC does not have an enforcement role since it is unaware of the server's policy which may differ based on the location in the namespace.

I don't think client should form requests with pseudo-flavors but only with the already defined flavors.

I think the client should be allowed (by RPC) of sending an RPC request using the  AUTH_SYS flavor and with the server free to reject it using WRONGSEC.

My proposal was an attempt to address concerns about the security of the RPC AUTH_SYS/AUTH_NONE flavors, and to address those concerns for all consumers of AUTH_SYS and AUTH_NONE in a consistent way (just as we approached the use of TLS).

The RPC layer is the common element here, it's where we implemented RPC-with-TLS. For RPCSEC_GSS (ie, the existing model we have of a secure auth flavor) the RPC layer is responsible for establishing trust for all RPC consumers. When a malformed or corrupted request is received, the historical model is that the RPC layer rejects that request and returns an appropriate auth_stat to the client.

Apparently you have a somewhat different concern that I still do not recognize.

OK, then. We stick with the idea of defining pseudo-flavor values used only for MNT and SECINFO. The RPC layer continues to use only AUTH_SYS and AUTH_NONE, and does no new checking of these traditional auth flavors.

The NFS layer on the server must still use channel binding to assess whether an AUTH_SYS-flavored RPC is being received on a transport that matches its security policy (as represented by the new pseudo-flavors), and if not, it returns NFS4ERR_WRONGSEC for NFSv4, and NFS3ERR_ACCES for NFSv2/3.

Thoughts, opinions?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 7 Dec 2021 11:44:13 -0500

I think this can help me simplify section 15 in security-04, getting it
down to one page.

The only open issue is a way to indicate you want mpa with gss.  The
obvious solution, to do AUTH_GSS_MPA in the same way as you do AUTH_SYS_MPA
is blocked by the fact that only RPCSEC_GSS has non-void switch contents.
 Since MNT doesn't need this, I can address this for v4 specifically, in
the v4 security document.

On Tue, Dec 7, 2021, 10:58 AM Chuck Lever III <[email-masked]>
wrote:

>
>
> On Dec 7, 2021, at 6:30 AM, David Noveck <[email-masked]> wrote:
>
>
>
> My proposal was an attempt to address concerns about the security of the
> RPC AUTH_SYS/AUTH_NONE flavors, and to address those concerns for all
> consumers of AUTH_SYS and AUTH_NONE in a consistent way (just as we
> approached the use of TLS).
>
> The RPC layer is the common element here, it's where we implemented
> RPC-with-TLS. For RPCSEC_GSS (ie, the existing model we have of a secure
> auth flavor) the RPC layer is responsible for establishing trust for all
> RPC consumers. When a malformed or corrupted request is received, the
> historical model is that the RPC layer rejects that request and returns an
> appropriate auth_stat to the client.
>
> OK, then. We stick with the idea of defining pseudo-flavor values used
> only for MNT and SECINFO. The RPC layer continues to use only AUTH_SYS and
> AUTH_NONE, and does no new checking of these traditional auth flavors.
>
> The NFS layer on the server must still use channel binding to assess
> whether an AUTH_SYS-flavored RPC is being received on a transport that
> matches its security policy (as represented by the new pseudo-flavors), and
> if not, it returns NFS4ERR_WRONGSEC for NFSv4, and NFS3ERR_ACCES for
> NFSv2/3.
>
> Thoughts, opinions?
>
> --
> Chuck Lever
>
>
>
>

---

From: Rick Macklem <[email-masked]>
Date: Tue, 7 Dec 2021 16:47:15 +0000

>>I disagree.  The NFS server can determine when its policy is violated and return WRONGSEC if it is.
Yes. This is what  the FreeBSD NFS server currently does.
The RPC layer tags each received request with whether or not it was received on an encrypted
channel )whether or not TLS was used) and whether or not that channel was peer authenticated (client
provided X.509 certificate that verified during TLS handshake).

Then the nfsd decides if the request can be performed.
Here's an example (assume the server has two file systems: /data and /data/private):

The exports file looks like this:
/data -sec=sys -network 192.168.1.0 -mask 255.255.255.0
/data -sec=sys -tlscert
/data/private -sec=sys -tlscert -network 192.168.1.0 -mask 255.255.255.0
V4: /data -sec=sys

The above says that /data can be mounted without using TLS on the local lan,
but TLS and peer authentication must be done for clients outside of the local lan.
All clients need to use TLS and peer authentication to access /data/private.

If an RPC request that is not tagged TLS and peer authenticated tries to access
/data/private (except in the ways specified by RFC5661 Sec. 2.6.3.1), NFS4ERR_WRONGSEC
is replied. As described in RFC5661 Sec. 2.6.3.1, Secinfo/SecInfo_No_Name can be used to
acquire the pseudo-flavors, which could return the appropriate one from your list (someday,
but not yet). See below w.r.t. what it does for NFSv3 clients.

I think being able to do this on a per-file-system and per-client-ip basis is useful since,
although using encryption is nice, there will often be a significant overhead in doing so.
(For my test hardware, doing data transfer at 1Gbps wire speed over NFS uses about 40%
 of the CPU for one core for one client connection doing the transfer. I have no offload
 hardware, just AESNI.)

>
>It is the same with the GSS pseudo-flavors.  They don't appear in the flavor field of any request and RPC does not >have an enforcement role since it is unaware of the server's policy which may differ based on the location in the >namespace.
>
>
I agree. The RPC code knows if the channel is encrypted and whether or not peer authentication was
done for the channel. Doing so would require changes to extant RPC code, which just works unchanged
if you use extant flavors.

>>I think the client should be allowed (by RPC) of sending an RPC request using the  AUTH_SYS flavor and with the >>server free to reject it using WRONGSEC.
>>
>My proposal was an attempt to address concerns about the security of the RPC AUTH_SYS/AUTH_NONE flavors, and >to address those concerns for all consumers of AUTH_SYS and AUTH_NONE in a consistent way (just as we >approached the use of TLS).
>
>The RPC layer is the common element here, it's where we implemented RPC-with-TLS. For RPCSEC_GSS (ie, the >existing model we have of a secure auth flavor) the RPC layer is responsible for establishing trust for all RPC >consumers. When a malformed or corrupted request is received, the historical model is that the RPC layer rejects >that request and returns an appropriate auth_stat to the client.
>
>OK, then. We stick with the idea of defining pseudo-flavor values used only for MNT and SECINFO. The RPC layer >continues to use only AUTH_SYS and AUTH_NONE, and does no new checking of these traditional auth flavors.
I think the RPC layer does need to "tag" the requests to indicate whether encryption and or peer authorization
was in use, but that could be considered an implementation detail?

>The NFS layer on the server must still use channel binding to assess whether an AUTH_SYS-flavored RPC is being >received on a transport that matches its security policy (as represented by the new pseudo-flavors), and if not, it >returns NFS4ERR_WRONGSEC for NFSv4, and NFS3ERR_ACCES for NFSv2/3.
For the current FreeBSD NFS server, I have two new auth_stat values defined (I thought this had been
discussed on this list at some point?). I called them:
   AUTH_NEEDS_TLS = 15,
   AUTH_NEEDS_TLS_MUTUAL_HOST = 16,
(It sounds like more generic naming would be preferred.)

Then, for NFSv3, AUTH_ERR with one of the above auth_stat values (instead of AUTH_TOOWEAK)
is returned when the "tags" do not indicate adequate channel binding security.
I think this is preferable to NFS3ERR_ACCES, since the latter refers to user permissions.

rick

Thoughts, opinions?

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Tue, 7 Dec 2021 16:53:57 +0000

Oh, and I forgot to mention the case where all access requires encryption and/or peer authentication.
That case is also handled by AUTH_ERR with one of the new auth_stat values I described at the
end of the previous post, since NFS4ERR_WRONGSEC is not an allowed error reply for ExchangeID.

In other words, AUTH_ERR with a new auth_stat value is the "catch-all" when NFS4ERR_WRONGSEC
cannot be replied.

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Rick Macklem <[email-masked]>
Sent: Tuesday, December 7, 2021 11:47 AM
To: Chuck Lever III; David Noveck
Cc: NFSv4
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt

rick

Thoughts, opinions?

--
Chuck Lever

---

From: Chuck Lever III <[email-masked]>
Date: Tue, 7 Dec 2021 17:25:03 +0000

> On Dec 7, 2021, at 11:47 AM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:
>> 

That sounds like it is a detail that is particular to your implementation. Another approach would be for the NFS server layer to check the channel binding status of the RPC's incoming transport.

> I think this is preferable to NFS3ERR_ACCES, since the latter refers to user permissions.

So for NFSv4, you want the server to return an NFS layer error, but for NFSv3, you'd like the server to return an RPC layer error.

Can you describe how your NFSv3 implementation behaves if an unpermitted GSS pseudo-flavor is used to access an NFS share? Can other implementers describe the behavior of their servers in this case?

> In other words, AUTH_ERR with a new auth_stat value is the "catch-all" when NFS4ERR_WRONGSEC

It sounds like you do indeed want to have some of the RPC layer machinery I describe in rpc-tls-pseudoflavor for NFSv4. Is there precedent that I can model rpc-tls-pseudoflavor after?

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Tue, 7 Dec 2021 21:25:51 +0000

[stuff snipped]
>> Chuck Level II wrote:
>>> The NFS layer on the server must still use channel binding to assess whether an AUTH_SYS-flavored RPC is being >>>received on a transport that matches its security policy (as represented by the new pseudo-flavors), and if not, it >>>returns NFS4ERR_WRONGSEC for NFSv4, and NFS3ERR_ACCES for NFSv2/3.
>So for NFSv4, you want the server to return an NFS layer error, but for NFSv3, you'd like the server to return an RPC >layer error.
Yep. Sun RPC only exists as an underpinning for NFS these days. (I have great difficulty imagining anyone
creating another major protocol on top of it.
Also, sessions threw away any notion of layering between the RPC and NFS.
Since NFSv3 doesn't have a WRONGSEC and NFSv4 restricts it to certain operations, use the RPC
layer error reply as a fallback.
--> If you really want to always use the RPC layer error reply, I don't have a big problem
    with that. I just feel that NFS4ERR_WRONGSEC is the "natural fit" when it can be used and
    I can see clients being triggered to do a SecInfo/SecInfo_No_Name when a NFS4ERR_WRONGSEC
     is received, such as when crossing server mount point boundaries.
     (Fyi, the FreeBSD client just considers NFS4ERR_WRONGSEC an access failure and
      never does SecInfo/SecInfo_No_Name at this time or for the forseeable future,
      so it doesn't much matter to me.)

>Can you describe how your NFSv3 implementation behaves if an unpermitted GSS pseudo-flavor is used to access >an NFS share? Can other implementers describe the behavior of their servers in this case?
AUTH_ERR with auth_stat AUTH_TOOWEAK.

>It sounds like you do indeed want to have some of the RPC layer machinery I describe in rpc-tls-pseudoflavor for >NFSv4. Is there precedent that I can model rpc-tls-pseudoflavor after?
Not sure what you are asking here. All these new auth_stat replies do is give the client a little more
information w.r.t. why the RPC failed.

To be honest, I'm definitely not a security type, but I think some security types might argue
that the server should not provide any "hints" to the client why the access failed.
In other words, they might argue that the correct response is...
- Stop accepting requests on the connection and then silently shut the connection down
  after a few seconds.

rick

--
Chuck Lever

---

From: Chuck Lever III <[email-masked]>
Date: Tue, 7 Dec 2021 21:55:19 +0000

> On Dec 7, 2021, at 4:25 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever III wrote:

Sure, but NFSv3, which is still broadly deployed, doesn't have either SECINFO or sessions. That's why I started with RPC as the common element.

>      so it doesn't much matter to me.)

My plan was that the NFS server would return NFS4ERR_WRONGSEC just as you describe. The AUTH_TOOWEAK error would be returned only if the received RPC message was corrupted. But if we are going with pure pseudo-flavors, the RPC layer won't know from AUTH_SYS_XYZZY. The upper layer (NFS) will have to manufacture and return the AUTH error. I need to check code, but I think that will work for Linux NFSD.

I'll shoot for submitting an -01 by the end of next week that moves closer to what you and Dave have suggested.

> Not sure what you are asking here. All these new auth_stat replies do is give the client a little more information w.r.t. why the RPC failed.

OK, thanks for clarifying that.

I think I'll start with not adding new auth_stat values. New auth_stat values returned to clients that don't support RPC-with-TLS will be a backwards-compatibility problem. AUTH_TOOWEAK will be a placeholder.

We can visit this again as we go along.

--
Chuck Lever