[secdir] review of draft-ietf-nfsv4-scsi-layout-06
Stephen Kent <kent@bbn.com> Tue, 02 August 2016 19:49 UTC
Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6512D867 for <secdir@ietfa.amsl.com>; Tue, 2 Aug 2016 12:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 DBseZ3g9t0ZN for <secdir@ietfa.amsl.com>; Tue, 2 Aug 2016 12:49:30 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A1112D7B0 for <secdir@ietf.org>; Tue, 2 Aug 2016 12:49:30 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:35535 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1bUfgZ-0008WH-TI; Tue, 02 Aug 2016 15:49:08 -0400
To: secdir <secdir@ietf.org>, hch@lst.de, spencer.shepler@gmail.com, beepee@gmail.com, spencerdawkins.ietf@gmail.com, leifj@sunet.se
From: Stephen Kent <kent@bbn.com>
Message-ID: <753991fe-9379-c6cd-9342-4c837a81e6db@bbn.com>
Date: Tue, 02 Aug 2016 15:49:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------B62E64E575DBDA929184A3E1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uawebl--ipGlKtvfeCY_2PBd8SI>
Subject: [secdir] review of draft-ietf-nfsv4-scsi-layout-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 19:49:32 -0000
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This document the SCSI layout for Parallel NFS (RFC 5663). It appears to update that RFC (see the last paragraph on page 3), although the header does not indicate this. In section 1 the text refers to a SCSI device “signature” but does not define this term. Section 2.1 describes the security responsibilities for clients, and notes that the Security Considerations section (4) provides an expanded discussion. The bottom line is that SCSI layout pNFS is not recommended for use in contexts where clients cannot be trusted to enforce file access controls. I did not review later parts of Section 2. Section 3 reiterates the fact that SCSI layout pNFS relies on clients to enforce access controls and locks at a granularity finer than a device. For example, the architecture relies on client software to not try to access blocks on a device other than those to which the metadata server has granted access. Sections 3.1 and 3.2 provide additional descriptions of the security assumptions and limitations associated with SCSI layout pNFS. TheSecurity Considerations section consists of two paragraphs. The first reminds the reader that NFS security mechanisms may not be available in the SCSI layout pNFS context, because it operates at a lower layer than NFS. This mode of operation for pNFS may be insecure, or may be afforded good security, depending on the underlying access protocols. iSCSI (RFC 7143) is cited as an example of the latter.The second paragraph reiterates the warnings that appeared earlier in the document, noting that this mode of pNFS is not suitable for all environments. I think the discussions of security provided by this I-D are appropriate and clearly written.
- [secdir] review of draft-ietf-nfsv4-scsi-layout-06 Stephen Kent