[nfsv4] Review of draft-ietf-nfsv4.integrity-measurement-07
David Noveck <davenoveck@gmail.com> Sat, 02 November 2019 11:35 UTC
Return-Path: <davenoveck@gmail.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 1DA101200C3 for <nfsv4@ietfa.amsl.com>; Sat, 2 Nov 2019 04:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QSXSS8Cj3HhR for <nfsv4@ietfa.amsl.com>; Sat, 2 Nov 2019 04:35:34 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7BB120089 for <nfsv4@ietf.org>; Sat, 2 Nov 2019 04:35:33 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id k2so10295115oij.12 for <nfsv4@ietf.org>; Sat, 02 Nov 2019 04:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Kcs8wqDqyYxqJpw1b5iROYg2Ol+f0H76rpYjBaHZqpU=; b=PprtMGAXSBpdAo0a/jN42TR4MtjIPbkkw9dIancHgYco6Avwb5FGfkTVfCS8khbQFf UYIXqnd7NqJffjzMn93p0xNL5mJi1yi6dxTO7zxc3tCjUFE6tWJDUGTQB1S+lVg5Yiy5 nZ2LKpx1qE38fZcClwMD5jVbXO7s4AXyIby2Sl81O48S4elADJr0MYASwnK1zpy8jPrW rp6CsNs7ooDO4mbv1sspiRi76AS8KI+wcQ9u4JINFBUqfPF0cSoCkZibXdQ/683Rpqgy halwPl/bRNPTnWCpJi6AvWSLykj+wth3LnZHzdKP7eQDMWuu6lQ2m8ibnwESuszTwBGC W3GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Kcs8wqDqyYxqJpw1b5iROYg2Ol+f0H76rpYjBaHZqpU=; b=LMNMfUSScX2NO6ObdwRM92HxD+Bg8D67NqcPM4W7BWqFM1ymg/MdkBvz4yTOqmeReH w+D/EXo1XJ+Oxururj2A6ynztfn4SEKeCIKTFA4EUOz6ZrU0jAodtmWDWm1rh2ji9pzZ JWc/QaUyjXhVioGcBEBPu2nd8y9Wz9M15EaR5NWB/KqyC8D7vgLyWeeefofIQ3J/EmTE L+ZZjlhZCBtFwP/4rSDSOFmK3G0Hz1kfdYw96L64GFJN0C5+TDC3Q0ghi5NSjoCotOGu LHRJIFX7lGr+5UHn4/nnUHCJwRBoDfGLqJ/Fw++JqkAPupTJVYn8X4Gw0ZTDac87vp69 uOXA==
X-Gm-Message-State: APjAAAWvifaVFGvet1/JlTc5lFD26vGcH1GZykBCzF9y54xClxrDqC7v sim+Vw2SinvY9nrrTObvVRucN3AoZUCy5hWvBAacLg==
X-Google-Smtp-Source: APXvYqz9t8iNH8HfNCcb1CqnEP3zOkftafIGkvHhQNkhh/1mZ+PiAEgS5N+udkkH5GHlEf7l88WKh3EZNb14W192xAE=
X-Received: by 2002:a54:4701:: with SMTP id k1mr8418020oik.47.1572694532777; Sat, 02 Nov 2019 04:35:32 -0700 (PDT)
MIME-Version: 1.0
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 02 Nov 2019 07:35:21 -0400
Message-ID: <CADaq8jdbdgAuq5wuO2kJLy9T5Juq_dUyRF60Ec4JxC2AVWbfxw@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f76ede05965b7a0a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/TSV9ANr56Bvis0JeQdtboYHmp1o>
Subject: [nfsv4] Review of draft-ietf-nfsv4.integrity-measurement-07
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: Sat, 02 Nov 2019 11:35:36 -0000
*General Comments* *Overall Evaluation* This document is in good shape and I feel it is ready for Working Group Last Call. While I note some potential improvements below in *Per-section Comments,* I feel these changes could reasonably be made as part of last call rather then needing to be be done before that time. However, if there are plans for a -08, I feel it would simplify things if some of the suggestions made here were considered for inclusion in -08 *Possible Overuse of the Word "MUST"* I feel that the use of "MUST" within this document is not in accord with the advice given in RFC2119 that these terms be used "sparingly". Although I haven't looked at each such use, where I suggest rewriting for other reasons, I would only use "MUST" where there is a special reason to do so. *Issues Related to Documentation of IMA Metadata Format* There has been a lot of discussion/comment on the mailing list regarding the fact this format is not documented in this draft. Some of the suggestions made in *Per-section Comments *are intended to make it clearer why this has not been done. While I feel this would be helpful, I have no expectation it will resolve the objections that have been expressed, which I don't fully understand. While I do not think that this issue should pose any obstacle to publication, it might make it hard for the working group to arrive at a consensus for publication. Nevertheless, I feel we need to move to WGLC and try to resolve the issue in that context, as I feel that discussion on the list so far has not been all that helpful. *Per-section Comments* *Abstract* Suggest addition of the following sentence: "The format of the IMA Metadata is not described in this document." *1.1. The Linux Integrity Measurement Architecture* In the first paragraph, suggest replacement of the phrase "local tinkering" by "other local modifications" *1.1.1. IMA Metadata* The last paragraph of this section, while a correct description of the current situation may give readers pause since it suggests the possibility of an interoprerability nightmare. Even though such a scenario is, strictly speaking, out of scope, I believe it would be helpful to assure people that steps are being taken to avoid it, even though those steps are being taken by others. For that reason, I am proposing replacing that parapraph by the following two paragraphs. The precise format of this metadata is currently determined by policies set by the local security administrator. The metadata and its format are opaque to the mechanisms that store or transport it (i.e. filesystems). The particulars of the PKI and the hash algorithm are set by local policy. In order to provide interoperability, there is a need to provide agreement on these matters by an out-of-band mechanism so that the IMA data can be recorgnized by all participating IMA subsystems. The difficulties which arise when multiple formats are supported makes it likely that a sinlgle format will be arrived at, avoiding the need for an out-of-band agreement mechanism. However the details of that format and the means by which it will standardized remain uncertain at this tiime. *3. Protocol Extension Considerations* In the last clause of the last sentence of the last paragraph suggest replacing "does not update [RFC7862] or [RFC7863]" by "updates neither [RFC7862] nor [RFC7863]" *4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY)* Suggest that the following additional paragraph be added to this section: This error provides a means by which servers which implement an internal apprasal mechanism may communicate to the client the fact that an appraisal failure occurred, causing the requested operarion not be be performed. *4.2.1. Reporting Server-Side IMA Appraisal Failures* Suggest rewriting the first paragraph to read as follows: An NFS server that implements an internal appraisal mechanism needs to be able to report integrity-related failures to clients. In the absense of the NFS4ERR_INTEGRITY error, described in Section 1.1,1, a server implementer would be forced choose choose one of the status codes that were available in the base NFS version 4.2 protocol, typically NFS4ERR_IO or NFS4ERR_ACCESS, even though these code points have generic meanings that do iindicate an integrity-related failure. *4.3.2. Authorizing Updates to IMA Metadata* As written, the second pragraph, does not make any provision for the possibility that update of IMA Metadata would be supported for some but not all of the file system on a particular server. If it is desirable to allow this possibility suggest rewriting this paragraph as follows: If an NFS server implementation does not support modification of IMA metadata via NFS within a particular file system, the server returns NFS4ERR_INVAL to a SETATTR request within that file systen with the FATTR4_IMA attribute, as specified by Section 5.5 of [RFC5661]. *4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY)* Suggest rewriting the second paragraph as follows: When implementing these operations, the server is to use a simple byte-by-byte comparison to evaluate whether the client-provided FATTR4_IMA matches the FATTR4_IMA attribute associated with the target object. If the server has a local IMA appraisal implementation, its failure MAY prevent the use of the local FATTR4_IMA attribute value for the purpose of this comparison. In the event that this happens, the appraisal failure is indicated by returing NFS4ERR_INTEGRITY if the client has indicated support for IMA metadata, with NFS4ERR_ACCESS used otherwise. *8. IANA Considerations* Suggest replacing "has no" by "does not require any"
- [nfsv4] Review of draft-ietf-nfsv4.integrity-meas… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4.integrity-… Chuck Lever