Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

From: [email-masked]
Date: Mon, 24 Sep 2018 07:55:06 -0700

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           : File Content Provenance for Network File System version 4
        Author          : Charles Lever
	Filename        : draft-ietf-nfsv4-integrity-measurement-01.txt
	Pages           : 9
	Date            : 2018-09-24

Abstract:
   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables file provenance information to be conveyed
   between NFS version 4.2 servers and clients.  File provenance
   information authenticates the creator of a file's content and helps
   guarantee the content's integrity 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-01
https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-integrity-measurement-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-integrity-measurement-01

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/

---

From: Chuck Lever <[email-masked]>
Date: Mon, 24 Sep 2018 08:06:39 -0700

> On Sep 24, 2018, at 7:55 AM, [email-masked] wrote:
> 
> 

As a result of the discussion at IETF 102 and recent follow-ups
on this mailing list, I've made substantial changes to this
document.

- References to and discussion of Linux IMA have been replaced
throughout the document, with the exception of a single citation
as an informative example in the Introduction. IMA metadata is
now referred to generically using the term "file provenance
information".

- Integrity checking of file attributes is no longer an included
feature. There were some issues that made attribute integrity
not straightforward for NFS, especially without an existing
IMA/EVM standard even for local file systems. Attribute
integrity can still be addressed at a later time.

- The Introduction now makes a problem statement and discusses
use cases instead of explaining the mechanism of file integrity
checking. The new Introduction addresses the most common
questions I've received during previous review.

Spencer D. and other reviewers:
- Have previously stated interoperability concerns been addressed?
- Have normative citation requirements been sufficiently met?

I know time is precious, but even a cursory review of this new
revision would be helpful. It's wafer-thin!

--
Chuck Lever

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 24 Sep 2018 10:45:29 -0500

Hi, Chuck,

> - Have normative citation requirements been sufficiently met?

Recognizing that I haven't done an AD Evaluation of this draft, but looking
at the responses to my previous questions, I think dropping down to one
explicit mention of IMA pointing to the best available reference is about
right.

Thanks for making that change. It will be helpful during Last Call and IESG
Evaluation.

Spencer (D)

---

From: Chuck Lever <[email-masked]>
Date: Mon, 24 Sep 2018 09:22:48 -0700

> On Sep 24, 2018, at 8:45 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Chuck, 
> Recognizing that I haven't done an AD Evaluation of this draft, but looking at the responses to my previous questions, I think dropping down to one explicit mention of IMA pointing to the best available reference is about right. 
> 
> Thanks for making that change. It will be helpful during Last Call and IESG Evaluation.

Thanks for the quick response!

--
Chuck Lever

---

From: [email-masked] (J. Bruce Fields)
Date: Wed, 26 Sep 2018 16:21:57 -0400

> explicit mention of IMA pointing to the best available reference is about

	"A keyed hash authenticates the identity of the last modifier of
	a file's content and serves as a strong check of the content's
	integrity.  For the purposes of this document, we will refer to
	this as file provenance information.  The Linux Integrity
	Measurement Architecture (IMA) is an example of a mechanism for
	assessing file content provenance [IMA-WP]."

I think it's also true that this draft is sufficient to allow a client
to support IMA?  That also seems worth mentioning.

	"To ensure interoperability among accessors of this information
	when it is stored on NFS version 4.2 servers, this information
	MUST be self- describing."

How do you propose that an implementation would make the information
self-describing?

--b.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Wed, 26 Sep 2018 13:27:41 -0700

> On Sep 26, 2018, at 1:21 PM, [email-masked] wrote:
> 

I'm confused by your remark. I'm describing a transport
protocol between a NFS client and server. Why would it
not be sufficient to implement client support? Or, what
do you believe might be missing in the draft?

> How do you propose that an implementation would make the information

That is out of scope for this draft.

But typically if an integrity service wanted to do this, it
could use XML or JSON to describe the information, for example.

An HMAC has a particular structure (RFC 2104) that should be
easy to recognize.

--
Chuck Lever

---

From: Bruce Fields <[email-masked]>
Date: Wed, 26 Sep 2018 21:12:57 -0400

On Wed, Sep 26, 2018 at 01:27:41PM -0700, Chuck Lever wrote:
> not be sufficient to implement client support?

Oh, I was pretty sure it was, just thought it was worth making that
explicit.  "The Linux Integrity Measurement Architecture (IMA) is an
example of a mechanism for assessing file content provenance, and the
protocol described in this draft could be used to implement IMA."  Or
something like that.

