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

[Thomas Haynes <[e-mail]>]

> On Aug 1, 2017, at 10:29 AM, Olga Kornievskaia <[e-mail]> 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 <[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 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.
>>> 
>