Re: [nfsv4] NFS over TLS for laptops

[Benjamin Kaduk <[e-mail]>]

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.  (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
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4