doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc8000.txt b/doc/rfc/rfc8000.txt
new file mode 100644
index 0000000..0317385
--- /dev/null
+++ b/doc/rfc/rfc8000.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        W. Adamson
+Request for Comments: 8000                                        NetApp
+Category: Standards Track                                    N. Williams
+ISSN: 2070-1721                                             Cryptonector
+                                                           November 2016
+
+
+        Requirements for NFSv4 Multi-Domain Namespace Deployment
+
+Abstract
+
+   This document presents requirements for the deployment of the NFSv4
+   protocols for the construction of an NFSv4 file namespace in
+   environments with multiple NFSv4 Domains.  To participate in an NFSv4
+   multi-domain file namespace, the server must offer a multi-domain-
+   capable file system and support RPCSEC_GSS for user authentication.
+   In most instances, the server must also support identity-mapping
+   services.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8000.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 1]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Federated File System . . . . . . . . . . . . . . . . . . . .   5
+   4.  Identity Mapping  . . . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  NFSv4 Server Identity Mapping . . . . . . . . . . . . . .   6
+     4.2.  NFSv4 Client Identity Mapping . . . . . . . . . . . . . .   7
+   5.  Stand-Alone NFSv4 Domain Deployment Examples  . . . . . . . .   7
+     5.1.  AUTH_SYS with Stringified UID/GID . . . . . . . . . . . .   7
+     5.2.  AUTH_SYS with Name@domain . . . . . . . . . . . . . . . .   8
+     5.3.  RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . .   8
+   6.  Multi-Domain Constraints to the NFSv4 Protocol  . . . . . . .   9
+     6.1.  Name@domain Constraints . . . . . . . . . . . . . . . . .   9
+       6.1.1.  NFSv4 Domain and DNS Services . . . . . . . . . . . .   9
+       6.1.2.  NFSv4 Domain and Name Services  . . . . . . . . . . .  10
+     6.2.  RPC Security Constraints  . . . . . . . . . . . . . . . .  10
+       6.2.1.  NFSv4 Domain and Security Services  . . . . . . . . .  11
+   7.  Stand-Alone Examples in an NFSv4 Multi-Domain Deployment  . .  11
+   8.  Resolving Multi-Domain Authorization Information  . . . . . .  12
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
+
+1.  Introduction
+
+   The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and NFSv4.2
+   [RFC7862] introduce the concept of an NFS Domain.  An NFSv4 Domain is
+   defined as a set of users and groups using the NFSv4 name@domain user
+   and group identification syntax with the same specified @domain.
+
+   Previous versions of the NFS protocol, such as NFSv3 [RFC1813], use
+   the UNIX-centric user identification mechanism of numeric user and
+   group ID for the uid3 and gid3 [RFC1813] file attributes and for
+   identity in the authsys_parms AUTH_SYS credential defined in the Open
+   Network Computing (ONC) Remote Procedure Call (RPC) protocol
+   [RFC5531].  Section 6.1 of [RFC2624] notes that the use of UNIX-
+   centric numeric IDs limits the scale of NFS to large local work
+   groups.  UNIX-centric numeric IDs are not unique across NFSv3
+   deployments and so are not designed for Internet scaling achieved by
+   taking into account multiple naming domains and multiple naming
+   mechanisms (see Section 6.2).  The NFSv4 Domain's use of the
+   name@domain syntax provides this Internet scaling by allowing servers
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 2]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   and clients to translate between the external name@domain string
+   representation to a local or internal numeric (or other identifier)
+   representation, which matches internal implementation needs.
+
+   Multi-domain deployments require support for unique identities across
+   the deployment's name services and security services, as well as the
+   use of multi-domain file systems capable of the on-disk
+   representation of identities belonging to multiple NFSv4 Domains.
+   The name@domain syntax can provide unique identities and thus enables
+   the NFSv4 multi-domain file namespace.
+
+   Unlike previous versions of NFS, the NFSv4 protocols define a
+   referral mechanism (Section 8.4.3 of [RFC7530]) that allows a single
+   server or a set of servers to present a multi-server namespace that
+   encompasses file systems located on multiple servers.  This enables
+   the establishment of site-wide, organization-wide, or even a truly
+   global file namespace.
+
+   The NFSv4 protocols' name@domain syntax and referral mechanism along
+   with the use of RPCSEC_GSS security mechanisms enables the
+   construction of an NFSv4 multi-domain file namespace.
+
+   This document presents requirements on the deployment of the NFSv4
+   protocols for the construction of an NFSv4 file namespace in
+   environments with multiple NFSv4 Domains.  To participate in an NFSv4
+   multi-domain file namespace, the server must offer a multi-domain-
+   capable file system and support RPCSEC_GSS [RFC2203] for user
+   authentication.  In most instances, the server must also support
+   identity-mapping services.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Terminology
+
+   NFSv4 Domain:  A set of users and groups using the NFSv4 name@domain
+      user and group identification syntax with the same specified
+      @domain.
+
+   Stand-alone NFSv4 Domain:  A deployment of the NFSv4 protocols and
+      NFSv4 file namespace in an environment with a single NFSv4 Domain.
+
+
+
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 3]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   Local representation of identity:  A representation of a user or a
+      group of users capable of being stored persistently within a file
+      system.  Typically, such representations are identical to the form
+      in which users and groups are represented within internal server
+      APIs.  Examples are numeric IDs such as a uidNumber (UID),
+      gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID)
+      [CIFS].  In some cases, the identifier space for user and groups
+      overlap, requiring anyone using such an ID to know a priori
+      whether the identifier is for a user or a group.
+
+   Unique identity:  An on-the-wire form of identity that is unique
+      across an NFSv4 multi-domain namespace that can be mapped to a
+      local representation.  For example, the NFSv4 name@domain or the
+      Kerberos principal [RFC4120].
+
+   Multi-domain:  In this document, the term "multi-domain" always
+      refers to multiple NFSv4 Domains.
+
+   Multi-domain-capable file system:  A local file system that uses a
+      local ID form that can represent NFSv4 identities from multiple
+      domains.
+
+   Principal:  An RPCSEC_GSS [RFC2203] authentication identity.  It is
+      usually, but not always, a user; rarely, if ever, a group; and
+      sometimes a host or server.
+
+   Authorization Context:  A collection of information about a principal
+      such as user name, userID, group membership, etc., used in
+      authorization decisions.
+
+   Stringified UID or GID:  NFSv4 owner and group strings that consist
+      of decimal numeric values with no leading zeros and that do not
+      contain an '@' sign.  See Section 5.9 of [RFC5661].
+
+   Name Service:  Facilities that provide the mapping between {NFSv4
+      Domain, group, or user name} and the appropriate local
+      representation of identity.  Also includes facilities providing
+      mapping between a security principal and local representation of
+      identity.  Can be applied to unique identities or principals from
+      within local and remote domains.  Often provided by a Directory
+      Service such as the Lightweight Directory Access Protocol (LDAP)
+      [RFC4511].
+
+   Name Service Switch (nsswitch):  A facility that provides a variety
+      of sources for common configuration databases and name resolution
+      mechanisms.
+
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 4]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   FedFS:  The Federated File System (FedFS) [RFC5716] describes the
+      requirements and administrative tools to construct a uniform NFSv4
+      file-server-based namespace that is capable of spanning a whole
+      enterprise and that is easy to manage.
+
+   Domain:  This term is used in multiple contexts where it has
+      different meanings.  "NFSv4 Domain" and "multi-domain" are defined
+      above.
+
+      DNS domain:  A set of computers, services, or any Internet
+         resource identified by a DNS domain name [RFC1034].
+
+      Security realm or domain:  A set of configured security providers,
+         users, groups, security roles, and security policies running a
+         single security protocol and administered by a single entity,
+         for example, a Kerberos realm.
+
+      FedFS domain:  A file namespace that can cross multiple shares on
+         multiple file servers using file-access protocols such as
+         NFSv4.  A FedFS domain is typically a single administrative
+         entity and has a name that is similar to a DNS domain name.
+         Also known as a "Federation".
+
+      Administrative domain:  A set of users, groups, computers, and
+         services administered by a single entity.  Can include multiple
+         DNS domains, NFSv4 Domains, security domains, and FedFS
+         domains.
+
+3.  Federated File System
+
+   The FedFS is the standardized method of constructing and
+   administrating an enterprise-wide NFSv4 file system and is thus
+   referenced in this document.  The requirements for multi-domain
+   deployments described in this document apply to all NFSv4 multi-
+   domain deployments, whether or not they are run as a FedFS.
+
+   Stand-alone NFSv4 Domain deployments can be run in many ways.  While
+   a FedFS can be run within all stand-alone NFSv4 Domain
+   configurations, some of these configurations (Section 5) are not
+   compatible with joining a multi-domain FedFS namespace.
+
+
+
+
+
+
+
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 5]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+4.  Identity Mapping
+
+4.1.  NFSv4 Server Identity Mapping
+
+   NFSv4 servers deal with two kinds of identities: authentication
+   identities (referred to here as "principals") and authorization
+   identities ("users" and "groups" of users).  NFSv4 supports multiple
+   authentication methods, each authenticating an "initiator principal"
+   (typically representing a user) to an "acceptor principal" (always
+   corresponding to the NFSv4 server).  NFSv4 does not prescribe how to
+   represent authorization identities on file systems.  All file access
+   decisions constitute "authorization" and are made by NFSv4 servers
+   using authorization context information and file metadata related to
+   authorization, such as a file's access control list (ACL).
+
+   NFSv4 servers may be required to perform two kinds of mappings
+   depending upon what authentication and authorization information is
+   sent on the wire and what is stored in the exported file system.  For
+   example, if an authentication identity such as a Kerberos principal
+   is sent with authorization information such as a "privilege attribute
+   certificate" (PAC) [PAC], then mapping is not required (see
+   Section 8).
+
+   1.  Auth-to-authz: A mapping between the authentication identity and
+       the authorization context information.
+
+   2.  Wire-to-disk: A mapping between the on-the-wire authorization
+       identity representation and the on-disk authorization identity
+       representation.
+
+   A name service such as LDAP often provides these mappings.
+
+   Many aspects of these mappings are entirely implementation specific,
+   but some require multi-domain-capable name resolution and security
+   services in order to interoperate in a multi-domain environment.
+
+   NFSv4 servers use these mappings for:
+
+   1.  File access: Both the auth-to-authz and the wire-to-disk mappings
+       may be required for file access decisions.
+
+   2.  Metadata setting and listing: The auth-to-authz mapping is
+       usually required to service file metadata setting or listing
+       requests such as ACL or UNIX permission setting or listing.  This
+       mapping is needed because NFSv4 messages use identity
+       representations of the form name@domain, which normally differs
+       from the server's local representation of identity.
+
+
+
+
+Adamson & Williams           Standards Track                    [Page 6]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+4.2.  NFSv4 Client Identity Mapping
+
+   A client setting the owner or group attribute will often need access
+   to identity-mapping services.  This is because APIs within the client
+   will specify the identity in a local form (e.g., UNIX using a UID/
+   GID) so that when stringified id's cannot be used, the ID must be
+   converted to a unique identity form.
+
+   A client obtaining values for the owner or group attributes will
+   similarly need access to identity-mapping services.  This is because
+   the client API will need these attributes in a local form, as above.
+   As a result, name services need to be available to convert the unique
+   identity to a local form.
+
+   Note that each of these situations arises because client-side APIs
+   require a particular local identity representation.  The need for
+   mapping services would not arise if the clients could use the unique
+   representation of identity directly.
+
+5.  Stand-Alone NFSv4 Domain Deployment Examples
+
+   The purpose of this section is to list some typical stand-alone
+   deployment examples to highlight the need for the required restraints
+   to the NFSv4 protocol, name service configuration, and security
+   service choices in an NFSv4 multi-domain environment described in
+   Section 6.
+
+   Section 7 notes how these stand-alone deployment examples would need
+   to change to participate in an NFSv4 multi-domain deployment.
+
+   In order to service as many environments as possible, the NFSv4
+   protocol is designed to allow administrators freedom to configure
+   their NFSv4 Domains as they please.  Stand-alone NFSv4 Domains can be
+   run in many ways.
+
+   These examples are for an NFSv4 server exporting a POSIX UID/GID-
+   based file system, a typical deployment.  These examples are listed
+   in the order of increasing NFSv4 administrative complexity.
+
+5.1.  AUTH_SYS with Stringified UID/GID
+
+   This example is the closest NFSv4 gets to being run as NFSv3 as there
+   is no need for a name service for file metadata listing.
+
+   File access: The AUTH_SYS RPC credential [RFC5531] provides a UID as
+   the authentication identity, and a list of GIDs as authorization
+   context information.  File access decisions require no name service
+   interaction as the on-the-wire and on-disk representation are the
+
+
+
+Adamson & Williams           Standards Track                    [Page 7]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   same and the auth-to-authz UID and GID authorization context
+   information is provided in the RPC credential.
+
+   Metadata setting and listing: When the NFSv4 clients and servers
+   implement a stringified UID/GID scheme, where a stringified UID or
+   GID is used for the NFSv4 name@domain on-the-wire identity, then a
+   name service is not required for file metadata listing as the UID, or
+   GID can be constructed from the stringified form on the fly by the
+   server.
+
+5.2.  AUTH_SYS with Name@domain
+
+   Another possibility is to express identity using the form
+   'name@domain', rather than using a stringified UID/GID scheme for
+   file metadata setting and listing.
+
+   File access: This is the same as in Section 5.1.
+
+   Metadata setting and listing: The NFSv4 server will need to use a
+   name service for the wire-to-disk mappings to map between the on-the-
+   wire name@domain syntax and the on-disk UID/GID representation.
+   Often, the NFSv4 server will use the nsswitch interface for these
+   mappings.  A typical use of the nsswitch name service interface uses
+   no domain component, just the UID attribute [RFC2307] (or login name)
+   as the name component.  This is not an issue in a stand-alone NFSv4
+   Domain deployment as the NFSv4 Domain is known to the NFSv4 server
+   and can be combined with the login name to form the name@domain
+   syntax after the return of the name service call.
+
+5.3.  RPCSEC_GSS with Name@domain
+
+   RPCSEC_GSS uses Generic Security Service Application Program
+   Interface (GSS-API) [RFC2743] security mechanisms to securely
+   authenticate users to servers.  The most common mechanism is Kerberos
+   [RFC4121].
+
+   This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS
+   security mechanism.
+
+   File Access: The forms of GSS principal names are mechanism specific.
+   For Kerberos, these are of the form principal@REALM.  Sometimes
+   authorization context information is delivered with authentication,
+   but this cannot be counted on.  Authorization context information not
+   delivered with authentication has timely update considerations (i.e.,
+   generally it's not possible to get a timely update).  File access
+   decisions therefore require a wire-to-disk mapping of the GSS
+   principal to a UID and an auth-to-authz mapping to obtain the list of
+   GIDs as the authorization context.
+
+
+
+Adamson & Williams           Standards Track                    [Page 8]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   Metadata setting and listing: This is the same as in Section 5.2.
+
+6.  Multi-Domain Constraints to the NFSv4 Protocol
+
+   Joining NFSv4 Domains under a single file namespace imposes slightly
+   on the NFSv4 administrative freedom.  In this section, we describe
+   the required constraints.
+
+6.1.  Name@domain Constraints
+
+   NFSv4 uses a syntax of the form "name@domain" (see Section 5.9 of
+   [RFC7530]) as the on-the-wire representation of the "who" field of an
+   NFSv4 access control entry (ACE) for users and groups.  This design
+   provides a level of indirection that allows NFSv4 clients and servers
+   with different internal representations of authorization identity to
+   interoperate even when referring to authorization identities from
+   different NFSv4 Domains.
+
+   Multi-domain-capable sites need to meet the following requirements in
+   order to ensure that NFSv4 clients and servers can map between
+   name@domain and internal representations reliably.  While some of
+   these constraints are basic assumptions in NFSv4.0 [RFC7530] and
+   NFSv4.1 [RFC5661], they need to be clearly stated for the multi-
+   domain case.
+
+   o  The NFSv4 Domain portion of name@domain MUST be unique within the
+      multi-domain namespace.  See [RFC5661], Section 5.9 ("Interpreting
+      owner and owner_group") for a discussion on NFSv4 Domain
+      configuration.
+
+   o  The name portion of name@domain MUST be unique within the
+      specified NFSv4 Domain.
+
+   Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used
+   in a multi-domain deployment.  This means that multi-domain-capable
+   servers MUST reject requests that use stringified UID/GIDs.
+
+6.1.1.  NFSv4 Domain and DNS Services
+
+   Here we address the relationship between NFSv4 Domain name and DNS
+   domain name in a multi-domain deployment.
+
+   The definition of an NFSv4 Domain name, the @domain portion of the
+   name@domain syntax, needs clarification to work in a multi-domain
+   file system namespace.  [RFC5661], Section 5.9 loosely defines the
+   NFSv4 Domain name as a DNS domain name.  This loose definition for
+   the NFSv4 Domain name is a good one, as DNS domain names are globally
+   unique.  As noted in Section 6.1, any choice of NFSv4 Domain name can
+
+
+
+Adamson & Williams           Standards Track                    [Page 9]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   work within a stand-alone NFSv4 Domain deployment whereas the NFSv4
+   Domain name is required to be unique across a multi-domain
+   deployment.
+
+   A typical configuration is that there is a single NFSv4 Domain that
+   is served by a single DNS domain.  In this case, the NFSv4 Domain
+   name can be the same as the DNS domain name.
+
+   An NFSv4 Domain can span multiple DNS domains.  In this case, one of
+   the DNS domain names can be chosen as the NFSv4 Domain name.
+
+   Multiple NFSv4 Domains can also share a DNS domain.  In this case,
+   only one of the NFSv4 Domains can use the DNS domain name, the other
+   NFSv4 Domains must choose another unique NFSv4 Domain name.
+
+6.1.2.  NFSv4 Domain and Name Services
+
+   As noted in Section 6.1, each name@domain is unique across the multi-
+   domain namespace and maps, on each NFSv4 server, to the local
+   representation of identity used by that server.  Typically, this
+   representation consists of an indication of the particular domain
+   combined with the UID/GID corresponding to the name component.  To
+   support such an arrangement, each NFSv4 Domain needs to have a single
+   name resolution service capable of converting the names defined
+   within the domain to the corresponding local representation.
+
+6.2.  RPC Security Constraints
+
+   As described in [RFC5661], Section 2.2.1.1 ("RPC Security Flavors"):
+
+      NFSv4.1 clients and servers MUST implement RPCSEC_GSS.  (This
+      requirement to implement is not a requirement to use.)  Other
+      flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as
+      well.
+
+   The underlying RPCSEC_GSS GSS-API [RFC2203] security mechanism used
+   in a multi-domain namespace is REQUIRED to employ a method of cross
+   NFSv4 Domain trust so that a principal from a security service in one
+   NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a
+   security service with the same security mechanism.  Kerberos is an
+   example of such a security service.
+
+   The AUTH_NONE [RFC5531] security flavor can be useful in a multi-
+   domain deployment to grant universal read-only access to public data
+   without any credentials.
+
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 10]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   The AUTH_SYS security flavor [RFC5531] uses a host-based
+   authentication model where the weakly authenticated host (the NFSv4
+   client) asserts the user's authorization identities using small
+   integers, uidNumber, and gidNumber [RFC2307] as user and group
+   identity representations.  Because this authorization ID
+   representation has no domain component, AUTH_SYS can only be used in
+   a namespace where all NFSv4 clients and servers share a name service
+   as described in [RFC2307].  A shared name service is required because
+   uidNumbers and gidNumbers are passed in the RPC credential; there is
+   no negotiation of namespace in AUTH_SYS.  Collisions can occur if
+   multiple name services are used, so AUTH_SYS MUST NOT be used in a
+   multi-domain file system deployment.
+
+6.2.1.  NFSv4 Domain and Security Services
+
+   As noted in Section 6.2 regarding AUTH_NONE, multiple NFSv4 Domain
+   security services are RPCSEC_GSS based with the Kerberos 5 security
+   mechanism being the most commonly (and as of this writing, the only)
+   deployed service.
+
+   A single Kerberos 5 security service per NFSv4 Domain with the upper
+   case NFSv4 Domain name as the Kerberos 5 REALM name is a common
+   deployment.
+
+   Multiple security services per NFSv4 Domain is allowed and brings the
+   need of mapping multiple Kerberos 5 principal@REALMs to the same
+   local ID.  Methods of achieving this are beyond the scope of this
+   document.
+
+7.  Stand-Alone Examples in an NFSv4 Multi-Domain Deployment
+
+   In this section, we revisit the stand-alone NFSv4 Domain deployment
+   examples in Section 5 and note what is prohibiting them from
+   participating in an NFSv4 multi-domain deployment.
+
+   Note that because all on-disk identities participating in a stand-
+   alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4
+   Domain deployments have no requirement for exporting multi-domain-
+   capable file systems.  To participate in an NFSv4 multi-domain
+   deployment, all three examples in Section 5 would need to export
+   multi-domain-capable file systems.
+
+   Due to the use of AUTH_SYS and stringified UID/GIDs, the first stand-
+   alone deployment example (described in Section 5.1) is not suitable
+   for participation in an NFSv4 multi-domain deployment.
+
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 11]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   The second example (described in Section 5.2) does use the
+   name@domain syntax, but the use of AUTH_SYS prohibits its
+   participation in an NFSv4 multi-domain deployment.
+
+   The third example (described in Section 5.3) can participate in a
+   multi-domain namespace deployment if:
+
+   o  The NFSv4 Domain name is unique across the namespace.
+
+   o  All exported file systems are multi-domain capable.
+
+   o  A secure method is used to resolve the remote NFSv4 Domain
+      principal's authorization information from an authoritative
+      source.
+
+8.  Resolving Multi-Domain Authorization Information
+
+   When an RPCSEC_GSS principal is seeking access to files on an NFSv4
+   server, after authenticating the principal, the server SHOULD obtain
+   in a secure manner the principal's authorization context information
+   from an authoritative source such as the name service in the
+   principal's NFSv4 Domain.
+
+   In the stand-alone NFSv4 Domain case where the principal is seeking
+   access to files on an NFSv4 server in the principal's home NFSv4
+   Domain, the server administrator has knowledge of the local policies
+   and methods for obtaining the principal's authorization information
+   and the mappings to local representation of identity from an
+   authoritative source.  For example, the administrator can configure
+   secure access to the local NFSv4 Domain name service.
+
+   In the multi-domain case where a principal is seeking access to files
+   on an NFSv4 server not in the principal's home NFSv4 Domain, the
+   NFSv4 server may be required to contact the remote name service in
+   the principal's NFSv4 Domain.  In this case, there is no assumption
+   of:
+
+   o  Remote name service configuration knowledge.
+
+   o  The syntax of the remote authorization context information
+      presented to the NFSv4 server by the remote name service for
+      mapping to a local representation.
+
+   There are several methods the NFSv4 server can use to obtain the
+   NFSv4 Domain authoritative authorization information for a remote
+   principal from an authoritative source.  While detailing these
+   methods is beyond the scope of this document, some general methods
+   are listed here.
+
+
+
+Adamson & Williams           Standards Track                   [Page 12]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   1.  A mechanism-specific GSS-API authorization payload containing
+       credential authorization data such as a "privilege attribute
+       certificate" (PAC) [PAC] or a "principal authorization data"
+       (PAD) [GEN-PAC].  This is the preferred method as the payload is
+       delivered as part of GSS-API authentication, avoids requiring any
+       knowledge of the remote authoritative service configuration, and
+       has a well-known syntax.
+
+   2.  When there is a security agreement between the local and remote
+       NFSv4 Domain name services plus regular update data feeds, the
+       NFSv4 server local NFSv4 Domain name service can be authoritative
+       for principals in the remote NFSv4 Domain.  In this case, the
+       NFSv4 server makes a query to its local NFSv4 Domain name service
+       just as it does when servicing a local domain principal.  While
+       this requires detailed knowledge of the remote NFSv4 Domain name
+       service for the update data feeds, the authorization context
+       information presented to the NFSv4 server is in the same form as
+       a query for a local principal.
+
+   3.  An authenticated direct query from the NFSv4 server to the
+       principal's NFSv4 Domain authoritative name service.  This
+       requires the NFSv4 server to have detailed knowledge of the
+       remote NFSv4 Domain's authoritative name service and detailed
+       knowledge of the syntax of the resultant authorization context
+       information.
+
+9.  Security Considerations
+
+   This RFC discusses security throughout.  All the security
+   considerations of the relevant protocols, such as NFSv4.0 [RFC7530],
+   NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP
+   [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace
+   Database Protocol [RFC7532], FedFS Administration Protocol [RFC7533],
+   and FedFS Security Addendum [SEC-ADD] apply.
+
+   Authentication and authorization across administrative domains
+   present security considerations, most of which are treated elsewhere,
+   but we repeat some of them here:
+
+   o  latency in propagation of revocation of authentication credentials
+
+   o  latency in propagation of revocation of authorizations
+
+   o  latency in propagation of granting of authorizations
+
+   o  complications in establishing a complete authorization context for
+      users of a foreign domain (only parts may be available to servers)
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 13]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   o  privacy considerations in a federated environment
+
+   Most of these are security considerations of the mechanisms used to
+   authenticate users to servers and servers to users and of the
+   mechanisms used to evaluate a user's authorization context.
+
+   Implementors may be tempted to assume that "realm" (or "issuer") and
+   "NFSv4 Domain" are roughly the same thing, but they are not.
+   Configuration and/or lookup protocols (such as LDAP) and associated
+   schemas are generally required in order to evaluate a user
+   principal's authorization context (see Section 8).  In the simplest
+   scheme, a server has access to a database mapping all known principal
+   names to user names whose authorization context can be evaluated
+   using operating system interfaces that deal in user names rather than
+   principal names.
+
+   Note that clients may also need to evaluate a server's authorization
+   context when using labeled security [RFC7862] (e.g., is the server
+   authorized to handle content at a given security level for the given
+   client process subject label).
+
+   When the server accepts user credentials from more than one realm, it
+   is important to remember that the server must verify that the client
+   it is talking to has a credential for the name the client has
+   presented the server and that the credential's issuer (i.e., its
+   realm) is allowed to issue it.  Usually, the service principal realm
+   authorization function is implemented by the security mechanism, but
+   the implementor should check this.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <http://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
+              Version 3 Protocol Specification", RFC 1813,
+              DOI 10.17487/RFC1813, June 1995,
+              <http://www.rfc-editor.org/info/rfc1813>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 14]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
+              Specification", RFC 2203, DOI 10.17487/RFC2203, September
+              1997, <http://www.rfc-editor.org/info/rfc2203>.
+
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743,
+              DOI 10.17487/RFC2743, January 2000,
+              <http://www.rfc-editor.org/info/rfc2743>.
+
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              DOI 10.17487/RFC4121, July 2005,
+              <http://www.rfc-editor.org/info/rfc4121>.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511,
+              DOI 10.17487/RFC4511, June 2006,
+              <http://www.rfc-editor.org/info/rfc4511>.
+
+   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
+              "Network File System (NFS) Version 4 Minor Version 1
+              Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
+              <http://www.rfc-editor.org/info/rfc5661>.
+
+   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File System
+              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
+              March 2015, <http://www.rfc-editor.org/info/rfc7530>.
+
+   [RFC7862]  Haynes, T., "Network File System (NFS) Version 4 Minor
+              Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
+              November 2016, <http://www.rfc-editor.org/info/rfc7862>.
+
+10.2.  Informative References
+
+   [CIFS]     Microsoft Corporation, "[MS-CIFS]: Common Internet File
+              System (CIFS) Protocol", MS-CIFS v20160714 (Rev 26.0),
+              July 2016.
+
+   [GEN-PAC]  Sorce, S., Ed., Yu, T., Ed., and T. Hardjono, Ed., "A
+              Generalized PAC for Kerberos V5", Work in Progress,
+              draft-ietf-krb-wg-general-pac-01, October 2011.
+
+   [PAC]      Brezak, J., "Utilizing the Windows 2000 Authorization Data
+              in Kerberos Tickets for Access Control to Resources",
+              February 2002.
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 15]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+   [RFC2307]  Howard, L., "An Approach for Using LDAP as a Network
+              Information Service", RFC 2307, DOI 10.17487/RFC2307,
+              March 1998, <http://www.rfc-editor.org/info/rfc2307>.
+
+   [RFC2624]  Shepler, S., "NFS Version 4 Design Considerations",
+              RFC 2624, DOI 10.17487/RFC2624, June 1999,
+              <http://www.rfc-editor.org/info/rfc2624>.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              DOI 10.17487/RFC4120, July 2005,
+              <http://www.rfc-editor.org/info/rfc4120>.
+
+   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
+              Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
+              May 2009, <http://www.rfc-editor.org/info/rfc5531>.
+
+   [RFC5716]  Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
+              Naik, "Requirements for Federated File Systems", RFC 5716,
+              DOI 10.17487/RFC5716, January 2010,
+              <http://www.rfc-editor.org/info/rfc5716>.
+
+   [RFC7532]  Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace
+              Database (NSDB) Protocol for Federated File Systems",
+              RFC 7532, DOI 10.17487/RFC7532, March 2015,
+              <http://www.rfc-editor.org/info/rfc7532>.
+
+   [RFC7533]  Lentini, J., Tewari, R., and C. Lever, Ed.,
+              "Administration Protocol for Federated File Systems",
+              RFC 7533, DOI 10.17487/RFC7533, March 2015,
+              <http://www.rfc-editor.org/info/rfc7533>.
+
+   [SEC-ADD]  Lever, C., "Federated Filesystem Security Addendum", Work
+              in Progress, draft-cel-nfsv4-federated-fs-security-
+              addendum-06, October 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 16]
+
+RFC 8000                   Multi NFSv4 Domain              November 2016
+
+
+Acknowledgments
+
+   Andy Adamson would like to thank NetApp, Inc., for its funding of his
+   time on this project.
+
+   We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and
+   David Noveck for their review.
+
+Authors' Addresses
+
+   William A. (Andy) Adamson
+   NetApp
+
+   Email: andros@netapp.com
+
+
+   Nicolas Williams
+   Cryptonector
+
+   Email: nico@cryptonector.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Adamson & Williams           Standards Track                   [Page 17]
+