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

Tom Haynes <loghyr@gmail.com> Thu, 03 May 2018 23:51 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 62E201270B4; Thu, 3 May 2018 16:51:00 -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 5Q2obeflIs02; Thu, 3 May 2018 16:50:58 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 A3969124BAC; Thu, 3 May 2018 16:50:58 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id p12so15959935pff.13; Thu, 03 May 2018 16:50:58 -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=7cl/YC3hiOScWXx8cqremrMLeyFk2j0lPK3fpVgjkUY=; b=PwmjBQKc9sdv0EW9RdzJl0bDojb9zMYR58gik1OnETcCBCTejogBnbZIfMz4Q//1sW vUuhJYJop0YSKVyoE/UFZlX6JQikcXmB8KGlFXEUejndDZfVQIxPRQK1fclR7MvT+M0C yj7ucIpps9avqFlv5K9dC6ljlRXOgZD3QqMlKdb8Aha2j7nSgR+mmWAdB1qEMDj5S8f/ 7hJ5amyUv/zT0K2T54qMn+79fmEZ2QIKnucr6OTbgYMRFxG5sOrQ6v1yvQTR1Aw6gJZd pjgJ9E+3AUaTOoF6Ppmi67DmlSLHAlL5V2yBrN/6rWRXmpwsYFGS9VMDNY+S3xITivYk vaeQ==
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=7cl/YC3hiOScWXx8cqremrMLeyFk2j0lPK3fpVgjkUY=; b=OXUWIkwW+yupkBr3ya6BYtSfF1VkyTBJXAd/YpN/fLi1O6z+TpCjjZFSjqRxHWsrfV jB+sYT/KtF27oQUN0326VV7+zuMKk1MakdjOpQWV8je7tGRlVAYpzzQxF807gqj36wa6 /AVBxQh3GgzIJAxL9phbhw3Zwo5vQa7sUWelWtuuhxRoUQgZ4sjru+8avNgQj3doYaNp rntvQPtWX1Y6PNZn8nwefh7CMHQ0Og87BnN7YUb9eRn7k+nd5kb+jUUPxw8jkVbsymUq rPhFnp+qY8Eptu28E94+aT1Ry6wPgXA7unuVP5wYhAhntOMFerbRsK9nNG5AM8tPM1Sm BUlg==
X-Gm-Message-State: ALQs6tDw2TymjByHxBF2hXk5i1GsFie9UIpiyX2K4Vi3VAp3SvTsOea3 rZhMbWktmeYTf5o6Sncr2SI=
X-Google-Smtp-Source: AB8JxZpsPNmi29xprkLu6OXs6vCJu3Mpo9KsOwK4iBYnW3yyV2yJpZgyGV9NeVs7N3WrP55dCwoIrw==
X-Received: by 2002:a63:9711:: with SMTP id n17-v6mr20204137pge.171.1525391458172; Thu, 03 May 2018 16:50:58 -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 h1sm30315828pfg.135.2018.05.03.16.50.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 16:50:56 -0700 (PDT)
From: Tom Haynes <loghyr@gmail.com>
Message-Id: <9A3E372B-809E-4DA6-81FE-6ABBFC8E8DB6@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CA75BA7A-A6E7-421C-9AC5-7CB3B26B3D9C"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 3 May 2018 16:50:55 -0700
In-Reply-To: <CABcZeBNu+V+qTcw3FB=vDijN3-G-5w17rnDy5xSuativiXpU7g@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>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pixMry7wTO1e5Zbn5JD-LespzYE>
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: Thu, 03 May 2018 23:51:00 -0000

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