[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, 2 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.