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

From: [email-masked]
Date: Wed, 27 Mar 2019 07:31:03 -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           : 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/

---

From: Chuck Lever <[email-masked]>
Date: Wed, 27 Mar 2019 10:39:59 -0400

> On Mar 27, 2019, at 10:31 AM, [email-masked] wrote:
> 
> 

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

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 27 Mar 2019 15:23:01 +0000

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.

		Craig Everhart

On 3/27/19, 10:40 AM, "nfsv4 on behalf of Chuck Lever" <[email-masked] on behalf of [email-masked]> 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.

    

    

    --
    Chuck Lever

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

---

From: Chuck Lever <[email-masked]>
Date: Wed, 27 Mar 2019 11:49:27 -0400

> On Mar 27, 2019, at 11:23 AM, Everhart, Craig <[email-masked]> wrote:
> 

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

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 27 Mar 2019 15:58:42 +0000

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

    

    

    
    --
    Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 27 Mar 2019 12:34:03 -0400

> On Mar 27, 2019, at 11:58 AM, Everhart, Craig <[email-masked]> wrote:
> 

I'm trying to understand the context of your remarks. Until now,
I haven't seen any disclaimer on e-mails from you at your NetApp
address. So be it: you are interested in understanding the whole
stack.

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

I've been specifically told not to repeat what appears in cited
material. If there's a brief summary that can be added, I can do
that, but I prefer to let referenced material speak for itself.

This document specifies NFS protocol, not implementation of IMA.
I can be somewhat flexible about an explanation of IMA, but it
does not seem appropriate to provide an explicit description of
IMA metadata content and format -- just as it is out of scope
for RFC 7862 to be specific about the exact format of Security
Labels. I'm describing a transport and storage mechanism for
an application-defined data format.

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

The identities in question are not 32-bit UIDs and are not users
or file owners. The document does not mention AUTH_SYS or
traditional Unix UIDs anywhere. Cryptographic signatures, which
are discussed here, are performed using large keys or x.509
certificates that are generated by global trust authorities.

The Introduction outlines several use cases that ought to provide
appropriate context for understanding the architecture -- that
the signers are typically global software vendors.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 Mar 2019 12:19:31 -0500

This seems to have gotten a bit heated.  Let's try to stick to the
technical factors, please.

> I haven't seen any disclaimer on e-mails from you at your NetApp

In particular, you shouldn't need to see any disclaimer: the BCPs are
pretty clear that we make our IETF contributions in an individual capacity.

> address. So be it: you are interested in understanding the whole

Putting my IESG hat on briefly, we also need to have some understanding of
the complete stack in order to review documents.  External references are
unavoidable sometimes, of course, but when a brief summary can avoid the
need for them, that does save us time.

> that, but I prefer to let referenced material speak for itself.

I think it's a bit more subtle than this blanket admonition would indicate;
I'm also a bit curious exactly what you were told  (and by whom), though
perhaps I should not worry about that.

> an application-defined data format.

With apologies for commenting on a document I have not yet read, you  do
need to document what is and is not allowed in this container (and external
references will of course play abig part in that).

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Sun, 31 Mar 2019 11:10:59 -0400

> On Mar 30, 2019, at 1:19 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I apologize. I will try to keep the discourse civil and technical.

--
Chuck Lever