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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/