Re: [nfsv4] NFS over TLS for laptops

[Benjamin Kaduk <[e-mail]>]

On Wed, Dec 30, 2020 at 11:12:05AM -0500, Chuck Lever wrote:
> 
> 
> > 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...

Agreed on both counts.

Thanks,

Ben