Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
Tom Haynes <loghyr@gmail.com> Fri, 04 May 2018 00:38 UTC
Return-Path: <loghyr@gmail.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 6D6F8127058; Thu, 3 May 2018 17:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oI_yfnBboI0l; Thu, 3 May 2018 17:38:47 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DD312704A; Thu, 3 May 2018 17:38:47 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id q22so16052120pff.11; Thu, 03 May 2018 17:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AfLGlKUpGe+ldRpRUKJGs2slE//JuU28+nKYZZnh8go=; b=Kkw2nHVMczVWAaoaZn3+xduEBlwvkg0n9PmiqFwG3ECUzb3jZcHIxA0qNYaJsPooTJ HsBy1gjsVe133Dulpf6vY0oQDTaOBLFgTDkeb1VcWGp5ewIyct0tkTgXvERG37sqMDHw +MNzOcfA/2elukmuT5/vmKFqh3OluZfvGOD92DOQcXOvG7q5+hQ8JWXmOX+SIx5gi94Z MI9T/TtCzUghkW4ArhlwwV9qbmyCZZbsj+WdsTGnCiNDZ8BTajA7fT1e0jkCio3MK8op XjNzu0iYYetnzf+JYaP6PPbv/Yf2j3FUofP95kQDHkMbW3NT5aOq0h/v0uEgItfXGXTR VNnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AfLGlKUpGe+ldRpRUKJGs2slE//JuU28+nKYZZnh8go=; b=V4VG1StfTtA062uyCOwzosuZlCwwzqQ2AnBPdUeFhRggaP1xRocJTkzH0tCGmMA16d stnvvoJvRdTmsriSdcTgsaGCspAqZiQqxQsZh4ggamgLb4L9ryH1xv5MeWPMYJGwc1t1 HEQGx+HHtG69AlZ5ZFzCQbba/rHm5cqwbtZaYUvzhfU4+eSSIdzFtv3agSK+2qDIq8hC DdmZJNHIg8a3h+VQihc/VNvAlHA9aqaPWGFnPt4nq7C49iU+r0IP1n2Vq2NwadoQHhwq HbvxNf9HthlCA4aGOmaeBkI/feE2xQudnekSgNg4rZbAeJowq/ilw8m9oUuKREoDy1jF xGuQ==
X-Gm-Message-State: ALQs6tByir6z1Ivdwp6nTNIkKlhM31Rwya97NBNb17+gIa6WwXkhjcds GrBwK9ajpBfjL1QxbFYk1zk=
X-Google-Smtp-Source: AB8JxZoxfDgCc70L6dAf1bI4nxuex1mGJpje4b922fZFAX33DpfhCQkFFow0AHdmwMfTtctGHRrPEg==
X-Received: by 2002:a17:902:d20a:: with SMTP id t10-v6mr25684067ply.364.1525394326588; Thu, 03 May 2018 17:38:46 -0700 (PDT)
Received: from kinslayer.corp.primarydata.com (63-157-6-18.dia.static.qwest.net. [63.157.6.18]) by smtp.gmail.com with ESMTPSA id k186sm39819748pfc.142.2018.05.03.17.38.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 17:38:46 -0700 (PDT)
From: Tom Haynes <loghyr@gmail.com>
Message-Id: <EABDCD68-EB4B-40B5-A711-C1A9B976F911@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2749AB80-ADB6-41A9-A91A-AD1A5C81E85D"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 03 May 2018 17:38:44 -0700
In-Reply-To: <CABcZeBNfqyNMvx7h+1_zrM6QoL3-YS=4-3rc80khs-PZBj3D9g@mail.gmail.com>
Cc: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, draft-ietf-nfsv4-flex-files@ietf.org, The IESG <iesg@ietf.org>, NFSv4 <nfsv4@ietf.org>, nfsv4-chairs@ietf.org
To: Eric Rescorla <ekr@rtfm.com>
References: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com> <9FD918F5-D08C-45FC-B6BB-30CBB3D4EC51@gmail.com> <CABcZeBPE5gV3KPpRpRxAtYRSSCZh8+3-fcf-1VsxF3AxmomnwQ@mail.gmail.com> <F2ADAD73-6AB3-45EF-B6FE-033E01F58D8E@gmail.com> <CAKKJt-e=81qyR3YXNb9imu8kzk6+nCYgMjeZqHNwt3xi4CfNxQ@mail.gmail.com> <CABcZeBPM_Rnb0QZvbvBpUCNd6yurtz0ipexUQscmnG_samb2RA@mail.gmail.com> <FD8AF7AF-632A-461C-A82A-BC0711B2F8D0@gmail.com> <CABcZeBMhEHhV1ie=TNqrj_arupO=kd27houBpZgdqZw1pPMfww@mail.gmail.com> <5C013DFE-96E3-4B74-B597-5F3FE1D314C6@gmail.com> <CAKKJt-deRBop1n8sv6dNaqUL_RUWxWMELutWubRdTOovKXEHwg@mail.gmail.com> <3670A5DF-4E11-4848-AE28-354F45F50D2B@gmail.com> <CAKKJt-dmcqLULhe_92wwOqVTcxKweB4YqiPKxoePRZAiQfv-Mg@mail.gmail.com> <CABcZeBMNQKV8m3Z46rsMKjraaHH5zCcKEe-Vo-b+Yo2SRQjTYg@mail.gmail.com> <897972F7-E7B8-4C6D-9470-CBD44B229CE7@gmail.com> <D64530FC-0FA1-4955-AA8A-31CEB32703BA@gmail.com> <CABcZeBNu+V+qTcw3FB=vDijN3-G-5w17rnDy5xSuativiXpU7g@mail.gmail.com> <9A3E372B-809E-4DA6-81FE-6ABBFC8E8DB6@gmail.com> <CABcZeBNfqyNMvx7h+1_zrM6QoL3-YS=4-3rc80khs-PZBj3D9g@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pQuOLgVy75epKGHQGt6qAe3juw4>
Subject: Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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, 04 May 2018 00:38:50 -0000
Hi Eric, Thanks for bearing with me and the review. The changes are posted here: A new version of I-D, draft-ietf-nfsv4-flex-files-19.txt has been successfully submitted by Thomas Haynes and posted to the IETF repository. Name: draft-ietf-nfsv4-flex-files Revision: 19 Title: Parallel NFS (pNFS) Flexible File Layout Document date: 2018-05-03 Group: nfsv4 Pages: 42 URL: https://www.ietf.org/internet-drafts/draft-ietf-nfsv4-flex-files-19.txt <https://www.ietf.org/internet-drafts/draft-ietf-nfsv4-flex-files-19.txt> Status: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/> Htmlized: https://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-19 <https://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-19> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-flex-files <https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-flex-files> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-flex-files-19 <https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-flex-files-19> Abstract: The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS which allows the use of storage devices in a fashion such that they require only a quite limited degree of interaction with the metadata server, using already existing protocols. Client-side mirroring is also added to provide replication of files. Spencer S. I know Spencer D is going to ask if the WG is okay with the changes, so I’ll help him out and ask away! Tom > On May 3, 2018, at 5:13 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > LGTM > > On Thu, May 3, 2018 at 4:50 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote: > More in line? > > > The combination of components in a pNFS system is required to > preserve the security properties of NFSv4.1+ with respect to > an entity accessing data via a client. The pNFS feature > partitions the NFSv4.1+ file system protocol into two parts, > the control protocol and the data protocol. As the control > protocol in this document is NFS, the security properties are > equivalent to that version of NFS. The Flexible File > Layout further divides the data protocol into metadata and data > paths. The security properties of the metadata path are equivalent > to those of NFSv4.1x (see Sections 1.7.1 and 2.2.1 of > [RFC5661]). And the security properties of the data > path are equivalent to those of the version of NFS used to > access the storage device, with the provision that the metadata > server is responsible for authenticating client access to the > data file. The metadata server provides appropriate credentials > to the client to access data files on the storage device. It > is also responsible for revoking access for a client to the > storage device. > > >> On May 3, 2018, at 3:45 PM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >> >> I'm sorry, but I still find this really opaque. >> >> What I'm looking for is a simple statement. Either "The security properties of the protocol described in this document are equivalent to those of NFS vX" >> or "The security properties of the protocol described in this document are equivalent to those of NFS vX if you do X, Y, and Z" or >> "The security properties of the protocol described in this document are different from those of NFS vX in the following ways" >> >> -Ekr >> >> >> >> On Wed, May 2, 2018 at 1:43 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote: >> Hi Eric, >> >> I haven’t seen a reply to this one. >> >> The current draft-18 has the changes mentioned in this thread. >> >> It has: >> >> >> The pNFS feature partitions the NFSv4.1+ file system protocol into >> two parts, the control path and the data path (storage protocol). >> The control path contains all the new operations described by this >> feature; all existing NFSv4 security mechanisms and features apply to >> the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]). The >> combination of components in a pNFS system is required to preserve >> the security properties of NFSv4.1+ with respect to an entity >> accessing data via a client, including security countermeasures to >> defend against threats that NFSv4.1+ provides defenses for in >> environments where these threats are considered significant. >> >> 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. >> >> Would having something like: >> >> The pNFS feature partitions the NFSv4.1+ file system protocol into >> two parts, the control path and the data path (storage protocol). >> The control path contains all the new operations described by this >> feature; all existing NFSv4 security mechanisms and features apply to >> the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]). The >> combination of components in a pNFS system is required to preserve >> the security properties of NFSv4.1+ with respect to an entity >> accessing data via a client, including security countermeasures to >> defend against threats that NFSv4.1+ provides defenses for in >> environments where these threats are considered significant. >> >> The data path is also constrained to security mechanisms of the >> NFS version being used between the client and the storage >> device. The metadata server authenticates the client access and provides >> 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. >> >> be better for you? >> >> Thanks, >> Tom >> >>> On Apr 11, 2018, at 2:25 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote: >>> >>> Hi Eric, >>> >>> It is the same. >>> >>> Section 2.2: >>> >>> It is RECOMMENDED to implement common access control methods at the >>> storage device filesystem to allow only the metadata server root >>> (super user) access to the storage device, and to set the owner of >>> all directories holding data files to the root user. This approach >>> provides a practical model to enforce access control and fence off >>> cooperative clients, but it can not protect against malicious >>> clients; hence it provides a level of security equivalent to >>> AUTH_SYS. It is RECOMMENDED that the communication between the >>> metadata server and storage device 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. >>> >>> (By the way, this contradicts the original text in my first paragraph below >>> and is why we needed a change.) >>> >>> And as for why, Section 15.1.1 discusses why RPCSEC_GSS is not >>> provided in this version of the Flex File Layout Type. >>> >>> Thanks, >>> Tom >>> >>>> On Apr 11, 2018, at 1:52 PM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >>>> >>>> Hi Tom. >>>> >>>> This text is clear, but I fear it doesn't answer the question I asked in my discuss: how does the security here compare to ordinary NFS and why. >>>> >>>> -Ekr >>>> >>>> >>>> On Wed, Apr 11, 2018 at 11:08 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> wrote: >>>> Hi, Tom, >>>> >>>> On Wed, Apr 11, 2018 at 12:38 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote: >>>> So actually, after thinking about, the discussion about securing the namespace on >>>> the storage device is wrong. >>>> >>>> The current text is: >>>> >>>> >>>> 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. >>>> >>>> My replacement would be: >>>> >>>> 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 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. >>>> >>>> Thanks for proposing new text here. >>>> >>>> Spencer (S) as shepherd and WG co-chair, does this look like something that would come as a surprise to the working group? >>>> >>>> Spencer (D) as AD >>>> >>> >> >> > >
- [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfs… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Thomas Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… spencer shepler
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Tom Haynes
- Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla