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

From: spencer shepler <[email-masked]>
Date: Sun, 27 Oct 2019 23:50:17 -0700

Feedback and comments on the draft “Integrity Measurement for Network File
System version 4” - draft-ietf-nfsv4-integrity-measurement-07.

Note that these comments are personal contribution and do not reflect my
position as working group co-chair.

In short, I am opposed to moving this draft to last call in its current
state.  Generally, the draft describes the Linux implementation of a
feature that is to be extended via NFS.  However, the description provided
is insufficient for interoperable implementations to be achieved.

There are two options, in my opinion, to moving this document forward:

1)  Limit the description to the addition of the new, opaque attribute and
corresponding errors that can be returned as a result of the interpretation
of that attribute.

2)  Fully define the contents of the new attribute such that independent
implementations can be achieved. This would include, but is not limited to,
the open definition of the content of the new attribute and the procedures
associated with defining new content and interpretation thereof.

If option 1) were chosen, I would still be of the opinion that the draft
should not move forward since it would present another barrier to open,
interoperable implementations.

Note that I am also doubtful of the use case being presented. Using NFS to
directly store and supply application executables seems to be in rapid
decline or has already fallen out of use.  Given the rise of virtualization
and the hosting of virtual disks on NFS along with the rise of containers
and distribution thereof, application distribution seems to be a thing of
the past with respect to their store/retrieval from NFS mounts.

If the effort was more focused on more traditional data integrity from
source to consumption, that would be a more interesting use case.  With the
rise of large scale data center usage of NFS (e.g. cloud computing) where
customers expect data integrity or the identification of failure, the scale
of cloud computing presents many opportunities for the loss of data
integrity and NFS (and the client and server implementations thereof) do
nothing to ensure data integrity.  The draft does mention spot fixes of
data-at-rest methods, and in-transit methods, but there are many points
that present areas of potential failure, and these are ignored in today’s
implementations (at least to this commenter's knowledge).

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Mon, 28 Oct 2019 11:00:29 -0400

Hi Spencer, thanks for taking time to review this document. Responses
to individual comments are below.

> On Oct 28, 2019, at 2:50 AM, spencer shepler <[email-masked]> wrote:
> 
>  
> Feedback and comments on the draft “Integrity Measurement for Network File System version 4” - draft-ietf-nfsv4-integrity-measurement-07.
> 
>  
> Note that these comments are personal contribution and do not reflect my position as working group co-chair.
> 
> In short, I am opposed to moving this draft to last call in its current state.  Generally, the draft describes the Linux implementation of a feature that is to be extended via NFS.  However, the description provided is insufficient for interoperable implementations to be achieved.

Issues about interoperation have already been raised and addressed
multiple times both on the mailing list and in presentations at IETF
meetings. The metadata stored in this attribute is opaque to the NFS
protocol and implementations, just like file data is opaque.

The metadata is not created by the NFS implementation; it is created
by a user space tool. It is not interpreted by the NFS implementation;
it is interpreted by a separate privileged security module.

NetApp, for instance, could create a fully interoperating implementation
today, based solely on this document, simply by enabling clients to store
and retrieve this attribute. There is no more to it than that.

NFS, in this case, is used as a transport. It is an intermediary. There's
no reason it needs to interpret the metadata. It's only job is to ensure
that data and metadata is not maliciously or accidentally altered.

> 1)  Limit the description to the addition of the new, opaque attribute and corresponding errors that can be returned as a result of the interpretation of that attribute.
> 
> 2)  Fully define the contents of the new attribute such that independent implementations can be achieved. This would include, but is not limited to, the open definition of the content of the new attribute and the procedures associated with defining new content and interpretation thereof.
> 
> If option 1) were chosen, I would still be of the opinion that the draft should not move forward since it would present another barrier to open, interoperable implementations.

"To move this document forward, pick option 1 or 2. But if you pick option
1, I will still object."

That means there is really only one option in your opinion. I have repeatedly
stated why option 2 is not practical or necessary. The nfsv4 working group
and the IETF does not want to be the bearer of the IMA standard for Linux.

