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

[David Noveck <[e-mail]>]

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

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

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.

> An _NFS_ implementation is free to make more restrictive policy
> 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.

> If we want NFS to do something else, I think another document, an
> 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
> authentication is future work.

If we do that at all.

On Fri, Dec 6, 2019 at 4:58 PM Chuck Lever <[e-mail]> wrote:

>
>
> > On Dec 6, 2019, at 4:44 PM, Tom Talpey <[e-mail]> wrote:
> >
> > On 12/6/2019 4:30 PM, Chuck Lever wrote:
> >>> On Dec 6, 2019, at 3:58 PM, Tom Talpey <[e-mail]> wrote:
> >>>
> >>> On 12/6/2019 2:46 PM, Chuck Lever wrote:
> >>>>> On Dec 6, 2019, at 2:24 PM, Tom Talpey <[e-mail]>
> wrote:
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Chuck Lever <[e-mail]>
> >>>>>> Sent: Friday, December 6, 2019 2:12 PM
> >>>>>> To: David Noveck <[e-mail]>; Black, David
> >>>>>> <[e-mail]>
> >>>>>> Cc: Tom Talpey <[e-mail]>; NFSv4 <[e-mail]>
> >>>>>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of
> draft-ietf-nfsv4-rpc-tls04
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Dec 6, 2019, at 11:53 AM, David Noveck <[e-mail]>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <[e-mail]>
> >>>>>> wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
> >>>>>>>> Sent: Friday, December 6, 2019 10:11 AM
> >>>>>>>> To: David Noveck <[e-mail]>
> >>>>>>>> Cc: NFSv4 <[e-mail]>
> >>>>>>>> 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.
>
> Not a trap, it's a conscious choice.
>
>
> > 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.
>
> 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.
>
>
> >> 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.
> >
> >>>> 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?
>
> 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.
>
>
> >>> 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
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>