Subject: Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07

From: spencer shepler <[email-masked]>
Date: Wed, 6 Nov 2019 23:05:42 -0800

Apologies for top posting but I would like to address one portion of this
thread only.

I have poached one particular comment.... the below is quoted from Chuck's
last response on this thread.
--
> I think I lack the background to understand why Spencer doesn't believe
> this is an appropriate use of the NFS protocol, but I don't think that
this
> is the right thread to educate me.

I'm also interested in learning more about this. The same argument has been
made in the past about extending NFS in general, and I guess I had assumed
that this had been resolved with the publication of RFCs 8178 and 8276.

--

I agree that RFC 8178 provides the ability to add features, particularly
attributes, to the protocol and I agree with the utility of 8178 and that
is appropriate.

I also agree with the utility of RFC 8276 but I disagree with the
interpreted precedent of the RFC per Chuck's comment.

To quote from RFC 8276:

"Xattr keys and values MUST NOT be interpreted
by the NFS clients and servers, as such behavior would lead to
non-interoperable implementations.  If there were a need to specify
one or more attributes that servers need to act upon, the appropriate
semantics would be specified by adding a new attribute for the
purpose as provided for by [RFC5661] and [RFC8178]."

I read the proposed integrity measurement capability as providing a
"system-level" interpretation.

The decision to allow for the execution of application binaries is a
"system" level activity or in other words, a feature that explicitly
requires the client to interpret the semantics of the protocol extension.
Because of the client's need to interpret the capability, the definition
should be defined in a way that it can be implemented in an open fashion
and hopefully, but not required, defined in a way that it is "upgradeable".

To the point of "open", I don't believe the availability of open source
sufficient in this instance.  Yes, a clean-room approach to implementation
can be executed but even with that action, a patent claim can still be
made.  Therefore, without the protocol definition being captured in a way
that clearly allows the reader to have a sense that IETF's policies for
disclosure have followed, I don't believe it should be allowed as an
extension of the NFS protocol.

So, I am left with my objection to this work moving forward.

If this proposal would to be accepted, it sets a precedent that a
individual could define a similar extension for their favorite XYZ product
in such a way that interoperable implementations could be not implemented.
In least this could lead to a proliferation of OS, vendor specific feature
creep and at worse, non IP infringing implementations would be impossible
to implement.

Spencer

On Thu, Oct 31, 2019 at 12:54 PM Chuck Lever <[email-masked]> wrote:

>
>
> > On Oct 31, 2019, at 3:24 PM, Benjamin Kaduk <[email-masked]> wrote:
> >
> > A few points/questions inline:
> >
> > On Tue, Oct 29, 2019 at 11:33:18AM -0400, Chuck Lever wrote:
> >>
> >>> On Oct 29, 2019, at 2:15 AM, spencer shepler <
> [email-masked]> wrote:
> >>>>
> >>>> On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <[email-masked]>
> wrote:
> >>>>
> >>>>> On Oct 28, 2019, at 3:28 PM, David Noveck <[email-masked]>
> wrote:
> >>>>>
> >>>>
> >>>> In my earlier reply, I proposed breaking this process into two steps:
> >>>>
> >>>> 1. Specify how NFS is to transport IMA metadata in an IETF publication
> >>>> 2. Specify the Linux IMA metadata format itself in some other venue
> >>>>
> >>>> So then:
> >>>>
> >>>> 1. would be a Normative extension to the NFS protocol
> >
> > I'm probably missing something obvious, but why does it have to be a
> > normative extension to the NFS protocol?  Is there some IANA registry
> with
> > a Standards Action registration policy?
> > IETF WGs can publish informational documents, is where I'm going with
> this.
>
> I'm proposing that:
>
> The transport piece would be Normative, as NFS protocol extensions
> typically are.
>
> The metadata format would be Informative, just as you suggest.
>
> Not clear to me how making the transport piece Informative would
> allay concerns about the metadata format.
>
> Btw, I've added Spencer's review along with some thoughts about how
> to address his comments in an issue:
>
> https://github.com/chucklever/i-d-integrity-measurement/issues/7
>
>
> >>>> 2. might be published by the nfsv4 as an Informative description of
> the
> >>>> metadata format, in lieu of getting this published somewhere else.
> Think
> >>>> of it as an illustrative example rather than a hard specification.
> >>>>
> >>>> It still doesn't feel like it's the job of an inter-networking
> standards
> >>>> body to maintain this metadata data format specification, however.
> >>>>
> >>>> Does it make sense to publish either a separate Informative document
> or
> >>>> have an Appendix to this document that provides an Informative example
> >>>> that gives a specific format for Linux IMA metadata?
> >>>>
> >>> Chuck,
> >>>
> >>> Given this last set of responses, you seem to be saying that the only
> implementation of this capability will be with Linux and that you would be
> surprised to find any other implementations that would need to implement
> the support for this feature.
> >>
> >> That's not at all what I'm saying.
> >>
> >> There is currently no published standard definition of the IMA metadata
> format.
> >> I've made it clear from the very beginning that one does not yet exist,
> and
> >> have asked repeatedly whether this will be a problem. For the past 18
> months,
> >> I've gotten the answer "no, it shouldn't be, because NFS
> implementations won't
> >> be required to interpret the metadata format."
> >>
> >> Thus I'm asking for a protocol extension so that NFS can transport, and
> NFS
> >> servers can store, a particular piece of opaque metadata. This is a
> narrow
> >> scope. All I want to do is store and retrieve this metadata via NFS.
> >>
> >> I've been asked to provide the format of the metadata. But at this
> time, no-one,
> >> except for Linux, has stated a plan to actually use it. Thus, this
> sounds like
> >> a piece of this puzzle that can be deferred until it is actually needed
> (or
> >> until someone decides the Linux IMA format is awesome and publishes it).
> >>
> >> I'm also not claiming the metadata format should /never/ be published;
> merely
> >> that we don't need this format definition to create a mechanism for
> storing it.
> >>
> >> - Interpretation of the metadata can be left to the future because
> there is
> >>   a clean dividing line between moving the data and parsing it. This
> allows
> >>   the protocol piece of this work to move forward quickly while we
> wrestle
> >>   with the standards issues around the metadata format.
> >>
> >> - I don't believe the IETF is the right place to publish the metadata
> format.
> >>   The IETF does networking, not data storage and not Trusted Computing.
> If
> >>   we have to publish anything, it should be Informative only. Or maybe
> we
> >>   can approach another standards setting organization where it would be
> more
> >>   appropriate. I'm open to hear arguments either way about this.
> >
> > I'm not arguing that the IETF should take on and publish the Linux IMA
> > format (for one, we don't seem to have many people willing to put energy
> > into doing so), but I will note that the IETF has recently chartered a WG
> > for remote attestation procedures and does have people thinking about
> > endpoint security and endpoint assessment (e.g., the SACM WG).
>
> That's interesting! I'll investigate.
>
>
> >> It seems to me that the only thing that is missing from the current
> document
> >> is a clear statement that this document, by itself, will not enable the
> >> implementation of an IMA appraiser on the NFS server or client. The
> document
> >> does not prevent or forbid future publication that would enable such an
> >> implementation.
> >>
> >>
> >>> So, this is then clearly opening the door for the NFS protocol to be
> used for implementation specific features and to the point that all that is
> needed is an opaque attribute and possibly some error codes to go along
> with it to achieve a side band protocol for that specific implementation.
> And if anyone is interested in the feature, a pointer to some "open source"
> is sufficient.
> >>>
> >>> Well, I don't believe that is an appropriate use of the NFS protocol
> as defined within the IETF.  I apologize if I have the characterization
> incorrect and would be happy to hear otherwise.
> >
> > I think I lack the background to understand why Spencer doesn't believe
> > this is an appropriate use of the NFS protocol, but I don't think that
> this
> > is the right thread to educate me.
>
> I'm also interested in learning more about this. The same argument has been
> made in the past about extending NFS in general, and I guess I had assumed
> that this had been resolved with the publication of RFCs 8178 and 8276.
>
>
> --
> Chuck Lever
>
>
>
>

---

From: Chuck Lever <[email-masked]>
Date: Thu, 7 Nov 2019 10:56:43 -0500

Hi Spencer, thanks for your reply. Unfortunately it leaves me with more questions.

> On Nov 7, 2019, at 2:05 AM, spencer shepler <[email-masked]> wrote:
> 
> 
> Apologies for top posting but I would like to address one portion of this thread only.
> 
> I have poached one particular comment.... the below is quoted from Chuck's last response on this thread.
> --
> > this is an appropriate use of the NFS protocol, but I don't think that this
> I agree that RFC 8178 provides the ability to add features, particularly attributes, to the protocol and I agree with the utility of 8178 and that is appropriate.
> 
> I also agree with the utility of RFC 8276 but I disagree with the interpreted precedent of the RFC per Chuck's comment.
> 
> To quote from RFC 8276:
> 
> I read the proposed integrity measurement capability as providing a "system-level" interpretation.

