Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

Hi Rick!

> 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?
- If it adds sufficient value, can it be made interoperable?

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.

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.


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

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

In addition:

Is TLS identity squashing going to cause interoperability problems
or loss of security in environments that don't support it?

What is our thinking about how certificates might be used to handle
RPC user authentication? Will TLS identity squashing conflict with
that future?


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