| NFSv4 Working Group | W. Adamson |
| Internet-Draft | NetApp |
| Intended status: Standards Track | N. Williams |
| Expires: March 2, 2017 | Cryptonector |
| August 29, 2016 |
Multiple NFSv4 Domain Namespace Deployment Requirements
draft-ietf-nfsv4-multi-domain-fs-reqs-10
This document presents requirements on the deployment of the NFSv4 protocols for the construction of an NFSv4 file name space in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file name space, the server must offer a multi-domain capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity mapping services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], NFSv4.2 [I-D.NFSv4.2] introduce the concept of an NFS Domain. An NFSv4 Domain is defined as a set of users and groups using the NFSv4 name@domain user and group identification syntax with the same specified @domain.
Previous versions of the NFS protocol, such as NFSv3 [RFC1813], use the UNIX-centric user identification mechanism of numeric user and group ID for the uid3 and gid3 [RFC1813] file attributes and for identity in the ONCRPC [RFC5531] authsys_parms AUTH_SYS credential. Section 6.1 of [RFC2624] notes that the use of UNIX-centric numeric IDs limits the scale of NFS to large local work groups. UNIX-centric numeric IDs are not unique across NFSv3 deployments and so are not designed for Internet scaling achieved by taking into account multiple naming domains and multiple naming mechanisms (see Section 6.2). The NFSv4 Domain's use of the name@domain syntax provides this Internet scaling by allowing servers and clients to translate between the external name@domain string representation to a local or internal numeric (or other identifier) representation which matches internal implementation needs.
Multi-domain deployments require support for unique identities across the deployment's name services and security services, as well as the use of multi-domain file systems capable of the on-disk representation of identities belonging to multiple NFSv4 Domains. The name@domain identity syntax can provide unique identities and so enables the NFSv4 multi-domain file name space.
Unlike previous versions of NFS, the NFSv4 protocols define a referral mechanism (Section 8.4.3 [RFC7530]) that allows a single server or a set of servers to present a multi-server namespace that encompasses file systems located on multiple servers. This enables the establishment of site-wide, organization-wide, or even a truly global file name space.
The NFSv4 protocols name@domain identity syntax and referral mechanism along with the use of RPCSEC_GSS security mechanisms enables the construction of an NFSv4 multi-domain file name space.
This document presents requirements on the deployment of the NFSv4 protocols for the construction of an NFSv4 file name space in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file name space, the server must offer a multi-domain capable file system and support RPCSEC_GSS [RFC2203] for user authentication. In most instances, the server must also support identity mapping services.
The FedFS is the standardized method of constructing and administrating an enterprise-wide NFSv4 filesystem, and so is referenced in this document. The requirements for multi-domain deployments described in this document apply to all NFSv4 multi-domain deployments, whether they are run as a FedFS or not.
Stand-alone NFSv4 Domain deployments can be run in many ways. While a FedFS can be run within all stand-alone NFSv4 domain configurations some of these configurations [StandAlone] are not compatible with joining a multi-domain FedFS name space.
NFSv4 servers deal with two kinds of identities: authentication identities (referred to here as "principals") and authorization identities ("users" and "groups" of users). NFSv4 supports multiple authentication methods, each authenticating an "initiator principal" (typically representing a user) to an "acceptor principal" (always corresponding to the NFSv4 server). NFSv4 does not prescribe how to represent authorization identities on file systems. All file access decisions constitute "authorization" and are made by NFSv4 servers using authorization context information and file metadata related to authorization, such as a file's access control list (ACL).
NFSv4 servers may be required to perform two kinds of mappings depending upon what authentication and authorization information is sent on the wire, and what is stored in the exported file system. For example, if an authentication identity such as a Kerberos principal is sent with authorization information such a "privilege attribute certificate" (PAC) [PAC] then mapping is not required (see Section 8).
A Name Service such as LDAP often provides these mappings.
Many aspects of these mappings are entirely implementation specific, but some require multi-domain capable name resolution and security services in order to interoperate in a multi-domain environment.
NFSv4 servers use these mappings for:
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 unique identity form.
A client obtaining values 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 local form, as above. As a result name services need to be available to convert the unique 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 unique representation of identity directly.
The purpose of this section is to list some typical stand-alone deployment examples to highlight the need for the required restraints to the NFSv4 protocol, name service configuration, and security service choices in an NFSv4 multi-domain environment described in Section 6.
Section 7 notes how these stand-alone deployment examples would need to change to participate in an NFSv4 multi-domain deployment.
In order to service as many environments as possible, the NFSv4 protocol is designed to allow administrators freedom to configure their NFSv4 domains as they please. Stand-alone NFSv4 Domains can be run in many ways.
These examples are for a NFSv4 server exporting a POSIX UID/GID based file system, a typical deployment. These examples are listed in the order of increasing NFSv4 administrative complexity.
This example is the closest NFSv4 gets to being run as NFSv3 as there is no need for a name service for file metadata listing.
File access: The AUTH_SYS RPC credential [RFC5531] provides a UID as the authentication identity, and a list of GIDs as authorization context information. File access decisions require no name service interaction as the on-the-wire and on-disk representation are the same and the auth-to-authz UID and GID authorization context information is provided in the RPC credential.
Meta-data setting and listing: When the NFSv4 clients and servers 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 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 server.
Another possibility is to express identity using the form 'name@domain', rather than using a stringified UID/GID scheme for file metadata setting and listing.
File access: This is the same as in Section 5.1.
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-wire name@domain syntax and the on-disk UID/GID representation. Often, the NFSv4 server will use the nsswitch interface for these mappings. A typical use of the nsswitch name service interface uses no domain component, just the UID attribute [RFC2307] (or login name) 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 and can combined with the login name to form the name@domain syntax after the return of the name service call.
RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely authenticate users to servers. The most common mechanism is Kerberos [RFC4121].
This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS security mechanism.
File Access: The forms of GSS principal names are mechanism-specific. For Kerberos these are of the form principal@REALM. Sometimes authorization context information is delivered with authentication, but this cannot be counted on. Authorization context information not delivered with authentication has timely update considerations (i.e., generally it's not possible to get a timely update). File access 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 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.
Joining NFSv4 Domains under a single file name space imposes slightly on the NFSv4 administration freedom. Here we describe the required constraints.
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 (ACE) for users and groups. This design provides a level of indirection that allows NFSv4 clients and servers with different internal representations of authorization identity to interoperate even when referring to authorization identities from different NFSv4 Domains.
Multi-domain capable sites need to meet the following requirements in order to ensure that NFSv4 clients and servers can map between name@domain and internal representations reliably. While some of these constraints are basic assumptions in NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661], they need to be clearly stated for the multi-domain case.
Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used in a multi-domain deployment. This means that multi-domain-capable servers MUST reject requests that use stringified UID/GIDs.
Here we address the relationship between NFSv4 Domain name and DNS domain name in a multi-domain deployment.
The definition of an NFSv4 Domain name, the @domain portion of the name@domain syntax, needs clarification to work in a multi-domain file system name space. Section 5.9 [RFC5661] loosely defines the NFSv4 Domain name as a DNS domain name. This loose definition for the NFSv4 Domain name is a good one, as DNS domain names are globally unique. As noted above in Section 6.1, any choice of NFSv4 Domain name can work within a stand-alone NFSv4 Domain deployment whereas the NFSv4 Domain name is required to be unique across a multi-domain deployment.
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 can be the same as the DNS domain name.
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.
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 NFSv4 Domains must choose another unique NFSv4 Domain name.
As noted above in Section 6.1, each name@domain is unique across the multi-domain name space and maps, on each NFSv4 server, to the local representation of identity used by that server. Typically, this representation consists of an indication of the particular domain combined with the UID/GID corresponding to the name component. To support such an arrangement, each NFSv4 Domain needs to have a single name resolution service capable of converting the names defined within the domain to the corresponding local representation.
As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors":
NFSv4.1 clients and servers MUST implement RPCSEC_GSS.
(This requirement to implement is not a requirement
to use.) Other flavors, such as AUTH_NONE,
and AUTH_SYS, MAY be implemented as well.
The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used in a multi-domain name space is REQUIRED to employ a method of cross NFSv4 Domain trust so that a principal from a security service in one NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a security service with the same security mechanism. Kerberos is an example of such a security service.
The AUTH_NONE [RFC5531] security flavor can be useful in a multi-domain deployment to grant universal read-only access to public data without any credentials.
The AUTH_SYS security flavor [RFC5531] uses a host-based authentication model where the weakly authenticated host (the NFSv4 client) asserts the user's authorization identities using small integers, uidNumber, and gidNumber [RFC2307], as user and group identity representations. Because this authorization ID representation has no domain component, AUTH_SYS can only be used in a name space where all NFSv4 clients and servers share an [RFC2307] name service. A shared name service is required because uidNumbers and gidNumbers are passed in the RPC credential; there is no negotiation of name space in AUTH_SYS. Collisions can occur if multiple name services are used, so AUTH_SYS MUST NOT be used in a multi-domain file system deployment.
As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4 Domain security services are RPCSEC_GSS based with the Kerberos 5 security mechanism being the most commonly (and as of this writing, the only) deployed service.
A single Kerberos 5 security service per NFSv4 Domain with the upper case NFSv4 Domain name as the Kerberos 5 REALM name is a common deployment.
Multiple security services per NFSv4 Domain is allowed, and brings the need of mapping multiple Kerberos 5 principal@REALMs to the same local ID. Methods of achieving this are beyond the scope of this document.
In this section we revisit the stand-alone NFSv4 Domain deployment examples in Section 5 noting what is prohibiting them from participating in an NFSv4 multi-domain deployment.
Note that because all on-disk identities participating in a stand-alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4 Domain deployments have no requirement for exporting multi-domain capable file systems. To participate in an NFSv4 multi-domain deployment, all three examples in Section 5 would need to export multi-domain capable file systems.
Due to the use of AUTH_SYS and stringified UID/GIDs the first stand-alone deployment example in Section 5.1 is not suitable for participation in an NFSv4 multi-domain deployment.
The second example in described in Section 5.2 does use the name@domain identity syntax, but the use of AUTH_SYS prohibits its participation in an NFSv4 multi-domain deployment.
The third example in Section 5.3 can participate in a multi-domain name space deployment if:
When an RPCSEC_GSS principal is seeking access to files on an NFSv4 server, after authenticating the principal, the server must obtain in a secure manner the principal's authorization context information from an authoritative source such as the name service in the principal's NFSv4 Domain.
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 Domain, the server administrator has knowledge of the local policies and methods for obtaining the principal's authorization information and the mappings to local representation of identity from an authoritative source. E.g., the administrator can configure secure access to the local NFSv4 domain name service.
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 NFSv4 server may be required to contact the remote name service in the principals NFSv4 Domain. In this case there is no assumption of:
There are several methods the NFSv4 server can use to obtain the NFSv4 Domain authoritative authorization information for a remote principal from an authoritative source. While any detail is beyond the scope of this document, some general methods are listed here.
This RFC discusses security throughout. All the security considerations of the relevant protocols, such as NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS Security Addendum [I-D.lever-fedfs-security-addendum] apply.
Authentication and authorization across administrative domains presents security considerations, most of which are treated elsewhere, but we repeat some of them here:
Most of these are security considerations of the mechanisms used to authenticate users to servers and servers to users, and of the mechanisms used to evaluate a user's authorization context.
Implementors may be tempted to assume that realm (or "issuer") and NFSv4 Domain are roughly the same thing, but they are not. Configuration and/or lookup protocols (such as LDAP) and associated schemas are generally required in order to evaluate a user principal's authorization context (see Section 8). In the simplest scheme a server has access to a database mapping all known principal names to usernames whose authorization context can be evaluated using operating system interfaces that deal in usernames rather than principal names.
Note that clients may also need to evaluate a server's authorization context when using labeled security [I-D.NFSv4.2] (e.g., is the server authorized to handle content at a given security level, for the given client process subject label).
When the server accepts user credential from more than one realm, it is important to remember that the server must verify that the client it is talking to has a credential for the name the client has presented the server, and that that credential's issuer (i.e., its realm) is allowed to issue it. Usually the service principal realm authorization function is implemented by the security mechanism, but the implementor should check this.
There are no IANA considerations in this document.
Andy Adamson would like to thank NetApp, Inc. for its funding of his time on this project.
We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and David Noveck for their review.