[nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

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.

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

Typical filtering at the NFS server via client IP address obviously cannot work, so
what can be done?

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

rick