Further, there is no need for it do so, because the metadata stored in this
attribute is opaque to the NFS protocol and to NFS implementations.

"Barrier to open implementations." The Linux implementation is open source.
It would certainly be possible to port the Linux implementation, or with a
little more work, provide a clean-room implementation. In an era in which
open source dominates, "open" no longer means just that there is an open
standard. Maybe "open" is not what you actually meant here.

Seems to me that rejecting a protocol mechanism that enables the use of a
data format with an open source implementation but no published standard is
also a barrier to open implementations.

> Note that I am also doubtful of the use case being presented. Using NFS to directly store and supply application executables seems to be in rapid decline or has already fallen out of use.  Given the rise of virtualization and the hosting of virtual disks on NFS along with the rise of containers and distribution thereof, application distribution seems to be a thing of the past with respect to their store/retrieval from NFS mounts.

Do you have evidence that this change is taking place? Sharing the same
application executable on NFS seems pretty common in Oracle deployments.

Do you believe IMA is not also useful for the read-only virtual disk use
case?

One reason that virtual disks are used is /because/ NFS does not support
things like xattrs, capabilities, and integrity metadata. Otherwise,
maintaining guest root filesystems on NFS would be a popular solution.

How about protection of other types of read-mostly data like configuration
files?

> If the effort was more focused on more traditional data integrity from source to consumption, that would be a more interesting use case.  With the rise of large scale data center usage of NFS (e.g. cloud computing) where customers expect data integrity or the identification of failure, the scale of cloud computing presents many opportunities for the loss of data integrity and NFS (and the client and server implementations thereof) do nothing to ensure data integrity.  The draft does mention spot fixes of data-at-rest methods, and in-transit methods, but there are many points that present areas of potential failure, and these are ignored in today’s implementations (at least to this commenter's knowledge).

There is no claim made in the document that this mechanism closes all
integrity exposures. Can you identify particular areas that need to be
addressed by this mechanism but are not? Do you have specific alternative
proposals?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 28 Oct 2019 12:04:21 -0400

> 1)  Limit the description to the addition of the new, opaque attribute
and corresponding errors that can be returned as a result of the
interpretation of that attribute.

There is a third option which should be mentioned:

3) Provide enough information to enable interoperable server implementation
to be developed, while delaying work necessary to accomplish the ability to
develop other client implementations, i.e. to do 2)

While 2) would be preferrable to doing 3), that appears not to be possible,
in any realistic time frame, so the choice we have is between 3) and 1)
(or nothing).  If that is the choice, and I think it is, my choice would be
3).    I realize there may be objections to 3) as a general approach but I
feel that it makes sense to address those during the document's WGLC.
Given the naturre of the situation, it does not make sense to delay WGLC
until this issue addressed, since it is not the kind of issue where a delay
of any reasonable length could change the situation.

> > Note that I am also doubtful of the use case being presented. Using NFS
to directly store and supply application executables seems to be in rapid

> application executable on NFS seems pretty common in Oracle deployments.

Even if it were happening there would still be a need to transfer the
executables
acros machine boundaries, even if the uyltimate use were not using NFS to
access
directly.   I would prefer that if there are important  file system
interfaaces supported
by local file systems, we  provide that support remotely as well, unless
doing so
poses insuperable obstacles.   In this case it doesn't and so we should be
able to
proceed to WGLC as soon as Chuck feels the document is ready and have the
necessary discussion about 1), 2), and 3)  above.

On Mon, Oct 28, 2019 at 11:00 AM Chuck Lever <[email-masked]> wrote:

> > Feedback and comments on the draft “Integrity Measurement for Network
> File System version 4” - draft-ietf-nfsv4-integrity-measurement-07.
> >
> >
> > 1)  Limit the description to the addition of the new, opaque attribute
> and corresponding errors that can be returned as a result of the
> interpretation of that attribute.
> >
> > Note that I am also doubtful of the use case being presented. Using NFS
> to directly store and supply application executables seems to be in rapid
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Craig Everhart <[email-masked]>
Date: Mon, 28 Oct 2019 12:05:12 -0400

