From: Kurt Zeilenga Date: Sat, 31 May 2003 22:47:07 +0000 (+0000) Subject: Update drafts X-Git-Tag: OPENLDAP_REL_ENG_2_1_MP~949 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=304410c7a04289347df7f5e242882b455e7a61a0;p=openldap Update drafts --- diff --git a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt new file mode 100644 index 0000000000..312bd61115 --- /dev/null +++ b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt @@ -0,0 +1,2413 @@ + + +Internet-Draft Editor: R. Harrison +Intended Category: Draft Standard Novell, Inc. +Document: draft-ietf-ldapbis-authmeth-05.txt March 2003 +Obsoletes: RFC 2829, RFC 2830 + + + LDAP: Authentication Methods + and + Connection Level Security Mechanisms + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + This document is intended to be, after appropriate review and + revision, submitted to the RFC Editor as a Standard Track document. + Distribution of this memo is unlimited. Technical discussion of + this document will take place on the IETF LDAP Extension Working + Group mailing list . Please send + editorial comments directly to the author + . + + 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. + +Abstract + + This document describes LDAPv3 (Lightweight Directory Access + Protocol v3) authentication methods and connection level security + mechanisms that are required of all conforming LDAPv3 server + implementations and makes recommendations for combinations of these + mechanisms to be used in various deployment circumstances. + + Among the mechanisms described are + + - various forms of authentication including anonymous + authentication, password-based authentication, and certificate + based authentication + - the use of SASL mechanisms with LDAPv3 + - the use of TLS (Transport Layer Security) with LDAPv3 + + +Harrison Expires September 2003 [Page 1] + + Authentication Methods for LDAPv3 + + - the various authentication and authorization states through + which a connection to an LDAP server may pass and the actions + that trigger these state changes. + + +1. Conventions Used in this Document + +1.1. Glossary of Terms + + The following terms are used in this document. To aid the reader, + these terms are defined here. + + - "user" represents any application which is an LDAP client using + the directory to retrieve or store information. + + - "LDAP association" is used to distinguish the LDAP-level + connection from any underlying TLS-level connection that may or + may not exist. + +1.2. Security Terms and Concepts + + In general, security terms in this document are used consistently + with the definitions provided in [RFC2828]. In addition, several + terms and concepts relating to security, authentication, and + authorization are presented in Appendix B of this document. While + the formal definition of these terms and concepts is outside the + scope of this document, an understanding of them is prerequisite to + understanding much of the material in this document. Readers who are + unfamiliar with security-related concepts are encouraged to review + Appendix B before reading the remainder of this document. + +1.3. Keywords + + 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 RFC 2119 [RFC2119]. + +2. Introduction + + This document is an integral part of the LDAP Technical + Specification [ROADMAP]. This document replaces RFC 2829 and + portions of RFC 2830. Changes to RFC 2829 are summarized in Appendix + C and changes to RFC 2830 are summarized in Appendix D. + + LDAPv3 is a powerful access protocol for directories. It offers + means of searching, retrieving and manipulating directory content, + and ways to access a rich set of security functions. + + It is vital that these security functions be interoperable among all + LDAP clients and servers on the Internet; therefore there has to be + a minimum subset of security functions that is common to all + implementations that claim LDAPv3 conformance. + + Basic threats to an LDAP directory service include: + +Harrison Expires September 2003 [Page 2] + + Authentication Methods for LDAPv3 + + + (1) Unauthorized access to directory data via data-retrieval + operations, + + (2) Unauthorized access to reusable client authentication + information by monitoring others' access, + + (3) Unauthorized access to directory data by monitoring others' + access, + + (4) Unauthorized modification of directory data, + + (5) Unauthorized modification of configuration information, + + (6) Unauthorized or excessive use of resources (denial of service), + and + + (7) Spoofing of directory: Tricking a client into believing that + information came from the directory when in fact it did not, + either by modifying data in transit or misdirecting the client's + connection. + + Threats (1), (4), (5) and (6) are due to hostile clients. Threats + (2), (3) and (7) are due to hostile agents on the path between + client and server or hostile agents posing as a server. + + The LDAP protocol suite can be protected with the following security + mechanisms: + + (1) Client authentication by means of the SASL [RFC2222] mechanism + set, possibly backed by the TLS [RFC2246] credentials exchange + mechanism, + + (2) Client authorization by means of access control based on the + requestor's authenticated identity, + + (3) Data integrity protection by means of the TLS protocol or SASL + mechanisms that provide data integrity services, + + (4) Data confidentiality protection against snooping by means of the + TLS protocol or SASL mechanisms that provide data + confidentiality services, + + (5) Server resource usage limitation by means of administrative + service limits configured on the server, and + + (6) Server authentication by means of the TLS protocol or SASL + mechanism. + + At the moment, imposition of access controls is done by means + outside the scope of the LDAPv3 protocol. + +3. Rationale for LDAPv3 Security Mechanisms + + + +Harrison Expires September 2003 [Page 3] + + Authentication Methods for LDAPv3 + + It seems clear that allowing any implementation, faced with the + above requirements, to simply pick and choose among the possible + alternatives is not a strategy that is likely to lead to + interoperability. In the absence of mandates, clients will be + written that do not support any security function supported by the + server, or worse, they will support only mechanisms like the LDAPv3 + simple bind using clear text passwords that provide inadequate + security for most circumstances. + + Given the presence of the Directory, there is a strong desire to see + mechanisms where identities take the form of an LDAP distinguished + name [LDAPDN] and authentication data can be stored in the + directory. This means that this data must be updated outside the + protocol or only updated in sessions well protected against + snooping. It is also desirable to allow authentication methods to + carry authorization identities based on existing--non-LDAP DN--forms + of user identities for backwards compatibility with non-LDAP-based + authentication services. + + The set of security mechanisms provided in LDAPv3 and described in + this document is intended to meet the security needs for a wide + range of deployment scenarios and still provide a high degree of + interoperability among various LDAPv3 implementations and + deployments. Appendix A contains example deployment scenarios that + list the mechanisms that might be used to achieve a reasonable level + of security in various circumstances. + +4. Bind Operation + + The Bind operation defined in section 4.2 of [Protocol] allows + authentication information to be exchanged between the client and + server. + +4.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind") + + Unlike LDAP version 2, the client need not send a Bind Request in + the first PDU of the connection. The client may send any operation + request prior to binding, and the server MUST treat it as if it had + been performed after an anonymous bind operation. If the server + requires that the client bind before browsing or modifying the + directory, the server MAY reject a request other than binding, + unbinding or an extended request with the "operationsError" result. + + +4.2. Simple Authentication + + The simple authentication option provides minimal authentication + facilities, with the contents of the authentication field consisting + only of a cleartext password. Note that the use of cleartext + passwords is strongly discouraged over open networks when the + underlying transport service cannot guarantee confidentiality (see + section 8). + +4.3. SASL Authentication + +Harrison Expires September 2003 [Page 4] + + Authentication Methods for LDAPv3 + + + The sasl authentication option allows for any mechanism defined for + use with SASL [RFC2222] not specifically prohibited by this document + (see section 4.3.1). + + Clients sending a bind request with the sasl choice selected SHOULD + NOT send a value in the name field. Servers receiving a bind request + with the sasl choice selected SHALL ignore any value in the name + field. + + The mechanism field in SaslCredentials contains the name of the + mechanism. The credentials field contains the arbitrary data used + for authentication, inside an OCTET STRING wrapper. Note that unlike + some Internet application protocols where SASL is used, LDAP is not + text-based, thus no Base64 transformations are performed on the + credentials. + + If any SASL-based integrity or confidentiality services are enabled, + they take effect following the transmission by the server and + reception by the client of the final BindResponse with a resultCode + of success. + + If a SASL security layer is negotiated, the client MUST discard all + information about the server fetched prior to the initiation of the + SASL negotiation. If the client is configured to support multiple + SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list + both before and after the SASL security layer is negotiated. This + allows the client to detect active attacks that remove supported + SASL mechanisms from the supportedSASLMechanisms list and allows the + client to ensure that it is using the best mechanism supported by + both client and server. (This requirement is a SHOULD to allow for + environments where the supportedSASLMechanisms list is provided to + the client through a different trusted source, e.g. as part of a + digitally signed object.) + + The client can request that the server use authentication + information from a lower layer protocol by using the SASL EXTERNAL + mechanism (see section 5.2.2.). + +4.3.1. Use of ANONYMOUS and PLAIN SASL Mechanisms + + As LDAP includes native anonymous and plaintext authentication + methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used + with LDAP. If an authorization identity of a form different from a + DN is requested by the client, a data confidentiality mechanism that + protects the password in transit should be used. + +4.3.2. Use of EXTERNAL SASL Mechanism + + The "EXTERNAL" SASL mechanism can be used to request the LDAP server + make use of security credentials exchanged by a lower layer. If a + TLS session has not been established between the client and server + prior to making the SASL EXTERNAL Bind request and there is no other + external source of authentication credentials (e.g. IP-level + +Harrison Expires September 2003 [Page 5] + + Authentication Methods for LDAPv3 + + security [RFC2401]), or if during the process of establishing the + TLS session, the server did not request the client's authentication + credentials, the SASL EXTERNAL bind MUST fail with a resultCode of + inappropriateAuthentication. Any client authentication and + authorization state of the LDAP association is lost, so the LDAP + association is in an anonymous state after the failure (see + [Protocol] section 4.2.1). + +4.3.3. Other SASL Mechanisms + + Other SASL mechanisms may be used with LDAP, but their usage is not + considered in this document. + +4.4. SASL Authorization Identity + + The authorization identity is carried as part of the SaslCredentials + credentials field in the Bind request and response. + + When the "EXTERNAL" SASL mechanism is being negotiated, if the + credentials field is present, it contains an authorization identity + of the authzId form described below. + + Other mechanisms define the location of the authorization identity + in the credentials field. + +4.4.1. Authorization Identity Syntax + + The authorization identity is a string in the UTF-8 character set, + corresponding to the following ABNF grammar [RFC2234]: + + ; Specific predefined authorization (authz) id schemes are + ; defined below -- new schemes may be defined in the future. + + authzId = dnAuthzId / uAuthzId + + DNCOLON = %x64 %x6e %x3a ; "dn:" + UCOLON = %x75 %x3a ; "u:" + + ; distinguished-name-based authz id. + dnAuthzId = DNCOLON dn + dn = utf8string ; with syntax defined in [LDAPDN] section 3. + + + ; unspecified authorization id, UTF-8 encoded. + uAuthzId = UCOLON userid + userid = utf8string ; syntax unspecified + + The dnAuthzId choice allows client applications to assert + authorization identities in the form of a distinguished name. The + decision to allow or disallow an authentication identity to have + access to the requested authorization identity is a matter of local + policy ([SASL] section 4.2). For this reason there is no requirement + that the asserted dn be that of an entry in directory. + + +Harrison Expires September 2003 [Page 6] + + Authentication Methods for LDAPv3 + + The uAuthzId choice allows for compatibility with client + applications that wish to assert an authorization identity to a + local directory but do not have that identity in distinguished name + form. The format of utf8string is defined as only a sequence of UTF- + 8 encoded ISO 10646 characters, and further interpretation is + subject to prior agreement between the client and server. + + For example, the userid could identify a user of a specific + directory service, or be a login name or the local-part of an RFC + 822 email address. In general, a uAuthzId MUST NOT be assumed to be + globally unique. + + Additional authorization identity schemes MAY be defined in future + versions of this document. + +4.5. SASL Service Name for LDAP + + For use with SASL [RFC2222], a protocol must specify a service name + to be used with various SASL mechanisms, such as GSSAPI. For LDAP, + the service name is "ldap", which has been registered with the IANA + as a GSSAPI service name. + +4.6. SASL Integrity and Privacy Protections + + Any negotiated SASL integrity and privacy protections SHALL start on + the first octet of the first LDAP PDU following successful + completion of the SASL bind operation. If lower level security layer + is negotiated, such as TLS, any SASL security services SHALL be + layered on top of such security layers regardless of the order of + their negotiation. + +5. Start TLS Operation + + The Start Transport Layer Security (StartTLS) operation defined in + section 4.13 of [Protocol] provides the ability to establish + Transport Layer Security [RFC2246] on an LDAP association. + +5.1. Sequencing of the Start TLS Operation + + This section describes the overall procedures clients and servers + must follow for TLS establishment. These procedures take into + consideration various aspects of the overall security of the LDAP + association including discovery of resultant security level and + assertion of the client's authorization identity. + + Note that the precise effects, on a client's authorization identity, + of establishing TLS on an LDAP association are described in detail + in section 5.5. + +5.1.1. Requesting to Start TLS on an LDAP Association + + The client MAY send the Start TLS extended request at any time after + establishing an LDAP association, except that in the following cases + the client MUST NOT send a Start TLS extended request: + +Harrison Expires September 2003 [Page 7] + + Authentication Methods for LDAPv3 + + + - if TLS is currently established on the connection, or + - during a multi-stage SASL negotiation, or + - if there are any LDAP operations outstanding on the + connection. + + The result of violating any of these requirements is a resultCode of + operationsError, as described above in [Protocol] section 14.3.2.2. + + In particular, there is no requirement that the client have or have + not already performed a Bind operation before sending a Start TLS + operation request. The client may have already performed a Bind + operation when it sends a Start TLS request, or the client might + have not yet bound. + + If the client did not establish a TLS connection before sending any + other requests, and the server requires the client to establish a + TLS connection before performing a particular request, the server + MUST reject that request by sending a resultCode of + confidentialityRequired or strongAuthRequired. In response, the + client MAY send a Start TLS extended request, or it MAY choose to + close the connection. + +5.1.2. Starting TLS + + The server will return an extended response with the resultCode of + success if it is willing and able to negotiate TLS. It will return + other resultCodes (documented in [Protocol] section 4.13.2.2) if it + is unable to do so. + + In the successful case, the client (which has ceased to transfer + LDAP requests on the connection) MUST either begin a TLS negotiation + or close the connection. The client will send PDUs in the TLS Record + Protocol directly over the underlying transport connection to the + server to initiate TLS negotiation [RFC2246]. + +5.1.3. TLS Version Negotiation + + Negotiating the version of TLS or SSL to be used is a part of the + TLS Handshake Protocol, as documented in [RFC2246]. Please refer to + that document for details. + +5.1.4. Discovery of Resultant Security Level + + After a TLS connection is established on an LDAP association, both + parties MUST individually decide whether or not to continue based on + the privacy level achieved. Ascertaining the TLS connection's + privacy level is implementation dependent, and accomplished by + communicating with one's respective local TLS implementation. + + If the client or server decides that the level of authentication or + privacy is not high enough for it to continue, it SHOULD gracefully + close the TLS connection immediately after the TLS negotiation has + completed (see [Protocol] section 4.13.3.1 and section 5.2.3 below). + +Harrison Expires September 2003 [Page 8] + + Authentication Methods for LDAPv3 + + If the client decides to continue, it MAY attempt to Start TLS + again, it MAY send an unbind request, or it MAY send any other LDAP + request. + +5.1.5. Assertion of Client's Authorization Identity + + The client MAY, upon receipt of a Start TLS response indicating + success, assert that a specific authorization identity be utilized + in determining the client's authorization status. The client + accomplishes this via an LDAP Bind request specifying a SASL + mechanism of "EXTERNAL" [RFC2222] (see section 5.5.1.2 below). + +5.1.6. Server Identity Check + + The client MUST check its understanding of the server's hostname + against the server's identity as presented in the server's + Certificate message, in order to prevent man-in-the-middle attacks. + + Matching is performed according to these rules: + + - The client MUST use the server hostname it used to open the LDAP + connection as the value to compare against the server name as + expressed in the server's certificate. The client MUST NOT use + the any other derived form of name including the server's + canonical DNS name. + + - If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + - Matching is case-insensitive. + + - The "*" wildcard character is allowed. If present, it applies + only to the left-most name component. + + For example, *.bar.com would match a.bar.com and b.bar.com, but it + would not match a.x.bar.com nor would it match bar.com. If more + than one identity of a given type is present in the certificate + (e.g. more than one dNSName name), a match in any one of the set is + considered acceptable. + + If the hostname does not match the dNSName-based identity in the + certificate per the above check, user-oriented clients SHOULD either + notify the user (clients MAY give the user the opportunity to + continue with the connection in any case) or terminate the + connection and indicate that the server's identity is suspect. + Automated clients SHOULD close the connection, returning and/or + logging an error indicating that the server's identity is suspect. + + Beyond the server identity checks described in this section, clients + SHOULD be prepared to do further checking to ensure that the server + is authorized to provide the service it is observed to provide. The + client MAY need to make use of local policy information. + + +Harrison Expires September 2003 [Page 9] + + Authentication Methods for LDAPv3 + +5.1.7. Refresh of Server Capabilities Information + + Upon TLS session establishment, the client MUST discard all + information about the server fetched prior to the initiation of the + TLS negotiation and MUST refresh any cached server capabilities + information (e.g. from the server's root DSE; see section 3.4 of + [Protocol]). This is necessary to protect against active- + intermediary attacks that may have altered any server capabilities + information retrieved prior to TLS establishment. + + The server MAY advertise different capabilities after TLS + establishment. In particular, the value of supportedSASLMechanisms + MAY be different after TLS has been negotiated (specifically, the + EXTERNAL mechanism or the proposed PLAIN mechanism are likely to + only be listed after a TLS negotiation has been performed). + +5.2. Effects of TLS on a Client's Authorization Identity + + This section describes the effects on a client's authorization + identity brought about by establishing TLS on an LDAP association. + The default effects are described first, and next the facilities for + client assertion of authorization identity are discussed including + error conditions. Finally, the effects of closing the TLS connection + are described. + + Authorization identities and related concepts are described in + Appendix B. + +5.2.1. Default Effects + + Upon establishment of the TLS session onto the LDAP association, any + previously established authentication and authorization identities + MUST remain in force, including anonymous state. This holds even in + the case where the server requests client authentication via TLS -- + e.g. requests the client to supply its certificate during TLS + negotiation (see [RFC2246]). + +5.2.2. Client Assertion of Authorization Identity + + A client MAY either implicitly request that its LDAP authorization + identity be derived from its authenticated TLS credentials or it MAY + explicitly provide an authorization identity and assert that it be + used in combination with its authenticated TLS credentials. The + former is known as an implicit assertion, and the latter as an + explicit assertion. + +5.2.2.1. Implicit Assertion + + An implicit authorization identity assertion is accomplished after + TLS establishment by invoking a Bind request of the SASL form using + the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL NOT + include the optional credentials octet string (found within the + SaslCredentials sequence in the Bind Request). The server will + derive the client's authorization identity from the authentication + +Harrison Expires September 2003 [Page 10] + + Authentication Methods for LDAPv3 + + identity supplied in the client's TLS credentials (typically a + public key certificate) according to local policy. The underlying + mechanics of how this is accomplished are implementation specific. + +5.2.2.2. Explicit Assertion + + An explicit authorization identity assertion is accomplished after + TLS establishment by invoking a Bind request of the SASL form using + the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL + include the credentials octet string. This string MUST be + constructed as documented in section 4.4.1. + +5.2.2.3. Error Conditions + + For either form of assertion, the server MUST verify that the + client's authentication identity as supplied in its TLS credentials + is permitted to be mapped to the asserted authorization identity. + The server MUST reject the Bind operation with an invalidCredentials + resultCode in the Bind response if the client is not so authorized. + + Additionally, with either form of assertion, if a TLS session has + not been established between the client and server prior to making + the SASL EXTERNAL Bind request and there is no other external source + of authentication credentials (e.g. IP-level security [RFC2401]), or + if during the process of establishing the TLS session, the server + did not request the client's authentication credentials, the SASL + EXTERNAL bind MUST fail with a result code of + inappropriateAuthentication. + + After the above Bind operation failures, any client authentication + and authorization state of the LDAP association is lost (see + [Protocol] section 4.2.1), so the LDAP association is in an + anonymous state after the failure. The TLS session state is + unaffected, though a server MAY end the TLS session, via a TLS + close_notify message, based on the Bind failure (as it MAY at any + time). + +5.2.3. TLS Connection Closure Effects + + Closure of the TLS session MUST cause the LDAP association to move + to an anonymous authentication and authorization state regardless of + the state established over TLS and regardless of the authentication + and authorization state prior to TLS session establishment. + +6. LDAP Association State Transition Tables + + To comprehensively diagram the various authentication and TLS states + through which an LDAP association may pass, this section provides a + state transition table to represent a state diagram for the various + states through which an LDAP association may pass during the course + of its existence and the actions that cause these changes in state. + +6.1. LDAP Association States + + +Harrison Expires September 2003 [Page 11] + + Authentication Methods for LDAPv3 + + The following table lists the valid LDAP association states and + provides a description of each state. The ID for each state is used + in the state transition table in section 6.4. + + ID State Description + -- -------------------------------------------------------------- + S1 no Auth ID + no AuthZ ID + [TLS: no Creds, OFF] + S2 no Auth ID + no AuthZ ID + [TLS: no Creds, ON] + S3 no Auth ID + no AuthZ ID + [TLS: Creds Auth ID "I", ON] + S4 Auth ID = Xn + AuthZ ID= Y + [TLS: no Creds, OFF] + S5 Auth ID = Xn + AuthZ ID= Yn + [TLS: no Creds, ON] + S6 Auth ID = Xn + AuthZ ID= Yn + [TLS: Creds Auth ID "I", ON] + S7 Auth ID = I + AuthZ ID= J + [TLS: Creds Auth ID "I", ON] + S8 Auth ID = I + AuthZ ID= K + [TLS: Creds Auth ID "I", ON] + +6.2. Actions that Affect LDAP Association State + + The following table lists the actions that can affect the state of + an LDAP association. The ID for each action is used in the state + transition table in section 6.4. + + ID Action + -- ------------------------------------------------ + A1 Client binds anonymously + A2 Inappropriate authentication: client attempts an anonymous + bind or a bind without supplying credentials to a server that + requires the client to provide some form of credentials. + A3 Client Start TLS request + Server: client auth NOT required + A4 Client: Start TLS request + Server: client creds requested + Client: [TLS creds: Auth ID "I"] + A5 Client or Server: send TLS closure alert ([Protocol] section + X) + A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST- + MD5 password, Kerberos, etc. -รป except EXTERNAL [Auth ID "X" + +Harrison Expires September 2003 [Page 12] + + Authentication Methods for LDAPv3 + + maps to AuthZ ID "Y"] + A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J" + [Explicit Assertion (section 5.2.1.2.2)] + A8 Client Bind SASL EXTERNAL without credentials [Implicit + Assertion (section 5.2 .1.2.1)] + +6.3. Decisions Used in Making LDAP Association State Changes + + Certain changes in the state of an LDAP association are only allowed + if the server can affirmatively answer a question. These questions + are applied as part of the criteria for allowing or disallowing a + state change in the state transition table in section 6.4. + + ID Decision Question + -- -------------------------------------------------------------- + D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"? + D2 Can a valid AuthZ ID "K" be derived from TLS Credentials Auth + ID "I"? + +6.4. LDAP Association State Transition Table + + The LDAP Association table below lists the valid states for an LDAP + association and the actions that could affect them. For any given + row in the table, the Current State column gives the state of an + LDAP association, the Action column gives an action that could + affect the state of an LDAP assocation, and the Next State column + gives the resulting state of an LDAP association after the action + occurs. + + The initial state for the state machine described in this table is + S1. + + Current Next + State Action State Comment + ------- ------------- ----- ----------------------------------- + S1 A1 S1 + S1 A2 S1 Error: Inappropriate authentication + S1 A3 S2 + S1 A4 S3 + S1 A6 S4 + S1 A7 ? identity could be provided by + another underlying mechanism such + as IPSec. + S1 A8 ? identity could be provided by + another underlying mechanism such + as IPSec. + S2 A1 S2 + S2 A2 S2 Error: Inappropriate authentication + S2 A5 S1 + S2 A6 S5 + S2 A7 ? identity could be provided by + another underlying mechanism such + as IPSec. + +Harrison Expires September 2003 [Page 13] + + Authentication Methods for LDAPv3 + + S2 A8 ? identity could be provided by + another underlying mechanism such + as IPSec. + S3 A1 S3 + S3 A2 S3 Error: Inappropriate authentication + S3 A5 S1 + S3 A6 S6 + S3 A7 and D1=NO S3 Error: InvalidCredentials + S3 A7 and D1=YES S7 + S3 A8 and D2=NO S3 Error: InvalidCredentials + S3 A8 and D2=YES S8 + S4 A1 S1 + S4 A2 S4 Error: Inappropriate Authentication + S4 A3 S5 + S4 A4 S6 + S4 A5 S1 + S4 A6 S4 + S4 A7 ? identity could be provided by + another underlying mechanism such + as IPSec. + S4 A8 ? identity could be provided by + another underlying mechanism such + as IPSec. + S5 A1 S2 + S5 A2 S5 Error: Inappropriate Authentication + S5 A5 S1 + S5 A6 S5 + S5 A7 ? identity could be provided by + another underlying mechanism such + as IPSec. + S5 A8 ? identity could be provided by + another underlying mechanism such + as IPSec. + S6 A1 S3 + S6 A2 S6 Error: Inappropriate Authentication + S6 A5 S1 + S6 A6 S6 + S6 A7 and D1=NO S6 Error: InvalidCredentials + S6 A7 and D1=YES S7 + S6 A8 and D2=NO S6 Error: InvalidCredentials + S6 A8 and D2=YES S8 + S7 A1 S3 + S7 A2 S7 Error: Inappropriate Authentication + S7 A5 S1 + S7 A6 S6 + S7 A7 S7 + S7 A8 and D2=NO S3 Error: InvalidCredentials + S7 A8 and D2=YES S8 + S8 A1 S3 + S8 A2 S8 Error: Inappropriate Authentication + S8 A5 S1 + S8 A6 S6 + +Harrison Expires September 2003 [Page 14] + + Authentication Methods for LDAPv3 + + S8 A7 and D1=NO S6 Error: InvalidCredentials + S8 A7 and D1=YES S7 + S8 A8 S8 + + +7. Anonymous Authentication + + Directory operations that modify entries or access protected + attributes or entries generally require client authentication. + Clients that do not intend to perform any of these operations + typically use anonymous authentication. Servers SHOULD NOT allow + clients with anonymous authentication to modify directory entries or + access sensitive information in directory entries. + + LDAP implementations MUST support anonymous authentication, as + defined in section 7.1. + + LDAP implementations MAY support anonymous authentication with TLS, + as defined in section 7.2. + + While there MAY be access control restrictions to prevent access to + directory entries, an LDAP server SHOULD allow an anonymously-bound + client to retrieve the supportedSASLMechanisms attribute of the root + DSE. + + An LDAP server MAY use other information about the client provided + by the lower layers or external means to grant or deny access even + to anonymously authenticated clients. + +7.1. Anonymous Authentication Procedure + + An LDAPv3 client that has not successfully completed a bind + operation on a connection is anonymously authenticated. See section + 4.3.3. + + An LDAP client MAY also choose to explicitly bind anonymously. A + client that wishes to do so MUST choose the simple authentication + option in the Bind Request (see section 4.1) and set the password to + be of zero length. (This is often done by LDAPv2 clients.) Typically + the name is also of zero length. + +7.2. Anonymous Authentication and TLS + + An LDAP client MAY use the Start TLS operation (section 5) to + negotiate the use of TLS security [RFC2246]. If the client has not + bound beforehand, then until the client uses the EXTERNAL SASL + mechanism to negotiate the recognition of the client's certificate, + the client is anonymously authenticated. + + Recommendations on TLS ciphersuites are given in section 10. + + An LDAP server which requests that clients provide their certificate + during TLS negotiation MAY use a local security policy to determine + + +Harrison Expires September 2003 [Page 15] + + Authentication Methods for LDAPv3 + + whether to successfully complete TLS negotiation if the client did + not present a certificate which could be validated. + +8. Password-based Authentication + + This section discusses various options for performing password-based + authentication to LDAPv3 compliant servers and the environments + suitable for their use. + +8.1. Simple Authentication + + The LDAP "simple" authentication choice is not suitable for + authentication in environments where there is no network or + transport layer confidentiality. LDAP implementations SHOULD support + authentication with the "simple" authentication choice when the + connection is protected against eavesdropping using TLS, as defined + in section 5. LDAP implementations SHOULD NOT support authentication + with the "simple" authentication choice unless the data on the + connection is protected using TLS or other data confidentiality and + data integrity protection. + +8.2. Digest Authentication + + LDAP servers that implement any password-based authentication method + MUST support authentication with a password using the DIGEST-MD5 + SASL mechanism for password protection. + + An LDAP client MAY determine whether the server supports this + mechanism by performing a search request on the root DSE, requesting + the supportedSASLMechanisms attribute, and checking whether the + string "DIGEST-MD5" is present as a value of this attribute. + + In the first stage of authentication, when the client is performing + an "initial authentication" as defined in section 2.1 of [RFC2831], + the client sends a bind request in which the version number is 3, + the authentication choice is sasl, the sasl mechanism name is + "DIGEST-MD5", and the credentials are absent. The client then waits + for a response from the server to this request. + + The server will respond with a bind response in which the resultCode + is saslBindInProgress, and the serverSaslCreds field is present. The + contents of this field is a string defined by "digest-challenge" in + section 2.1.1 of [RFC2831]. The server SHOULD include a realm + indication and MUST indicate support for UTF-8. + + The client will send a bind request with a distinct message id, in + which the version number is 3, the authentication choice is sasl, + the sasl mechanism name is "DIGEST-MD5", and the credentials contain + the string defined by "digest-response" in section 2.1.2 of + [RFC2831]. The serv-type is "ldap". + + The server will respond with a bind response in which the resultCode + is either success, or an error indication. If the authentication is + successful and the server does not support subsequent + +Harrison Expires September 2003 [Page 16] + + Authentication Methods for LDAPv3 + + authentication, then the credentials field is absent. If the + authentication is successful and the server supports subsequent + authentication, then the credentials field contains the string + defined by "response-auth" in section 2.1.3 of [RFC2831]. Support + for subsequent authentication is OPTIONAL in clients and servers. + +8.3. "simple" authentication choice under TLS encryption + + Following the negotiation of an appropriate TLS ciphersuite + providing connection confidentiality [RFC2246], a client MAY + authenticate to a directory that supports the simple authentication + choice by performing a simple bind operation. + + The client will use the Start TLS operation [Protocol] to negotiate + the use of TLS security [RFC2246] on the connection to the LDAP + server. The client need not have bound to the directory beforehand. + + For this authentication procedure to be successful, the client and + server MUST negotiate a ciphersuite which contains a bulk encryption + algorithm of appropriate strength. Recommendations on cipher suites + are given in section 10. + + Following the successful completion of TLS negotiation, the client + MUST send an LDAP bind request with the version number of 3, the + name field containing a DN, and the "simple" authentication choice, + containing a password. + +8.3.1. "simple" Authentication Choice + + DSAs that map the DN sent in the bind request to a directory entry + with an associated set of one or more passwords will compare the + presented password to the set of passwords associated with that + entry. If there is a match, then the server will respond with + resultCode success, otherwise the server will respond with + resultCode invalidCredentials. + +8.4. Other authentication choices with TLS + + It is also possible, following the negotiation of TLS, to perform a + SASL authentication that does not involve the exchange of plaintext + reusable passwords. In this case the client and server need not + negotiate a ciphersuite that provides confidentiality if the only + service required is data integrity. + +9. Certificate-based authentication + + LDAP server implementations SHOULD support authentication via a + client certificate in TLS, as defined in section 5.2.2. + +9.1. Certificate-based authentication with TLS + + A user who has a public/private key pair in which the public key has + been signed by a Certification Authority may use this key pair to + authenticate to the directory server if the user's certificate is + +Harrison Expires September 2003 [Page 17] + + Authentication Methods for LDAPv3 + + requested by the server. The user's certificate subject field SHOULD + be the name of the user's directory entry, and the Certification + Authority that issued the user's certificate must be sufficiently + trusted by the directory server in order for the server to process + the certificate. The means by which servers validate certificate + paths is outside the scope of this document. + + A server MAY support mappings for certificates in which the subject + field name is different from the name of the user's directory entry. + A server which supports mappings of names MUST be capable of being + configured to support certificates for which no mapping is required. + + The client will use the Start TLS operation [Protocol] to negotiate + the use of TLS security [RFC2246] on the connection to the LDAP + server. The client need not have bound to the directory beforehand. + + In the TLS negotiation, the server MUST request a certificate. The + client will provide its certificate to the server, and the server + MUST perform a private key-based encryption, proving it has the + private key associated with the certificate. + + In deployments that require protection of sensitive data in transit, + the client and server MUST negotiate a ciphersuite that contains a + bulk encryption algorithm of appropriate strength. Recommendations + of cipher suites are given in section 10. + + The server MUST verify that the client's certificate is valid. The + server will normally check that the certificate is issued by a known + certification authority (CA), and that none of the certificates on + the client's certificate chain are invalid or revoked. There are + several procedures by which the server can perform these checks. + + Following the successful completion of TLS negotiation, the client + will send an LDAP bind request with the SASL "EXTERNAL" mechanism. + +10. TLS Ciphersuites + + The following ciphersuites defined in [RFC2246] MUST NOT be used for + confidentiality protection of passwords or data: + + TLS_NULL_WITH_NULL_NULL + TLS_RSA_WITH_NULL_MD5 + TLS_RSA_WITH_NULL_SHA + + The following ciphersuites defined in [RFC2246] can be cracked + easily (less than a day of CPU time on a standard CPU in 2000). + These ciphersuites are NOT RECOMMENDED for use in confidentiality + protection of passwords or data. Client and server implementers + SHOULD carefully consider the value of the password or data being + protected before using these ciphersuites: + + TLS_RSA_EXPORT_WITH_RC4_40_MD5 + TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 + TLS_RSA_EXPORT_WITH_DES40_CBC_SHA + +Harrison Expires September 2003 [Page 18] + + Authentication Methods for LDAPv3 + + TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA + TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA + TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA + TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA + TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 + TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA + + The following ciphersuites are vulnerable to man-in-the-middle + attacks, and SHOULD NOT be used to protect passwords or sensitive + data, unless the network configuration is such that the danger of a + man-in-the-middle attack is tolerable: + + TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 + TLS_DH_anon_WITH_RC4_128_MD5 + TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA + TLS_DH_anon_WITH_DES_CBC_SHA + TLS_DH_anon_WITH_3DES_EDE_CBC_SHA + + A client or server that supports TLS MUST support + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites + offering equivalent or better protection. + +11. Security Considerations + + Security issues are discussed throughout this memo; the + (unsurprising) conclusion is that mandatory security is important + and that session confidentiality protection is required when + snooping is a problem. + + Servers are encouraged to prevent modifications by anonymous users. + Servers may also wish to minimize denial of service attacks by + timing out idle connections, and returning the unwillingToPerform + result code rather than performing computationally expensive + operations requested by unauthorized clients. + + Operational experience shows that clients can misuse unauthenticated + access (simple bind with name but no password). For this reason, + servers SHOULD by default reject authentication requests that have a + DN with an empty password with an error of invalidCredentials. + + Access control SHOULD be applied when reading sensitive information + or updating directory information. + + A connection on which the client has not performed the Start TLS + operation or negotiated a suitable SASL mechanism for connection + integrity and encryption services is subject to man-in-the-middle + attacks to view and modify information in transit. + +11.1. Start TLS Security Considerations + + The goals of using the TLS protocol with LDAP are to ensure + connection confidentiality and integrity, and to optionally provide + for authentication. TLS expressly provides these capabilities, as + described in [RFC2246]. + +Harrison Expires September 2003 [Page 19] + + Authentication Methods for LDAPv3 + + + All security gained via use of the Start TLS operation is gained by + the use of TLS itself. The Start TLS operation, on its own, does not + provide any additional security. + + Once established, TLS only provides for and ensures confidentiality + and integrity of the operations and data in transit over the LDAP + association--and only if the implementations on the client and + server support and negotiate it. The use of TLS does not provide or + ensure for confidentiality and/or non-repudiation of the data housed + by an LDAP-based directory server. Nor does it secure the data from + inspection by the server administrators. + + The level of security provided though the use of TLS depends + directly on both the quality of the TLS implementation used and the + style of usage of that implementation. Additionally, an active- + intermediary attacker can remove the Start TLS extended operation + from the supportedExtension attribute of the root DSE. Therefore, + both parties SHOULD independently ascertain and consent to the + security level achieved once TLS is established and before beginning + use of the TLS connection. For example, the security level of the + TLS connection might have been negotiated down to plaintext. + + Clients SHOULD either warn the user when the security level achieved + does not provide confidentiality and/or integrity protection, or be + configurable to refuse to proceed without an acceptable level of + security. + + Client and server implementors SHOULD take measures to ensure proper + protection of credentials and other confidential data where such + measures are not otherwise provided by the TLS implementation. + + Server implementors SHOULD allow for server administrators to elect + whether and when connection confidentiality and/or integrity is + required, as well as elect whether and when client authentication + via TLS is required. + + Additional security considerations relating to the EXTERNAL + mechanism to negotiate TLS can be found in [RFC2222] and [RFC2246]. + + +12. Acknowledgements + + This document combines information originally contained in RFC 2829 + and RFC 2830. The author acknowledges the work of Harald Tveit + Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan , + and Mark Wahl, each of whom authored one or more of these documents. + RFC 2829 and RFC 2830 were products of the IETF LDAPEXT Working + Group. RFC 2251 was a product of the ASID Working Group. + + This document is based upon input of the IETF LDAP Revision working + group. The contributions of its members is greatly appreciated. + +13. Normative References + +Harrison Expires September 2003 [Page 20] + + Authentication Methods for LDAPv3 + + + [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2222] Myers, J., "Simple Authentication and Security Layer + (SASL)", draft-myers-saslrev-xx.txt, a work in progress. + + [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as + a SASL Mechanism", RFC 2831, May 2000. + + [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of + Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in + progress. + + [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- + ldapbis-protocol-xx.txt, a work in progress. + + [ROADMAP] K. Zeilenga, "LDAP: Technical Specification Road Map", + draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. + +14. Informative References + + [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May + 2000. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + +15. Author's Address + + Roger Harrison + Novell, Inc. + 1800 S. Novell Place + Provo, UT 84606 + +1 801 861 2642 + roger_harrison@novell.com + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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 + +Harrison Expires September 2003 [Page 21] + + Authentication Methods for LDAPv3 + + 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. + +Appendix A. Example Deployment Scenarios + + The following scenarios are typical for LDAP directories on the + Internet, and have different security requirements. (In the + following discussion, "sensitive data" refers to information whose + disclosure, alteration, destruction, or loss would adversely affect + the interests or business of its owner or user. Also note that there + may be data that is protected but not sensitive.) This is not + intended to be a comprehensive list; other scenarios are possible, + especially on physically protected networks. + + (1) A read-only directory, containing no sensitive data, accessible + to "anyone", and TCP connection hijacking or IP spoofing is not + a problem. Anonymous authentication, described in section 7, is + suitable for this type of deployment, and requires no additional + security functions except administrative service limits. + + (2) A read-only directory containing no sensitive data; read access + is granted based on identity. TCP connection hijacking is not + currently a problem. This scenario requires data confidentiality + for sensitive authentication information AND data integrity for + all authentication information. + + (3) A read-only directory containing no sensitive data; and the + client needs to ensure the identity of the directory server and + that the directory data is not modified while being returned + from the server. A data origin authentication service AND data + integrity service are required. + + (4) A read-write directory, containing no sensitive data; read + access is available to "anyone", update access to properly + authorized persons. TCP connection hijacking is not currently a + problem. This scenario requires data confidentiality for + sensitive authentication information AND data integrity for all + authentication information. + + +Harrison Expires September 2003 [Page 22] + + Authentication Methods for LDAPv3 + + (5) A directory containing sensitive data. This scenario requires + data confidentiality protection AND secure authentication. + +Appendix B. Authentication and Authorization: Definitions and Concepts + + This appendix defines basic terms, concepts, and interrelationships + regarding authentication, authorization, credentials, and identity. + These concepts are used in describing how various security + approaches are utilized in client authentication and authorization. + +B.1. Access Control Policy + + An access control policy is a set of rules defining the protection + of resources, generally in terms of the capabilities of persons or + other entities accessing those resources. A common expression of an + access control policy is an access control list. Security objects + and mechanisms, such as those described here, enable the expression + of access control policies and their enforcement. Access control + policies are typically expressed in terms of access control + attributes as described below. + +B.2. Access Control Factors + + A request, when it is being processed by a server, may be associated + with a wide variety of security-related factors (section 4.2 of + [Protocol]). The server uses these factors to determine whether and + how to process the request. These are called access control factors + (ACFs). They might include source IP address, encryption strength, + the type of operation being requested, time of day, etc. Some + factors may be specific to the request itself, others may be + associated with the connection via which the request is transmitted, + others (e.g. time of day) may be "environmental". + + Access control policies are expressed in terms of access control + factors. E.g., a request having ACFs i,j,k can perform operation Y + on resource Z. The set of ACFs that a server makes available for + such expressions is implementation-specific. + +B.3. Authentication, Credentials, Identity + + Authentication credentials are the evidence supplied by one party to + another, asserting the identity of the supplying party (e.g. a user) + who is attempting to establish an association with the other party + (typically a server). Authentication is the process of generating, + transmitting, and verifying these credentials and thus the identity + they assert. An authentication identity is the name presented in a + credential. + + There are many forms of authentication credentials -- the form used + depends upon the particular authentication mechanism negotiated by + the parties. For example: X.509 certificates, Kerberos tickets, + simple identity and password pairs. Note that an authentication + mechanism may constrain the form of authentication identities used + with it. + +Harrison Expires September 2003 [Page 23] + + Authentication Methods for LDAPv3 + + +B.4. Authorization Identity + + An authorization identity is one kind of access control factor. It + is the name of the user or other entity that requests that + operations be performed. Access control policies are often expressed + in terms of authorization identities; e.g., entity X can perform + operation Y on resource Z. + + The authorization identity bound to an association is often exactly + the same as the authentication identity presented by the client, but + it may be different. SASL allows clients to specify an authorization + identity distinct from the authentication identity asserted by the + client's credentials. This permits agents such as proxy servers to + authenticate using their own credentials, yet request the access + privileges of the identity for which they are proxying [RFC2222]. + Also, the form of authentication identity supplied by a service like + TLS may not correspond to the authorization identities used to + express a server's access control policy, requiring a server- + specific mapping to be done. The method by which a server composes + and validates an authorization identity from the authentication + credentials supplied by a client is implementation-specific. + +Appendix C. RFC 2829 Change History + + This appendix lists the changes made to the text of RFC 2829 in + preparing this document. + +C.0. General Editorial Changes + Version -00 + + - Changed other instances of the term LDAP to LDAPv3 where v3 of + the protocol is implied. Also made all references to LDAPv3 use + the same wording. + + - Miscellaneous grammatical changes to improve readability. + + - Made capitalization in section headings consistent. + + Version -01 + + - Changed title to reflect inclusion of material from RFC 2830 and + 2251. + +C.1. Changes to Section 1 + + Version -01 + + - Moved conventions used in document to a separate section. + +C.2. Changes to Section 2 + + Version -01 + + +Harrison Expires September 2003 [Page 24] + + Authentication Methods for LDAPv3 + + - Moved section to an appendix. + +C.3. Changes to Section 3 + + Version -01 + + - Moved section to an appendix. + +C.4 Changes to Section 4 + + Version -00 + + - Changed "Distinguished Name" to "LDAP distinguished name". + +C.5. Changes to Section 5 + + Version -00 + + - Added the following sentence: "Servers SHOULD NOT allow clients + with anonymous authentication to modify directory entries or + access sensitive information in directory entries." + +C.5.1. Changes to Section 5.1 + + Version -00 + + - Replaced the text describing the procedure for performing an + anonymous bind (protocol) with a reference to section 4.2 of RFC + 2251 (the protocol spec). + + Version -01 + + - Brought text describing procedure for performing an anonymous + bind from section 4.2 of RFC 2251 bis. This text will be + removed from the draft standard version of that document. + +C.6. Changes to Section 6. + + Version -00 + + Reorganized text in section 6.1 as follows: + + 1. Added a new section (6.1) titled "Simple Authentication" and + moved one of two introductory paragraphs for section 6 into + section 6.1. Added sentences to the paragraph indicating: + + a. simple authentication is not suitable for environments where + confidentiality is not available. + + b. LDAP implementations SHOULD NOT support simple + authentication unless confidentiality and data integrity + mechanisms are in force. + + + +Harrison Expires September 2003 [Page 25] + + Authentication Methods for LDAPv3 + + 2. Moved first paragraph of section 6 (beginning with "LDAP + implementations MUST support authentication with a passwordร ") + to section on Digest Authentication (Now section 6.2). + +C.6.1. Changes to Section 6.1. + + Version -00 Renamed section to 6.2 + + - Added sentence from original section 6 indicating that the + DIGEST-MD5 SASL mechanism is required for all conforming LDAPv3 + implementations + +C.6.2. Changes to Section 6.2 + + Version -00 + + - Renamed section to 6.3 + + - Reworded first paragraph to remove reference to user and the + userPassword password attribute Made the first paragraph more + general by simply saying that if a directory supports simple + authentication that the simple bind operation MAY performed + following negotiation of a TLS ciphersuite that supports + confidentiality. + + - Replaced "the name of the user's entry" with "a DN" since not + all bind operations are performed on behalf of a "user." + + - Added Section 6.3.1 heading just prior to paragraph 5. + + - Paragraph 5: replaced "The server" with "DSAs that map the DN + sent in the bind request to a directory entry with a + userPassword attribute." + +C.6.3. Changes to section 6.3. + + Version -00 + + - Renamed to section 6.4. + +C.7. Changes to section 7. + + none + +C.7.1. Changes to section 7.1. + + Version -00 + + - Clarified the entity issuing a certificate by moving the phrase + "to have issued the certificate" immediately after + "Certification Authority." + +C.8. Changes to section 8. + + +Harrison Expires September 2003 [Page 26] + + Authentication Methods for LDAPv3 + + Version -00 + + - Removed the first paragraph because simple authentication is + covered explicitly in section 6. + + - Added section 8.1. heading just prior to second paragraph. + + - Added section 8.2. heading just prior to third paragraph. + + - Added section 8.3. heading just prior to fourth paragraph. + + Version -01 + + - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL + for Other Security Services) to bring material on SASL + mechanisms together into one location. + +C.9. Changes to section 9. + + Version -00 + + - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL + mechanism." + + - Added section 9.1. heading. + + - Modified a comment in the ABNF from "unspecified userid" to + "unspecified authz id". + + - Deleted sentence, "A utf8string is defined to be the UTF-8 + encoding of one or more ISO 10646 characters," because it is + redundant. + + - Added section 9.1.1. heading. + + - Added section 9.1.2. heading. + + Version -01 + + - Moved entire section 9 to become section 3.5 so that it would be + with other SASL material. + +C.10. Changes to Section 10. + + Version -00 + + - Updated reference to cracking from a week of CPU time in 1997 to + be a day of CPU time in 2000. + + - Added text: "These ciphersuites are NOT RECOMMENDED for use... + and server implementers SHOULD" to sentence just prior the + second list of ciphersuites. + + + +Harrison Expires September 2003 [Page 27] + + Authentication Methods for LDAPv3 + + - Added text: "and MAY support other ciphersuites offering + equivalent or better protection," to the last paragraph of the + section. + +C.11. Changes to Section 11. + + Version -01 + + - Moved to section 3.6 to be with other SASL material. + +C.12. Changes to Section 12. + + Version -00 + + - Inserted new section 12 that specifies when SASL protections + begin following SASL negotiation, etc. The original section 12 + is renumbered to become section 13. + + Version -01 + + - Moved to section 3.7 to be with other SASL material. + +C.13. Changes to Section 13 (original section 12). + + None + +Appendix D. RFC 2830 Change History + + This appendix lists the changes made to the text of RFC 2830 in + preparing this document. + +D.0. General Editorial Changes + + - Material showing the PDUs for the Start TLS response was broken + out into a new section. + + - The wording of the definition of the Start TLS request and Start + TLS response was changed to make them parallel. NO changes were + made to the ASN.1 definition or the associated values of the + parameters. + + - A separate section heading for graceful TLS closure was added + for parallelism with section on abrupt TLS closure. + +Appendix E. RFC 2251 Change History + + This appendix lists the changes made to the text of RFC 2251 in + preparing this document. + +E.0. General Editorial Changes + + - All material from section 4.2 of RFC 2251 was moved into this + document. + + +Harrison Expires September 2003 [Page 28] + + Authentication Methods for LDAPv3 + + - A new section was created for the Bind Request + + - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved + after the section on the Bind Response for parallelism with the + presentation of the Start TLS operations. The section was also + subdivided to explicitly call out the various effects being + described within it. + + - All SASL profile information from RFC 2829 was brought within + the discussion of the Bind operation (primarily sections 4.4 - + 4.7). + +Appendix F. Change History to Combined Document + +F.1. Changes for draft-ldap-bis-authmeth-02 + + General + + - Added references to other LDAP standard documents, to sections + within the document, and fixed broken references. + + - General editorial changesรนpunctuation, spelling, formatting, + etc. + + Section 1. + + - Added glossary of terms and added sub-section headings + + Section 2. + + - Clarified security mechanisms 3, 4, & 5 and brought language in + line with IETF security glossary. + + Section 3. + + - Brought language in requirement (3) in line with security + glossary. + + - Clarified that information fetched prior to initiation of TLS + negotiation must be discarded + + -Clarified that information fetched prior to initiation of SASL + negotiation must be discarded + + - Rewrote paragraph on SASL negotiation requirements to clarify + intent + + Section 4.4. + + - Added stipulation that sasl choice allows for any SASL mechanism + not prohibited by this document. (Resolved conflict between this + statement and one that prohibited use of ANONYMOUS and PLAIN + SASL mechanisms.) + + +Harrison Expires September 2003 [Page 29] + + Authentication Methods for LDAPv3 + + Section 5.3.6 + + - Added a.x.bar.com to wildcard matching example on hostname + check. + + Section 6 + + - Added LDAP Association State Transition Tables to show the + various states through which an LDAP association may pass along + with the actions and decisions required to traverse from state + to state. + + Appendix A + + - Brought security terminology in line with IETF security glossary + throughout the appendix. + +F.2. Changes for draft-ldap-bis-authmeth-03 + + General + + - Added introductory notes and changed title of document and + references to conform to WG chair suggestions for the overall + technical specification. + + - Several issues--G.13, G.14, G.16, G.17--were resolved without + requiring changes to the document. + + Section 3 + + - Removed reference to /etc/passwd file and associated text. + + Section 4 + + - Removed sections 4.1, 4.2 and parts of section 4.3. This + information was being duplicated in the protocol specification + and will now reside there permanently. + Section 4.2 + + - changed words, "not recommended" to "strongly discouraged" + + Section 4.3 + + - Based on ldapbis WG discussion at IETF52 two sentences were + added indicating that clients SHOULD NOT send a DN value when + binding with the sasl choice and servers SHALL ignore any value + received in this circumstance. + - + + Section 8.3.1 + + - Generalized the language of this section to not refer to any + specific password attribute or to refer to the directory entry + as a "user" entry. + +Harrison Expires September 2003 [Page 30] + + Authentication Methods for LDAPv3 + + + Section 11 + + - Added security consideration regarding misuse of unauthenticated + access. + + - Added security consideration requiring access control to be + applied only to authenticated users and recommending it be + applied when reading sensitive information or updating directory + information. + + +F.3. Changes for draft-ldap-bis-authmeth-04 + + General + + - Changed references to use [RFCnnnn] format wherever possible. + (References to works in progress still use [name] format.) + - Various edits to correct typos and bring field names, etc. in + line with specification in [Protocol] draft. + + - Several issues--G.13, G.14, G.16, G.17--were resolved without + requiring changes to the document. + + Section 4.4.1. + + - Changed ABNF grammar to use productions that are like those in + the model draft. + + Section 5 + + - Removed sections 5.1, 5.2, and 5.4 that will be added to + [Protocol]. Renumbered sections to accommodate this change. + - + + Section 6 + + - Reviewed LDAP Association State table for completeness and + accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4 + respectively. Re-ordered several lines in the table to ensure + that actions are in ascending order (makes analyzing the table + much more logical). Added action A2 to several states where it + was missing and valid. Added actions A7 and A8 placeholders to + states S1, S2, S4 and S5 pending resolution of issue G.28. + + Section 11 + + - Modified security consideration (originally added in -03) + requiring access control to be applied only to authenticated + users. This seems nonsensical because anonymous users may have + access control applied to limit permissible actions. + - + Section 13 + + +Harrison Expires September 2003 [Page 31] + + Authentication Methods for LDAPv3 + + - Verified all normative references and moved informative + references to a new section 14. + +F.4. Changes for draft-ldap-bis-authmeth-05 + + General + + - General editory changes to fix punctuation, spelling, line + length issues, etc. + - Verified and updated intra- and inter-document references + throughout. + - Document-wide review for proper usage of RFC 2119 keywords with + several changes to correct improper usage. + + Abstract + - Updated to match current contents of documents. This was needed + due to movement of material on Bind and Start TLS operations to + [Protocol] in this revision. + + Section 3. + + - Renamed section to "Rationale for LDAPv3 Security Mechanisms" + and removed text that did not support this theme. Part of the + motivation for this change was to remove the implication of the + previous section title, "Required Security Mechanisms", and + other text found in the section that everything in the section + was a requirement + + - Information from several removed paragraphs that describe + deployment scenarios will be added Appendix A in the next + revision of the draft. + + + - Paragraph beginning, " If TLS is negotiated, the client MUST + discard all information..." was moved to section 5.1.7 and + integrated with related material there. + + - Paragraph beginning, "If a SASL security layer is negotiated..." + was moved to section 4.2 + + Section 4.l. + + - Changed wording of first paragraph to clarify meaning. + + Section 4.2. + - Added paragraph from section 3 of -04 beginning, "If a SASL + security layer is negotiated..." + + Section 4.3.3. + - Renamed to "Other SASL Mechanisms" and completely rewrote the + section (one sentence) to generalize the treatment of SASL + mechanisms not explicitly mentioned in this document. + + Section 4.4.1. + +Harrison Expires September 2003 [Page 32] + + Authentication Methods for LDAPv3 + + + - Added paragraph beginning, "The dnAuthzID choice allows client + applications..." to clarify whether DN form authorization + identities have to also have a corresponding directory entry. + This change was based on editor's perception of WG consensus. + + - Made minor clarifying edits in the paragraph beginning, "The + uAuthzID choice allows for compatibility..." + + Section 5.1.1. + + - Made minor clarifying edits in the last paragraph of the + section. + + Section 5.1.7. + + - Wording from section 3 paragraph beginning " If TLS is + negotiated, the client MUST discard all information..." was + moved to this section and integrated with existing text. + + Section 5.2. + + - Changed usage of "TLS connection" to "TLS session" throughout. + + - Removed empty section 5.2.1 and renumbered sections it had + previously contained. + + Section 8. + + - Added introductory paragraph at beginning of section. + + Section 8.1. + + - Changed term "data privacy" to "data confidentiality" to be + consistent with usage in rest of document. + + Section 8.2. + + - Changed first paragraph to require implementations that + implement *password-based* authentication to implement and + support DIGEST-MD5 SASL authentication. + + Section 11. + + - First paragraph: changed "session encryption" to "session + confidentiality protection" to be consistent with usage in rest + of document. + + Appendix A. + + - Began changes to incorporate information on deployment scenarios + removed from section 3. + + + +Harrison Expires September 2003 [Page 33] + + Authentication Methods for LDAPv3 + +Appendix G. Issues to be Resolved + + This appendix lists open questions and issues that need to be + resolved before work on this document is deemed complete. + +G.1. + + Section 1 lists 6 security mechanisms that can be used by LDAP + servers. I'm not sure what mechanism 5, "Resource limitation by + means of administrative limits on service controls" means. + + Status: resolved. Changed wording to "administrative service limits" + to clarify meaning. + +G.2. + + Section 2 paragraph 1 defines the term, "sensitive." Do we want to + bring this term and other security-related terms in alignment with + usage with the IETF security glossary (RFC 2828)? + + Status: resolved. WG input at IETF 51 was that we should do this, so + the appropriate changes have been made. + +G.3. + + Section 2, deployment scenario 2: What is meant by the term "secure + authentication function?" + + Status: resolved. Based on the idea that a "secure authentication + function" could be provided by TLS, I changed the wording to require + data confidentiality for sensitive authentication information and + data integrity for all authentication information. + +G.4. + + Section 3, deployment scenario 3: What is meant by the phrase, + "directory data is authenticated by the server?" + + Status: resolved. I interpreted this to mean the ability to ensure + the identity of the directory server and the integrity of the data + sent from that server to the client, and explictly stated such. + +G.5. + + Section 4 paragraph 3: What is meant by the phrase, "this means that + either this data is useless for faking authentication (like the Unix + "/etc/passwd" file format used to be)?" + + Status: resolved. Discussion at IETF 52 along with discussions with + the original authors of this material have convinced us that this + reference is simply too arcane to be left in place. In -03 the text + has been modified to focus on the need to either update password + information in a protected fashion outside of the protocol or to + + +Harrison Expires September 2003 [Page 34] + + Authentication Methods for LDAPv3 + + update it in session well protected against snooping, and the + reference to /etc/passwd has been removed. + +G.6. + + Section 4 paragraph 7 begins: "For a directory needing session + protection..." Is this referring to data confidentiality or data + integrity or both? + + Status: resolved. Changed wording to say, "For a directory needing + data security (both data integrity and data confidentiality)..." + +G.7. + + Section 4 paragraph 8 indicates that "information about the server + fetched fetched prior to the TLS negotiation" must be discarded. Do + we want to explicitly state that this applies to information fetched + prior to the *completion* of the TLS negotiation or is this going + too far? + + Status: resolved. Based on comments in the IETF 51 LDAPBIS WG + meeting, this has been changed to explicitly state, "fetched prior + to the initiation of the TLS negotiation..." + +G.8. + + Section 4 paragraph 9 indicates that clients SHOULD check the + supportedSASLMechanisms list both before and after a SASL security + layer is negotiated to ensure that they are using the best available + security mechanism supported mutually by the client and server. A + note at the end of the paragraph indicates that this is a SHOULD + since there are environments where the client might get a list of + supported SASL mechanisms from a different trusted source. + + I wonder if the intent of this could be restated more plainly using + one of these two approaches (I've paraphrased for the sake of + brevity): + + Approach 1: Clients SHOULD check the supportedSASLMechanisms + list both before and after SASL negotiation or clients SHOULD + use a different trusted source to determine available supported + SASL mechanisms. + + Approach 2: Clients MUST check the supportedSASLMechanisms list + both before and after SASL negotiation UNLESS they use a + different trusted source to determine available supported SASL + mechanisms. + + Status: resolved. WG input at IETF 51 was that Approach 1 was + probably best. I ended up keeping the basic structure similar to the + original to meet this intent. + +G.9. + + +Harrison Expires September 2003 [Page 35] + + Authentication Methods for LDAPv3 + + Section 6.3.1 states: "DSAs that map the DN sent in the bind request + to a directory entry with a userPassword attribute will... compare + [each value in the named user's entry]... with the presented + password." This implies that this applies only to user entries with + userPassword attributes. What about other types of entries that + might allow passwords and might store in the password information in + other attributes? Do we want to make this text more general? + + Status: resolved in -03 draft by generalizing section 8.3.1 to not + refer to any specific password attribute and by removing the term + "user" in referring to the directory entry specified by the DN in + the bind request. + +G.10 userPassword and simple bind + + We need to be sure that we don't require userPassword to be the only + attribute used for authenticating via simple bind. (See 2251 sec 4.2 + and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this. + On publication state something like: "This is the specific + implementation of what we discussed in our general reorg + conversation on the list." (Source: Kurt Zeilenga) + + Status: resolved in -03 draft by generalizing section 8.3.1 to not + refer to any specific password attribute and by removing the term + "user" in referring to the directory entry specified by the DN in + the bind request. + +G.11. Meaning of LDAP Association + + The original RFC 2830 uses the term "LDAP association" in describing + a connection between an LDAP client and server regardless of the + state of TLS on that connection. This term needs to be defined or + possibly changed. + + Status: resolved. at IETF 51 Bob Morgan indicated that the term + "LDAP association" was intended to distinguish the LDAP-level + connection from the TLS-level connection. This still needs to be + clarified somewhere in the draft. Added "LDAP association" to a + glossary in section 1. + +G.12. Is DIGEST-MD5 mandatory for all implementations? + + Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server + supports password based authentication...but the following makes it + sound mandatory to provide BOTH password authentication AND DIGEST- + MD5: + + "6.2. Digest authentication + + LDAP implementations MUST support authentication with a password + using the DIGEST-MD5 SASL mechanism for password protection, as + defined in section 6.1." + + The thing is for acl it would be nice (though not critical) to be + +Harrison Expires September 2003 [Page 36] + + Authentication Methods for LDAPv3 + + able to default the required authentication level for a subject to a + single "fairly secure" mechanism--if there is no such mandatory + authentication scheme then you cannot do that. (Source: Rob Byrne) + + Status: resolved. -00 version of the draft added a sentence at the + beginning of section 8.2 stating that LDAP server implementations + must support this method. + +G.13. Ordering of authentication levels requested + + Again on the subject of authentication level, is it possible to + define an ordering on authentication levels which defines their + relative "strengths" ? This would be useful in acl as you could say + things like"a given aci grants access to a given subject at this + authentication level AND ABOVE". David Chadwick raised this before + in the context of denying access to a subject at a given + authentication level, in which case he wanted to express "deny + access to this subject at this authentication level AND TO ALL + IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne) + + Status: out of scope. This is outside the scope of this document and + will not be addressed. + +G.14. Document vulnerabilities of various mechanisms + + While I'm here...in 2829, I think it would be good to have some + comments or explicit reference to a place where the security + properties of the particular mandatory authentication schemes are + outlined. When I say "security properties" I mean stuff like "This + scheme is vulnerable to such and such attacks, is only safe if the + key size is > 50, this hash is widely considered the best, etc...". + I think an LDAP implementor is likely to be interested in that + information, without having to wade through the security RFCs. + (Source: Rob Byrne) + + Status: out of scope. This is outside the scope of this document and + will not be addressed. + +G.15. Include a StartTLS state transition table + + The pictoral representation it is nominally based on is here (URL + possibly folded): + + http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram- + 1999-12-14.html + + (Source: Jeff Hodges) + + Status: In Process. Table provided in -03. Review of content for + accuracy in -04. Additional review is needed, plus comments from WG + members indicate that additional description of each state's meaning + would be helpful. + + + +Harrison Expires September 2003 [Page 37] + + Authentication Methods for LDAPv3 + +G.16. Empty sasl credentials question + + I spent some more time looking microscopically at ldap-auth-methods + and ldap-ext-tls drafts. The drafts say that the credential must + have the form dn:xxx or u:xxx or be absent, and although they don't + say what to do in the case of an empty octet string I would say that + we could send protocolError (claim it is a bad PDU). + + There is still the question of what to do if the credential is 'dn:' + (or 'u:') followed by the empty string. (Source: ariel@columbia.edu + via Jeff Hodges) + + Status: resolved. Kurt Zeilenga indicated during ldapbis WG + discussion at IETF 52 that SASL AuthzID credentials empty and absent + are equivalent in the latest SASL ID. This resolves the issue. + +G.17. Hostname check from MUST to SHOULD? + + I am uneasy about the hostname check. My experience from PKI with + HTTP probably is a contributing factor; we have people using the + short hostname to get to a server which naturally has the FQDN in + the certificate, no end of problems. I have a certificate on my + laptop which has the FQDN for the casse when the system is on our + Columbia network with a fixed IP; when I dial in however, I have + some horrible dialup name, and using the local https server becomes + annoying. Issuing a certificate in the name 'localhost' is not a + solution! Wildcard match does not solve this problem. For these + reasons I am inclined to argue for 'SHOULD' instead of + 'MUST' in paragraph... + + Also, The hostname check against the name in the certificate is a + very weak means of preventing man-in-the-middle attacks; the proper + solution is not here yet (SecureDNS or some equivalent). Faking out + DNS is not so hard, and we see this sort of thing in the press on a + pretty regular basis, where site A hijacks the DNS server for site B + and gets all their requests. Some mention of this should be made in + the draft. (Source: ariel@columbia.edu via Jeff Hodges) + + Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting, + this text will stand as it is. The check is a MUST, but the behavior + afterward is a SHOULD. This gives server implementations the room to + maneuver as needed. + + G.18. Must SASL DN exist in the directory? + + If the 'dn:' form of sasl creds is used, is it the intention of the + draft(ers) that this DN must exist in the directory and the client + will have the privileges associated with that entry, or can the + server map the sasl DN to perhaps some other DN in the directory, + in an implementation-dependent fashion? + + We already know that if *no* sasl credentials are presented, the DN + or altname in the client certificate may be mapped to a DN in an + implementation-dependent fashion, or indeed to something not in the + +Harrison Expires September 2003 [Page 38] + + Authentication Methods for LDAPv3 + + directory at all. (Right?) (Source: ariel@columbia.edu via Jeff + Hodges) + + Status: resolved. (11/12/02)Based on my research I propose that the + DN MUST exist in the directory when the DN form of sasl creds is + used. I have made this proposal to the ldapbis mailing list. + + (11/21/02) Feedback from mailing list has proposed removing this + paragraph entirely because (1) explicit assertion of authorization + identity should only be done when proxying (2) mapping of the + asserted authorization identity is implementation specific and + policy driven [SASL] section 4.2, and (3) keeping this paragraph is + not required for interoperability. + +G.19. DN used in conjunction with SASL mechanism + + We need to specify whether the DN field in Bind operation can/cannot + be used when SASL mechanism is specified. (source: RL Bob) + + Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two + sentences were added to section 4.3 indicating that clients SHOULD + NOT send a DN value when binding with the sasl choice and servers + SHALL ignore any value received in this circumstance. During edits + for -04 version of draft it was noted that [Protocol] section 4.2 + conflicts with this draft. The editor of [Protocol] has been + notified of the discrepancy, and they have been handled. + +G.20. Bind states + + Differences between unauthenticated and anonymous. There are four + states you can get into. One is completely undefined (this is now + explicitly called out in [Protocol]). This text needs to be moved + from [Protocol] to this draft. (source: Jim Sermersheim) + + Status: Resolved. There are four states: (1) no name, no password + (anon); (2) name, no password (anon); (3) no name, password + (invalid); (4) name, password (simple bind). States 1, 2, and 4 are + called out in [AuthMeth]. State 3 is called out in [Protocol]; this + seems appropriate based on review of alternatives. + +G.21. Misuse of unauthenticated access + + Add a security consideration that operational experience shows that + clients can misuse unauthenticated access (simple bind with name but + no password). Servers SHOULD by default reject authentication + requests that have a DN with an empty password with an error of + invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun)) + + Status: Resolved. Added to security considerations in รป03. + +G.22. Need to move StartTLS protocol information to [Protocol] + + Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and + they are [Protocol] -11. + +Harrison Expires September 2003 [Page 39] + + Authentication Methods for LDAPv3 + + +G.23. Split Normative and Non-normative references into separate +sections. + + Status: Resolved. Changes made in -04 + +G.24. What is the authentication state if a Bind operation is +abandoned? + + Status: In process. (11/12/02) This text was suggested to be added + to [Protocol] -11 to cover what happens if a bind operation is + abandoned: + + "If a server receives an Abandon request for a Bind operation, the + server SHOULD leave the connection in the anonymous state. Clients + that abandon a Bind operation MUST rebind after abandoning the Bind + request in order to have a known authentication state on the + connection." + + (11/21/02) Jim Sermersheim prposed the following wording on the + ldapbis mail list: "Authentication from earlier binds are + subsequently ignored. A failed or abandoned Bind Operation has the + effect of leaving the connection in an anonymous state. Clients MUST + rebind after abandoning a bind operation in order to determine a + known authentication state." + + Once this is resolved in [Protocol] the state table in section 6 of + [AuthMeth] will need to be updated to reflect the consensus wording. + +G.25. Difference between checking server hostname and server's +canonical DNS name in Server Identity Check? + + Section 5.1.6: I now understand the intent of the check (prevent + man-in-the-middle attacks). But what is the subtle difference + between the "server hostname" and the "server's canonical DNS name"? + (Source: Tim Hahn) + + Status: In Process. (11/12/02) Sent suggested wording change to this + paragraph to the ldapbis mail list and also asked for opinion as to + whether we should discuss the distinction between server DNS + hostname and server canonical DNS hostname in [AuthMeth]. + + (11/21/02): RL Bob Morgan will provide wording that allows + derivations of the name that are provided securely. + +6.26. Server Identity Check using servers located via SRV records + + Section 5.1.6: What should be done if the server was found using SRV + records based on the "locate" draft/RFC? (Source: Tim Hahn). + + Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08 + specifically calls out how the server identity should be performed + if the server is located using the method defined in that draft. + + +Harrison Expires September 2003 [Page 40] + + Authentication Methods for LDAPv3 + + This is the right location for this information, and the coverage + appears to be adequate. + +G.27 Inconsistency in effect of TLS closure on LDAP association. + + Section 5.4.1 of authmeth -03 (section 4.1 of RFC2830) states that + TLS closure alert will leave the LDAP association intact. Contrast + this with Section 5.5.2 (section 5.2 of RFC2830) that says that the + closure of the TLS connection MUST cause the LDAP association to + move to an anonymous authentication. + + Status: in process. (11/12/02) This is actually a [Protocol] issue + because these sections have now been moved to [Protocol] -11. I have + proposed the following text for Section 5.4.1 of [AuthMeth] -03 + (section 4.13.3.1 of [Protocol]) to resolve this apparent + discrepancy: + + "Either the client or server MAY terminate the TLS connection on an + LDAP association by sending a TLS closure alert. The LDAP + connection remains open for further communication after TLS closure + occurs although the authentication state of the LDAP connection is + affected (see [AuthMeth] section 5.2.2). + + (11/21/02): resolution to this is expected in [Protocol] -12 + +G.28 Ordering of external sources of authorization identities + + Section 4.3.2 implies that external sources of authorization + identities other than TLS are permitted. What is the behavior when + two external sources of authentication credentials are available + (e.g. TLS and IPsec are both present (is this possible?)) and a SASL + EXTERNAL Bind operation is performed? + + Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which + states that the decision to allow or disallow the asserted identity + is based on an implementation defined policy. + +G.29 Rewrite of Section 10, TLS Ciphersuites + + This section contains anachronistic references and needs to be + updated/rewritten in a way that provides useful guidance for future + readers in a way that will transcend the passage of time. + +G.30 Update to Appendix A, Example Deployment Scenarios + + This section needs to be updated to indicate which security + mechanisms and/or combinations of security mechanisms described + elsewhere in the document can provide the types of protections + suggested in this appendix. + + + + + +Harrison Expires September 2003 [Page 41] + diff --git a/doc/drafts/draft-ietf-ldapbis-dn-xx.txt b/doc/drafts/draft-ietf-ldapbis-dn-xx.txt new file mode 100644 index 0000000000..ac1882a6fb --- /dev/null +++ b/doc/drafts/draft-ietf-ldapbis-dn-xx.txt @@ -0,0 +1,731 @@ + + + + + + +INTERNET-DRAFT Editor: Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires in six months 4 May 2003 +Obsoletes: 2253 + + + LDAP: String Representation of Distinguished Names + + + +Status of Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + This document is intended to be, after appropriate review and + revision, submitted to the RFC Editor as a Standard Track document + replacing RFC 2253. Distribution of this memo is unlimited. + Technical discussion of this document will take place on the IETF LDAP + Revision (LDAPbis) Working Group mailing list + . Please send editorial comments directly + to the document editor . + + 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 + . The list of + Internet-Draft Shadow Directories can be accessed at + . + + Copyright 2003, The Internet Society. All Rights Reserved. + + Please see the Copyright section near the end of this document for + more information. + + +Abstract + + The X.500 Directory uses distinguished names (DNs) as primary keys to + entries in the directory. This document defines the string + representation used in the Lightweight Directory Access Protocol + (LDAP) to transfer distinguished names. The string representation is + + + +Zeilenga LDAP: Distinguished Names [Page 1] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + designed to give a clean representation of commonly used distinguished + names, while being able to represent any distinguished name. + + +Conventions + + 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 BCP 14 [RFC2119]. + + +1. Background and Intended Usage + + In X.500-based directory systems [X.500], including those accessed + using the Lightweight Directory Access Protocol (LDAP) [Roadmap], + distinguished names (DNs) are used to unambiguously refer to a + directory entry [X.501][Models]. + + The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. + In the X.500 Directory Access Protocol [X.511] (and other ITU-defined + directory protocols), DNs are encoded using the Basic Encoding Rules + (BER) [X.690]. In LDAP, DNs are represented in string form. + + It is important to have a common format to be able to unambiguously + represent a distinguished name. The primary goal of this + specification is ease of encoding and decoding. A secondary goal is + to have names that are human readable. It is not expected that LDAP + implementations with a human user interface would display these + strings directly to the user, but would most likely be performing + translations (such as expressing attribute type names in one of the + local national languages). + + This document defines the string representation of Distinguished Names + used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED + algorithm for converting a DN from its ASN.1 structured representation + to a string. Section 3 details how to convert a DN from a string to a + ASN.1 structured representation. + + While other documents may define other algorithms for converting a DN + from its ASN.1 structured representation to a string, all algorithms + MUST produce strings which adhere to the requirements of Section 3. + + This document does not define a canonical string representation for + DNs. Comparison of DNs for equality is to be performed in accordance + with the distinguishedNameMatch matching rule [Syntaxes]. + + This document is an integral part of the LDAP Technical Specification + [Roadmap]. + + + +Zeilenga LDAP: Distinguished Names [Page 2] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + This document obsoletes RFC 2253. Changes since RFC 2253 are + summarized in Appendix B. + + This specification assumes familiarity with X.500 [X.500], and the + concept of Distinguished Name [X.501][Models]. + + +2. Converting DistinguishedName from ASN.1 to a String + + X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished + name. The following is a variant provided for discussion purposes. + + DistinguishedName ::= RDNSequence + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + RelativeDistinguishedName ::= SET SIZE (1..MAX) OF + AttributeTypeAndValue + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue } + + This section defines the RECOMMENDED algorithm for converting a + distinguished name from an ASN.1 structured representation to an UTF-8 + [RFC2279] encoded Universal Character Set (UCS) [ISO10646] character + string representation. Other documents may describe other algorithms + for converting a distinguished name to a string, but only strings + which conform to the grammar defined in Section 3 MUST be produced by + LDAP implementations. + + +2.1. Converting the RDNSequence + + If the RDNSequence is an empty sequence, the result is the empty or + zero length string. + + Otherwise, the output consists of the string encodings of each + RelativeDistinguishedName in the RDNSequence (according to Section + 2.2), starting with the last element of the sequence and moving + backwards toward the first. + + The encodings of adjoining RelativeDistinguishedNames are separated by + a comma ("," U+002C) character. + + +2.2. Converting RelativeDistinguishedName + + + + +Zeilenga LDAP: Distinguished Names [Page 3] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + When converting from an ASN.1 RelativeDistinguishedName to a string, + the output consists of the string encodings of each + AttributeTypeAndValue (according to Section 2.3), in any order. + + Where there is a multi-valued RDN, the outputs from adjoining + AttributeTypeAndValues are separated by a plus sign ("+" U+002B) + character. + + +2.3. Converting AttributeTypeAndValue + + The AttributeTypeAndValue is encoded as the string representation of + the AttributeType, followed by an equals ("=" U+003D) character, + followed by the string representation of the AttributeValue. The + encoding of the AttributeValue is given in Section 2.4. + + If the AttributeType is defined to have a short name and that short + name is known to be registered [REGISTRY] as identifying the + AttributeType, that short name, a , is used. Otherwise the + AttributeType is encoded as the dotted-decimal encoding, a + , of its OBJECT IDENTIFIER. The and + is defined in [Models]. + + Implementations are not expected dynamically update their knowledge of + registered short names. However, implementations SHOULD provide a + mechanism to allow its knowledge of registered short names to be + updated. + + +2.4. Converting an AttributeValue from ASN.1 to a String + + If the AttributeType is of the dotted-decimal form, the AttributeValue + is represented by an number sign ("#" U+0023) character followed by + the hexadecimal encoding of each of the octets of the BER encoding of + the X.500 AttributeValue. This form is also used when the syntax of + the AttributeValue does not have a native string encoding defined for + it or the native string encoding is not restricted to UTF-8 encoded + UCS (or a subset of UCS) characters. This form may also be used in + other cases, such as when a reversible string representation is + desired (see Section 5.2). + + Otherwise, if the AttributeValue is of a syntax which has a native + string encoding, the value is converted first to a UTF-8 encoded UCS + string according to its syntax specification (see for example Section + 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any + of the following characters which need escaping, then that string can + be used as the string representation of the value. + + + + +Zeilenga LDAP: Distinguished Names [Page 4] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + - a space (" " U+0020) or number sign ("#" U+0023) occurring at + the beginning of the string; + + - a space (" " U+0020) character occurring at the end of the + string; + + - one of the characters """, "+", ",", ";", "<", ">", or "\" + (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C + respectively); + + - the null (U+0000) character. + + Other characters may be escaped. + + Each octet of the character to be escaped is replaced by a backslash + and two hex digits, which form a single octet in the code of the + character. Alternatively, if and only if the character to be escaped + is one of + + " ", """, "#", "+", ",", ";", "<", "=", ">", or "\" + (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B, + U+003C, U+003D, U+003E, U+005C respectively) + + it can be prefixed by a backslash ("\" U+0005C). + + Examples of the escaping mechanism are shown in Section 4. + + +3. Parsing a String back to a Distinguished Name + + The string representation of Distinguished Names is restricted to + UTF-8 [RFC2279] encoded characters from the Universal Character Set + (UCS) [ISO10646]. The structure of this string representation is + specified using the following Augmented BNF [RFC2234] grammar: + + distinguishedName = [ relativeDistinguishedName + *( COMMA relativeDistinguishedName ) ] + + relativeDistinguishedName = attributeTypeAndValue + *( PLUS attributeTypeAndValue ) + + attributeTypeAndValue = attributeType EQUALS attributeValue + + attributeType = descr / numericoid + + attributeValue = string / hexstring + + ; The UTF-8 string shall not contain NULL, ESC, or + + + +Zeilenga LDAP: Distinguished Names [Page 5] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + ; one of escaped, shall not start with SHARP or SPACE, + ; and shall must not end with SPACE. + string = [ (leadchar / pair) + [ *( stringchar / pair ) ( trailchar / pair ) ] ] + + leadchar = LUTF1 / UTFMB + LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A / + %x3D / %x3F-5B / %x5D-7F + + trailchar = TUTF1 / UTFMB + TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A / + %x3D / %x3F-5B / %x5D-7F + + stringchar = SUTF1 / UTFMB + SUTF1 = %x01-21 / %x23-2A / %x2D-3A / + %x3D / %x3F-5B / %x5D-7F + + pair = ESC ( ESC / special / hexpair ) + + special = escaped / SPACE / SHARP / EQUALS + + escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE + + hexstring = SHARP 1*hexpair + + hexpair = HEX HEX + + where the productions , , , , + , , , , , , , , + , , are defined in [Models]. + + Each , either a or a , refers to an + attribute type of an attribute value assertion (AVA). The + is followed by a and an . + The is either in or form. + + If in form, a LDAP string representation asserted value can + be obtained by replacing (left-to-right, non-recursively) each + appearing in the as follows: + replace with ; + replace with ; + replace with the octet indicated by the . + + If in form, a BER representation can be obtained from + converting each of the to the octet indicated by + the . + + One or more attribute values assertions, separated by , for a + + + +Zeilenga LDAP: Distinguished Names [Page 6] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + relative distinguished name. + + Zero or more relative distinguished names, separated by , for a + distinguished name. + + Implementations MUST recognize AttributeType name strings + (descriptors) listed in the following table, but MAY recognize other + name strings. + + String X.500 AttributeType + ------ -------------------------------------------- + CN commonName (2.5.4.3) + L localityName (2.5.4.7) + ST stateOrProvinceName (2.5.4.8) + O organizationName (2.5.4.10) + OU organizationalUnitName (2.5.4.11) + C countryName (2.5.4.6) + STREET streetAddress (2.5.4.9) + DC domainComponent (0.9.2342.19200300.100.1.25) + UID userId (0.9.2342.19200300.100.1.1) + + Implementations MAY recognize other DN string representations + (such as that described in RFC 1779). However, as there is no + requirement that alternative DN string representations to be + recognized (and, if so, how), implementations SHOULD only generate + DN strings in accordance with Section 2 of this document. + + +4. Examples + + This notation is designed to be convenient for common forms of + name. This section gives a few examples of distinguished names + written using this notation. First is a name containing three + relative distinguished names (RDNs): + + UID=jsmith,DC=example,DC=net + + Here is an example name containing three RDNs, in which the first + RDN is multi-valued: + + OU=Sales+CN=J. Smith,DC=example,DC=net + + This example shows the method of escaping of a comma in a common + name: + + CN=John Smith\, III,DC=example,DC=net + + An example name in which a value contains a carriage return + + + +Zeilenga LDAP: Distinguished Names [Page 7] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + character: + + CN=Before\0dAfter,DC=example,DC=net + + An example name in which an RDN was of an unrecognized type. The + value is the BER encoding of an OCTET STRING containing two octets + 0x48 and 0x69. + + 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com + + Finally, an example of an RDN commonName value consisting of 5 + letters: + + Unicode Letter Description UCS code UTF-8 Escaped + ------------------------------- -------- ------ -------- + LATIN CAPITAL LETTER L U+004C 0x4C L + LATIN SMALL LETTER U U+0075 0x75 u + LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D + LATIN SMALL LETTER I U+0069 0x69 i + LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87 + + could be written in printable ASCII (useful for debugging purposes): + + CN=Lu\C4\8Di\C4\87 + + +5. Security Considerations + + The following security considerations are specific to the handling of + distinguished names. LDAP security considerations are discussed in + [Protocol] and other documents comprising the LDAP Technical + Specification [Roadmap]. + + +5.1. Disclosure + + Distinguished Names typically consist of descriptive information about + the entries they name, which can be people, organizations, devices or + other real-world objects. This frequently includes some of the + following kinds of information: + + - the common name of the object (i.e. a person's full name) + - an email or TCP/IP address + - its physical location (country, locality, city, street address) + - organizational attributes (such as department name or affiliation) + + Most countries have privacy laws regarding the publication of + information about people. + + + +Zeilenga LDAP: Distinguished Names [Page 8] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + +5.2. Use of Distinguished Names in Security Applications + + The transformations of an AttributeValue value from its X.501 form to + an LDAP string representation are not always reversible back to the + same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules) + form. An example of a situation which requires the DER form of a + distinguished name is the verification of an X.509 certificate. + + For example, a distinguished name consisting of one RDN with one AVA, + in which the type is commonName and the value is of the TeletexString + choice with the letters 'Sam' would be represented in LDAP as the + string CN=Sam. Another distinguished name in which the value is still + 'Sam' but of the PrintableString choice would have the same + representation CN=Sam. + + Applications which require the reconstruction of the DER form of the + value SHOULD NOT use the string representation of attribute syntaxes + when converting a distinguished name to the LDAP format. Instead, + they SHOULD use the hexadecimal form prefixed by the number sign ('#') + as described in the first paragraph of Section 2.3. + + +6. Acknowledgment + + This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and + Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. + + This document is a product of the IETF LDAPBIS Working Group. + + +7. Document Editor's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + + +8. Normative References + + [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993). + + [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - + Specification of Basic Notation", X.680, 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14 (also RFC 2119). + + [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax + + + +Zeilenga LDAP: Distinguished Names [Page 9] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [Models] K. Zeilenga (editor), "LDAP: Directory Information + Models", draft-ietf-ldapbis-models-xx.txt, a work in + progress. + + [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", + draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. + + [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", + draft-ietf-ldapbis-protocol-xx.txt, a work in progress. + + [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", + draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. + + [Schema] K. Dally (editor), "LDAP: User Schema", + draft-ietf-ldapbis-user-schema-xx.txt, a work in + progress. + + [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC + 10646-1 : 1993. + + +9. Informative References + + [X.500] "The Directory -- overview of concepts, models and + services," ITU-T Rec. X.500(1993). + + [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, + Canonical, and Distinguished Encoding Rules", X.690, + 1994. + + [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also + RFC 3383), September 2002. + + [RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) - + Technical Specification", RFC 2849, June 2000. + + +Appendix A. Presentation Issues + + This appendix is provided for informational purposes only, it is not a + normative part of this specification. + + + + +Zeilenga LDAP: Distinguished Names [Page 10] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + The string representation described in this document is not intended + to be presented to humans without translation. However, at times it + may be desirable to present non-translated DN strings to users. This + section discusses presentation issues associated with non-translated + DN strings. Presentation of translated DN strings issues are not + discussed in this appendix. Transcoding issues are also not discussed + in this appendix. + + This appendix provides guidance for applications presenting DN strings + to users. This section is not comprehensive, it does not discuss all + presentation issues which implementors may face. + + Not all user interfaces are capable of displaying the full set of UCS + characters. Some UCS characters are not displayable. + + It is recommended that human interfaces use the optional hex pair + escaping mechanism (Section 2.3) to produce a string representation + suitable for display to the user. For example, an application can + generate a DN string for display which escapes all non-printable + characters appearing in the AttributeValue's string representation (as + demonstrated in the final example of Section 4). + + When a DN string is displayed in free form text, it is often necessary + to distinguish the DN string from surrounding text. While this is + often done with white space (as demonstrated in Section 4), it is + noted that DN strings may end with white space. Careful readers of + Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may + only appear in the DN string if escaped. These characters are + intended to be used in free form text to distinguish a DN string from + surrounding text. For example, distinguished the string + representation of the DN comprised of one RDN consisting of the AVA: + the commonName (CN) value "Sam " from the surrounding text. It should + be noted to the user that the wrapping "<" and ">" characters are not + part of the DN string. + + DN strings can be quite long. It is often desirable to line-wrap + overly long DN strings in presentations. Line wrapping should be done + by inserting white space after the RDN separator character or, if + necessary, after the AVA separator character. It should be noted to + the user that the inserted white space is not part of the DN string + and is to be removed before use in LDAP. For example, + + The following DN string is long: + CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, + O=OpenLDAP Foundation,ST=California,C=US + so it has been line-wrapped for readability. The extra white + space is to be removed before the DN string is used in LDAP. + + + + +Zeilenga LDAP: Distinguished Names [Page 11] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + It is not advised to insert white space otherwise as it may not be + obvious to the user which white space is part of the DN string and + which white space was added for readability. + + Another alternative is to use the LDAP Data Interchange Format (LDIF) + [RFC2849]. For example, + + # This entry has a long DN... + dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores, + O=OpenLDAP Foundation,ST=California,C=US + CN: Kurt D. Zeilenga + SN: Zeilenga + objectClass: person + + +Appendix B. Changes made since RFC 2253 + + This appendix is provided for informational purposes only, it is not a + normative part of this specification. + + The following substantive changes were made to RFC 2253: + - Removed IESG Note. The IESG Note has been addressed. + - Clarified (in Section 1), that this document does not define a + canonical string representation. + - Replaced specification of additional requirements for LDAPv2 + implementations which also support LDAPv3 (RFC 2253, Section 4) + with a statement (in Section 3) allowing recognition of + alternative string representations. + - Clarified (in Section 2.3) that the "published" table of names + which may be appear in DNs is the table which Section 2.3 + provides. Remove "as an example" language. Noted this table is + not extensible. Added statement (in Section 3) allowing + recognition of additional names. Added security considerations + (Section 5.3) regarding the use of other names. + - Updated Section 2.3 to indicate attribute type name strings are + case insensitive. + - Updated Section 2.4 to allow hex pair escaping of all characters + and clarified escaping for when multiple octet UTF-8 characters + are present. + - Rewrote Section 3 to use ABNF as defined in RFC 2234. + - Rewrote Section 3 ABNF to be consistent with 2.4. + - Updated Section 3 to describe how to parse elements of the + grammar. + - Rewrote examples. + - Added reference to documentations containing general LDAP security + considerations. + - Added discussion of presentation issues (Appendix A). + - Added this appendix. + + + +Zeilenga LDAP: Distinguished Names [Page 12] + +INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003 + + + In addition, numerous editorial changes were made. + + +Copyright 2003, The Internet Society. 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 AUTHORS, 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. + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga LDAP: Distinguished Names [Page 13] + diff --git a/doc/drafts/draft-ietf-ldapbis-filter-xx.txt b/doc/drafts/draft-ietf-ldapbis-filter-xx.txt new file mode 100644 index 0000000000..33790efcf2 --- /dev/null +++ b/doc/drafts/draft-ietf-ldapbis-filter-xx.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group M. Smith, Editor +Request for Comments: DRAFT Netscape Communications Corp. +Obsoletes: RFC 2254 T. Howes +Expires: 28 August 2003 Opsware, Inc. + 28 February 2003 + + + LDAP: String Representation of Search Filters + + + + +1. Status of this Memo + + This document is an Internet-Draft and is subject to 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Discussion of this document should take place on the LDAP (v3) + Revision (ldapbis) Working Group mailing list . + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +2. Abstract + + LDAP search filters are transmitted in the LDAP protocol using a + binary representation that is appropriate for use on the network. + This document defines a human-readable string representation of LDAP + search filters that is appropriate for use in LDAP URLs and in other + applications. + + + + + +Smith & Howes Intended Category: Standards Track [Page 1] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + +3. Table of Contents + +1. Status of this Memo............................................1 +2. Abstract.......................................................1 +3. Table of Contents..............................................2 +4. Introduction...................................................2 +5. LDAP Search Filter Definition..................................2 +6. String Search Filter Definition................................4 +7. Examples.......................................................5 +8. Security Considerations........................................7 +9. Normative References...........................................7 +10. Informative References.........................................8 +11. Acknowledgments................................................8 +12. Authors' Address...............................................8 +13. Full Copyright Statement.......................................9 +14. Appendix A: Changes Since RFC 2254.............................9 +14.1. Technical Changes...........................................9 +14.2. Editorial Changes...........................................10 +15. Appendix B: Changes Since Previous Document Revision...........11 +15.1. Technical Changes...........................................11 +15.2. Editorial Changes...........................................11 + +4. Introduction + + The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a + network representation of a search filter transmitted to an LDAP + server. Some applications may find it useful to have a common way of + representing these search filters in a human-readable form; LDAP URLs + are an example of one such application. This document defines a + human-readable string format for representing the full range of + possible LDAP version 3 search filters, including extended match + filters. + + This document is an integral part of the LDAP Technical + Specification [Roadmap]. + + This document replaces RFC 2254. Changes to RFC 2254 are summarized + in Appendix A. + + 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 BCP 14 [RFC2119]. + +5. LDAP Search Filter Definition + + An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as + follows: + + + + +Smith & Howes Intended Category: Standards Track [Page 2] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + Filter ::= CHOICE { + and [0] SET SIZE (1..MAX) OF Filter, + or [1] SET SIZE (1..MAX) OF Filter, + not [2] Filter, + equalityMatch [3] AttributeValueAssertion, + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeDescription, + approxMatch [8] AttributeValueAssertion, + extensibleMatch [9] MatchingRuleAssertion } + + SubstringFilter ::= SEQUENCE { + type AttributeDescription, + -- at least one must be present, + -- initial and final can occur at most once + substrings SEQUENCE OF CHOICE { + initial [0] AssertionValue, + any [1] AssertionValue, + final [2] AssertionValue } } + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + AttributeDescription ::= LDAPString + -- Constrained to attributedescription + -- [Models] + + AttributeValue ::= OCTET STRING + + MatchingRuleId ::= LDAPString + + AssertionValue ::= OCTET STRING + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- ISO 10646 characters + + where the LDAPString above is limited to the UTF-8 encoding [RFC2279] + of the ISO 10646 character set [ISO10646]. The AttributeDescription + is a string representation of the attribute description and is + defined in [Protocol]. The AttributeValue and AssertionValue OCTET + + + +Smith & Howes Intended Category: Standards Track [Page 3] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + STRING have the form defined in [Syntaxes]. The Filter is encoded + for transmission over a network using the Basic Encoding Rules + defined in [ASN.1], with simplifications described in [Protocol]. + +6. String Search Filter Definition + + The string representation of an LDAP search filter is a string of + UTF-8 encoded ISO 10646-1 characters that is defined by the following + grammar, following the ABNF notation defined in [RFC2234]. The + productions used that are not defined here are defined in section 1.3 + (Common ABNF Productions) of [Models] unless otherwise noted. The + filter format uses a prefix notation. + + filter = LPAREN filtercomp RPAREN + filtercomp = and / or / not / item + and = AMPERSAND filterlist + or = VERTBAR filterlist + not = EXCLAMATION filter + filterlist = 1*filter + item = simple / present / substring / extensible + simple = attr filtertype assertionvalue + filtertype = equal / approx / greater / less + equal = EQUALS + approx = TILDE EQUALS + greater = RANGLE EQUALS + less = LANGLE EQUALS + extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue + / [dnattrs] matchingrule COLON EQUALS assertionvalue + / COLON EQUALS assertionvalue + present = attr EQUALS ASTERIX + substring = attr EQUALS [initial] any [final] + initial = assertionvalue + any = ASTERIX *(assertionvalue ASTERIX) + final = assertionvalue + attr = attributedescription + ; The attributedescription rule is defined in + ; Section 2.5 of [Models]. + dnattrs = COLON "dn" + matchingrule = COLON oid + assertionvalue = valueencoding + ; The rule is used to encode an + ; from Section 4.1.6 of [Protocol]. + valueencoding = 0*(normal / escaped) + normal = UTF1SUBSET / UTFMB + escaped = ESC HEX HEX + UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F + ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, + ; RPAREN, ASTERIX, and ESC. + + + +Smith & Howes Intended Category: Standards Track [Page 4] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + EXCLAMATION = %x21 ; exclamation mark ("!") + AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") + ASTERIX = %x2A ; asterix ("*") + COLON = %x3A ; colon (":") + VERTBAR = %x7C ; vertical bar (or pipe) ("|") + TILDE = %x7E ; tilde ("~") + + + Note that although both the and productions in + the grammar above can produce the "attr=*" construct, this construct + is used only to denote a presence filter. + + The rule ensures that the entire filter string is a + valid UTF-8 string and provides that the octets that represent the + ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII + 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a + backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits + representing the value of the encoded octet. + + This simple escaping mechanism eliminates filter-parsing ambiguities + and allows any filter that can be represented in LDAP to be + represented as a NUL-terminated string. Other octets that are part of + the set may be escaped using this mechanism, for example, + non-printing ASCII characters. + + For AssertionValues that contain UTF-8 character data, each octet of + the character to be escaped is replaced by a backslash and two hex + digits, which form a single octet in the code of the character. + + For example, the filter checking whether the "cn" attribute contained + a value with the character "*" anywhere in it would be represented as + "(cn=*\2a*)". + + As indicated by the valueencoding rule, implementations MUST escape + all octets greater than 0x7F that are not part of a valid UTF-8 + encoding sequence when they generate a string representation of a + search filter. Since RFC 2254 does not clearly define the term + "string representation" (and in particular does mention that the + string representation of an LDAP search filter is a string of UTF-8 + encoded ISO 10646-1 characters) implementations SHOULD accept as + input strings that include invalid UTF-8 octet sequences. + +7. Examples + + This section gives a few examples of search filters written using + this notation. + + (cn=Babs Jensen) + + + +Smith & Howes Intended Category: Standards Track [Page 5] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + (!(cn=Tim Howes)) + (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) + (o=univ*of*mich*) + (seeAlso=) + + The following examples illustrate the use of extensible matching. + + (cn:1.2.3.4.5:=Fred Flintstone) + (cn:=Betty Rubble) + (sn:dn:2.4.6.8.10:=Barney Rubble) + (o:dn:=Ace Industry) + (:1.2.3:=Wilma Flintstone) + (:dn:2.4.6.8.10:=Dino) + (:=Fred Flintstone) + + The first example shows use of the matching rule "1.2.3.4.5". + + The second example demonstrates use of a MatchingRuleAssertion form + without a matchingRule. + + The third example illustrates the use of the ":dn" notation to + indicate that matching rule "2.4.6.8.10" should be used when making + comparisons, and that the attributes of an entry's distinguished name + should be considered part of the entry when evaluating the match. + + The fourth example denotes an equality match, except that DN + components should be considered part of the entry when doing the + match. + + The fifth example is a filter that should be applied to any attribute + supporting the matching rule given (since the attr has been omitted). + + The sixth example is also a filter that should be applied to any + attribute supporting the matching rule given. Attributes supporting + the matching rule contained in the DN should also be considered. + + The seventh and final example is a filter that should be applied to + any attribute (since both the attr and matching rule have been + omitted). + + The following examples illustrate the use of the escaping mechanism. + + (o=Parens R Us \28for all your parenthetical needs\29) + (cn=*\2A*) + (filename=C:\5cMyFile) + (bin=\00\00\00\04) + (sn=Lu\c4\8di\c4\87) + (1.3.6.1.4.1.1466.0=\04\02\48\69) + + + +Smith & Howes Intended Category: Standards Track [Page 6] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + The first example shows the use of the escaping mechanism to + represent parenthesis characters. The second shows how to represent a + "*" in an assertion value, preventing it from being interpreted as a + substring indicator. The third illustrates the escaping of the + backslash character. + + The fourth example shows a filter searching for the four-byte value + 0x00000004, illustrating the use of the escaping mechanism to + represent arbitrary data, including NUL characters. + + The fifth example illustrates the use of the escaping mechanism to + represent various non-ASCII UTF-8 characters. + + The sixth and final example demonstrates assertion of a BER encoded + value. + +8. Security Considerations + + This memo describes a string representation of LDAP search filters. + While the representation itself has no known security implications, + LDAP search filters do. They are interpreted by LDAP servers to + select entries from which data is retrieved. LDAP servers should + take care to protect the data they maintain from unauthorized access. + + Please refer to the Security Considerations sections of [Protocol] + and [AuthMeth] for more information. + +9. Normative References + + [ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and + Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. + + [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and + Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth- + xx.txt, a work in progress. + + [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993. + + [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", + draft-ietf-ldapbis-models-xx.txt, a work in progress. + + [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- + ietf-ldapbis-protocol-xx.txt, a work in progress. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14 (also RFC 2119), March 1997. + + + + +Smith & Howes Intended Category: Standards Track [Page 7] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + RFC 2279, January 1998. + + [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road + Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. + + [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- + syntaxes-xx.txt, a work in progress. + + +10. Informative References + + None. + + +11. Acknowledgments + + This document replaces RFC 2254 by Tim Howes. Changes included in + this revised specification are based upon discussions among the + authors, discussions within the LDAP (v3) Revision Working Group + (ldapbis), and discussions within other IETF Working Groups. The + contributions of individuals in these working groups is gratefully + acknowledged. + + +12. Authors' Address + + Mark Smith, Editor + Netscape Communications Corp. + 360 W. Caribbean Drive + Sunnyvale, CA 94089 + USA + +1 650 937-3477 + mcs@netscape.com + + Tim Howes + Opsware, Inc. + 599 N. Mathilda Ave. + Sunnyvale, CA 94085 + USA + +1 408 744-7509 + howes@opsware.com + + + + + + +Smith & Howes Intended Category: Standards Track [Page 8] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + +13. 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. + + +14. Appendix A: Changes Since RFC 2254 + +14.1. Technical Changes + + The following technical changes were made to the contents of the + "String Search Filter Definition" section: + + Added statement that the string representation is a string of UTF-8 + encoded ISO 10646-1 characters. + + Revised all of the ABNF to use common productions from [Models]. + + Replaced the "value" rule with a new "assertionvalue" rule within the + "simple", "extensible", and "substring" ("initial", "any", and + "final") rules. This matches a change made in [Syntaxes]. + + Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more + precisely reference productions from the [Models] and [Protocol] + documents. + + + +Smith & Howes Intended Category: Standards Track [Page 9] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + Introduced the "valueencoding" and associated "normal" and "escaped" + rules to reduce the dependence on descriptive text. The "normal" + production restricts filter strings to valid UTF-8 sequences. + + Added a third option to the "extensible" production to allow creation + of a MatchingRuleAssertion that only has a matchValue. + + Added a statement about expected behavior in light of RFC 2254's lack + of a clear definition of "string representation." + + +14.2. Editorial Changes + + Changed document title to include "LDAP:" prefix. + + IESG Note: removed note about lack of satisfactory mandatory + authentication mechanisms. + + Header and "Authors' Addresses" sections: added Mark Smith as the + document editor and updated affiliation and contact information. + + "Table of Contents" section: added. + + Copyright: updated the year. + + "Abstract" section: separated from introductory material. + + "Introduction" section: new section; separated from the Abstract. + Updated second paragraph to indicate that RFC 2254 is replaced by + this document (instead of RFC 1960). Added reference to the [Roadmap] + document. + + "LDAP Search Filter Definition" section: made corrections to the + LDAPv3 search filter ABNF so it matches that used in [Protocol]. + + Clarified the definition of 'value' (now 'assertionvalue') to take + into account the fact that it is not precisely an AttributeAssertion + from [Protocol] section 4.1.6 (special handling is required for some + characters). Added a note that each octet of a character to be + escaped is replaced by a backslash and two hex digits, which + represent a single octet. + + "Examples" section: added five additional examples: (seeAlso=), + (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), (:=Fred Flintstone), + and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a + value" with "an assertion value". + + "Security Considerations" section: added references to [Protocol] and + + + +Smith & Howes Intended Category: Standards Track [Page 10] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + [AuthMeth]. + + "Normative References" section: renamed from "References" per new RFC + guidelines. Changed from [1] style to [Protocol] style throughout the + document. Added entries for [ISO10646], [RFC2119], [AuthMeth], + [Models], and [Roadmap] and updated UTF-8 reference to RFC 2279. + Replaced RFC 822 reference with a reference to RFC 2234. + + "Informative References" section: added for clarity. + + "Acknowledgments" section: added. + + "Appendix A: Changes Since RFC 2254" section: added. + + "Appendix B: Changes Since Previous Document Revision" section: + added. + + +15. Appendix B: Changes Since Previous Document Revision + + This appendix lists all changes relative to the last published + revision, draft-ietf-ldapbis-filter-03.txt. Note that when + appropriate these changes are also included in Appendix A, but are + also included here for the benefit of the people who have already + reviewed draft-ietf-ldapbis-filter-03.txt. This section will be + removed before this document is published as an RFC. + + +15.1. Technical Changes + + "String Search Filter Definition" section: Added statement that the + string representation is a string of UTF-8 encoded ISO 10646-1 + characters and statement about expected behavior in light of RFC + 2254's lack of a clear definition of "string representation." + + "String Search Filter Definition" section: Revised all of the ABNF to + use common productions from [Models]. Revised the "normal" + production to restrict filter strings to valid UTF-8 sequences. + + +15.2. Editorial Changes + + "Status of this Memo" section: updated boilerplate to match current + I-D guidelines. + + "Examples" section: removed ;binary from an example. + + "LDAP Search Filter Definition " section: updated section references + + + +Smith & Howes Intended Category: Standards Track [Page 11] + +INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003 + + + to match current LDAPBis drafts. Made minor changes to the ASN.1 so + it exactly matches that used in the Protocol document (added + comments). + + "Normative References" section: added references to [ISO10646], + [RFC2119] and [Models]. + + "Informative References" section: added for clarity. + + Updated copyright year to 2003. + + +This Internet Draft expires on 28 August 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smith & Howes Intended Category: Standards Track [Page 12] + diff --git a/doc/drafts/draft-ietf-ldapbis-models-xx.txt b/doc/drafts/draft-ietf-ldapbis-models-xx.txt new file mode 100644 index 0000000000..38d44aa8cb --- /dev/null +++ b/doc/drafts/draft-ietf-ldapbis-models-xx.txt @@ -0,0 +1,2747 @@ + + + + + + +INTERNET-DRAFT Editor: Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires in six months 1 March 2003 +Obsoletes: RFC 2251, RFC 2252, RFC 2256 + + + + LDAP: Directory Information Models + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + This document is intended to be published as a Standard Track RFC. + Distribution of this memo is unlimited. Technical discussion of this + document will take place on the IETF LDAP Revision Working Group + mailing list . Please send editorial + comments directly to the author . + + 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 + . The list of + Internet-Draft Shadow Directories can be accessed at + . + + Copyright 2003, The Internet Society. All Rights Reserved. Please + see the Copyright section near the end of this document for more + information. + + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an Internet + protocol for accessing distributed directory services which act in + accordance with X.500 data and service models. This document + describes the X.500 Directory Information Models, as used in LDAP. + + + + +Zeilenga LDAP Models [Page 1] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + +Table of Contents + + Status of this Memo 1 + Abstract + Table of Contents 2 + 1. Introduction 3 + 1.1. Relationship to Other LDAP Specifications + 1.2. Relationship to ITU Specifications + 1.3. Conventions 4 + 1.4. Common ABNF Productions + 2. Model of Directory User Information 6 + 2.1. The Directory Information Tree + 2.2. Naming of Entries 7 + 2.3. Structure of an Entry 8 + 2.4. Object Classes + 2.5. Attribute Descriptions 11 + 2.6. Alias Entries 15 + 3. Directory Administrative and Operational Information 16 + 3.1. Subtrees + 3.2. Subentries 17 + 3.3. The 'objectClass' attribute + 3.4. Operational attributes 18 + 4. Directory Schema 20 + 4.1. Schema Definitions 21 + 4.2. Subschema Subentries 30 + 4.3. 'extensibleObject' 34 + 4.4. Subschema Discovery + 5. DSA (Server) Informational Model + 5.1. Server-specific Data Requirements 35 + 6. Other Considerations 38 + 6.1. Preservation of User Information + 6.2. Short Names + 6.3. Cache and Shadowing 39 + 7. Implementation Guidelines 40 + 7.1. Server Guidelines + 7.2. Client Guidelines + 8. Security Considerations 41 + 9. IANA Considerations + 10. Acknowledgments 42 + 11. Author's Address + 12. References + 12.1. Normative References + 12.2. Informative References 43 + Appendix A. Changes + A.1 Changes to RFC 2251 44 + A.2 Changes to RFC 2252 46 + A.3 Changes to RFC 2256 47 + Copyright + + + +Zeilenga LDAP Models [Page 2] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + +1. Introduction + + This document discusses the X.500 Directory Information Models + [X.501], as used by the Lightweight Directory Access Protocol (LDAP) + [Roadmap]. + + The Directory is "a collection of open systems cooperating to provide + directory services" [X.500]. The information held in the Directory is + collectively known as the Directory Information Base (DIB). A + Directory user, which may be a human or other entity, accesses the + Directory through a client (or Directory User Agent (DUA)). The + client, on behalf of the directory user, interacts with one or more + servers (or Directory System Agents (DSA)). A server holds a fragment + of the DIB. + + The DIB contains two classes of information: + + 1) user information (e.g., information provided and administrated + by users). Section 2 describes the Model of User Information. + + 2) administrative and operational information (e.g., information + used to administer and/or operate the directory). Section 3 + describes the model of Directory Administrative and Operational + Information. + + These two models, referred to as the generic Directory Information + Models, describe how information is represented in the Directory. + These generic models provide a framework for other information models. + Section 4 discusses the subschema information model and subschema + discovery. Section 5 discusses the DSA (Server) Informational Model. + + Other X.500 information models, such as access control, collective + attribute, distribution knowledge, and replication knowledge + information models, may be adapted for use in LDAP. Specification of + how these models apply to LDAP is left to future documents. + + +1.1. Relationship to Other LDAP Specifications + + This document is a integral part of the LDAP technical specification + [Roadmap] which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as + portions of sections 4 and 6. Appendix A.1 summaries changes to these + sections. The remainder of RFC 2251 is obsoleted by the [Protocol], + [AuthMeth], and [Roadmap] documents. + + + + +Zeilenga LDAP Models [Page 3] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 + summaries changes to these sections. The remainder of RFC 2252 is + obsoleted by [Syntaxes] and [Schema]. + + This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. + Appendix A.3 summarizes changes to these sections. The remainder of + RFC 2256 is obsoleted by [Schema] and [Syntaxes]. + + +1.2. Relationship to X.501 + + This document includes material, with and without adaptation, from the + [X.501]. Due to the adaptation, the material included in this + document takes precedence. + + +1.3. Conventions + + 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 BCP 14 [RFC2119]. + + Schema definitions are provided using LDAP description formats (as + defined in Section 4.1). Definitions provided here are formatted + (line wrapped) for readability. Matching rules and LDAP syntaxes + referenced in these definitions are specified in [Syntaxes]. + + +1.4. Common ABNF Productions + + A number of syntaxes in this document are described using Augmented + Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a + number of syntaxes defined in other documents) rely on the following + common productions: + + keystring = leadkeychar *keychar + leadkeychar = ALPHA + keychar = ALPHA / DIGIT / HYPHEN + + number = DIGIT / ( LDIGIT 1*DIGIT ) + + ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" + DIGIT = %x30 / LDIGIT ; "0"-"9" + LDIGIT = %x31-39 ; "1"-"9" + + HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f + + SP = 1*SPACE ; one or more " " + + + +Zeilenga LDAP Models [Page 4] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + WSP = 0*SPACE ; zero or more " " + + NULL = %x00 ; null (0) + SPACE = %x20 ; space (" ") + DQUOTE = %x22 ; quote (""") + SHARP = %x23 ; octothorpe (or sharp sign) ("#") + DOLLAR = %x24 ; dollar sign ("$") + SQUOTE = %x27 ; single quote ("'") + LPAREN = %x28 ; left paren ("(") + RPAREN = %x29 ; right paren (")") + PLUS = %x2B ; plus sign ("+") + COMMA = %x2C ; comma (",") + HYPHEN = %x2D ; hyphen ("-") + DOT = %x2E ; period (".") + SEMI = %x3B ; semicolon (";") + LANGLE = %x3C ; left angle bracket ("<") + EQUALS = %x3D ; equals sign ("=") + RANGLE = %x3E ; right angle bracket (">") + X = %x58 ; uppercase x ("X") + ESC = %x5C ; backslash ("\") + USCORE = %x5F ; underscore ("_") + LCURLY = %x7B ; left curly brace "{" + RCURLY = %x7D ; right curly brace "}" + + ; Any UTF-8 character + UTF8 = UTF1 / UTFMB + UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 + UTF0 = %x80-BF + UTF1 = %x00-7F + UTF2 = %xC0-DF 1(UTF0) + UTF3 = %xE0-EF 2(UTF0) + UTF4 = %xF0-F7 3(UTF0) + UTF5 = %xF8-FB 4(UTF0) + UTF6 = %xFC-FD 5(UTF0) + + ; Any octet + OCTET = %x00-FF + + Object identifiers are represented in LDAP using a dot-decimal format + conforming to the ABNF: + + numericoid = number *( DOT number ) + + Short names, also known as descriptors, are used as more readable + aliases for object identifiers. Short names are case insensitive and + conform to the ABNF: + + descr = keystring + + + +Zeilenga LDAP Models [Page 5] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + Where either an object identifier or a short name may be specified, + the following production is used: + + oid = descr / numericoid + + While the form is generally preferred when the usage is + restricted to short names referring to object identifiers which + identify like kinds of objects (e.g., attribute type descriptions, + matching rule descriptions, object class descriptions), the + form should be used when the object identifiers may + identify multiple kinds of objects or when an unambiguous short name + (descriptor) is not available. + + When the form is used, the representation SHALL be considered + invalid if the usage is not restricted as discussed above or the + implementation cannot determine unambiguously which object identifier + the refers to. + + Short Names (descriptors) are discussed further in Section 6.2. + + +2. Model of Directory User Information + + As [X.501] states: + + The purpose of the Directory is to hold, and provide access to, + information about objects of interest (objects) in some 'world'. + An object can be anything which is identifiable (can be named). + + An object class is an identified family of objects, or conceivable + objects, which share certain characteristics. Every object belongs + to at least one class. An object class may be a subclass of other + object classes, in which case the members of the former class, the + subclass, are also considered to be members of the latter classes, + the superclasses. There may be subclasses of subclasses, etc., to + an arbitrary depth. + + A directory entry, a named collection of information, is the basic + unit of information held in the Directory. There are multiple kinds + of directory entries. + + An object entry represents a particular object. An alias entry + provides alternative naming. A subentry holds administrative and/or + operational information. + + The set of entries representing the DIB are organized hierarchically + in a tree structure known as the Directory Information Tree (DIT). + + + + +Zeilenga LDAP Models [Page 6] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + Section 2.1 describes the Directory Information Tree + Section 2.2 discusses naming of entries. + Section 2.3 discusses the structure of entries. + Section 2.4 discusses object classes. + Section 2.5 discusses attribute descriptions. + Section 2.6 discusses alias entries. + + +2.1. The Directory Information Tree + + As noted above, the DIB is composed of a set of entries organized + hierarchically in a tree structure known as the Directory Information + Tree (DIT). Specifically, a tree where vertices are the entries. + + The arcs between vertices define relations between entries. If an arc + exists from X to Y, then the entry at X is the immediate superior of Y + and Y is the immediate subordinate of X. An entry's superiors are the + entry's immediate superior and its superiors. An entry's subordinates + are all of its immediate subordinates and their subordinates. + + Similarly, the superior/subordinate relationship between object + entries can be used to derive a relation between the objects they + represent. DIT structure rules can be used to govern relationships + between objects. + + Note: An entry's immediate superior is also known as the entry's + parent and an entry's immediate subordinate is also known as the + entry's child. Entries which have the same parent are known as + siblings. + + +2.2. Naming of Entries + +2.2.1. Relative Distinguished Names + + Each entry is named relative to its immediate superior. This relative + name, known as its Relative Distinguished Name (RDN) [X.501], is + composed of an unordered set of one or more attribute value assertions + (AVA) consisting of an attribute description with zero options and an + attribute value. These AVAs are chosen from the attributes of the + entry. + + An entry's relative distinguished name must be unique among all + immediate subordinates of the entry's immediate superior (i.e., all + siblings). + + The following are example string representations of RDNs [LDAPDN]: + + + + +Zeilenga LDAP Models [Page 7] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + UID=12345 + OU=Engineering + CN=Kurt Zeilenga+L=Redwood Shores + + The last is an example of a multi-valued RDN. That is, an RDN + composed of multiple AVAs. + + +2.2.2. Distinguished Names + + An entry's fully qualified name, known as its Distinguished Name (DN) + [X.501], is the concatenation of its RDN and its immediate superior's + DN. A Distinguished Name unambiguously refers to an entry in the + tree. The following are example string representations of DNs + [LDAPDN]: + + UID=nobody@example.com,DC=example,DC=com + CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US + + +2.2.3. Alias Names + + An alias, or alias name, is "an name for an object, provided by the + use of alias entries" [X.501]. Alias entries are described in Section + 2.6. + + +2.3. Structure of an Entry + + An entry consists of a set of attributes which hold information about + the object which entry represents. Some attributes represent user + information and are called user attributes. Other attributes + represent operational and/or administrative information and are called + operational attributes. + + An attribute is an attribute description (a type and zero or more + options) with one or more associated values. An attribute is often + referred to by its attribute description. For example, the + 'givenName' attribute is the attribute which consists of the attribute + description 'givenName' (the 'givenName' attribute type [Schema] and + zero options) and one or more associated values. + + The attribute type governs whether the attribute can have multiple + values, the syntax and matching rules used to construct and compare + values of that attribute, and other functions. Options indicate + subtypes and other functions. No two values of an attribute may be + equivalent. + + + + +Zeilenga LDAP Models [Page 8] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + Two values are considered equivalent if they would match according to + the equality matching rule of the attribute type. If the attribute + type is defined with no equality matching rule, two values are + equivalent if and only if they are identical. + + For example, the 'givenName' attribute can have can have more than one + value, they must be Directory Strings, and they are case insensitive. + The 'givenName' attribute cannot hold both "John" and "JOHN" as these + are equivalent values per the equality matching rule of the attribute + type. + + +2.4. Object Classes + + An object class is "an identified family of objects (or conceivable + objects) which share certain characteristics" [X.501]. + + As defined in [X.501]: + + Object classes are used in the Directory for a number of purposes: + + - describing and categorising objects and the entries that + correspond to these objects; + + - where appropriate, controlling the operation of the Directory; + + - regulating, in conjunction with DIT structure rule + specifications, the position of entries in the DIT; + + - regulating, in conjunction with DIT content rule + specifications, the attributes that are contained in entries; + + - identifying classes of entry that are to be associated with a + particular policy by the appropriate administrative authority. + + An object class (a subclass) may be derived from an object class + (its direct superclass) which is itself derived from an even more + generic object class. For structural object classes, this process + stops at the most generic object class, 'top' (defined in Section + 2.4.1). An ordered set of superclasses up to the most superior + object class of an object class is its superclass chain. + + An object class may be derived from two or more direct + superclasses (superclasses not part of the same superclass chain). + This feature of subclassing is termed multiple inheritance. + + Each object class identifies the set of attributes required to be + present in entries belonging to the class and the set of attributes + + + +Zeilenga LDAP Models [Page 9] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + allowed to be present in entries belonging to the class. As an entry + of a class must meet the requirements of each class it belongs to, it + can be said that an object class inherits the sets of allowed and + required attributes from its superclasses. A subclass can identify an + attribute allowed by its superclass as being required. If an + attribute is a member of both sets, it is required to be present. + + Each object class is defined to be one of three kinds of object + classes: Abstract, Structural, or Auxiliary. + + Each object class is identified by an object identifier (OID) and, + optionally, one or more short names (descriptors). + + +2.4.1. Abstract Object Classes + + An abstract object class, as the name implies, provides a base of + characteristics from which other object classes can be defined to + inherit from. An entry cannot belong to an abstract object class + unless it belongs to a structural or auxiliary class which inherits + from that abstract class. + + Abstract object classes can not derive from structural nor auxiliary + object classes. + + All structural object classes derive (directly or indirectly) from the + 'top' abstract object class. Auxiliary object classes do not + necessarily derive from 'top'. + + ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) + + All entries belong to the 'top' abstract object class. + + +2.4.2. Structural Object Classes + + As stated in [X.501]: + + An object class defined for use in the structural specification of + the DIT is termed a structural object class. Structural object + classes are used in the definition of the structure of the names + of the objects for compliant entries. + + An object or alias entry is characterised by precisely one + structural object class superclass chain which has a single + structural object class as the most subordinate object class. + This structural object class is referred to as the structural + object class of the entry. + + + +Zeilenga LDAP Models [Page 10] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + Structural object classes are related to associated entries: + + - an entry conforming to a structural object class shall + represent the real-world object constrained by the object + class; + + - DIT structure rules only refer to structural object classes; + the structural object class of an entry is used to specify the + position of the entry in the DIT; + + - the structural object class of an entry is used, along with an + associated DIT content rule, to control the content of an + entry. + + The structural object class of an entry shall not be changed. + + Each structural object class is a (direct or indirect) subclass of the + 'top' abstract object class. + + Structural object classes cannot subclass auxiliary object classes. + + Each entry is said to belong to its structural object class as well as + all classes in its structural object class's superclass chain, which + always includes 'top'. + + +2.4.3. Auxiliary Object Classes + + Auxiliary object classes are used augment the characteristics of + entries. They are commonly used to augment the sets of attributes + required and allowed attributes to be present in an entry. They can + be used to describe entries or classes of entries. + + Auxiliary object classes cannot subclass structural object classes. + + An entry can belong to any subset of the set of auxiliary object + classes allowed by the DIT content rule associated with structural + object class of the entry. If no DIT content rule is associated with + the structural object class of the entry, the entry cannot belong to + any auxiliary object class. + + The set of auxiliary object classes which an entry belongs to can + change over time. + + +2.5. Attribute Descriptions + + An attribute description is composed of an attribute type (see Section + + + +Zeilenga LDAP Models [Page 11] + +INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003 + + + 2.5.1) and a set of zero or more attribute options (see Section + 2.5.2). + + An attribute description is represented by the ABNF: + + attributedescription = attributetype options + + attributetype = oid + + options = *( SEMI option ) + + option = 1*keychar + + where identifies the attribute type and each