Re: [nfsv4] comments w.r.t. flex layout draft 12

[Thomas Haynes <[e-mail]>]

> On Jul 24, 2017, at 1:43 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Fri, Jul 21, 2017 at 09:41:40PM +0000, Rick Macklem wrote:
>> Hi,
>> 
>> Overall, it looks good to me.
>> 
>> First off, there is one generic issue I thought I'd bring up...
>> - w.r.t. Kerberos...shouldn't it be talking about Rpcsec_gss instead of Kerberos,
>>  just in case someone uses another security mechanism someday?
> 
> Arguably it should, yes.

My bad - too much caffeine and not enough sleep. I knew I should
not have been writing down the word “kerberos”.

I’ll tie this back into Section 1.7.1 of RFC 5661.


>  But the GSSAPI way to do the sort of thing
> needed here involves GSS_Export_sec_context/GSS_Import_sec_context, which
> is formally only specified for interprocess transfer on a single machine.
> (After all, GSS-API objects are permitted to be opaque handles referring
> to data stored outside of the current process.)  Some implementations
> do just dump a serialized data structure that could in theory be sent
> over the network and used elsewhere, but there is no standardized way to
> do so.  Kerberos tickets, on the other hand, are standardized and quite
> interoperable.  But the specification might do well from using more general
> terms and only listing Kerberos tickets as an example.
> 
>> - Also, I'll admit I didn't understand the last two sentences of Sec. 15.1.1.
>> - Why is the metadata server generating TGTs. Is this referring to the case of
>>   the metadata doing I/O on the storage server? Or is this specific to some part of
>>   RPCSEC_GSS_V3 (which I'll admit I've never looked at;-). If the latter, just ignore
>>   my ignorance;-)
> 
> My (admittedly hasty) reading was that the metadata server is generating
> "credentials" that the client then uses in subsequent communication with
> the data server.  Those newly minted credentials ought to be limited to
> just the file access that was indicated to the MDS, whether by having
> a dedicated/throwaway client principal name akin to the synthetic uid/gid
> schemes, authorization data in the ticket, or some out-of-band scheme.
> In order to fit nicely into the existing deployments using Kerberos,
> the minted credentials need to be Kerberos credentials.
> 
> That said, I see no reason why they need to be a TGT -- a service ticket
> for the data server principal would work just fine and would save the
> client a round-trip to the KDC.  Doing so would also provide a bit more
> implementation flexibility, if the MDS is given access to the long-term
> key of the data servers (as it could then just print tickets locally and
> not need to interact with the KDC).  Another option for this sort of thing
> would be the S4U2Proxy extension, that lets the MDS request that the KDC
> print the desired tickets and the KDC can do authorization checking and
> apply restrictions to the generated tickets/etc.

Thanks for the suggestion, I’ll try to write this in to the next draft.

My main concerns here were:

1) Having sufficient requirements to meet the ones we have at the standards body level.
2) Giving enough detail that it did not look like hand waving.
3) Not lock an implementation down.




> 
> -Ben
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>