Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt
Bruce Fields <bfields@fieldses.org> Thu, 27 September 2018 01:13 UTC
Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84837127AC2 for <nfsv4@ietfa.amsl.com>; Wed, 26 Sep 2018 18:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN6ab-_1a8LL for <nfsv4@ietfa.amsl.com>; Wed, 26 Sep 2018 18:13:28 -0700 (PDT)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id B750212777C for <nfsv4@ietf.org>; Wed, 26 Sep 2018 18:13:28 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 01B007EC; Wed, 26 Sep 2018 21:12:57 -0400 (EDT)
Date: Wed, 26 Sep 2018 21:12:57 -0400
From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20180927011257.GC2715@fieldses.org>
References: <153780090601.28221.16958675117475194416@ietfa.amsl.com> <CADE569F-8584-42CF-A297-E60956D368A2@oracle.com> <CAKKJt-fmB5psmtbm9PJTnhkZkZLCBnCVZnr3fMsf++exN5XObQ@mail.gmail.com> <20180926202157.GA826@fieldses.org> <1F2E60B5-E09F-4B33-8301-99C5E5A0F310@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1F2E60B5-E09F-4B33-8301-99C5E5A0F310@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/fD8pq7W0r8Xljs0-SXyVF5nlM3c>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 01:13:31 -0000
On Wed, Sep 26, 2018 at 01:27:41PM -0700, Chuck Lever wrote: > > On Sep 26, 2018, at 1:21 PM, bfields@fieldses.org wrote: > > "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. > > 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? 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. > > "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? > > 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. 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.
- [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-me… internet-drafts
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Spencer Dawkins at IETF
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… J. Bruce Fields
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Bruce Fields
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Bruce Fields
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Everhart, Craig
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Everhart, Craig
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Bruce Fields
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Everhart, Craig
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Quigley, David
- Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrit… Chuck Lever