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

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

Please leave my employer out of this.  They don't speak for me, and I don't speak for them.

Solely as an individual, I really want to know the answers to whether this proposal makes sense for the broadest interconnected NFS community; ideally the answers would be in this document and not in cited material.  Last I looked at the documents, if I recall correctly, they referred to an authority on a single machine, and not an authority that was expected to serve a broader community, let alone a collection of machines larger than a classic workgroup.  The discussion of "identity" is along the same lines: a 32-bit userid is no longer an identifier for a principal.  NFS4 generally realizes this, but there is no indication that the IMA world does.

		Craig Everhart


On 3/27/19, 11:49 AM, "Chuck Lever" <[e-mail]> wrote:

    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
    
    
    
    
    > On Mar 27, 2019, at 11:23 AM, Everhart, Craig <[e-mail]> wrote:
    >
    > This version of the draft is at least more honest that it is simply an NFSv4 wrapper around one platform's implementation.  I admire the intellectual honesty.
    >
    > At the same time, a large amount is left unspecified:
    >       - how keyed hashes are applied or interpreted
    >       - what agents create or interpret "IMA metadata"
    >       - format and semantics for "IMA metadata"
    >
    > Because of this and other issues, the reader of this draft has no idea whether "IMA metadata" is portable from one Linux machine to another, or perhaps portable within some unspecified community boundary, or how to participate in this standard other than simply standing aside and hoping that Linux implementations do what one wishes that they would do.  For example, what is "the identity of the last modifier of a file's content"--is that an attribute that has meaning beyond a single machine's boundary?  How would one tell?  Even if assertions were made about it in prose, how would one tell in practice?  Does it even have meaning to carry one machine's "IMA metadata" to another participating machine?
    >
    > This is a set of semantic questions beyond the "IMA metadata format" question that is alluded to in the prose.
    >
    > I do not understand how the proposed extension is useful, and what use this OPTIONAL facility would have beyond a private community.
    
    I don't find your criticism to be fair. The Security Labels implementation
    added in NFSv4.2 takes the same approach, as does the proposed extension
    to support Linux extended attributes. I haven't heard any similar
    objection ("beyond a private community") to either precedent. OPTIONAL
    means you don't have to implement it if you don't agree with it.
    
    The document has unambiguous citations of material that explains how IMA
    works. Indeed, if you have questions beyond that, the implementation
    of IMA in Linux is open source, and there is an open mailing list where
    questions can be answered: [e-mail]. I can't
    force you to read the cited material, but I also can't answer your
    questions any more clearly than that material already does.
    
    What's more, as your employer makes only NFS servers, and the responsibility
    of an NFS server is simply to store IMA metadata just as it stores file
    content and file names without interpretation, I haven't a clue what
    possible issue you could have with the current revision of this document
    and why you refuse to look at the references to further your understanding.
    
    Therefore I question whether you are truly interested in improving this
    proposal. Perhaps your only interest is in vetoing it? If it isn't, please
    make specific suggestions as to how I can resolve your concerns.
    
    
    >               Craig Everhart
    >
    >
    > On 3/27/19, 10:40 AM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:
    >
    >    NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
    >
    >
    >
    >
    >> On Mar 27, 2019, at 10:31 AM, [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           : Integrity Measurement for Network File System version 4
    >>       Author          : Charles Lever
    >>      Filename        : draft-ietf-nfsv4-integrity-measurement-04.txt
    >>      Pages           : 13
    >>      Date            : 2019-03-27
    >>
    >> Abstract:
    >>  This document specifies an OPTIONAL extension to NFS version 4 minor
    >>  version 2 that enables Linux Integrity Measurement Architecture
    >>  metadata (IMA) to be conveyed between NFS version 4.2 servers and
    >>  clients.  Integrity measurement authenticates the creator of a file's
    >>  content and helps guarantee the content's integrity end-to-end 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-04
    >> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-04
    >>
    >> A diff from the previous version is available at:
    >> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-04
    >>
    >>
    >> 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/
    >
    >    I recently created a prototype implementation in the Linux NFS
    >    server and client which can be found in the nfs-ima-prototype
    >    topic branch of
    >
    >    git://git.linux-nfs.org/projects/cel/cel-2.6.git
    >
    >
    >    Commenters seem to prefer a "Linux IMA" specific implementation
    >    over a generic file provenance implementation. Thus the prototype
    >    I created is specific to Linux IMA. The draft has been updated to
    >    reflect what the prototype implements.
    >
    >    All references to "file provenance" have been replaced with the
    >    original text that referred specifically to Linux IMA. The request
    >    to create a file provenance registry has been removed. The XDR
    >    definition has been updated likewise.
    >
    >    I've added an "Implementation Status" section that documents the
    >    existence of the Linux prototype.
    >
    >
    >    --
    >    Chuck Lever
    >
    >
    >
    >    _______________________________________________
    >    nfsv4 mailing list
    >    [e-mail]
    >    https://www.ietf.org/mailman/listinfo/nfsv4
    >
    >
    
    --
    Chuck Lever