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

[Chuck Lever <[e-mail]>]

> On Sep 26, 2018, at 1:21 PM, [e-mail] wrote:
> 
> On Mon, Sep 24, 2018 at 10:45:29AM -0500, Spencer Dawkins at IETF wrote:
>> Hi, Chuck,
>> On Mon, Sep 24, 2018 at 10:06 AM Chuck Lever <[e-mail]> wrote:
>> 
>>> 
>>> 
>>>> On Sep 24, 2018, at 7:55 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           : File Content Provenance for Network File System
>>> version 4
>>>>       Author          : Charles Lever
>>>>      Filename        : draft-ietf-nfsv4-integrity-measurement-01.txt
>>>>      Pages           : 9
>>>>      Date            : 2018-09-24
>>>> 
>>>> 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-01
>>>> 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-01
>>>> 
>>>> A diff from the previous version is available at:
>>>> 
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-01
>>>> 
>>>> 
>>>> 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/
>>> 
>>> As a result of the discussion at IETF 102 and recent follow-ups
>>> on this mailing list, I've made substantial changes to this
>>> document.
>>> 
>>> - References to and discussion of Linux IMA have been replaced
>>> throughout the document, with the exception of a single citation
>>> as an informative example in the Introduction. IMA metadata is
>>> now referred to generically using the term "file provenance
>>> information".
>>> 
>>> - Integrity checking of file attributes is no longer an included
>>> feature. There were some issues that made attribute integrity
>>> not straightforward for NFS, especially without an existing
>>> IMA/EVM standard even for local file systems. Attribute
>>> integrity can still be addressed at a later time.
>>> 
>>> - The Introduction now makes a problem statement and discusses
>>> use cases instead of explaining the mechanism of file integrity
>>> checking. The new Introduction addresses the most common
>>> questions I've received during previous review.
>>> 
>>> Spencer D. and other reviewers:
>>> - Have previously stated interoperability concerns been addressed?
>>> - Have normative citation requirements been sufficiently met?
>>> 
>> 
>> Recognizing that I haven't done an AD Evaluation of this draft, but looking
>> at the responses to my previous questions, I think dropping down to one
>> explicit mention of IMA pointing to the best available reference is about
>> right.
> 
> 	"A keyed hash authenticates the identity of the last modifier of
> 	a file's content and serves as a strong check of the content's
> 	integrity.  For the purposes of this document, we will refer to
> 	this as file provenance information.  The Linux Integrity
> 	Measurement Architecture (IMA) is an example of a mechanism for
> 	assessing file content provenance [IMA-WP]."
> 
> I think it's also true that this draft is sufficient to allow a client
> to support IMA?  That also seems worth mentioning.

I'm confused by your remark. I'm describing a transport
protocol between a NFS client and server. Why would it
not be sufficient to implement client support? Or, what
do you believe might be missing in the draft?


> 	"To ensure interoperability among accessors of this information
> 	when it is stored on NFS version 4.2 servers, this information
> 	MUST be self- describing."
> 
> How do you propose that an implementation would make the information
> self-describing?

That is out of scope for this draft.

But typically if an integrity service wanted to do this, it
could use XML or JSON to describe the information, for example.

An HMAC has a particular structure (RFC 2104) that should be
easy to recognize.


> --b.
> 
>> 
>> Thanks for making that change. It will be helpful during Last Call and IESG
>> Evaluation.
>> 
>> Spencer (D)
>> 
>> 
>>> 
>>> I know time is precious, but even a cursory review of this new
>>> revision would be helpful. It's wafer-thin!
>>> 
>>> --
>>> Chuck Lever
>>> 
>>> 
>>> 
>>> 
> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever