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

[David Noveck <[e-mail]>]

> Why would it not be sufficient to implement client support?

I think it is sufficient.

> Or, what do you believe might be missing in the draft?

Not sure what Bruce had in mind but I think the problem is something that
is in the draft that shouldn't be, rather than something missing.

>> How do you propose that an implementation would make the information
>> self-describing?

> That is out of scope for this draft.

If so, then so is "*MUST* (emphasis added) be self-describing".

> But typically if an integrity service wanted to do this

If it were really a "MUST", then what an integrity service wants to do
should be irrelevant.


On Wed, Sep 26, 2018 at 4:27 PM Chuck Lever <[e-mail]> wrote:

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