Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

> On Dec 15, 2020, at 10:54 AM, Rick Macklem <[e-mail]> wrote:
> 
> Oops. Here's a slightly updated reply with some typos/missing words added.
> 
> 
> ________________________________________
> From: nfsv4 <[e-mail]> on behalf of Rick Macklem <[e-mail]>
> Sent: Monday, December 14, 2020 9:46 PM
> To: Chuck Lever
> Cc: [e-mail]
> Subject: Re: [nfsv4] NFS over TLS for laptops
> 
> Chuck Level wrote:
>> Hi Rick!
> Hi Chuck
>> On Dec 12, 2020, at 7:02 PM, Rick Macklem <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> David Noveck emailed me w.r.t talking about this at a future meeting.
>>> This sounds rather scary to me, so I figured I'd post here and then, if
>>> others want me to, I can try to attend a "virtual meeting".
>>> First off, the disclaimer that I am neither a security guy nor TLS guy.
>> 
>> Disclaimer: I'm also not really much of either. The goal of
>> this exercise would to get help from real experts to understand:
>> 
>> - Your use case and threat model
>> - Is your proposed solution secure?
> Is anything secure?;-)
> It is definitely more secure than AUTH_SYS or a TLS session where
> the client does not present a verifiable certificate.
> 
> As noted, with "TLS squashing" I think it is about the same as RPCSEC_GSS
> with Kerberos mechanism. Without "TLS squashing" a malicious client using a
> stolen certificate/key would be able to use AUTH_SYS to authenticate as any user
> and that will not happen when a client uses a "stolen" Kerberos TGT, making it
> less secure than Kerberos.
> 
> Another area that can make it less secure would be the creation of client
> certificates with long validity durations. A Kerberos TGT is typically valid
> for 24hrs, whereas a X.509 certificate is typically 30days or more.
> Of course, the validity duration can be set to any duration for both cases.
> 
>> - If it adds sufficient value, can it be made interoperable?
> For the client, I do not think there is going to be interoperability issues.
> The FreeBSD client side TLS handshake daemon (I call it rpc.tlsclntd) and
> I suspect most others simply handles the client certificate as an opaque blob
> that it presents to the server during TLS handshake.
> 
> If there are standardized ways for the server to handle the  client certificate's
> information (subjectAltName->otherName for my use case), then the same
> client certificate could be used against multiple server implementations,

That's the interoperability bit I'm concerned about: What goes
in the certs and how clients and servers are expected to
interpret those blobs.


>> Pursuing this discussion further on the list before the meeting
>> seems prudent.
>> 
>>> The case I was trying to address was mobile device (aka laptop)
>>> mounts to an NFS server using TLS. These devices are assumed to
>>> have two properties:
>>> - Used by a single user.
>>> - Connecting to the Internet from anywhere (ie. no fixed IP nor
>>>  DNS name).
>> 
>> I agree that this is an interesting and common use case, though
>> it might need another bullet or two to characterize fully. More
>> below.
>> 
>>> Typical filtering at the NFS server via client IP address obviously cannot work, so
>>> what can be done?
>> 
>> Our vision is that a TLS-enabled NFS service would be unlikely
>> to filter based on IP address. Such an NFS server either
>> allows the cert presented by a client, or the server tells
>> that client to pound sand. That's part of the TLS handshake.
> Btw, it's a little off topic, but I do think there is a use case for TLS,
> where the NFS client does not have a certificate.
> --> Server trusts the client's identity via it's IP host address, but
>      encryption on the wire is desired. For this case, creating
>      certificates for all the clients would seem to be unnecessary
>      overhead, unless "TLS squashing" is desired.
> -->The harder we make deployment of NFS-over-TLS, the less likely
>     it will be adopted.
> Client TLS mounts without certificates is optionally allowed by
> the current FreeBSD implementation.

Agreed, this is absolutely a use case we have in mind. There is
text throughout the document that discusses it.

And in this case, such clients would not be able to present an
otherName. If the server is security-sensitive, it will need
to be responsible for constraining the user identity of requests
from unauthenticated clients. It might map them all to nobody, for
example. 


