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

[Chuck Lever <[e-mail]>]

> On Oct 8, 2018, at 5:17 PM, Everhart, Craig <[e-mail]> wrote:
> 
> Hi Chuck, I guess I don't understand this.
> 
> On 10/8/18, 3:50 PM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:
> 
>> You're declaring that kind of interaction to be not well-defined.  Why?
> 
>    This is precisely because the file system plays no part in provenance
>    assessment.
> 
>    If you want the server to do the assessment for all clients that access
>    it, there's no need to expose FPI via NFS. A trust relationship must
>    exist between the clients and server, of course,
> 
> And, because of the opaque nature of the specification, I have no reason to understand why this "of course" would have to be the case--or, for that matter, why the first sentence is true.  Intuitively, it's not obvious.

Actually, I think it is pretty obvious based on your earlier construction
of the use case:

>> you couldn't have the server do assessment once and for all, for all its clients, for all future uses of a file.

In fact, you normally don't want to do this if end-to-end, point-of-use
integrity checking is the goal. But let's entertain this use case for a
moment.

If an NFS server is performing provenance assessment for its clients,
why would the clients have any use for FPI? They would not need to
perform the assessment again, unless I have grossly misunderstood your
words. Thus, there is no need to expose any file's FPI to the NFS
server's clients whether they are participating or not.

In addition, provenance assessment is expensive in terms of memory, CPU
utilization, and network bandwidth. An obvious purpose of having the
server perform provenance assessment is to act as an offload service so
that clients do not have to bear the repeated assessment costs.

Now, related to the clause preceding "of course". The very first
sentence of Section 1.1 states:

   A keyed hash authenticates the identity of the last modifier of a
   file’s content and serves as a strong check of the content’s
   integrity.

In other words, there are two value-adds. First, the hash serves as a
check of the content's integrity. Second, the signature preserves the
hash cryptographically, and it authenticates the provenance authority.
In other words, the authority plus the checksum guarantee the contents
of the file by attaching an agent who is responsible for that content.

If FPI is not presented to the client, then the client has to trust
that the server has authenticated the FPI properly in order that the
trust chain is not broken. The client must authenticate the server to
guarantee that it is a well-known NFS server, possibly one within the
same administrative and security domain.


> If there's a defect in my intuition, I believe that the document has done little to correct my defects.

There's a tradition of avoiding duplication of material that is already
found in referenced documents. The Introduction is pretty clear now
about where the FPI format and policies are defined. If you have any
questions about those things, you need to consult documentation for
that mechanism.


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


> -----
> 
> My point in most of this is that one gives up a huge amount of understanding when the content semantics is completely opaque, as in this case.  Fine--it can be optional--but if it is present, what does it mean?  How should an implementation treat it?  What kind of implementation can someone write if they look only at the specification?

Why would an implementor have only this specification to look at? An NFS
implementor would have not only this document, but also the cited
materials, and very likely a provenance assessor already built into the
OS and used by local file systems. Otherwise there is no purpose for
implementing this extension.

The extension enables provenance assessment at point-of-use (which is
typically on NFS clients). The extension does not provide a full
assessment mechanism.

I find the bar you have set is unreasonably high. An implementer of an
NFS server is not responsible for deep understanding of the underlying
file system or the physical materials used to implement durable storage,
nor is the implementer responsible for the security policies implemented
by the operating system or 3rd party security modules. I don't see this
extension as being any different.


--
Chuck Lever
[e-mail]