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

[Thomas Haynes <[e-mail]>]

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.