> An HMAC has a particular structure (RFC 2104) that should be

OK, but you do have to know how all the other clients are formatting the
information.  I don't quite understand what's meant by ensuring
interoperability, then.

I guess I expected to see something like say a 32-bit "type" field with
implementations able to register different "type" values so you could at
least tell whether it should bother trying to parse a given file
provenance field.

Maybe it's not necessary.  I wonder what would would happen in practice.
I geuss if people deployed two different clients that both claimed
support for file provenance, they might be surprised when they started
randomly throwing errors when one client tries to read files written by
another.

--b.

---

From: David Noveck <[email-masked]>
Date: Thu, 27 Sep 2018 05:55:02 -0400

> Why would it not be sufficient to implement client support?

I think it is sufficient.

> Or, what do you believe might be missing in the draft?

Not sure what Bruce had in mind but I think the problem is something that
is in the draft that shouldn't be, rather than something missing.

> That is out of scope for this draft.

If so, then so is "*MUST* (emphasis added) be self-describing".

> But typically if an integrity service wanted to do this

If it were really a "MUST", then what an integrity service wants to do
should be irrelevant.

On Wed, Sep 26, 2018 at 4:27 PM Chuck Lever <[email-masked]> wrote:

> >>>> This draft is a work item of the Network File System Version 4 WG of
> the
> >>> IETF.
> >>>>
> >>>>       Title           : File Content Provenance for Network File
> System
> >>> version 4
> >>>>       Author          : Charles Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 08:24:08 -0700

> On Sep 27, 2018, at 2:55 AM, David Noveck <[email-masked]> wrote:
> 
> Not sure what Bruce had in mind but I think the problem is something that is in the draft that shouldn't be, rather than something missing.
> 
> If so, then so is "MUST (emphasis added) be self-describing".

I don't agree.

MUST means that we are stating a requirement for correct
interoperability. A self-describing FPI payload is a requirement
for interoperation. Implementers, as always, are free to ignore
this requirement.

> If it were really a "MUST", then what an integrity service wants to do should be irrelevant.

I'm open to suggested replacement texts.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 08:31:58 -0700

> On Sep 26, 2018, at 6:12 PM, Bruce Fields <[email-masked]> wrote:
> 

I don't think it's helpful to insert the WG and IANA in the
process of deciding the type of information in the FPI payload,
especially when the structure of that payload is out of the WG's
hands.

Either the clients look at a 32-bit enum value, or they look at
the payload and figure out what it is. I can't see how it makes
any operational difference.

> randomly throwing errors when one client tries to read files written by

Typically, an NFS server serves a fleet of clients that have a
common administrator who provisions and configures these clients
to recognize the same FPI payload.

The consequences of not recognizing the file provenance information
are not dire. In those cases, clients simply don't allow access to
the file's content, and the implementations are free to report to
the administrator that the FPI format is not recognized.

Would it help to state that in the draft?

--
Chuck Lever

---

From: Bruce Fields <[email-masked]>
Date: Thu, 27 Sep 2018 11:55:46 -0400

Just to be clear, I don't claim to know what's best, I'm just want to
make sure I understand the decisions here:

> especially when the structure of that payload is out of the WG's

What would be the problem with, for example, documenting what IMA
currently does?

> any operational difference.

If the client tries to parse it without knowing which implementation
created it, and it turns out it was created by someone else, I guess the
verification will normally fail and maybe that's what you want.

It's not impossible that it could get misparse it and succeed, though.
Maybe there's no realistic situation where that has practical
consequences, I don't know.

> Would it help to state that in the draft?

Maybe so.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 09:06:06 -0700

> On Sep 27, 2018, at 8:55 AM, Bruce Fields <[email-masked]> wrote:
> 

There's no normative standard that defines IMA and what it does.
IMO it would have to be only an example, citing an informative
reference, about how IMA behaves at the time this draft is
published.

This revision of the draft is an attempt to remove the details
of IMA from this document because there is no IMA standard
specification. We could add an example here if we think that
the illustration is going to be of value to implementers.

>> Would it help to state that in the draft?

Craig Everhart has also suggested stating, instead of saying the
FPI payload is self-describing, that there has to exist an out-
of-band agreement between the clients and server about the FPI
format.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 27 Sep 2018 16:09:01 +0000

This exact issue needs to be discussed in the draft--whether it makes sense for clients/servers that don't a-priori recognize the "file provenance" information to reject the communication, and how.  Should non-recognizing servers store the information blind?  Or should they reject such files?

