Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

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