RFC 8000

Requirements for NFSv4 Multi-Domain Namespace Deployment

📅 published November 2016, from ietf

Requirements for NFSv4 Multi-Domain Namespace Deployment 💖

  • RFC number: 8000
  • Authors: W. Adamson (NetApp) and N. Williams (Cryptonector) 🎀
  • Category: Standards Track 🔥
  • ISSN: 2070-1721
  • Date: November 2016 🌸
  • Obsoletes and updates: the title block doesn't list anything this RFC obsoletes or updates ✨

Abstract ✨

okay so this doc lays out the requirements for deploying NFSv4 to build an NFSv4 file namespace when you've got multiple NFSv4 Domains going on 🦋 to join one of these multi-domain file namespaces, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. in most cases, the server must also support identity-mapping services 💅

Status of This Memo 🧚

this is an Internet Standards Track document 💜

it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🙌 for more on Internet Standards, check Section 2 of RFC 7841.

you can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc8000 🍓

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) as they stand on the date this document was published. please actually read these, because they spell out your rights and restrictions for this document 👀 any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 📖

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Federated File System . . . . . . . . . . . . . . . . . . . .   5
   4.  Identity Mapping  . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  NFSv4 Server Identity Mapping . . . . . . . . . . . . . .   6
     4.2.  NFSv4 Client Identity Mapping . . . . . . . . . . . . . .   7
   5.  Stand-Alone NFSv4 Domain Deployment Examples  . . . . . . . .   7
     5.1.  AUTH_SYS with Stringified UID/GID . . . . . . . . . . . .   7
     5.2.  AUTH_SYS with Name@domain . . . . . . . . . . . . . . . .   8
     5.3.  RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . .   8
   6.  Multi-Domain Constraints to the NFSv4 Protocol  . . . . . . .   9
     6.1.  Name@domain Constraints . . . . . . . . . . . . . . . . .   9
       6.1.1.  NFSv4 Domain and DNS Services . . . . . . . . . . . .   9
       6.1.2.  NFSv4 Domain and Name Services  . . . . . . . . . . .  10
     6.2.  RPC Security Constraints  . . . . . . . . . . . . . . . .  10
       6.2.1.  NFSv4 Domain and Security Services  . . . . . . . . .  11
   7.  Stand-Alone Examples in an NFSv4 Multi-Domain Deployment  . .  11
   8.  Resolving Multi-Domain Authorization Information  . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🎀

okay so the NFSv4 protocols (NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and NFSv4.2 [RFC7862]) bring in the concept of an NFS Domain 💅 an NFSv4 Domain is basically a set of users and groups that use the NFSv4 name@domain user and group identification syntax with the same specified @domain ✨

older NFS versions, like NFSv3 [RFC1813], were super UNIX-centric. they used numeric user and group IDs for the uid3 and gid3 [RFC1813] file attributes, and for identity in the authsys_parms AUTH_SYS credential defined in the Open Network Computing (ONC) Remote Procedure Call (RPC) protocol [RFC5531]. ngl that's giving very local vibes 😭 Section 6.1 of [RFC2624] points out that those UNIX-centric numeric IDs limit NFS to large local work groups. they also aren't unique across NFSv3 deployments, so they weren't built for Internet scaling, which means taking multiple naming domains and multiple naming mechanisms into account (see Section 6.2). the NFSv4 Domain's name@domain syntax is what unlocks that Internet scaling 🌍 it lets servers and clients translate between the external name@domain string and a local or internal numeric (or other identifier) form that fits what the implementation actually needs 🔥

multi-domain deployments need unique identities across the deployment's name services and security services. they also need multi-domain file systems that can store identities from multiple NFSv4 Domains on disk 💜 the name@domain syntax can give you those unique identities, which is what makes the NFSv4 multi-domain file namespace possible 🦋

here's the other big upgrade: unlike earlier NFS versions, the NFSv4 protocols have a referral mechanism (Section 8.4.3 of [RFC7530]). that lets one server, or a set of servers, present a multi-server namespace covering file systems on several servers 🧚 it makes site-wide, organization-wide, or even truly global file namespaces possible 🌈

