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

[Olga Kornievskaia <[e-mail]>]

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.