NFSv4 Working Group                                           W. Adamson
Internet-Draft                                                    NetApp
Intended status: Standards Track                             N. Williams
Expires: March 2, 5, 2017                                      Cryptonector
                                                         August 29,
                                                       September 1, 2016

        Multiple NFSv4 Domain Namespace Deployment Requirements


   This document presents requirements on the deployment of the NFSv4
   protocols for the construction of an NFSv4 file name space in
   environments with multiple NFSv4 Domains.  To participate in an NFSv4
   multi-domain file name space, 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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 2, 5, 2017.

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Federated File System . . . . . . . . . . . . . . . . . . . .   5
   4.  Identity Mapping  . . . . . . . . . . . . . . . . . . . . . .   5
   4.1.  NFSv4 Server Identity Mapping . . . . . . . . . . . . . . .   5
   4.2.  NFSv4 Client Identity Mapping . . . . . . . . . . . . . . .   6
   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   8
   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. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   11.1.  Normative References . . . . . . . . . . . . . . . . . . .  14
   11.2.  Informative References . . . . . . . . . . . . . . . . . .  15
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], NFSv4.2
   [I-D.NFSv4.2] 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 ONCRPC [RFC5531] authsys_parms AUTH_SYS credential.
   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 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 identity syntax can provide unique identities and so enables
   the NFSv4 multi-domain file name space.

   Unlike previous versions of NFS, the NFSv4 protocols define a
   referral mechanism (Section 8.4.3 [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 name space.

   The NFSv4 protocols name@domain identity syntax and referral mechanism along
   with the use of RPCSEC_GSS security mechanisms enables the
   construction of an NFSv4 multi-domain file name space.

   This document presents requirements on the deployment of the NFSv4
   protocols for the construction of an NFSv4 file name space in
   environments with multiple NFSv4 Domains.  To participate in an NFSv4
   multi-domain file name space, 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.

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 name space in an environment with a single NFSv4

      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
      API's.  Examples are numeric id's such as a uidNumber (UID),
      gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID)
      [CIFS].  In some case 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 name space that can be mapped to a
      local representation.  For example, the NFSv4 name@domain or the
      Kerberos principal@REALM [RFC4121].

      Multi-domain: In this document, the term "multi-domain" always
      refers to multiple NFSv4 Domains.

      Multi-domain capable filesystem: A local filesystem that uses a
      local ID form that can represent NFSv4 identities from multiple

      Principal: an RPCSEC_GSS [RFC2203] authentication identity.
      Usually, but not always, a user; rarely, if ever, a group;
      sometimes a host or server.

      Authorization Context: A collection of information about a
      principal such as username, userID, group membership, etcetera
      used in authorization decisions.

      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 of [RFC5661].

      Name Service: Facilities that provides 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 LDAP [RFC4511].

      Name Service Switch (nsswitch): a facility in provides a variety
      of sources for common configuration databases and name resolution

      FedFS: The Federated File System (FedFS) [RFC5716] describes the
      requirements and administrative tools to construct a uniform NFSv4
      file server based name space 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.  Definitions of "nfsv4 domain" and "multi-
      domain" have already appeared above in Section 1.  Below we
      provide other specific definitions used this document.

         DNS domain: a set of computers, services, or any Internet
         resource identified by an 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 name space 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

3.  Federated File System

   The FedFS is the standardized method of constructing and
   administrating an enterprise-wide NFSv4 filesystem, and so is
   referenced in this document.  The requirements for multi-domain
   deployments described in this document apply to all NFSv4 multi-
   domain deployments, whether they are run as a FedFS or not.

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

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

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

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 API's 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 API's
   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 a 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
   same and the auth-to-authz UID and GID authorization context
   information is provided in the RPC credential.

   Meta-data 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

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.

   Meta-data 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 no issue in a stand-alone NFSv4
   domain deployment as the NFSv4 Domain is known to the NFSv4 server
   and can 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 GSS-API [RFC2743] security mechanisms to securely
   authenticate users to servers.  The most common mechanism is Kerberos

   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.

   Implementations must never blindly drop a Kerberos REALM name from a
   Kerberos principal name to obtain a POSIX username, but they may be
   configured to do so for specific REALMs.

   Meta-data 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 name space imposes slightly
   on the NFSv4 administration freedom.  Here we describe the required

6.1.  Name@domain Constraints

   NFSv4 uses a syntax of the form "name@domain" (see Section 5.9
   [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 name space.  See [RFC5661] section 5.9 "Interpreting
      owner and owner_group" for a discussion on NFSv4 Domain

   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 name space.  Section 5.9 [RFC5661] 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 above in Section 6.1, any choice of NFSv4 Domain
   name can work within a stand-alone NFSv4 Domain deployment whereas
   the NFSv4 Domain name is required to be unique across a multi-domain

   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 above in Section 6.1, each name@domain is unique across the
   multi-domain name space 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 "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 [RFC2203] GSS-API security mechanism used
   in a multi-domain name space 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.

   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 name space where all NFSv4 clients and servers share an [RFC2307]
   name service.  A shared name service is required because uidNumbers
   and gidNumbers are passed in the RPC credential; there is no
   negotiation of name space 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 above in Section 6.2, caveat 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

   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

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 noting 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 in Section 5.1 is not suitable for
   participation in an NFSv4 multi-domain deployment.

   The second example in described in Section 5.2 does use the
   name@domain identity syntax, but the use of AUTH_SYS prohibits its
   participation in an NFSv4 multi-domain deployment.

   The third example in Section 5.3 can participate in a multi-domain
   name space deployment if:

   o  The NFSv4 Domain name is unique across the name space.

   o  All exported file systems are multi-domain capable.

   o  A secure method is used to resolve remote NFSv4 Domain principals
      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 must 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.  E.g., 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 principals 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 any detail is beyond
   the scope of this document, some general methods are listed here.

   1.  A mechanism specific GSS-API authorization payload containing
       credential authorization data such as a "privilege attribute
       certificate" (PAC) [PAC] or a "principal authentication data"
       (PAD) [I-D.sorce-krbwg-general-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 its syntax is well

   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 principal's in the remote NFSv4 Domain.  In this case, the
       NFSv4 server makes a query to it's local NFSv4 Domain name
       service just as it does when servicing a local domain principal.
       While this requires detailed knowledge of the remote NFSv4
       Domains 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

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
   DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS
   Security Addendum [I-D.lever-fedfs-security-addendum] apply.

   Authentication and authorization across administrative domains
   presents 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 foreign domain's users' complete
      authorization context: only parts may be available to servers

   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 usernames whose authorization context can be evaluated using
   operating system interfaces that deal in usernames rather than
   principal names.

   Note that clients may also need to evaluate a server's authorization
   context when using labeled security [I-D.NFSv4.2] (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 credential 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 that 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.  IANA Considerations

   There are no IANA considerations in this document.

11.  References

11.1.  Normative References

              Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
              nfsv4-minorversion2-36 (Work In Progress), April 2015.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
              Version 3 Protocol Specification", RFC 1813, DOI 10.17487/
              RFC1813, June 1995,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,

   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, DOI 10.17487/RFC2203, September
              1997, <>.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, DOI 10.17487/
              RFC2743, January 2000,

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

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/
              RFC4511, June 2006,

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

   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File System
              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
              March 2015, <>.

11.2.  Informative References

   [CIFS]     Microsoft Corporation, "[MS-CIFS] -- v20130118 Common
              Internet File System (CIFS) Protocol", January 2013.

              Lever, C., "Federated Filesystem Security Addendum",
              draft-cel-nfsv4-federated-fs-security-addendum-05 (Active
              Internet Draft), May 2016.

              Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for
              Kerberos V5", draft-ietf-krb-wg-general-pac-01 (Work In
              Progress awaiting merge with other document ), June 2011.

   [PAC]      Brezak, J., "Utilizing the Windows 2000 Authorization Data
              in Kerberos Tickets for Access Control to Resources",
              October 2002.

   [RFC2307]  Howard, L., "An Approach for Using LDAP as a Network
              Information Service", RFC 2307, DOI 10.17487/RFC2307,
              March 1998, <>.

   [RFC2624]  Shepler, S., "NFS Version 4 Design Considerations", RFC
              2624, DOI 10.17487/RFC2624, June 1999,

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
              May 2009, <>.

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

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

   [RFC7533]  Lentini, J., Tewari, R., and C. Lever, Ed.,
              "Administration Protocol for Federated File Systems", RFC
              7533, DOI 10.17487/RFC7533, March 2015,

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


   Nicolas Williams