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

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Dec 2019 10:11:04 -0500

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

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.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Fri, 6 Dec 2019 15:28:47 +0000

> -----Original Message-----
> From: nfsv4 <[email-masked]> On Behalf Of Chuck Lever
> Sent: Friday, December 6, 2019 10:11 AM
> To: David Noveck <[email-masked]>
> Cc: NFSv4 <[email-masked]>
> Subject: [EXTERNAL] Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04
> 
> > 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?
> 

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

> tenant's network activity.

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

Tom.

---

From: David Noveck <[email-masked]>
Date: Fri, 6 Dec 2019 11:53:14 -0500

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

> of the host partition/process. It's more generally a matter of key

That seems right to me.

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

> 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 :-(

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Dec 2019 14:11:52 -0500

> On Dec 6, 2019, at 11:53 AM, David Noveck <[email-masked]> wrote:
> 

>> Essentially, we want to require that the host separates
> I think the move from "user identiy domain" to "tenant" is helpful here even 

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

> 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

---

From: Tom Talpey <[email-masked]>
Date: Fri, 6 Dec 2019 19:24:53 +0000

> From: Chuck Lever <[email-masked]>
> Sent: Friday, December 6, 2019 2:12 PM
> To: David Noveck <[email-masked]>; Black, David
> <[email-masked]>
> Cc: Tom Talpey <[email-masked]>; NFSv4 <[email-masked]>
> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
> 
> 
> 

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.

Tom.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Dec 2019 14:46:17 -0500

> On Dec 6, 2019, at 2:24 PM, Tom Talpey <[email-masked]> wrote:
> 

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.

If you have an example, that would help.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Fri, 6 Dec 2019 15:58:22 -0500

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

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

A user then becomes an "authenticated principal", and the RPC/TLS
connection may therefore be protected by a key derived from this
authentication. Or, if the administrator allows, it can be a
per-machine key, or shared in other ways. But this would not be
as secure as the former, and the implications need to be stated.

Tom.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Dec 2019 16:30:02 -0500

> On Dec 6, 2019, at 3:58 PM, Tom Talpey <[email-masked]> wrote:
> 

With RPCSEC GSS, each user gets its own key as well.

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.

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.

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

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

> 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

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

---

From: Tom Talpey <[email-masked]>
Date: Fri, 6 Dec 2019 16:44:06 -0500

> With RPCSEC GSS, each user gets its own key as well.

Indeed, yes.

> we need to state here is how much key sharing is secure/recommended/

I disagree - this is an implementation choice not a TLS requirement.
This is the trap I think the draaft needs to avoid falling into.

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.

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

> encrypted TLS session. The TLS identity represents the client, not

But again, why not? Is that forbidden somehow? Or is it simply the
way most OS's implement it?

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Dec 2019 16:54:51 -0500

> On Dec 6, 2019, at 4:44 PM, Tom Talpey <[email-masked]> wrote:
> 

Not a trap, it's a conscious choice.

> authentication. But NFS is a different scenario.

An _NFS_ implementation is free to make more restrictive policy
choices. We are defining a generic RPC over TLS mechanism here.

If we want NFS to do something else, I think another document, an
NFS-specific document, is required.

> way most OS's implement it?

This document/protocol is restricting it to keep it simple. Nothing
to do with implementations.

All we want in this iteration is encryption. Using TLS for user
authentication is future work.

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

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 6 Dec 2019 17:35:08 -0500

> Not a trap,

If it's not, we seem to have an awful lot of difficulty getting out of it.

> it's a conscious choice.

That doesn't means it's not a trap.  Sigh!

> authentication. But NFS is a different scenario.

True, but if the implication seems to be that it is in some way inadequate
for
that scenario, we need to understand exactly why.   If it is truly
inadequate
we might decide that we don't want to do this for NFS.

> choices.

Yes, but why would it need to do so?   I'm not looking for spec text
here but I want to know enough to understand where we are going with
this for NFS.   It is going to be better than a privacy service that is
almost
never used, but I had thought was good enough for the Maeketer's of
Coke, Diet Coke,  and Coke Zero to share an NFS Client,  I realize
coke and Pepsi are paranoid about one another.

> We are defining a generic RPC over TLS mechanism here.

Yes, but I want to understand how helpful it is in dealing with NFSv4's
poor security.

> NFS-specific document, is required.

Sure, but I want to understand why or why not we would want to do
someting else.

> All we want in this iteration is encryption.

Yes, but it would be nice to get some better sense of how adequate it is.

> Using TLS for user

If we do that at all.

---

From: Chuck Lever <[email-masked]>
Date: Sun, 8 Dec 2019 11:58:44 -0500

Having had some time to digest this....

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

> 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

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

--
Chuck Lever
[email-masked]

---

From: Tom Talpey <[email-masked]>
Date: Mon, 9 Dec 2019 16:11:07 +0000

> Sent: Sunday, December 8, 2019 11:59 AM
> To: Tom Talpey <[email-masked]>

Ok!

> >>>>>>> On Dec 6, 2019, at 11:53 AM, David Noveck
> <[email-masked]>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey
> <[email-masked]>
> >>>>>> wrote:

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.

> the server has no way to distinguish between the latter two cases.

This is an excellent point and should be described in the document.

> opportunity to follow this thread.

I didn't see a cc on this, but I'm sure he reads nfsv4@ietf :-)

Tom.

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fnfsv4&amp;data=02%7C01%7Cttalpey%40mi
> crosoft.com%7Cd7a805eab3bf4f76b98308d77bffe8ea%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C637114211384334519&amp;sdata=0kWEWZz
> QqojRaQ4JCx%2BfAAXlg8QEwF6izKE5h9bj6MA%3D&amp;reserved=0

---

From: Chuck Lever <[email-masked]>
Date: Mon, 9 Dec 2019 11:25:54 -0500

> On Dec 9, 2019, at 11:11 AM, Tom Talpey <ttalpey=[email-masked]> wrote:
> 

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.

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

--
Chuck Lever