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

> -----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
> 
> There is one comment that I would like to address via e-mail before
> pursuing a fresh revision of rpc-tls.
> 
> > On Nov 27, 2019, at 9:52 AM, David Noveck <[email protected]>
> wrote:
> >
> > 7.2.  Multiple User Identity Realms
> > I don't see how establishing an independent TLS session for each user identity
> domain would prevent privileged users in each security realm from monitoring
> RPC traffic emitted on behalf of users in other security realms on the same
> peer.  What am I missing?   Are there some unstated assumptions about what
> privileged users might be allowed to do?
> 
> There is an unstated assumption. The requirement here is poorly stated,
> and I'd appreciate help making this text more crisp.
> 
> The main worry is in a virtualization environment: the host might be
> inclined to share NFS resources amongst guests/tenants that access the
> same server. Essentially, we want to require that the host separates
> the encryption of each tenant's traffic.

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?

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.

Hopefully there are better-worded normative examples of this language...

> In this case, the privileged users on each tenant do not have any view
> of the local activity of other tenants, but might have a view of other
> tenant's network activity.

This is a different matter, and not something introduced by RPC/TLS?

Tom. 

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