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

Rick Macklem wrote this message on Wed, Mar 25, 2020 at 23:50 +0000:
> 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.

Yeah, having a "secret" in the CN doesn't make sense, but what does make
sense is allowing the exports line to specify what the CN should contain
to be authenticated...

Say as a corp, you issue personal certificates to everyone.  This is
because you require everyone to sign and/or encrypt their email w/
S/MIME.  Each cert includes the email address of that person, so you
could simply do something like:
/home/alice -tlscert -tlsroot /etc/company.pem -email alice_at_example.com

And anyone who has the certificate w/ alice_at_example.com that was signed
by the public key in /etc/company.pem would be granted access to the
export /home/alice.

If it allowed ANY cert signed by the CA specified, then that introduces
an authentication problem, as now if Malory is a coworker of Alice
could also access Alice's home directory...

IMO, this is one auth feature that MUST be supported...

Now that I reread your comments, it sounds like any certificate would be
allowed in #2 as long as it is valid, and that would only be marginally
better than verification by IP, and in some ways worse, in that now any
user could pretend to be any other user, or you have to do something
crazy like have a CA per user.

I'm wonder if your use of the term secret was the problem, and not the
idea...  Anything that goes in the client cert is by definition public...
TLS prior to 1.3 sends the client cert in clear text...  But keying
based upon the contents of the cert is fine, as that's the point of
what a cert is..  It's trusting the CA to say that the CN and other
fields in the cert corresponds to this user, and you can use parts of
the cert, like the CN to decide which user the public key in the cert
corresponds to.

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

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