I (could) have a specific alternative proposal.

It would be based on an articulation of exactly what should be the contents
of an integrity "blob"--e.g., something like an HMAC_SHA256 computation
based on the file contents and a specific authorizing key, presumably
associated with the originating provenance of the file: some private key
associated with an originator's certificate, or a PSK.

The question would then be how the consumer of the provenance blob is to
verify that the HMAC value correctly identifies the given file.  In other
words, all the questions that I've had for this architecture from the
beginning.

It would not be pre-built into Linux, but it would be something that
multiple independent parties could know how to create and validate.

Craig

---

From: spencer shepler <[email-masked]>
Date: Mon, 28 Oct 2019 09:36:46 -0700

Chuck,

inline for comments.

> that data and metadata is not maliciously or accidentally altered.

If the attribute is truly opaque to one implementation, then state it
clearly.
If this is an attribute that is in support of the Linux method of operation
and only ever intended to be such, then retitle the document to make that
clear and remove the extraneous content of the document.  This will make it
clear to the reviewer what the intent is.

To the statement of the server implementation, the document refers to the
server's ability to check the file content.  This to me meant that there
was a client / server interoperability issue at hand.  I note that the
server is not required to implement the capability but if it is possible,
then it should be well defined.

> standard. Maybe "open" is not what you actually meant here.

This is the question of client interoperability.  If two separate client
implementations to follow the "IMA standard for Linux", then there should
be an open definition of what that standard is in my opinion.  And I do
mean the ability to implement with clarity about how and what implications
there are for any intellectual property that exists.

> also a barrier to open implementations.

I am asking for clarity.  Either the attribute is opaque and that is clear
to everyone or there is enough information to create interoperable
implementations as mentioned above.

> addressed by this mechanism but are not? Do you have specific alternative

My comment was not meant to offer an alternative solution to the document's
proposal but rather to suggest that there are other areas of "integrity"
that could be addressed that would result in utility.  If the working group
finds the area interesting, this may be a potential path.

Spencer

---

From: spencer shepler <[email-masked]>
Date: Mon, 28 Oct 2019 09:39:26 -0700

Craig,

The general idea does appear to have utility and would be in the direction
of what I think would be needed.

Is it worthwhile or will the idea be acceptable to others?  No idea but it
might be worth some discussion but the overall motivation still seems weak
in my opinion as general motivation - but it is but a single opinion.

Spencer

On Mon, Oct 28, 2019 at 9:05 AM Craig Everhart <[email-masked]> wrote:

> It would be based on an articulation of exactly what should be the
> contents of an integrity "blob"--e.g., something like an HMAC_SHA256
> computation based on the file contents and a specific authorizing key,
> presumably associated with the originating provenance of the file: some
> private key associated with an originator's certificate, or a PSK.
>
>> > 2)  Fully define the contents of the new attribute such that
>> independent implementations can be achieved. This would include, but is not
>> limited to, the open definition of the content of the new attribute and the
>> procedures associated with defining new content and interpretation thereof.
>> >
>> > If option 1) were chosen, I would still be of the opinion that the
>> draft should not move forward since it would present another barrier to
>> open, interoperable implementations.
>>

---

From: David Noveck <[email-masked]>
Date: Mon, 28 Oct 2019 13:14:40 -0400

>To the statement of the server implementation, the document refers to the
server's ability to check the file content.
> This to me meant that there was a client / server interoperability issue
at hand.  I note that the server is not
> required to implement the capability but if it is possible, then it
should be well defined.

Agree.

> This is the question of client interoperability.  If two separate client
implementations to follow the "IMA standard for
> Linux", then there should be an open definition of what that standard is
in my opinion.  And I do mean the ability
> to implement with clarity about how and what implications there are for
any intellectual property that exists.

Right.   This is why "just look at the (open) source" is not a solution.
 I'm not sure of the exact legalities but feel that some people might
justifiably feel that doing so exposes them to the possibility of viral
infection.

I think this is the issue that Craig's suggestion would address.

