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

[Rick Macklem <[e-mail]>]

Well, first I'll mention that fattr4_owner and fattr4_owner_group don't
seem to be defined anywhere (not in the RFCs such as 5661 I grep'd).
Presumably, they are strings, so you can define anything you want in them,
can't you?

Having said that. I think all you should do is say "if support of RPCSEC_GSS
is required, tight coupling needs to be used".
I think Olga suggested this in her first post on the topic?

If someone really wants to support RPCSEC_GSS/Kerberos for a loose
coupled pNFS server, let them figure out exactly how to do it and
write that up at that time. (I believe it might be possible, but doubt
anyone will actually implement it. Just like no one implements security
mechanisms other than Kerberos.)

rick
________________________________________
From: nfsv4 <[e-mail]> on behalf of Thomas Haynes <[e-mail]>
Sent: Friday, August 4, 2017 4:43:29 PM
To: Olga Kornievskaia
Cc: [e-mail]
Subject: Re: [nfsv4] New wording of Security Section for Flex Files

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]<mailto:[e-mail]>> wrote:



On Tue, Aug 1, 2017 at 3:59 PM, Thomas Haynes <[e-mail]<mailto:[e-mail]>> wrote:

On Aug 1, 2017, at 11:29 AM, David Noveck <[e-mail]<mailto:[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[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif].

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.