Date: Mon, 23 Mar 2020 23:53:34 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Alexander Leidinger <Alexander@leidinger.net>, John-Mark Gurney <jmg@funkthat.com> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <QB1PR01MB36491D0C0306EEB894E37EADDDF00@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote:=0A=
John-Mark Gurney <jmg@funkthat.com> wrote:=0A=
>>Rick Macklem wrote:=0A=
>>> to be the best solution. The server can verify that the certificate=A0 =
=0A=
>>> was issued by=0A=
>>> the local CA. Unfortunately, if the client is compromised and the=A0 =
=0A=
>>> certificate is copied=0A=
>>> to another client, that client would gain access.=0A=
>>=0A=
>> This is why CRLs/OSCP is necessary, but there isn't anything you can do=
=0A=
>> to prevent that.=A0 This is both a better situation than what we have=0A=
>> today (no auth/confidentiality), and if you tie the cert to an IP, it's=
=0A=
>> of limited use, and better than today...=0A=
>=0A=
>There are multiple ways to handle that:=0A=
>=A0 - First of all, you can just validate based upon "cert is signed by=A0=
=0A=
>trusted CA".=0A=
>=A0 - Then you can require that the CN matches the hostname and the=A0 =0A=
>reverse lookup matches.=0A=
>=A0 - Or (similar to browsers today) you can ignore the CN and require=A0 =
=0A=
>that the hostnames of the client matches one of the subject=A0 =0A=
>alternative name (SAN) entries (requires reverse DNS lookup to work=A0 =0A=
>and match).=0A=
At this point, I have three variants in the code (strictest to less strict)=
:=0A=
1 - A "-h" command line option on the server handshake daemon (called rpctl=
ssd).=0A=
This requires that all clients have=0A=
certificates that validate and have the FQDN acquired via reverse DNS =
of=0A=
the IP address of the client for the TCP connection (getnameinfo(NI_NA=
MEREQD))=0A=
in either the subjectAltName or CommonName. (I call X509_check_host()=
=0A=
and this is what I understand it checks.)=0A=
--> This case implies that the NFS server admin. does not "trust" the=
=0A=
client's IP address enough to apply exports(5) line(s)to it to =
decide to=0A=
allow the client to do an NFS mount.=0A=
(An NFS server *might* be willing to allow client(s) to mount via any =
IP address=0A=
for the #2 case below and not use this option.)=0A=
2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indica=
te=0A=
if the client provided a certificate and whether or not it verified.=
=0A=
Then the "-tlscert" option on the appropriate exports(5) line(s) =0A=
indicates that the client must have provided a certificate that verifi=
ed.=0A=
--> For this case (and #3), the server admin. is willing to "trust" th=
e client's=0A=
IP address enough to apply exports(5) rules to it.=0A=
--> This is the case where a floating (no fixed IP) laptop could have =
a=0A=
certificate signed by a site local CA.=0A=
3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s).=0A=
In this case, the client must use TLS so that data is encrypted on the=
wire,=0A=
but does not need to have a certificate.=0A=
--> The NFS server admin. "trusts" the client IP address enough that t=
hey=0A=
are willing to allow the client to mount based on that IP, but w=
ants the=0A=
data to be encrypted on the wire.=0A=
- Avoids the bother of generating certificates for the client(s)=
.=0A=
=0A=
A part of this (as discussed in the IETF draft) is to make this easy enough=
to=0A=
use that it does get used. (sec=3Dkrb5p achieves both user authentication a=
nd=0A=
data encryption on the wire, but does not get widely used, due to the need=
=0A=
to run a KDC, etc).=0A=
=0A=
Comments on the above options is welcome, since this does need to be=0A=
reviewed by users.=0A=
=0A=
rick=0A=
=0A=
=0A=
At this point you prevent simple cert theft as additionally you=A0 =0A=
require that someone also has to be able to modify the DNS (or NFS=A0 =0A=
server hosts file, but then he probably can already add an additional=A0 =
=0A=
cert to the truststore of nfsd).=0A=
=0A=
Additional protection is possible by also adding the IP to the SAN. I=A0 =
=0A=
haven't put an effort into evaluating if either IP or DNS is enough=A0 =0A=
from a security point of view, or if it makes a difference if the "IP=A0 =
=0A=
in SAN" case has an additional benefit in terms of security if it is=A0 =0A=
in addition to the reverse DNS requirement.=0A=
=0A=
Yes this makes it more inconvenient to change the IP of a host, but if=A0 =
=0A=
all the policy possibilities are up to the admin to configure (e.g.=A0 =0A=
"cert is signed by trusted CA" as a default, and all the other=A0 =0A=
possibilities as an option for nfsd), it is up to the admin and the=A0 =0A=
security requirement.=0A=
=0A=
In general, all the possibilities are can either be distinct, or=A0 =0A=
accumulative. There is also the possibility that you do not go with=A0 =0A=
any CA but configure X self-signed certs for X clients as being=A0 =0A=
trusted and the cert of the client needs to be an exact match with one=A0 =
=0A=
of the X self-signed certs in the truststore.=0A=
=0A=
Whatever the policy(/ies) is/are in nfsd, I suggest to make it=A0 =0A=
explicit in the docs what is required and what is checked for each=A0 =0A=
policy. And even if it may be obvious for you Rick, please also print=A0 =
=0A=
out why a client was rejected. Unfortunately I've seen a lot of cases=A0 =
=0A=
where the error is a simple/frustrating "certificate rejected", but no=A0 =
=0A=
info which part of the certificate check failed.=0A=
=0A=
Bye,=0A=
Alexander.=0A=
-- =0A=
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=0A=
http://www.FreeBSD.org=A0=A0=A0 netchild@FreeBSD.org=A0 : PGP 0x8F31830F9F2=
772BF=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB36491D0C0306EEB894E37EADDDF00>