Re: [nfsv4] NFS over TLS for floating clients

[Chuck Lever <[e-mail]>]

Hi Rick-

> On Mar 29, 2020, at 10:16 PM, Rick Macklem <[e-mail]> wrote:
> 
> A case I've coded up that may or may not be allowed by the current draft is:
> - Optionally, if the client presents a certificate to the server that verifies and
>   where the CN is of the form "user@dns_domain", then this "user" is translated
>   to a set of credentials used for all RPCs on the TCP connection instead of
>   what is   provided in the RPC request header. I put "user" in quotes because
>   I think you can argue that this is the identity of the client host and the server
>   chooses to assign credentials to that client identity.
>   (Basically, I'd argue that, for laptops, the line between "user" and "host" is fuzzy
>    and normally one and the same.)
> 
> As for the current draft, it says:
> (end of sec. 4.2)
> In either of these modes, RPC user authentication is not affected by
>   the use of transport layer security.  When a client presents a TLS
>   peer identity to an RPC server, the protocol extension described in
>   the current document provides no way for the server to know whether
>   that identity represents one RPC user on that client, or is shared
>   amongst many RPC users.
> 
> True, although there is the case where there is only one user on the client
> and that is known by the server administrator.
> 
> Therefore, a server implementation must not
>   utilize the remote TLS peer identity for RPC user authentication.
> 
> I would argue that this is a server implementation choice and does not
> affect the protocol.

I don't fully understand this statement, but the protocol described in
draft-ietf-nfsv4-rpc-tls forces this choice to be "does not utilize
the TLS peer identity for RPC user authentication." IMO we cannot
relax this requirement in this protocol, though it can be revisited if
RPC is made to handle user authentication with certificates: I will
be discussing that possibility during our interim meetings in April.

A connection/TLS session uses exactly one pair of certificates for its
entire lifetime: a server cert and a client cert (let's set aside the
"no client cert" case for a moment).

After the TLS session has been established, in general a client is free
to send multiple RPC user identities on that connection. Users have no
association with the certificate the client used to establish that
session.

The certificates here are used to establish secure communication between
two hosts. They are not intended to be used for authenticating RPC user
identities, period.

We do not want to alter RPC user authentication at this time. If using
a certificate to identify an RPC user is something we _do_ want to do,
and we most likely do want to allow it eventually, then that will
require a different set of changes to the RPC protocol, and not just at
the transport layer.


> (in sec. 7.3)
> In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
>   every RPC client should present host authentication material to RPC
>   servers to prove that the client is a known one.  The server can then
>   determine whether the UIDs and GIDs in AUTH_SYS requests from that
>   client can be accepted.
> 
> I would argue this is what the above case does.
> 
> The use of TLS does not enable RPC clients to detect compromise that
>   leads to the impersonation of RPC users.  Also, there continues to be
>   a requirement that the mapping of 32-bit user and group ID values to
>   user identities is the same on both the RPC client and server.
> 
> Doing the above solves/avoids this problem.
> 
> I do feel the above case can be useful (optionally, not always) and I would
> appreciate comments w.r.t. it.
> If others think it is a reasonable approach, it would be nice if the draft allowed
> it, but I can leave it in the FreeBSD code, noting it is "non-RFC conformant".

IMO you should wait until the RPC protocol has a purpose-built mechanism
for user authentication via certificates, then implement a client that
presents the same certificate to establish a TLS session as it does to
identify its only user.

However, you can probably make your current proposed implementation a
little more future proof:

An NFS client should use AUTH_NONE for your use case, since the NFS
server ignores the client-provided RPC user identities. Maybe the server
should enforce the use of AUTH_NONE. That would possibly navigate around
the restriction stated in rpc-tls that the server cannot use the client's
TLS identity to make RPC user-specific authentication and authorization
decisions.

Add the following per-export controls on your NFS server implementation:

- A control requiring a TLS connection to access the shared filesystem.

- A control requiring the client to present a certificate to establish
a TLS session (ie, the server should prevent TLS with anonymous clients).

- A control that enables mapping between the client's TLS identity to a
particular user identity that already exists on your server. The mapping
should happen via NFSv4 id-mapping. Then the server can map both user-
specific or client certificates to particular local user identities.

It's significantly more secure if the server is pre-configured with
known user/client identities. Then, if the server does not recognize a
client's certificate, it rejects the attempt to establish a TLS
session.


--
Chuck Lever