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

John-Mark Gurney wrote:
>Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +0000:
>> Alexander Leidinger wrote:
>> John-Mark Gurney <jmg_at_funkthat.com> wrote:
>> >>Rick Macklem wrote:
>> >>> 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.
>> >>
>> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do
>> >> to prevent that.  This is both a better situation than what we have
>> >> today (no auth/confidentiality), and if you tie the cert to an IP, it's
>> >> of limited use, and better than today...
>> >
>> >There are multiple ways to handle that:
>> >  - First of all, you can just validate based upon "cert is signed by
>> >trusted CA".
>> >  - Then you can require that the CN matches the hostname and the
>> >reverse lookup matches.
>> >  - Or (similar to browsers today) you can ignore the CN and require
>> >that the hostnames of the client matches one of the subject
>> >alternative name (SAN) entries (requires reverse DNS lookup to work
>> >and match).
>> At this point, I have three variants in the code (strictest to less strict):
>> 1 - A "-h" command line option on the server handshake daemon (called rpctlssd).
>>      This requires that all clients have
>>      certificates that validate and have the FQDN acquired via reverse DNS of
>>      the IP address of the client for the TCP connection (getnameinfo(NI_NAMEREQD))
>>      in either the subjectAltName or CommonName. (I call X509_check_host()
>>      and this is what I understand it checks.)
>>      --> This case implies that the NFS server admin. does not "trust" the
>>             client's IP address enough to apply exports(5) line(s)to it to decide to
>>             allow the client to do an NFS mount.
>>      (An NFS server *might* be willing to allow client(s) to mount via any IP address
>>       for the #2 case below and not use this option.)
>> 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate
>>      if the client provided a certificate and whether or not it verified.
>>      Then the "-tlscert" option on the appropriate exports(5) line(s)
>>      indicates that the client must have provided a certificate that verified.
>>      --> For this case (and #3), the server admin. is willing to "trust" the client's
>>             IP address enough to apply exports(5) rules to it.
>>      --> This is the case where a floating (no fixed IP) laptop could have a
>>            certificate signed by a site local CA.
>> 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s).
>>      In this case, the client must use TLS so that data is encrypted on the wire,
>>      but does not need to have a certificate.
>>      --> The NFS server admin. "trusts" the client IP address enough that they
>>            are willing to allow the client to mount based on that IP, but wants the
>>            data to be encrypted on the wire.
>>            - Avoids the bother of generating certificates for the client(s).
>>
>> A part of this (as discussed in the IETF draft) is to make this easy enough to
>> use that it does get used. (sec=krb5p achieves both user authentication and
>> data encryption on the wire, but does not get widely used, due to the need
>> to run a KDC, etc).
>>
>> Comments on the above options is welcome, since this does need to be
>> reviewed by users.
>
>Maybe I'm missing the option where the cert needs to be authenticated,
>but matching against IP/dns name does not need to be done.  Or is this
>a case of #2.  I'm just confused by the first point of #2 in that the
>server admin is wiling to trust the IP address...
Yes, that is #2. "trust the IP address" probably wasn't a good way to
express it. I was simply trying to say "the NFS server admin. is willing to
use the client IP address to select rules via the exports(5) file".

>I'd like to see where CN or other field is freeform/provided by exports
>entry, and validated to gain access to those resources...  i.e. it
>doesn't matter what IP or DNS name the client is, it's based solely on
>the certificate.  This would allow roaming users..  This maybe be
>addressed by #2 point 2, but it isn't clear in your description that
>it isn't dns tied or something else...
Yes, for #2 the daemon only validates the certificate (actually uses the openssl
default verification library function). It does not filter the certificate's CN or
other fields in any way. (It does have the implication that all the NFS clients
could use the same certificate. I'm not sure that would be a good plan, since
revoking the certificate would revoke it for all clients and having it on N clients
would increase the risk of it being compromised, but ...)
--> The only way I can see that the server can enforce each client to use a
       separate certificate for each client is by using #1.

I had originally planned on some "secret" in the certificate (like a CN name
that satisfies some regular expression or ???) but others convinced me that
that wouldn't provide anything beyond knowing that the certificate was
signed by the appropriate CA, so I have not implemented anything.

>As the CA admin, they control what is valid/gets signed in the CN or
>other fields, so this is safe to do... If you can't trust your CA to
>sign only valid (to your policy) certs, then you shouldn't be using
>that CA..
Yes, that is my thinking for #2, as suggested by others.
(For cases like using LetsEncrypt, my impression, which could be wrong, is
 that anyone with a well known DNS name can get a certificate. As such,
 without using #1, those certificates seem meaningless to the NFS server to me?)

I, personally, don't think many NFS admins. will want #1, but if they happen
to have NFS clients with well known DNS addresses, they can enable this check.
I think it is also a required capability according to the draft that will become
an RFC at some point. (At some point I need to re-read the draft to try and
make sure I am playing by the rules. When I first read it, I thought that site
local CAs were not allowed, but the author clarified that site local CAs are
meant to be allowed.)

Thanks for the comments, rick

--
  John-Mark Gurney                              Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."