Requirements for NFSv4 Multi-Domain Namespace Deployment
Extracted elements (26)
AUTH_SYS cannot be used in multi-domain deployments because it uses a host-based authentication model with small integers (uidNumber, gidNumber) that have no domain component; collisions are inevitable when multiple name services are used and there is no namespace negotiation in AUTH_SYS.
NFSv4 adopted the name@domain syntax to overcome the limitation of UNIX-centric numeric UIDs/GIDs (from NFSv3), which are not unique across deployments. The name@domain syntax provides Internet scaling by allowing translation between the external string form and local numeric identifiers, enabling multi-domain namespaces.
The NFSv4 Domain name is intentionally defined loosely as a DNS domain name (per RFC 5661 Section 5.9) because DNS domain names are globally unique, making them a natural basis for ensuring cross-deployment NFSv4 Domain uniqueness.
The preferred method for resolving multi-domain authorization information is a mechanism-specific GSS-API authorization payload (e.g., PAC or PAD) delivered as part of GSS-API authentication, because it avoids requiring knowledge of the remote authoritative service configuration and has a well-known syntax.
An NFSv4 Domain can span multiple DNS domains (in which case one DNS domain name is chosen as the NFSv4 Domain name), and multiple NFSv4 Domains can share a DNS domain (in which case only one can use the DNS domain name; others must choose unique names).
Each NFSv4 Domain needs a single name resolution service capable of converting domain-internal names to the local representation of identity; typically, this is a domain component combined with a UID/GID.
NFSv4 clients setting or getting owner/group attributes typically need identity-mapping services because client-side APIs require local identity forms (e.g., UID/GID), which must be converted to or from the unique name@domain form for on-the-wire representation.
Stand-alone deployments using AUTH_SYS (with or without name@domain) cannot participate in an NFSv4 multi-domain deployment. Only deployments using RPCSEC_GSS with name@domain, a unique NFSv4 Domain name, multi-domain-capable file systems, and secure remote authorization resolution are eligible.
AUTH_SYS MUST NOT be used in a multi-domain file system deployment because its UID/GID authorization ID representation has no domain component, causing collisions when multiple name services are used.
NFSv4.1 clients and servers MUST implement RPCSEC_GSS (though this is not a requirement to use it); other flavors such as AUTH_NONE and AUTH_SYS MAY be implemented as well.
Stringified UID/GIDs MUST NOT be used in a multi-domain deployment due to UID and GID collisions. Multi-domain-capable servers MUST reject requests that use stringified UID/GIDs.
The name portion of name@domain MUST be unique within the specified NFSv4 Domain.
The NFSv4 Domain portion of the name@domain syntax MUST be unique within the multi-domain namespace to ensure reliable mapping between name@domain and internal representations.
The RPCSEC_GSS GSS-API security mechanism used in a multi-domain namespace is REQUIRED to employ a method of cross NFSv4 Domain trust so that a principal from one domain can be authenticated in another domain using the same security mechanism.
When an RPCSEC_GSS principal seeks file access, the server SHOULD obtain the principal's authorization context information in a secure manner from an authoritative source such as the name service in the principal's NFSv4 Domain.
A multi-domain-capable file system is a local file system that uses a local ID form capable of representing NFSv4 identities from multiple domains. All servers participating in a multi-domain deployment must export such file systems.
A Principal is an RPCSEC_GSS authentication identity, usually a user, sometimes a host or server. For Kerberos, principal names take the form principal@REALM.
An Authorization Context is a collection of information about a principal (user name, userID, group membership, etc.) used in authorization decisions. NFSv4 servers use this for file access and metadata setting/listing.
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.
NFSv4 servers may require two kinds of identity mappings: (1) auth-to-authz mapping between authentication identity and authorization context information, and (2) wire-to-disk mapping between on-the-wire and on-disk authorization identity representations. A name service such as LDAP often provides these.
Stringified UID or GID values are NFSv4 owner and group strings consisting of decimal numeric values with no leading zeros and no '@' sign, as defined in RFC 5661 Section 5.9. These MUST NOT be used in multi-domain deployments.
The NFSv4 name@domain syntax is the on-the-wire representation of identity for the 'who' field of NFSv4 ACEs, providing a level of indirection that allows clients and servers with different internal identity representations to interoperate across NFSv4 Domains.
Clients may need to evaluate a server's authorization context when using labeled security (RFC 7862), for example to determine whether the server is authorized to handle content at a given security level for the client process subject label.
Cross-domain authentication and authorization introduce latency risks in propagation of revocation of authentication credentials and authorizations, as well as latency in granting of authorizations, and privacy considerations in federated environments.
Implementors must not conflate 'realm' (or 'issuer') with 'NFSv4 Domain'; they are distinct concepts. Configuration and lookup protocols (such as LDAP) are generally required to evaluate a user principal's authorization context.
When a server accepts user credentials from more than one realm, it must verify that the client holds a credential for the name it presented and that the credential's issuer (realm) is authorized to issue it. This realm authorization function is usually implemented by the security mechanism, but implementors should verify this.