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

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

Hello Russ

Thanks for the review. I’ll respond soon.

—>Andy

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