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

From: Thomas Haynes <[email-masked]>
Date: Tue, 25 Jul 2017 01:07:02 +0000

I hope the following addresses the issues brought up by Ben and Olga;

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

   o  authorization data in the ticket.

   o  an out-of-band scheme between the client and metadata server.

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

   Depending on the implementation details, fencing would then be
   controlled either by expiring the credential or by modifying the
   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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Jul 2017 21:23:33 -0500

> I hope the following addresses the issues brought up by Ben and Olga;

I think it does, thanks.  A couple notes inline.

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

>    o  an out-of-band scheme between the client and metadata server.

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.

>    either the number of files or the number of client.  Feel free to

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.

>    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