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

Benjamin Kaduk wrote:
>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.
Yep, I thought that the stuff in the certificate was encrypted in a way that the
client couldn't see it. I now see that isn't the case.

>Trusting the local network to be secure is pretty risky, in general.
Well, for my personal case, the subnet has a few machines plugged into it
around my desk and wifi isn't enabled on the modem/NAT gateway, so
I'm fairly confident the local machines are ok.
To be honest, I don't need encryption on the wire, but since the phone
company uses Huawei technology, I could see some wanting the data
encrypted on the wire, if the data were sensitive.
This case is meant to be easy to do, since the clients don't have to have
certificates.

I am trying to provide whatever people might need/want when I implement
this. The rest is obviously up to them.

>> 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.)
As you note below, creating a site local CA is probably appropriate and the
server should be able to check that the certificates were signed by this.
(I haven't quite figured out how to do this yet. I think I've created the CA
and used to sign a client certificate, but haven't yet gotten the server daemon
to verify it. (Playing with SSL_set_verify_locations() to try to get it to work.;-)

>> 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.)
I had thought this would be too much work, but it seems fairly straightforward,
so this is what I am now working on.

>> 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".
Yes. I now see it is the CA stuff that can stay secret.

>> 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.
I had looked at an older RFC, where it seemed to be web site specific.
Since none of my stuff has fixed well known DNS names, I'm not going to
worry about using an established CA for now.

Thanks to everyone for their comments.
I may respond to some of the other posts, but I'm figuring things out for now.

rick

-Ben