On Mon, Oct 28, 2019 at 12:37 PM spencer shepler <[email-masked]>
wrote:

> If this is an attribute that is in support of the Linux method of
> operation and only ever intended to be such, then retitle the document to
> make that clear and remove the extraneous content of the document.  This
> will make it clear to the reviewer what the intent is.
>
> My comment was not meant to offer an alternative solution to the
> document's proposal but rather to suggest that there are other areas of
> "integrity" that could be addressed that would result in utility.  If the
> working group finds the area interesting, this may be a potential path.
>
> Spencer
>
>
>>
>>
>> --
>> Chuck Lever
>>
>>
>>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 28 Oct 2019 14:39:27 -0400

> On Oct 28, 2019, at 12:36 PM, spencer shepler <[email-masked]> wrote:
> 
> 
> Chuck,
> 
> inline for comments.
> 
> If the attribute is truly opaque to one implementation, then state it clearly.

I don't understand the "if" clause. The NFS implementations do not
interpret this metadata _ever_.

The metadata can be interpreted on a server host by a private security
module. But that is separate from the NFS server implementation itself.
The NFS implementation on the server does not interpret this metadata.
I'm defining a transport for the metadata, and nothing more.

> If this is an attribute that is in support of the Linux method of operation and only ever intended to be such, then retitle the document to make that clear and remove the extraneous content of the document. This will make it clear to the reviewer what the intent is.

How about "Transport and Storage of Linux Integrity Metadata for
Network File System 4" ?

> To the statement of the server implementation, the document refers to the server's ability to check the file content.  This to me meant that there was a client / server interoperability issue at hand.  I note that the server is not required to implement the capability but if it is possible, then it should be well defined.

An NFS server is merely a vessel for integrity metadata. If the
server happens to have an integrity appraisal module, then that
module will process the metadata. The NFS server implementation
itself does not parse this metadata.

> This is the question of client interoperability.  If two separate client implementations to follow the "IMA standard for Linux", then there should be an open definition of what that standard is in my opinion.

There is no open definition of this metadata other than the
implementation in Linux and the wiki that describes how to use it.
In other words, IMA is an application that uses NFS (or any other file
system) to store its data.

> And I do mean the ability to implement with clarity about how and what implications there are for any intellectual property that exists.
>  
> 
> I am asking for clarity.  Either the attribute is opaque and that is clear to everyone or there is enough information to create interoperable implementations as mentioned above.

It is opaque, period. There is not enough information in this document
to implement appraisal, and that's on purpose. The document is meant
to define a transport mechanism only.

> > If the effort was more focused on more traditional data integrity from source to consumption, that would be a more interesting use case.

That's exactly what this mechanism is supposed to achieve. The metadata
is a signed hash of the file's content. It is not interpreted and should
remain unaltered from the point the content is created to the point
where it is used. There, an independent mechanism appraises the content
and the metadata to see if any alteration has occurred since the hash
was signed.

Appraisal is done at the point when file content is about to be used.
With NFS, most frequently that would be on an NFS client system. That
does not mean the NFS client implementation itself does the appraisal.

The focus here is on read-mostly data (software distribution) because of
the high overhead of re-signing the file content hash in a secure fashion.
The key material is stored in TCMs.

Suppose an OS implementer wants to implement something that interoperates
with Linux's IMA. It is up to that implementer to approach the Linux IMA
community and get them to provide this information.

Does anyone have suggestions as to where the Linux IMA community should
go to publish a standard describing the integrity metadata format?
Maybe the Trusted Computing Group ? Somewhere else?

Would it make sense to make up our own integrity metadata format just
for NFS? Or, perhaps we leave this explicitly to storage vendors to enable
them to innovate. As the generation and appraisal of this metadata occurs
outside of the filesystem, it is possible to provide plug-ins that handle
this.

