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

[Benjamin Kaduk <[e-mail]>]

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 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.
> 
>    o  authorization data in the ticket.
> 
>    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.


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