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

John-Mark Gurney wrote:
>Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +0000:
>> 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
>
>Are you looking at implementing draft-cel-nfsv4-rpc-tls?
Yes. The 2 week out of date (I can only do commits once in a while these days) can
be found in FreeBSD's subversion under base/projects/nfs-over-tls.

>> 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.
>>
>> 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?
>> 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?
>>
>> 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?
>
>Without a problem statement or what you're trying to accomplish, it's
>hard to say if it is.
The problem I was/am trying to solve was a way for NFS clients without a
fixed IP/DNS name could have a certificate to allow access to the NFS server.
As suggested by others, having a site local CA created by the NFS admin. seemed
to be the best solution. The server can verify that the certificate was issued by
the local CA. Unfortunately, if the client is compromised and the certificate is copied
to another client, that client would gain access.
--> I've thought of having the client keep the certificate encrypted in a file and
       require the "user" of the client type in a passphrase to unencrypt the certificate
       so that it can be used by the daemon in the client that handles the client side
       of the TLS handshake, but I have not implemented this.
       --> This would at least subvert the simple case of the certificate file being copied
              to a different client and being used to mount the NFS server, but if the
              client is compromised, then the passphrase could be captured and...

>> 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?)
>
>There is DNS challenges that can be used.  I use them to obtain certs
>for SMTP and SIP servers...  using nsupdate, this is relatively easy to
>automate pushing the challenges to a DNS server, and I now use DNS
>challenges for everything, including https.
Since my internet connection is a single dynamically assigned IP from the phone
company, I doubt this would work for me (which I why I say I don't know how
to do this). I suspect there are ways and it would be nice if you could document
this, so I can put it in a howto document.
- An actual example using the nsupdate command would be nice.
Thanks, rick

> Thanks for any help with this, rick

Let me know if you'd like to hop on a call about this.

--
  John-Mark Gurney                              Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."