Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

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,

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

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

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

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

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

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

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

> --> FreeBSD has for a long time had a "-mapall" export option which
>       is similar to root squash, but happens for all uids. However this
>       doesn't work for this case, since exports are based on client IP
>       address.
>
>       This is similar to that, but using the information in the client's
>        machine certificate to decide what to squash the AUTH_SYS
>        credentials to.
>
> This limits the damage done if a laptop is compromised to that
> which can be done by that user (aka rmacklem) against the NFS server.
>
> Now, how does this compare with "sec=krb5" for this laptop case?
> --> Well, if the device is compromised such that a "trojan horse" can capture
>       the latop key's passphrase can the same be done on it for login/kinit
>       to capture the Kerberos password for the user principal the laptop's
>       user uses?
>       I think so.
>       --> If the user principal's password is compromised, then access to the
>              server as that user is acquired.
>
>        Also, this would require the KDC be accessible from "the world", which
>        sounds pretty scary to me.
>
> This seems comparable to the mobile device's certificate being compromised,
> which allows NFS server access as the user in the otherName component of
> subjectAltName.
> Seems like the level of risk is about the same?
>
> For Kerberos, the user's password can be changed to stop the compromised
> access. For the certificate being compromised, the site local CA admin. can
> put the certificate in the CRL for the site to stop the compromised access.
>
> Anyhow, I am about as far from a security guy as you can get, so I may be way
> off w,r.t the above.
>
> Also, the NFS over TLS code in FreeBSD is still considered "test" (it uses
> OpenSSL3, which is alpha test at this time), so I can easily change things
> if others have a better idea.
>
> I will document this as "non-RFC conformant" if that appears to be the case.

I'm having trouble remembering exactly why we decided on MUST NOT
there. 2020 has been a long year.


--
Chuck Lever





_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4