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 5:34 PM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever III wrote:
>> 
>> Hi Rick, thanks for taking a look.
>> 
>>> On Dec 5, 2021, at 9:06 PM, Rick Macklem <[e-mail]> wrote:
>>> 
>>> 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?
>> 
>> 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.
> Ok, I can accept this, but see below...
>> 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.
> 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.
> 
>> * 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.
> 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_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.


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

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.


>> 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.
> I think the SECINFO reply should indicate whether or not "peer
> 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.


>> 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".
> As you can see, I would have worded this as "You can't access that NFS
> 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.


> rick
> 
>> rick
>> 
>> 
>> ________________________________________
>> From: nfsv4 <[e-mail]> on behalf of Chuck Lever III <[e-mail]>
>> 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 [e-mail]
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: [e-mail]
>>> 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" <[e-mail]>, "Chuck Lever" <[e-mail]>
>>> 
>>> 
>>> 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
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
> 
> --
> Chuck Lever

--
Chuck Lever