NFSv4 Multi-Domain Access
draft-adamson-nfsv4-multi-domain-access-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 29, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The Network File System, version 4 (NFSv4) uses a representation of identity that allows the use of users and groups from multiple, distinct administrative domains, and NFSv4 allows the use of security mechanisms that authenticate principals from multiple, distinct administrative domains. This document describes methods by which NFSv4 clients and servers can handle principals, users, groups from multiple administrative domains.

Table of Contents

1.  Requirements notation
2.  Introduction
3.  Background
4.  Terminology
5.  Local Representations of Global Identity
    5.1.  Storing Name@Domainname
    5.2.  Storing Remote-ID@Domainname
        5.2.1.  Storing Remote-ID@Domain-ID
        5.2.2.  ID Mapping
        5.2.3.  Use of Name Services
6.  GSS-API Principal-to-NFSv4 Authorization Context
    6.1.  Using GSS-API Naming Extensions
        6.1.1.  Using a PAC
    6.2.  Mapping Principal Names to Usernames
        6.2.1.  Using a Name Service to Map Principal Names to User Accounts
    6.3.  User Group Membership Determination
7.  LDAP Schema Extensions for Multi-Domain NFSv4
    7.1.  LDAP Attribute for Principal Name to Local ID Translation
8.  Name Resolution
    8.1.  Using LDAP Caching Proxies
    8.2.  LDAP Schema Extensions for ID Mapping
9.  Multi-Domain Access Summary
10.  Security Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses

1.  Requirements notation

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

The NFS Version 4 (Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “Network File System (NFS) version 4 Protocol,” April 2003.) [RFC3530] protocol enables the construction of a distributed file system which can join NFSv4.0 or NFSv4.1 (Shepler, S., Eisler, M., and D. Noveck, “NFS Version 4 Minor Version 1,” December 2008.) [I‑D.ietf‑nfsv4‑minorversion1] servers from multiple administrative domains, each potentially using separate name resolution services and separate security services, into a common multi-domain name space.

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 information about client principals (such as username, group memberships, and so on) and file metadata related to authorization, such as a file's access control list (ACL).

Authentication in NFSv4 occurs at the the RPCSEC_GSS (Eisler, M., Chiu, A., and L. Ling, “RPCSEC_GSS Protocol Specification,” September 1997.) [RFC2203] layer where GSS-API mechanisms (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) [RFC2743] are used to authenticate users on NFSv4 clients to NFSv4 servers, and to provide security services such as confidentiality and integrity protection for the protocol's messages. The NFSv4 protocol specifies no particular representation for authentication identities as these are entirely mechanism-specific

Authorization for file object access is done at the NFSv4 protocol layer (i.e., above the RPCSEC_GSS layer), on the server side, based on an authenticated client principal's authorization context and the authorization meta-data of the file system objects that the client wishes to access. File authorization meta-data is set and retrieved in the NFSv4 RPC (Srinivasan, R., “RPC: Remote Procedure Call Protocol Specification Version 2,” August 1995.) [RFC1831] layer, specifically via the object's owner, owner_group and acl, dacl and sacl attributes (the last three being ACLs). ACLs are lists of ACL entries (ACEs). Each ACE has a "who" field identifying a subject to whom some permision is granted or denied. The owner and owner_group attributes and the who ACE field, all reference users and groups. On the wire, the protocol represents users and groups as strings of characters with this form: name@domain, where <name> is a user or group name, and <domain> is a the name of an administrative domain, more specifically a DNS (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1034] domainname.

NFSv4 server implementations usually do not, and really ought not, store authorization identities on disk in the same form as is used on the wire. The reason is that users' and groups' names change all too often, while searching for and updating file authorization meta-data after a user/group name change is not trivial, particularly in a global namespace spanning multiple administrative domains.

