Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

DISCUSS cleared.

On Thu, May 3, 2018 at 5:38 PM, Tom Haynes <[e-mail]> wrote:

> 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
> Status:         https://datatracker.ietf.org/doc/draft-ietf-nfsv4-
> flex-files/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-nfsv4-flex-files-19
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-
> nfsv4-flex-files
> Diff:           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 <[e-mail]> wrote:
>
> LGTM
>
> On Thu, May 3, 2018 at 4:50 PM, Tom Haynes <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <
>>> [e-mail]> wrote:
>>>
>>>> Hi, Tom,
>>>>
>>>> On Wed, Apr 11, 2018 at 12:38 PM, Tom Haynes <[e-mail]> 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
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>