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

"Adamson, Andy" <> Tue, 22 December 2015 17:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DA971A8992; Tue, 22 Dec 2015 09:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IS_KwvWAYKnD; Tue, 22 Dec 2015 09:15:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D0C81A899C; Tue, 22 Dec 2015 09:15:30 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,465,1444719600"; d="scan'208";a="84356883"
Received: from ([]) by with ESMTP; 22 Dec 2015 09:10:30 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 22 Dec 2015 09:10:29 -0800
Received: from ([::1]) by ([fe80::d0b6:c2cf:8cbc:16b8%21]) with mapi id 15.00.1130.005; Tue, 22 Dec 2015 09:10:29 -0800
From: "Adamson, Andy" <>
To: Radia Perlman <>
Thread-Topic: Secdir review of draft-ietf-nfsv4-rpcsec-gssv3-14
Thread-Index: AQHRN69zZbHX3YsQJkywCdvQTsMBeZ7XzgwA
Date: Tue, 22 Dec 2015 17:10:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.2098)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Tue, 22 Dec 2015 09:49:02 -0800
Cc: The IESG <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rpcsec-gssv3-14
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Dec 2015 17:15:32 -0000

> On Dec 15, 2015, at 10:10 PM, Radia Perlman <> wrote:
> 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.


draft version 14 says:  Label Assertions

   ….Full mode MAC is
   enabled when an RPCSEC_GSS_CREATE process subject label assertion is
   combined with a file object label provided by the NFSv4.2 sec_label


  Servers that support labeling in the requested LFS MAY map the
   requested subject label to a different subject label as a result of
   server-side policy evaluation.

I guess I could be a bit clearer - "the Label assertion asserts the client process subject labels"

> 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.

We used ‘aspects of authority’ instead of ‘authorization information’ as the multi-principal assertion adds additional authentication. We could change it to ‘…insufficient for communicating certain authorization and authentication information"

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

Oops - thought I got rid of that :)

Thanks for the review


> Radia