> With the rise of large scale data center usage of NFS (e.g. cloud computing) where customers expect data integrity or the identification of failure, the scale of cloud computing presents many opportunities for the loss of data integrity and NFS (and the client and server implementations thereof) do nothing to ensure data integrity.  The draft does mention spot fixes of data-at-rest methods, and in-transit methods, but there are many points that present areas of potential failure, and these are ignored in today’s implementations (at least to this commenter's knowledge).
> 
> My comment was not meant to offer an alternative solution to the document's proposal but rather to suggest that there are other areas of "integrity" that could be addressed that would result in utility.  If the working group finds the area interesting, this may be a potential path.

The discussion in the room during IETF 105 suggested there was interest
enough to move this document forward to publication. I thought this
whole issue had been resolved at that time, as the conversation finished
with an understanding that this was opaque metadata and that the next
step was WGLC.

Of the two options, IMO option 1 is the only sensible one because there
is no citable specification of what goes in the metadata. However you've
stated you will object if I take option 1. I don't have any strong sense
of how to move this forward. Is there an appropriate opportunity for a
design phone call to work all this out?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 28 Oct 2019 15:28:23 -0400

> does not mean the NFS client implementation itself does the appraisal.

Perhaps not but the fact is that if you want to have a client implementation
you need to know the formal so that appraisal can be done correctly.   The
fact that this is not within the Linucx Client as you would describe it is
to me
a distinction without a difference.

> community and get them to provide this information.

That is the problem that people are concerned about.   I think some people
want one now  and I can see their point although I don't have any need for
this
data.

> Maybe the Trusted Computing Group ? Somewhere else?

I have no suggestions in this regard but am sure that if the Linux IMA
community
were willing to do this it could find some place suitable.

> for NFS?

No.

> Or, perhaps we leave this explicitly to storage vendors to enable
> them to innovate.

I don't see much much interest in that.

> As the generation and appraisal of this metadata occurs

But to interoperate successfully everybody's plug-in would have to
implement the
same format.   That's why a specification of that format is needed to
provide
interoperability.

> enough to move this document forward to publication.

There was and there still is.

> I thought this
> with an understanding that this was opaque metadata

It did but apparently there were people not present who now feel that it
cannot
be treated as totally opaque and needs to be documented.

> the next step was WGLC.

I still think it should be.   However, during WGLC, objections  will
inevitably be offered to the lack of a specfication of the integrity
metadata fomat. While I don't need this and would prefer that
this go forward even without it, I don't feel that these objections
can simply be dismissed.

> is no citable specification of what goes in the metadata.

The alternative is to create one.   I don't understand why it is so
difficult
given that there is an implementation that can be examined to determine
the format.

On Mon, Oct 28, 2019 at 2:40 PM Chuck Lever <[email-masked]> wrote:

> > > In short, I am opposed to moving this draft to last call in its
> current state.  Generally, the draft describes the Linux implementation of
> a feature that is to be extended via NFS.  However, the description
> provided is insufficient for interoperable implementations to be achieved.
> >
> > To the statement of the server implementation, the document refers to
> the server's ability to check the file content.  This to me meant that
> there was a client / server interoperability issue at hand.  I note that
> the server is not required to implement the capability but if it is
> possible, then it should be well defined.
>
> be an open definition of what that standard is in my opinion.
>
> > And I do mean the ability to implement with clarity about how and what
> implications there are for any intellectual property that exists.
> >
> >
> > I am asking for clarity.  Either the attribute is opaque and that is
> clear to everyone or there is enough information to create interoperable
> > > Note that I am also doubtful of the use case being presented. Using
> NFS to directly store and supply application executables seems to be in
> rapid decline or has already fallen out of use.  Given the rise of
> virtualization and the hosting of virtual disks on NFS along with the rise
> of containers and distribution thereof, application distribution seems to
> be a thing of the past with respect to their store/retrieval from NFS
> mounts.
> >
> source to consumption, that would be a more interesting use case.
>
> > With the rise of large scale data center usage of NFS (e.g. cloud
> computing) where customers expect data integrity or the identification of
> failure, the scale of cloud computing presents many opportunities for the
> loss of data integrity and NFS (and the client and server implementations
> thereof) do nothing to ensure data integrity.  The draft does mention spot
> fixes of data-at-rest methods, and in-transit methods, but there are many
> points that present areas of potential failure, and these are ignored in
> today’s implementations (at least to this commenter's knowledge).
> >

---

From: Chuck Lever <[email-masked]>
Date: Mon, 28 Oct 2019 16:05:34 -0400

> On Oct 28, 2019, at 3:28 PM, David Noveck <[email-masked]> wrote:
> 
> fact that this is not within the Linucx Client as you would describe it is to me
> want one now  and I can see their point although I don't have any need for this
> data.

That's my problem with the request: no-one here has a real need
for this metadata format except for Linux, where it is already
implemented.

The only fresh real-world need is to be able to store and transport
this metadata on behalf of OS implementations that can generate and
interpret it.

Thus the additional request for a specific format definition seems
specious to me.

> I have no suggestions in this regard but am sure that if the Linux IMA community
> But to interoperate successfully everybody's plug-in would have to implement the
> same format.   That's why a specification of that format is needed to provide 
> interoperability.
> 
> It did but apparently there were people not present who now feel that it cannot
> metadata fomat.

If the document is clear that this is a transport protocol, and treats
the metadata as opaque, they should have the same reaction as others
did during our conversation at IETF 105: that this is perfectly
reasonable for a transport protocol.

> While I don't need this and would prefer that 
> The alternative is to create one.   I don't understand why it is so difficult

The difficulty isn't that I can't look at the format and spell it out
somewhere, but rather: If the IETF documents this format, then the IETF
becomes responsible for publishing it as a standard. I don't think either
the Linux community or the IETF wants to take this step with something so
far outside of the purview of either the IETF or the nfsv4 WG. It ties
everyone down -- and as mentioned above, there doesn't yet seem to be
any need for that.

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

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 Lever

---

From: spencer shepler <[email-masked]>
Date: Mon, 28 Oct 2019 23:15:12 -0700

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.

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.

There have been other implementations of this type of ride-a-long or
side-band protocol in the past.  The Solaris ACL protoocl for example - and
there are others.  To be honest, that seems to be what is needed for
Linux.  Just create a small RPC protocol that can ride on top of the NFS
port and shares the same file handles and it should be good to go.

Spencer

---

From: Chuck Lever <[email-masked]>
Date: Tue, 29 Oct 2019 11:33:18 -0400

> On Oct 29, 2019, at 2:15 AM, spencer shepler <[email-masked]> wrote:
>> 
>> 
>> 
> 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.

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 believe your characterization is incorrect.

> There have been other implementations of this type of ride-a-long or side-band protocol in the past.  The Solaris ACL protoocl for example - and there are others.  To be honest, that seems to be what is needed for Linux.  Just create a small RPC protocol that can ride on top of the NFS port and shares the same file handles and it should be good to go.

As I state above, I'm seeking a standards-based NFS protocol extension
because I would like to see non-Linux NFS servers store this metadata. The
question of whether non-Linux NFS servers want to interpret and use it is
left open for another time.

The same arguments were made for user xattrs, which are opaque to the NFS
protocol. I don't see how this situation is different from those or from NFS
Security Labels, which are also largely Linux-only, and could have been
implemented using a side-band RPC protocol.

I am trying to meet your requirements, but because there is currently no
published standard for the metadata format, it is difficult. I am only the
messenger here.

Can you help me understand why those extensions were appropriate but the one
I'm requesting now is not? And, why is it not appropriate to split the
standard for IMA on NFS into a transport document and later, something that
might define the metadata format?

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Oct 2019 12:24:09 -0700

A few points/questions inline:

> >> 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.

>    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).

> > 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.

> implemented using a side-band RPC protocol.

Everything I've heard about this so far sounds very similar to user xattrs
in terms of how much the NFS layer knows about what is being transported.
And I don't have a problem with NFS supporting xattrs!

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Thu, 31 Oct 2019 15:54:22 -0400

> On Oct 31, 2019, at 3:24 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

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

> endpoint security and endpoint assessment (e.g., the SACM WG).

That's interesting! I'll investigate.

> 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