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

[David Noveck <[e-mail]>]

> 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.

On Tue, Aug 1, 2017 at 1:29 PM, Olga Kornievskaia <[e-mail]>
wrote:

> For some reason I didn't not receive the Tom's original email that
> addressed the comments so I'm replying within Ben's reply.
>
> On Thu, Jul 27, 2017 at 10:23 PM, Benjamin Kaduk <[e-mail]> wrote:
> > On Tue, Jul 25, 2017 at 01:07:02AM +0000, Thomas Haynes wrote:
> >> I hope the following addresses the issues brought up by Ben and Olga;
>
> I'd like the say the new wording is more specific but I still think
> the proposal tries to fit Kerberos security where it doesn't fit.
>
> > I think it does, thanks.  A couple notes inline.
> >
> >> First paragraph of Section 15 is replaced by:
> >>
> >>    The pNFS extension partitions the NFSv4.1+ file system protocol into
> >>    two parts, the control path and the data path (storage protocol).
> >>    The control path contains all the new operations described by this
> >>    extension; all existing NFSv4 security mechanisms and features apply
> >>    to the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]).  The
> >>    combination of components in a pNFS system is required to preserve
> >>    the security properties of NFSv4.1+ with respect to an entity
> >>    accessing data via a client, including security countermeasures to
> >>    defend against threats that NFSv4.1+ provides defenses for in
> >>    environments where these threats are considered significant.
> >>
> >> Replace Section 15.1 with:
> >>
> >>    RPCSEC_GSS version 3 (RPCSEC_GSSv3) [RFC7861] could be used to
> >>    authorize the client to the storage device on behalf of the metadata
> >>    server.  This would require that each of the metadata server, storage
> >>    device, and client would have to implement RPCSEC_GSSv3.  The second
> >>    requirement does not match the intent of the loosely coupled model
> >>    that the storage device need not be modified.  (Note that this does
> >>    not preclude the use of RPCSEC_GSSv3 in a loosely coupled model.)
> >>
> >>    Under this coupling model, the principal used to authenticate the
> >>    metadata file is different than that used to authenticate the data
> >>    file.  For the metadata server, the RPC credentials would be
> >>    generated by the same source as the client.  For RPC credentials to
> >
> > "by the same source as" feels like a slightly awkward phrasing that
> leaves
> > me wondering if I don't quite properly understand the intended sentiment.
> > Isn't it basically required that the client has RPC credentials to talk
> > to the metadata server in order to do anything?
> >
> >>    the data on the storage device, the metadata server would be
> >>    responsible for their generation.  Such "credentials" SHOULD be
> >>    limited to just the data file be accessed.  Using Kerberos V5 GSS-API
> >>    [RFC4121], some possible approaches would be:
> >>
> >>    o  a dedicated/throwaway client principal name akin to the synthetic
> >>       uid/gid schemes.
>
> If the identity is a throwaway, I don't see how this would work in
> practice (how would the user be informed of the passwords that go
> together with the throwaway identity to be used by NFS)? It just
> doesn't seem like a practical scheme to suggest.
>
> >>    o  authorization data in the ticket.
> >>    o  an out-of-band scheme between the client and metadata server.
>
> Is this meant to be an "out-of-band security scheme" not necessary
> Kerberos or GSS. That's something I would agree with. However, what's
> worse suggesting that GSSv3 should be implemented by the model vs just
> stating that some out of band scheme is used. Earlier in the spec, it
> says that "With a loose coupling, the only control protocol might be a
> version of NFS.  As such, semantics for managing security, state, and
> locking models MUST be defined." Is stating that an out-of-band scheme
> is used satisfies the "MUST" of semantics for managing security?
>
> > Now I feel like I should have spent more time to carefully word the
> listing
> > in my original email :)
> > Though I think this text is fine to convey the needed information, at
> least.
> >
> >
> >>    [[AI15: Editorial Note: I have *SHOULD* and not *MUST* because there
> >>    might be some limit on the number of outstanding credentials due to
> >>    either the number of files or the number of client.  Feel free to
> >>    correct me.  --TH]]
> >
> > I can think of schemes where there are no limits, but I am not prepared
> > to guarantee that all schemes one might want to use would be free of
> limits.
> > So the SHOULD seems fine to me.
> >
> > 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.
> >
> >>    Depending on the implementation details, fencing would then be
> >>    controlled either by expiring the credential or by modifying the
> >
> > Kerberos doesn't have a revocation (expiry prior to the original expiry)
> > story at all.  But since we are talking about RPCSEC_GSS, this text
> > is fine, since other GSS mechanisms might allow it :)
> >
> > -Ben
> >
> >>    synthetic uid or gid on the data file.  I.e., if the credentials are
> >>    at a finer granularity than the synthetic ids, it might be possible
> >>    to also fence just one client from the file.
> >>
> >> Replace 15.1.2 with:
> >>
> >>    With tight coupling, the principal used to access the metadata file
> >>    is exactly the same as used to access the data file.  The storage
> >>    device can use the control protocol to validate any RPC credentials.
> >>    As a result there are no security issues related to using RPCSEC_GSS
> >>    with a tightly coupled system.  For example, if Kerberos V5 GSS-API
> >>    [RFC4121] is used as the security mechanism, then the storage device
> >>    could use a control protocol to validate the RPC credentials to the
> >>    metadata server.
> >>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>