so the NFSv4 protocols' name@domain syntax and referral mechanism, plus RPCSEC_GSS security mechanisms, are what make building an NFSv4 multi-domain file namespace possible 💖

this document lays out requirements for deploying the NFSv4 protocols to build an NFSv4 file namespace across multiple NFSv4 Domains. to join an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS [RFC2203] for user authentication. in most cases, the server must also support identity-mapping services 🫶

1.1. Requirements Language 📝

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]. 🍓

2. Terminology 📚

  • NFSv4 Domain: a set of users and groups that use the NFSv4 name@domain user and group identification syntax with the same specified @domain 💅
  • Stand-alone NFSv4 Domain: a deployment of the NFSv4 protocols and NFSv4 file namespace in an environment with a single NFSv4 Domain ✨
  • Local representation of identity: a representation of a user or group of users that can be stored persistently in a file system. usually it's the same form users and groups take inside internal server APIs. examples are numeric IDs like a uidNumber (UID), gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID) [CIFS]. sometimes the ID space for users and groups overlaps, which means anyone using such an ID has to know ahead of time whether it's for a user or a group 🙈
  • Unique identity: an on-the-wire form of identity that's unique across an NFSv4 multi-domain namespace and can be mapped to a local representation. for example, the NFSv4 name@domain or the Kerberos principal [RFC4120] 🔑
  • Multi-domain: in this document, "multi-domain" always refers to multiple NFSv4 Domains 🌸
  • Multi-domain-capable file system: a local file system that uses a local ID form able to represent NFSv4 identities from multiple domains 🎀
  • Principal: an RPCSEC_GSS [RFC2203] authentication identity. it's usually, but not always, a user; rarely, if ever, a group; and sometimes a host or server 🧚
  • Authorization Context: a collection of information about a principal, such as user name, userID, group membership, etc., used in authorization decisions 🦋
  • Stringified UID or GID: NFSv4 owner and group strings made of decimal numeric values with no leading zeros that don't contain an '@' sign. see Section 5.9 of [RFC5661] 💜
  • Name Service: facilities that map {NFSv4 Domain, group, or user name} to the right local representation of identity. this also covers facilities that map a security principal to a local representation of identity. it can apply to unique identities or principals from local and remote domains. it's often provided by a Directory Service like the Lightweight Directory Access Protocol (LDAP) [RFC4511] 🌈
  • Name Service Switch (nsswitch): a facility that provides a bunch of sources for common configuration databases and name resolution mechanisms 🍓
  • FedFS: the Federated File System (FedFS) [RFC5716] describes the requirements and admin tools for building a uniform NFSv4 file-server-based namespace that can span a whole enterprise and is easy to manage 👑
  • Domain: this term gets used in several contexts with different meanings. "NFSv4 Domain" and "multi-domain" are defined above 🙈
    • DNS domain: a set of computers, services, or any Internet resource identified by a DNS domain name [RFC1034] 🌐
    • Security realm or domain: a set of configured security providers, users, groups, security roles, and security policies running a single security protocol and administered by a single entity, for example, a Kerberos realm 🔐
    • FedFS domain: a file namespace that can cross multiple shares on multiple file servers using file-access protocols such as NFSv4. a FedFS domain is typically a single administrative entity and has a name that looks like a DNS domain name. also known as a "Federation" 🧺
    • Administrative domain: a set of users, groups, computers, and services administered by a single entity. it can include multiple DNS domains, NFSv4 Domains, security domains, and FedFS domains 🏰

3. Federated File System 🌸

the FedFS is the standardized way to build and administer an enterprise-wide NFSv4 file system, which is why it's referenced in this document 💖 the requirements for multi-domain deployments described here apply to all NFSv4 multi-domain deployments, whether or not they run as a FedFS.

stand-alone NFSv4 Domain deployments can be set up in lots of ways 🎀 a FedFS can run inside all stand-alone NFSv4 Domain configurations, but some of those configurations (Section 5) aren't compatible with joining a multi-domain FedFS namespace 🙅‍♀️

4. Identity Mapping 🦋

