Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
Chuck Lever <chuck.lever@oracle.com> Mon, 09 December 2019 16:26 UTC
Return-Path: <chuck.lever@oracle.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 41D681200B6 for <nfsv4@ietfa.amsl.com>; Mon, 9 Dec 2019 08:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 rtXiFuxfFGcx for <nfsv4@ietfa.amsl.com>; Mon, 9 Dec 2019 08:26:00 -0800 (PST)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 626F012000F for <nfsv4@ietf.org>; Mon, 9 Dec 2019 08:26:00 -0800 (PST)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xB9GO7WO046938; Mon, 9 Dec 2019 16:25:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=8JO2rA/EoBbICN4LC4/QJnKmpV4XrZkHNZiodCKqsqs=; b=CNcTsTezDPkNn+3+zTWjunheVaYBZXSAzKmXiXGIk/8OBwC/mfhup/eS2cvVstUG3xqm lFbaq6cZkhVr2GZxqlvNwXyYg0cmh0NT7ha5ITtX0/2p+t8fF4Eq+nu6QwlUFiToADLU 1H9/Zk7BIOnJ+ytHKIk9TAlrJJGgvFlfa1fwjKosM3M/cFuvjNOkMyacaRah0vGlbB79 pcIMjfiVOMUkbrca4PBaunB2+cNwHnfKKO1cfdSspT/mDkRckvGX2rEtknIWm/4nbnz3 uhiFvGhy+rN8y8bgWjrGRZIncdJij6bmsPt4rI/HeD5RON23jSMgtoXzXfKEE1A0e95/ 5w==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2wr41q0n9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Dec 2019 16:25:58 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xB9GPgOT058157; Mon, 9 Dec 2019 16:25:58 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2wsfv1ppnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Dec 2019 16:25:57 +0000
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xB9GPu2B006136; Mon, 9 Dec 2019 16:25:56 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Dec 2019 08:25:55 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <MN2PR21MB1439F5C7CF631859E70BCF47A0580@MN2PR21MB1439.namprd21.prod.outlook.com>
Date: Mon, 09 Dec 2019 11:25:54 -0500
Cc: Tom Talpey <tom@talpey.com>, NFSv4 <nfsv4@ietf.org>, Trond Myklebust <trondmy@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F019E78-F33A-4224-9795-C5A4B284A4F8@oracle.com>
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> <c4a0ccc6-ebea-1732-d088-d645f970a3e5@talpey.com> <8F73800E-1589-4EC4-90C0-FF349472C391@gmail.com> <MN2PR21MB1439F5C7CF631859E70BCF47A0580@MN2PR21MB1439.namprd21.prod.outlook.com>
To: Tom Talpey <ttalpey@microsoft.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9466 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912090141
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9466 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912090141
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/6WAHyXtHu6y__KxkjyioxKlbgZg>
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: Mon, 09 Dec 2019 16:26:02 -0000
> On Dec 9, 2019, at 11:11 AM, Tom Talpey <ttalpey=40microsoft.com@dmarc.ietf.org> wrote: > >> -----Original Message----- >> From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever >> Sent: Sunday, December 8, 2019 11:59 AM >> To: Tom Talpey <tom@talpey.com> >> Cc: NFSv4 <nfsv4@ietf.org> >> 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 <tom@talpey.com> wrote: >>> >>> 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. >> >> 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. 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. >> 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 :-) Doi. It was there at one point. Not sure why it disappeared. > 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
- [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