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

[Chuck Lever <[e-mail]>]

> On Mar 30, 2019, at 1:19 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> This seems to have gotten a bit heated.  Let's try to stick to the
> technical factors, please.

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


> On Wed, Mar 27, 2019 at 12:34:03PM -0400, Chuck Lever wrote:
>> 
>> 
>>> On Mar 27, 2019, at 11:58 AM, Everhart, Craig <[e-mail]> wrote:
>>> 
>>> Please leave my employer out of this.  They don't speak for me, and I don't speak for them.
>> 
>> 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
> 
> 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
>> stack.
> 
> 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.
> 
>> 
>>> 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.
> 
> 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.
> 
>> 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.
> 
> 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
> 
>> 
>>> 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.
>> 
>> 
>>> 		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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever