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

> On Dec 9, 2019, at 11:11 AM, Tom Talpey <[email protected]> wrote:
> 
>> -----Original Message-----
>> From: nfsv4 <[email protected]> On Behalf Of Chuck Lever
>> Sent: Sunday, December 8, 2019 11:59 AM
>> To: Tom Talpey <[email protected]>
>> Cc: NFSv4 <[email protected]>
>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
>> 
>> Having had some time to digest this....
> 
> Ok!
> 
>>> On Dec 6, 2019, at 4:44 PM, Tom Talpey <[email protected]> wrote:
>>> 
>>> 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.
>> 
>> 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.
> 
> Ok good that we're in agreement. I guess I'm suggesting to avoid the
> notion that this is an "iteration". In the protocol spec, it should strive
> to map out an architecture, and to note where a specific approach
> may be desirable, allowed, limited, or whatever. This is why I initially
> pointed out it's a key management issue at its base, i.e. it is not an
> RPC/TLS protocol requirement or restriction. This observation does
> not lead to any specific wording suggestion, but it does color the
> approach.
> 
>>> 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.
> 
> This is an excellent point and should be described in the document.

For the next revision, I'll include that distinction. Unless someone
has a brilliant suggestion for avoiding this conundrum.

The Coke/Pepsi text will focus on client-side key management, as you
suggested.

After WGLC closes, I'll post a link to a diff between the reviewed
document (-04) and my proposed changes to address LC comments. We can
tune up the language at that point.


>> 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.
> 
> I didn't see a cc on this, but I'm sure he reads nfsv4@ietf :-)

Doi. It was there at one point. Not sure why it disappeared.


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