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

[Chuck Lever <[e-mail]>]

Hi Craig -

> On Oct 8, 2018, at 11:48 AM, Everhart, Craig <[e-mail]> wrote:
> 
> 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?

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 be done with clients or servers that participate in one but not all kinds of provenance information?

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.


> 		Craig
> 
> 
> On 10/8/18, 10:58 AM, "nfsv4 on behalf of [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    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/
> 
>    _______________________________________________
>    nfsv4 mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/nfsv4
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever
[e-mail]