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

[Olga Kornievskaia <[e-mail]>]

Sorry might be a stupid question but why do you need to wait for another
version to add back "opaque_auth/or something" that carries the security
information?

On Fri, Aug 4, 2017 at 4:43 PM, Thomas Haynes <[e-mail]>
wrote:

> Hi,
>
> I’m going to top post to keep the focus on the problem at hand.
>
> In a nutshell, Olga is correct that we are not going to be able to secure
> loosely coupled flex files.
> The removal of “opaque_auth” prevents this from occurring.
>
> And while I have a bastardized approach using RPCSEC_GSSv3 structured
> privilege assertions,
> like we did for SSC - see Section 4.9.1. in RFC 7862, I think a better
> approach is to
> document the failure of securing loosely coupled flex files v1 and create
> a flex files v2
> which addresses a minor change in the XDR to:
>
> (a) Fix the stateid issue for loosely coupled NFSv4.x
> (b) Fix this issue for “opaque_auth” - which includes the issues raised by
> Olga at the end of
> her email.
>
> As to how we go about that, I see two scenarios:
>
> (1) We produce a single standards track document with a request for:
>
>      +-----------------------+-------+----------+-----+----------------+
>      | Layout Type Name      | Value | RFC      | How | Minor Versions |
>      +-----------------------+-------+----------+-----+----------------+
>      | LAYOUT4_FLEX_FILES    | 0x4   | RFCTBD10 | L   | 1              |
>      | LAYOUT4_FLEX_FILES_v2 | 0x6   | RFCTBD10 | L   | 1              |
>      +-----------------------+-------+----------+-----+----------------+
>
> (2) We produce two standards track documents, the first for
> LAYOUT4_FLEX_FILES
> and the second much smaller document which would have a normative
> reference to the first and encompass LAYOUT4_FLEX_FILES_v2. It would
> have the delta XDR and the new required text.
>
> What I am approaching the WG for is consensus on which approach to take.
> For
> me, the first is less administrative headache and the second preserves a
> much
> cleaner separation of the minor versioning.
>
> Oh, and in case it is not clear, I am very appreciative of Olga’s review in
> getting me to see the flaw in this document.
>
> Thanks,
> Tom
>
>
> On Aug 2, 2017, at 9:03 AM, Olga Kornievskaia <[e-mail]> wrote:
>
>
>
> On Tue, Aug 1, 2017 at 3:59 PM, Thomas Haynes <[e-mail]>
> wrote:
>
>>
>> On Aug 1, 2017, at 11:29 AM, David Noveck <[e-mail]> wrote:
>>
>> > Is stating that an out-of-band scheme
>> > is used satisfies the "MUST" of semantics for managing security?
>>
>> Probably not, but the "MUST" can always be changed to a "SHOULD" :-)
>>
>> The problem is deeper here.   The job of a standards-track document that
>> defines a protocol or layout type is to clearly tell the implementer what
>> must be done to implement the protool or layout type.  Despite the possble
>> issues with the specificity of any of these three possible alternatives,
>> the big problem is the fact that there is more than one.  If the client and
>>  MDS do not pick the same one, or they do and that one is not fully
>> specfied, they will not nteroperate.  If that is the case, then the
>> document is not ready.
>>
>> I think the treatment of security with tight coupling is sufficiently
>> clear to implement from and has been for a while.  With regard to security
>> for loose coupluing, what you have is essentially a promise to provide a
>> specfication at some later date.  I don't think the IESG is going to be OK
>> with that.
>>
>> You have focusing on it being plausible in the sense of convincing people
>> that this can be done
>> (i.e. that a definition along these lines can be produced) which it can,
>> but I think the IESG is going to want you to show them that it has been
>> done (i.e. that the definiton has been arrived at), and you are a ways away
>> from being there.
>>
>>
>> The problem isn’t that we are pushing off a specification to a later
>> date, but rather that the security is implementation specific. The client
>> and MDS are forced to pick the same one.
>>
>> Section 1.7.1 RFC 5661 is quite clear that:
>>
>>    As with previous versions of NFS, the External Data Representation
>>    (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4.1
>>    protocol are those defined in [2] and [3].  To meet end-to-end
>>    security requirements, the RPCSEC_GSS framework [4] is used to extend
>>    the basic RPC security.  With the use of RPCSEC_GSS, various
>>    mechanisms can be provided to offer authentication, integrity, and
>>    privacy to the NFSv4 protocol.  Kerberos V5 is used as described in
>>    [5] to provide one security framework.  With the use of RPCSEC_GSS,
>>    other mechanisms may also be specified and used for NFSv4.1 security.
>>
>> Note that nothing is stated as to how the TGT are constructed, so Ben’s
>> approach:
>>
>> 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.
>>
>>
>> meets the requirements of RFC 5661 and the loosely coupled model. The
>> details
>> of how the mds gets the storage device’s keytab are up to the
>> implementation
>> (just as how the storage device gets the keytab in the first place).
>>
>>
>> We could wait until the first implementation and then make that a
>> standard, but I
>> don’t like that approach.
>>
>
> I think you would agree that implementations frequently find issues with
> this spec. But yes, all the previous specs when ahead prior to full
> implementations. And that's why we have versions, right? It'll be fixed
> later.
>
> I'm thinking like an implementor and I have questions that cause me
> problems. Let's for the moment assume that metadata server will be running
> on the same machine as the normal KDC and have access to the principals
> database. To construct these tickets you need a new service as it will not
> be a part of the (existing) KDC. Let's assume it is practical.
>
> Let's talk about of the fact that user doesn't know the password for the
> synthetic identity.
>
> Metadata server gets a flexile layout request. It, at some point,
> constructs a service ticket  (session key, "synthetic identity", ...
> )encrypted with data server's key. It needs to encrypt the "session key"
> with the client's TGT key so that the client can then use the service
> ticket against the data server. How doest the client gets this ticket?
>
> In normal kerberos, the client would initiate request for a service
> ticket. But here the client doesn't know the "synthetic identity" ahead of
> time.  And even if the intent is that once the ffds_owner is returned, then
> the client would request a service ticket for the specified identity. Well
> in that case, the client would need to provide the password for the
> synthetic identity. But he doesn't know the password so that's not going to
> work. So at this point we can't use normal kerberos to get a service ticket
> for the synthetic identity.
>
> Initially, in some earlier drafts of the spec the creds was "opaque_auth"
> but it's not no longer there so I don't see a way of passing the service
> ticket, encrypted session key. So I think if you want to pass the service
> ticket back, then you need to add the "opaque_auth" back to the structure?
> Ok now, we are just passing them back, how are we going to protect against
> replay attacks? typically there is a challenge response. So perhaps require
> that LAYOUTGET is always done with krb5i/p?
>
> Also on the (linux) client side I would suspect you won't be able to use
> standard krb5 libraries to deal with the processing the "service ticket".
> You might have issues getting the gssd given that the identity inside the
> ticket doesn't "match" the running identity of the user (I'm not 100%sure
> here). *i understand that this comment is really implementation specific
> and not specs job*
>
> Having said all that, I still feel like we are proposing an "SPKM"
> security here. It will not be practical and later on would be removed. I'd
> say AUTH_SYS or GSSv3 should be used.
>
> And if you still want to keep Kerberos then I guess I'm proposing (a) add
> "opaque_auth cred" back to the ff_data_server_4 and (b) require that
> LAYOUTGET much be done with krb5i/p. (c) as suggested by Ben, issue
> "service tickets" and explicitly specify what is being passed back, need to
> dig out the Kerberos spec and write out how the "synthetic identity"
> information is fitted into those Kerberos structures. I feel that you need
> to do this because the spec isn't use standard Kerberos so can't just say
> see Kerberos spec.  (d) explicitly specify that metadata must have access
> to the principal database for the non-synthetic client and the storage
> servers.
>
> I wonder is "opaque_auth" the right structure? I think the spec defines it
> upto 400bytes. Is that sufficient to capture service ticket + the encrypted
> stuff for the client. I dunno.
>
> You mentioned that RFC5661 doesn't state anything as to how TGT are
> constructed. That's only true because it states the Kerberos v5 and cites
> the spec is used. This proposal does not follow Kerberos v5 spec -- the
> proposal does not engage in KRB_AP/REP sequence which is what kerberos is
> -- and thus i feel it must specify what goes into the service ticket.
>
>
>