Re: [nfsv4] Review of draft-ief-nfsv4-integrity-measurement-04

Chuck Lever <chuck.lever@oracle.com> Tue, 21 May 2019 20:56 UTC

Return-Path: <chuck.lever@oracle.com>
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 170CF1200A4 for <nfsv4@ietfa.amsl.com>; Tue, 21 May 2019 13:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 RO3DpubxoZq5 for <nfsv4@ietfa.amsl.com>; Tue, 21 May 2019 13:56:19 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07AB12001A for <nfsv4@ietf.org>; Tue, 21 May 2019 13:56:19 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4LKml9s014775 for <nfsv4@ietf.org>; Tue, 21 May 2019 20:56:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=corp-2018-07-02; bh=eE9fbr60/yAnLmnEJvOTV+sd4q/PhtqxoUmV6TAqhuI=; b=Qb5msNBReN9ekf9uEk3/M8m/1me3+HgR/hv9q1ZOibf8UPOm0aoByyhW9pcwwz1hWP/V IXO5SYpelLbRfypZZh4Wb5Tu35jvWxeItxFMoEx3G74RWGWFUJxSAUWhYQi+9oI1h81l OqxkZD3NO6QunP8tAJowDtqUjYi0V0a5xA3se4Tao/AQPfgu/d8Js+5p1927kn31S5y/ Q+6qBkFsLxg6UKYOU+czuR4flhmRghJcF98Oc6Rma9YZKAwn6WGyT6fPRiP93FnBbJBk v9OSrJ1XiEwM47b3yST/QpY04k0O1vJU6AklbI2tIs46thqbe0Rj3i6XRCmi40sA7nbg mQ==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2sjapqfy90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Tue, 21 May 2019 20:56:18 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4LKtXhL166918 for <nfsv4@ietf.org>; Tue, 21 May 2019 20:56:18 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2sks1ydx46-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Tue, 21 May 2019 20:56:17 +0000
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4LKuGJZ020660 for <nfsv4@ietf.org>; Tue, 21 May 2019 20:56:16 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 May 2019 20:56:16 +0000
From: Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 21 May 2019 16:56:13 -0400
References: <CADaq8jc2FoNEYHp282hxjY3EnWH7qQhF=WHomp+W9O5qf85USw@mail.gmail.com> <AACE7624-98E3-47AE-AA4F-BBD752A818AD@oracle.com> <CADaq8jeKEN9MY9hs859hJxfyCjeObOR1vBdWMyjFGF9g+KhnfQ@mail.gmail.com> <6562B008-FDA5-4DE2-B0CE-EC310F372E03@oracle.com> <A3D33A2F-F2ED-49A2-A89B-7E7079AB0BB9@netapp.com>
To: NFSv4 <nfsv4@ietf.org>
In-Reply-To: <A3D33A2F-F2ED-49A2-A89B-7E7079AB0BB9@netapp.com>
Message-Id: <7E63CF3E-29F6-4E10-B2BB-FB56153B0853@oracle.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9264 signatures=668687
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905210130
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9264 signatures=668687
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905210130
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/aLsDseNGD0AujSLZoDntRFlTBD8>
Subject: Re: [nfsv4] Review of draft-ief-nfsv4-integrity-measurement-04
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: Tue, 21 May 2019 20:56:22 -0000


> On May 21, 2019, at 3:54 PM, Everhart, Craig <Craig.Everhart@netapp.com> wrote:
> 
> Hi Chuck.
> 
> It's a little specious to cite RFC8276 as a model for a Linux-only feature, isn't it?

The purpose of that document was to enable support for Linux xattrs
in particular. I'm not aware of plans to implement support in other
OSes; it was driven by a desire to support these objects in Linux.

The fact that there are similar objects in other operating systems
is used in RFC 8276 merely as rationale. It is not a normative
statement.

Note that there is no standard specification for extended attributes
or for the OS APIs that access them.


> It goes to some pains to describe how its xattrs are supported in multiple operating systems (Linux, FreeBSD, Windows's NTFS, with even Swift).  It suggests enough detail for some of the xattrs that it's imaginable that there might one day be semantic interoperation: message-IDs, a URL, checksumming, crypto hashing, source application, etc. All this is lacking in the IMA document.

Sections 2 through 6 of RFC 8276 act as Informational rationale, not
as Normative requirement. I don't see where any of the text in Section
2, for example, provides a detailed enough description that would
enable me to build an interoperable implementation of user xattrs.

For example, I do not see a citation that specifies the format of a
"message-ID" in RFC 8276, either Normative or Informative, and it
is not otherwise described in RFC 8276.

The Introduction of integrity-measurement goes into similar detail
for a similarly informative purpose. In fact that section provides
quite a bit more detail than RFC 8276 does for the particular use
case of IMA metadata.


> One particularly difficult omission from the IMA document is some understanding of the domain of discourse.  In the Linux document, the domain is one Linux machine.  Presumably, the draft intends to extend this domain to all the clients connected to the Linux machine?  It's not clear.  What would it mean?  (What is being intended?)  Is there any guarantee that the IMA implementations are compatible?

IMA metadata is upper layer application data, just like xattrs are.

We have never specified a similar interoperability requirement for
databases stored in NFS files, or for information transferred via
TCP. Questions about interoperability belong in the upper layer in
those cases, and here too, and not in the transport layers.


> How is the "identity of the last modifier of a file's content" converted to a keyed hash?  Is that "identity" something that has meaning outside the single Linux machine, or the one that's acting as the server here?

The hash is computed from the file content.

The hash is signed with a certificate which identifies the source of
the file content or an authority that can verify that the content
is valid.

That certificate was signed by a trust authority that is recognized
on the client hosts where the hashes are appraised.

Any changes to the hash or the file content will be detected when
the file is appraised before use. That makes the content immutable
and the source of the content is identified by the signing cert.


> NB.  I tried to go to the URIs given in the -04 draft; the first directed me to a string of software versions--not the document that I was expecting--and the second didn't resolve.

[1] is http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf

I was able to download that document, entitled "An Overview of the Linux
Integrity Subsystem".

[2] is https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-Summary_04292008.pdf

I was able to view that document in my browser.

FYI, in the next revision, [1] has been replaced by a reference to:

Sailer, R., Zhang, X., Jaeger, T. and L. van Doorn, "Design and
Implementation of a TCG-based Integrity Measurement Architecture",
Proceedings of the 13th USENIX Security Symposium, August 2004.


--
Chuck Lever