[nfsv4] New wording of Security Section for Flex Files

[Thomas Haynes <[e-mail]>]

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.