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

[Chuck Lever <[e-mail]>]

> On Dec 6, 2019, at 3:58 PM, Tom Talpey <[e-mail]> wrote:
> 
> 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.

With RPCSEC GSS, each user gets its own key as well.

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.

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.


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


> 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