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

["Adamson, Andy" <[e-mail]>]

Hello Russ

I just submitted draft-ietf-nfsv4-multi-domain-fs-reqs-09 which responds to your review comments on draft-08.

Thanks again for the helpful review.

—>Andy


> On Jun 28, 2016, at 9:48 AM, Adamson, Andy <[e-mail]> wrote:
> 
>> 
>> On Jun 24, 2016, at 12:30 PM, Russ Housley <[e-mail]> 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 issues are central as guidance or deployment alternatives are in reaction to the issues discussed.
> I can point that out.
> 
>> 
>> 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.
> 
> Agreed - the abstract is issues centric, I can change that.
> 
>> - The server must offer a multi-domain-capable file system
> 
> This is in the abstract. I can reword.
> 
>> and support
>>  RPCSEC_GSS for user authentication.
> 
> OK
> 
>> - The server must also support identity mapping.
> 
> No it doesn’t if the multi-domain capable file system stores name@domain. (none currently do……)
> 
>> 
>> 
>> 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
> 
> OK
> 
>> - Federated File System (FedFS)
> 
> FedFS is explained in the Introduction:
> 
>  The FedFS is the standardized method of constructing and
>   administrating an enterprise-wide NFSv4 filesystem, and so is
>   referenced in this document.  The issues with multi-domain
>   deployments described in this document apply to all multi-domain
>   deployments, whether they are run as a FedFS or not.
> 
> 
>> 
>> 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.
> 
> Well. Say you have identities that are unique across NFSv4 domain “A” and NFSv4 domain “B”, and these domains have support in the name services and security services.  Then NFSV4 domain ‘C’ joins the multi-domain namespace.  We then expect the multi-domain capable file system and the name/security services to support this new domain. This is why I chose “global”.
> 
> I can talk about this and tie it into the Name@domain Constraints section 5.1.
> 
>> 
>> 
>> In Section 4, please provide a pointers for AUTH_NONE, AUTH_SYS,
>> and RPCSEC_GSS.
> 
> OK
> 
>> 
>> 
>> 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.
> 
> Sure.
> 
>> 
>> 
>> 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.
> 
> I changed the first paragraph to include all relevant protocols, and did not remove the above sentence.
> Thanks for pointing this out.
> 
>> 
>> 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.
> 
> Yeah…
> 
>> 
>> 
>> 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.
> 
> this is confusing. I’ll re-write.
> 
>> 
>> 
>> 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.
> 
> will do
> 
> Thanks for the review
> 
> —>Andy