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

So ok, it's good to code to RFCs.  OTOH, state actors are a thing now.
Alice & Bob's protocols need to be perfect.  State actors watch for
mistakes.

Here I commit heresy, by A) top posting, and B) by just saying, why
not make it easy, first, to tunnel NFSv4 sessions through
e.g. net/wireguard or sysutils/spiped?  NFS is point to point.
Security infrastructure that actually works understands the shared
secret model.

Not going to argue further. I'm a grateful letsencrypt consumer.
Rick is a hero for his NFS work.  I use his code every day.

Best,
Russell

On 2020-03-19 16:41, Rick Macklem wrote:
> 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." 
> _______________________________________________ 
> freebsd-current_at_freebsd.org mailing list 
> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
> unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"
>