NFSv4 servers therefore must perform two kinds of mappings: a) authentication identity to authorization context (a principal's user ID, group memberships, etcetera), and on-the-wire authorization identity representation to on-disk authorization identity representation. Many aspects of these mappings are entirely implementation-specific, but some require name resolution services, and in order to interoperate servers must use such services in compatible ways. Many implementations are limited to being able to represent users and groups from a single domain.

In this document we address both of those kind of mappings, describing possible implementation strategies, and specifying a name service for interoperation in a global namespace [I‑D.ietf‑nfsv4‑federated‑fs‑reqts] (Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, “Requirements for Federated File Systems,” October 2009.).

3.  Background

NFSv4 uses a syntax of the form "name@domain" to represent, on the wire, the NFSv4 ACL name 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 certain requirements in order to ensure that clients and servers can map name@domain to internal representations reliably:

• name@domain MUST be unique within the DNS 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 [I‑D.ietf‑nfsv4‑minorversion1] (Shepler, S., Eisler, M., and D. Noveck, “NFS Version 4 Minor Version 1,” December 2008.) 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 AUTH_NONE security flavor can be useful to the multi-domain NFSv4 or federated name space 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] client asserts the user's authorization identities using small integers as user and group identity representations. Because of the small integer authorization ID representation, AUTH_SYS can only be used in a name space where all clients and servers share a uidNumber and gidNumber translation service. A shared translation 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 translation services are used. These and other issues are addressed in [I‑D.williams‑rpcsecgssv3] (Williams, N., “Remote Procedure Call (RPC) Security Version 3,” January 2009.) which describes a new version of RPCSEC_GSS that includes a modernized replacement for AUTH_SYS.

4.  Terminology

Identity: a way to refer to a user or group.

Principal: an entity that is authenticated by RPCSEC_GSS (usually, but not always, a user; rarely, if ever, a group; sometimes a host).

Authorization context: the set of user and group IDs, privileges, labels, and other items relevant to authorization, corresponding to a subject (user or principal).

Domain-local ID: Most installations assign numeric, local identifiers to users and groups, using a namespace local to their domain. We call this a domain-local ID.

Local representation of identity: an item such as a POSIX user IDentifier (UID) or group ID (GID), or a Windows Security IDentifier (SID), or other such local representation of a user or a group of users.

