draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-10.txt 
NFSv4 Working Group W. Adamson NFSv4 Working Group W. Adamson
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: December 31, 2016 Cryptonector Expires: March 2, 2017 Cryptonector
June 29, 2016 August 29, 2016
Multiple NFSv4 Domain Namespace Deployment Guidelines Multiple NFSv4 Domain Namespace Deployment Requirements
draft-ietf-nfsv4-multi-domain-fs-reqs-09 draft-ietf-nfsv4-multi-domain-fs-reqs-10
Abstract Abstract
This document provides guidance 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 name space in
environments with multiple NFSv4 Domains. To participate in an NFSv4 environments with multiple NFSv4 Domains. To participate in an NFSv4
mulit-domain file name space, the server must offer a mulit-domain multi-domain file name space, 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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2016. This Internet-Draft will expire on March 2, 2017.
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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 . . . . . . . 9 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. Resolving Multi-domain Authorization Information . . . . . . 11 7. Stand-alone Examples in an NFSv4 Multi-domain Deployment . . 11
8. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12 8. Resolving Multi-domain Authorization Information . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
skipping to change at page 3, line 9 skipping to change at page 3, line 9
name@domain user and group identification syntax with the same name@domain user 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 ONCRPC [RFC5531] authsys_parms AUTH_SYS credential.
Section 6.1 of [RFC2624] notes that the use of UNIX-centric numeric 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 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 numeric IDs are not unique across NFSv3 deployments and so are not
designed for internet scaling achieved by taking into account designed for Internet scaling achieved by taking into account
multiple naming domains and multiple naming mechanisms (see multiple naming domains and multiple naming mechanisms (see
Section 6.2). The NFSv4 Domain's use of the name@domain syntax Section 6.2). The NFSv4 Domain's use of the name@domain syntax
provides this internet scaling by allowing servers and clients to provides this Internet scaling by allowing servers and clients to
translate between the external name@domain string representation to a translate between the external name@domain string representation to a
local or internal numeric (or other identifier) representation which local or internal numeric (or other identifier) representation which
matches internal implementation needs. 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 identity syntax can provide unique identities and so The name@domain identity syntax can provide unique identities and so
enables the NFSv4 multi-domain file name space. enables the NFSv4 multi-domain file name space.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
referral mechanism (Section 8.4.3 [RFC7530]) that allows a single referral mechanism (Section 8.4.3 [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 name space.
The NFSv4 protocols name@domain identity syntax and referral The NFSv4 protocols name@domain identity syntax and referral
mechanism along with the use of RPCSEC_GSS security mechanisms mechanism along with the use of RPCSEC_GSS security mechanisms
enables the construction of an NFSv4 multi-domain file name space. enables the construction of an NFSv4 multi-domain file name space.
This document provides guidance 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 name space in
environments with multiple NFSv4 Domains. To participate in an NFSv4 environments with multiple NFSv4 Domains. To participate in an NFSv4
mulit-domain file name space, the server must offer a mulit-domain multi-domain file name space, 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.
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 user and group identification syntax with the same name@domain user and group identification syntax with the same
specified @domain. specified @domain.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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), API's. Examples are numeric id's 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 case 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 name space 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. Kerberos principal@REALM [RFC4121].
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 filesystem: A local filesystem 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.
Usually, but not always, a user; rarely, if ever, a group; Usually, but not always, a user; rarely, if ever, a group;
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 such as username, userID, group membership, etcetera principal such as username, userID, group membership, etcetera
used in authorization decisions. used in 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 which do not
contain an '@' sign. See Section 5.9 [RFC5661]. contain an '@' sign. See Section 5.9 of [RFC5661].
Name Service: Facilities that provides the mapping between {NFSv4 Name Service: Facilities that provides 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. Service such as LDAP [RFC4511].
Name Service Switch (nsswitch): a facility in provides a variety Name Service Switch (nsswitch): a facility in 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 name space 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. Definitions of "nfsv4 domain" and "multi-
domain" have already appeared above in Section 1. Below we domain" have already appeared above in Section 1. Below we
provide other specific definitions used this document. 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 an DNS domain name [RFC1034].
Security realm or domain: a set of configured security Security realm or domain: a set of configured security
providers, users, groups, security roles, and security policies providers, users, groups, security roles, and security policies
running a single security protocol and administered by a single running a single security protocol and administered by a single
entity, for example a Kerberos realm. entity, for example a Kerberos realm.
FedFS domain: A file name space that can cross multiple shares FedFS domain: A file name space that can cross multiple shares
on multiple file servers using file-access protocols such as on 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
skipping to change at page 5, line 35 skipping to change at page 5, line 35
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 filesystem, and so is
referenced in this document. The issues with 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 they are run as a FedFS or not.
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 configurations
some of these configurations (Section 5) are not compatible with some of these configurations (Section 5) are not compatible with
joining a multi-domain FedFS name space. joining a multi-domain FedFS name space.
4. Identity Mapping 4. Identity Mapping
skipping to change at page 6, line 17 skipping to change at page 6, line 17
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 example, if an authentication identity such as a Kerberos For example, if an authentication identity such as a Kerberos
principal is sent with authorization information such a "privilege principal is sent with authorization information such a "privilege
attribute certificate" (PAC) [PAC] then mapping is not required (see attribute certificate" (PAC) [PAC] then mapping is not required (see
Section 7). 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.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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 API's
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
In order to service as many environments as possible, the NFSv4 The purpose of this section is to list some typical stand-alone
protocol is designed to allow administrators freedom to configure deployment examples to highlight the need for the required restraints
their NFSv4 domains as they please. to the NFSv4 protocol, name service configuration, and security
service choices in an NFSv4 multi-domain environment described in
Section 6.
Stand-alone NFSv4 Domains can be run in many ways. Here we list some Section 7 notes how these stand-alone deployment examples would need
stand-alone NFSv4 Domain deployment examples focusing on the NFSv4 to change to participate in an NFSv4 multi-domain deployment.
server's use of name service mappings (Section 4.1) and security
services deployments to demonstrate the need for some multiple NFSv4
Domain constraints to the NFSv4 protocol, name service configuration,
and security service choices.
Typically, stand-alone NFSv4 Domain deployments only provide support In order to service as many environments as possible, the NFSv4
for identities belonging to a single NFSv4 Domain. Because all on- protocol is designed to allow administrators freedom to configure
disk identities participating in a stand-alone NFSv4 Domain belong to their NFSv4 domains as they please. Stand-alone NFSv4 Domains can be
the same NFSv4 Domain, stand-alone NFSv4 Domain deployments have no run in many ways.
requirement for exporting multi-domain capable file systems.
These examples are for a NFSv4 server exporting a POSIX UID/GID based These examples are for a NFSv4 server exporting a POSIX UID/GID based
file system, a typical deployment. These examples are listed in the file system, a typical deployment. These examples are listed in the
order of increasing NFSv4 administrative complexity. 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 [RFC1831] 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 Meta-data 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
skipping to change at page 10, line 45 skipping to change at page 10, line 45
to use.) Other flavors, such as AUTH_NONE, to use.) Other flavors, such as AUTH_NONE,
and AUTH_SYS, MAY be implemented as well. and AUTH_SYS, MAY be implemented as well.
The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used
in a multi-domain name space is REQUIRED to employ a method of cross 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 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 [RFC1831] 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 [RFC1831] 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 name space where all NFSv4 clients and servers share an [RFC2307]
name service. A shared name service is required because uidNumbers name service. A shared name service is required because uidNumbers
and gidNumbers are passed in the RPC credential; there is no and gidNumbers are passed in the RPC credential; there is no
negotiation of name space in AUTH_SYS. Collisions can occur if 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 multiple name services are used, so AUTH_SYS MUST NOT be used in a
skipping to change at page 11, line 26 skipping to change at page 11, line 26
As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4 As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4
Domain security services are RPCSEC_GSS based with the Kerberos 5 Domain security services are RPCSEC_GSS based with the Kerberos 5
security mechanism being the most commonly (and as of this writing, security mechanism being the most commonly (and as of this writing,
the only) deployed service. the only) 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 issue of mapping multiple Kerberos 5 principal@REALMs to the same the 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. Resolving Multi-domain Authorization Information 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 When an RPCSEC_GSS principal is seeking access to files on an NFSv4
server, after authenticating the principal, the server must obtain in server, after authenticating the principal, the server must obtain in
a secure manner the principal's authorization context information 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
skipping to change at page 12, line 41 skipping to change at page 13, line 25
context information presented to the NFSv4 server is in the same context information presented to the NFSv4 server is in the same
form as a query for a local principal. form as 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.
8. Stand-alone Examples and Multiple NFSv4 Domain Namespaces
Revisiting the stand-alone (Section 5) NFSv4 Domain deployment
examples, we note that due to the use of AUTH_SYS, neither
Section 5.1 nor Section 5.2 configurations are suitable for multi-
domain deployments.
The Section 5.3 configuration example 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.
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 DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS
Security Addendum [I-D.lever-fedfs-security-addendum] apply. Security Addendum [I-D.lever-fedfs-security-addendum] apply.
Authentication and authorization across administrative domains Authentication and authorization across administrative domains
skipping to change at page 13, line 42 skipping to change at page 14, line 9
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 7). 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 usernames whose authorization context can be evaluated using
operating system interfaces that deal in usernames rather than operating system interfaces that deal in usernames 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 [I-D.NFSv4.2] (e.g., is the
server authorized to handle content at a given security level, for server authorized to handle content at a given security level, for
the given client process subject label). the given client process subject label).
skipping to change at page 14, line 34 skipping to change at page 14, line 49
[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, DOI 10.17487/
RFC1813, June 1995, RFC1813, June 1995,
<http://www.rfc-editor.org/info/rfc1813>. <http://www.rfc-editor.org/info/rfc1813>.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, DOI 10.17487/RFC1831,
August 1995, <http://www.rfc-editor.org/info/rfc1831>.
[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, DOI 10.17487/
RFC2119, March 1997, 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
skipping to change at page 15, line 16 skipping to change at page 15, line 25
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, DOI
10.17487/RFC4121, July 2005, 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, DOI 10.17487/
RFC4511, June 2006, RFC4511, June 2006,
<http://www.rfc-editor.org/info/rfc4511>. <http://www.rfc-editor.org/info/rfc4511>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[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 11.2. Informative References
skipping to change at page 16, line 9 skipping to change at page 16, line 13
October 2002. October 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", RFC
2624, DOI 10.17487/RFC2624, June 1999, 2624, DOI 10.17487/RFC2624, June 1999,
<http://www.rfc-editor.org/info/rfc2624>. <http://www.rfc-editor.org/info/rfc2624>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [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", RFC
7532, DOI 10.17487/RFC7532, March 2015, 7532, DOI 10.17487/RFC7532, March 2015,
<http://www.rfc-editor.org/info/rfc7532>. <http://www.rfc-editor.org/info/rfc7532>.
 End of changes. 29 change blocks. 
64 lines changed or deleted 71 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/