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

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

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

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
> [email protected]
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> 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

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