>> IIRC a client cert don't have to contain a domain name or IP
>> address that matches the network endpoint that presents that
>> cert. Unlike RPC-over-TLS server certs.
> I agree. For FreeBSD's current implementation, this is optional and
> obviously cannot be done for mobile devices.
> 
>>> 1 - The NFS server admin. creates an x509v3 certificate via a site
>>>     local CA for the laptop, which is stored on the laptop.
>>> 
>>>     --> When the laptop mounts the server via TLS, the NFS server
>>>            verifies this certificate acquired during the TLS handshake
>>>            from the laptop.
>>> 
>>> Ok, so at least the server knows that the laptop has a certificate created
>>> by the server admin. How can this be compromised?
>>> --> The trivial case would be the laptop being stolen or similar.
>>>      If the CA admin. creates the private key for the laptop's certificate
>>>      with a passphrase (something like the "-aes256" option on the
>>>       openssl command used to create it), then the user will need to
>>>      enter the correct passphrase before the client side daemon that
>>>      does the TLS handshake can run.
>>>      No daemon-->no handshake-->no TLS.
>>> --> An attacker could still install something like a "trojan horse", that
>>>     would pretend to be the daemon and capture the passphrase
>>>     when the laptop user types it in.
>>> 
>>> Now, for the part that might be considered a violation of the "soon
>>> to be an RFC" draft.
>>> 2 - When the site local CA admin creates the certificate for the laptop,
>>>    put an otherName component in  subjectAltName that looks like:
>>>     1.3.6.1.4.1.2238.1.1;UTF8:[e-mail]
>>> 
>>>     Now. if the daemon that does the TLS handshake on the NFS server
>>>     is started with the "--certuser" option, it will take the
>>>     [e-mail] from the client's certificate and translate
>>>     that to a POSIX <uid, gidlist> credential on the serve in a manner
>>>     analogous to what the mapper daemon (think rpc.imapd) and gssd
>>>     does for a Kerberos user principal.
>>>     --> Strip off @uoguelph.ca as the local domain and then get the
>>>           POSIX credentials for "rmacklem" from the user/group databases.
>>> 
>>> Now, all RPCs done on this TLS/TCP connection use the above POSIX
>>> credentials instead of the contents of any AUTH_SYS credential in the
>>> RPC request header.
>> 
>> Here you want to introduce an additional constraint so that the
>> holder of a client certificate may act only as a single user
>> identity on the NFS server. The server itself would force that
>> constraint. For convenience of narrative, I'll refer to this as
>> "TLS identity squashing".
>> 
>> - Kerberos already provides this kind of constriction, but
>> RPC-over-TLS with AUTH_SYS by itself does not.
> Yes, as I noted above.
> 
>> Have we
>> documented this AUTH_SYS limitation somewhere? Would it be
>> non-repudiation or something else?
>> 
>> - Since that client certificate is already unique, otherName isn't
>> a requirement for this constraint to work. The client's identity
>> is supposed to be exposed to the NFS server, which can be
>> configured to constrain that client's activity to a single user.
>> otherName seems to be an administrative convenience (and I think
>> you alluded to that somewhere else).
> Yes. My understanding is that the tuple <issuerName, subjectName>
> should be uniquely assigned to a certificate.
> As such, an NFS server admin. could maintain a database keyed on that
> tuple, which could be used to constrain access in a manner analogous
> to an exports file, but for TLS clients that present certificates during TLS
> handshake.
> --> I think this would be more effort to implement and, more importantly,
>       more effort for a NFS server admin. to maintain.
>       --> What I implemented simply uses the user database that
>              will normally already exist and the same technique as the gssd
>              already uses for Kerberos user principals.

At least for the server implementations I'm familiar with,
I don't see much difference between the current GSS cases and
needing to add server-side per-user information to deal with
TLS identity squashing. The tooling might be a little different,
but in both cases we are adding a user mapping mechanism, and
that means updating a database or directory somewhere.


So I think we agree that AUTH_SYS with TLS has a significant
weakness that leaves NFS-served data content vulnerable if a
client cert is stolen. Thank you for pointing that out!

We likely disagree on whether the client cert should present
the squashed user identity, or whether the server should be
responsible for mapping operations for that user based on a
trusted user mapping database (eg, KDC or LDAP).

Server implementations have had user identity mapping and
squashing capabilities for a very long time, so the latter
approach feels more natural to me.

