Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-flex-files-15
Thomas Haynes <loghyr@primarydata.com> Tue, 16 January 2018 18:57 UTC
Return-Path: <loghyr@primarydata.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A5A12EA91 for <secdir@ietfa.amsl.com>; Tue, 16 Jan 2018 10:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primarydata.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 IItMsMPlmlZy for <secdir@ietfa.amsl.com>; Tue, 16 Jan 2018 10:57:40 -0800 (PST)
Received: from us-smtp-delivery-194.mimecast.com (us-smtp-delivery-194.mimecast.com [216.205.24.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC8812EAB0 for <secdir@ietf.org>; Tue, 16 Jan 2018 10:57:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata.com; s=mimecast20170802; t=1516129046; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=lQeGcCWsLh5WclnAMEtpNDeEr7jkETfnx8glsG79Fmc=; b=ZPh5W5S9KNsj3VHHzurKn4PuLQRwNW+IHW4ucFG0pJA8QoJoDYfvBBhAdg/1+7aKISim7UcPVaZopfHi2jY+KpCvy6TX8EsanETUuKzLFS3f3EI9j1vMF1uhkFSmyhKxl60YAXnQM2fu9mBbJfD9a0ZSLYjCGq70+s4T0VGrTUo=
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0118.outbound.protection.outlook.com [207.46.163.118]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-225-lgaimzIBM9ip7ui4hZNRFg-1; Tue, 16 Jan 2018 13:56:18 -0500
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com (10.164.166.21) by BY2PR1101MB1095.namprd11.prod.outlook.com (10.164.166.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Tue, 16 Jan 2018 18:56:15 +0000
Received: from BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) by BY2PR1101MB1093.namprd11.prod.outlook.com ([10.164.166.21]) with mapi id 15.20.0407.012; Tue, 16 Jan 2018 18:56:15 +0000
From: Thomas Haynes <loghyr@primarydata.com>
To: "Brian Weis (bew)" <bew@cisco.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, NFSv4 <nfsv4@ietf.org>, "draft-ietf-nfsv4-flex-files.all@ietf.org" <draft-ietf-nfsv4-flex-files.all@ietf.org>
Thread-Topic: [nfsv4] Secdir last call review of draft-ietf-nfsv4-flex-files-15
Thread-Index: AQHTi9WQTx5RarnLbUyAVOTsrpXN+aNwovgAgACajgCABaIqgA==
Date: Tue, 16 Jan 2018 18:56:15 +0000
Message-ID: <599605AF-7CB3-4A56-A26A-3DE56B805309@primarydata.com>
References: <151578274278.18715.11694935076324562133@ietfa.amsl.com> <75FDDF9F-C335-4488-9EAE-679DD9727A99@primarydata.com> <2D43D657-817F-4C43-A405-E7FB83C688AD@cisco.com>
In-Reply-To: <2D43D657-817F-4C43-A405-E7FB83C688AD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [63.157.6.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1095; 20:daUj76h4BIHJYG29OWFPvIF0HHcZ6OvMFPyQWuQDnddjbWk5M9ndG8QDNSqJ36U1piTGi/M9TpD61rqhvEr0KgQ+hVUVdW+LgIi+3bD1uajhE5xfm8ITaMEMYN99uRKxO6kwG2lMVrYNIqrH3TKyt9qpLiGgrehx+ZtiX7nc/bI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b048988c-1529-4f5b-fbec-08d55d12d1bf
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR1101MB1095;
x-ms-traffictypediagnostic: BY2PR1101MB1095:
x-microsoft-antispam-prvs: <BY2PR1101MB1095A577F74EDBF2FBEC9571CEEA0@BY2PR1101MB1095.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(95692535739014)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231023)(2400038)(944501161)(10201501046)(6041268)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:BY2PR1101MB1095; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR1101MB1095;
x-forefront-prvs: 0554B1F54F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(396003)(376002)(39380400002)(346002)(54094003)(252514010)(51914003)(24454002)(199004)(189003)(102836004)(77096006)(6486002)(54906003)(36756003)(316002)(606006)(4326008)(16200700003)(53946003)(82746002)(3660700001)(106356001)(3280700002)(99286004)(966005)(26005)(478600001)(8676002)(81156014)(59450400001)(25786009)(6506007)(53546011)(76176011)(81166006)(14454004)(53936002)(2906002)(229853002)(6512007)(86362001)(6116002)(3846002)(66066001)(83716003)(97736004)(33656002)(2900100001)(230783001)(8936002)(7736002)(54896002)(236005)(6306002)(68736007)(105586002)(6246003)(6436002)(6916009)(2950100002)(5660300001)(42262002)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1095; H:BY2PR1101MB1093.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-microsoft-antispam-message-info: iwqn/o95CS6Eil7TuhSL3H33QhQlU5vslmX5tHUlZoBTg4kM514Xm3McW/eEtGDo95jQvz75foB9c66s3r3vuA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: primarydata.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b048988c-1529-4f5b-fbec-08d55d12d1bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2018 18:56:15.1668 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1095
X-MC-Unique: lgaimzIBM9ip7ui4hZNRFg-1
Content-Type: multipart/alternative; boundary="_000_599605AF7CB34A56A26A3DE56B805309primarydatacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SQOkjjC00j6qOAkaR_djdmUYI0M>
Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-flex-files-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 18:57:44 -0000
On Jan 12, 2018, at 3:54 PM, Brian Weis (bew) <bew@cisco.com<mailto:bew@cisco.com>> wrote: Hi Thomas, On Jan 12, 2018, at 11:41 AM, Thomas Haynes <loghyr@primarydata.com<mailto:loghyr@primarydata.com>> wrote: Hi Brian, Thanks for the review - comments inline.. On Jan 12, 2018, at 10:45 AM, Brian Weis <bew@cisco.com<mailto:bew@cisco.com>> wrote: Reviewer: Brian Weis Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the Parallel Network File System (pNFS), which allows a storage system to store the metadata for files onto a metadata server, and data of that file onto a separate storage device. The document focuses on the interaction between the two types of servers, and the requirements of clients using a pNFS system. The document describes two models by which the metadata server and file storage server can communicate. One is a “tight coupling model”, in which the two types of servers directly communicate. In this model the metadata server can ensure that file access control state is synchronized between the two servers, and I believe that level of access control is equivalent to NFS v4.x today. From a security considerations perspective, this is perhaps best summarized in Section 2.2: “With tightly coupled storage devices, the metadata server sets the user and group owners, mode bits, and ACL of the data file to be the same as the metadata file. And the client must authenticate with the storage device and go through the same authorization process it would go through via the metadata server.” The other model is a “loose coupling model”, in which the client is authenticated and authorized by the metadata server, and is given access to the file server through the use credentials. However, there is no direct communications between the metadata server and the file server. The metadata server does not seem to provide a fine grained access control to files on the file server, but instead relies upon the client to enforce a less granular level of access control. [1] No, there is still direct communication between the metadata server and the file server. The difference is that it is via a storage protocol, in this case NFS. The access control is enforced by the metadata server. The client only get access to the file if it can get a layout. The layout can either provide read/write access or only read access. The metadata server can revoke that access at any point, so it is not correct to say that it depends on the client to enforce a less granular level of access control. Thanks for the clarification. To a non-NFS expert the relationship between layouts and access control wasn’t obvious. I wonder if this discussion could be added to Security Considerations? Hi Brian, I’ve already got that (and yes, I understand it is not sufficient if I have to spell it out :-): 15. Security Considerations ... The metadata server is primarily responsible for securing the data path. It has to authenticate the client access and provide appropriate credentials to the client to access data files on the storage device. Finally, it is responsible for revoking access for a client to the storage device. The metadata server enforces the file access-control policy at LAYOUTGET time. The client should use RPC authorization credentials for getting the layout for the requested iomode (READ or RW) and the server verifies the permissions and ACL for these credentials, possibly returning NFS4ERR_ACCESS if the client is not allowed the requested iomode. If the LAYOUTGET operation succeeds the client receives, as part of the layout, a set of credentials allowing it I/O access to the specified data files corresponding to the requested iomode. When the client acts on I/O operations on behalf of its local users, it MUST authenticate and authorize the user by issuing respective OPEN and ACCESS calls to the metadata server, similar to having NFSv4 data delegations. If access is allowed, the client uses the corresponding (READ or RW) credentials to perform the I/O operations at the data file's storage devices. When the metadata server receives a request to change a file's permissions or ACL, it SHOULD recall all layouts for that file and then MUST fence off any clients still holding outstanding layouts for the respective files by implicitly invalidating the previously distributed credential on all data file comprising the file in question. It is REQUIRED that this be done before committing to the new permissions and/or ACL. By requesting new layouts, the clients will reauthorize access against the modified access control metadata. Recalling the layouts in this case is intended to prevent clients from getting an error on I/Os done after the client was fenced off. How about: If access is allowed, the client uses the corresponding (READ or RW) credentials to perform the I/O operations at the data file's storage devices. … becomes The combination of file handle, synthetic uid, and gid in the layout are the way that the metadata server enforces access control to the data server. The directory namespace on the storage device SHOULD only be accessible to the metadata server and not the clients. In that case, the client only has access to file handles of file objects and not directory objects. Thus, given a file handle in a layout, it is not possible to guess the parent directory file handle. Further, as the data file permissions only allow the given synthetic uid read/write permission and the given synthetic gid read permission, knowing the synthetic ids of one file does not necessarily allow access to any other data file on the storage device. The metadata server can also deny access at any time by fencing the data file, which means changing the synthetic ids. In turn, that forces the client to return its current layout and get a new layout if it wants to continue IO to the data file. If the configuration of the storage device is such that clients can access the directory namespace, then the access control degrades to that of a typical NFS server with exports with a security flavor of AUTH_SYS. Any client which is allowed access can forge credentials to access any data file. The caveat is that the rogue client might have no knowledge of the data file’s type or position in the metadata directory namespace. If access is allowed, the client uses the corresponding (READ or RW) credentials to perform the I/O operations at the data file's storage devices. … Or do you want me to pull that new text into a new subsection 15.1 and slam the other subsections down? The Security Considerations section is well-written and helpful. I do have some suggestions for improving it, and also some questions. (1) Section 2.2: should the “recommended” in the Note be RECOMMENDED? Restricting access control to just superuser have access to the storage device seems like a valuable advice. sure (2) Section 2.2: The NOTE probably should provide guidance regarding protecting the network connections between the metadata server and the file server. For example, something like: “Communications between the metadata server and file server need to secured. If there is not adequate physical security (i.e., the servers are not co-located in a physically secure area), their communications MUST be protected for confidentiality (e.g., using TLS or IPsec).” No, the MUST is too strong here. We can recommend procedures, we can not REQUIRE them. I am fine with: Communications between the metadata server and file server SHOULD be secured. If there is not adequate physical security (i.e., the servers are not co-located in a physically secure area), their communications SHOULD be protected for confidentiality (e.g., using TLS or IPsec).” I understand the hesitation to make it a MUST, because it’s on a protocol that isn’t described in this document. But I think it’s reasonable to describe a risk and make a requirement that the risk be mitigated. I do not disagree with that statement. Certainly it’s not reasonable to require a particular method to be used to protect the protocol (which is why I suggested “e.g., using TLS or IPsec” above rather than “i.e.”). With today’s pervasive privacy threats to network traffic it’s hard to justify allowing metadata to traverse unprotected networks as clear-text (i..e, available to passive eavesdroppers). It’s also hard or to justify allowing security-relevent protocols to be transferring it without cryptographic integrity protection. It seems important to remind protocol developers that both concerns are applicable. How about something like this, where more rationale is given. Note that the requirement that the protocol must be protected, but no particular method of protection is not mandated. "Communications between the metadata server and file server MUST be secure from eavesdroppers and man-in-the-middle protocol tampering. The security measure could be due to physical security (e.g., the servers are co-located in a physically secure area), from encrypted communications, or some other technique.” I’m still hesitant, in part because I can’t make an ironclad rule as a standard’s author that I know I am going to violate with my own implementation. Also, I know that there might be existent storage devices which do not support NFS over TLS/IPsec/etc. Yes, physical security is the answer here, but I cannot in full confidence expect that an actual deployment meets all of these criteria. At some point, the burden is off of the protocol implementation and onto the deployment. If we change the MUST to a SHOULD, I am perfectly fine making the change. :-) (3) From the description of synthetic uids/gids in Section 2.2, I believe that the full range of file permissions (e.g., owner r/w/x) is honored in the tightly coupled model, but are restricted in the loosely coupled model to “owner r/w”, “group r”. If that is correct, I think the security considerations should explicitly mention that the effect of access permissions is reduced on the file server files. [2] I think the confusion here is that the files on storage device are not in the file hierarchy as seen on the metadata server. On a file by file basis on the storage device, we are giving the client either write modification access, read access, or no access at all. The client cannot remove the file (it would need to know the parent directory FH and the name of the file - neither of which it has). It can effectively remove the content if it has write permission (but nothing would prevent this in a tightly coupled model). Got it, thanks. (4) Section 2.2. In this phrase “it may be assigned some random synthetic uid/gid to deny access”, would a better word for “random” be “unused” or “unpredictable”? Also what is the security value intended by the use of a “random” value for synthetic uids/gids? In an earlier review (by Linda Dunbar), that phrase was changed: On the storage device, it may be assigned some random synthetic uid/ gid to deny access: -rw-r----- 1 19452 28418 1697 Dec 4 11:31 data_ompha.c When the file is opened on a client and accessed, it will try to get a layout for the data file. Since the layout knows nothing about the user (and does not care), whether the user loghyr or garbo opens the file does not matter. The client has to present an uid of 19452 to get write permission. If it presents any other value for the uid, then it must give a gid of 28418 to get read access. Further, if the metadata server decides to fence the file, it may change the uid and gid as such: -rw-r----- 1 19453 28419 1697 Dec 4 11:31 data_ompha.c What we could suggest would be something along the lines of: On the storage device, it may be assigned some unpredictable synthetic uid/gid to deny access. … Further, if the metadata server decides to fence the file, it should change the uid and/or gid such that these values neither match earlier values for that file nor match a predictable change based on an earlier fencing. Ugh, not sure I like the words. uid[N+1] != uid[N-1] && uid[N+1] != change(uid[N-1] -> uid[N]). I.e., do not set to recent old values (might fence back to an uid an older client already has) and do not use a fixed increment. So maybe in the first paragraph you mean “… some unpredictable and unused by any current client”? (5) In the “loose coupling model” file access actually enforced by the client, which presumably can be manipulated by an evil user. This is clearly stated n Section 2.2: “ The client is thus solely responsible for enforcing file permissions in a loosely coupled model.” Also, Section 2.2.1 mentions “a SETATTR would be sent to the storage device to set the owner and group of the data file”, and since here is no control protocol between the metadata server and the file server so I assume it is sent by the client. It is subtle, but this goes back to the fact (see [1]) that “no control protocol” does not imply “no communication between the metadata server and the storage device”. I.e., the MDS does the SETATTR. Also, I notice you are using the phrase “file server”, which probably impacts your view in your point 3 (see my [2]) - the term we use is storage device. There is no requirement that this device serve up data files as if they were in a filesystem. The storage device is limited in the operations that it can respond to from the client based on the information it is presented with. For example, the exports on the storage device can be configured such that the metadata server is the only one which can mount the exports. And since the metadata server only hands out File Handles to the clients, they would not be able to walk the namespace of the storage device. Thanks for the explanation … makes sense. Put another way, it seems as if any client that has credentials allowing it to access to the file server can access any file on the file system if it is chooses to do so (e.g.., if it is a malicious client). Is that correct? As with any NFS filesystem which uses an AUTH_SYS security model, each of the file handle, uid, and gid can be forged to gain access. In other words, this is nothing new. The security model for NFSv4.2 (and based on that, NFSv4.0 and NFSv4.1): [RFC7862] 17. Security Considerations NFSv4.2 has all of the security concerns present in NFSv4.1 (see Section 21 of [RFC5661]), as well as those present in the server-side copy (see Section 4.9) and in Labeled NFS (see Section 9.6). Which leads us to [RFC5661]: 2.2.1.1.1.2. Security Mechanisms for NFSv4.1 RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide security services. Therefore, NFSv4.1 clients and servers MUST support the Kerberos V5 security mechanism. The use of RPCSEC_GSS requires selection of mechanism, quality of protection (QOP), and service (authentication, integrity, privacy). For the mandated security mechanisms, NFSv4.1 specifies that a QOP of zero is used, leaving it up to the mechanism or the mechanism's configuration to map QOP zero to an appropriate level of protection. Each mandated mechanism specifies a minimum set of cryptographic algorithms for implementing integrity and privacy. NFSv4.1 clients and servers MUST be implemented on operating environments that comply with the REQUIRED cryptographic algorithms of each REQUIRED mechanism. 2.2.1.1.1.2.1. Kerberos V5 The Kerberos V5 GSS-API mechanism as described in [5] MUST be implemented with the RPCSEC_GSS services as specified in the following table: To paraphrase it, NFSv4.x clients and servers MUST support the Kerberos V5 security mechanism, but installations are not required to use Kerberos. I.e., this: mount -o vers=4.2,sec=sys server:/ /mnt means that any malicious user can use any client which can connect to the server to do whatever they want. In other words, this is not a reduction of the actual security from NFSv4.x. Thanks for the extensive explanation. It resolves the issue that I perceived. Thanks, Brian Unless I’m mistaken, this is a serious reduction of actual security from NFS 4.x, and also from the tight coupling model. This should be clearly stated in the security considerations section, so that protocol adopters and users understand the additional risks of the loose coupling model. For this reason, I've marked the review with "Has Issues" rather than "Has Nits". _______________________________________________ nfsv4 mailing list nfsv4@ietf.org<mailto:nfsv4@ietf.org> https://www.ietf.org/mailman/listinfo/nfsv4 -- Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com<mailto:bew@cisco.com>
- [secdir] Secdir last call review of draft-ietf-nf… Brian Weis
- Re: [secdir] [nfsv4] Secdir last call review of d… Thomas Haynes
- Re: [secdir] [nfsv4] Secdir last call review of d… Brian Weis (bew)
- Re: [secdir] [nfsv4] Secdir last call review of d… Thomas Haynes
- Re: [secdir] [nfsv4] Secdir last call review of d… Thomas Haynes
- Re: [secdir] [nfsv4] Secdir last call review of d… Brian Weis (bew)
- Re: [secdir] [nfsv4] Secdir last call review of d… Thomas Haynes