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

On 12/6/2019 4:30 PM, Chuck Lever wrote:
> 
> 
>> On Dec 6, 2019, at 3:58 PM, Tom Talpey <[email protected]> wrote:
>>
>> On 12/6/2019 2:46 PM, Chuck Lever wrote:
>>>> On Dec 6, 2019, at 2:24 PM, Tom Talpey <[email protected]> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Chuck Lever <[email protected]>
>>>>> Sent: Friday, December 6, 2019 2:12 PM
>>>>> To: David Noveck <[email protected]>; Black, David
>>>>> <[email protected]>
>>>>> Cc: Tom Talpey <[email protected]>; NFSv4 <[email protected]>
>>>>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
>>>>>
>>>>>
>>>>>
>>>>>> On Dec 6, 2019, at 11:53 AM, David Noveck <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <[email protected]>
>>>>> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: nfsv4 <[email protected]> On Behalf Of Chuck Lever
>>>>>>> Sent: Friday, December 6, 2019 10:11 AM
>>>>>>> To: David Noveck <[email protected]>
>>>>>>> Cc: NFSv4 <[email protected]>
>>>>>>> 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.

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.

> 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?

>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4