[secdir] Secdir review of draft-ietf-nfsv4-rpcsec-gssv3-14

Radia Perlman <radiaperlman@gmail.com> Wed, 16 December 2015 03:10 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839141A1BD7; Tue, 15 Dec 2015 19:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 Tq7mEng5swgd; Tue, 15 Dec 2015 19:10:30 -0800 (PST)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 7CD891A1BC2; Tue, 15 Dec 2015 19:10:20 -0800 (PST)
Received: by mail-ob0-x22e.google.com with SMTP id iw8so23039586obc.1; Tue, 15 Dec 2015 19:10:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GtM82lUV/Lh3p7jx/yGZQ3rtC/N3kEtFwilbbIkVebA=; b=ue1qq4wRY46p3pWukj7TenAf3+A8ykY8AJDM44Roll9QpITaSOubNul0lIn8+UpPF7 ocds9DzrvhbQj6CTRJSfwAiFP2TvJW7Sciw5ECC7peBEzpH5xz/ufNv/h6Achl+68xNb OlvfSiVaF5tOiwHeHt7quejTR5hnCGP5yLTJeTGhZFLUoA7G/mfVEXH6COP7GYT/0jjk WiP46mv9LO8aiuBruyFt/kijyVHkeTXnBUjXsD3b5cgolBX1maI9iNj5jiz3TloKOPXd 2eKI2XYWdTV8WF7aBbCPJEK2dSzuo8GKff7pkhCpIQVbMgrszeCmmY/avfSLA8j1c9v+ f1vA==
MIME-Version: 1.0
X-Received: by 10.182.63.82 with SMTP id e18mr1206915obs.28.1450235418532; Tue, 15 Dec 2015 19:10:18 -0800 (PST)
Received: by 10.182.172.40 with HTTP; Tue, 15 Dec 2015 19:10:18 -0800 (PST)
Date: Tue, 15 Dec 2015 19:10:18 -0800
Message-ID: <CAFOuuo5ZBH3RW_nCGzOSPsrZrK31BiQ3pEjgBTsfOj6F-BXGcA@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcsec-gssv3.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=e89a8fb1ec64f663460526fb3e03
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/GSCSGGeHjaIs1K9wfhCS6N2ArnY>
Subject: [secdir] Secdir review of draft-ietf-nfsv4-rpcsec-gssv3-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 16 Dec 2015 03:10:34 -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 just
like any other last call comments.

Note I'm reviewing the version 14 (although it was version 13 in the
assignments list).

The document specifies where to carry Mandatory Access Control information
in the protocol. It does not specify the Mandatory Access Control
information itself… that is inherited from another spec.

The language in places is a bit foreign to me, perhaps because I don't
"speak" GSS-API or mandatory access control.  So, for instance, in the
sentence

    "Existing GSS-API mechanisms are insufficient for communicating certain
aspects of authority               to a server"

I gather from context that this is authorization information.  I'd have
said "...insufficient for communicating certain authorization
information".  If "aspects of authority" means something else then perhaps
"aspects of authority" should be defined here, even if defined elsewhere.
If indeed this is common terminology then OK.

There's a typo in section 2.5  "with an acccept stat of PROC_UNAVAIL"
 (extra "c" in accept)

Radia