Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
Tom Talpey <tom@talpey.com> Fri, 06 December 2019 21:44 UTC
Return-Path: <tom@talpey.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60B6120074 for <nfsv4@ietfa.amsl.com>; Fri, 6 Dec 2019 13:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azj601rClnxP for <nfsv4@ietfa.amsl.com>; Fri, 6 Dec 2019 13:44:09 -0800 (PST)
Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29B7120090 for <nfsv4@ietf.org>; Fri, 6 Dec 2019 13:44:09 -0800 (PST)
Received: from [192.168.0.56] ([24.218.182.144]) by :SMTPAUTH: with ESMTPSA id dLOQizUrXG8KqdLORiUiT8; Fri, 06 Dec 2019 14:44:08 -0700
To: nfsv4@ietf.org
References: <CADaq8jdbQJFKS7xoeP+wLMhT0e8gSQQeqHDsV7PHNbT_YC+hSQ@mail.gmail.com> <11820D8F-A192-46EE-AD32-8561BCBE31A2@oracle.com> <MN2PR21MB143931B6F1DC40FF6A765AAEA05F0@MN2PR21MB1439.namprd21.prod.outlook.com> <CADaq8jf5Dh8bMmA2fcDKBknTbz-Oah1dZH=KRawjSRtOa6zh5w@mail.gmail.com> <63ADA2AC-815D-4899-B863-4FD321A968ED@oracle.com> <MN2PR21MB143950BE6F7130739D1280CAA05F0@MN2PR21MB1439.namprd21.prod.outlook.com> <741F6898-6A1B-4968-BC63-B9CDBB97C16F@oracle.com> <b1b36bba-2d60-3665-db67-0e58a2c82dc7@talpey.com> <CEB4BEE5-2BC3-44BB-873F-57FD24F00E45@oracle.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <c4a0ccc6-ebea-1732-d088-d645f970a3e5@talpey.com>
Date: Fri, 06 Dec 2019 16:44:06 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CEB4BEE5-2BC3-44BB-873F-57FD24F00E45@oracle.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfCeMy3cZAdOsw7ZiVCUSblrKPSnvMqrWg+flhZ5QdY20joTUhmjG1onSdvdMG4f69ysB7KxstoScBaFYtqBxqJH4NByciyMFQwQ3RVM3kEYC6bD3xFFS /Rzfvju5z27vwhJ/uoOUAaQ7X1PUk0MyIxERDHwhhFr22bTRrWlAKPSo
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Y8Xf--FH0UdQp_XoxGeSjd0we2o>
Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 21:44:12 -0000
On 12/6/2019 4:30 PM, Chuck Lever wrote: > > >> On Dec 6, 2019, at 3:58 PM, Tom Talpey <tom@talpey.com> wrote: >> >> On 12/6/2019 2:46 PM, Chuck Lever wrote: >>>> On Dec 6, 2019, at 2:24 PM, Tom Talpey <ttalpey@microsoft.com> wrote: >>>> >>>>> -----Original Message----- >>>>> From: Chuck Lever <chuck.lever@oracle.com> >>>>> Sent: Friday, December 6, 2019 2:12 PM >>>>> To: David Noveck <davenoveck@gmail.com>; Black, David >>>>> <David.Black@dell.com> >>>>> Cc: Tom Talpey <ttalpey@microsoft.com>; NFSv4 <nfsv4@ietf.org> >>>>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04 >>>>> >>>>> >>>>> >>>>>> On Dec 6, 2019, at 11:53 AM, David Noveck <davenoveck@gmail.com> >>>>> wrote: >>>>>> >>>>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <ttalpey@microsoft.com> >>>>> wrote: >>>>>>> -----Original Message----- >>>>>>> From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever >>>>>>> Sent: Friday, December 6, 2019 10:11 AM >>>>>>> To: David Noveck <davenoveck@gmail.com> >>>>>>> Cc: NFSv4 <nfsv4@ietf.org> >>>>>>> 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. 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. >>> 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? >> 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] Review of draft-ietf-nfsv4-rpc-tls04 David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04 Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04 Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Tom Talpey
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… David Noveck
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Tom Talpey
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Tom Talpey
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Tom Talpey
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… David Noveck
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Tom Talpey
- Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-n… Chuck Lever