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

[Tom Talpey <[e-mail]>]

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

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

A user then becomes an "authenticated principal", and the RPC/TLS
connection may therefore be protected by a key derived from this
authentication. Or, if the administrator allows, it can be a
per-machine key, or shared in other ways. But this would not be
as secure as the former, and the implications need to be stated.

Tom.