4.1. NFSv4 Server Identity Mapping ✨

okay so NFSv4 servers deal with two kinds of identities 🫶: authentication identities (called "principals" here) and authorization identities ("users" and "groups" of users). NFSv4 supports multiple authentication methods, and each one authenticates an "initiator principal" (usually a user 💖) to an "acceptor principal" (which always corresponds to the NFSv4 server). NFSv4 doesn't prescribe how authorization identities get represented on file systems 🤷‍♀️. Every file access decision counts as "authorization," and NFSv4 servers make those calls using authorization context information and file metadata related to authorization, like a file's access control list (ACL) 💅.

NFSv4 servers may be required to do two kinds of mappings, depending on what authentication and authorization info is sent on the wire and what's stored in the exported file system. For example, if an authentication identity like a Kerberos principal gets sent along with authorization info like a "privilege attribute certificate" (PAC) [PAC], then mapping isn't required (see Section 8) ✨. Lowkey a glow-up!

  1. Auth-to-authz: A mapping between the authentication identity and the authorization context information.
  2. Wire-to-disk: A mapping between the on-the-wire authorization identity representation and the on-disk authorization identity representation.

A name service such as LDAP often provides these mappings 🧚.

Many aspects of these mappings are entirely implementation specific 🌸, but some need multi-domain-capable name resolution and security services in order to interoperate in a multi-domain environment.

NFSv4 servers use these mappings for:

  1. File access: Both the auth-to-authz and the wire-to-disk mappings may be required for file access decisions.
  2. Metadata setting and listing: The auth-to-authz mapping is usually required to service file metadata setting or listing requests, such as ACL or UNIX permission setting or listing. This mapping is needed because NFSv4 messages use identity representations of the form name@domain, which normally differs from the server's local representation of identity 🍓.

4.2. NFSv4 Client Identity Mapping 🎀

A client setting the owner or group attribute will often need access to identity-mapping services. Why? Because APIs within the client specify the identity in a local form (e.g., UNIX using a UID/GID), so when stringified id's can't be used, the ID has to be converted into a unique identity form 🔄.

A client obtaining values for the owner or group attributes will similarly need access to identity-mapping services 👀. The client API needs these attributes in a local form, as above, so name services need to be available to convert the unique identity into a local form. It's giving teamwork 🫶.

Note that each of these situations happens because client-side APIs require a particular local identity representation. The need for mapping services wouldn't come up if clients could use the unique representation of identity directly 💜.

5. Stand-Alone NFSv4 Domain Deployment Examples 🏠

The purpose of this section is to list some typical stand-alone deployment examples, so we can see why the required restraints on the NFSv4 protocol, name service configuration, and security service choices in an NFSv4 multi-domain environment (described in Section 6) are a thing 🧐.

Section 7 notes how these stand-alone deployment examples would need to change to join an NFSv4 multi-domain deployment 🦋.

To serve as many environments as possible, the NFSv4 protocol lets administrators do whatever they want when configuring their NFSv4 Domains 💅. Stand-alone NFSv4 Domains can be run in lots of ways ✨.

These examples are for an NFSv4 server exporting a POSIX UID/GID-based file system, which is a typical deployment 🌈. They're listed in order of increasing NFSv4 administrative complexity 📈.

5.1. AUTH_SYS with Stringified UID/GID 🔥

This example is the closest NFSv4 gets to running as NFSv3, because there's 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 need no name service interaction, since the on-the-wire and on-disk representations are the same, and the auth-to-authz UID and GID authorization context information comes right in the RPC credential 💖.

Metadata setting and listing: When 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, a name service isn't needed for file metadata listing, because the server can construct the UID or GID from the stringified form on the fly 🧚.

5.2. AUTH_SYS with Name@domain 🦄

Another option is to express identity using the form name@domain, instead of a stringified UID/GID scheme, for file metadata setting and listing 🍓.

File access: This is the same as in Section 5.1.

