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

From: Russ Housley <[email-masked]>
Date: Fri, 24 Jun 2016 12:30:32 -0400

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.

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 24 Jun 2016 21:22:18 +0000

Hello Russ

Thanks for the review. I’ll respond soon.

—>Andy

> On Jun 24, 2016, at 12:30 PM, Russ Housley <[email-masked]> wrote:
>

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 28 Jun 2016 13:48:19 +0000

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

>   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

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……)

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

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

OK

> please expand this paragraph to cover this point.

Sure.

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

> Please define "domain" without using that word in the definition.

Yeah…

> paragraph of Section 8 should be made before this one.

this is confusing. I’ll re-write.

> pointer to Section 5.9 of RFC 5661.

will do

Thanks for the review

—>Andy

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 29 Jun 2016 16:51:22 +0000

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 <[email-masked]> wrote:
> 
>>