Re: [nfsv4] NFS over TLS for laptops

[Benjamin Kaduk <[e-mail]>]

Hi Rick,

Consolidating a few messages into a single note (inline)...

On Sun, Dec 13, 2020 at 12:02:02AM +0000, Rick Macklem wrote:
> 
[...]
> 
> Now, for the part that might be considered a violation of the "soon
> to be an RFC" draft.
> 2 - When the site local CA admin creates the certificate for the laptop,
>      put an otherName component in  subjectAltName that looks like:
>       1.3.6.1.4.1.2238.1.1;UTF8:[e-mail]
> 
>       Now. if the daemon that does the TLS handshake on the NFS server
>       is started with the "--certuser" option, it will take the
>       [e-mail] from the client's certificate and translate
>       that to a POSIX <uid, gidlist> credential on the serve in a manner
>       analogous to what the mapper daemon (think rpc.imapd) and gssd
>       does for a Kerberos user principal.
>       --> Strip off @uoguelph.ca as the local domain and then get the
>             POSIX credentials for "rmacklem" from the user/group databases.
> 
> Now, all RPCs done on this TLS/TCP connection use the above POSIX
> credentials instead of the contents of any AUTH_SYS credential in the
> RPC request header.
> --> FreeBSD has for a long time had a "-mapall" export option which
>        is similar to root squash, but happens for all uids. However this
>        doesn't work for this case, since exports are based on client IP
>        address.
> 
>        This is similar to that, but using the information in the client's
>         machine certificate to decide what to squash the AUTH_SYS
>         credentials to.
> 
> This limits the damage done if a laptop is compromised to that
> which can be done by that user (aka rmacklem) against the NFS server.

(I agree with Chuck that we should be careful about conflating host and
user authentication, and that some sort of "squash", or rather,
constraining the allowed users from a given host/certificate, will be
useful.)

> Now, how does this compare with "sec=krb5" for this laptop case?
> --> Well, if the device is compromised such that a "trojan horse" can capture
>        the latop key's passphrase can the same be done on it for login/kinit
>        to capture the Kerberos password for the user principal the laptop's
>        user uses?
>        I think so.
>        --> If the user principal's password is compromised, then access to the
>               server as that user is acquired.
> 
>         Also, this would require the KDC be accessible from "the world", which
>         sounds pretty scary to me.

It shouldn't -- the protocol is designed for it, the software is designed
for it, and lots of sites do it.

> This seems comparable to the mobile device's certificate being compromised,
> which allows NFS server access as the user in the otherName component of
> subjectAltName.
> Seems like the level of risk is about the same?
> 
> For Kerberos, the user's password can be changed to stop the compromised
> access. For the certificate being compromised, the site local CA admin. can
> put the certificate in the CRL for the site to stop the compromised access.

(The point raised downthread about the disparity in credential lifetimes is
also relevant, though can be managed in several ways, including via CRL as
you note.)

On Tue, Dec 15, 2020 at 03:54:26PM +0000, Rick Macklem wrote:
> From: nfsv4 <[e-mail]> on behalf of Rick Macklem <[e-mail]>
> Sent: Monday, December 14, 2020 9:46 PM
> To: Chuck Lever
> Cc: [e-mail]
> Subject: Re: [nfsv4] NFS over TLS for laptops
> 
> Chuck Level wrote:
[...]
> >> Typical filtering at the NFS server via client IP address obviously cannot work, so
> >> what can be done?
> >
> >Our vision is that a TLS-enabled NFS service would be unlikely
> >to filter based on IP address. Such an NFS server either
> >allows the cert presented by a client, or the server tells
> >that client to pound sand. That's part of the TLS handshake.
> Btw, it's a little off topic, but I do think there is a use case for TLS,
> where the NFS client does not have a certificate.

TLS does not allow you to have the client authenticate with a certificate
when the server does not.

> --> Server trusts the client's identity via it's IP host address, but
>       encryption on the wire is desired. For this case, creating
>       certificates for all the clients would seem to be unnecessary
>       overhead, unless "TLS squashing" is desired.
> -->The harder we make deployment of NFS-over-TLS, the less likely
>      it will be adopted.
> Client TLS mounts without certificates is optionally allowed by
> the current FreeBSD implementation.
> 
> >IIRC a client cert don't have to contain a domain name or IP
> >address that matches the network endpoint that presents that
> >cert. Unlike RPC-over-TLS server certs.
> I agree. For FreeBSD's current implementation, this is optional and
> obviously cannot be done for mobile devices.

Subject names for X.509 certificates are quite flexible, yes; the
subjectAltName is in essence arbitrarily exztensible.

[...]
> > Have we
> > documented this AUTH_SYS limitation somewhere? Would it be
> >  non-repudiation or something else?
> >
> >- Since that client certificate is already unique, otherName isn't
> >  a requirement for this constraint to work. The client's identity
> >  is supposed to be exposed to the NFS server, which can be
> >  configured to constrain that client's activity to a single user.
> >  otherName seems to be an administrative convenience (and I think
> >  you alluded to that somewhere else).
> Yes. My understanding is that the tuple <issuerName, subjectName>
> should be uniquely assigned to a certificate.

No.  It's perfectly normal to have multiple concurrently valid certificates
for the same issuerName/subjectName -- that is how certificate renewal
works.

A certificate is uniquely identified by its serialNumber/issuer pair; the
issuer, in turn, can be identified either by its own subject and issuer, or
by keyIdentifier.

[...]
> >What is our thinking about how certificates might be used to handle
> >RPC user authentication?
> --> I posted about this once before and, in my opinion, using more than
>       one certificate per TLS session/TCP connection is not practical.
>       To do so, something like RPCSEC_GSS with X509 mechanism
>        would need to be implemented. The client would need to have

It already has been, actually -- the Globus Grid Security Infrastructure
(GSI) mechanism uses X.509 certificates as credentials for a GSSAPI
mechanism (that's essentially just running a TLS handshake) and there are
patched ssh clients around if you search for them.  (Paper at
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=BF00DE253BA4E15725A19A87974D62D5?doi=10.1.1.109.6988&rep=rep1&type=pdf
.)  Not that I am advocating using it in this context!  I don't think we
should put much effort into supporting multiple certificates per
connection.

>        a database of certificates for different users. A compromised
>        client system would compromise all those users, etc and so on.
>        --> For this we have Kerberos and it works. Doing RPCSEC_GSS
>              with X509 mechanism would require a lot of implementation work
>              and the result would be less secure and as much effort to manage
>              as using Kerberos, I think.

"Much effort" seems likely; "less secure" is not so clear -- I think it
would have somewhat different security properties but which one is better
or worse would depend on the deployment conditions.

On Sun, Dec 20, 2020 at 10:48:41PM +0000, Rick Macklem wrote:
> Rick Macklem wrote:
> >Chuck Level wrote:
> >[stuff snipped]
> >>The certificate has a unique identity other than the CN. I was
> >>thinking that unique identity was going to be the key for the
> >>squashing mapping.
> >Not sure what field(s) of a certificate you are referring to?
> I took a look at a CRL and it appears to use SerialNumber to
> refer to s revoked certificate, so I'm guessing that is what
> you are referring to?
> 
> Since the serial number is per issuer and I would expect some
> NFS servers will want to handle certificates from multiple issuers,
> I think that the issuerName will be needed in the database key,
> as well.

Yes, serialNumber + issuer is the common practice (as mentioned above).
RFC 5280 is a bit dense but if you know the terms to search for these
points can be found.

> For the below certificate, the database key would be:
> Issuer: C = CA, ST = Alberta, L = Jasper, O = MMM, OU = XXX, CN = democa.home.rick, emailAddress = [e-mail]
> Serial Number: 2 (0x2)
> 
> Of course, as I think you noted, there is no guarantee that the
> certificates will be correctly generated, to result in the above
> referring uniquely to one certificate.

There's no guarantee that any endpoint will correclty implement the
protocol, but a CA that reuses a serial number is seriously misbehaving and
shouldn't be trusted for anything.

-Ben