The intent of the quoted text was to prevent the use of xattrs as a side-channel ioctl mechanism, which I'm not proposing here. However, I am proposing "adding a new attribute" as suggested in the quoted text. Therefore, I feel that I'm following the letter, if not also the intention, of this text.

> The decision to allow for the execution of application binaries is a "system" level activity or in other words, a feature that explicitly requires the client to interpret the semantics of the protocol extension.  Because of the client's need to interpret the capability, the definition should be defined in a way that it can be implemented in an open fashion and hopefully, but not required, defined in a way that it is "upgradeable".

"System level activity" is not defined in the quoted text, so it's not clear-cut to me that there is any consensus that can be relied upon as solid rhetorical ground.

Interpretation of the stored metadata can be done by the NFS implementations themselves, by the kernels on those hosts, or by unprivileged agents running in user space. The same functionality, but are all three "system level activity" ? Not clear where the boundary is.

Why is "outside of the NFS implementation but in the kernel" still a system-level activity? How would you draw this line on a non-POSIX or user space NFS client, for example?

> To the point of "open", I don't believe the availability of open source sufficient in this instance.  Yes, a clean-room approach to implementation can be executed but even with that action, a patent claim can still be made.  Therefore, without the protocol definition being captured in a way that clearly allows the reader to have a sense that IETF's policies for disclosure have followed, I don't believe it should be allowed as an extension of the NFS protocol.

NFS is being used only to transport and store this metadata, in the same way that is used to transport and store file content, which is also interpreted on clients in ways that are out of the purview of the IETF. It would be a stronger argument if there existed an actual IETF document which recorded a consensus and an on-point legal opinion about this.

My document also permits an implementation not to interpret the metadata at all. If a reader or implementer has any doubts, s/he can simply treat that metadata as the opaque blob that it is.

> So, I am left with my objection to this work moving forward.

Even if I introduce an Informative definition of the metadata format to the document? Does that not meet your second suggested way forward (from earlier email)?

Is there a need to make the format Normative, either within the IETF or in some other standards setting context?

What if the Linux community made the IMA metadata format completely open (ie, stated publicly that it is unencumbered IP) ?

What if Linux stored this metadata in a user xattr instead?

> If this proposal would to be accepted, it sets a precedent that a individual could define a similar extension for their favorite XYZ product in such a way that interoperable implementations could be not implemented.  In least this could lead to a proliferation of OS, vendor specific feature creep and at worse, non IP infringing implementations would be impossible to implement.

That's dire. I wish this requirement was clearly documented somewhere.

Why isn't the SELinux label work a problem in this regard?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Thu, 7 Nov 2019 18:13:15 -0500

> Why isn't the SELinux label work a problem in this regard?

I don't understand Spencer's position well  enough to know if he has
a problem with this, but given that this model has already been adopted
by the working group for arguably system-level attributes, it is hard for
me to believe such objections, if they were to exist, would be widely
shared.

Since adopting a parallel approach for the IMA metadata
format is compatible with your plans for -08, perhaps you should
adopt a similar approach (an IANA registry with a specification-required
policy) for IMA.   I know that such things have been suggested in the past
and seemed at the time like overkill, but, given that there are a number
of existing formats, and likely there will be a more general format which
has not been arrived at  right now, it might be best to take this step,
hoping that it will deal with the objections about the lack of a metadata
format specification even though the Linux community is kind of slow
about producing  one.  I think you ould have to add a new fs-scope
attribute with the id, rather than stick with the local-policy approach,
but there would b no requirement tat the client check this.

BTW, specification-required and even RFC-required do not require a
normative specification.   With specification-required, the IETF does
not have to be involved in writing the spec although a designated-expert
would have to check that it clear enough to enable implementation.

On Thu, Nov 7, 2019 at 10:56 AM Chuck Lever <[email-masked]> wrote:

> The intent of the quoted text was to prevent the use of xattrs as a
> side-channel ioctl mechanism, which I'm not proposing here. However, I am
> proposing "adding a new attribute" as suggested in the quoted text.
> Therefore, I feel that I'm following the letter, if not also the intention,
> of this text.
>
>
> "System level activity" is not defined in the quoted text, so it's not
> clear-cut to me that there is any consensus that can be relied upon as
> solid rhetorical ground.
>
> Interpretation of the stored metadata can be done by the NFS
> implementations themselves, by the kernels on those hosts, or by
> unprivileged agents running in user space. The same functionality, but are
> all three "system level activity" ? Not clear where the boundary is.
>
> Why is "outside of the NFS implementation but in the kernel" still a
> system-level activity? How would you draw this line on a non-POSIX or user
> space NFS client, for example?
>
>
> NFS is being used only to transport and store this metadata, in the same
> way that is used to transport and store file content, which is also
> interpreted on clients in ways that are out of the purview of the IETF. It
> would be a stronger argument if there existed an actual IETF document which
> recorded a consensus and an on-point legal opinion about this.
>
> My document also permits an implementation not to interpret the metadata
> at all. If a reader or implementer has any doubts, s/he can simply treat
> that metadata as the opaque blob that it is.
>
>
> Even if I introduce an Informative definition of the metadata format to
> the document? Does that not meet your second suggested way forward (from
> earlier email)?
>
> What if the Linux community made the IMA metadata format completely open
> (ie, stated publicly that it is unencumbered IP) ?
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever <[email-masked]>
Date: Fri, 8 Nov 2019 10:12:02 -0500

> On Nov 7, 2019, at 6:13 PM, David Noveck <[email-masked]> wrote:
> 

It appears that draft-ietf-nfsv4-integrity-measurement can't move
forward without some description of the IMA metadata format.

My preference would be that the Linux community is responsible for
the process and document(s) that describe their own format. Failing
that, a description can be added to integrity-measurement, as I
recently proposed.

To make an IANA registry a sensible thing to do, at least one more
independent integrity metadata format will have to be identified.

I will see what can be done.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Nov 2019 10:11:13 -0800

> forward without some description of the IMA metadata format.

My name is not Magnus, but I'm not fully convinced of that yet.

> independent integrity metadata format will have to be identified.

I'm sure I can find many examples of IANA registries that are created with
only one substantive initial entry; why would this one be any different?
The point is to have a clear extension point, not (necessarily) to require
someone to use it from the start.  (Though, perhaps, see also
draft-ietf-tls-grease...)

-Ben

---

From: David Noveck <[email-masked]>
Date: Mon, 11 Nov 2019 14:43:42 -0500

> forward without some description of the IMA metadata format.

It is my understanding that you already plan to do that in -08.

> the process and document(s) that describe their own format.

That's very sensible but that doesn't mean it's going to happen.

Failing
> that, a description can be added to integrity-measurement, as I

Understood.

> independent integrity metadata format will have to be identified.

I think one has already been identified.  To make this scheme work, there
will need to have a common metadata format implemented.

Once it is implemented, it will need to be specified, leaving you with
following tasks:

   - Identifying a victim to provide it.
   - Figuring out when/where it will be provided.

The virtue of the IANA registry is that it gives you the ability to defer
these tasks.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 11 Nov 2019 16:55:54 -0500

> On Nov 11, 2019, at 2:43 PM, David Noveck <[email-masked]> wrote:
> 
> 
> 

That is what I proposed last week. Now I'm thinking the description
could be a separate document. Certainly a description could be
published separately by the IETF (eg., nfsv4, rats or teep) or it
could come from some other SSO (such as TCG).

> That's very sensible but that doesn't mean it's going to happen.

As a card-carrying member of the Linux community, I can attempt to
get it done myself. Two issues:

 - Who will be responsible for maintaining the publication as new
Linux IMA formats are introduced. IMA is currently an active effort,
and I anticipate some integration with fs-verity will require a new
IMA metadata format.

- How long will it take to ensure the format is not encumbered by
patent or software license. I have contacts at the Linux Foundation
that I hope can help address this issue. I will also discuss this
with any copyright holders.

> I think one has already been identified.  To make this scheme work, there will need to have a common metadata format implemented.
> 
> Once it is implemented, it will need to be specified, leaving you with following tasks:
> 	• Identifying a victim to provide it.
> 	• Figuring out when/where it will be provided.
> The virtue of the IANA registry is that it gives you the ability to defer these tasks.

