Re: [nfsv4] NFS over TLS for floating clients

[Chuck Lever <[e-mail]>]

> On Apr 1, 2020, at 4:48 PM, Chuck Lever <[e-mail]> wrote:
> 
> 
> 
>> On Apr 1, 2020, at 4:36 PM, Rick Macklem <[e-mail]> wrote:
>> 
>> Chuck Lever wrote:
>>> 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."
>> Btw, when I said "does not affect the protocol" I was referring to what goes
>> on the wire. The only thing that changes in the content of the client's certificate,
>> which is not covered by this document (except for where the DNS name goes).
>> --> Actually I am surprised that Ben and others accept putting the DNS name in
>>     the CN field of subjectName and aren't insisting it be in the DNS field
>>     of the subjectAltName. (I, personally, don't care.)
>> 
>>> 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.
>>> 
>> As you'll see below, I am not talking about user authentication, I am
>> referring to what credentials are being used for an RPC, which I believe
>> is a server configuration issue.
>> FreeBSD NFS server have had a "-mapall" option which says "use these
>> credentials for all RPCs for a very long time (since the 1980s, I think?).
>> 
>>> 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.
>> Yes, I understand all of the above.
>> 
>>> 
>>> 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.
>> Yes, I understand that you do not want to address user authentication, which
>> the draft clearly defines as the credentials in the RPC request header.
>> 
>> Another way to put what I am doing is:
>> - The server derives "machine credentials" from the client's certificate.
>> The server then chooses via server configuration what RPCs are performed
>> using these machine credentials instead of the user credentials derived from
>> the RPC request header.
>> 
>> I know that Sun RPC has never had the concept of machine credentials and
>> that is one reason why it has not been a great fit for NFSv4, since NFSv4 does
>> use machine credentials.
>> - The workaround has been for the NFSv4 server to define the user credentials
>>  used for the first ExchangeID (SetClientID) operation as the machine credentials
>>  that must be used.
>>  For AUTH_SYS, this is typically the infamous uid == 0.
>>  For RPCSEC_GSS (Kerberos mechanism), it has typically required:
>>  - host based principal being created on the KDC.
>>  - keytab entry for this principal being created.
>>  - this keytab entry being copied to the client via some secure method.
>> (I won't bother to mention what credentials actually get used for callbacks.
>> I'll admit I don't even understand how to do callback user credentials via
>> RPCSEC_GSS. I think most just use AUTH_SYS with uid == 0 and clients mostly
>> ignore the RPC request credentials for callbacks?)
>> 
>> It might make sense to look at using client certificates to create machine credentials
>> in the future?
>> 
>> I am fine with this not being allowed by this spec. I will simply document that.
>> However, you could state:
>> Creation of machine credentials from peer certificates is out of the scope of
>> this document.
>> 
>>> 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.
>> I have no idea what you are considering, but if it is along the lines of
>> clients providing separate X509 certificates for each user,
>> I think that would require:
>> - generation of certificates for every user
>> - copying these certificates into a database on each client in some secure
>> manner.
>> - You almost have to generate a separate certificate for each user for each
>>    client (ie. #clients * #users).
>> --> Too much administrative overhead, in my opinion.
>> It is easier (and a better fit, imho) to just use Kerberos for this case and it
>> is already implemented and works.
>> 
>> However, I do think that a certificate is a good fit for machine credentials,
>> which is not a good fit for Kerberos (the above exercise of host based principal...).
>> Having a way for clients to do a Kerberos NFSv4 mount without the host based
>> principal in a keytab on the client, would make Kerberized NFSv4 easier, I think?
>> 
>>>> (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.
>> As above, I'm not convinced this is practical.
>> 
>>> 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.
>> I don't believe extant NFSv4 clients can be configured to use AUTH_NONE
>> for all RPCs.
> 
> Really? mount with sec=null/none does not work?

Duh. sec= does not control the authentication principal or flavor
of lease management operations. :-)


>> What I am doing should work with an extant NFSv4 client once
>> it has RPC-over-TLS support (I'm assuming client's will consider the X509
>> certificate is an opaque blob that is only used for the TLS handshake).
>> 
>>> Add the following per-export controls on your NFS server implementation:
>>> 
>>> - A control requiring a TLS connection to access the shared filesystem.
>> Yes, this exists in my implementation as the export option "-tls".
>> 
>>> - A control requiring the client to present a certificate to establish
>>> a TLS session (ie, the server should prevent TLS with anonymous clients).
>> Yes, this exists in my implementation as the export option "-tlscert".
>> 
>>> - 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.
>> As above, I do not think user specific certificates is practical.
>> (Of course, feel free to prove me wrong;-)
> 
> For the moment, I'll just say that you might be misreading what I
> wrote here: take out the "user-specific" and just make it "the server
> maps the client-presented transport credential to a local user
> identity on the server." That might be close to what you've already
> implemented.
> 
> I agree that the preference in multi-user environments is a certificate
> for the machine and Kerberos principals for user identities, for exactly
> the reasons you stated.
> 
> 
>>> 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.
>> I also have the "-h" option on the server side TLS handshake daemon,
>> which states that the client's certificate must have a DNS name that
>> matches the reverse DNS name for the client's IP address.
>> --> This is on the daemon and not in exports, since for this case,
>>     the IP address presented by the client is not trusted and, as such,
>>     the exports file cannot be applied to it until it has passed this
>>     requirement. (With "-h" it follows RFC 6125 style verification, but
>>     for on the server for a client certificate and not the other way around.)
>> 
>> rick
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever