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

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

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

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?
>
I think you always have to assume the worst case, that anybody can see
anybody else's network activity :-(

> Tom.
>
>

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