NFSv4 Multi-Domain FedFS Requirements

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 .

The NFSv4.0 and NFSv4.1 (NFSv4) protocols enable the construction of a distributed file system which can join NFSv4 servers from multiple administrative domains, each potentially using separate name resolution services and separate security services, into a common multi-domain name space. The Federated File System (FedFS) describes the requirements and administrative tools to construct a uniform server-based namespace that is capable of spanning a whole enterprise and that is easy to manage. A multi-domain capable filesystem uses local ID forms that can represent identities from both local and remote domains. A multi-domain NFSv4 FedFS joins multiple NFSv4 administrative domains each consisting of NFSv4 servers that export multi-domain capable filesystems, and that employ potentially :w separate name resolution services and separate security services into a uniform 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 to fully enable a multi-domain NFSv4 federated file system.

(NFSv4) Domain: a set of users, groups and computers administered by a single entity, and identified by a DNS domain name. Local representation of identity: an object such as a uidNumber (UID) or gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID), or other such representation of a user or a group of users on-disk in a file system. Global ID: A representation of identity that is globally unique. Examples include the name@domain or ID@domain NFSv4 syntax, and the Windows Security Identifier (SID). Name Service: provides the mapping between {domain, name} and {domain, ID} via lookups. Can be applied to local or remote domains. Often provided by a Directory Service such as LDAP. ID mapping: Is a mapping between {remote domain, remote domain ID} and {local representation of identity}. Principal: an RPCSEC_GSS authentication identity. Usually, but not always, a user; rarely, if ever, a group; sometimes a host. Authorization Context: A collection of information about a principal such as username, userID, group membership, etcetera used in authorization decisions.

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 principals" (always corresponding to the server). NFSv4 does not prescribe how to represent authorization identities on file systems. All file access decisions constitute "authorization" and are made by 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: A mapping between the authentication identity and the authorization context information. A mapping between the on-the-wire authorization identity representation and the on-disk authorization identity representation. 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 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 a client and server with different internal representations of authorization identity to interoperate even when referring to authorization identities from different administrative domains. Multi-domain capable sites need to meet the following requirements in order to ensure that clients and servers can map between name@domain and internal representations reliably: The domain portion of name@domain MUST be unique within the FedFS NFSv4 multi-domain namespace. [ANDROS: IANA help here?] See section 5.9 "Interpreting owner and owner_group" for a discussion on NFSv4 domain configuration. The name portion of name@domain MUST be unique within the specified domain. Every local representation of a user and of a group MUST have a canonical name@domain, and it must be possible to return the canonical name@domain for any identity stored on disk, at least when required infrastructure servers (such as name services) are online.

As described in 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 domain trust so that a principal from a security service in one domain can be authenticated in another domain that uses a security service with the same security mechanism. Kerberos, and 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 NFS client) asserts the user's authorization identities using small integers, uidNumber and gidNumber , 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 clients and servers share an 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 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 server in a different NFSv4 domain, the NFS server needs to obtain, in a secure manner, the principal's authorization information from an authoritative source: e.g. a name service in the principal's NFS domain. The NFS server must map the remote RPCSEC_GSS principal to a local representation of ID suitable for use in file system ACLs. This may also involve the need to map the remote RPCSEC_GSS principal to a name@domain form. The principal's primary group and group membership list must also be mapped into local representations of ID. In the local NFSv4 domain case where the principal is seeking access to files on a server in the local 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 cross-domain authoritative authorization information can be obtained: A mechanism specific GSS-API authorization payload containing credential authorization data. This is the preferred method as it avoids requiring any knowledge of a remote domain name service. An authenticated NFS server local domain name query when there is a security agreement between the two multi-domain name services plus regular update data feeds so that the NFS server local domain name service is authoritative for the principal's NFSv4 domain. An authenticated direct query from the NFS server to the principal's domain authoritative name service. This requires the NFS server to have detailed knowledge of the remote domain's authoritative name service. The authorization data information SHOULD be obtained via the GSS-API name attribute interface 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.

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: Kerberos 5 has a method for conveying "authorization data", both client-asserted as well as KDC-authenticated authorization data. Some KDC implementation, notably Windows KDCs, use this feature to convey a "privilege attribute certificate" listing the principal's user and group global IDs as "security identifiers" (SIDs). Some KDCs (will) issue Kerberos Tickets with the General PAD (PAD) as Kerberos authorization data listing user and group names along with their uidNumber and gidNumber [RFC2307], the name of the DNS domain along with a unique domain identifier and other information. The General PAD authorization data MUST be authenticated in the sense that its contents must come from an authenticated, trusted source, such as a name server or the issuer of the principal's credential. PKIX certificates allow for extensions that could be used similarly. When a principal is authenticated using a GSS-API authorization payload, the server SHOULD extract the payload from the client's ticket and ID-Map or use name services to map the information to local ID representations if required. 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 server must parse it into its individual elements. Remote authoritative name service queries may also be necessary to construct the name@domain form of an ID obtained from a GSS-API authorization payload.

When servicing a set acl request, the NFS 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 NFS 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 needs to be done against an authoritative service.

In order to add a remote NFSv4 domain's users and groups to file system ACLs in the local NFSv4 domain, a local account must be created. This in turn makes the local domain authoritative with respect to mapping between name@domain and local representation of identity for the remote user. Adding a user from a remote NFSv4 domain to a local NFSv4 domain is not that different from adding a local user: a local account is created giving the remote user a local representation of ID. Extra steps may need to be taken to enable mapping between the remote RPCSEC_GSS principal and the local representation of ID, as well as the mapping between the local representation of ID and the name@(remote)domain. Adding a group from a remote NFSv4 domain to a local NFSv4 domain is similar to adding a local group: a local account is created giving the remote group a local representation of ID. Extra steps may need to be taken to enable mapping between the name@(remote)domain and the local representation of ID.

There are several issues here that need to be resolved, including which if any of these questions should be answered in this document: Remote user: We want the local name service to be authoritative for resolving name@domain to local ID mappings. Does this mean we need to be notified when a remote user is removed from the remote domain? How is this different from a local user? Remote user/group: Note that when the authorization context information is parsed as part of multi-domain file access, group membership for the principal is determined which gives an opportunity to update the local domain data concerning the principals membership (or not) in remote groups. Remote group: Who gets to add members to a remote group? The remote group owner? The local domain admin? Who performs membership updates? Remote group: We want the local name service to be authoritative for resolving name@domain to local ID mappings. Does this mean that we need to be notified if the remote group is removed from the remote home domain? Remote group: Listing the membership of a remote group may not be allowed (expected to work?) due to the problem of knowing about and querying all domains that provide members.

Some considerations to come