draft-ietf-nfsv4-multi-domain-fs-reqs-10.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-11.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: March 2, 2017 Cryptonector Expires: March 5, 2017 Cryptonector
August 29, 2016 September 1, 2016
Multiple NFSv4 Domain Namespace Deployment Requirements Multiple NFSv4 Domain Namespace Deployment Requirements
draft-ietf-nfsv4-multi-domain-fs-reqs-10 draft-ietf-nfsv4-multi-domain-fs-reqs-11
Abstract Abstract
This document presents requirements on the deployment of the NFSv4 This document presents requirements on the deployment of the NFSv4
protocols for the construction of an NFSv4 file name space in protocols for the construction of an NFSv4 file name space in
environments with multiple NFSv4 Domains. To participate in an NFSv4 environments with multiple NFSv4 Domains. To participate in an NFSv4
multi-domain file name space, the server must offer a multi-domain multi-domain file 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.
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 March 2, 2017. This Internet-Draft will expire on March 5, 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 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Federated File System . . . . . . . . . . . . . . . . . . . . 5 3. Federated File System . . . . . . . . . . . . . . . . . . . . 5
4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5 4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5
4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5 4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5
4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6 4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6
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 . . . . . . . 8
6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 9 6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 9
6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9 6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9
6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 10 6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 10
6.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10 6.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10
6.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 11 6.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 11
7. Stand-alone Examples in an NFSv4 Multi-domain Deployment . . 11 7. Stand-alone Examples in an NFSv4 Multi-domain Deployment . . 11
8. Resolving Multi-domain Authorization Information . . . . . . 12 8. Resolving Multi-domain Authorization Information . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 21 skipping to change at page 3, line 21
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 syntax can provide unique identities and so enables
enables the NFSv4 multi-domain file name space. the NFSv4 multi-domain file name space.
Unlike previous versions of NFS, the NFSv4 protocols define a Unlike previous versions of NFS, the NFSv4 protocols define a
referral mechanism (Section 8.4.3 [RFC7530]) that allows a single referral mechanism (Section 8.4.3 [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 syntax and referral mechanism along
mechanism along with the use of RPCSEC_GSS security mechanisms with the use of RPCSEC_GSS security mechanisms enables the
enables the construction of an NFSv4 multi-domain file name space. construction of an NFSv4 multi-domain file name space.
This document presents requirements on the deployment of the NFSv4 This document presents requirements on the deployment of the NFSv4
protocols for the construction of an NFSv4 file name space in protocols for the construction of an NFSv4 file name space in
environments with multiple NFSv4 Domains. To participate in an NFSv4 environments with multiple NFSv4 Domains. To participate in an NFSv4
multi-domain file name space, the server must offer a multi-domain multi-domain file 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
skipping to change at page 8, line 45 skipping to change at page 8, line 45
File Access: The forms of GSS principal names are mechanism-specific. File Access: The forms of GSS principal names are mechanism-specific.
For Kerberos these are of the form principal@REALM. Sometimes For Kerberos these are of the form principal@REALM. Sometimes
authorization context information is delivered with authentication, authorization context information is delivered with authentication,
but this cannot be counted on. Authorization context information not but this cannot be counted on. Authorization context information not
delivered with authentication has timely update considerations (i.e., delivered with authentication has timely update considerations (i.e.,
generally it's not possible to get a timely update). File access generally it's not possible to get a timely update). File access
decisions therefore require a wire-to-disk mapping of the GSS decisions therefore require a wire-to-disk mapping of the GSS
principal to a UID, and an auth-to-authz mapping to obtain the list principal to a UID, and an auth-to-authz mapping to obtain the list
of GIDs as the authorization context. of GIDs as the authorization context.
Implementations must never blindly drop a Kerberos REALM name from a
Kerberos principal name to obtain a POSIX username, but they may be
configured to do so for specific REALMs.
Meta-data setting and listing: This is the same as in Section 5.2. Meta-data setting and listing: This is the same as in Section 5.2.
6. Multi-domain Constraints to the NFSv4 Protocol 6. Multi-domain Constraints to the NFSv4 Protocol
Joining NFSv4 Domains under a single file name space imposes slightly Joining NFSv4 Domains under a single file name space imposes slightly
on the NFSv4 administration freedom. Here we describe the required on the NFSv4 administration freedom. Here we describe the required
constraints. constraints.
6.1. Name@domain Constraints 6.1. Name@domain Constraints
NFSv4 uses a syntax of the form "name@domain" as the on-the-wire NFSv4 uses a syntax of the form "name@domain" (see Section 5.9
representation of the "who" field of an NFSv4 access control entry [RFC7530]) as the on-the-wire representation of the "who" field of an
(ACE) for users and groups. This design provides a level of NFSv4 access control entry (ACE) for users and groups. This design
indirection that allows NFSv4 clients and servers with different provides a level of indirection that allows NFSv4 clients and servers
internal representations of authorization identity to interoperate with different internal representations of authorization identity to
even when referring to authorization identities from different NFSv4 interoperate even when referring to authorization identities from
Domains. different NFSv4 Domains.
Multi-domain capable sites need to meet the following requirements in Multi-domain capable sites need to meet the following requirements in
order to ensure that NFSv4 clients and servers can map between order to ensure that NFSv4 clients and servers can map between
name@domain and internal representations reliably. While some of name@domain and internal representations reliably. While some of
these constraints are basic assumptions in NFSv4.0 [RFC7530] and these constraints are basic assumptions in NFSv4.0 [RFC7530] and
NFSv4.1 [RFC5661], they need to be clearly stated for the multi- NFSv4.1 [RFC5661], they need to be clearly stated for the multi-
domain case. domain case.
o The NFSv4 Domain portion of name@domain MUST be unique within the o The NFSv4 Domain portion of name@domain MUST be unique within the
multi-domain name space. See [RFC5661] section 5.9 "Interpreting multi-domain name space. See [RFC5661] section 5.9 "Interpreting
skipping to change at page 11, line 48 skipping to change at page 11, line 41
Domain deployments have no requirement for exporting multi-domain Domain deployments have no requirement for exporting multi-domain
capable file systems. To participate in an NFSv4 multi-domain capable file systems. To participate in an NFSv4 multi-domain
deployment, all three examples in Section 5 would need to export deployment, all three examples in Section 5 would need to export
multi-domain capable file systems. multi-domain capable file systems.
Due to the use of AUTH_SYS and stringified UID/GIDs the first stand- Due to the use of AUTH_SYS and stringified UID/GIDs the first stand-
alone deployment example in Section 5.1 is not suitable for alone deployment example in Section 5.1 is not suitable for
participation in an NFSv4 multi-domain deployment. participation in an NFSv4 multi-domain deployment.
The second example in described in Section 5.2 does use the The second example in described in Section 5.2 does use the
name@domain identity syntax, but the use of AUTH_SYS prohibits its name@domain syntax, but the use of AUTH_SYS prohibits its
participation in an NFSv4 multi-domain deployment. participation in an NFSv4 multi-domain deployment.
The third example in Section 5.3 can participate in a multi-domain The third example in Section 5.3 can participate in a multi-domain
name space deployment if: name space deployment if:
o The NFSv4 Domain name is unique across the name space. o The NFSv4 Domain name is unique across the name space.
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. Resolving Multi-domain Authorization Information 8. Resolving Multi-domain Authorization Information
When an RPCSEC_GSS principal is seeking access to files on an NFSv4 When an RPCSEC_GSS principal is seeking access to files on an NFSv4
server, after authenticating the principal, the server must obtain in server, after authenticating the principal, the server SHOULD obtain
a secure manner the principal's authorization context information in a secure manner the principal's authorization context information
from an authoritative source such as the name service in the from an authoritative source such as the name service in the
principal's NFSv4 Domain. principal's NFSv4 Domain.
In the stand-alone NFSv4 Domain case where the principal is seeking In the stand-alone NFSv4 Domain case where the principal is seeking
access to files on an NFSv4 server in the principal's home NFSv4 access to files on an NFSv4 server in the principal's home NFSv4
Domain, the server administrator has knowledge of the local policies Domain, the server administrator has knowledge of the local policies
and methods for obtaining the principal's authorization information and methods for obtaining the principal's authorization information
and the mappings to local representation of identity from an and the mappings to local representation of identity from an
authoritative source. E.g., the administrator can configure secure authoritative source. E.g., the administrator can configure secure
access to the local NFSv4 domain name service. access to the local NFSv4 domain name service.
 End of changes. 10 change blocks. 
24 lines changed or deleted 20 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/