Re: TLS certificates for NFS-over-TLS floating client

On Wed, Mar 04, 2020 at 03:15:48AM +0000, Rick Macklem wrote:
> Hi,
> 
> I am slowly trying to understand TLS certificates and am trying to figure
> out how to do the following:
> -> For an /etc/exports file with...
> /home -tls -network 192.168.1.0 -mask 255.255.255.0
> /home -tlscert
> 
> This syntax isn't implemented yet, but the thinking is that clients on the
> 192.168.1 subnet would use TLS, but would not require a certificate.
> For access from anywhere else, the client(s) would be required to have a
> certificate.

My gut reaction: that doesn't sound like a good idea.
Trusting the local network to be secure is pretty risky, in general.

> A typical client mounting from outside of the subnet might be my laptop,
> which is using wifi and has no fixed IP/DNS name.
> --> How do you create a certificate that the laptop can use, which the NFS
>        server can trust enough to allow the mount?

You can give your laptop a certificate for an arbitrary name, provided that
the NFS server knows to "validate" that name in an appropriate fashion.  (I
don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.)

> My thinking is that a "secret" value can be put in the certificate that the NFS
> server can check for.
> The simplest way would be a fairly long list of random characters in the
> organizationName and/or organizationUnitName field(s) of the subject name.
> Alternately, it could be a newly defined extension for X509v3, I think?

It would be better to just make a site-local CA and trust everything it
issues (which, admittedly, is not the greatest option itself.)

> Now, I'm not sure, but I don't think this certificate can be created via
> a trust authority such that it would "verify". However, the server can
> look for the "secret" in the certificate and allow the mount based on that.
> 
> Does this sound reasonable?

I'm not sure what goal you're trying to achieve by this "security through
obscurity".

> Also, even if the NFS client/server have fixed IP addresses with well known
> DNS names, it isn't obvious to me how signed certificates can be acquired
> for them?
> (Lets Encrypt expects the Acme protocol to work and that seems to be
>  web site/http specific?)

RFC 8738 specifies the ACME protocol for validating IP addresses.

-Ben