Re: [nfsv4] New wording of Security Section for Flex Files

Thomas Haynes <> Tue, 01 August 2017 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F0E1322D3 for <>; Tue, 1 Aug 2017 12:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GcLmagSzWDnR for <>; Tue, 1 Aug 2017 12:44:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BB9112EB5D for <>; Tue, 1 Aug 2017 12:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-primarydata-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5MMDQtXoPRiB7zARBw/a5s6O6OimuYjH+JBw0vo5EhI=; b=ICO8TQFd6OWVCagbcKK6RZi7BQzQXDAqiS3RuDXZE0JUwXF3q/rCrqYo9126ExFsSDnHJx+UJDrnLSn9dFA6WLmX6LTBkwdcxrAakKBtimI9NuQ//ajt2a/2+WxmNLl0CgCssYLwQ0gGGWnmnkxr+DUlfQWyXLlWlhzB1Fulclo=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-108-9IZkobzdNFejJo70hKLJsQ-1; Tue, 01 Aug 2017 15:44:00 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Tue, 1 Aug 2017 19:43:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.1304.023; Tue, 1 Aug 2017 19:43:56 +0000
From: Thomas Haynes <>
To: Olga Kornievskaia <>
CC: Benjamin Kaduk <>, "" <>
Thread-Topic: New wording of Security Section for Flex Files
Thread-Index: AQHTBOJTubmEu3G57EqvOqsgsMtAEKJoh0CAgAdGdgCAACWLAA==
Date: Tue, 01 Aug 2017 19:43:56 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1094; 20:U2cnQly/3GVm4+OkSUY4Kr8ZXIDqsEAQ2rlXKoleZIfyqnvQ3j/e+fbx3oGJ622nGm979acjxE/0GakdJlNcFUXywiFW2u/rR/ABnWFh+Cwnv9NC+0CkdmnD3W8GE+KTE7gPsyp5bROVsBVwlwPZcvCMTvh8itjvD2Yt5wG04hQ=
x-ms-office365-filtering-correlation-id: 80a1f9ce-5416-4718-fb3b-08d4d915a608
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1094;
x-ms-traffictypediagnostic: BY2PR1101MB1094:
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089)(177329092695168);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(2016111802025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(6043046)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1094; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1094;
x-forefront-prvs: 0386B406AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(189002)(199003)(24454002)(377454003)(4326008)(6436002)(2171002)(7736002)(3280700002)(15650500001)(3660700001)(38730400002)(101416001)(6246003)(229853002)(110136004)(50986999)(54356999)(76176999)(6512007)(105586002)(3846002)(106356001)(8676002)(54906002)(8936002)(2900100001)(77096006)(6486002)(36756003)(68736007)(2906002)(561944003)(81166006)(81156014)(83716003)(14454004)(99286003)(6116002)(102836003)(53936002)(478600001)(97736004)(33656002)(305945005)(189998001)(86362001)(6506006)(53546010)(82746002)(66066001)(551544002)(5660300001)(2950100002)(6916009)(25786009)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1094;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 19:43:56.8292 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1094
X-MC-Unique: 9IZkobzdNFejJo70hKLJsQ-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [nfsv4] New wording of Security Section for Flex Files
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Aug 2017 19:44:07 -0000

> On Aug 1, 2017, at 10:29 AM, Olga Kornievskaia <> wrote:
> For some reason I didn't not receive the Tom's original email that
> addressed the comments so I'm replying within Ben's reply.
> On Thu, Jul 27, 2017 at 10:23 PM, Benjamin Kaduk <> wrote:
>> On Tue, Jul 25, 2017 at 01:07:02AM +0000, Thomas Haynes wrote:
>>> I hope the following addresses the issues brought up by Ben and Olga;
> I'd like the say the new wording is more specific but I still think
> the proposal tries to fit Kerberos security where it doesn't fit.

I agree that the traditional model of trust does not apply here, that
we have to shoehorn in a level of trust that basically states the
mds owns the data on the storage device.

But I believe if if we are willing to accept that trust model, RPCSEC_GSS
can be used here.

>> I think it does, thanks.  A couple notes inline.
>>> First paragraph of Section 15 is replaced by:
>>>   The pNFS extension 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
>>>   extension; 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.
>>> Replace Section 15.1 with:
>>>   RPCSEC_GSS version 3 (RPCSEC_GSSv3) [RFC7861] could be used to
>>>   authorize the client to the storage device on behalf of the metadata
>>>   server.  This would require that each of the metadata server, storage
>>>   device, and client would have to implement RPCSEC_GSSv3.  The second
>>>   requirement does not match the intent of the loosely coupled model
>>>   that the storage device need not be modified.  (Note that this does
>>>   not preclude the use of RPCSEC_GSSv3 in a loosely coupled model.)
>>>   Under this coupling model, the principal used to authenticate the
>>>   metadata file is different than that used to authenticate the data
>>>   file.  For the metadata server, the RPC credentials would be
>>>   generated by the same source as the client.  For RPC credentials to
>> "by the same source as" feels like a slightly awkward phrasing that leaves
>> me wondering if I don't quite properly understand the intended sentiment.
>> Isn't it basically required that the client has RPC credentials to talk
>> to the metadata server in order to do anything?
>>>   the data on the storage device, the metadata server would be
>>>   responsible for their generation.  Such "credentials" SHOULD be
>>>   limited to just the data file be accessed.  Using Kerberos V5 GSS-API
>>>   [RFC4121], some possible approaches would be:
>>>   o  a dedicated/throwaway client principal name akin to the synthetic
>>>      uid/gid schemes.
> If the identity is a throwaway, I don't see how this would work in
> practice (how would the user be informed of the passwords that go
> together with the throwaway identity to be used by NFS)? It just
> doesn't seem like a practical scheme to suggest.

I *think* the intent is that these identities would not have passwords.

>>>   o  authorization data in the ticket.
>>>   o  an out-of-band scheme between the client and metadata server.
> Is this meant to be an "out-of-band security scheme" not necessary
> Kerberos or GSS. That's something I would agree with. However, what's
> worse suggesting that GSSv3 should be implemented by the mode

“should” was not used, “could” was used. I may be guilty of trying to
describe an approach without having an actual implementation, but
I can envision if the same vendor supplied each of the metadata server,
client, and the storage device and did not want to define a control
protocol, they could use GSSv3’s RPC-application-defined
structured privilege assertion in a manner described in
Section 4.9.1 of RFC 7862.

I can be much more explicit in citing this approach, but I believe the
implementation constraints means that none will utilize it. However,
if multiple implementors wanted to do this, we could provide an
additional standards track document detailing the approach.

> l vs just
> stating that some out of band scheme is used. Earlier in the spec, it
> says that "With a loose coupling, the only control protocol might be a
> version of NFS.  As such, semantics for managing security, state, and
> locking models MUST be defined." Is stating that an out-of-band scheme
> is used satisfies the "MUST" of semantics for managing security?

No, I do not think so.

Even if NFSv4 were just a data center implementation, we would still
be asked (by the IETF and users/customers) to supply security.

My goal in this document is to provide enough plausible approaches
without handcuffing an implementation. I.e., if I supplied XDR and
verbiage for equivalent structures to copy_from_auth_priv,
copy_to_auth, and copy_to_auth_priv and with no intent to
ever implement it, then an implementation with 3rd party storage
devices would be prohibited.

>> Now I feel like I should have spent more time to carefully word the listing
>> in my original email :)
>> Though I think this text is fine to convey the needed information, at least.
>>>   [[AI15: Editorial Note: I have *SHOULD* and not *MUST* because there
>>>   might be some limit on the number of outstanding credentials due to
>>>   either the number of files or the number of client.  Feel free to
>>>   correct me.  --TH]]
>> I can think of schemes where there are no limits, but I am not prepared
>> to guarantee that all schemes one might want to use would be free of limits.
>> So the SHOULD seems fine to me.
>> Semi-relatedly, I forget exactly how much trust/coupling there is supposed
>> to be between the data and metadata servers/operators in this scheme.
>> In particular, if the metadata server is sufficiently trusted that it can
>> have a copy of the data server's kerberos credentials (the nfs/ keytab),
>> then there is quite a lot of flexibility, since the metadata server can
>> literally construct an arbitrary ticket and encrypt it to "itself" (i.e.,
>> the data server's keytab).  But I don't know whether it's appropriate
>> to mention this example in the document or not.
>>>   Depending on the implementation details, fencing would then be
>>>   controlled either by expiring the credential or by modifying the
>> Kerberos doesn't have a revocation (expiry prior to the original expiry)
>> story at all.  But since we are talking about RPCSEC_GSS, this text
>> is fine, since other GSS mechanisms might allow it :)
>> -Ben
>>>   synthetic uid or gid on the data file.  I.e., if the credentials are
>>>   at a finer granularity than the synthetic ids, it might be possible
>>>   to also fence just one client from the file.
>>> Replace 15.1.2 with:
>>>   With tight coupling, the principal used to access the metadata file
>>>   is exactly the same as used to access the data file.  The storage
>>>   device can use the control protocol to validate any RPC credentials.
>>>   As a result there are no security issues related to using RPCSEC_GSS
>>>   with a tightly coupled system.  For example, if Kerberos V5 GSS-API
>>>   [RFC4121] is used as the security mechanism, then the storage device
>>>   could use a control protocol to validate the RPC credentials to the
>>>   metadata server.