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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> wrote:
> >> 
> >> On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <[e-mail]> wrote:
> >> 
> >> > On Oct 28, 2019, at 3:28 PM, David Noveck <[e-mail]> 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.

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

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

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