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

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.

rick

     
At this point you prevent simple cert theft as additionally you  
require that someone also has to be able to modify the DNS (or NFS  
server hosts file, but then he probably can already add an additional  
cert to the truststore of nfsd).

Additional protection is possible by also adding the IP to the SAN. I  
haven't put an effort into evaluating if either IP or DNS is enough  
from a security point of view, or if it makes a difference if the "IP  
in SAN" case has an additional benefit in terms of security if it is  
in addition to the reverse DNS requirement.

Yes this makes it more inconvenient to change the IP of a host, but if  
all the policy possibilities are up to the admin to configure (e.g.  
"cert is signed by trusted CA" as a default, and all the other  
possibilities as an option for nfsd), it is up to the admin and the  
security requirement.

In general, all the possibilities are can either be distinct, or  
accumulative. There is also the possibility that you do not go with  
any CA but configure X self-signed certs for X clients as being  
trusted and the cert of the client needs to be an exact match with one  
of the X self-signed certs in the truststore.

Whatever the policy(/ies) is/are in nfsd, I suggest to make it  
explicit in the docs what is required and what is checked for each  
policy. And even if it may be obvious for you Rick, please also print  
out why a client was rejected. Unfortunately I've seen a lot of cases  
where the error is a simple/frustrating "certificate rejected", but no  
info which part of the certificate check failed.

Bye,
Alexander.
-- 
http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild_at_FreeBSD.org  : PGP 0x8F31830F9F2772BF