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. > >
- Re: [secdir] SecDir Review of draft-ietf-nfsv4-mu… Adamson, Andy
- Re: [secdir] SecDir Review of draft-ietf-nfsv4-mu… Adamson, Andy
- Re: [secdir] SecDir Review of draft-ietf-nfsv4-mu… Adamson, Andy
- [secdir] SecDir Review of draft-ietf-nfsv4-multi-… Russ Housley