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

[Olga Kornievskaia <[e-mail]>]

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 <[e-mail]> 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 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.

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

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