Global representation of identity: a tuple consisting of a domain identifier (possibly the domain's name itself) and a domain-local user/group ID. We do not propose a standard global representation of identity, but the concept is useful.

Domain: a set of users and computers administered by a single entity, and identified by a DNS domain name.

POSIX IDs: small non-negative integers (typically 0..2^31 or 0..2^32) identifiers. The namespace of user IDs (UIDs) is distinct from the namespace of group IDs (GIDs).

Windows SIDs: an identifier of security entities, including users and groups. The form of a SID is: S-1-<authority><RID_0><RID_1><RID_n> By convention some authority numbers denote security entities, identified by RID_n, local to a domain identified by RIDs 0..n-1. Domain RIDs are usually generated randomly within a "forest" of domains.

Name resolution: mapping from {domain, name} to {domain, ID}, and vice-versa via lookups. Can be applied to local or remote domains.

ID mapping: {domain-remote ID } to { domain-local ID } mappings.

Logon service: { user ID } -> { groups user is a member of, and other authorization context }

5.  Local Representations of Global Identity

Multi-domain support starts at the fileserver where local ID forms need to be able to represent global identities from both, local and remote domains. Local representation of global identity also applies to clients, particularly clients with local filesystems. There's a range of local solutions to this multi-domain ID representation problem. In this section we describe several approaches to representing a <name>@<local or remote domain> on disk. None of these approaches are REQUIRED; all are INFORMATIVE. However, conventions relating to the use of name services are NORMATIVE.

5.1.  Storing Name@Domainname

One simple approach to the multiple domain problem is the identity function applied to name@domain, with the resultant ID stored on disk.

This approach imposes a severe constraint on the administrators of these domains: user and group names must never be reused, as there is also no realistic way to keep the name@domain on disk representation up to date with user, group or domain renames and removals. Consider a remote domain's NFSv4 servers where real-time employee join/leave data may be (typically is!) considered privileged, and remote servers may not be sufficiently privileged to access it [elaborate...].

5.2.  Storing Remote-ID@Domainname

Most installations assign numeric, local identifiers to users and groups, using a namespace local to their domain. We call this a domain-local ID. We can then construct a global identity form consisting of a domain ID and a domain-local user/group ID.

The user or group renaming issue can be addressed by using a global identity form where domain-local IDs are required. I.e., use name resolution to lookup name@domain to find the ID local to the domain, and join the ID with the result of the identity function applied to the domain. This function still has a renaming problem with respect to DNS domain renames, but that is a realistically manageable problem.

5.2.1.  Storing Remote-ID@Domain-ID

The DNS domain renaming issue in the previous section can be addressed by assigning and publishing a unique ID to each DNS domain. I.e., use name resolution to lookup name@domain to find some ID local to the domain, lookup the domain ID and store <remote-ID,domain-ID>.

5.2.2.  ID Mapping

Many file systems exported by NFS only store 32-bit user and group IDs which limit their ability to utilize the on disk representation described in Section 5.2 (Storing Remote-ID@Domainname). Such systems may need to use an additional service to map between <remote users, local user IDs> and <remote groups, local group IDs>. We call this an "ID mapping service".

The use of an ID mapping service is not strictly necessary if the system operates on IDs large enough such that <user/group ID, domain ID> can be encoded into a native ID. However, a large class of operating systems, those which are Unix or Unix-like operating systems, such as Solaris and Linux, use 32-bit UIDs and GIDs in many services and therefore need mapping for backwards compatibility reasons.

One example of such a service is to keep a local or distributed database for dynamically assigning a local 32 bit ID to every <ID>@<domain-ID>, or one could do that only for remote domains, reserving only a small part of the local 32-bit ID namespace for remote domains' users/groups.

The remote ID and remote domain are then used as inputs to a name resolution service which contacts the remote domain name service to resolve the remote name.

5.2.3.  Use of Name Services

Such file systems often use a distributed directory service for assigning domain local 32 bit IDs to remote users and groups. The Network Information Service (Sun Microsystems, “System and Network Administration,” March 1990.) [NIS] and the Lightweight Directory Access Protocol (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.) [RFC4511] are the two broadly used distributed directory service protocols used for this purpose. LDAP is used instead of NIS in environments where scale and security are issues. Section 7 (LDAP Schema Extensions for Multi-Domain NFSv4) expands the LDAP protocol to include mappings between name@domain and local user and group IDs.

Support for LDAP [RFC4511] (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.) with the RFC2307 schema [RFC2307] (Howard, L., “An Approach for Using LDAP as a Network Information Service,” March 1998.) is REQUIRED.

5.2.3.1.  Using LDAP with RFC2307 Schema

Name resolution consists of searches with scope 'sub', a base DN corresponding to a domain (more on this below) and a filter of either of these forms, with matching on objectClass being optional:

• ((objectClass=posixAccount)(uid="<username>))
• ((objectClass=posixGroup)(cn="<groupname>))
• ((objectClass=posixAccount)(uidNumber="<UID>))
• ((objectClass=posixGroup)(gidNumber="<GID>))

The base DN should be formatted from a domain's DNS domainname as follows. First format the domainname as a string, then strip the trailing dot ('.'), if any, then replace all dots ('.') with ",DC=", then prepend "DC=" to the resulting string. For example, foo.bar.example becomes "DC=foo,DC=bar,DC=example". This convention is REQUIRED to be implemented. Domains with base DNs that do not match this convention may be used, but their domainname-to-base-DN mappings must be published where NFSv4 clients and servers may find them; we provide no conventions for publishing such mappings. Implementations MUST support the use of LDAP referrals to find LDAP servers authoritative for any given base DN.

For example, to resolve a user named joe@foo.bar.example to a remote ID a system would do an LDAP search with DC=foo,DC=bar,DC=example as the base DN, scope='sub' and with a filter of ((objectClass=posixAccount)(uid="<username>)) looking for the uidNumber attribute.

5.2.3.2.  Using Active Directory LDAP

[Add text describing searches by which to resolve name@domain to SIDs and vice versa.]

5.2.3.3.  Resolving Domain Names to Domain IDs

[Add text on mapping domainnames to domain IDs.]

5.2.3.4.  LDAP DIT Construction for a Federated Namespace

[Add text on federated namespace LDAP DIT construction, and caching services.

6.  GSS-API Principal-to-NFSv4 Authorization Context

In order to authorize user access to files, the NFSv4 server must map the RPCSEC_GSS client principal name or the underlying GSS-API security context to local security information including a local ID, a set of group IDs and other user privileges. This security information is contained in an "authorization context" (also called an "access token" in some systems).

Authorization contexts consist of:

1. UserID: This field contains the principal's global ID and/or local ID mapping thereof, and the name@domain form thereof.
2. PrimarygroupID: This field contains the global ID and/or local ID mapping thereof for the principal's primary group, and the name@domain form thereof.
3. Groups: This field contains an array of group IDs for the groups that the user is a member of, in global ID form and/or local ID mappings thereof, as well as in name@domain name@domain forms.
4. As yet unspecified field(s) for privileges and authorizations granted to the principal, if any.
5. As yet unspecified field(s) for other privilege information such as the multi-level security label range/set of the principal.
6. Implementation-specific items relevant to authorization.

The RPCSEC_GSS client principal authorization context determination may be mechanism-specific, and even operating system-specific, but from the NFSv4 server's point of view, it is a generic facility. Below we describe several methods of authorization context determination.

The NFSv4 authorization context SHOULD be obtained via discrete GSS-API name attributes [I‑D.ietf‑kitten‑gssapi‑naming‑exts] (Williams, N. and L. Johansson, “GSS-API Naming Extensions,” March 2010.) corresponding to the above elements of authorization contexts. URIs for those attributes are TBD. If the named attribute interface is not available, or the attributes are not available, other means of determining a principal's authorization context SHOULD be used, such as those described in Section 6.1 (Using GSS-API Naming Extensions) and Section 6.2 (Mapping Principal Names to Usernames).

6.1.  Using GSS-API Naming Extensions

Authorization context information can sometimes be obtained from the credentials authenticating a principal; the GSS-API represents such information as attributes of the initiator prinicpal's name. For example: Kerberos 5 [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.) has a method for conveying "authorization data", both client-asserted as well as KDC-authenticated authorization data, and one KDC implementation uses this feature to convey a "privilege attribute certificate" (PAC) listing the principal's user and group "security identifiers" (SIDs). PKIX [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,” May 2008.) certificates allow for extensions that could be used similarly.

6.1.1.  Using a PAC

The Windows operating system uses something called a "PAC", which contains a user Security IDentifier (SID) and a list of group SIDs. Some Kerberos Key Distribution Centers (KDCs), notably Windows KDCs, issue Kerberos Tickets with PACs as Kerberos authorization data. When a client principal is authenticated using such a ticket, the server SHOULD extract the PAC from the client's ticket and map, if need be, the SIDs in the PAC to local ID representations.

The authorization context information in a PAC can be considered a single, authenticated, discrete GSS-API name attribute, in which case the server must parse it into its individual elements.

[Add references.]

6.2.  Mapping Principal Names to Usernames

If suitable and sufficient authenticated name attributes for the client principal are not available, then the server may try to map the client principal name to a local notion of user account, and then lookup that user account's authorization context information through name service lookups.

One simple method for Kerberos principal-to-username mapping is to first apply an algorithmic or table-based Kerberos client principal realm name to domain name mapping, then a client principal name to username mapping. Finally, the server can look up the user's authorization context using the user's domain's name services.

A trivial Kerberos realm-name-to-domainname mapping consists of case-folding the realm name to lower-case. [Add notes about internationalization.] Servers MUST implement this mapping as an option, possibly as a default option.

A trivial Kerberos principal name to username mapping for 1-component principal names, is the identity function. Servers MUST implement this mapping as an option, possibly as a default option.

6.2.1.  Using a Name Service to Map Principal Names to User Accounts

Name services such as the Solaris gsscred database where the local identity is looked up in a database keyed by the GSS exported name token, or LDAP with the extension described in Section 7.1 (LDAP Attribute for Principal Name to Local ID Translation), can be used to map principal names to user accounts.

6.3.  User Group Membership Determination

[Add text.]

7.  LDAP Schema Extensions for Multi-Domain NFSv4

7.1.  LDAP Attribute for Principal Name to Local ID Translation

The gSSPrincipal objectclass allows for the use of the gSSAuthName attribute described in the following section.

                     objectclass ( 1.3.6.1.4.1.250.10.7
                     NAME 'gSSPrincipal'
                     DESC 'GSS Principal Name'
                     SUP  posixAccount
                     MAY ( gSSAuthName ) )

Here we present a new LDAP attribute that provides a method for the translations between a local ID and (multiple) GSS-API security principals, used as described in Section 6.2 (Mapping Principal Names to Usernames).

The gSSAuthName attribute stores a user's GSS-API principal name in exported name token form (see [RFC2743] (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.)).

                        attributetype ( 1.3.6.1.4.1.250.10.6
                        NAME ( 'gSSAuthName')
                        DESC 'GSS-API exported principal name
                        exported token'
                        EQUALITY bitStringMatch
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.6)

8.  Name Resolution

As noted in Section 5.2.1 (Storing Remote-ID@Domain-ID), most local representations require a name service to perform ID to name translations. Implementations are REQUIRED to support the use of LDAP as a name service, relying on LDAP referrals for federated namespace construction.

Note that in a topographically widely separated set of domains the need to do name service lookups in various domains' name services may prove brittle, resulting in non-deterministic server behavior (e.g., sometimes a user can access share, sometimes they cannot; sometimes they appear to be members of some group, sometimes they do not). To avoid this, site administrators may wish to maintain local caches of remote domains' name services such that LDAP searches for users/groups in remote domains can be satisfied locally for some set of key attributes (such as naming and ID attributes), with referrals used in all other cases.

Domains in a federated namespace may provide each other with LDAP LDIF delta feeds by which to maintain cached LDAP contents up to date.

8.1.  Using LDAP Caching Proxies

Many sites use a distributed name service such as Lightweight Directory Access Protocol (Sermersheim, J., “Lightweight Directory Access Protocol (LDAP): The Protocol,” June 2006.) [RFC4511] for distributing system configuration data and providing name translation. RFC2307 (Howard, L., “An Approach for Using LDAP as a Network Information Service,” March 1998.) [RFC2307] defines the LDAP posixAccount object class and an associated set of attributes used to resolve account information such as user IDs to login names and group IDs to group names.

The LDAP posixAccount schema can be used to map between the multiple domain local ID and the NFSv4 name@domain form by adding remote domain DN hierarchies to the local LDAP name service.

An LDAP service set up in this way is a caching proxy because it caches remote domain information. The DN hierarchy structure has the advantage of aiding delta feeds from remote domains because each domain's information is in it's own DN subtree.

An example follows that shows the DN hierarchy for sample.com's LDAP service.

                        dc=com/
                        dc=sample/
                        ou=People/
                        [all the rfc2307 people entries for
                        sample.com]
                        uid=bob

                        dc=edu/
                        dc=university/
                        ou=People/
                        [all the rfc2307 people entries for the
                        remote domain university.edu]
                        uid=alice

An LDAP hierarchy for two domains, the local sample.com domain and the remote university.edu domain.

More detail on two entries from sample.com's LDAP service:

                        dn: uid=bob,ou=People,dc=sample,dc=com
                        objectClass: top
                        objectClass: person
                        objectClass: organizationalPerson
                        objectClass: inetorgperson
                        objectClass: gSSPrincipal
                        cn: Bob B. Bar
                        sn: Bar
                        uidNumber: 5989
                        gidNumber: 100
                        gSSAuthName: <bob@SAMPLE.COM>
                        gSSAuthName: <bob@SAMPLE-ENG.COM>

                        dn: uid=alice,ou=People,dc=university,dc=edu
                        objectClass: top
                        objectClass: person
                        objectClass: organizationalPerson
                        objectClass: inetorgperson
                        objectClass: gSSPrincipal
                        cn: Alice A. Answer
                        sn: Answer
                        uidNumber: 5990
                        gidNumber: 100
                        remoteID: 1234
                        gSSAuthName: <alice@UNIVERSITY.EDU>

Figure 2 shows two entries in the sample.com LDAP service also shown in Figure 1. One entry is for a local user Bob and one entry for a remote user alice. The mappings of the local uidNumber to an NFSv4 name@domain are also shown where the NFSv4 name@domain is expressed as a concatenation of the posixAccount uid attribute and the DN domain.

Figure 2 also demonstrates the use of the gSSAuthName and remoteID attributes. User bob@sample.com has a principal in both the SAMPLE.COM and the SAMPLE_ENG.COM Kerberos realms, and both map to his uidNumber. User alice@university.edu has a principal in the UNIVERSITY.EDU Kerberos realm, and a remoteID of 1234 which is her uidNumber in the university.edu name service.

8.2.  LDAP Schema Extensions for ID Mapping

[Add text.]

9.  Multi-Domain Access Summary

File systems exported by the NFSv4 file server need to be able to represent user and group IDs from multiple domains.

The RPCSEC_GSS client presents the GSS principal to the NFSv4 server which maps the GSS principal into the principal's authorization context via methods described in Section 6 (GSS-API Principal-to-NFSv4 Authorization Context). The authorization context information is used to determine file access. Depending on the local representation as described in Section 5 (Local Representations of Global Identity), ID mapping and/or name resolution may be required to translate between IDs and names contained in the authorization context.

An NFSv4 SETATTR or GETATTR with an acl attribute presented to the NFSv4 server may also require ID mapping and/or name resolution to translate between the name@domain and the local file system ID.

10.  Security Considerations

Yet to be determined

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses