Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

Hi Rick -

> On Dec 20, 2020, at 5:48 PM, Rick Macklem <[e-mail]> 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?

Section 5.2.1 used to start this way:

5.2.1.  X.509 Certificates Using PKIX trust

   Implementations are REQUIRED to support this mechanism.  In this
   mode, the tuple (serial number of the presented certificate; Issuer)
   uniquely identifies the RPC peer.

This is quoted from rpc-tls-05. This is the tuple that I meant
as a unique ID for a certificate.

It's also common for cert-based security implementations to use
a certificate's fingerprint for indexing databases or mappings.
Take the SHA-256 hash of the whole cert, and use that, or a
portion of it if a small index is needed.


A pre-shared key (Section 5.2.2 of the current revision), I
believe, cannot carry an otherName payload. For PSK, the only
way to implement identity squashing is for each server to enforce
a mapping of unique IDs (keys) to a set of one or more allowed
users.

And, as mentioned before, when a client does not present any TLS
identity, the server is the only party that can perform identity
squashing.


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

Correct. As I quoted above, both are part of that unique
tuple.


> 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.
> 
> Still seems to be an Administrative Hassle to me, rick

In a small deployment, client certificates could be generated
on the NFS server itself. A tool specifically for this purpose
could generate the certificate and update the squashing
configuration at the same time. This can also work for PSK
deployments.

When you have more than one server, some mechanism for sharing
the squashing information is needed. You have proposed adding
that information to the certificates, but that would work only
in the case when each client actually has a certificate.

I expect larger deployments (eg, client fleets in the tens of
thousands and user populations in the hundreds of thousands,
with dozens of servers) to have infrastructure that would make
certificate creation as easy. An administrative host would be
able to create certificates and update an LDAP directory that
is consulted by servers. (Think of Red Hat's "IPA" which
already combines certificate management, Kerberos, and LDAP)

So I still believe that TLS administrative scalability is:

a. better than a Kerberos deployment

b. able to be improved by clever infrastructure and tool chains

---

You said you are not asking the WG to codify the otherName
convention. So, right now, you do not care whether other
implementations interoperate with FreeBSD in this regard. Fair
enough.

And, we agree that securing single-user clients is an important
and common usage scenario.

I expect other implementers will find the same thing. When they
deal with this issue, they might see your implementation and
and copy it. Or they might copy it and add some variations,
since there is no published specification.

And then I can see one or more of them approaching the WG and
asking us to either update rpc-tls or provide a specification
to enable proper interoperation.

Or, possibly, at some point in the future, the WG will be tasked
with updating rpc-tls to reflect implementation practice, part
of which might be otherName.


At that point, we have a real problem. Or maybe just me, as an
author of rpc-tls and possibly its descendants, has that problem.


--
Chuck Lever