Further, the server already has to know a priori how to map
user@domain to a UID whether or not it supports RPC-over-TLS.
Otherwise the server has to squash an unknown identity to
something anonymous like nobody.

Is there another benefit to an otherName vs. a server-side
mapping approach that I'm missing?


>> - For NFSv4, there's a separate authentication for SETCLIENTID /
>> EXCHANGE_ID, which must present consistent authentication material
>> across client reboots. Usually that's the client's root user,
>> though that could also be rmacklem in this case. Which is your
>> implementation doing?
> rmacklem. The FreeBSD server implementation will optionally not allow
> non-NULL RPCs to be done from a client without TLS being enabled on
> the TCP connection and that option would always be used for this case.
> --> All compounds, including the EXCHANGE_ID etc will be done as the
>      squashed user.
> Btw, although not widely adopted as far as I am aware, FreeBSD does allow the
> NFSv4 client mount to be done using Kerberos, but where all RPCs including
> EXCHANGE_ID etc use the Kerberos user principal's TGT, avoiding the
> need for a host based credential in a keytab on the client.
> --> rmacklem would do EXCHANGE_ID etc for this case as well.

Sure, just as long as the same "principal" is presented to the
server when the client needs to recover its lease state, that
should work fine.


>> This is an area that might be tackled by
>> an NFSv4-on-TLS document that can in fact require that an NFS
>> server map the client's identity to a particular lease.
> Not sure what you mean here?
> My understanding of the NFSv4 RFCs is that the same user that does
> the EXCHANGE_ID/SET_CLIENT_ID must be used for the others like
> DESTROY_CLIENTID/RENEW.
> 
> --> For 4.0 there is Renew, but for 4.1/4.2 anyone doing Sequence is
>       sufficient. Were you thinking of Renew for 4.0?

So I was thinking of enabling a server to use the client cert instead
of the GSS or AUTH_SYS RPC credentials for authenticating all of
these operations.

Dave Noveck suggested we might add this to the EXCHANGE_ID operation
as a new state_protect_4a value, or simply some additional language
in RFC 5661bis explaining how to use the client certificate with an
existing state_protect_4a value.

More discussion is needed here.


>> In addition:
>> 
>> Is TLS identity squashing going to cause interoperability problems
>> or loss of security in environments that don't support it?
> I suppose there might be confusion caused by one server doing
> all RPCs as "rmacklem" and another doing the RPC as whatever
> uid is in the AUTH_SYS RPC authenticator.
> -->This would be no more so than different servers having different
>      squashing rules in their exports file.
> 
> If an NFS server chooses to trust the client's identity due to its
> presentation of a verifiable certificate but not its IP address/DNS name
> then, without TLS squashing, a stolen client certificate could provide
> cart blanche access to the server (assuming AUTH_SYS).
> This would result in weaker security than with "TLS squashing" and
> also weaker that if the client uses RPCSEC_GSS/Kerberos.

Agreed.


>> What is our thinking about how certificates might be used to handle
>> RPC user authentication?
> --> I posted about this once before and, in my opinion, using more than
>      one certificate per TLS session/TCP connection is not practical.
>      To do so, something like RPCSEC_GSS with X509 mechanism
>       would need to be implemented. The client would need to have
>       a database of certificates for different users. A compromised
>       client system would compromise all those users, etc and so on.
>       --> For this we have Kerberos and it works. Doing RPCSEC_GSS
>             with X509 mechanism would require a lot of implementation work
>             and the result would be less secure and as much effort to manage
>             as using Kerberos, I think.

Agreed, IIRC that was the consensus a year ago.


> --> For a small number of different users (I would be concerned with
>      scaling this to a large numbesr of users), they can simply use
>      separate TLS sessions/TCP connections. Each of these could
>      present a different client certificate during TLS handshake and
>      then "TLS squashing" can be applied to each of them, squashed
>      to the appropriate user.
> 
>> Will TLS identity squashing conflict with that future?
> As above, I think "TLS squashing" would be an appropriate
> mechanism for this.
> 
> rick
> ps: If anyone is interested in the various options I have implemented, you can
>     look at https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Thank you Rick, I'll take a look.

--
Chuck Lever