Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-08

"Adamson, Andy" <William.Adamson@netapp.com> Fri, 24 June 2016 21:24 UTC

Return-Path: <William.Adamson@netapp.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 D28FA12D674; Fri, 24 Jun 2016 14:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.327
X-Spam-Level:
X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable 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 ovWMGtXqNgYy; Fri, 24 Jun 2016 14:23:56 -0700 (PDT)
Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E00F12B012; Fri, 24 Jun 2016 14:23:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.26,522,1459839600"; d="scan'208";a="124917471"
Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 24 Jun 2016 14:22:21 -0700
Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 24 Jun 2016 14:22:18 -0700
Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::bc9d:c26a:65b2:409%21]) with mapi id 15.00.1156.000; Fri, 24 Jun 2016 14:22:18 -0700
From: "Adamson, Andy" <William.Adamson@netapp.com>
To: Russ Housley <housley@vigilsec.com>
Thread-Topic: SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-08
Thread-Index: AQHRzjdtyikHWcv0hU2EfZTj9Mg2CJ/5leOA
Date: Fri, 24 Jun 2016 21:22:18 +0000
Message-ID: <2CEDD215-51CA-4399-AC1C-A2997D4BDE8E@netapp.com>
References: <988BE781-CAC5-49B8-ADAD-F8637C6776D9@vigilsec.com>
In-Reply-To: <988BE781-CAC5-49B8-ADAD-F8637C6776D9@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.122.56.79]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B90016CF5DAB394594E15CDA1562BDE0@hq.netapp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/J0mpO8nQXGht-T-tim25zFIZbC8>
Cc: "draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org" <draft-ietf-nfsv4-multi-domain-fs-reqs.all@ietf.org>, IESG <iesg@ietf.org>, IETF SecDir <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-nfsv4-multi-domain-fs-reqs-08
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: Fri, 24 Jun 2016 21:24:01 -0000

Hello Russ

Thanks for the review. I’ll respond soon.

—>Andy

> On Jun 24, 2016, at 12:30 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 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 primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
> 
> Version reviewed: draft-ietf-nfsv4-multi-domain-fs-reqs-08
> 
> 
> Summary: Not Ready
> 
> 
> Major Concerns:
> 
> The whole document needs an editing pass.  In many places it talks about
> issues.  To be consistent with the title of the document, it should be
> talking about guidance or deployment alternatives.
> 
> The Abstract does not reflect the content of the document.  Please
> rewrite the Abstract.  Some things that I believe belong in the Abstract
> include:
> 
> - This document provide guidance on the deployment of the NFSv4
>   protocols in environments with multiple NFSv4 domains.
> - The server must offer a multi-domain-capable file system and support
>   RPCSEC_GSS for user authentication.
> - The server must also support identity mapping.
> 
> 
> I did not find the Introduction helpful.  I really needed to read the
> whole document to get a feeling to the guidance that it contains.  The
> reader needs some background that is not directly explained in the 
> Introduction.  I suggest some topics that should be covered in the
> Introduction:
> 
> - Point to NFSv4 specifications
> - Users and Groups are named with the name@domain syntax
> - Explain the difference between an NFS domain and NFSv4 domain
> - This document provides guidance on deploying servers that support
>   multiple NFSv4 domains
> - Features that the NFSv4 server must implementation to work in this
>   environment
> 
> 
> I think it might also be useful to explain some other concepts toward
> the front of the document, but I am not sure if they belong in the
> Introduction or the Terminology section:
> 
> - Stand-alone NFSv4 domain
> - Federated File System (FedFS)
> 
> 
> In Section 1, it says:
> 
>   Multi-domain deployments require support for global identities in
>   name services and security services, and file systems capable of the
>   on-disk representation of identities belonging to multiple NFSv4
>   domains.
> 
> I do not think that "global" is the right term here.  The identities
> clearly need to be unique across all of the NFSv4 domains involved, but
> this may not mean global uniqueness.
> 
> 
> In Section 4, please provide a pointers for AUTH_NONE, AUTH_SYS,
> and RPCSEC_GSS.
> 
> 
> In section 5.2, it says:
> 
>   The AUTH_NONE security flavor can be useful in a multi-domain
>   deployment to grant universal access to public data without any
>   credentials.
> 
> I assume this is read-only access.  If my assumption is correct,
> please expand this paragraph to cover this point.
> 
> 
> In Section 8, it says:
> 
>   ...  We don't
>   treat them fully here, but implementors should study the protocols in
>   question to get a more complete set of security considerations.
> 
> Does the first paragraph os Section 8 include all of the references
> that are relevant.  If so, then I do not understand the point of this
> sentence.  If not, then please expand the first paragraph of Section 8
> to cover all of the places that an implementer needs to look.
> 
> 
> Minor Concerns:
> 
> The first sentence of the introduction says:
> 
>   An NFSv4 domain is defined as a set of users and groups named by a
>   particular domain using the NFSv4 name@domain syntax.
> 
> Please define "domain" without using that word in the definition.
> 
> 
> In Section 8, it says:
> 
>   ... Even when not using labeled
>   security, since there could be many realms (credential issuer) for a
>   given server, it's important to verify that the server a client is
>   talking to has a credential for the name the client has for the
>   server, and that that credential's issuer (i.e., its realm) is
>   allowed to issue it.  
> 
> I cannot figure this out.  First, it has nothing to do with security
> labels, so it might deserve a paragraph of its own.  Second, maybe the
> point can be made more directly, perhaps something that begins: "When
> the server accepts user credential from more than one realm, then the
> server must verify that ... and ...".  Third, the points in the last
> paragraph of Section 8 should be made before this one.
> 
> 
> Nits:
> 
> Please pick one spelling and use it throughout the document:
>   - unix or UNIX
>   - uid or UID
>   - gid or GID
>   - AUTH_NONE or AUTH_NULL
> 
> 
> In Section 2, it says:
> 
>      Stringified UID or GID: NFSv4 owner and group strings that consist
>      of decimal numeric values with no leading zeros, and which do not
>      contain an '@' sign.  See Section 5.9 "Interpreting owner and
>      owner_group" [RFC5661].
> 
> Please reword the last sentence so that it is clear that this is a
> pointer to Section 5.9 of RFC 5661.
> 
>