Essentially, the draft seems to imply that there's a well-understood way that some community of file handlers has of describing file provenance.  Instead of explaining what that is, the author(s) of the draft simply want to standardize a way of describing data that is otherwise opaque.  The draft gives no information on how to construct an appropriate file-provenance blob of bits, to my reading, or to explain what a formatted blob of bits would mean.

Let's say that there are multiple communities that all are composed of people that understand some formatting scheme.  How should they interact?  How would I (a file server) take a blob from community A and present it in a way that community B would understand?  Or is this formatting scheme to remain opaque forever?

We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's fine as long as everybody who sees a given name knows how to interpret it.  (This was in the days before UTF-8 or its analogues; we had a lot of localized character sets that people wanted to use verbatim.)  Thank heavens that we no longer have that particular fight.  But this draft feels analogous: it apparently wants NFS to store and retrieve "provenance" blobs without altering them, saying that they have meaningful semantics, but without explaining what those semantics are.

		Craig Everhart

On 9/27/18, 11:32 AM, "nfsv4 on behalf of Chuck Lever" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 09:23:56 -0700

> On Sep 27, 2018, at 9:09 AM, Everhart, Craig <[email-masked]> wrote:
> 

Good point. I can add language that fills that in. In fact
that will be a copy-and-paste from an earlier version of
this document.

> We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's…

Yes, that's what we want to do. This is exactly the same
as storing opaque file data. NFS is conveying and storing
data on behalf of an application which is responsible for
interpreting that data.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 27 Sep 2018 16:59:05 +0000

Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with some other unspecified character encoding scheme.

The analogy here is that you're either trying to reserve an "8-bit-clean" repository of opaque data, where a server doesn't know what it's storing and a separate client has no idea what it's seeing, or you're trying to reserve a particular slot for the sole use of some format that you don't describe.  In that second case, the analogy with file name data isn't so clear: NFS is built around having exactly one (component) file name, without a label explaining how to interpret that file name label.

But you're effectively asking for private use of the "file provenance" name space.  I hope there's never another community that also comes up with a "file provenance" description scheme.

		Craig

    

    
    --
    Chuck Lever

---

From: Bruce Fields <[email-masked]>
Date: Thu, 27 Sep 2018 13:26:42 -0400

> Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with…

Huh, I thought we'd gone the other way--RFC 3530 tried to mandate UTF-8
but that didn't really take.

But I don't know if there's any lesson there.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 11:10:39 -0700

Hi Craig-

> On Sep 27, 2018, at 9:59 AM, Everhart, Craig <[email-masked]> wrote:
> 

We've already taken this route this with NFS security labels. There is
exactly one xattr that can store only _one_ of a MAC label, or SMACK,
or ...

Both cases you describe above are serviceable via the mechanism
I proposed. If there ever is a collision, then the assessment
applications involved can use an XML wrapper to label and store
both types of FPI in the same slot, or they can approach the WG
and request another fattr4 attribute.

Alternatively, an implementation may choose to have a security.ima
xattr for local consumers, and a separate xattr that stores FPI
consumed by remote users.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 27 Sep 2018 18:21:35 +0000

Sigh--great sadness.

How do I tell whether NFS security labels are MAC or SMACK or one of their friends?

Why wait for a collision before specifying how a choice of label formats is represented?

		Craig

On 9/27/18, 2:11 PM, "Chuck Lever" <[email-masked]> wrote:

    Hi Craig-

    

    
    --
    Chuck Lever

---

From: "Quigley, David" <[email-masked]>
Date: Thu, 27 Sep 2018 18:24:36 +0000

SELinux and SMACK use different label formats. You can determine which is which by looking at the LFS identifier for the security label. This is currently set to 0 in the Linux implementation but it should be set to the LFS for the label format that you are using.

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Everhart, Craig
Sent: Thursday, September 27, 2018 12:22 PM
To: Chuck Lever <[email-masked]>
Cc: Bruce Fields <[email-masked]>; NFSv4 <[email-masked]>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

Sigh--great sadness.

		Craig

    Hi Craig-

    

    
    --
    Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Sep 2018 13:33:11 -0700

> On Sep 27, 2018, at 11:21 AM, Everhart, Craig <[email-masked]> wrote:
> 
> Sigh--great sadness.
> 

It's a design philosophy. Avoid overdesign -- don't add something now that you don't need now. I can't think of a use case where you'd want
to have multiple concurrent mechanisms for assessing file integrity.

We could add an LFS-like identifier and an IANA registry, and we'll
have just one entry in it forever.

If you know of a specific potential user of this mechanism that is
not IMA, I'll reconsider.

--
Chuck Lever