Metadata setting and listing: The NFSv4 server will need a name service for the wire-to-disk mappings, so it can map between the on-the-wire name@domain syntax and the on-disk UID/GID representation 🔄. The NFSv4 server will often 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 not an issue in a stand-alone NFSv4 Domain deployment, because the NFSv4 Domain is known to the NFSv4 server and can be combined with the login name to form the name@domain syntax after the name service call returns 🫶.

5.3. RPCSEC_GSS with Name@domain 🔐

RPCSEC_GSS uses Generic Security Service Application Program Interface (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, they look like principal@REALM. Sometimes authorization context information is delivered along with authentication, but you can't count on that 😭. Authorization context information that isn't delivered with authentication has timely update considerations (i.e., generally it's not possible to get a timely update) 🙃. So file access decisions need a wire-to-disk mapping of the GSS principal to a UID, plus an auth-to-authz mapping to get the list of GIDs as the authorization context 💅.

Metadata setting and listing: This is the same as in Section 5.2.

6. Multi-Domain Constraints to the NFSv4 Protocol 🌍

Joining NFSv4 Domains under a single file namespace puts a bit of a squeeze on NFSv4 administrative freedom 🥺. In this section, we describe the required constraints 📋.

6.1. Name@domain Constraints 💎

NFSv4 uses a syntax of the form "name@domain" (see Section 5.9 of [RFC7530]) as the on-the-wire representation of the "who" field of an NFSv4 access control entry (ACE) for users and groups 🎯. This design adds a layer of indirection that lets NFSv4 clients and servers with different internal representations of authorization identity interoperate, even when they're referring to authorization identities from different NFSv4 Domains 🦋.

Multi-domain-capable sites need to meet the following requirements so NFSv4 clients and servers can map between name@domain and internal representations reliably 🔍. Some of these constraints are basic assumptions in NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661], but they need to be clearly stated for the multi-domain case 📣.

  • The NFSv4 Domain portion of name@domain MUST be unique within the multi-domain namespace. See [RFC5661], 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 NFSv4 Domain.
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. 🚨

6.1.1. NFSv4 Domain and DNS Services 🌐

Here we look at how the NFSv4 Domain name relates to the DNS domain name in a multi-domain deployment 🗺️.

The definition of an NFSv4 Domain name, the @domain portion of the name@domain syntax, needs clarifying to work in a multi-domain file system namespace 🔎. [RFC5661], Section 5.9 loosely defines the NFSv4 Domain name as a DNS domain name. That loose definition is a good one, because DNS domain names are globally unique ✨. As noted 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 a single NFSv4 Domain 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, and the other NFSv4 Domains have to choose another unique NFSv4 Domain name 😤.

6.1.2. NFSv4 Domain and Name Services 🧠

As noted in Section 6.1, each name@domain is unique across the multi-domain namespace 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 this arrangement, each NFSv4 Domain needs a single name resolution service capable of converting the names defined within the domain into the corresponding local representation 🫶💖

6.2. RPC Security Constraints 🔐

okay so [RFC5661] lays out the RPC security flavors in Section 2.2.1.1 ("RPC Security Flavors") and the big rule is this: NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 🫶 But implementing it isn't the same as having to use it, so you're not stuck with it. Other flavors, like AUTH_NONE and AUTH_SYS, MAY be implemented too. ✨

The underlying RPCSEC_GSS GSS-API [RFC2203] security mechanism in a multi-domain namespace is REQUIRED to use a method of cross NFSv4 Domain trust. This means a principal from a security service in one NFSv4 Domain can get authenticated in another NFSv4 Domain, as long as that domain uses a security service with the same security mechanism. Kerberos is an example of a security service that does this. 🔥

AUTH_NONE [RFC5531] is lowkey useful in a multi-domain deployment. It gives universal read-only access to public data with no credentials needed. 🌸

AUTH_SYS [RFC5531] is giving host-based authentication. The weakly authenticated host (the NFSv4 client) claims the user's authorization identities using small integers, uidNumber and gidNumber [RFC2307], as the user and group identity representations. 🙈 Here's the catch: this authorization ID has no domain component, so AUTH_SYS can only be used in a namespace where every NFSv4 client and server shares a name service as described in [RFC2307]. A shared name service is required because the uidNumbers and gidNumbers get passed in the RPC credential, and AUTH_SYS has no negotiation of namespace. 💀 Collisions can happen if multiple name services are used, so AUTH_SYS MUST NOT be used in a multi-domain file system deployment. Not me getting that close to a collision. 😭

6.2.1. NFSv4 Domain and Security Services 👑

As noted in Section 6.2 about AUTH_NONE, multiple NFSv4 Domain security services are RPCSEC_GSS based. The most commonly deployed one is the Kerberos 5 security mechanism. As of this writing, it's the only one deployed, so it's the main character. 🧚

A really common setup is a single Kerberos 5 security service per NFSv4 Domain, where the upper case NFSv4 Domain name is used as the Kerberos 5 REALM name. 🎀

Multiple security services per NFSv4 Domain are allowed, but that brings the need to map multiple Kerberos 5 principal@REALMs to the same local ID. 🦋 The methods for doing that are beyond the scope of this document, so that's a problem for another day. 💅

7. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment 🌈

okay, so in this section we revisit the stand-alone NFSv4 Domain deployment examples from Section 5 and check what's stopping them from joining an NFSv4 multi-domain deployment. 👀

Here's the tea: because all on-disk identities in a stand-alone NFSv4 Domain belong to the same NFSv4 Domain, those deployments have no need to export multi-domain-capable file systems. ✨ If a stand-alone setup wants to join a multi-domain deployment, all three examples from Section 5 would need to export multi-domain-capable file systems. 🍓

The first stand-alone example (described in Section 5.1) is a no-go for multi-domain deployment. It uses AUTH_SYS and stringified UID/GIDs, and that's a dealbreaker. 💀

The second example (described in Section 5.2) does use the name@domain syntax, which is the vibe. But it still uses AUTH_SYS, and that rules it out of a multi-domain deployment. 😭

The third example (described in Section 5.3) can join a multi-domain namespace deployment, but only if:

  • The NFSv4 Domain name is unique across the namespace.
  • All exported file systems are multi-domain capable.
  • A secure method is used to resolve the remote NFSv4 Domain principal's authorization information from an authoritative source.

Being the one that can actually level up is so iconic. 👑

8. Resolving Multi-Domain Authorization Information 🔍

okay so when an RPCSEC_GSS principal wants to access files on an NFSv4 server, the server SHOULD, after authenticating the principal, get the principal's authorization context information in a secure manner from an authoritative source. The name service in the principal's NFSv4 Domain is a good example. 🫶

In the stand-alone NFSv4 Domain case, the principal is accessing files on an NFSv4 server in their home NFSv4 Domain. The server administrator knows the local policies and methods for getting the principal's authorization information, plus the mappings to the local representation of identity from an authoritative source. For example, the admin can set up secure access to the local NFSv4 Domain name service. 🔐

In the multi-domain case, a principal is accessing files on an NFSv4 server that is not in their home NFSv4 Domain. The NFSv4 server may be required to contact the remote name service in the principal's NFSv4 Domain. In this case, there is no assumption of:

  • Remote name service configuration knowledge.
  • The syntax of the remote authorization context information presented to the NFSv4 server by the remote name service for mapping to a local representation.

There are several ways the NFSv4 server can get the NFSv4 Domain authoritative authorization information for a remote principal from an authoritative source. Detailing those methods is beyond the scope of this document, but here are some general ones. 🦋

  1. A mechanism-specific GSS-API authorization payload with credential authorization data, like a "privilege attribute certificate" (PAC) [PAC] or a "principal authorization data" (PAD) [GEN-PAC]. This is the preferred method, and it's the MVP because the payload arrives as part of GSS-API authentication. It doesn't need any knowledge of the remote authoritative service configuration, and it has a well-known syntax. 👑
  2. When the local and remote NFSv4 Domain name services have a security agreement plus regular update data feeds, the NFSv4 server's local NFSv4 Domain name service can be authoritative for principals in the remote NFSv4 Domain. In this case, the NFSv4 server queries its local NFSv4 Domain name service just like it does for a local domain principal. This does require detailed knowledge of the remote NFSv4 Domain name service for the update data feeds, but the authorization context information is in the same form as a query for a local principal. ✨
  3. An authenticated direct query from the NFSv4 server to the principal's NFSv4 Domain authoritative name service. This requires the NFSv4 server to have detailed knowledge of the remote NFSv4 Domain's authoritative name service, and detailed knowledge of the syntax of the resulting authorization context information. That's a lot of homework, bestie. 📚

9. Security Considerations 🛡️

this RFC talks about security all throughout. All the security considerations of the relevant protocols apply here too: NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace Database Protocol [RFC7532], FedFS Administration Protocol [RFC7533], and FedFS Security Addendum [SEC-ADD]. Please read them. Seriously. 🙏

Authentication and authorization across administrative domains bring some security considerations. Most of them are handled elsewhere, but we're repeating a few here so nobody skips them: 😭

  • latency in propagation of revocation of authentication credentials
  • latency in propagation of revocation of authorizations
  • latency in propagation of granting of authorizations
  • complications in establishing a complete authorization context for users of a foreign domain (only parts may be available to servers)
  • privacy considerations in a federated environment

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 might be tempted to assume that "realm" (or "issuer") and "NFSv4 Domain" are roughly the same thing. They are not. 🚨 Configuration and/or lookup protocols (such as LDAP) and their associated schemas are generally required to evaluate a user principal's authorization context (see Section 8). In the simplest scheme, a server has access to a database that maps all known principal names to user names, and the authorization context can then be evaluated using operating system interfaces that deal in user names instead of principal names. 🧠

Clients may also need to evaluate a server's authorization context when they use labeled security [RFC7862]. For example, they might need to check whether the server is authorized to handle content at a given security level for the given client process subject label. 🏷️

When the server accepts user credentials from more than one realm, it's really important to remember that the server must verify that the client it's talking to has a credential for the name the client presented to the server, and that the credential's issuer (that is, its realm) is allowed to issue it. Usually the security mechanism handles the service principal realm authorization function, but the implementor should check this anyway. 💅 No skipping this one, periodt. 💀

10. References 📖

10.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
           <http://www.rfc-editor.org/info/rfc1034>.

[RFC1813]  Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
           Version 3 Protocol Specification", RFC 1813,
           DOI 10.17487/RFC1813, June 1995,
           <http://www.rfc-editor.org/info/rfc1813>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
           Specification", RFC 2203, DOI 10.17487/RFC2203, September
           1997, <http://www.rfc-editor.org/info/rfc2203>.

[RFC2743]  Linn, J., "Generic Security Service Application Program
           Interface Version 2, Update 1", RFC 2743,
           DOI 10.17487/RFC2743, January 2000,
           <http://www.rfc-editor.org/info/rfc2743>.

[RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
           Version 5 Generic Security Service Application Program
           Interface (GSS-API) Mechanism: Version 2", RFC 4121,
           DOI 10.17487/RFC4121, July 2005,
           <http://www.rfc-editor.org/info/rfc4121>.

[RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
           Protocol (LDAP): The Protocol", RFC 4511,
           DOI 10.17487/RFC4511, June 2006,
           <http://www.rfc-editor.org/info/rfc4511>.

[RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
           "Network File System (NFS) Version 4 Minor Version 1
           Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
           <http://www.rfc-editor.org/info/rfc5661>.

[RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File System
           (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
           March 2015, <http://www.rfc-editor.org/info/rfc7530>.

[RFC7862]  Haynes, T., "Network File System (NFS) Version 4 Minor
           Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
           November 2016, <http://www.rfc-editor.org/info/rfc7862>.

10.2. Informative References ✨

okay so these are the bonus reads, bestie 📚 they're not required to get the core picture, but they're the receipts behind the vibes 💅

Acknowledgments 🫶

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. 🙌✨

Authors' Addresses 🎀

William A. (Andy) Adamson NetApp

Email: andros@netapp.com

Nicolas Williams Cryptonector

Email: nico@cryptonector.com

and that's the whole spec, bestie!! 🌈🦋 you made it through the entire thing, you're literally iconic 👑

📦 where this page comes from