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

[Chuck Lever <[e-mail]>]

> On Oct 9, 2018, at 9:06 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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 serves
> IMA-capable clients or non-IMA-capable clients.  (That is, not a mix of
> both.)

This is another reason why the server should not prevent remote
access based on failures of its own provenance assessor. But
I begin to see why this should be a policy decision rather than
a specified requirement.


> The situation gets much more complicated if one posits a non-IMA
> implementation 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.

As long as FPI is self-describing, I don't see a strong need for
in-protocol indication (a type tag). However, if we believe there
might ultimately be more than one provenance mechanism in effect
at the same time, FPI accessors would need to steer the NFS server
to retrieve the correct flavor of FPI, and to steer tools to store
FPI in the correct location (a particular xattr, for example).

In that case a tag would be valuable, though I still struggle with
the lack of an actual example of a non-IMA provenance assessment
mechanism.


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

"varying levels of specification maturity" -- OK, that makes it
easier. I will add a 32-bit type tag and request a registry.


--
Chuck Lever
[e-mail]