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

From: [email-masked]
Date: Mon, 08 Oct 2018 07:56:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 WG of the IETF.

        Title           : File Content Provenance for Network File System version 4
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-integrity-measurement-02.txt
	Pages           : 13
	Date            : 2018-10-08

Abstract:
   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables file provenance information to be conveyed
   between NFS version 4.2 servers and clients.  File provenance
   information authenticates the creator of a file's content and helps
   guarantee the content's integrity from creation to use.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-integrity-measurement/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-integrity-measurement-02
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Chuck Lever <[email-masked]>
Date: Mon, 8 Oct 2018 11:03:25 -0400

> On Oct 8, 2018, at 10:56 AM, [email-masked] wrote:
> 
> 

With this revision I hope to have addressed Craig's, Bruce's, and Dave's
review comments. I've introduced text that explains the broad architecture
of provenance assessment and who is responsible for the assessment policy
and FPI format. A number of smaller corrections and clarifications have
also been done.

I believe the only outstanding issue is Section 5.2.1, which will describe
the issues around authorizing FPI updates.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 8 Oct 2018 15:48:11 +0000

In the "1. Introduction", the opaque provenance information is described as including a "keyed hash, such as an HMAC [RFC2104]" without any indication as to the management of the key information.  Must that information, also, be taken on faith?  What's the basis for this claim?  Is it required for all provenance information, or just for some?

There's an effort made in this draft to distinguish participating/non-participating clients and servers.  Because this draft really talks about only one kind of provenance information, what is to be done with clients or servers that participate in one but not all kinds of provenance information?

Apparently, the updating of file content must be done in conjunction with updating of provenance information.  What can be done to make such operations mutually atomic?  What's to be done with a server that wants to vet provenance information, but notices that the stored provenance information is not correct with respect to the stored file content?  Surely there are other, similar, race-like conditions.

		Craig

On 10/8/18, 10:58 AM, "nfsv4 on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

    
    _______________________________________________
    nfsv4 mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Mon, 8 Oct 2018 12:42:44 -0400

Hi Craig -

> On Oct 8, 2018, at 11:48 AM, Everhart, Craig <[email-masked]> wrote:
> 

The Introduction describes that as "out of scope" but suggests key
management can be done via another distribution channel and stored
locally in a Trusted Platform Module.

Section 1.1:
   A Trusted Platform Module [TPM-SUM] can seal the key material used to
   sign and verify file content.  Distributing and protecting such key
   material is outside the scope of the OPTIONAL extension specified in
   this document.

> There's an effort made in this draft to distinguish participating/non-participating clients and servers.  Because this draft really talks about only one kind of provenance information, what is to b…

The Introduction states that "participating" clients have to agree on
using the same provenance assessor.
 
Section 1.1:
   NFS acts as a conduit by which file provenance information and file
   content move between storage on an NFS server and the provenance
   assessor where that content is to be accessed.  NFS peers accessing a
   set of shared files must all agree on the at-rest file provenance
   information format.  The format is specified by the provenance
   assessor and is therefore not described in this document.

The document later states that provenance assessors have to be prepared
to encounter unrecognized provenance information.

Section 5.3:
   A provenance assessor on an NFS version 4.2 peer needs to be prepared
   to deal with file provenance information it does not recognize or
   cannot parse.  Typically its policy treats this case as a provenance
   verification failure.

Again, I'm struggling to see the purpose of deploying multiple
incompatible FPI schemas concurrently. Do you have something specific in
mind?

> Apparently, the updating of file content must be done in conjunction with updating of provenance information.  What can be done to make such operations mutually atomic?

I don't believe these "race conditions" are consequential, typically.
While the provenance information does not match the content, assessors
will prevent access to that content.

Moreover, attaching FPI is usually a final step before content distri-
bution, performed separately via a tool. The tool, not the file system
stack, has access to the private signing key.

> What's to be done with a server that wants to vet provenance information, but notices that the stored provenance information is not correct with respect to the stored file content?  Surely there are other, similar, race-like conditions.

NFS servers do not vet the provenance information during remote access
of content. A provenance assessor on the server may prevent access only
to local accessors.

Section 5.3:
   Note that an NFS version 4.2 server may use a provenance assessor to
   prevent access by local users to protected files.  To enable NFS
   version 4.2 clients to do their own assessment, an NFS version 4.2
   server should never prevent remote access to clients if local
   provenance assessment fails.

If the content and FPI are out of sync, local assessment on the server
prevents only local access to that content.

Because FPI is meant to be end-to-end protection, the goal here is to
perform provenance assessment immediately before the content is to be
used. Because it is typically expensive, assessment should be done as
few times as needed (once?) to guarantee protection. No point in having
the server do it and then the client do it again.

--
Chuck Lever
[email-masked]

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 8 Oct 2018 17:40:51 +0000

Hi Chuck, thanks for the quick reply.

On 10/8/18, 12:43 PM, "nfsv4 on behalf of Chuck Lever" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Craig -

    
    Section 1.1:
    
Are we talking about a keyed hash or signing/verifying the content (as in encrypting a hash)?  They're similar, but different, kinds of operations.

    
    
    Section 1.1:

