Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04

> On Dec 6, 2019, at 4:44 PM, Tom Talpey <tom@talpey.com> wrote:
> 
> On 12/6/2019 4:30 PM, Chuck Lever wrote:
>>> On Dec 6, 2019, at 3:58 PM, Tom Talpey <tom@talpey.com> wrote:
>>> 
>>> On 12/6/2019 2:46 PM, Chuck Lever wrote:
>>>>> On Dec 6, 2019, at 2:24 PM, Tom Talpey <ttalpey@microsoft.com> wrote:
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>>>> Sent: Friday, December 6, 2019 2:12 PM
>>>>>> To: David Noveck <davenoveck@gmail.com>; Black, David
>>>>>> <David.Black@dell.com>
>>>>>> Cc: Tom Talpey <ttalpey@microsoft.com>; NFSv4 <nfsv4@ietf.org>
>>>>>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Dec 6, 2019, at 11:53 AM, David Noveck <davenoveck@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <ttalpey@microsoft.com>
>>>>>> wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever
>>>>>>>> Sent: Friday, December 6, 2019 10:11 AM
>>>>>>>> To: David Noveck <davenoveck@gmail.com>
>>>>>>>> Cc: NFSv4 <nfsv4@ietf.org>
>>>>>>>> Subject: [EXTERNAL] Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04
>>>>>> 
>>>>>>>> Essentially, we want to require that the host separates
>>>>>>>> the encryption of each tenant's traffic.
>>>>>>> 
>>>>>>> I think the move from "user identiy domain" to "tenant" is helpful here even
>>>>>>> though you would have to explain what multipe tenants, which, as Tom
>>>>>>> points out, can alsooccur without virtalization per se, bein involved.
>>>>>> 
>>>>>> 
>>>>>> Fair 'nuf. To me "tenant" and "user identity domain" mean the same thing
>>>>>> in this context. In Linux, a tenant container is represented by a set of
>>>>>> namespaces, one of which controls the user identity mapping. So "user
>>>>>> identity domain" seems natural to me, but maybe not to others.
>>>>>> 
>>>>>> RFC 4949 does not have a convenient definition of "tenant."
>>>>>> 
>>>>>> RFC 7644 Section 6 comes close.
>>>>>> 
>>>>>> David Black, perhaps you might have thoughts based on your work on
>>>>>> network virtualization overlays ( RFCs 736[45] )?
>>>>> 
>>>>> I'm arguing the opposite - that there's no need to bring in "tenant" or
>>>>> "virtualization" or adding references to nvo, etc. Unless you have a very
>>>>> specific vulnerability in mind that this needs to cover.
>>>>> 
>>>>> In other words, keep it simple and at the highest-level abstraction possible.
>>>> I'm flexible, and philosophically agree that an abstract requirement
>>>> would be best. I just don't yet see how to make that happen. "Tenancy"
>>>> seems to me like an inseparable part of the discussion.
>>> 
>>> [replying from a different account]
>>> 
>>> I think "tenant" is a loaded word, especially when you seek an
>>> RFC-based definition. I understand the tenant container and namespace
>>> approach, but it's only one approach, and shouldn't be written into
>>> the protocol justification.
>>> 
>>> For example, the SMB3 protocol protects its traffic with per-user
>>> keys, and even safely mixes user traffic on a single connection
>>> because of this isolation. But this is implemented independent of
>>> containers and virtualization.
>> With RPCSEC GSS, each user gets its own key as well.
> 
> Indeed, yes.
> 
>> With TLS, a set of users shares a single host key. The constraint
>> we need to state here is how much key sharing is secure/recommended/
>> allowed.
> 
> I disagree - this is an implementation choice not a TLS requirement.
> This is the trap I think the draaft needs to avoid falling into.

Not a trap, it's a conscious choice.

> A single machine key is great for protecting HTTPS to a laptop, it
> covers traffic through unsafe networks and gives us a bit of server
> authentication. But NFS is a different scenario.

An _NFS_ implementation is free to make more restrictive policy
choices. We are defining a generic RPC over TLS mechanism here.

If we want NFS to do something else, I think another document, an
NFS-specific document, is required.

>> In addition, Section 4.2 has this language:
>>>    In either of these modes, RPC user authentication is not affected by
>>>    the use of transport layer security.  Once a TLS session is
>>>    established, the server MUST NOT substitute RPC_AUTH_TLS, or the
>>>    remote identity used for TLS peer authentication, for existing forms
>>>    of per-request RPC user authentication specified by [RFC5531].
>> The document explicitly prohibits the use of these keys for making
>> authorization decisions about individual users. In other words, a
>> TLS identity in this case is not the same as an RPC user.
> 
> Right. But the language you quote is pretty vague. "Existing forms of
> per-request RPC user authentiction" I have to think about that long and
> hard, much less translate to a specific thing to MUST NOT do.
> 
>>>> If you have an example, that would help.
>>> 
>>> Well, it's the same thing - per-user NFS/RPC/TLS mounts, but it
>>> leaves out any mention of containers or namespaces or tenancy.
>>> Those are today's Linux approach, but they are by no means required
>>> to drive the protocol. I'm just suggesting the draft can say this
>>> without any of that baggage.
>> Again, I don't disagree with any of this. But I'm stuck when trying
>> to bridge the gap between "the draft can say this" and actually
>> writing the text. I'm not arguing with you, just trying to shake out
>> what it is we need to say in the document.
>>> A user then becomes an "authenticated principal", and the RPC/TLS
>>> connection may therefore be protected by a key derived from this
>>> authentication.
>> As above: RPC on TLS explicitly does not bind an RPC user to a TLS
>> identity in this iteration of the protocol. RPC users share the
>> encrypted TLS session. The TLS identity represents the client, not
>> the users.
> 
> But again, why not? Is that forbidden somehow? Or is it simply the
> way most OS's implement it?

This document/protocol is restricting it to keep it simple. Nothing
to do with implementations.

All we want in this iteration is encryption. Using TLS for user
authentication is future work.

>>> Or, if the administrator allows, it can be a
>>> per-machine key, or shared in other ways.
>> That's the (only) model we are trying to express here. And perhaps
>> we need to take care not to prevent a future protocol iteration
>> from going further and binding a single RPC user to a TLS identity.
>>> But this would not be
>>> as secure as the former, and the implications need to be stated.
>> To state those implications, IMO we need to express the concept of
>> a set of one or more users that reside in a single user identity
>> domain -- ie, users that are administered in the same security realm.
>> --
>> Chuck Lever
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever