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

["Everhart, Craig" <[e-mail]>]

Hi Chuck, thanks for the quick reply.

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

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


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

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?
    
    The document later states that provenance assessors have to be prepared
    to encounter unrecognized provenance information.

Recognized how?
    
    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?

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

    
    >
    >
    > 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]
    
    
    
    _______________________________________________
    nfsv4 mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/nfsv4