Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

Chuck Lever wrote:
[lots of stuff snipped]
>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

If this is going to work for NFS servers from different vendors
(using vendors loosely to include open source projects)
you may have to think about defining a standard format
for the database information and a standard secure way
to distribute the data.
Otherwise, how is a Redhat tool going to manage a Netapp
filer, for example?
--> This could be a lot of work to define and implement
       for all vendors?

Wearing my old sysadmin hat, I'll admit that I was careful to
deploy NFS servers that were not dependent on other services
such as LDAP, DNS.
Why?
Well, after something like a major power failure I did not the
NFS servers stuck waiting for other services to come online.
--> As such, personally, I'd rather not depend on a service
      like LDAPS (note the 'S') to be running for the NFS server to be running.
      But, that's just me.

>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.
I suspect (although I cannot be 100% sure) that non-FreeBSD
clients will simply handle the X.509 certificate as a blob.
As such, it will work against a FreeBSD server.

For non-FreeBSD servers, they will probably ignore the otherName.
So, for those, the TLS squashing will need to be done with whatever that
server vendor provides.

Dealing with this will probably not be a lot different than dealing with
every server vendor choosing their own data format and distribution
mechanism.

>And, we agree that securing single-user clients is an important
>use case. (paraphrase. My stupid email system cut the text line out.)
>
>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.
Yes. As above w.r.t a TLS squashing data and distribution mechanism,
I agree.

>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.
And you can simply restate that you do not consider use of the
otherName field this way as acceptable, due to conflagration
of user and machine credentials in the certificate.
(I suppose there is the question of whether or not the "collective"
 working group agrees with the above, but since no one else has
 commented except Ben Kaduk, we do not know the answer to
 that?)

Anyone other implementation who might choose the otherName
approach can easily do so from the FreeBSD doc. and sources.
(Or by simply asking me.)

>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.
I do not really see the problem. No is a simple answer.

I will make one more generic comment...
There is a cousin to Administrative Hassle called Implementation
Effort.
--> It has been almost 11years since RFC5661 was published and
       I think you can count the number of different NFSv4.1 client
       and server implementations on one hand. Different vendors
       for client vs server, but both about 5 or less?

rick


--
Chuck Lever