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.