Re: [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 don't think this is limited to a virtualization environment, or the behavior
>> of the host partition/process. It's more generally a matter of key management,
>> isn't it?
> 
> That seems right to me.
>  
> 
>> The more general statement in that case might be that the key(s) used to
>> protect the TLS connections MUST be managed in such a way that do not
>> impact the privacy or integrity of one another. For example, if Coke and Pepsi
>> were both guests of a single host, the keys used for their RPC/TLS mounts
>> MUST NOT allow Coke to attack Pepsi.
> 
> Good requirement but I think it needs to be stated in terms of what the 
> implementation is to do, rather than what it needs to prevent.

I agree that this has become implementation guidance. But I'm still not
clear on exactly how to state this recommendation/requirement.

For one thing, the use of compliance keywords might no longer be appropriate.


--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4