| NFSv4 Working Group | W.A. Adamson |
| Internet-Draft | NetApp |
| Intended status: Standards Track | N. Williams |
| Expires: October 19, 2013 | Cryptonector |
| April 17, 2013 |
NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02
This document describes constraints to the NFSv4.0 and NFSv4.1 protocols as well as the use of multi-domain capable file systems, name resolution services, and security services required to fully enable a multi-domain NFSv4 federated file system.
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 October 19, 2013.
Copyright (c) 2013 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 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].
The NFSv4.0 [RFC3530] and NFSv4.1 [RFC5661] (hereafter referred to as NFSv4) protocols enable the construction of a distributed file system which can join NFSv4 servers from multiple NFSv4 domains, each potentially using separate name resolution services and separate security services, into a common multi-domain name space.
The Federated File System (FedFS) [RFC5716] describes the requirements and administrative tools to construct a uniform file server based namespace that is capable of spanning a whole enterprise and that is easy to manage.
An NFSv4 multi-domain capable filesystem uses local ID forms that can represent identities from both local and remote NFSv4 domains. An NFSv4 multi-domain FedFS joins multiple NFSv4 domains each consisting of NFSv4 servers that export multi-domain capable filesystems, and that employ potentially separate name resolution services and separate security services into a uniform NFSv4 server-based name space capable of spanning multiple enterprises.
This document describes constraints to the NFSv4.0 and NFSv4.1 protocols as well as the use of multi-domain capable file systems, name resolution services, and security services required to fully enable an NFSv4 multi-domain federated file system.
NFSv4 deals 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 therefore must perform two kinds of 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 NFSv4 FedFS file system, NFSv4 servers must use such services in compatible ways.
NFSv4 uses a syntax of the form "name@domain" as the on 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.
NFSv4 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:
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 security mechanism used in a multi-domain NFSv4 FedFS 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, and PKU2U [I-D.zhu-pku2u] are examples of such security services.
The AUTH_NONE security flavor can be useful in a multi-domain NFSv4 FedFS to grant universal access to public data without any credentials.
The AUTH_SYS security flavor 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 DNS 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 namespace in AUTH_SYS. Collisions can occur if multiple name services are used. AUTH_SYS can not be used in an NFSv4 multi-domain federated file system.
A new version of RPCSEC_GSS [I-D.williams-rpcsecgssv3] includes a modernized replacement for AUTH_SYS which addresses this issue.
In the mult-domain case where a principal is seeking access to files on a NFSv4 server in a different NFSv4 domain, the NFSv4 server must [ANDROS: MUST?] obtain, in a secure manner, the principal's authorization information from an authoritative source: e.g. a name service in the principal's NFSv4 domain. The NFSv4 server then needs to map the remote principal and the authorization information such as the principal's primary group and group membership list into a local representation of ID suitable for use in file system ACLs. This is the first mapping described in Section 4 "Background".
In the local NFSv4 domain case where the principal is seeking access to files on an NFSv4 server in the local NFSv4 domain, the server has knowledge of the local policies and methods for obtaining the principal's authorization information and the mapping to local representation of identity. In the multi-domain case there can be no assumption of such knowledge.
There are several methods the remote NFSv4 domain authoritative authorization information for a principal can be obtained:
The authorization data information should be obtained via the GSS-API name attribute interface [RFC6680] either via a single attribute for the credential authorization data or via discrete GSS-API name attributes corresponding to the authorization data elements.
Note that the retrieval of attribute values used by the GSS-API name attribute interface implementation could utilize any of the above mentioned methods of obtaining the authorization information which demonstrates the usefulness of the API.
To avoid requiring detailed knowledge of remote NFSv4 domain name services, authorization context information SHOULD be obtained from the credentials authenticating a principal; the GSS-API represents such information as attributes of the initiator principal name.
For example:
The authorization context information in a GSS-API authorization payload can be considered a single, authenticated, discrete GSS-API name attribute, in which case the NFSv4 server must parse it into its individual elements and ID-Map or use name services to map the information to local ID representations. [ANDROS: clarify - is it one name attribute or not. If not, how can you tell?]
When servicing a set acl request, the NFSv4 server must be able to map the name@domain in the ACE who field to a local representation of ID. When servicing a get acl request, the NFSv4 server must be able to map the local representation of ID in the file system ACL to the name@domain form. This mapping between name@domain and local representation of ID must [ANDROS: MUST?] be done against an authoritative source. This is the second mapping described in Section 4 "Background".
The local name-service is authoritative for these mappings for remote users and groups when one of the first two methods in [AuthResolution] is used to keep the local name-service updated with remote information.
Some considerations to come
| [I-D.williams-rpcsecgssv3] | Haynes, T. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", Internet-Draft draft-williams-rpcsecgssv3-02, May 2011. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. |