draft-ietf-nfsv4-multi-domain-fs-reqs-03.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-04.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: February 8, 2016 Cryptonector Expires: February 15, 2016 Cryptonector
August 7, 2015 August 14, 2015
Multiple NFSv4 Domain Namespace Deployment Guidelines Multiple NFSv4 Domain Namespace Deployment Guidelines
draft-ietf-nfsv4-multi-domain-fs-reqs-03 draft-ietf-nfsv4-multi-domain-fs-reqs-04
Abstract Abstract
This document describes administrative constraints to the deployment This document discusses issues relevant to the deployment of the
of the NFSv4 protocols required for the construction of an NFSv4 file NFSv4 protocols in situations allowing for the construction of an
system namespace supporting the use of multiple NFSv4 domains and NFSv4 file namespace supporting the use of multiple NFSv4 domains and
utilizing multi-domain capable file systems. Also described are utilizing multi-domain capable file systems. Also described are
administrative constraints to name resolution and security services constraints on name resolution and security services appropriate to
appropriate to such a system. Such a namespace is a suitable way to the administration of such a system. Such a namespace is a suitable
enable a Federated File System supporting the use of multiple NFSv4 way to enable a Federated File System supporting the use of multiple
domains. NFSv4 domains.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 February 8, 2016. This Internet-Draft will expire on February 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 5 3. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5
4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5 3.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5
4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6 3.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6
4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6
4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 8
5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8
5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 8 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9
5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10
5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10
6. Resolving Multi-domain Authorization Information . . . . . . 10 6. Resolving Multi-domain Authorization Information . . . . . . 11
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 11 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
An NFSv4 domain is defined as a set of users, groups and computers An NFSv4 domain is defined as a set of users and groups named by a
running NFSv4 protocols (NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and particular domain using the NFSv4 name@domain syntax. This includes
NFSv4.2 [I-D.NFSv4.2] as of this writing) identified by an NFSv4 NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be
domain name. published. Often, a computer which acts as an NFSv4 client and
always acts on behalf of users belonging to a particular NFSv4 domain
is thought of a part of that NFSv4 domain. Similarly, a computer
acting as an NFSv4 server that is only aware of users within a
particular NFSv4 domain may be thought of as part of that NFSv4
domain.
In this document, the term "multi-domain" always refers to multiple
NFSv4 domains.
The Federated File System (FedFS) [RFC5716] describes the 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 namespace 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.
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 multiple NFSv4 domain referenced in this document. The issues with multi-domain
file systems described in this document apply to all multiple NFSv4 deployments described in this document apply to all multi-domain
domain file systems, be they run as a FedFS or not. deployments, whether they are run as a FedFS or not.
Stand-alone NFSv4 domains can be run in many ways. While a FedFS can Stand-alone NFSv4 domain deployments can be run in many ways. While
be run within all stand-alone NFSv4 domain configurations some of a FedFS can be run within all stand-alone NFSv4 domain configurations
these configurations (Section 4) are not compatible with joining a some of these configurations (Section 4) are not compatible with
multiple NFSv4 domain FedFS namespace. joining a multi-domain FedFS namespace.
Multi NFSv4 domain file systems require support for global identities Multi-domain deployments require support for global identities in
in name services, security services, and in the exporting of on-disk name services and security services, and file systems capable of the
local identity representation. Many of the stand-alone NFSv4 domain on-disk representation of identities belonging to multiple NFSv4
deployments do not provide full support for global identities. domains. Typically, stand-alone NFSv4 domain deployments only
provide support for identities belonging to a single NFSv4 domain.
This document describes administrative constraints to the deployment This document describes administration-related constraints applying
of the NFSv4 protocols required for the construction of an NFSv4 file to the deployment of the NFSv4 protocols in environments supporting
system namespace supporting the use of multiple NFSv4 domains and the construction of an NFSv4 file system namespace supporting the use
utilizing multi-domain capable file systems. Also described are of multiple NFSv4 domains and utilizing multi-domain capable file
administrative constraints to name resolution and security services systems. Also described are constraints regarding the name
appropriate to such a system. Such a namespace is a suitable way to resolution and security services appropriate to such a deployment.
enable a Federated File System supporting the use of multiple NFSv4 Such a namespace is a suitable way to enable a Federated File System
domains. supporting the use of multiple NFSv4 domains.
2. Terminology 2. Terminology
Name Service: provides the mapping between {NFSv4 domain, group or Name Service: Facilities that provides the mapping between {NFSv4
user name} and {NFSv4 domain, local ID}, as well as the mapping domain, group or user name} and the appropriate local
between {security principal} and {NFSv4 domain, local ID} via representation of identity. Also includes facilities providing
lookups. Can be applied to local or remote domains. Often mapping between a security principal and local representation of
provided by a Directory Service such as LDAP. identity. Can be applied to global identities or principals from
within local and remote domains. Often provided by a Directory
Service such as LDAP.
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.
Domain: This term is used in multiple contexts where it has Domain: This term is used in multiple contexts where it has
different meanings. Here we provide specific definitions used in different meanings. Definitions of "nfsv4 domain" and "multi-
this document. domain" have already appeared above in Section 1. Below we
provide other specific definitions used this document.
DNS domain: a set of computers, services, or any internet 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.
NFSv4 domain: a set of users, groups, and computers running
NFSv4 protocols identified by a unique NFSv4 domain name. See
[RFC5661] Section 5.9 "Interpreting owner and owner_group".
Multi-domain: In this document this always refers to multiple
NFSv4 domains.
FedFS domain: A file namespace that can cross multiple shares FedFS domain: A file namespace 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
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.
Local representation of identity: an object such as a uidNumber Local representation of identity: A representation of a user or a
(UID) or gidNumber (GID) [RFC2307], a Windows Security Identifier group of users capable of being stored persistently within a file
(SID) [CIFS], or other such representation of a user or a group of system. Typically such representations are identical to the form
users on-disk in a file system. in which users and groups are represented within internal server
API's. Examples are numeric id's such as a a uidNumber (UID) or
gidNumber (GID) [RFC2307], a Windows Security Identifier (SID)
[CIFS]. In some case the identifier space for user and groups
overlap, requiring the one using such an id to know a priori
whether the identifier is for a user or a group.
Global identity: An on-the-wire globally unique form of identity Global identity: An on-the-wire globally unique form of identity
that can be mapped to a local representation. For example, the that can be mapped to a local representation. For example, the
NFSv4 name@domain or the Kerberos principal@REALM. NFSv4 name@domain or the Kerberos principal@REALM.
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 identities from both local and local ID form that can represent NFSv4 identities from multiple
remote domains. For example, an SSID based local ID form where domains.
the SSID contains both a domain and a user or group component.
Principal: an RPCSEC_GSS authentication identity. Usually, but Principal: an RPCSEC_GSS [RFC2203] authentication identity.
not always, a user; rarely, if ever, a group; sometimes a host or Usually, but not always, a user; rarely, if ever, a group;
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 "Interpreting owner and contain an '@' sign. See Section 5.9 "Interpreting owner and
owner_group" [RFC5661]. owner_group" [RFC5661].
3. NFSv4 Server Identity Mapping 3. Identity Mapping
3.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
skipping to change at page 5, line 31 skipping to change at page 5, line 46
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 multiple NFSv4 domain file services in order to interoperate in a multi-domain environment
system.
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. Meta-data 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) as requests such as ACL or unix permission setting or listing. This
NFSv4 uses the name@domain on-the-wire identity representation mapping is needed because NFSv4 messages use identity
which usually differs from the exported on-disk identity representations of the form name@domain which normally differs
representation. from the server's local representation of identity.
3.2. NFSv4 Client Identity Mapping
A client setting the owner or group attribute will often need access
to identity mapping services. This is because API's within the
client will specify the identity in a local form (e.g UNIX using a
uid/gid) so that when stringified id's cannot be used, the id must be
converted to a global form.
A client obtaining value for the owner or group attributes will
similarly need access to identity mapping services. This is because
the client API will need these attributes in a a local form, as
above. As a result name services need to be available to convert the
global identity to a local form.
Note that each of these situations arises because client-side API's
require a particular local identity representation. The need for
mapping services would not arise if the clients could use the global
representation of identity directly.
4. Stand-alone NFSv4 Domain Deployment Examples 4. Stand-alone NFSv4 Domain Deployment Examples
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. their NFSv4 domains as they please.
Stand-alone NFSv4 domains can be run in many ways. Here we list some Stand-alone NFSv4 domains can be run in many ways. Here we list some
stand-alone NFSv4 domain deployment examples focusing on the NFSv4 stand-alone NFSv4 domain deployment examples focusing on the NFSv4
server's use of name service mappings (Section 3) and security server's use of name service mappings (Section 3.1) and security
services deployment to demonstrate the need for some multiple NFSv4 services deployment to demonstrate the need for some multiple NFSv4
domain constraints to the NFSv4 protocol, name service configuration, domain constraints to the NFSv4 protocol, name service configuration,
and security service choices. and security service choices.
Because all on-disk identities participating in a stand-alone NFSv4 Because all on-disk identities participating in a stand-alone NFSv4
domain belong to the same NFSv4 domain, stand-alone NFSv4 domain domain belong to the same NFSv4 domain, stand-alone NFSv4 domain
deployments have no requirement for exporting multi-domain capable deployments have no requirement for exporting multi-domain capable
file systems. file systems.
Note that stringified identifiers, which are limited to 32 bit
unsigned quantities, cannot be validly used to set or interrogate
ACL's. This is because a given numeric value may represent the user
with that value as a uid and the group with that value as a gid. As
there is no way to resolve this ambiguity, aces cannot contain
stringified id's to represent a particular identity. This is opposed
to identities of the form name@domain, for which the mapping process
will determine both the associated local ID and indicate whether a
user or group is being designated.
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.
4.1. AUTH_SYS with Stringified UID/GID 4.1. AUTH_SYS with Stringified UID/GID
This example is the closest NFSv4 gets to being run as NFSv3. This example is the closest NFSv4 gets to being run as NFSv3.
File access: The AUTH_SYS RPC credential provides a UID as the File access: The AUTH_SYS RPC credential provides a UID as the
authentication identity, and a list of GIDs as authorization context authentication identity, and a list of GIDs as authorization context
skipping to change at page 6, line 41 skipping to change at page 7, line 34
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
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.
4.2. AUTH_SYS with name@domain 4.2. AUTH_SYS with name@domain
The next level of complexity is to not use a stringified UID/GID Another possibility is express identity using the form 'name@domain',
scheme for file metadata listing. rather than using use a stringified UID/GID scheme for file metadata
setting and listing.
File access: This is the same as in Section 4.1. File access: This is the same as in Section 4.1.
Meta-data setting and listing: The NFSv4 server will need to use a Meta-data setting and listing: The NFSv4 server will need to use a
name service for the wire-to-disk mappings to map between the on-the- 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 no 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 combined with the login name to form the name@domain syntax
after the return of the name service call. after the return of the name service call.
4.3. RPCSEC_GSS with name@domain 4.3. RPCSEC_GSS with name@domain
RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely RPCSEC_GSS uses 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 complexity of RPCSEC_GSS with the This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS
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 but this cannot be counted on. Authorization context information
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 GIDs as the authorization context. of GIDs as the authorization context.
skipping to change at page 7, line 41 skipping to change at page 8, line 38
Meta-data setting and listing: This is the same as in Section 4.2. Meta-data setting and listing: This is the same as in Section 4.2.
5. Multi-domain Constraints to the NFSv4 Protocol 5. Multi-domain Constraints to the NFSv4 Protocol
Joining NFSv4 domains under a single file namespace 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 administration freedom. Here we describe the required
constraints. constraints.
5.1. Name@domain Constraints 5.1. Name@domain Constraints
NFSv4 uses a syntax of the form "name@domain" as the on wire NFSv4 uses a syntax of the form "name@domain" as the on-the-wire
representation of the "who" field of an NFSv4 access control entry representation of the "who" field of an NFSv4 access control entry
(ACE) for users and groups. This design provides a level of (ACE) for users and groups. This design provides a level of
indirection that allows NFSv4 clients and servers with different indirection that allows NFSv4 clients and servers with different
internal representations of authorization identity to interoperate internal representations of authorization identity to interoperate
even when referring to authorization identities from different NFSv4 even when referring to authorization identities from different NFSv4
domains. domains.
Multiple NFSv4 domain capable sites need to meet the following Multi-domain capable sites need to meet the following requirements in
requirements in order to ensure that NFSv4 clients and servers can order to ensure that NFSv4 clients and servers can map between
map between name@domain and internal representations reliably. While name@domain and internal representations reliably. While some of
some of these constraints are basic assumptions in NFSv4.0 [RFC7530] these constraints are basic assumptions in NFSv4.0 [RFC7530] and
and NFSv4.1 [RFC5661], they need to be clearly stated for the NFSv4.1 [RFC5661], they need to be clearly stated for the multi-
multiple NFSv4 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
multiple NFSv4 domain namespace. See [RFC5661] section 5.9 multi-domain namespace. See [RFC5661] section 5.9 "Interpreting
"Interpreting owner and owner_group" for a discussion on NFSv4 owner and owner_group" for a discussion on NFSv4 domain
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 multiple NFSv4 domain file system. This means that multi- in a multi-domain deployment. This means that multi-domain-capable
domain-capable servers MUST reject requests that use stringified UID/ servers MUST reject requests that use stringified UID/GIDs.
GIDs.
5.1.1. NFSv4 Domain and DNS Services 5.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 multiple NFSv4 domain deployment. domain name in a multi-domain deployment.
The definition of an NFSv4 domain name needs clarification to work in The definition of an NFSv4 domain name needs clarification to work in
a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661] a multi-domain file system namespace. Section 5.9 [RFC5661] loosely
loosely defines the NFSv4 domain name as a DNS domain name. This defines the NFSv4 domain name as a DNS domain name. This loose
loose definition for the NFSv4 domain is a good one, as DNS domain definition for the NFSv4 domain is a good one, as DNS domain names
names are globally unique. As noted above in Section 5.1, any choice are globally unique. As noted above in Section 5.1, any choice of
of NFSv4 domain name can work within a stand-alone NFSv4 domain NFSv4 domain name can work within a stand-alone NFSv4 domain
deployment whereas the NFSv4 domain is required to be unique in a deployment whereas the NFSv4 domain is required to be unique in a
multiple NFSv4 domain deployment. multi-domain 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 name
can be the same as the DNS domain 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.
5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 5.1.2. NFSv4 Domain and Name Services
As noted above in Section 5.1, each name@domain is unique across the As noted above in Section 5.1, each name@domain is unique across the
multiple NFSv4 domain namespace, and maps to a local representation multi-domain namespace and maps, on each NFSv4 server, to the local
of ID in each NFSv4 domain. This means that each NFSv4 domain has a representation of identity used by that server. Typically, this
single name resolution service exporting the NFSv4 domain local ID representation consists of an indication of the particular domain
namespace. combined with the uid/gid corresponding to the name component. To
support such an arrangement, each NFSv4 domain needs to have a single
An NFSv4 domain administrator that wants to give NFSv4 local file name resolution service capable of converting the names defined
access to a remote user from a remote NFSv4 domain needs to create a within the domain to the corresponding uid/gid.
local ID for the remote user which can then be assigned on-disk and
used for local access decisions. Since the local ID for the remote
user must be able to be mapped to a name@remote-domain, only multi-
domain capable file systems can be exported in a multiple NFSv4
domain namespace.
We note that many file systems exported by NFSv4 use POSIX UID and
GIDs as a local ID form and as this local ID form has no domain
component, these file systems are not domain aware and can not easily
participate in a multiple NFSv4 domain namespace. There are ways to
overcome this deficiency, but these practices are beyond the scope of
this document.
5.2. RPC Security Constraints 5.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 requirement to implement is not a requirement (This requirement to implement is not a requirement
to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS,
MAY be implemented as well. MAY be implemented as well.
The underlying RPCSEC_GSS security mechanism used in a multiple NFSv4 The underlying RPCSEC_GSS security mechanism used in a multi-domain
domain namespace is REQUIRED to employ a method of cross NFSv4 domain namespace is REQUIRED to employ a method of cross NFSv4 domain trust
trust so that a principal from a security service in one NFSv4 domain so that a principal from a security service in one NFSv4 domain can
can be authenticated in another NFSv4 domain that uses a security be authenticated in another NFSv4 domain that uses a security service
service with the same security mechanism. Kerberos, and PKU2U with the same security mechanism. Kerberos, and PKU2U
[I-D.zhu-pku2u] are examples of such security services. [I-D.zhu-pku2u] are examples of such security services.
The AUTH_NONE security flavor can be useful in a multiple NFSv4 The AUTH_NONE security flavor can be useful in a multi-domain
domain namespace to grant universal access to public data without any deployment to grant universal access to public data without any
credentials. credentials.
The AUTH_SYS security flavor uses a host-based authentication model The AUTH_SYS security flavor uses a host-based authentication model
where the weakly authenticated host (the NFSv4 client) asserts the where the weakly authenticated host (the NFSv4 client) asserts the
user's authorization identities using small integers, uidNumber, and user's authorization identities using small integers, uidNumber, and
gidNumber [RFC2307], as user and group identity representations. gidNumber [RFC2307], as user and group identity representations.
Because this authorization ID representation has no domain component, Because this authorization ID representation has no domain component,
AUTH_SYS can only be used in a namespace where all NFSv4 clients and AUTH_SYS can only be used in a namespace where all NFSv4 clients and
servers share an [RFC2307] name service. A shared name service is servers share an [RFC2307] name service. A shared name service is
required because uidNumbers and gidNumbers are passed in the RPC required because uidNumbers and gidNumbers are passed in the RPC
skipping to change at page 10, line 4 skipping to change at page 10, line 34
The AUTH_SYS security flavor uses a host-based authentication model The AUTH_SYS security flavor uses a host-based authentication model
where the weakly authenticated host (the NFSv4 client) asserts the where the weakly authenticated host (the NFSv4 client) asserts the
user's authorization identities using small integers, uidNumber, and user's authorization identities using small integers, uidNumber, and
gidNumber [RFC2307], as user and group identity representations. gidNumber [RFC2307], as user and group identity representations.
Because this authorization ID representation has no domain component, Because this authorization ID representation has no domain component,
AUTH_SYS can only be used in a namespace where all NFSv4 clients and AUTH_SYS can only be used in a namespace where all NFSv4 clients and
servers share an [RFC2307] name service. A shared name service is servers share an [RFC2307] name service. A shared name service is
required because uidNumbers and gidNumbers are passed in the RPC required because uidNumbers and gidNumbers are passed in the RPC
credential; there is no negotiation of namespace in AUTH_SYS. credential; there is no negotiation of namespace in AUTH_SYS.
Collisions can occur if multiple name services are used, so AUTH_SYS Collisions can occur if multiple name services are used, so AUTH_SYS
MUST NOT be used in a multiple NFSv4 domain file system. MUST NOT be used in a multi-domain file system deployment.
While the AUTH_SYS security mechanism can not be used (indeed, While the AUTH_SYS security mechanism can not be used (indeed,
AUTH_SYS is obsolete and of limited use for all of NFS), RPCSEC_GSSv3 AUTH_SYS is obsolete and of limited use for all of NFS), RPCSEC_GSSv3
can completely replace all uses of AUTH_SYS in a multiple NFSv4 [I-D.rpcsec-gssv3] can completely replace all uses of AUTH_SYS in a
domain file system. Like AUTH_SYS, and unlike RPCSEC_GSSv1/2, multi-domain file system. Like AUTH_SYS, and unlike RPCSEC_GSSv1/2,
RPCSEC_GSSv3 allows the client to assert and contribute knowledge of RPCSEC_GSSv3 allows the client to assert and contribute knowledge of
the user process' authorization context. the user process' authorization context.
5.2.1. NFSv4 Domain and Security Services 5.2.1. NFSv4 Domain and Security Services
As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 As noted above in Section 5.2, caveat AUTH_NULL, 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.
skipping to change at page 10, line 47 skipping to change at page 11, line 30
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. E.g., the administrator can configure secure
access to the local NFSv4 domain name service. access to the local NFSv4 domain name service.
In the multiple NFSv4 domain case where a principal is seeking access In the multi-domain case where a principal is seeking access to files
to files on an NFSv4 server not in the principal's home NFSv4 domain, on an NFSv4 server not in the principal's home NFSv4 domain, the
the NFSv4 server may be required to contact the remote name service NFSv4 server may be required to contact the remote name service in
in the principals NFSv4 domain. In this case there is no assumption the principals NFSv4 domain. In this case there is no assumption of:
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 any detail is beyond
skipping to change at page 11, line 46 skipping to change at page 12, line 27
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.
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces
Revisiting the stand-alone (Section 4) NFSv4 domain deployment Revisiting the stand-alone (Section 4) NFSv4 domain deployment
examples, we note that due to the use of AUTH_SYS, neither examples, we note that due to the use of AUTH_SYS, neither
Section 4.1 nor Section 4.2 configurations are suitable for multiple Section 4.1 nor Section 4.2 configurations are suitable for multi-
NFSv4 domain deployments. domain deployments.
The Section 4.3 configuration example can participate in a multiple The Section 4.3 configuration example can participate in a multi-
NFSv4 domain namespace deployment if: domain namespace deployment if:
o The NFSv4 domain name is unique across the namespace. 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 remote NFSv4 domain principals
authorization information from an authoritative source. authorization information from an authoritative source.
8. Security Considerations 8. Security Considerations
skipping to change at page 12, line 39 skipping to change at page 13, line 20
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. We don't mechanisms used to evaluate a user's authorization context. We don't
treat them fully here, but implementors should study the protocols in treat them fully here, but implementors should study the protocols in
question to get a more complete set of security considerations. question to get a more complete set of security considerations.
Note that clients/users may also need to evaluate a server's Note that clients/users may also need to evaluate a server's
authorization context when using labeled security (e.g., is the authorization context when using labeled security [I-D.NFSv4.2]
server authorized to handle content at a given security level, for (e.g., is the server authorized to handle content at a given security
the given compartments). Even when not using labeled security, since level, for the given compartments). Even when not using labeled
there could be many realms (credential issuer) for a given server, security, since there could be many realms (credential issuer) for a
it's important to verify that the server a client is talking to has a given server, it's important to verify that the server a client is
credential for the name the client has for the server, and that that talking to has a credential for the name the client has for the
credential's issuer (i.e., its realm) is allowed to issue it. server, and that that credential's issuer (i.e., its realm) is
Usually the service principle realm authorization function is allowed to issue it. Usually the service principle realm
implemented by the security mechanism, but the implementor should authorization function is implemented by the security mechanism, but
check this. the implementor should check this.
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. In the simplest scheme a server principal's authorization context. In the simplest scheme a server
has access to a database mapping all known principal names to has access to a database mapping all known principal names to
usernames whose authorization context can be evaluated using 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.
 End of changes. 44 change blocks. 
155 lines changed or deleted 182 lines changed or added

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