draft-ietf-nfsv4-multi-domain-fs-reqs-04.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-05.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 15, 2016 Cryptonector Expires: February 22, 2016 Cryptonector
August 14, 2015 August 21, 2015
Multiple NFSv4 Domain Namespace Deployment Guidelines Multiple NFSv4 Domain Namespace Deployment Guidelines
draft-ietf-nfsv4-multi-domain-fs-reqs-04 draft-ietf-nfsv4-multi-domain-fs-reqs-05
Abstract Abstract
This document discusses issues relevant to the deployment of the This document discusses issues relevant to the deployment of the
NFSv4 protocols in situations allowing for the construction of an NFSv4 protocols in situations allowing for the construction of an
NFSv4 file 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
constraints on name resolution and security services appropriate to constraints on name resolution and security services appropriate to
the administration of such a system. Such a namespace is a suitable the administration of such a system. Such a namespace is a suitable
way to enable a Federated File System supporting the use of multiple way to enable a Federated File System supporting the use of multiple
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 15, 2016. This Internet-Draft will expire on February 22, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5 3. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5 3.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5
3.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6 3.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6
4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6
4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7
4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7
4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 8 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8
5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9
5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9 5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10 5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9
5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10
6. Resolving Multi-domain Authorization Information . . . . . . 11 6. Resolving Multi-domain Authorization Information . . . . . . 10
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12 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 . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
An NFSv4 domain is defined as a set of users and groups named by a An NFSv4 domain is defined as a set of users and groups named by a
particular domain using the NFSv4 name@domain syntax. This includes particular domain using the NFSv4 name@domain syntax. This includes
NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be
published. Often, a computer which acts as an NFSv4 client and published. Often, a computer which acts as an NFSv4 client and
always acts on behalf of users belonging to a particular NFSv4 domain always acts on behalf of users belonging to a particular NFSv4 domain
is thought of a part of that NFSv4 domain. Similarly, a computer is thought of a part of that NFSv4 domain. Similarly, a computer
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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: 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 a uidNumber (UID) or API's. Examples are numeric id's such as a uidNumber (UID),
gidNumber (GID) [RFC2307], 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 the one 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.
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 NFSv4 identities from multiple local ID form that can represent NFSv4 identities from multiple
domains. domains.
skipping to change at page 5, line 46 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 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. 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. 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
skipping to change at page 6, line 20 skipping to change at page 6, line 20
from the server's local representation of identity. from the server's local representation of identity.
3.2. NFSv4 Client Identity Mapping 3.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 API's within the
client will specify the identity in a local form (e.g UNIX using a 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 uid/gid) so that when stringified id's cannot be used, the id must be
converted to a global form. converted to a global form.
A client obtaining value 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 a local form, as the client API will need these attributes in a local form, as above.
above. As a result name services need to be available to convert the As a result name services need to be available to convert the global
global 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 global mapping services would not arise if the clients could use the global
representation of identity directly. 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
skipping to change at page 6, line 49 skipping to change at page 6, line 49
server's use of name service mappings (Section 3.1) 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 7, line 34 skipping to change at page 7, line 25
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
Another possibility is express identity using the form 'name@domain', Another possibility is to express identity using the form
rather than using use a stringified UID/GID scheme for file metadata 'name@domain', rather than using a stringified UID/GID scheme for
setting and listing. 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
skipping to change at page 8, line 17 skipping to change at page 8, line 5
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 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 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 GIDs as the authorization context. of GIDs as the authorization context.
Implementations must never blindly drop a Kerberos REALM name from a Implementations must never blindly drop a Kerberos REALM name from a
Kerberos principal name to obtain a POSIX username, but they may be Kerberos principal name to obtain a POSIX username, but they may be
configured to do so for specific REALMs. configured to do so for specific REALMs.
skipping to change at page 9, line 51 skipping to change at page 9, line 39
5.1.2. NFSv4 Domain and Name Services 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
multi-domain namespace and maps, on each NFSv4 server, to the local multi-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 uid/gid. within the domain to the corresponding local representation.
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.
skipping to change at page 11, line 35 skipping to change at page 11, line 20
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 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 principals 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 any detail is beyond
the scope of this document, some general methods are listed here. the scope of this document, some general methods are listed here.
skipping to change at page 12, line 12 skipping to change at page 11, line 46
avoids requiring any knowledge of the remote authoritative avoids requiring any knowledge of the remote authoritative
service configuration, and its syntax is well known. service configuration, and its syntax is well 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 principal's 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 it's local NFSv4 domain name
service just as it does when servicing a local domain principal. service just as it does when servicing a local domain principal.
While this requires detailed knowledge of the remote NFSv4 While this requires detailed knowledge of the remote NFSv4
domains name service, the authorization context information domains name service for the update data feeds, the authorization
presented to the NFSv4 server is in the same form as a query for context information presented to the NFSv4 server is in the same
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.
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces
 End of changes. 18 change blocks. 
35 lines changed or deleted 25 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/