[secdir] SecDir Review of draft-ietf-nfsv4-labreqs

Yoav Nir <ynir@checkpoint.com> Sat, 02 November 2013 12:30 UTC

Return-Path: <ynir@checkpoint.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 3D5F011E81FF; Sat, 2 Nov 2013 05:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.377
X-Spam-Level:
X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov3OAnr-+tGg; Sat, 2 Nov 2013 05:29:56 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E011E81FD; Sat, 2 Nov 2013 05:29:54 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA2CTmmf018382; Sat, 2 Nov 2013 14:29:48 +0200
X-CheckPoint: {5274EF09-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 2 Nov 2013 14:29:48 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<secdir@ietf.org>" <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-nfsv4-labreqs.all@tools.ietf.org" <draft-ietf-nfsv4-labreqs.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-nfsv4-labreqs
Thread-Index: AQHO18c3l5Ocx4tIM0WjeGDw7jvwUA==
Date: Sat, 02 Nov 2013 12:29:47 +0000
Message-ID: <FF6A9891-728D-4688-BE3D-663A2C1DF362@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.241]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10E74F5DF062E54B8097AFBDB7C05F63@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir Review of draft-ietf-nfsv4-labreqs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 02 Nov 2013 12:30:02 -0000

I have 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 primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments.

Short version: I think the draft is ready.

This draft is intended to be Informational. It does not specify any standard. Instead, it describes the operating environment and assumptions behind labeled NFS. 

Labeled NFS associates labels with resources (usually files) and processes, where the resources reside on a file server, while the resources run on a client. Such labels (Multi-Level Security is but one example) are then used as a basis for policy decisions. The draft is intended for people not familiar with NFS, and does a good job of explaining the different scenarios. For example, with a limited server, it is up to the client to decide about authorization for accessing resources, and the server functions solely as a store. This model is surprising to people familiar with, for example, web servers, where the resources are considered to belong to the server, and it is up to the server to make authorization decisions. Other NFS servers, called "MAC-functional" have authorization decisions on both client and server.

I found the draft to be well-written and informative.

I have a few comments, but I consider none of them show-stoppers:

- The introduction has this text: "DAC systems offer no real protection against malicious or flawed software due to each program running with the full permissions of the user executing it.". Put like that, this sentence is inflammatory. Discretionary Access Control protects you against unauthorized users running malicious software. It just doesn't protect against "good" users being tricked into running bad software.

- Section 3.3 uses the term "opaque". This is a surprising term, considering this sentence about the opaque component: "The LFS component provides a mechanism for identifying the structure and semantics of the opaque component." So it's not really opaque, is it?  The term "opaque" is commonly used when the data is unparseable by the participants in the protocol. Here, the client and a MAC-functional server can parse this data just fine.

- I think the security considerations is missing some text on what additional security is needed in the case of a limited server that only stores the information. Something should protect the data so that client A's data is not served to client B, even if client B is malicious. 

Yoav