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

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...

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...

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..

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

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