Deferral would be nice, as that would enable integrity-measurement
to move forward sooner (assuming Spencer's objection is lifted).
But it might be unnecessary if I can get a document put together
and signed-off by others in the Linux community in the next few
months.

We did try an IANA registry before, and I'm willing to consider
that again to help move this along. The e-mail conversation a few
months ago rat-holed on whether or not there would be an actual
need for multiple metadata formats, as I recall. We can put aside
the question of over-engineering and decide simply that the document
will start with a registry containing one format discriminator.

There is also the question of whether the format discriminator field
not only marks the internal format, but also allows the storage and
retrieval of metadata stored in other xattrs (unlike the discriminator
for NFSv4 security labels, which applies only to one xattr).

IMA, for example, already uses two xattrs, security.ima and
security.evm, that can co-exist on the same file. It would be slick
to add support for security.evm simply by adding another entry into
the IANA registry.

Before I go too much further, however, I would like to hear from
Spencer if he believes these changes would adequately address his
concerns.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 12 Nov 2019 09:09:33 -0500

> not only marks the internal format,

I don't understand.   I would think that the format discriminator
identified the *external *format.  Of course, as a practical, matter,
a server implementation might well choode to make the internal
and external formats the same, since it doesn't really care.

> but also allows the storage and

>From the NFSv4 poiint of view, the particular (system) xattr used
for this purpose don't really matter.   Since they are not not
NFSv4 (user) xattrs, any such assigment is purely an
implemenation matter.

> security.evm, that can co-exist on the same file.

That the first of hear of this and your spec does not mention it.
I presume this is because this division into multiple sub-blobs
is not necessary to implement the protocol you describe,
although it might be necessary to implement appraisal.

> It would be slick

I don't see why this wouldn't work or why it is even in question.
If there is a furure IMA metadata format consisting of these two
sub-blobs, it would not affect the protocol yout have described.
Servers would not care about this sub-dvision while those concerned
with appraisal would have to be aware of them.  However, they would
not need to know anything about how these sub-blobs were stored.
I assume on-Disk Linux file systems would use these xattrs, while
NFSv4.2 servers with no appraisal capabilities would probably store
the whole blob  as-is.

On Mon, Nov 11, 2019 at 4:57 PM Chuck Lever <[email-masked]> wrote:

> > I think one has already been identified.  To make this scheme work,
> there will need to have a common metadata format implemented.
> >

---

From: Chuck Lever <[email-masked]>
Date: Tue, 12 Nov 2019 10:12:26 -0500

> On Nov 12, 2019, at 9:09 AM, David Noveck <[email-masked]> wrote:
> 
> identified the external format.  Of course, as a practical, matter,

Sorry. Not sure why I used the term "internal" here. I merely
meant the public integrity metadata format.

> NFSv4 (user) xattrs, any such assigment is purely an

The issue is similar for NFSv4 security labels, though that ship
has sailed. On Linux each label type is stored in a unique xattr,
but the NFSv4 security label specification requires there be only
one accessible label at a time per file.

Yes, multiple security labels per file does make sense.

> That the first of hear of this and your spec does not mention it.

It's not the first time it's been discussed here, and in fact
some earlier revisions of the personal draft version of this
document did discuss EVM, iirc.

IMA is a hash of file content. EVM is a hash of file
attributes. EVM is not supported by my spec simply because
the NFS protocol does not expose all of a file's attributes
(the file's capability settings being one of the most
important attributes that EVM protects). Thus NFS clients
are unable to verify EVM metadata.

> I don't see why this wouldn't work or why it is even in question.

It's in question because NFSv4 security labels explicitly do not
allow multiple labels per file, but integrity will likely need
that kind of functionality.

During a previous discussion, future EVM support was mentioned as
a reason why having a discriminator field would be a good thing.

> not need to know anything about how these sub-blobs were stored.

That's correct: EVM is similarly opaque to filesystem implementations.

> NFSv4.2 servers with no appraisal capabilities would probably store 

I agree that the protocol specification should remain agnostic about
how NFS servers store integrity metadata. I'd simply like to be able
to store multiple distinct types of integrity metadata on the same
file.

=====

Recall that at least one revision of this document called the metadata
"file provenance information." Craig didn't like that because he felt
it was dishonest about what the purpose of this extension actually
was -- to store Linux IMA metadata.

If the pendulum is swinging back to enabling storage and transport of
generic integrity metadata, perhaps calling this attribute IMA is no
longer appropriate, and some other name would be better.

FATTR4_INTEGRITY_METADATA or maybe just FATTR4_INTEGRITY ?

--
Chuck Lever