Re: [nfsv4] NFS over TLS for laptops

[Craig Everhart <[e-mail]>]

Am I the only clueless one who doesn’t understand what “TLS squashing” is or means?  If so I’ll go back to background and try to trawl old emails.  Otherwise, perhaps you could enlighten.

Happy New Year.

Craig


> On Dec 31, 2020, at 11:53 AM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever wrote:
>> Ben Kaduk wrote:
>>> 
>>> 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.
> Yes. I agree with this.
> My current implementation simply ignores the AUTH_SYS RPC
> credential when TLS squashing is enabled.
> 
>> 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.
> My implementation is done in the RPC layer.
> However, since NFS is the main/only Sun RPC consumer and NFS
> is what we do, an NFS specific document seems appropriate to me.
> 
> I do think that TLS squashing done via a database keyed on
> issuer+serial could be a useful alternative (for larger deployments or ...).
> I also think the database structure/access should be specified in detail,
> so that all server implementations can use the same database deployment.
> --> Possibly use secure LDAP?
>       I do not know how to specify LDAP data, but there must
>       be a way?
> I could easily implement that as an optional alternative to otherName
> in the FreeBSD daemon that does the TLS handshake.
> 
>> 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.)
>>> 
> I think the "squash everything" will work best and that already appears to
> be a concensus.
> 
> rick
> 
>> -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