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
<draft-williams-nfsv4-ace-mapping-01.txt>
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
<none>
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
<none>
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
<none>
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.<mapping_domain>.<client's DNS domain>.
_mapper.<mapping_domain>.
where "<mapping_domain>" is the name of the mapping domain that the
client is interested in and where "<client's DNS domain>" 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]