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

[Chuck Lever <[e-mail]>]

> On Oct 31, 2019, at 3:24 PM, Benjamin Kaduk <[e-mail]> 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 <[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.

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