So, NFS, as an interchange protocol, is not being tasked with even the little bit of interoperability necessary to identify which kind of provenance information is in use?

Recognized how?
    
    Section 5.3:

I bring up the issue because NFS can transit multiple storage domains.  Think of it as having multiple authentication domains.  It's the job of the communication protocol not only to deal with how the happy path works, but what happens when it isn't the happy path.

    

    
    Section 5.3:

    
So, finally, a piece of architecture accidentally falls out: you couldn't have the server do assessment once and for all, for all its clients, for all future uses of a file.  You're declaring that kind of interaction to be not well-defined.  Why?

		Thanks,
		Craig

    --
    Chuck Lever
    [email-masked]

---

From: Chuck Lever <[email-masked]>
Date: Mon, 8 Oct 2018 15:50:12 -0400

> On Oct 8, 2018, at 1:40 PM, Everhart, Craig <[email-masked]> wrote:
> 

A TPM can be used on end-points to store public keys that can be
used for provenance assessment. This would be typical for a mobile
device using an IMA-protected root file system, for instance, or
on systems where a strong guarantee that the key material is not
tampered with is required.

> So, NFS, as an interchange protocol, is not being tasked with even the little bit of interoperability necessary to identify which kind of provenance information is in use?

No it is not. FPI interoperability is handled (or not) by the
provenance assessor.

>    to encounter unrecognized provenance information.

Given that the provenance assessor is responsible for interoperability,
I don't see how that question is relevant to NFS or this document.

If you have a problem with this part of the architecture, that is
really about the provenance assessment mechanism, not about the way
NFS transports the FPI. You should take that up with the IMA
community (or whomever is developing your favorite provenance
assessor).

It's outside of the IETF's purview to maintain a registry of FPI
types, especially because there are no FPI types defined by any
standards.

> I bring up the issue because NFS can transit multiple storage domains.  Think of it as having multiple authentication domains.  It's the job of the communication protocol not only to deal with how…

FPI is end-to-end. It doesn't matter how many different copies of
the file there are or on how many NFS servers a protected file
might have resided before an application on a client sees it. FPI
is not a local at-rest checksum. It is not replaced every time a
fresh copy of a file is written on a new server; it is copied
along with the content.

The provenance information and the content must match before the
content is used by an application or OS, end of story. The file
system, whether it is a local FS like ext4, or one that has lots
of distributed moving parts, like CephFS, does not get a say in
whether the content is usable at its end-point.

> So, finally, a piece of architecture accidentally falls out: you couldn't have the server do assessment once and for all, for all its clients, for all future uses of a file.

See above: FPI is assessed at point of use, not point of storage. No
part of the storage subsystem or file system plays any part in
provenance assessment decisions.

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

I could weaken the statement to "a server should not prevent access to
_participating_ clients."

--
Chuck Lever
[email-masked]

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 8 Oct 2018 21:17:47 +0000

Hi Chuck, I guess I don't understand this.

    
    
    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.  If there's a defect in my intuition, I believe that the document has done little to correct my defects.

    and there would need

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?

-----

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?

		Craig

---

From: Chuck Lever <[email-masked]>
Date: Tue, 9 Oct 2018 11:24:13 -0400

> On Oct 8, 2018, at 5:17 PM, Everhart, Craig <[email-masked]> wrote:
> 
> 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.

> 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 adequa…

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…

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
[email-masked]

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 9 Oct 2018 15:56:41 +0000

Let's go back to the document proper.  I think it contains the fundamental disagreement.

To me, the point is to achieve interoperation.  The question is--"interoperation of what"?

There's an attractive feature that you describe: a keyed hash that's a strong check on the integrity of file content.  Suppose that I want to play, but I'm not running Linux, and/or I cannot run Linux for one reason or another.  I might even have a TPM on a client or a server.  How do the parts interrelate?  If I come up with some scheme that encodes provenance as a tree, saying how the file content is a product of many different originators (let's just say an executable file built by linker X from objects Y and Z, where each of those objects are based on a signed source file and a given compiler), how do I relate to what you're calling "provenance"?

Thinking much more simply: if IMA does what the draft says that it does, then it would be straightforward to describe exactly what it does, saying just how an HMAC is to be calculated and validated, with some description of the source of the key used in the HMAC.

This would perhaps be a more honest draft if it didn't call the blob that NFS was to store FATTR4_FILE_PROVENANCE, but just one brand of provenance encoding.  FATTR4_FILE_IMA?  That would rankle much less.  It would still suffer from all the weaknesses of not being well-defined, but at least it wouldn't appear to describe many possible "provenance" descriptions but really mean only one.

		Craig

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Oct 2018 20:06:04 -0500

> 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

---

From: Chuck Lever <[email-masked]>
Date: Wed, 10 Oct 2018 10:48:38 -0400

> On Oct 9, 2018, at 9:06 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> unreasonable to assume that any given NFS server either only serves
> 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

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.

> makes the most sense here and would suggest the Expert Review procedure for

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

--
Chuck Lever
[email-masked]