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

[Chuck Lever <[e-mail]>]

Having had some time to digest this....


> On Dec 6, 2019, at 4:44 PM, Tom Talpey <[e-mail]> wrote:
> 
> On 12/6/2019 4:30 PM, Chuck Lever wrote:
>>> 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.
> 
> 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.

What I meant is "With the current iteration of RPC-on-TLS,". I agree
TLS itself does not make a single key per client requirement.


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

It does seem vague to the point of being unimplementable. I will have
to strengthen this paragraph significantly. Consider below:


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

The reason the current protocol does not bind the client certificate
to a particular user is because we want to enable encryption in the
following usage scenarios:

 - The client has no certificate

 - The client has a certificate that is shared amongst some or all
   of its users

 - Each user has her own certificate (or, the client has a single
   user which is indistinguishable from the host itself)

The problem is that, given the currently proposed protocol extension,
the server has no way to distinguish between the latter two cases.
IMO this is why the server MUST NOT treat the client's TLS identity
as identical to an RPC user in this iteration of the protocol.

I've cc'd my co-author for his thoughts, hoping he has had an
opportunity to follow this thread.


>>> 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
[e-mail]