NFSv4 Working Group Nicolas Williams INTERNET-DRAFT Sun Microsystems June 2003 A Method and Protocol for Mapping User and Group names from Multiple Domains to Internal Security Identifiers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 draft expires on December 1st, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document presents a model for mapping the domain-qualified user and group names used in the Network File System version 4's Access Control List (ACL) entries (ACEs) to internal identifiers such as POSIX UIDs and GIDs, as well as reverse mappings as well as a protocol for effecting such mappings in a consistent way across a server cluster, site, or entire domain. The main goals of this model and protocol are to allow the use of user and group names from multiple domains to be used in POSIX environments as well as enabling multi-protocol fileserver implementations which must support the use of a variety of user and group identifiers. N. Williams [Page 1] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 Table of Contents 1 Introduction 1.1 Glossary 2 Mapping Model 3 SID Mapping Protocol 3.1 SID Mapping Domains 3.2 Procedures of the SID Mapping Protocol 3.2.1 The NULL Procedure 3.2.2 Determine Server Support for a Given Mapping Domain 3.2.3 Negotiate RPCSEC_GSS Security Triples 3.2.4 Lookup Mappings by ESID 3.2.5 Lookup Mappings by QISID 3.2.6 Lookup Mappings by MISID 3.2.7 Map Login and Principal Names to ESID Lists 3.3 Authentication and RPCSEC_GSS Security Triple Negotiation 3.4 Relation of SID Mapping Protocol to Directories 3.4.1 Rationale Using an RPC Protocol Instead of Directory Schemas 3.5 High Availability of SID Mapping Services 3.6 Protocol Extensibility 4 Mapping Login Names to SID Mapping Lists 4.1 Mapping GSS-API Contexts 5 ONC RPC Protocol Definition 6 Kerberos V Authorization-Data for ESID List Lookup Optimization 7 Operational Considerations 7.1 Locating Mapping Services 7.2 Mapping Consistency with Home Domain 7.3 High Availability of Mapping Service 8 Pseudo-code 8.1 Pseudo-code for MAPPER_PROG Clients 8.2 Pseudo-code for MAPPER_PROG Servers 9 Security Considerations 10 References 10.1 Normative References 10.2 Informative References Conventions used in this document 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]. 1 Introduction Operating systems such as Linux, BSD and Solaris have a small, flat namespace of internal identifiers for security entities such as users or groups. Even small internetworks usually have multiple domains each of which defines its own users and groups names to POSIX UIDs and GIDs. Generally, users from one domain cannot login to other domains (where authorization would be granted) without having a local (stub) account in each such other domain; this problem applies as much to console logins as to NFS access (specifically NFS ACLs) - N. Williams [Page 2] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 generally user and group names are not even qualified with a domain name in such environments. The larger the internetwork of domains, the harder it is to automate creation and maintenance of stub accounts through meta-directories or directory synchronization. This document defines a model for automatically mapping non-flat user and group namespaces to flat internal identifier namespaces. This model assumes that no consistency in mappings is required across hosts in one domain, but because this assumption is expected to be generally incorrect this document also defines a protocol which can be used to implement this mapping model across multiple hosts (e.g., a server cluster, a site, an entire domain). User and group names are generally referred to herein as External Security IDentifiers, or ESIDs. POSIX UIDs, GIDs and Windows SIDs are generally referred to herein as Internal Security IDentifiers, or ISIDs. ISIDs qualified with a domain identifier are referred to herein as Qualified Internal Security IDentifiers, or QISIDs. ISIDs from flat internal identifier namespaces produced by the model and/or protocol are herein referred to as Mapped Internal Security IDentifiers, or MISIDs. This model and protocol also facilitates the implementation of multi- protocol fileservers that need to reference multiple kinds of SIDs on the wire. The mapping model can fairly be described as "automatic, on-demand allocation of mapped identifiers." The protocol merely extends a given "mapping domain" to all clients of a mapping service for that mapping domain and provides some additional services. Areas of particular interest, from operations and security points of view are: ESID reuse, ISID reuse, DoS attacks where a malicious or wayward client attempts to exhaust the internal identifier namespaces for a server or domain or otherwise slow down servers by causing too many mapping operations, user/group enumeration attacks. 1.1 Glossary Some familiarity of the reader with NFSv4 [RFC3530], CIFS [CIFS] and RPCSEC_GSS [RFC2203] is expected. Some terms defined or heavily used in this document are defined in this partial glossary to help readers: - Security IDentifier (SID) A user or group name, or POSIX UID or GID or Windows SID. Not to be confused with the term from Windows. - External SID (ESID) N. Williams [Page 3] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 External Security IDentifier. The NFSv4 representation of user and group names (the non-special values of the "who" field of NFSv4 ACEs). The term "ESID" is not used in RFC3530; it was invented for this document. ESIDs are expected not to be reused for a configurable amount of time so as to make it safe to cache ESID to ISID mappings. - Internal SID (ISID) Internal Security [entity] IDentifier. Refers to the internal identifiers used to represent references to users and groups on disk on file systems. POSIX UIDs and GIDs are ISIDs, as are Windows RIDs. The term "ESID" is not used in RFC3530; it was invented for this document. - Qualified ISID (QISID) An ISID associated with a domain identifier. Windows SIDs are QISIDs. POSIX UIDs and GIDs qualified with the name of the domain of their provenance are QISIDs. Every user and group is expected to have at least one QISID. The QISIDs of a user or group are expected not to change. - Mapped ISID (MISID) POSIX UIDs and GIDs mapped as per the model and/or protocol presented herein are termed MISIDs. MISIDs are qualified with the name of their mapping domain. - Mapping domain The set of ESID-to-MISID and QISID-to-MISID mappings used by a the clients of the same mapping domain. 2 Mapping Model The mapping model is quite simple: map ESIDs and QISIDs to ISIDs automatically and on-demand to the next available ISID. This model has been implemented by Samba since version 2.2. However, Samba only needs to establish mappings of Windows SIDs to POSIX UIDs/GIDs because CIFS references SIDs on the wire, whereas NFSv4 implementations need to establish mappings of user and group names, as used on the wire in NFSv4, to internal identifiers (such as POSIX UIDs and GIDs). This difference is very important because, while the ISID of a user or group never changes, the ESID of a user or group sometimes does (such as when users get renamed, because of the use of new naming conventions or because of major life events such as marriage, divorce, legal name change, etc..., or even just to correct spelling errors). The fact that ESIDs can change or even be reused N. Williams [Page 4] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 (in some environments) is something that the mapping model and protocol have to cope with to avoid security breaches; specifically, ESIDs are not to be used as permanent indexes to a mapping database or cache. Typically ESID/QISID mapping would be performed as follows: Check if a mapping already exists for a given input ESID or QISID, if so return the existing mapping, else lookup the QISID(s) corresponding to the input ESID and verify that the entity exists and generate a new mapping by assigning the next available ISID of the applicable type and recording the QISID(s)<->MISID mappings. ESIDs can be used as indexes into the mapping database within a limited timeframe during which such ESIDs are expected not to be reused. ESID renaming and reuse is handled as follows: first, the ISIDs of users and groups are expected not to change, second, users and groups are expected to have at least one QISID each such that a QISID uniquely and permanently identifies a user/group, third, user and group names are required not to be reused for configurable period of time such that ESIDs can be used for some time as indexes into the mapping database. ISID reused MUST NOT be allowed. Mapping services SHOULD NOT map ESIDs and QISIDs from domains not "trusted." 3 SID Mapping Protocol Because in practice NFSv4 servers and even clients will need to use consistent mappings amongst themselves, and also to facilitate multi-protocol file server implementation, an ONC/RPC protocol is defined to effect ESID mapping on a network. The definition of the MAPPER_PROG protocol using the ONC/RPC syntax is given in section 6. Samba 3.0.0 beta1 introduced a protocol for mapping Windows SIDs to POSIX UIDs and GIDs using LDAP. See section 2 for a discussion of the differences between the Samba mapping model and the model presented herein. 3.1 SID Mapping Domains Each host MUST operate in at most one mapping domain. Once a host is in one mapping domain it MUST NOT be moved to another without also searching for all references on the host to MISIDs of the first mapping domain and replacing them with their equivalents from the second mapping domain. N. Williams [Page 5] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 The mapping service for a given mapping domain SHOULD map only ESIDs and QISIDs from "trusted" domains. The mapping service SHOULD verify the existence of users and groups prior to allocating MISIDs to them. The mapping service allocates new MISIDs on-demand, but MAY defer mappings of some parts of the ESID and MISID namespaces to the directory of its home domain (see Section 7.2). For example, when mapping ESIDs whose domain is the same as the mapping domain's "home domain" the mapping service could be configured to use POSIX UIDs and GIDs from its home domain's directory; for ESIDs and QISIDs from other domains the mapping service would have to allocate POSIX UIDs and GIDs from a block of UIDs and GIDs set aside for allocation to new mappings. 3.2 Procedures of the SID Mapping Protocol The ESID mapping protocol defines six (6) mandatory to implement procedures and one (1) optional to implement procedure (which MUST be present but MAY always return MAP_NOPROC to indicate that the server does not support them): - MAP_NULL - MAP_DOMAIN - MAP_SECINFO - MAP_ESID - MAP_QISID - MAP_MISID - MAP_LOGIN_NAME MAP_NULL is the traditional null procedure. MAP_DOMAIN is required for clients to determine what mapping domain is served by a mapper server. MAP_SECINFO is for RPCSEC_GSS security triple negotiation. MAP_ESID, MAP_ISID and MAP_MISID are for mapping user and group identifiers of one kind to another. MAP_LOGIN_NAME is optional. Its purpose is to map login names and GSS-API principal names to the list of QISIDs associated with them (e.g., the groups that the users belong to). All procedures other than the MAP_NULL, MAP_DOMAIN and MAP_SECINFO procedures return a status value of type "enum mapstat", with the following possible values: - MAP_OK, for success. - MAP_NO_SUBJECT, for operations where the subject to be mapped does not exist. - MAP_NO_DOMAIN - the server does not serve the mapping domain referenced in the request. - MAP_PERM_DENIED, for operations not authorized to the client. N. Williams [Page 6] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 - MAP_UNAVAIL, for when the service is temporarily unavailable. - MAP_NO_MAP, for operations that could not be performed for any other reason. - MAP_INVAL, for requests containing invalid arguments (e.g., an invalid ESID type). - MAP_NOPROC, for unsupported operations 3.2.1 The NULL Procedure NAME MAP_NULL - Traditional NULL procedure SYNOPSIS MAP_NULL(void) -> void ARGUMENT void RESULT void DESCRIPTION This is the traditional NULL procedure. SECURITY The use of RPCSEC_GSS when calling this procedure is NOT REQUIRED. ERRORS 3.2.2 Determine Server Support for a Given Mapping Domain NAME MAP_DOMAIN - Does the server serve a given mapping domain SYNOPSIS MAP_NULL(utf8str_t) -> bool ARGUMENT utf8str_t RESULT N. Williams [Page 7] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 void DESCRIPTION Returns TRUE if the server supports the given mapping domain, FALSE otherwise. SECURITY The use of RPCSEC_GSS when calling this procedure during service discovery is NOT REQUIRED. Clients MUST call this procedure after mutually authenticating to servers. ERRORS 3.2.3 Negotiate RPCSEC_GSS Security Triples NAME MAP_SECINFO - Get server's RPCSEC_GSS security triples SYNOPSIS MAP_SECINFO(void) -> rpcsec_gss_info<> ARGUMENT void RESULT rpcsec_gss_info<> DESCRIPTION Returns the list of RPCSEC_GSS security triples supported by the server in the server's order of preference. ERRORS 3.2.4 Lookup Mappings by ESID NAME MAP_ESID - Map an ESID to the user/group's QISIDs and MISID SYNOPSIS N. Williams [Page 8] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 MAP_ESID(esid, esid_name_type, mapping_domain) -> (esid, esid_type, esid_cache_max, qisids, aisids) ARGUMENT map_esid_name_args RESULT MAP_SID_results DESCRIPTION This procedure takes an ESID type (user or group), and ESID and an ESID mapping domain and returns the user/group's associated QISIDs and MISIDs. Clients SHOULD cache the results of this procedure. One result item is the length of time, in seconds, for which the ESID is expected not to be reused; after that many seconds transpire the clients MUST forget the ESID mapping but SHOULD continue to cache the QISID/MISID associations of the ESID. ERRORS MAP_NO_SUBJECT MAP_PERM_DENIED MAP_UNAVAIL MAP_NO_MAP 3.2.5 Lookup Mappings by QISID NAME MAP_QISID - Map a QISID to its ESID and MISID SYNOPSIS MAP_QISID(qisid) -> (esid, esid_type, qisids, aisids) ARGUMENT qualified_isid_t RESULT MAP_SID_results DESCRIPTION Same as MAP_ESID, but its input is a QISID. ERRORS N. Williams [Page 9] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 MAP_NO_SUBJECT MAP_PERM_DENIED MAP_UNAVAIL MAP_NO_MAP 3.2.6 Lookup Mappings by MISID NAME MAP_MISID - Map a MISID to its QISIDs and ESIDs SYNOPSIS MAP_MISID(qisid) -> (esid, esid_type, qisids, aisids) ARGUMENT mapped_isid_t RESULT MAP_MISID_results DESCRIPTION Same as MAP_ESID, but its input is an MISID. ERRORS MAP_NO_SUBJECT MAP_PERM_DENIED MAP_UNAVAIL MAP_NO_MAP 3.2.7 Map Login and Principal Names to ESID Lists NAME MAP_LOGIN_NAME - Map a login name to a list of ESIDs SYNOPSIS MAP_LOGIN_NAME(login_name, login_name_type, client_default_domain) -> cache_time, user_sid_mappings, group_sid_mappings ARGUMENT map_login_name_args RESULT N. Williams [Page 10] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 MAP_LOGIN_NAME_results DESCRIPTION This procedure is optional. Its purpose is to map login names (including GSS-API principal names) to the sets or lists of SID mappings associated with them. The mapping service SHOULD authorize use of this procedure only by clients that are known to need this feature. For example, thin clients may not need this feature if they use file system protocols which put the responsibility of evaluating access controls on the file servers. The mapping service SHOULD construct the list of SIDs associated with a login name such that group membership in groups of the various trusted domains (including the domain of the mapping service itself) is included in the result, but also the mapping service SHOULD provide for domain- and client-specific policies as filters of SID sets built in this manner. Clients SHOULD cache the results of this procedure for a period of up to as many seconds as indicated by the server in its reply. ERRORS MAP_NO_SUBJECT MAP_PERM_DENIED MAP_UNAVAIL MAP_NO_MAP MAP_NOPROC 3.3 Authentication and RPCSEC_GSS Security Triple Negotiation This protocol REQUIRES the use of RPCSEC_GSS with mutual GSS-API authentication for all procedures except the MAP_NULL and MAP_SECINFO procedures. The AUTH_NONE security flavor MAY be used when calling the MAP_NULL and MAP_SECINFO procedures. The mapper service MUST have a GSS-API hostbased service principal (GSS_C_NT_HOSTBASED_SERVICE name type). The service name MUST be "mapper". The use of either integrity or privacy protection is REQUIRED and the use of privacy protection is RECOMMENDED. A procedure, MAP_SECINFO, is provided for clients to obtain the ordered list of RPCSEC_GSS security triples supported by the server. Negotiation of RPCSEC_GSS security triples works as follows: - Clients SHOULD call MAP_SECINFO using the AUTH_NONE RPC security flavor prior to RPCSEC_GSS GSS-API security context N. Williams [Page 11] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 establishment and SHOULD select the first security triple in the server's reply that the client supports. - Servers MUST NOT offer or accept the use of RPC_GSS_SVC_NONE. Clients MUST NOT use RPC_GSS_SVC_NONE. - Upon completion of RPCSEC_GSS GSS-API security context establishment the client SHOULD again call MAP_SECINFO and verify that the server's reply matches the reply to the MAP_SECINFO made with AUTH_NONE; if the second reply does not match the first one and if the client would have selected a different security triple given the second reply then the client SHOULD establish a new RPCSEC_GSS GSS-API security context and delete the previous one. Thus the client can detect attempted downgrade attacks. NOTE: The GSS-API does not have a concept of "domain-based principal names" - such a concept is sorely missed as GSS-API mechanisms generally support such a concept. Naming MAPPER service principal names after the mapping domain they serve would improve the security of the service where multiple mapping domains co-exist in the same Kerberos realm, for example. 3.4 Relation of SID Mapping Protocol to Directories The mapping service needs read access to the directories for all trusted domains, including permission to lookup user and group objects by internal identifiers. User and group names (ESIDs) are expected not to be reused for some time after deletion or renaming makes a name available. Each domain may specify a different length of time before ESID reuse. The longer this length of time, the longer mapper clients can cache ESID mappings, thus minimizing mapping service traffic. 3.4.1 Rationale Using an RPC Protocol Instead of Directory Schemas It should be possible to define a service that automatically allocates POSIX UIDs/GIDs to domain-qualified identifiers (e.g., Windows SIDs) through an LDAP schema and move much of the functionality of the mapping service to its would be clients. However, there are some advantages to specifying a mapping service as an RPC service: - Directory access protocol and schema independence LDAP is not the only directory protocol in current use and is not likely to be the last directory protocol deployed. Earlier directory protocols include NIS, NIS+, Hesiod and NetInfo, amongst others. Mergers and acquisitions (M&A) activity may well result in some organizations with multiple trusted domains N. Williams [Page 12] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 each running different directory protocols. The SID mapping service proxies access of trusted domains' directories for the clients, thus allowing trusted domains to run directory protocols other than those supported by the mapping service's clients. - Directory lookup efficiency By allowing mapping service clients and servers to cache SID mappings the mapping service should reduce the load on directory services. - Ease of implementation The mapping service uses the same protocol syntax and encoding as NFS, namely ONC/RPC, which means NFSv4 implementors already have the necessary tools to implement ONC/RPC protocols. 3.5 High Availability of SID Mapping Services For any mapping domain there MUST be at most one (1) active mapping service servers establishing new mappings for any one range of ESIDs in that mapping domain. Multiple mapping service servers MAY be deployed, provided that they service mapping requests from mapping caches or by proxying the request to the master mapping service server currently performing new mappings. Implementors SHOULD provide a mechanism for replication of mapping service databases and SHOULD provide a mechanism or procedure for recovering from failures of the master mapping service server. The specification of such replication and recovery protocols and procedures is beyond the scope of this document. Future versions of this protocol may provide these additional functions. 3.6 Protocol Extensibility Extensions to this protocol MUST be defined by Standards Track IETF RFCs and MUST be defined through new versions of the RPC program MAPPER_PROG. 4 Mapping Login Names to SID Mapping Lists In order to evaluate access requests against ACLs NFSv4 fileservers need to know what user(s) and groups are associated with the requester so as to compared them to the ACL entries' "WHO" values. It is possible for a given client principal to be associated with more than one user entity and more than one group entity. Servers therefore need a way to look up the user and group identifiers associated with their client principals. The MAPPER_PROG's MAP_LOGIN_NAME procedure provides a mechanism for N. Williams [Page 13] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 performing performing such lookups. It supports the following sorts of client principal names: - Unqualified (bare) login names (e.g., "janedoe"). - Login names qualified with a domain name in the same manner as NFSv4 ESIDs (e.g., "janedoe@some.domain.name"). - Exported GSS-API principal names (i.e., the result of calling GSS_Export_name() on a GSS-API name object with the GSS_C_NT_EXPORT_NAME name type). 4.1 Mapping GSS-API Contexts It may, in some cases, be possible to map GSS-API contexts to ESID lists, rather than GSS-API principals. For example, in the case of the Kerberos V mechanism for the GSS-API the Kerberos V tickets used in context establishment may contain KDC-provided "authorization data" listing the ESIDs associated with the initiator, in which case it should be possible for GSS-API acceptors to map Kerberos V GSS-API security contexts (as opposed to GSS-API principal names) to ESID lists by extracting and parsing the authorization data from initiators' Kerberos V tickets. Such a Keberos V authorization data type is described in Section 6. 5 ONC RPC Protocol Definition /* Basic typedefs */ typedef opaque utf8str_t<>; typedef int int32_t; typedef unsigned int uint32_t; typedef uint32_t seconds; /* SECINFO - more or less lifted from RFC3530 */ typedef opaque gss_mech_oid_t<>; typedef uint32_t qop_t; enum rpc_gss_svc_t {/* From RFC 2203 */ RPC_GSS_SVC_NONE = 0, /* MUST NOT be used */ RPC_GSS_SVC_INTEGRITY = 1, RPC_GSS_SVC_PRIVACY = 2 }; struct rpcsec_gss_info { gss_mech_oid_t oid; qop_t qop; rpc_gss_svc_t service; }; typedef rpcsec_gss_info rpcsec_gss_info_t<>; /* Status codes */ enum mapstat { MAP_OK = 0, /* Success */ MAP_NO_SUBJECT = 1, /* Subject of request does not exist */ N. Williams [Page 14] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 MAP_NO_DOMAIN = 2, /* Mapping domain in request not served */ MAP_PERM_DENIED = 3, /* Client not authorized for proc */ MAP_UNAVAIL = 4, /* Try again later */ MAP_NO_MAP = 5, /* Mapping not performed */ MAP_INVAL = 6, /* Invalid argument */ MAP_NOPROC = 7 /* Procedure not supported */ }; /* * Internal security entity identifier types * * There are qualified ISIDs and mapped ISIDs. * * A qualified ISID is an internal ID, here always an integer, plus * a domain ID. Windows SIDs are an example of a qualified ISID. * QISIDs permanently identify a user or group and are generally * expected not to change. * * Here only POSIX IDs (UIDs and GIDs) are mapped through automatic * allocation from blocks of available UIDs/GIDs. */ enum mapped_isid_type_t { MISIDT_POSIX_UID32 = 0, MISIDT_POSIX_GID32 = 1 }; enum qualified_isid_type_t { QISIDT_POSIX_UID32 = 0, QISIDT_POSIX_GID32 = 1, QISIDT_WINDOWS_SID = 2 }; /* Security entities come in two flavors: users and groups */ enum esid_type_t { ESIDT_USER = 0, ESIDT_GROUP = 1 }; /* Basic integer internal IDs */ typedef uint32_t uid_t; /* POSIX UID */ typedef uint32_t gid_t; /* POSIX GID */ typedef uint32_t rid_t; /* Windows RID */ /* * Qualified ISIDs (i.e., a domain ID + an integer ID local * to that domain. */ struct qualified_uid32_t { utf8str_t domain; uid_t uid; }; struct qualified_gid32_t { utf8str_t domain; gid_t gid; N. Williams [Page 15] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 }; struct win_sid_t { opaque domain<>; rid_t rid; }; union qualified_isid_t switch (isid_type_t isid_type) { case ISIDT_POSIX_UID32: qualified_uid32_t qi_uid; case ISIDT_POSIX_GID32: qualified_uid32_t qi_gid; case ISIDT_WINDOWS_SID: win_sid_t qi_sid; }; /* Mapped ISIDs */ union mapped_isid_data_t switch (isid_type_t isid_type) { case ISIDT_POSIX_UID32: uid_t m_uid; case ISIDT_POSIX_GID32: gid_t m_gid; }; struct mapped_isid_t { utf8str_t m_domain; mapped_isid_data_t m_isid; }; /* Lookups by ESIDs, QISIDs and MISIDs return this */ struct sid_mapping_t { esid_type_t sm_esid_type; /* user or group */ utf8str_t sm_esid; /* name of this user/group */ seconds sm_name_cache_max; /* Max time before * this sm_esid can be * reused; max time that * this mapping's ESID * can be cached. */ qualified_isid_t sm_qisids<>; /* QISIDs of this entity */ mapped_isid_t sm_misid; /* MISIDs of this entity */ }; /* Procedure arguments/results */ struct map_esid_args { utf8str_t esid; esid_type_t esid_type; utf8str_t mapping_domain; }; union MAP_SID_results switch (mapstat status) { case MAP_OK: sid_mapping_t results; default: void; N. Williams [Page 16] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 }; /* Login name types */ enum login_name_type_t { LT_BARE_UNAME = 0, LT_UNAME_WITH_DOMAIN = 1, LT_GSS_API_EXP_PRINC = 2 }; union login_name_t switch (enum login_name_type_t ln_type) { case LT_GSS_API_EXP_PRINC: opaque gss_exp_name<>; default: utf8str_t utf8_name; }; struct sid_list_t { seconds_t cache_time; sid_mapping_t supplemental_user_sids<>; /* First is primary */ sid_mapping_t supplemental_group_sids<>; /* First is primary */ }; struct map_login_name_args { login_name_t login_name; utf8str_t client_default_domain; /* Domain of client */ }; union MAP_LOGIN_NAME_results switch (mapstat status) { case MAP_OK: sid_list_t sid_list; default: void; }; program MAPPER_PROG { version ESID_MAPPER_VERS { void MAP_NULL(void) = 0; bool MAP_DOMAIN(utf8str_t) = 1; rpcsec_gss_info_t MAP_SECINFO(void) = 2; MAP_SID_results MAP_ESID(map_esid_args) = 3; MAP_SID_results MAP_QISID(qualified_idit_t) = 4; MAP_SID_results MAP_MISID(mapped_idit_t) = 5; MAP_LOGIN_NAME_results N. Williams [Page 17] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 MAP_LOGIN_NAME(map_login_name_args) = 6; } = 1; } = TBD; 6 Kerberos V Authorization-Data for ESID List Lookup Optimization A type of authorization data (AD) for use with Kerberos V is defined herein for carrying the list of ESIDs associated with a ticket's client principal name. This AD type is intended to allow KDCs to perform the login name to ESID list mapping and save other MAPPER_PROG clients the trouble of mapping Kebreros principal names to ESID lists and thus greatly reduce the number login name mapping requests in Kerberos V environments. This AD type's type identifier is TBD (by the IANA or the KRB WG). This AD MUST always be used encapsulated in an AD-KDC-ISSUED AD element. KDCs MAY also encapsulate either this AD or the AD-KDC-ISSUED in a AD-IF-RELEVANT AD element. Services receiving the AD MAY apply additional policy filters to its contents to produce a final ESID list for the client principal. This authorization data type is named AD-NFSv4-ESID-LIST and is encoded as the DER encoding of the following ASN.1 syntax: DEFINITIONS EXPLICIT TAGS ::= BEGIN ESID-Domain ::= UTF8String ESID-Domain-List ::= SEQUENCE OF ESID-Domain ESID-Domain-List-Index ::= INTEGER (-1..32768) -- 0 and up indicates that the domain of -- the ESID is the Nth domain from -- the domain list. -- -1 indicates that the ESID is a -- special "who" value. ESID ::= SEQUENCE { name-lhs [0] UTF8String, domain-name [1] ESID-Domain-List-Index } ESID-List ::= SEQUENCE OF ESID AD-NFSv4-ESID-LIST ::= SEQUENCE { domain-list [0] ESID-Domain-List, user-esids [1] ESID-List, -- The first user ESID is the primary -- user ESID of the login name. -- A user might have multiple user ESIDs -- associated with it; for -- example, root principals may have -- multiple user ESIDs associated N. Williams [Page 18] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 -- with them to reduce the number of -- service principals needed by diskless -- clients group-esids [2] ESID-List, -- The first group ESID is the primary -- group ESID of the login name. The -- remaining group ESIDs are the -- supplemental groups of the login. ... } END 7 Operational Considerations Availability of the mapping service is crucial to its clients. If the mapping service is unavailable its clients SHOULD act accordingly. For example, for an NFSv4 SETATTR request which references an ESID not in the file server's mapping cache, if the mapping service is unavailable then the server could, after a timeout, complete the request excluding the ACE whose "who" ESID could not be mapped then return NFS4ERR_RESOURCE or it could fail immediately and return NFS4ERR_RESOURCE. 7.1 Locating Mapping Services One mechanism for locating mapper servers is to broadcast an indirect call of the MAP_NULL or MAP_DOMAIN procedures then select the first responder that serves the mapping domain that the client wants and that properly authenticates to the client. Alternatively mapper clients can discover the mapping service through the use of DNS SRV records whose names are constructed by substituting the desired mapping into the following name templates: _mapper... _mapper.. where "" is the name of the mapping domain that the client is interested in and where "" is the client's DNS domain name or the names on the client's DNS search list. After locating a mapper server the client MUST mutually authenticate to it and SHOULD properly negotiate RPCSEC_GSS security triples (see section X). Then the client MUST call MAP_DOMAIN on the selected mapper to confirm that the server is a member of the mapping domain that the client is interested in. 7.2 Mapping Consistency with Home Domain Administrators may want mapping services to be consistent with their N. Williams [Page 19] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 home domains (the LDAP, or other directory, domain corresponding to a mapping service's mapping domain), as described in Section 3.1. To do so the administrators should setup UID and GID blocks for allocation by the mapping service to ESIDs from domains other than the its home domain and let the mapping service always defer to its home domain's directory for mapping of ESIDs in that domain and UIDs/GIDs not in the allocation block. Note that once all hosts, that reference ISIDs, in a given domain are using the mapping service it is no longer necessary to do this. 7.3 High Availability of Mapping Service Large sites may require the use of multiple mapping service replicas for scalable operation. The automatic nature of mappings means that replicas have to proxy all MAP_ESID and MAP_ISID requests that cannot be satisfied from their caches to a master mapping server. Multiple master mapping servers in one mapping domain can co-exist as long as only one mapping server can establish new mappings for any given QISID at any given time. Therefore, in order to have multiple such master mapping servers each such master should be authoritative for assigning MISIDs from a subset of the MISID namespace to QISIDs from a subset of the QISID namespace. Unavailability of the mapping service SHOULD be treated the same way as unavailability of a directory. 8 Pseudo-code This section provides sample pseudo-code. Where there are conflicts between the pseudo-code and descriptions in sections 3, 4, 5 and 6 those sections control. 8.1 Pseudo-code for MAPPER_PROG Clients [To be added.] 8.2 Pseudo-code for MAPPER_PROG Servers [To be added.] 9 Security Considerations It is crucial that all procedures of the MAPPER_PROG RPC protocol, excepting the MAP_NULL procedure and the MAP_SECINFO (as described in section 3.3) be mutually authenticated and their integrity be protected. It is RECOMMENDED that confidentiality services be used. Mapping servers SHOULD provide a facility for controlling access to the different mapping procedures based on client authorization. N. Williams [Page 20] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 If a mapping client does not need to map ISIDs to ESIDs then the mapping servers SHOULD respond to ISID mapping requests with an error (MAP_PERM_DENIED). If a mapping client does not need to map login names to ESID lists then the mapping servers SHOULD respond to login name mapping requests with an error (MAP_PERM_DENIED). 10 References 10.1 Normative References [RFC3050] S. Shepler et. al., RFC3050: "Network File System (NFS) version 4 Protocol," April 2003, Status: Standards Track. [RFC2203] M. Eisler et. al., RFC2203: "RPCSEC_GSS Protocol Specification," September 1997, Status: Standards Track. [RFC1964] J. Linn, RFC1964: "The Kerberos Version 5 GSS-API Mechanism," June 1996, Status: Standards Track. [RFC2025] C. Adams, RFC2025: "The Simple Public-Key GSS-API Mechanism (SPKM)," October 1996, Status: Standards Track. [RFC2847] M. Eisler, RFC2847: "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM," June 2000, Status: Standards Track. [More needed.] 10.2 Informative References [To be added, including references to Samba 2.2 and Samba 3.0.0 beta1.] Acknowledgements The author thanks Casper Dik for insisting that mapping is the correct way to use non-flat user and group namespaces with flat POSIX UID and GID namespaces, as well as Spencer Shepler, Lin Ling, Brent Callaghan, Bill Ricker and Luke Howard for their comments on the mapping model. Authors' Addresses Nicolas Williams Sun Microsystems 5300 Riata Trace Ct N. Williams [Page 21] DRAFT Mapping User/Group Names to ISIDs Expires December 2003 Austin, TX 78727 USA Email: nicolas.williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 22]