Skip site navigation (1)Skip section navigation (2)
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>