Date: Thu, 26 Mar 2020 14:33:12 +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: <QB1PR01MB3649F248F7D4C5B21630963FDDCF0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200326004154.GT4213@funkthat.com> References: <QB1PR01MB36491D0C0306EEB894E37EADDDF00@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM> <20200325231005.GQ4213@funkthat.com> <QB1PR01MB3649B224FC082726F085BA5DDDCE0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>, <20200326004154.GT4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:=0A=
[lots of stuff snipped]=0A=
>Rick Macklem wrote:=0A=
>> I had originally planned on some "secret" in the certificate (like a CN =
name=0A=
>> that satisfies some regular expression or ???) but others convinced me t=
hat=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=
>Yeah, having a "secret" in the CN doesn't make sense, but what does make=
=0A=
>sense is allowing the exports line to specify what the CN should contain=
=0A=
>to be authenticated...=0A=
>=0A=
>Say as a corp, you issue personal certificates to everyone. This is=0A=
>because you require everyone to sign and/or encrypt their email w/=0A=
>S/MIME. Each cert includes the email address of that person, so you=0A=
>could simply do something like:=0A=
>/home/alice -tlscert -tlsroot /etc/company.pem -email alice@example.com=0A=
>=0A=
>And anyone who has the certificate w/ alice@example.com that was signed=0A=
>by the public key in /etc/company.pem would be granted access to the=0A=
>export /home/alice.=0A=
>=0A=
>If it allowed ANY cert signed by the CA specified, then that introduces=0A=
>an authentication problem, as now if Malory is a coworker of Alice=0A=
>could also access Alice's home directory...=0A=
>=0A=
>IMO, this is one auth feature that MUST be supported...=0A=
The draft does not address user authentication, only machine authentication=
.=0A=
--> ie. The certificate is used to decide if a system can do a mount.=0A=
Users are still identified via user credentials in the RPC message he=
ader.=0A=
For AUTH_SYS, that still means <uid,gid,...>.=0A=
Otherwise, you need to use Kerberos (sec=3Dkrb5[ip]).=0A=
You could use "tls,sec=3Dkrb5" for a mount, but the only advantage th=
at=0A=
might have over "sec=3Dkrb5p" is performance, if there is hardware as=
sist=0A=
for TLS or something like that.=0A=
=0A=
>Now that I reread your comments, it sounds like any certificate would be=
=0A=
>allowed in #2 as long as it is valid, and that would only be marginally=0A=
>better than verification by IP, and in some ways worse, in that now any=0A=
>user could pretend to be any other user, or you have to do something=0A=
>crazy like have a CA per user.=0A=
The case where I see #2 is useful is where this discussion started some wee=
ks ago.=0A=
The example I started with was:=0A=
/home -tls -network 192.168.1.0 -mask 255.255.255.0=0A=
/home -tlscert=0A=
=0A=
This says that machines on the local lan can mount and do not need to have=
=0A=
certificates, but must use TLS so data is encrypted on the wire.=0A=
Mounts from anywhere else (presumably laptops) are allowed so long as they =
have a=0A=
certificate signed by me (as in the site local CA).=0A=
I trust these machines enough that I am willing to allow them to use AUTH_S=
YS,=0A=
which is what 99.9...% of NFS mounts do now.=0A=
(So, I'd agree that the site local certificate is not a lot better than IP =
address=0A=
for client machine identity, just that it is an alternative that can be us=
eful.=0A=
Without TLS, a line like "/home" allows anyone to mount /home from anywher=
e=0A=
and I think you'd agree that few NFS admins. will want to do that. I'm ass=
uming=0A=
no external firewall for this example.)=0A=
=0A=
Now, your suggestion of identifying a user via the CN and then having the=
=0A=
server do all RPCs for the mount as that user is an interesting one.=0A=
My concern w.r.t. implementing it would be interoperability.=0A=
Put another way, if other servers such as Linux, Netapp,... don't adopt it=
=0A=
(and they won't until there is a draft/RFC specifying it), it would be=0A=
FreeBSD server specific and I'd like to avoid that.=0A=
There was some discussion w.r.t. user authentication via certificates=0A=
during development of the draft, but they decided to defer that work for=0A=
now, so they could get something in place for machine authentication first.=
=0A=
(If I understood the discussion on nfsv4@ietf.org.)=0A=
=0A=
rick=0A=
=0A=
>I'm wonder if your use of the term secret was the problem, and not the=0A=
>idea... Anything that goes in the client cert is by definition public...=
=0A=
>TLS prior to 1.3 sends the client cert in clear text... But keying=0A=
>based upon the contents of the cert is fine, as that's the point of=0A=
>what a cert is.. It's trusting the CA to say that the CN and other=0A=
>fields in the cert corresponds to this user, and you can use parts of=0A=
>the cert, like the CN to decide which user the public key in the cert=0A=
>corresponds to.=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?QB1PR01MB3649F248F7D4C5B21630963FDDCF0>