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

[David Noveck <[e-mail]>]

> Help me understand exactly why the current section is lacking.

i promised to send you a review and i will.

> I don't see why the exact authorization mechanism must be specified in
this document,

I'm not saying i need the ezact authentication mechanism, but the current
document
is light-years or megaparsecs) away from that.  this may not be the
intention but right
now the document essentially gives the server to accept or jects request
without constraint.

> since:

> a. it doesn't matter for interoperability

It does.   To be interoperable you have to interoperate, i.e issue a valid
request and
have the required operation performed.   That ability is compromised if the
server can reject it for any reason it chooses.
> b. the mechanism used for updating IMA metadata on
   local files on Linux (the CAP_SYS_ADMIN capability)
   does not exist in NFS; moreover capabilities are
   not defined in a standard

I don't understand the relevance of that.

> c. authorization is done by policy in other arenas
   (for example, the IP-based access control that is
   implemented by most current NFS servers), thus it
   should be sufficient here too

Yes it exists and a document you are writing explains what is
wrong with that.   i don't want us to create a similar mess here
if we can avoid it.    In summary, it is clearly not sufficient
there, although it unfortunately exists.

> even though it should strive to be as helpfu as it can.   Also, it
appears that the Linux community cannot make its own mind about how to
address this issue so perhaps some intra-community compromise is in order.

> See above. It's really not a simple matter of the community shrugging and
punting.

I'm not sure what it is but i note there are at least four different
approahes specified in the document and that somenody would have to
compromise to reduce that number.


> If that isn't forthcoming, our only option might to approve this as an
experimental/informational  RFC and upgrade it when the Linux community
gets its act together.

>That's a bit unfair. See above: there is a complete mismatch between how
> it works on local file systems and what mechanisms are available with NFS.
> IMO we are in a position to enable both "close enough" server
implementations
> and for server implementers to exercise some innovation.

Maybe we are, but I don't see much effort in that direction in the current
document.

> Anticipating the IESG's reaction to this text is probably not going to be
> possible or helpful. I'd rather hear their complaints from them.

Agrre.  If this gets through WGLC and IETF last call, then you can hear
their
complaints first-hand.

>Let's focus
> on the WG's concerns first.

As I said, I'll be sending my review comments pretty soon.

On Mon, Sep 23, 2019 at 1:48 PM Chuck Lever <[e-mail]> wrote:

>
>
> > On Sep 23, 2019, at 10:19 AM, David Noveck <[e-mail]> wrote:
> >
> > > The guidance in that section falls into the realm of "compromise
> between the Linux community and the > specification writer"
> >
> > I gaathered that, but it should not be assumed that the woring group is
> prepared for the same level of compromise,
>
> Help me understand exactly why the current section is lacking. I don't see
> why the exact authorization mechanism must be specified in this document,
> since:
>
> a. it doesn't matter for interoperability
> b. the mechanism used for updating IMA metadata on
>    local files on Linux (the CAP_SYS_ADMIN capability)
>    does not exist in NFS; moreover capabilities are
>    not defined in a standard
> c. authorization is done by policy in other arenas
>    (for example, the IP-based access control that is
>    implemented by most current NFS servers), thus it
>    should be sufficient here too
>
>
> > even though it should strive to be as helpfu as it can.   Also, it
> appears that the Linux community cannot make its own mind about how to
> address this issue so perhaps some intra-community compromise is in order.
>
> See above. It's really not a simple matter of the community shrugging and
> punting.
>
>
> > If that isn't forthcoming, our only option might to approve this as an
> experimental/informational  RFC and upgrade it when the Linux community
> gets its act together.
>
> That's a bit unfair. See above: there is a complete mismatch between how
> it works on local file systems and what mechanisms are available with NFS.
> IMO we are in a position to enable both "close enough" server
> implementations
> and for server implementers to exercise some innovation.
>
> Anticipating the IESG's reaction to this text is probably not going to be
> possible or helpful. I'd rather hear their complaints from them. Let's
> focus
> on the WG's concerns first.
>
>
> > On Mon, Sep 23, 2019 at 12:28 PM Chuck Lever <[e-mail]>
> wrote:
> > Context: The guidance in that section falls into the realm of
> "compromise between the Linux community and the specification writer".
> >
> >
> > > On Sep 23, 2019, at 8:23 AM, David Noveck <[e-mail]>
> wrote:
> > >
> > > > It's probably ready for (it's first) WGLC. :-)
> > >
> > > I feel that the basic issue with section 4.3.2 has not been
> > > satisfactorily resolved.    I'll send out a mail with the details
> > > in the next few days.
> > >
> > >
> > >
> > > On Sun, Sep 22, 2019 at 7:15 PM Chuck Lever <[e-mail]>
> wrote:
> > >
> > >
> > > > On Sep 22, 2019, at 4:11 PM, [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-06.txt
> > > >       Pages           : 18
> > > >       Date            : 2019-09-22
> > > >
> > > > 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-06
> > > >
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-06
> > > >
> > > > A diff from the previous version is available at:
> > > >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-06
> > > >
> > > >
> > > > 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/
> > >
> > > Fresh revision incorporates comments from IETF 105 and Linux
> > > Security Summit North America 2019.
> > >
> > > It's probably ready for (it's first) WGLC. :-) It's OK if the
> > > chair prefers to wait until we have more fully dealt with
> > > outstanding RFC 5661 errata.
> > >
> > >
> > > --
> > > 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
>
> --
> Chuck Lever
>
>
>
>