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

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

Hi Rick-

> On Dec 6, 2021, at 7:56 PM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever III wrote:
> Hi Rick-
> [stuff snipped]
>> Let me try an example.
>> 
>> Sending AUTH_SYS_ENC to a server on an unencrypted connection
>> 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.

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.


>> The upper layer server (NFS) should not even
>> see that request because the client sent a message that is
>> insecure and cannot be trusted.
> 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?

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.


> --> And as I noted before, I think the NFS server will want to look
>      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?


>      (per file system via file handle or NFSv4 state operation not
>       associated with a file handle)

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

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.


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

I don't really understand this remark, sorry.


--
Chuck Lever