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, 3 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
>>>> 
>>> 
>> 
>> 
> 
>