Date: Wed, 25 Mar 2020 23:50:56 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John-Mark Gurney <jmg@funkthat.com> Cc: Alexander Leidinger <Alexander@leidinger.net>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: TLS certificates for NFS-over-TLS floating client Message-ID: <QB1PR01MB3649B224FC082726F085BA5DDDCE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200325231005.GQ4213@funkthat.com> References: <QB1PR01MB36491D0C0306EEB894E37EADDDF00@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <20200325231005.GQ4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:=0A=
>Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000:=0A=
>> 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=
=0A=
>> >>> was issued by=0A=
>> >>> the local CA. Unfortunately, if the client is compromised and the=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. 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=
=0A=
>> >trusted CA".=0A=
>> >=A0 - Then you can require that the CN matches the hostname and the=0A=
>> >reverse lookup matches.=0A=
>> >=A0 - Or (similar to browsers today) you can ignore the CN and require=
=0A=
>> >that the hostnames of the client matches one of the subject=0A=
>> >alternative name (SAN) entries (requires reverse DNS lookup to work=0A=
>> >and match).=0A=
>> At this point, I have three variants in the code (strictest to less stri=
ct):=0A=
>> 1 - A "-h" command line option on the server handshake daemon (called rp=
ctlssd).=0A=
>> This requires that all clients have=0A=
>> certificates that validate and have the FQDN acquired via reverse D=
NS of=0A=
>> the IP address of the client for the TCP connection (getnameinfo(NI=
_NAMEREQD))=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" t=
he=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 a=
ny 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 ind=
icate=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 ver=
ified.=0A=
>> --> For this case (and #3), the server admin. is willing to "trust"=
the 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 ha=
ve 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 tha=
t they=0A=
>> are willing to allow the client to mount based on that IP, bu=
t wants 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 eno=
ugh to=0A=
>> use that it does get used. (sec=3Dkrb5p achieves both user authenticatio=
n and=0A=
>> data encryption on the wire, but does not get widely used, due to the ne=
ed=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=
>Maybe I'm missing the option where the cert needs to be authenticated,=0A=
>but matching against IP/dns name does not need to be done. Or is this=0A=
>a case of #2. I'm just confused by the first point of #2 in that the=0A=
>server admin is wiling to trust the IP address...=0A=
Yes, that is #2. "trust the IP address" probably wasn't a good way to=0A=
express it. I was simply trying to say "the NFS server admin. is willing to=
=0A=
use the client IP address to select rules via the exports(5) file".=0A=
=0A=
>I'd like to see where CN or other field is freeform/provided by exports=0A=
>entry, and validated to gain access to those resources... i.e. it=0A=
>doesn't matter what IP or DNS name the client is, it's based solely on=0A=
>the certificate. This would allow roaming users.. This maybe be=0A=
>addressed by #2 point 2, but it isn't clear in your description that=0A=
>it isn't dns tied or something else...=0A=
Yes, for #2 the daemon only validates the certificate (actually uses the op=
enssl=0A=
default verification library function). It does not filter the certificate'=
s CN or=0A=
other fields in any way. (It does have the implication that all the NFS cli=
ents=0A=
could use the same certificate. I'm not sure that would be a good plan, sin=
ce=0A=
revoking the certificate would revoke it for all clients and having it on N=
clients=0A=
would increase the risk of it being compromised, but ...)=0A=
--> The only way I can see that the server can enforce each client to use a=
=0A=
separate certificate for each client is by using #1.=0A=
=0A=
I had originally planned on some "secret" in the certificate (like a CN nam=
e=0A=
that satisfies some regular expression or ???) but others convinced me that=
=0A=
that wouldn't provide anything beyond knowing that the certificate was=0A=
signed by the appropriate CA, so I have not implemented anything.=0A=
=0A=
>As the CA admin, they control what is valid/gets signed in the CN or=0A=
>other fields, so this is safe to do... If you can't trust your CA to=0A=
>sign only valid (to your policy) certs, then you shouldn't be using=0A=
>that CA..=0A=
Yes, that is my thinking for #2, as suggested by others.=0A=
(For cases like using LetsEncrypt, my impression, which could be wrong, is=
=0A=
that anyone with a well known DNS name can get a certificate. As such,=0A=
without using #1, those certificates seem meaningless to the NFS server to=
me?)=0A=
=0A=
I, personally, don't think many NFS admins. will want #1, but if they happe=
n=0A=
to have NFS clients with well known DNS addresses, they can enable this che=
ck.=0A=
I think it is also a required capability according to the draft that will b=
ecome=0A=
an RFC at some point. (At some point I need to re-read the draft to try and=
=0A=
make sure I am playing by the rules. When I first read it, I thought that s=
ite=0A=
local CAs were not allowed, but the author clarified that site local CAs ar=
e=0A=
meant to be allowed.)=0A=
=0A=
Thanks for the comments, rick=0A=
=0A=
--=0A=
John-Mark Gurney Voice: +1 415 225 5579=0A=
=0A=
"All that I will do, has been done, All that I have, has not."=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3649B224FC082726F085BA5DDDCE0>