Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-02.txt

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 09, 2018 at 11:24:13AM -0400, Chuck Lever wrote:
> 
> 
> > On Oct 8, 2018, at 5:17 PM, Everhart, Craig <[e-mail]> wrote:
> > 
> >    and there would need
> >    to be a strong guarantee that the network between the server and clients
> >    is of very high integrity. Perhaps the use of a GSS integrity service
> >    would be required in such a use case.
> > 
> > Why does this impose additional requirements on this OPTIONAL, but otherwise completely opaque, service?  What additional requirements does it levy?  Why wouldn't, for example, it be totally adequate to apply other techniques for recovering incompatibility?  For example, if the provenance information were to include, effectively, a checksum of the content, what is the range of meaningful actions available to the provenance assessor if the file object's checksum were not to match that in the provenance's checksum?
> 
> Again, "meaningful actions" are policy to be determined by the provenance
> assessor. This is a separate, independent security module that is not a
> part of the storage or file system stack.
> 
> If you have any questions about the assessor, have a look at the IMA
> reference cited at the end of the document, or review the IMA
> implementation in the Linux kernel.

I have a question about "the assessor", but it is not about the internals
of IMA's operation.  In particular, it relates to the usage of the definite
article.  As Craig has noted upthread, any given NFS server can be serving
a broad array of clients and datasets, to the extent that it seems
unreasonable to assume that any given NFS server either only servers
IMA-capable clients or non-IMA-capable clients.  (That is, not a mix of
both.)  The situation gets much more complicated if one posits a non-IMA
implemnetation of provenance information.  In mixed environments one cannot
assume that provenance information implies IMA -- for well-behaved
interoperability there must be some in-protocol indication of which of the
many potential assessors should receive the information.

Also upthread the claim was made that with no specification for IMA or
other assessors, there cannot be a registry.  I don't think this is
actually true; e.g., an open registration policy such as expert
review or FCFS can allow for codepoint allocation for protocols at
varying levels of specification maturity.  I actually think a registry
makes the most sense here and would suggest the Expert Review procedure for
it.

-Ben