Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

> On Dec 29, 2020, at 2:07 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Dec 29, 2020 at 11:41:04AM -0500, Chuck Lever wrote:
>> 
>> 
>>> On Dec 23, 2020, at 7:03 PM, Rick Macklem <[e-mail]> wrote:
>>> 
>>>> 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?)
>> 
>> I think we know the answer. We have a consensus that was
>> arrived at by the usual process. It is documented in
>> rpc-tls.
>> 
>> 
>>> Any other implementation who might choose the otherName
>>> approach can easily do so from the FreeBSD doc. and sources.
>>> (Or by simply asking me.)
>> 
>> My concern is that we have a spec (one that supposedly
>> represents a community consensus) that tells us not to mix
>> client and user authentication material, and yet implementers
>> are choosing to do this anyway.
>> 
>> Is the spec then wrong? If it is, the WG needs to address that.
>> The primary purpose of specifications is to codify the practices
>> where we agree, yet there is clearly a disagreement already.
>> 
>> If the spec is not wrong, the WG needs to consider ways to
>> address the need while complying with the normative
>> requirements in rpc-tls.
>> 
>> I was hoping that we could identify a compromise position, at
>> least, with the FreeBSD implementation. If it turns out we
>> cannot, then the WG needs to construct a proper response to
>> the single-user-per-client scenario.
> 
> I suspect that we can find a compromise position, yes.
> The certificate still authenticates the client (not the user), and the
> client uses AUTH_SYS to claim what user is performing operations.  But the
> server uses the client's authenticated identity to restrict, by policy,
> what user identities the client is allowed to claim via AUTH_SYS.  In the
> degenerate case there is an otherName in the certificate that corresponds
> to a single user and the client can only claim that one user, which looks
> very similar to just authenticating the user, but we can say that the
> relevant policy logic is located in the server as part of its internal
> implementation choices.

An NFS client might send legitimate operations as UID 0 too
(e.g., lease management). Those cannot be rejected. Perhaps
we need to specify that the client has to perform _all_
operations as the squashed user.

As a process note, I'm thinking this explanation, a description
of the use of otherName, and a summary of the security discussion
in this thread ought to go in whichever document discusses how
NFS operates on RPC-over-TLS. It seems to be NFS-specific access
control behavior.

The alternative is publishing an update to rpc-tls...


> (There might be some divergence from what Rick has
> done for the FreeBSD implementation in terms of the behavior when a client
> does try to send some other user information via AUTH_SYS, in terms of
> getting "squashed" vs getting rejected, but I suspect that Rick is amenable
> to changing that behavior if we come up with some reasoning for why it
> makes sense.)
> 
> -Ben
> 
>> In short, the WG must come to a fresh consensus that either
>> otherName is OK to do in this scenario, or it must provide an
>> acceptable alternative.
>> 
>> 
>>>> 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.
>> 
>> Simple, but problematic. The possible result will be the
>> promulgation of implementations that do not comply with our
>> shiny new specification. I think the IETF would view that as
>> very much a quality-of-specification problem. The usual redress
>> is to publish an updated protocol specification.

--
Chuck Lever