From: Kurt Zeilenga Date: Fri, 9 Jun 2006 03:19:14 +0000 (+0000) Subject: New LDAP RFCs, including the revised LDAP TS X-Git-Tag: OPENLDAP_REL_ENG_2_4_3ALPHA~9^2~168 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=019dcb75890b41f2f44838ffa1d8ea200d814565;p=openldap New LDAP RFCs, including the revised LDAP TS --- diff --git a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt deleted file mode 100644 index 966dde24fb..0000000000 --- a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt +++ /dev/null @@ -1,1937 +0,0 @@ - -INTERNET-DRAFT Editor: R. Harrison -draft-ietf-ldapbis-authmeth-19.txt Novell, Inc. -Obsoletes: 2251, 2829, 2830 February 2006 -Intended Category: Standards Track - - - - - - - - LDAP: Authentication Methods - and - Security Mechanisms - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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 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 - http://www.ietf.org/ietf/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Abstract - - This document describes authentication methods and security - mechanisms of the Lightweight Directory Access Protocol (LDAP). - - - -Harrison Expires August 2006 [Page 1] - -Internet-Draft LDAP Authentication Methods February 2006 - - This document details establishment of Transport Layer Security - (TLS) using the StartTLS operation. - - This document details the simple Bind authentication method - including anonymous, unauthenticated, and name/password mechanisms - and the Simple Authentication and Security Layer (SASL) Bind - authentication method including the EXTERNAL mechanism. - - This document discusses various authentication and authorization - states through which a session to an LDAP server may pass and the - actions that trigger these state changes. - - This document, together with other documents in the LDAP Technical - Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC - 2829 and RFC 2830. - -Table of Contents - - 1. Introduction.....................................................3 - 1.1. Relationship to Other Documents................................5 - 1.2. Conventions....................................................6 - 2. Implementation Requirements......................................7 - 3. StartTLS Operation...............................................7 - 3.1. TLS Establishment Procedures...................................7 - 3.1.1. StartTLS Request Sequencing..................................8 - 3.1.2. Client Certificate...........................................8 - 3.1.3. Server Identity Check........................................8 - 3.1.3.1. Comparison of DNS Names...................................10 - 3.1.3.2. Comparison of IP Addresses................................10 - 3.1.3.3. Comparison of other subjectName types.....................10 - 3.1.4. Discovery of Resultant Security Level.......................10 - 3.1.5. Refresh of Server Capabilities Information..................11 - 3.2. Effect of TLS on Authorization State..........................11 - 3.3. TLS Ciphersuites..............................................11 - 4. Authorization State.............................................12 - 5. Bind Operation..................................................13 - 5.1. Simple Authentication Method..................................13 - 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13 - 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13 - 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14 - 5.2. SASL Authentication Method....................................15 - 5.2.1. SASL Protocol Profile.......................................15 - 5.2.1.1. SASL Service Name for LDAP................................15 - 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15 - 5.2.1.3. Optional Fields...........................................16 - 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17 - 5.2.1.5. Determination of Supported SASL Mechanisms................17 - 5.2.1.6. Rules for Using SASL Layers...............................17 - 5.2.1.7. Support for Multiple Authentications......................18 - 5.2.1.8. SASL Authorization Identities.............................18 - 5.2.2. SASL Semantics Within LDAP..................................19 - -Harrison Expires August 2006 [Page 2] - -Internet-Draft LDAP Authentication Methods February 2006 - - 5.2.3. SASL EXTERNAL Authentication Mechanism......................19 - 5.2.3.1. Implicit Assertion........................................19 - 5.2.3.2. Explicit Assertion........................................20 - 6. Security Considerations.........................................20 - 6.1. General LDAP Security Considerations..........................20 - 6.2. StartTLS Security Considerations..............................21 - 6.3. Bind Operation Security Considerations........................21 - 6.3.1. Unauthenticated Mechanism Security Considerations...........21 - 6.3.2. Name/Password Mechanism Security Considerations.............22 - 6.3.3. Password-related Security Considerations....................22 - 6.3.4. Hashed Password Security Considerations.....................23 - 6.4.SASL Security Considerations...................................23 - 6.5. Related Security Considerations...............................23 - 7. IANA Considerations.............................................24 - 8. Acknowledgments.................................................24 - 9. Normative References............................................24 - 10. Informative References.........................................25 - Author's Address...................................................26 - Appendix A. Authentication and Authorization Concepts..............26 - A.1. Access Control Policy.........................................26 - A.2. Access Control Factors........................................26 - A.3. Authentication, Credentials, Identity.........................27 - A.4. Authorization Identity........................................27 - Appendix B. Summary of Changes.....................................27 - B.1. Changes Made to RFC 2251......................................28 - B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28 - B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28 - B.2. Changes Made to RFC 2829......................................28 - B.2.1. Section 4 (Required security mechanisms)....................29 - B.2.2. Section 5.1 (Anonymous authentication procedure)............29 - B.2.3. Section 6 (Password-based authentication)...................29 - B.2.4. Section 6.1 (Digest authentication).........................29 - B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29 - B.2.6. Section 6.3 (Other authentication choices with TLS).........29 - B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30 - B.2.8. Section 8 (Other mechanisms)................................30 - B.2.9. Section 9 (Authorization identity)..........................30 - B.2.10. Section 10 (TLS Ciphersuites)..............................30 - B.3. Changes Made to RFC 2830: ....................................30 - B.3.1. Section 3.6 (Server Identity Check).........................30 - B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31 - B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31 - B.3.4. Section 5.1.1 (TLS Closure Effects).........................31 - Appendix C. Changes for draft-ldapbis-authmeth-19..................31 - Intellectual Property Rights.......................................32 - Full Copyright Statement...........................................33 - - -1. Introduction - - -Harrison Expires August 2006 [Page 3] - -Internet-Draft LDAP Authentication Methods February 2006 - - The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a - powerful protocol for accessing 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 LDAP conformance. - - Basic threats to an LDAP directory service include (but are not - limited to): - - (1) Unauthorized access to directory data via data-retrieval - operations. - - (2) Unauthorized access to directory data by monitoring access of - others. - - (3) Unauthorized access to reusable client authentication - information by monitoring access of others. - - (4) Unauthorized modification of directory data. - - (5) Unauthorized modification of configuration information. - - (6) Denial of Service: Use of resources (commonly in excess) in a - manner intended to deny service to others. - - (7) Spoofing: Tricking a user or 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 - transport connection. Tricking a user or client into sending - privileged information to a hostile entity that appears to be - the directory server but is not. Tricking a directory server - into believing that information came from a particular client - when in fact it came from a hostile entity. - - (8) Hijacking: An attacker seizes control of an established protocol - session. - - Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats - (2) and (3) are passive attacks. - - Threats (1), (4), (5) and (6) are due to hostile clients. Threats - (2), (3), (7) and (8) are due to hostile agents on the path between - client and server or hostile agents posing as a server, e.g., IP - spoofing. - - LDAP offers the following security mechanisms: - - - - - -Harrison Expires August 2006 [Page 4] - -Internet-Draft LDAP Authentication Methods February 2006 - - (1) Authentication by means of the Bind operation. The Bind - operation provides a simple method which supports anonymous, - unauthenticated, and name/password mechanisms, and the Simple - Authentication and Security Layer (SASL) method which supports a - wide variety of authentication mechanisms. - - (2) Mechanisms to support vendor-specific access control facilities - (LDAP does not offer a standard access control facility). - - (3) Data integrity service by means of security layers in Transport - Layer Security (TLS) or SASL mechanisms. - - (4) Data confidentiality service by means of security layers in TLS - or SASL mechanisms. - - (5) Server resource usage limitation by means of administrative - limits configured on the server. - - (6) Server authentication by means of the TLS protocol or SASL - mechanisms. - - LDAP may also be protected by means outside the LDAP protocol, e.g., - with IP-level security [RFC4301]. - - Experience has shown that simply allowing implementations to pick - and choose the security mechanisms that will be implemented is not a - strategy that leads to interoperability. In the absence of - mandates, clients will continue to be written that do not support - any security function supported by the server, or worse, they will - only support mechanisms that provide inadequate security for most - circumstances. - - It is desirable to allow clients to authenticate using a variety of - mechanisms including mechanisms where identities are represented as - distinguished names [X.501][Models] in string form [LDAPDN] or as - used in different systems (e.g., simple user names [RFC4013]). - Because some authentication mechanisms transmit credentials in plain - text form, and/or do not provide data security services and/or are - subject to passive attacks, it is necessary to ensure secure - interoperability by identifying a mandatory-to-implement mechanism - for establishing transport-layer security services. - - The set of security mechanisms provided in LDAP 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 LDAP implementations and deployments. - -1.1. Relationship to Other Documents - - This document is an integral part of the LDAP Technical - Specification [Roadmap]. - - - - -Harrison Expires August 2006 [Page 5] - -Internet-Draft LDAP Authentication Methods February 2006 - - This document, together with [Roadmap], [Protocol], and [Models], - obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and - 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1 - summarizes the substantive changes made to RFC 2251 by this document. - - This document obsoletes RFC 2829 in its entirety. Appendix B.2 - summarizes the substantive changes made to RFC 2829 by this document. - - Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The - remainder of RFC 2830 is obsoleted by this document. Appendix B.3 - summarizes the substantive changes made to RFC 2830 by this document. - - -1.2. Conventions - - The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", - "MAY", and "OPTIONAL" in this document are to be interpreted as - described in RFC 2119 [RFC2119]. - - The term "user" represents any human or application entity which is - accessing the directory using a directory client. A directory - client (or client) is also known as a directory user agent (DUA). - - The term "transport connection" refers to the underlying transport - services used to carry the protocol exchange, as well as - associations established by these services. - - The term "TLS layer" refers to TLS services used in providing - security services, as well as associations established by these - services. - - The term "SASL layer" refers to SASL services used in providing - security services, as well as associations established by these - services. - - The term "LDAP message layer" refers to the LDAP Message (PDU) - services used in providing directory services, as well as - associations established by these services. - - The term "LDAP session" refers to combined services (transport - connection, TLS layer, SASL layer, LDAP message layer) and their - associations. - - 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 A 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 A before reading the remainder of this document. - - - -Harrison Expires August 2006 [Page 6] - -Internet-Draft LDAP Authentication Methods February 2006 - -2. Implementation Requirements - - LDAP server implementations MUST support the anonymous - authentication mechanism of the simple Bind method (section 5.1.1). - - LDAP implementations that support any authentication mechanism other - than the anonymous authentication mechanism of the simple Bind - method MUST support the name/password authentication mechanism of - the simple Bind method (section 5.1.3) and MUST be capable of - protecting this name/password authentication using TLS as - established by the StartTLS operation (section 3). - - Implementations SHOULD disallow the use of the name/password - authentication mechanism by default when suitable data security - services are not in place, and MAY provide other suitable data - security services for use with this authentication mechanism. - - Implementations MAY support additional authentication mechanisms. - Some of these mechanisms are discussed below. - - LDAP server implementations SHOULD support client assertion of - authorization identity via the SASL EXTERNAL mechanism (section - 5.2.3). - - LDAP server implementations that support no authentication mechanism - other than the anonymous mechanism of the simple bind method SHOULD - support use of TLS as established by the the StartTLS operation - (section 3). (Other servers MUST support TLS per the second - paragraph of this section.) - - Implementations supporting TLS MUST support the - TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the - latter ciphersuite is recommended to encourage interoperability with - implementations conforming to earlier LDAP StartTLS specifications. - - -3. StartTLS Operation - - The Start Transport Layer Security (StartTLS) operation defined in - section 4.14 of [Protocol] provides the ability to establish TLS - [TLS] in an LDAP session. - - The goals of using the TLS [TLS] protocol with LDAP are to ensure - data confidentiality and integrity, and to optionally provide for - authentication. TLS expressly provides these capabilities, although - the authentication services of TLS are available to LDAP only in - combination with the SASL EXTERNAL authentication method (see - section 5.2.3), and then only if the SASL EXTERNAL implementation - chooses to make use of the TLS credentials. - - -3.1. TLS Establishment Procedures - - -Harrison Expires August 2006 [Page 7] - -Internet-Draft LDAP Authentication Methods February 2006 - - This section describes the overall procedures clients and servers - must follow for TLS establishment. These procedures take into - consideration various aspects of the TLS layer including discovery - of resultant security level and assertion of the client's - authorization identity. - - -3.1.1. StartTLS Request Sequencing - - A client may send the StartTLS extended request at any time after - establishing an LDAP session, except: - - - when TLS is currently established on the session, - - when a multi-stage SASL negotiation is in progress on the - session, or - - when there are outstanding responses for operation requests - previously issued on the session. - - As described in [Protocol] Section 4.14.1, a (detected) violation of - any of these requirements results in a return of the operationsError - resultCode. - - Client implementers should ensure that they strictly follow these - operation sequencing requirements to prevent interoperability - issues. Operational experience has shown that violating these - requirements causes interoperability issues because there are race - conditions that prevent servers from detecting some violations of - these requirements due to factors such as server hardware speed and - network latencies. - - There is no general requirement that the client have or have not - already performed a Bind operation (section 5) before sending a - StartTLS operation request, however where a client intends to - perform both a Bind operation and a StartTLS operation, it SHOULD - first perform the StartTLS operation so that the Bind request and - response messages are protected by the data security services - established by the StartTLS operation. - - -3.1.2. Client Certificate - - If an LDAP server requests or demands that a client provide a user - certificate during TLS negotiation and the client does not present a - suitable user certificate (e.g., one that can be validated), the - server may use a local security policy to determine whether to - successfully complete TLS negotiation. - - If a client that has provided a suitable certificate subsequently - performs a Bind operation using the SASL EXTERNAL authentication - mechanism (section 5.2.3), information in the certificate may be - used by the server to identify and authenticate the client. - - -3.1.3. Server Identity Check - -Harrison Expires August 2006 [Page 8] - -Internet-Draft LDAP Authentication Methods February 2006 - - - In order to prevent man-in-the-middle attacks the client MUST verify - the server's identity (as presented in the server's Certificate - message). In this section, the client's understanding of the - server's identity (typically the identity used to establish the - transport connection) is called the "reference identity". - - The client determines the type (e.g., DNS name or IP address) of the - reference identity and performs a comparison between the reference - identity and each subjectAltName value of the corresponding type - until a match is produced. Once a match is produced, the server's - identity has been verified and the server identity check is - complete. Different subjectAltName types are matched in different - ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of - various subjectAltName types. - - The client may map the reference identity to a different type prior - to performing a comparison. Mappings may be performed for all - available subjectAltName types to which the reference identity can - be mapped, however the reference identity should only be mapped to - types for which the mapping is either inherently secure (e.g., - extracting the DNS name from a URI to compare with a subjectAltName - of type dNSName) or for which the mapping is performed in a secure - manner (e.g., using DNSSec, or using user- (or admin-) configured - host-to-address/address-to-host lookup tables). - - The server's identity may also be verified by comparing the - reference identity to the Common Name (CN) [Schema] value in the - leaf RDN of the subjectName field of the server's certificate. This - comparison is performed using the rules for comparison of DNS names - in section 3.1.3.1 below, with the exception that no wildcard - matching is allowed. Although the use of the Common Name value is - existing practice, it is deprecated and Certification Authorities - are encouraged to provide subjectAltName values instead. Note that - the TLS implementation may represent DNs in certificates according - to X.500 or other conventions. For example, some X.500 - implementations order the RDNs in a DN using a left-to-right (most - significant to least significant) convention instead of LDAP's - right-to-left convention. - - If the server identity check fails, user-oriented clients SHOULD - either notify the user (clients may give the user the opportunity to - continue with the LDAP session in this case) or close the transport - connection and indicate that the server's identity is suspect. - Automated clients SHOULD close the transport connection and then - return or log an error indicating that the server's identity is - suspect or both. - - Beyond the server identity check 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 requested to provide. - The client may need to make use of local policy information in - making this determination. - - -Harrison Expires August 2006 [Page 9] - -Internet-Draft LDAP Authentication Methods February 2006 - - -3.1.3.1. Comparison of DNS Names - - If the reference identity is an internationalized domain name, - conforming implementations MUST convert it to the ASCII Compatible - Encoding (ACE) format as specified in section 4 of RFC 3490 - [RFC3490] before comparison with subjectAltName values of type - dNSName. Specifically, conforming implementations MUST perform the - conversion operation specified in section 4 of RFC 3490 as follows: - - * in step 1, the domain name SHALL be considered a "stored - string"; - * in step 3, set the flag called "UseSTD3ASCIIRules"; - * in step 4, process each label with the "ToASCII" - operation; and - * in step 5, change all label separators to U+002E (full - stop). - - After performing the "to-ASCII" conversion, the DNS labels and names - MUST be compared for equality according to the rules specified in - section 3 of RFC3490. - - The '*' (ASCII 42) wildcard character is allowed in subjectAltName - values of type dNSName and then only as the left-most (least - significant) DNS label in that value. This wildcard matches any - left-most DNS label in the server name. That is, the subject - *.example.com matches the server names a.example.com and - b.example.com but does not match example.com or a.b.example.com. - - -3.1.3.2. Comparison of IP Addresses - - When the reference identity is an IP address, the identity MUST be - converted to the "network byte order" octet string representation - [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the - octet string will contain exactly four octets. For IP Version 6, as - specified in RFC 2460, the octet string will contain exactly sixteen - octets. This octet string is then compared against subjectAltName - values of type iPAddress. A match occurs if the reference identity - octet string and value octet strings are identical. - - -3.1.3.3. Comparison of other subjectName types - - Client implementations MAY support matching against subjectAltName - values of other types as described in other documents. - - -3.1.4. Discovery of Resultant Security Level - - - - - - -Harrison Expires August 2006 [Page 10] - -Internet-Draft LDAP Authentication Methods February 2006 - - After a TLS layer is established in an LDAP session, both parties - are to each independently decide whether or not to continue based on - local policy and the security level achieved. If either party - decides that the security level is inadequate for it to continue, it - SHOULD remove the TLS layer immediately after the TLS - (re)negotiation has completed (see [Protocol] section 4.14.3 and - section 3.2 below). Implementations may reevaluate the security - level at any time and, upon finding it inadequate, should remove the - TLS layer. - - -3.1.5. Refresh of Server Capabilities Information - - After a TLS layer is established in an LDAP session, the client - SHOULD discard or refresh all information about the server it - obtained prior to the initiation of the TLS negotiation and not - obtained through secure mechanisms. This protects against man-in- - the-middle attacks that may have altered any server capabilities - information retrieved prior to TLS layer installation. - - The server may advertise different capabilities after installing a - TLS layer. In particular, the value of 'supportedSASLMechanisms' - may be different after a TLS layer has been installed (specifically, - the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed - only after a TLS layer has been installed). - - -3.2. Effect of TLS on Authorization State - - The establishment, change, and/or closure of TLS may cause the - authorization state to move to a new state. This is discussed - further in Section 4. - - -3.3. TLS Ciphersuites - - Several issues should be considered when selecting TLS ciphersuites - that are appropriate for use in a given circumstance. These issues - include the following: - - - The ciphersuite's ability to provide adequate confidentiality - protection for passwords and other data sent over the transport - connection. Client and server implementers should recognize - that some TLS ciphersuites provide no confidentiality protection - while other ciphersuites that do provide confidentiality - protection may be vulnerable to being cracked using brute force - methods, especially in light of ever-increasing CPU speeds that - reduce the time needed to successfully mount such attacks. - - - Client and server implementers should carefully consider the - value of the password or data being protected versus the level - of confidentiality protection provided by the ciphersuite to - ensure that the level of protection afforded by the ciphersuite - is appropriate. - -Harrison Expires August 2006 [Page 11] - -Internet-Draft LDAP Authentication Methods February 2006 - - - - The ciphersuite's vulnerability (or lack thereof) to man-in-the- - middle attacks. Ciphersuites vulnerable to man-in-the-middle - attacks 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 negligible. - - - After a TLS negotiation (either initial or subsequent) is - completed, both protocol peers should independently verify that - the security services provided by the negotiated ciphersuite are - adequate for the intended use of the LDAP session. If not, the - TLS layer should be closed. - - -4. Authorization State - - Every LDAP session has an associated authorization state. This - state is comprised of numerous factors such as what (if any) - authorization state has been established, how it was established, - and what security services are in place. Some factors may be - determined and/or affected by protocol events (e.g., Bind, StartTLS, - or TLS closure), and some factors may be determined by external - events (e.g., time of day or server load). - - While it is often convenient to view authorization state in - simplistic terms (as we often do in this technical specification) - such as "an anonymous state", it is noted that authorization systems - in LDAP implementations commonly involve many factors which - interrelate in complex manners. - - Authorization in LDAP is a local matter. One of the key factors in - making authorization decisions is authorization identity. The Bind - operation defined in section 4.2 of [Protocol] and discussed further - in section 5 below allows information to be exchanged between the - client and server to establish an authorization identity for the - LDAP session. The Bind operation may also be used to move the LDAP - session to an anonymous authorization state (see section 5.1.1). - - Upon initial establishment of the LDAP session, the session has an - anonymous authorization identity. Among other things this implies - that the client need not send a BindRequest in the first PDU of the - LDAP message layer. The client may send any operation request prior - to performing a Bind operation, and the server MUST treat it as if - it had been performed after an anonymous Bind operation (section - 5.1.1). - - Upon receipt of a Bind request, the server immediately moves the - session to an anonymous authorization state. If the Bind request is - successful, the session is moved to the requested authentication - state with its associated authorization state. Otherwise, the - session remains in an anonymous state. - - - - -Harrison Expires August 2006 [Page 12] - -Internet-Draft LDAP Authentication Methods February 2006 - - It is noted that other events both internal and external to LDAP may - result in the authentication and authorization states being moved to - an anonymous one. For instance, the establishment, change or - closure of data security services may result in a move to an - anonymous state, or the user's credential information (e.g., - certificate) may have expired. The former is an example of an event - internal to LDAP whereas the latter is an example of an event - external to LDAP. - - -5. Bind Operation - - The Bind operation ([Protocol] section 4.2) allows authentication - information to be exchanged between the client and server to - establish a new authorization state. - - The Bind request typically specifies the desired authentication - identity. Some Bind mechanisms also allow the client to specify the - authorization identity. If the authorization identity is not - specified, the server derives it from the authentication identity in - an implementation-specific manner. - - If the authorization identity is specified, the server MUST verify - that the client's authentication identity is permitted to assume - (e.g., proxy for) 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. - - -5.1. Simple Authentication Method - - The simple authentication method of the Bind Operation provides - three authentication mechanisms: - - - An anonymous authentication mechanism (section 5.1.1). - - - An unauthenticated authentication mechanism (section 5.1.2). - - - A name/password authentication mechanism using credentials - consisting of a name (in the form of an LDAP distinguished name - [LDAPDN]) and a password (section 5.1.3). - - -5.1.1. Anonymous Authentication Mechanism of Simple Bind - - An LDAP client may use the anonymous authentication mechanism of the - simple Bind method to explicitly establish an anonymous - authorization state by sending a Bind request with a name value of - zero length and specifying the simple authentication choice - containing a password value of zero length. - - -5.1.2. Unauthenticated Authentication Mechanism of Simple Bind - - -Harrison Expires August 2006 [Page 13] - -Internet-Draft LDAP Authentication Methods February 2006 - - An LDAP client may use the unauthenticated authentication mechanism - of the simple Bind method to establish an anonymous authorization - state by sending a Bind request with a name value (a distinguished - name in LDAP string form [LDAPDN] of non-zero length) and specifying - the simple authentication choice containing a password value of zero - length. - - The distinguished name value provided by the client is intended to - be used for trace (e.g., logging) purposes only. The value is not - to be authenticated or otherwise validated (including verification - that the DN refers to an existing directory object). The value is - not to be used (directly or indirectly) for authorization purposes. - - Unauthenticated Bind operations can have significant security issues - (see section 6.3.1). In particular, users intending to perform - Name/Password Authentication may inadvertently provide an empty - password and thus cause poorly implemented clients to request - Unauthenticated access. Clients SHOULD be implemented to require - user selection of the Unauthenticated Authentication Mechanism by - means other than user input of an empty password. Clients SHOULD - disallow an empty password input to a Name/Password Authentication - user interface. Additionally, Servers SHOULD by default fail - Unauthenticated Bind requests with a resultCode of - unwillingToPerform. - - -5.1.3. Name/Password Authentication Mechanism of Simple Bind - - An LDAP client may use the name/password authentication mechanism of - the simple Bind method to establish an authenticated authorization - state by sending a Bind request with a name value (a distinguished - name in LDAP string form [LDAPDN] of non-zero length) and specifying - the simple authentication choice containing an OCTET STRING password - value of non-zero length. - - Servers that map the DN sent in the Bind request to a directory - entry with an associated set of one or more passwords used with this - mechanism will compare the presented password to that set of - passwords. The presented password is considered valid if it matches - any member of this set. - - A resultCode of invalidDNSyntax indicates that the DN sent in the - name value is syntactically invalid. A resultCode of - invalidCredentials indicates that the DN is syntactically correct - but not valid for purposes of authentication, or the password is not - valid for the DN or the server otherwise considers the credentials - to be invalid. A resultCode of success indicates that the - credentials are valid and the server is willing to provide service - to the entity these credentials identify. - - Server behavior is undefined for Bind requests specifying the - name/password authentication mechanism with a zero-length name value - and a password value of non-zero length. - - -Harrison Expires August 2006 [Page 14] - -Internet-Draft LDAP Authentication Methods February 2006 - - The name/password authentication mechanism of the simple Bind method - is not suitable for authentication in environments without - confidentiality protection. - - -5.2. SASL Authentication Method - - The sasl authentication method of the Bind Operation provides - facilities for using any SASL mechanism including authentication - mechanisms and other services (e.g., data security services). - - -5.2.1. SASL Protocol Profile - - LDAP allows authentication via any SASL mechanism [SASL]. As LDAP - includes native anonymous and name/password (plain text) - authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] - SASL mechanisms are typically not used with LDAP. - - Each protocol that utilizes SASL services is required to supply - certain information profiling the way they are exposed through the - protocol ([SASL] section 4). This section explains how each of - these profiling requirements are met by LDAP. - - -5.2.1.1. SASL Service Name for LDAP - - The SASL service name for LDAP is "ldap", which has been registered - with the IANA as a SASL service name. - - -5.2.1.2. SASL Authentication Initiation and Protocol Exchange - - SASL authentication is initiated via a BindRequest message - ([Protocol] section 4.2) with the following parameters: - - - The version is 3. - - The AuthenticationChoice is sasl. - - The mechanism element of the SaslCredentials sequence contains - the value of the desired SASL mechanism. - - The optional credentials field of the SaslCredentials sequence - MAY be used to provide an initial client response for - mechanisms that are defined to have the client send data first - (see [SASL] sections 3 and 5 ). - - - - - - - - - - - -Harrison Expires August 2006 [Page 15] - -Internet-Draft LDAP Authentication Methods February 2006 - - In general, a SASL authentication protocol exchange consists of a - series of server challenges and client responses, the contents of - which are specific to and defined by the SASL mechanism. Thus for - some SASL authentication mechanisms, it may be necessary for the - client to respond to one or more server challenges by sending - BindRequest messages multiple times. A challenge is indicated by - the server sending a BindResponse message with the resultCode set to - saslBindInProgress. This indicates that the server requires the - client to send a new BindRequest message with the same SASL - mechanism to continue the authentication process. - - To the LDAP message layer, these challenges and responses are opaque - binary tokens of arbitrary length. LDAP servers use the - serverSaslCreds field (an OCTET STRING) in a BindResponse message to - transmit each challenge. LDAP clients use the credentials field - (an OCTET STRING) in the SaslCredentials sequence of a BindRequest - message to transmit each response. Note that unlike some Internet - protocols where SASL is used, LDAP is not text based and does not - Base64-transform these challenge and response values. - - Clients sending a BindRequest message with the sasl choice selected - SHOULD send a zero-length value in the name field. Servers - receiving a BindRequest message with the sasl choice selected SHALL - ignore any value in the name field. - - A client may abort a SASL Bind negotiation by sending a BindRequest - message with a different value in the mechanism field of - SaslCredentials or with an AuthenticationChoice other than sasl. - - If the client sends a BindRequest with the sasl mechanism field as - an empty string, the server MUST return a BindResponse with a - resultCode of authMethodNotSupported. This will allow the client to - abort a negotiation if it wishes to try again with the same SASL - mechanism. - - The server indicates completion of the SASL challenge-response - exchange by responding with a BindResponse in which the resultCode - value is not saslBindInProgress. - - The serverSaslCreds field in the BindResponse can be used to include - an optional challenge with a success notification for mechanisms - which are defined to have the server send additional data along with - the indication of successful completion. - - -5.2.1.3. Optional Fields - - As discussed above, LDAP provides an optional field for carrying an - initial response in the message initiating the SASL exchange and - provides an optional field for carrying additional data in the - message indicating outcome of the authentication exchange. As the - mechanism-specific content in these fields may be zero-length, SASL - requires protocol specifications to detail how an empty field is - distinguished from an absent field. - -Harrison Expires August 2006 [Page 16] - -Internet-Draft LDAP Authentication Methods February 2006 - - - Zero-length initial response data is distinguished from no initial - response data in the initiating message, a BindRequest PDU, by the - presence of the SaslCredentials.credentials OCTET STRING (of length - zero) in that PDU. If the client does not intend to send an - initial response with the BindRequest initiating the SASL exchange, - it MUST omit the SaslCredentials.credentials OCTET STRING (rather - than including an zero-length OCTET STRING). - - Zero-length additional data is distinguished from no additional - response data in the outcome message, a BindResponse PDU, by the - presence of the serverSaslCreds OCTET STRING (of length zero) in - that PDU. If a server does not intend to send additional data in - the BindResponse message indicating outcome of the exchange, the - server SHALL omit the serverSaslCreds OCTET STRING (rather than - including a zero-length OCTET STRING). - - -5.2.1.4. Octet Where Negotiated Security Layers Take Effect - - SASL layers take effect following the transmission by the server and - reception by the client of the final BindResponse in the SASL - exchange with a resultCode of success. - - Once a SASL layer providing data integrity or confidentiality - services takes effect, the layer remains in effect until a new layer - is installed (i.e. at the first octet following the final - BindResponse of the Bind operation that caused the new layer to take - effect). Thus, an established SASL layer is not affected by a - failed or non-SASL Bind. - - -5.2.1.5. Determination of Supported SASL Mechanisms - - Clients may determine the SASL mechanisms a server supports by - reading the 'supportedSASLMechanisms' attribute from the root DSE - (DSA-Specific Entry) ([Models] section 5.1). The values of this - attribute, if any, list the mechanisms the server supports in the - current LDAP session state. LDAP servers SHOULD allow all clients-- - even those with an anonymous authorization--to retrieve the - 'supportedSASLMechanisms' attribute of the root DSE both before and - after the SASL authentication exchange. The purpose of the latter - is to allow the client to detect possible downgrade attacks (see - section 6.4 and [SASL] section 6.1.2). - - Because SASL mechanisms provide critical security functions, clients - and servers should be configurable to specify what mechanisms are - acceptable and allow only those mechanisms to be used. Both clients - and servers must confirm that the negotiated security level meets - their requirements before proceeding to use the session. - - -5.2.1.6. Rules for Using SASL Layers - - -Harrison Expires August 2006 [Page 17] - -Internet-Draft LDAP Authentication Methods February 2006 - - Upon installing a SASL layer, the client SHOULD discard or refresh - all information about the server it obtained prior to the initiation - of the SASL negotiation and not obtained through secure mechanisms. - - If a lower level security layer (such as TLS) is installed, any SASL - layer SHALL be layered on top of such security layers regardless of - the order of their negotiation. In all other respects, the SASL - layer and other security layers act independently, e.g., if both a - TLS layer and a SASL layer are in effect then removing the TLS layer - does not affect the continuing service of the SASL layer. - - -5.2.1.7. Support for Multiple Authentications - - LDAP supports multiple SASL authentications as defined in [SASL] - section 4. - - -5.2.1.8. SASL Authorization Identities - - Some SASL mechanisms allow clients to request a desired - authorization identity for the LDAP session ([SASL] section 3.4. - The decision to allow or disallow the current authentication - identity to have access to the requested authorization identity is a - matter of local policy. The authorization identity is a string of - UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the - following ABNF [RFC2234bis] grammar: - - authzId = dnAuthzId / uAuthzId - - ; distinguished-name-based authz id - dnAuthzId = "dn:" distinguishedName - - ; unspecified authorization id, UTF-8 encoded - uAuthzId = "u:" userid - userid = *UTF8 ; syntax unspecified - - where the distinguishedName rule is defined in section 3 of [LDAPDN] - and the UTF8 rule is defined in section 1.4 of [Models]. - - The dnAuthzId choice is used to assert authorization identities in - the form of a distinguished name to be matched in accordance with - the distinguishedNameMatch matching rule [Syntaxes]. There is no - requirement that the asserted distinguishedName value be that of an - entry in the directory. - - - - - - - - - - -Harrison Expires August 2006 [Page 18] - -Internet-Draft LDAP Authentication Methods February 2006 - - The uAuthzId choice allows clients to assert an authorization - identity that is not in distinguished name form. The format of - userid is defined only as a sequence of UTF-8 [RFC3629] encoded - [Unicode] characters, and any further interpretation is a local - matter. For example, the userid could identify a user of a specific - directory service, be a login name or be an email address. A - uAuthzId SHOULD NOT be assumed to be globally unique. To compare - uAuthzID values, each uAuthzID value MUST be prepared as a "query" - string using [RFC4013] and then the two values are compared octet- - wise. - - The above grammar is extensible. The authzId production may be - extended to support additional forms of identities. Each form is - distinguished by its unique prefix (see section 3.12 of [LDAPIANA] - for registration requirements). - - -5.2.2. SASL Semantics Within LDAP - - Implementers must take care to maintain the semantics of SASL - specifications when handling data that has different semantics in - the LDAP protocol. - - For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829] - utilizes an authentication identity and a realm which are - syntactically simple strings and semantically simple username and - realm values ([DIGEST-MD5] section 2.1). These values are not LDAP - DNs, and there is no requirement that they be represented or treated - as such. - - -5.2.3. SASL EXTERNAL Authentication Mechanism - - A client can use the SASL EXTERNAL [SASL] mechanism to request the - LDAP server to authenticate and establish a resulting authorization - identity using security credentials exchanged by a lower security - layer (such as by TLS authentication). If the client's - authentication credentials have not been established at a lower - security layer, the SASL EXTERNAL Bind MUST fail with a resultCode - of inappropriateAuthentication. Although this situation has the - effect of leaving the LDAP session in an anonymous state (section - 4), the state of any installed security layer is unaffected. - - A client may either request that its authorization identity be - automatically derived from its authentication credentials exchanged - at a lower security layer or it may explicitly provide a desired - authorization identity. The former is known as an implicit - assertion, and the latter as an explicit assertion. - - -5.2.3.1. Implicit Assertion - - - - -Harrison Expires August 2006 [Page 19] - -Internet-Draft LDAP Authentication Methods February 2006 - - An implicit authorization identity assertion is performed by - invoking a Bind request of the SASL form using the EXTERNAL - mechanism name that does not include the optional credentials field - (found within the SaslCredentials sequence in the BindRequest). The - server will derive the client's authorization identity from the - authentication identity supplied by a security layer (e.g., a public - key certificate used during TLS layer installation) according to - local policy. The underlying mechanics of how this is accomplished - are implementation specific. - - -5.2.3.2. Explicit Assertion - - An explicit authorization identity assertion is performed by - invoking a Bind request of the SASL form using the EXTERNAL - mechanism name that includes the credentials field (found within the - SaslCredentials sequence in the BindRequest). The value of the - credentials field (an OCTET STRING) is the asserted authorization - identity and MUST be constructed as documented in section 5.2.1.8. - - -6. Security Considerations - - Security issues are discussed throughout this document. The - unsurprising conclusion is that security is an integral and - necessary part of LDAP. This section discusses a number of LDAP- - related security considerations. - - -6.1. General LDAP Security Considerations - - LDAP itself provides no security or protection from accessing or - updating the directory by other means than through the LDAP - protocol, e.g., from inspection of server database files by database - administrators. - - Sensitive data may be carried in almost any LDAP message and its - disclosure may be subject to privacy laws or other legal regulation - in many countries. Implementers should take appropriate measures to - protect sensitive data from disclosure to unauthorized entities. - - A session on which the client has not established data integrity and - privacy services (e.g., via StartTLS, IPsec or a suitable SASL - mechanism) is subject to man-in-the-middle attacks to view and - modify information in transit. Client and server implementers - SHOULD take measures to protect sensitive data in the LDAP session - from these attacks by using data protection services as discussed in - this document. Clients and servers should provide the ability to be - configured to require these protections. A resultCode of - confidentialityRequired indicates that the server requires - establishment of (stronger) data confidentiality protection in order - to perform the requested operation. - - - -Harrison Expires August 2006 [Page 20] - -Internet-Draft LDAP Authentication Methods February 2006 - - Access control should always be applied when reading sensitive - information or updating directory information. - - Various security factors, including authentication and authorization - information and data security services may change during the course - of the LDAP session, or even during the performance of a particular - operation. Implementations should be robust in the handling of - changing security factors. - - -6.2. StartTLS Security Considerations - - All security gained via use of the StartTLS operation is gained by - the use of TLS itself. The StartTLS operation, on its own, does not - provide any additional security. - - The level of security provided through the use of TLS depends - directly on both the quality of the TLS implementation used and the - style of usage of that implementation. Additionally, a man-in-the- - middle attacker can remove the StartTLS extended operation from the - 'supportedExtension' attribute of the root DSE. Both parties SHOULD - independently ascertain and consent to the security level achieved - once TLS is established and before beginning use of the TLS- - protected session. For example, the security level of the TLS layer - might have been negotiated down to plaintext. - - Clients MUST either warn the user when the security level achieved - does not provide an acceptable level of data confidentiality and/or - data integrity protection, or be configurable to refuse to proceed - without an acceptable level of security. - - As stated in section 3.1.2, a server may use a local security policy - to determine whether to successfully complete TLS negotiation. - Information in the user's certificate that is originated or verified - by the certification authority should be used by the policy - administrator when configuring the identification and authorization - policy. - - Server implementers SHOULD allow server administrators to elect - whether and when data confidentiality and integrity are required, as - well as elect whether authentication of the client during the TLS - handshake is required. - - Implementers should be aware of and understand TLS security - considerations as discussed in the TLS specification [TLS]. - - -6.3. Bind Operation Security Considerations - - This section discusses several security considerations relevant to - LDAP authentication via the Bind operation. - - -6.3.1. Unauthenticated Mechanism Security Considerations - -Harrison Expires August 2006 [Page 21] - -Internet-Draft LDAP Authentication Methods February 2006 - - - Operational experience shows that clients can (and frequently do) - misuse the unauthenticated authentication mechanism of the simple - Bind method (see section 5.1.2). For example, a client program - might make a decision to grant access to non-directory information - on the basis of successfully completing a Bind operation. LDAP - server implementations may return a success response to an - unauthenticated Bind request. This may erroneously leave the client - with the impression that the server has successfully authenticated - the identity represented by the distinguished name when in reality, - an anonymous authorization state has been established. Clients that - use the results from a simple Bind operation to make authorization - decisions should actively detect unauthenticated Bind requests (by - verifying that the supplied password is not empty) and react - appropriately. - - -6.3.2. Name/Password Mechanism Security Considerations - - The name/password authentication mechanism of the simple Bind method - discloses the password to the server, which is an inherent security - risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829] - that do not disclose the password to the server. - - -6.3.3. Password-related Security Considerations - - LDAP allows multi-valued password attributes. In systems where - entries are expected to have one and only one password, - administrative controls should be provided to enforce this behavior. - - The use of clear text passwords and other unprotected authentication - credentials is strongly discouraged over open networks when the - underlying transport service cannot guarantee confidentiality. LDAP - implementations SHOULD NOT by default support authentication methods - using clear text passwords and other unprotected authentication - credentials unless the data on the session is protected using TLS or - other data confidentiality and data integrity protection. - - The transmission of passwords in the clear--typically for - authentication or modification--poses a significant security risk. - This risk can be avoided by using SASL authentication [SASL] - mechanisms that do not transmit passwords in the clear or by - negotiating transport or session layer data confidentiality services - before transmitting password values. - - To mitigate the security risks associated with the transfer of - passwords, a server implementation that supports any password-based - authentication mechanism that transmits passwords in the clear MUST - support a policy mechanism that at the time of authentication or - password modification, requires: - - A TLS layer has been successfully installed. - - -Harrison Expires August 2006 [Page 22] - -Internet-Draft LDAP Authentication Methods February 2006 - - OR - - Some other data confidentiality mechanism that protects the - password value from eavesdropping has been provided. - - OR - - The server returns a resultCode of confidentialityRequired for - the operation (i.e. name/password Bind with password value, - SASL Bind transmitting a password value in the clear, add or - modify including a userPassword value, etc.), even if the - password value is correct. - - Server implementations may also want to provide policy mechanisms to - invalidate or otherwise protect accounts in situations where a - server detects that a password for an account has been transmitted - in the clear. - - -6.3.4. Hashed Password Security Considerations - - Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of - the password value that may be vulnerable to offline dictionary - attacks. Implementers should take care to protect such hashed - password values during transmission using TLS or other - confidentiality mechanisms. - - -6.4.SASL Security Considerations - - Until data integrity service is installed on an LDAP session, an - attacker can modify the transmitted values of the - 'supportedSASLMechanisms' attribute response and thus downgrade the - list of available SASL mechanisms to include only the least secure - mechanism. To detect this type of attack, the client may retrieve - the SASL mechanisms the server makes available both before and after - data integrity service is installed on an LDAP session. If the - client finds that the integrity-protected list (the list obtained - after data integrity service was installed) contains a stronger - mechanism than those in the previously obtained list, the client - should assume the previously obtained list was modified by an - attacker. In this circumstance it is recommended that the client - close the underlying transport connection and then reconnect to - reestablish the session. - - -6.5. Related Security Considerations - - Additional security considerations relating to the various - authentication methods and mechanisms discussed in this document - apply and can be found in [SASL], [RFC4013], [StringPrep] and - [RFC3629]. - - - -Harrison Expires August 2006 [Page 23] - -Internet-Draft LDAP Authentication Methods February 2006 - -7. IANA Considerations - - It is requested that the IANA update the LDAP Protocol Mechanism - registry to indicate that this document and [Protocol] provide the - definitive technical specification for the StartTLS - (1.3.6.1.4.1.1466.20037) extended operation. - - -8. Acknowledgments - - This document combines information originally contained in RFC 2251, - RFC 2829 and RFC 2830 which are products of the LDAP Extensions - (LDAPEXT) Working Group. - - This document is a product of the IETF LDAP Revision (LDAPBIS) - working group. - - -9. Normative References - - [[Note to the RFC Editor: please replace the citation tags used in - referencing Internet-Drafts with tags of the form RFCnnnn.]] - - [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String - Representation of Distinguished Names", draft-ietf- - ldapbis-dn-xx.txt, a work in progress. - - [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft- - ietf-ldapbis-bcp64-xx.txt, (a work in progress). - - [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings - in PKIX Certificates", draft-hoffman-pkix-stringmatch- - xx.txt, a work in progress. - - [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory - Information Models", draft-ietf-ldapbis-models-xx.txt, - a work in progress. - - [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf- - ldapbis-protocol-xx.txt, a work in progress. - - [RFC791] Information Sciences Institute, "INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC - 791, September 1981. - - [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", draft-crocker-abnf- - rfc2234bis-xx, a work in progress. - - [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 - (IPv6)", RFC 2460, December 1998. - -Harrison Expires August 2006 [Page 24] - -Internet-Draft LDAP Authentication Methods February 2006 - - - [RFC3490] Falstrom, P., P. Hoffman, and A. Costello, - "Internationalizing Domain Names In Applications - (IDNA)", RFC 3490, March 2003. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 3629, STD 63, November 2003. - - [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User - Names and Passwords", RFC 4013, February 2005. - - [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map", - draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. - - [SASL] Melnikov, A. (editor), "Simple Authentication and - Security Layer (SASL)", draft-ietf-sasl-rfc2222bis- - xx.txt, a work in progress. - - [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf- - ldapbis-user-schema-xx.txt, a work in progress. - - [StringPrep] M. Blanchet, "Preparation of Internationalized Strings - ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a - work in progress. - - [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", - draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. - - [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version - 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in - progress. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - -10. Informative References - - [[Note to the RFC Editor: please replace the citation tags used in - referencing Internet-Drafts with tags of the form RFCnnnn.]] - - [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft- - zeilenga-sasl-anon-xx.txt, a work in progress. - - [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest - Authentication as a SASL Mechanism", draft-ietf-sasl- - rfc2831bis-xx.txt, a work in progress. - - -Harrison Expires August 2006 [Page 25] - -Internet-Draft LDAP Authentication Methods February 2006 - - [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga- - sasl-plain-xx.txt, a work in progress. - - [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May - 2000. - - [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC - 2829, May 2000. - - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - -Author's Address - - Roger Harrison - Novell, Inc. - 1800 S. Novell Place - Provo, UT 84606 - USA - +1 801 861 2642 - roger_harrison@novell.com - - -Appendix A. Authentication and Authorization Concepts - - This appendix is non-normative. - - 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. - - -A.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. Security objects and - mechanisms, such as those described here, enable the expression of - access control policies and their enforcement. - - -A.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 ([Protocol] section - 4.2). 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 transport connection via which the request is - transmitted, others (e.g., time of day) may be "environmental". - - -Harrison Expires August 2006 [Page 26] - -Internet-Draft LDAP Authentication Methods February 2006 - - Access control policies are expressed in terms of access control - factors. For example, "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. - -A.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 a new authorization state 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. X.509 certificates, Kerberos tickets, and simple - identity and password pairs are all examples of authentication - credential forms. Note that an authentication mechanism may - constrain the form of authentication identities used with it. - - -A.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; for example, "entity - X can perform operation Y on resource Z." - - The authorization identity of an LDAP session is often semantically - 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 [SASL]. 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 B. Summary of Changes - - This appendix is non-normative. - - - - - -Harrison Expires August 2006 [Page 27] - -Internet-Draft LDAP Authentication Methods February 2006 - - This appendix summarizes substantive changes made to RFC 2251, RFC - 2829 and RFC 2830. In addition to the specific changes detailed - below, the reader of this document should be aware that numerous - general editorial changes have been made to the original content - from the source documents. These changes include the following: - - - The material originally found in RFC 2251 sections 4.2.1 and - 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC - 2830 was combined into a single document - - - The combined material was substantially reorganized and edited - to group related subjects, improve the document flow and clarify - intent. - - - Changes were made throughout the text to align with definitions - of LDAP protocol layers and IETF security terminology. - - - Substantial updates and additions were made to security - considerations from both documents based on current operational - experience. - - -B.1. Changes Made to RFC 2251 - - This section summarizes the substantive changes made to sections - 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional - substantive changes to section 4.2.1 of RFC 2251 are also documented - in [Protocol]. - - -B.1.1. Section 4.2.1 (Sequencing of the Bind Request) - - - Paragraph 1: Removed the sentence, "If at any stage the client - wishes to abort the bind process it MAY unbind and then drop the - underlying connection." The Unbind operation still permits this - behavior, but it is not documented explicitly. - - - Clarified that the session is moved to an anonymous state upon - receipt of the BindRequest PDU and that it is only moved to a - non-anonymous state if and when the Bind request is successful. - - -B.1.2. Section 4.2.2 (Authentication and Other Security Services) - - - RFC 2251 states that anonymous authentication MUST be performed - using the simple bind method. This specification defines the - anonymous authentication mechanism of the simple bind method and - requires all conforming implementations to support it. Other - authentication mechanisms producing anonymous authentication and - authorization state may also be implemented and used by - conforming implementations. - - -B.2. Changes Made to RFC 2829 - -Harrison Expires August 2006 [Page 28] - -Internet-Draft LDAP Authentication Methods February 2006 - - - This section summarizes the substantive changes made to RFC 2829. - - -B.2.1. Section 4 (Required security mechanisms) - - - The name/password authentication mechanism (see section B.2.5 - below) protected by TLS replaces the SASL DIGEST-MD5 mechanism - as LDAP's mandatory-to-implement password-based authentication - mechanism. Implementations are encouraged to continue - supporting SASL DIGEST-MD5 [RFC2829]. - - -B.2.2. Section 5.1 (Anonymous authentication procedure) - - - Clarified that anonymous authentication involves a name value of - zero length and a password value of zero length. The - unauthenticated authentication mechanism was added to handle - simple Bind requests involving a name value with a non-zero - length and a password value of zero length. - - -B.2.3. Section 6 (Password-based authentication) - - - See section B.2.1. - - -B.2.4. Section 6.1 (Digest authentication) - - - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to - implement, this section is now historical and was not included - in this document. RFC 2829 section 6.1 continues to document the - SASL DIGEST-MD5 authentication mechanism. - - -B.2.5. Section 6.2 ("simple" authentication choice with TLS) - - - Renamed the "simple" authentication mechanism to the - name/password authentication mechanism to better describe it. - - - The use of TLS was generalized to align with definitions of LDAP - protocol layers. TLS establishment is now discussed as an - independent subject and is generalized for use with all - authentication mechanisms and other security layers. - - - Removed the implication that the userPassword attribute is the - sole location for storage of password values to be used in - authentication. There is no longer any implied requirement for - how or where passwords are stored at the server for use in - authentication. - - -B.2.6. Section 6.3 (Other authentication choices with TLS) - - -Harrison Expires August 2006 [Page 29] - -Internet-Draft LDAP Authentication Methods February 2006 - - - See section B.2.5. - - -B.2.7. Section 7.1 (Certificate-based authentication with TLS) - - - See section B.2.5. - - -B.2.8. Section 8 (Other mechanisms) - - - All SASL authentication mechanisms are explicitly allowed within - LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN - mechanisms are no longer precluded from use within LDAP. - - -B.2.9. Section 9 (Authorization identity) - - - Specified matching rules for dnAuthzID and uAuthzID values. In - particular, the DN value in the dnAuthzID form must be matched - using DN matching rules and the uAuthzID value MUST be prepared - using SASLprep rules before being compared octet-wise. - - - Clarified that uAuthzID values should not be assumed to be - globally unique. - - -B.2.10. Section 10 (TLS Ciphersuites) - - - TLS Ciphersuite recommendations are no longer included in this - specification. Implementations must still support the - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. - - - Clarified that anonymous authentication involves a name value of - zero length and a password value of zero length. The - unauthenticated authentication mechanism was added to handle - simple Bind requests involving a name value with a non-zero - length and a password value of zero length. - - -B.3. Changes Made to RFC 2830: - - This section summarizes the substantive changes made to sections 3 - and 5 of RFC 2830. Readers should consult [Protocol] for summaries - of changes to other sections. - - -B.3.1. Section 3.6 (Server Identity Check) - - - - - - - - -Harrison Expires August 2006 [Page 30] - -Internet-Draft LDAP Authentication Methods February 2006 - - - Substantially updated the server identity check algorithm to - ensure that it is complete and robust. In particular, the use - of all relevant values in the subjectAltName and the subjectName - fields are covered by the algorithm and matching rules are - specified for each type of value. Mapped (derived) forms of the - server identity may now be used when the mapping is performed in - a secure fashion. - - -B.3.2. Section 3.7 (Refresh of Server Capabilities Information) - - - Clients are no longer required to always refresh information - about server capabilities following TLS establishment to allow - for situations where this information was obtained through a - secure mechanism. - - -B.3.3. Section 5.2 (Effects of TLS on Authorization Identity) - - - Establishing a TLS layer on an LDAP session may now cause the - authorization state of the LDAP session to change. - - -B.3.4. Section 5.1.1 (TLS Closure Effects) - - - Closing a TLS layer on an LDAP session changes the - authentication and authorization state of the LDAP session based - on local policy. Specifically, this means that implementations - are not required to to change the authentication and - authorization states to anonymous upon TLS closure. - - -Appendix C. Changes for draft-ldapbis-authmeth-19 - - [[Note to RFC Editor: Please remove this appendix upon publication - of this Internet-Draft as an RFC.]] - - This appendix is non-normative. - - This appendix summarizes changes made in this revision of the - document. - - General - - - This draft has addressed all issues raised for the -18 version. - - - Several minor edits for clarity and to remove typos based on - feedback from WG, IETF and IESG reviews. - - Abstract - - Added statement regarding RFCs obsoleted by this document. - - Section 2 - - -Harrison Expires August 2006 [Page 31] - -Internet-Draft LDAP Authentication Methods February 2006 - - - Changed mandatory-to-implement TLS ciphersuite from - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to - TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and - WG consensus. - - Section 5.2.1.5 - - Clarified that 'supportedSASLMechanisms' should be retrievable - by all clients both before and after SASL negotiation to allow - detection of mechanism downgrade attacks. - - Section 5.2.1.6 - - Changed wording to reflect the fact that SASL layers cannot be - uninstalled from the session. - - Section 5.2.3 - - Removed reference to IPsec as a source of authorization identity. - - Section 6.2 - - When TLS layer does not provide an acceptable level of security - client MUST warn the user or refuse to proceed. (This was - changed from SHOULD based on IESG recommendation and WG - consensus.) - - - Added a security consideration regarding the proper usage of - information found in the client certificate. - - Section 6.4 - - Added a new section on SASL security considerations that - discusses SASL mechanism downgrade attacks. - - Section 10 - - Replaced references to RFC 2401 with RFC 4301. - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; nor does it represent that - it has made any independent effort to identify any such rights. - Information on the procedures with respect to rights in RFC - documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - - - - -Harrison Expires August 2006 [Page 32] - -Internet-Draft LDAP Authentication Methods February 2006 - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIM 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Harrison Expires August 2006 [Page 33] - \ No newline at end of file diff --git a/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt b/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt deleted file mode 100644 index cdc8505536..0000000000 --- a/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt +++ /dev/null @@ -1,1179 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: BCP OpenLDAP Foundation -Expires in six months 23 January 2006 -Obsoletes: RFC 3383 - - - IANA Considerations for LDAP - - - - -Status of Memo - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Best Current Practice - document. This document is intended to replace RFC 3383. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Revision Working Group - (LDAPBIS) mailing list . Please send - editorial comments directly to the document editor - . - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - Copyright (C) The Internet Society (2006). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - - - -Zeilenga IANA Considerations for LDAP [Page 1] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - -Abstract - - This document provides procedures for registering extensible elements - of Lightweight Directory Access Protocol (LDAP). The document also - provides guidelines to Internet Assigned Numbers Authority (IANA) - describing conditions under which new values can be assigned. - - -1. Introduction - - The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an - extensible protocol. LDAP supports: - - - addition of new operations, - - extension of existing operations, and - - extensible schema. - - This document details procedures for registering values of used to - unambiguously identify extensible elements of the protocol including: - - - LDAP message types; - - LDAP extended operations and controls; - - LDAP result codes; - - LDAP authentication methods; - - LDAP attribute description options; and - - Object Identifier descriptors. - - These registries are maintained by the Internet Assigned Numbers - Authority (IANA). - - In addition, this document provides guidelines to IANA describing the - conditions under which new values can be assigned. - - This document replaces RFC 3383. - - -2. Terminology and Conventions - - This section details terms and conventions used in this document. - - -2.1. Policy Terminology - - The terms "IESG Approval", "Standards Action", "IETF Consensus", - "Specification Required", "First Come First Served", "Expert Review", - and "Private Use" are used as defined in BCP 26 [RFC2434]. - - - - - -Zeilenga IANA Considerations for LDAP [Page 2] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - -2.2. Requirement Terminology - - 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]. In - this case, "the specification" as used by BCP 14 refers to the - processing of protocols being submitted to the IETF standards - process. - - -2.3. Common ABNF Productions - - A number of syntaxes in this document are described using ABNF - [ABNF]. These syntaxes rely on the following common productions: - - ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" - LDIGIT = %x31-39 ; "1"-"9" - DIGIT = %x30 / LDIGIT ; "0"-"9" - HYPHEN = %x2D ; "-" - DOT = %x2E ; "." - number = DIGIT / ( LDIGIT 1*DIGIT ) - keychar = ALPHA / DIGIT / HYPHEN - leadkeychar = ALPHA - keystring = leadkeychar *keychar - - A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded - Unicode [Unicode] restricted to the production. - - -3. IANA Considerations for LDAP - - This section details each kind of protocol value which can be - registered and provides IANA guidelines on how to assign new values. - - IANA may reject obviously bogus registrations. - - LDAP values specified in RFCs MUST be registered. Other LDAP values, - except those in private-use name spaces, SHOULD be registered. RFCs - SHOULD NOT reference, use, or otherwise recognize unregistered LDAP - values. - - -3.1. Object Identifiers - - Numerous LDAP schema and protocol elements are identified by Object - Identifiers (OIDs) [X.680]. Specifications which assign OIDs to - elements SHOULD state who delegated the OIDs for its use. - - - - -Zeilenga IANA Considerations for LDAP [Page 3] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - For IETF developed elements, specifications SHOULD use OIDs under - "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed - by others, any properly delegated OID can be used, including those - under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private - Enterprise Numbers" (1.3.6.1.4.1.x). - - Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert - Review with Specification Required. Only one OID per specification - will be assigned. The specification MAY then assign any number of - OIDs within this arc without further coordination with IANA. - - Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by - IANA . Practices for IANA - assignment of Internet Private Enterprise Numbers is detailed in RFC - 2578 [RFC2578]. - - To avoid interoperability problems between early implementations of a - "work in progress" and implementations of the published specification - (e.g., the RFC), experimental OIDs SHOULD be used in "works in - progress" and early implementations. OIDs under the Internet - Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. - Practices for IANA assignment of these Internet Experimental numbers - is detailed in RFC 2578 [RFC2578] - - -3.2 Protocol Mechanisms - - LDAP provides a number of Root DSE attributes for discovery of - protocol mechanisms identified by OIDs, including the - supportedControl, supportedExtension, and supportedFeatures - attributes [Models], - - A registry of OIDs used for discover of protocol mechanisms is - provided to allow implementors and others to locate the technical - specification for these protocol mechanisms. Future specifications - of additional Root DSE attributes holding values identifying protocol - mechanisms MAY extend this registry for their values. - - Protocol Mechanisms are registered on a First Come First Served - basis. - - -3.3 LDAP Syntaxes - - This registry provides a listing of LDAP syntaxes [Models]. Each - LDAP syntax is identified by an object identifier (OID). This - registry is provided to allow implementors and others to locate the - technical specification describing a particular LDAP Syntax. - - - -Zeilenga IANA Considerations for LDAP [Page 4] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - LDAP Syntaxes are registered on a First Come First Served with - Specification Required basis. - - Note: unlike object classes, attribute types and various other kinds - of schema elements, descriptors are not used in LDAP to identify LDAP - Syntaxes. - - -3.4. Object Identifier Descriptors - - LDAP allows short descriptive names (or descriptors) to be used - instead of a numeric Object Identifier to identify select protocol - extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] - extensions, and other objects. - - While the protocol allows the same descriptor to refer to different - object identifiers in certain cases and the registry supports - multiple registrations of the same descriptor (each indicating a - different kind of schema element and different object identifier), - multiple registrations of the same descriptor are to be avoided. All - such multiple registration requests require Expert Review. - - Descriptors are restricted to strings of UTF-8 encoded Unicode - characters restricted by the following ABNF: - - name = keystring - - Descriptors are case-insensitive. - - Multiple names may be assigned to a given OID. For purposes of - registration, an OID is to be represented in numeric OID form (e.g., - 1.1.0.23.40) conforming to the ABNF: - - numericoid = number 1*( DOT number ) - - While the protocol places no maximum length restriction upon - descriptors, they should be short. Descriptors longer than 48 - characters may be viewed as too long to register. - - A value ending with a hyphen ("-") reserves all descriptors which - start with that value. For example, the registration of the option - "descrFamily-" reserves all options which start with "descrFamily-" - for some related purpose. - - Descriptors beginning with "x-" are for Private Use and cannot be - registered. - - Descriptors beginning with "e-" are reserved for experiments and will - - - -Zeilenga IANA Considerations for LDAP [Page 5] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - be registered on a First Come First Served basis. - - All other descriptors require Expert Review to be registered. - - The registrant need not "own" the OID being named. - - The OID name space is managed by The ISO/IEC Joint Technical - Committee 1 - Subcommittee 6. - - -3.5. AttributeDescription Options - - An AttributeDescription [Models] can contain zero or more options - specifying additional semantics. An option SHALL be restricted to a - string UTF-8 encoded Unicode characters limited by the following - ABNF: - - option = keystring - - Options are case-insensitive. - - While the protocol places no maximum length restriction upon option - strings, they should be short. Options longer than 24 characters may - be viewed as too long to register. - - Values ending with a hyphen ("-") reserve all option names which - start with the name. For example, the registration of the option - "optionFamily-" reserves all options which start with "optionFamily-" - for some related purpose. - - Options beginning with "x-" are for Private Use and cannot be - registered. - - Options beginning with "e-" are reserved for experiments and will be - registered on a First Come First Served basis. - - All other options require Standards Action or Expert Review with - Specification Required to be registered. - - -3.6. LDAP Message Types - - Each protocol message is encapsulated in an LDAPMessage envelope - [Protocol]. The protocolOp CHOICE indicates the type of message - encapsulated. Each message type consists of an ASN.1 identifier in - the form of a keyword and a non-negative choice number. The choice - number is combined with the class (APPLICATION) and data type - (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's - - - -Zeilenga IANA Considerations for LDAP [Page 6] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - encoding. The choice numbers for existing protocol messages are - implicit in the protocol's ASN.1 defined in [Protocol]. - - New values will be registered upon Standards Action. - - Note: LDAP provides extensible messages which reduces, but does not - eliminate, the need to add new message types. - - -3.7. LDAP Authentication Method - - The LDAP Bind operation supports multiple authentication methods - [Protocol]. Each authentication choice consists of an ASN.1 - identifier in the form of a keyword and a non-negative integer. - - The registrant SHALL classify the authentication method usage using - one of the following terms: - - COMMON - method is appropriate for common use on the - Internet, - LIMITED USE - method is appropriate for limited use, - OBSOLETE - method has been deprecated or otherwise found to - be inappropriate for any use. - - Methods without publicly available specifications SHALL NOT be - classified as COMMON. New registrations of class OBSOLETE cannot be - registered. - - New authentication method integers in the range 0-1023 require - Standards Action to be registered. New authentication method - integers in the range 1024-4095 require Expert Review with - Specification Required. New authentication method integers in the - range 4096-16383 will be registered on a First Come First Served - basis. Keywords associated with integers in the range 0-4095 SHALL - NOT start with "e-" or "x-". Keywords associated with integers in - the range 4096-16383 SHALL start with "e-". Values greater than or - equal to 16384 and keywords starting with "x-" are for Private Use - and cannot be registered. - - Note: LDAP supports Simple Authentication and Security Layers [SASL] - as an authentication choice. SASL is an extensible - authentication framework. - - -3.8. LDAP Result Codes - - LDAP result messages carry an resultCode enumerated value to indicate - the outcome of the operation [Protocol]. Each result code consists - - - -Zeilenga IANA Considerations for LDAP [Page 7] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - of a ASN.1 identifier in the form of a keyword and a non-negative - integer. - - New resultCodes integers in the range 0-1023 require Standards Action - to be registered. New resultCode integers in the range 1024-4095 - require Expert Review with Specification Required. New resultCode - integers in the range 4096-16383 will be registered on a First Come - First Served basis. Keywords associated with integers in the range - 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with - integers in the range 4096-16383 SHALL start with "e-". Values - greater than or equal to 16384 and keywords starting with "x-" are - for Private Use and cannot be registered. - - -3.9. LDAP Search Scope - - LDAP SearchRequest messages carry a scope enumerated value to - indicate the extend of search within the DIT [Protocol] Each search - value consists of a ASN.1 identifier in the form of a keyword and a - non-negative integer. - - New scope integers in the range 0-1023 require Standards Action to be - registered. New scope integers in the range 1024-4095 require Expert - Review with Specification Required. New scope integers in the range - 4096-16383 will be registered on a First Come First Served basis. - Keywords associated with integers in the range 0-4095 SHALL NOT start - with "e-" or "x-". Keywords associated with integers in the range - 4096-16383 SHALL start with "e-". Values greater than or equal to - 16384 and keywords starting with "x-" are for Private Use and cannot - be registered. - - -3.10. LDAP Filter Choice - - LDAP filters are used in making assertions against an object - represented in the directory [Protocol]. The Filter CHOICE indicates - a type of assertion. Each Filter CHOICE consists of an ASN.1 - identifier in the form of a keyword and a non-negative choice number. - The choice number is combined with the class (APPLICATION) and data - type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the - message's encoding. - - Note: LDAP provides the extensibleMatching choice which reduces, but - does not eliminate, the need to add new filter choices. - - -3.11. LDAP ModifyRequest Operation Type - - - - -Zeilenga IANA Considerations for LDAP [Page 8] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - The LDAP ModifyRequest carries a sequence of modification operations - [Protocol]. Each kind (e.g., add, delete, replace) of operation is - consists of a ASN.1 identifier in the form of a keyword and a - non-negative integer. - - New operation type integers in the range 0-1023 require Standards - Action to be registered. New operation type integers in the range - 1024-4095 require Expert Review with Specification Required. New - operation type integers in the range 4096-16383 will be registered on - a First Come First Served basis. Keywords associated with integers - in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords - associated with integers in the range 4096-16383 SHALL start with - "e-". Values greater than or equal to 16384 and keywords starting - with "x-" are for Private Use and cannot be registered. - - -3.12. LDAP authzId Prefixes - - Authorization Identities in LDAP are strings conforming to the - production [AuthMeth]. This production is extensible. - Each new specific authorization form is identified by a prefix string - conforming to the following ABNF: - - prefix = keystring COLON - COLON = %x3A ; COLON (":" U+003A) - - Prefixes are case-insensitive. - - While the protocol places no maximum length restriction upon prefix - strings, they should be short. Prefixes longer than 12 characters - may be viewed as too long to register. - - Prefixes beginning with "x-" are for Private Use and cannot be - registered. - - Prefixes beginning with "e-" are reserved for experiments and will be - registered on a First Come First Served basis. - - All other prefixes require Standards Action or Expert Review with - Specification Required to be registered. - - -3.13. Directory Systems Names - - The IANA-maintained "Directory Systems Names" registry [IANADSN] of - valid keywords for well known attributes was used in the LDAPv2 - string representation of a distinguished name [RFC1779]. LDAPv2 is - now Historic [RFC3494]. - - - -Zeilenga IANA Considerations for LDAP [Page 9] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - Directory systems names are not known to be used in any other - context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section - 3.2] (which have a different syntax than directory system names). - - New Directory System Names will no longer be accepted. For - historical purposes, the current list of registered names should - remain publicly available. - - -4. Registration Procedure - - The procedure given here MUST be used by anyone who wishes to use a - new value of a type described in Section 3 of this document. - - The first step is for the requester to fill out the appropriate form. - Templates are provided in Appendix A. - - If the policy is Standards Action, the completed form SHOULD be - provided to the IESG with the request for Standards Action. Upon - approval of the Standards Action, the IESG SHALL forward the request - (possibly revised) to IANA. The IESG SHALL be viewed as the owner of - all values requiring Standards Action. - - If the policy is Expert Review, the requester SHALL post the - completed form to the mailing list for - public review. The review period is two (2) weeks. If a revised - form is later submitted, the review period is restarted. Anyone may - subscribe to this list by sending a request to - . During the review, objections may - be raised by anyone (including the Expert) on the list. After - completion of the review, the Expert, based upon public comments, - SHALL either approve the request and forward it to the IANA OR deny - the request. In either case, the Expert SHALL promptly notify the - requester of the action. Actions of the Expert may be appealed - [RFC2026]. The Expert is appointed by Applications Area Director(s). - The requester is viewed as the owner of values registered under - Expert Review. - - If the policy is First Come First Served, the requester SHALL submit - the completed form directly to the IANA: . The - requester is viewed as the owner of values registered under First - Come First Served. - - Neither the Expert nor IANA will take position on the claims of - copyright or trademarks issues regarding completed forms. - - Prior to submission of the Internet Draft (I-D) to the RFC Editor but - after IESG review and tentative approval, the document editor SHOULD - - - -Zeilenga IANA Considerations for LDAP [Page 10] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - revise the I-D to use registered values. - - -5. Registration Maintenance - - This section discusses maintenance of registrations. - - -5.1. Lists of Registered Values - - IANA makes lists of registered values readily available to the - Internet community on their web site: . - - -5.2. Change Control - - The registration owner MAY update the registration subject to the - same constraints and review as with new registrations. In cases - where the owner is not unable or unwilling to make necessary updates, - the IESG MAY assume ownership in order to update the registration. - - -5.3. Comments - - For cases where others (anyone other than the owner) have significant - objections to the claims in a registration and the owner does not - agree to change the registration, comments MAY be attached to a - registration upon Expert Review. For registrations owned by the - IESG, the objections SHOULD be addressed by initiating a request for - Expert Review. - - The form to these requests is ad hoc, but MUST include the specific - objections to be reviewed and SHOULD contain (directly or by - reference) materials supporting the objections. - - -6. Security Considerations - - The security considerations detailed in BCP 26 [RFC2434] are - generally applicable to this document. Additional security - considerations specific to each name space are discussed in Section 3 - where appropriate. - - Security considerations for LDAP are discussed in documents - comprising the technical specification [Roadmap]. - - -7. Acknowledgment - - - -Zeilenga IANA Considerations for LDAP [Page 11] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - This document is a product of the IETF LDAP Revision (LDAPBIS) - Working Group (WG). This document is a revision of RFC 3383, also a - product of the LDAPBIS WG. - - This document includes text borrowed from "Guidelines for Writing an - IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and - Harald Alvestrand. - - -8. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - Email: Kurt@OpenLDAP.org - - -9. References - - [[Note to the RFC Editor: please replace the citation tags used in - referencing Internet-Drafts with tags of the form RFCnnnn where - possible.]] - - -9.1. Normative References - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9 (also RFC 2026), October 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26 (also RFC - 2434), October 1998. - - [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure - of Management Information Version 2 (SMIv2)", RFC 2578 - (STD: 58), April 1999. - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 3629 (also STD 63), November 2003. - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 4234, October 2005. - - [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification - Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in - progress. - - - -Zeilenga IANA Considerations for LDAP [Page 12] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and - Connection Level Security Mechanisms", - draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. - - [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. - - [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", - draft-ietf-ldapbis-url-xx.txt, a work in progress. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the "Unicode Standard Annex #27: Unicode - 3.1" (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(2002) (also ISO/IEC 8824-1:2002). - - -9.2. Informative References - - [RFC1779] Kille, S., "A String Representation of Distinguished - Names", RFC 1779, March 1995. - - [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol - version 2 (LDAPv2) to Historic Status", RFC 3494, March - 2003. - - [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", - draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. - - [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of - Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a - work in progress. - - [SASL] Melnikov, A. (Editor), "Simple Authentication and - Security Layer (SASL)", - draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. - - - - -Zeilenga IANA Considerations for LDAP [Page 13] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - [IANADSN] IANA, "Directory Systems Names", - http://www.iana.org/assignments/directory-system-names. - - -Appendix A. Registration Templates - - This appendix provides registration templates for registering new - LDAP values. Note that more than one value may be requested by - extending the template by listing multiple values, or through use of - tables. - - -A.1. LDAP Object Identifier Registration Template - - Subject: Request for LDAP OID Registration - - Person & email address to contact for further information: - - Specification: (I-D) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.2. LDAP Protocol Mechanism Registration Template - - Subject: Request for LDAP Protocol Mechanism Registration - - Object Identifier: - - Description: - - Person & email address to contact for further information: - - Usage: (One of Control or Extension or Feature or other) - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - - - - -Zeilenga IANA Considerations for LDAP [Page 14] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - -A.3. LDAP Syntax Registration Template - - Subject: Request for LDAP Syntax Registration - - Object Identifier: - - Description: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.4. LDAP Descriptor Registration Template - - Subject: Request for LDAP Descriptor Registration - - Descriptor (short name): - - Object Identifier: - - Person & email address to contact for further information: - - Usage: (One of administrative role, attribute type, matching rule, - name form, object class, URL extension, or other) - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.5. LDAP Attribute Description Option Registration Template - - Subject: Request for LDAP Attribute Description Option Registration - - Option Name: - - Family of Options: (YES or NO) - - - -Zeilenga IANA Considerations for LDAP [Page 15] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.6. LDAP Message Type Registration Template - - Subject: Request for LDAP Message Type Registration - - LDAP Message Name: - - Person & email address to contact for further information: - - Specification: (Approved I-D) - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.7. LDAP Authentication Method Registration Template - - Subject: Request for LDAP Authentication Method Registration - - Authentication Method Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.8. LDAP Result Code Registration Template - - Subject: Request for LDAP Result Code Registration - - - -Zeilenga IANA Considerations for LDAP [Page 16] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - Result Code Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.8. LDAP Search Scope Registration Template - - Subject: Request for LDAP Search Scope Registration - - Search Scope Name: - - Filter Scope String: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -A.9. LDAP Filter Choice Registration Template - - Subject: Request for LDAP Filter Choice Registration - - Filter Choice Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - - - -Zeilenga IANA Considerations for LDAP [Page 17] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - -A.10. LDAP ModifyRequest Operation Registration Template - - Subject: Request for LDAP ModifyRequest Operation Registration - - ModifyRequest Operation Name: - - Person & email address to contact for further information: - - Specification: (RFC, I-D, URI) - - Author/Change Controller: - - Comments: - - (Any comments that the requester deems relevant to the request) - - -Appendix B. Changes since RFC 3383 - - This informative appendix provides a summary of changes made since RFC - 3383. - - - Object Identifier Descriptors practices were updated to require - all descriptors defined in RFCs to be registered and - recommending all other descriptors (excepting those in - private-use name space) be registered. Additionally, all - requests for multiple registrations of the same descriptor are - now subject to Expert Review. - - - Protocol Mechanisms practices were updated to include values of - the 'supportedFeatures' attribute type. - - - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest - operation, and authzId prefixes registries were added. - [[Initial values provided in Appendix C. This Appendix is to be - removed by the RFC Editor before publication as an RFC.]] - - - References to RFCs comprising the LDAP technical specifications - have been updated to latest revisions. - - - References to ISO 10646 have been replaced with [Unicode]. - - - The "Assigned Values" appendix providing initial registry values - was removed. - - - Numerous editorial changes were made. - - - - - -Zeilenga IANA Considerations for LDAP [Page 18] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - -Appendix C. Initial Values for new registries - - This appendix provides initial values for new registries. - - -C.1. LDAP Syntaxes - - Object Identifier Syntax Owner Reference - ----------------------------- -------------------------- ----- --- - 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes] - 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes] - - -C.2. LDAP Search Scopes - - Name URLString Value Owner Reference - - - -Zeilenga IANA Considerations for LDAP [Page 19] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - ---------------- --------- ----- ----- ------------------- - baseObject base 0 IESG [Protocol][LDAPURL] - singleLevel one 1 IESG [Protocol][LDAPURL] - wholeSubtree sub 2 IESG [Protocol][LDAPURL] - - -C.3. LDAP Filter Choices - - Name Value Owner Reference - ---------------- ----- ----- --------- - and 0 IESG [Protocol] - or 1 IESG [Protocol] - not 2 IESG [Protocol] - equalityMatch 3 IESG [Protocol] - substrings 4 IESG [Protocol] - greaterOrEqual 5 IESG [Protocol] - lessOrEqual 6 IESG [Protocol] - present 7 IESG [Protocol] - approxMatch 8 IESG [Protocol] - extensibleMatch 9 IESG [Protocol] - - -C.4. LDAP ModifyRequest Operations - - Name Value Owner Reference - ---------------- ----- ----- --------- - add 0 IESG [Protocol] - delete 1 IESG [Protocol] - replace 2 IESG [Protocol] - - -C.5. LDAP authzId prefixes - - Name Prefix Owner Reference - ---------------- ------ ----- --------- - dnAuthzId dn: IESG [AuthMeth] - uAuthzId u: IESG [AuthMeth] - - -Full Copyright - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - - - -Zeilenga IANA Considerations for LDAP [Page 20] - -INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 - - - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be found - in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this specification - can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - - - - - - - - -Zeilenga IANA Considerations for LDAP [Page 21] - diff --git a/doc/drafts/draft-ietf-ldapbis-dn-xx.txt b/doc/drafts/draft-ietf-ldapbis-dn-xx.txt deleted file mode 100644 index 458f65eea1..0000000000 --- a/doc/drafts/draft-ietf-ldapbis-dn-xx.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 10 February 2005 -Obsoletes: RFC 2253 - - - - LDAP: String Representation of Distinguished Names - - - - -Status of Memo - - 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 . - - By submitting this Internet-Draft, I accept the provisions of Section - 4 of RFC 3667. By submitting this Internet-Draft, I certify that any - applicable patent or other IPR claims of which I am aware have been - disclosed, or will be disclosed, and any of which I become aware will - be disclosed, in accordance with RFC 3668. - - 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 - - - Copyright (C) The Internet Society (2005). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - - -Zeilenga LDAP: Distinguished Names [Page 1] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - -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 - designed to give a clean representation of commonly used distinguished - names, while being able to represent any distinguished name. - - -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 directory - entries [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 the string form - described in this document. - - 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 the local - national language). - - 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 a integral part of the LDAP technical specification - [Roadmap] which obsoletes the previously defined LDAP technical - - - -Zeilenga LDAP: Distinguished Names [Page 2] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - specification, RFC 3377, in its entirety. 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]. - - -1.1. 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]. - - Character names in this document use the notation for code points and - names from the Unicode Standard [Unicode]. For example, the letter - "a" may be represented as either or . - - Note: a glossary of terms used in Unicode can be found in [Glossary]. - Information on the Unicode character encoding model can be found in - [CharModel]. - - -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 - [RFC3629] encoded Unicode [Unicode] 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 SHALL be produced by LDAP - implementations. - - -2.1. Converting the RDNSequence - - - -Zeilenga LDAP: Distinguished Names [Page 3] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - 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 - - 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 sign ('=' 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 (descriptor) - [Models] and that short name is known to be registered - [REGISTRY][BCP64bis] 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 to 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 - - - -Zeilenga LDAP: Distinguished Names [Page 4] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - the X.500 AttributeValue. This form is also used when the syntax of - the AttributeValue does not have a LDAP-specific [Syntaxes, Section - 3.1] string encoding defined for it or the LDAP-specific string - encoding is not restricted to UTF-8 encoded Unicode 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 - LDAP-specific string encoding, the value is converted first to a UTF-8 - encoded Unicode string according to its syntax specification (see - [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode - 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. - - - 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+005C). - - 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 [RFC3629] encoded Unicode [Unicode] characters. The structure - of this string representation is specified using the following - - - -Zeilenga LDAP: Distinguished Names [Page 5] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - Augmented BNF [RFC2234] grammar: - - distinguishedName = [ relativeDistinguishedName - *( COMMA relativeDistinguishedName ) ] - relativeDistinguishedName = attributeTypeAndValue - *( PLUS attributeTypeAndValue ) - attributeTypeAndValue = attributeType EQUALS attributeValue - attributeType = descr / numericoid - attributeValue = string / hexstring - - ; The following characters are to be escaped when they appear - ; in the value to be encoded: ESC, one of , leading - ; SHARP or SPACE, trailing SPACE, and NULL. - 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 ; - - - -Zeilenga LDAP: Distinguished Names [Page 6] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - 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 - 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 - - - -Zeilenga LDAP: Distinguished Names [Page 7] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - This example shows the method of escaping of a special characters - appearing in a common name: - - CN=James \"Jim\" Smith\, III,DC=example,DC=net - - The following shows the method for encoding a value which contains a - carriage return character: - - CN=Before\0dAfter,DC=example,DC=net - - In this RDN example, the type in the RDN is unrecognized, and 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 - - Finally, this example shows an RDN whose commonName value consisting - of 5 letters: - - Unicode Character 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 encoded in printable ASCII (useful for debugging purposes) - as: - - 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: - - - - -Zeilenga LDAP: Distinguished Names [Page 8] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - - 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) - - In some cases, such information can be considered sensitive. In many - countries, privacy laws exist which prohibit disclosure of certain - kinds of descriptive information (e.g., email addresses). Hence, - servers implementors are encouraged to support DIT structural rules - and name forms [Models] as these provide a mechanism for - administrators to select appropriate naming attributes for entries. - Administrators are encouraged to use these mechanisms, access - controls, and other administrative controls which may be available to - restrict use of attributes containing sensitive information in naming - of entries. Additionally, use of authentication and data security - services in LDAP [AuthMeth][Protocol] should be considered. - - -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 . Another distinguished name in which the value is - still 'Sam' but of the PrintableString choice would have the same - representation . - - 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 ('#' - U+0023) as described in the first paragraph of Section 2.4. - - -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. - - - - - -Zeilenga LDAP: Distinguished Names [Page 9] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - -7. Document Editor's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - Email: Kurt@OpenLDAP.org - - -8. References - - [[Note to the RFC Editor: please replace the citation tags used in - referencing Internet-Drafts with tags of the form RFCnnnn where - possible.]] - - -8.1. Normative References - - [X.501] International Telecommunication Union - - Telecommunication Standardization Sector, "The Directory - -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). - - [X.680] International Telecommunication Union - - Telecommunication Standardization Sector, "Abstract - Syntax Notation One (ASN.1) - Specification of Basic - Notation", X.680(1997) (also ISO/IEC 8824-1:1998). - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 3629 (also STD 63), November 2003. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the "Unicode Standard Annex #27: Unicode - 3.1" (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [Models] Zeilenga, K. (editor), "LDAP: Directory Information - Models", draft-ietf-ldapbis-models-xx.txt, a work in - progress. - - [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification - - - -Zeilenga LDAP: Distinguished Names [Page 10] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in - progress. - - [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", - draft-ietf-ldapbis-protocol-xx.txt, a work in progress. - - [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", - draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. - - [Schema] Dally, K. (editor), "LDAP: User Schema", - draft-ietf-ldapbis-user-schema-xx.txt, a work in - progress. - - [REGISTRY] IANA, Object Identifier Descriptors Registry, - . - -8.2. Informative References - - [ASCII] Coded Character Set--7-bit American Standard Code for - Information Interchange, ANSI X3.4-1986. - - [X.500] International Telecommunication Union - - Telecommunication Standardization Sector, "The Directory - -- Overview of concepts, models and services," - X.500(1993) (also ISO/IEC 9594-1:1994). - - [X.690] International Telecommunication Union - - Telecommunication Standardization Sector, "Specification - of ASN.1 encoding rules: Basic Encoding Rules (BER), - Canonical Encoding Rules (CER), and Distinguished - Encoding Rules (DER)", X.690(1997) (also ISO/IEC - 8825-1:1998). - - [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - - Technical Specification", RFC 2849, June 2000. - - [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", - draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. - - [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report - #17, Character Encoding Model", UTR17, - , August - 2000. - - [Glossary] The Unicode Consortium, "Unicode Glossary", - . - - - - - -Zeilenga LDAP: Distinguished Names [Page 11] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - -Appendix A. Presentation Issues - - This appendix is provided for informational purposes only, it is not a - normative part of this specification. - - 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 - Unicode characters. Some Unicode 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: - - - -Zeilenga LDAP: Distinguished Names [Page 12] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - 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. - - 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. - - Replaced all references to ISO 10646-1 with [Unicode]. - - Clarified (in Section 1) that this document does not define a - canonical string representation. - - Clarified that Section 2 describes the RECOMMENDED encoding - algorithm and that alternative algorithms are allowed. Some - encoding options described in RFC 2253 are now treated as - alternative algorithms in this specification. - - Revised specification (in Section 2) to allow short names of any - registered attribute type to appear in string representations of - DNs instead of being restricted to a "published table". Remove - "as an example" language. Added statement (in Section 3) allowing - recognition of additional names but require recognization of those - names in the published table. The table is now published in - Section 3. - - Removed specification of additional requirements for LDAPv2 - implementations which also support LDAPv3 (RFC 2253, Section 4) as - LDAPv2 is now Historic. - - Allow recognition of alternative string representations. - - Updated Section 2.4 to allow hex pair escaping of all characters - and clarified escaping for when multiple octet UTF-8 encodings are - present. Indicated that null (U+0000) character is to be escaped. - - - -Zeilenga LDAP: Distinguished Names [Page 13] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - - Indicated that equals sign ('=' U+003D) character may be escaped - as '\='. - - Rewrote Section 3 to use ABNF as defined in RFC 2234. - - Updated the Section 3 ABNF. Changes include: - + allow AttributeType short names of length 1 (e.g., 'L'), - + use more restrictive production in AttributeTypes, - + do not require escaping of equals sign ('=' U+003D) characters, - + do not require escaping of non-leading number sign ('#' U+0023) - characters, - + allow space (' ' U+0020) to escaped as '\ ', - + require hex escaping of null (U+0000) characters, and - + removed LDAPv2-only constructs. - - 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. - - In addition, numerous editorial changes were made. - - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be found - in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this specification - can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - -Zeilenga LDAP: Distinguished Names [Page 14] - -INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005 - - -Full Copyright - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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 15] - - diff --git a/doc/drafts/draft-ietf-ldapbis-filter-xx.txt b/doc/drafts/draft-ietf-ldapbis-filter-xx.txt deleted file mode 100644 index 8f00270523..0000000000 --- a/doc/drafts/draft-ietf-ldapbis-filter-xx.txt +++ /dev/null @@ -1,724 +0,0 @@ -Network Working Group M. Smith, Editor -Request for Comments: DRAFT Pearl Crescent, LLC -Obsoletes: RFC 2254 T. Howes -Expires: 16 May 2005 Opsware, Inc. - 16 November 2004 - - - LDAP: String Representation of Search Filters - - - - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she become - aware will be disclosed, in accordance with RFC 3668. - - This document is intended to be published as a Standards Track RFC, - replacing RFC 2254. Distribution of this memo is unlimited. - Technical discussion of this document will take place on the IETF - LDAP (v3) Revision (ldapbis) Working Group mailing list - . Please send editorial comments directly - to the 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 a "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 - - Copyright (C) The Internet Society (2004). All Rights Reserved. - Please see the Full Copyright section near the end of this document - for more information. - - - - - - -Smith & Howes Intended Category: Standards Track [Page 1] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - -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 [LDAPURL] and - in other applications. - -Table of Contents - - Status of this Memo............................................1 - Abstract.......................................................2 - Table of Contents..............................................2 -1. Introduction...................................................2 -2. LDAP Search Filter Definition..................................3 -3. String Search Filter Definition................................4 -4. Examples.......................................................6 -5. Security Considerations........................................7 -6. IANA Considerations............................................7 -7. Normative References...........................................7 -8. Informative References.........................................8 -9. Acknowledgments................................................8 -10. Authors' Addresses.............................................9 -11. Appendix A: Changes Since RFC 2254.............................9 -11.1. Technical Changes...........................................9 -11.2. Editorial Changes...........................................10 -12. Appendix B: Changes Since Previous Document Revision...........11 -12.1. Technical Changes...........................................11 -12.2. Editorial Changes...........................................12 - Intellectual Property Rights...................................12 - Full Copyright.................................................13 - -1. Introduction - - The Lightweight Directory Access Protocol (LDAP) [Roadmap] 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 a integral part of the LDAP technical specification - [Roadmap] which obsoletes the previously defined LDAP technical - specification, RFC 3377, in its entirety. - - - - - -Smith & Howes Intended Category: Standards Track [Page 2] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - 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]. - -2. LDAP Search Filter Definition - - An LDAP search filter is defined in Section 4.5.1 of [Protocol] as - follows: - - Filter ::= CHOICE { - and [0] SET SIZE (1..MAX) OF filter Filter, - or [1] SET SIZE (1..MAX) OF filter 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, - -- initial and final can occur at most once - substrings SEQUENCE SIZE (1..MAX) OF substring 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 - -- [Models] - - AttributeValue ::= OCTET STRING - - - - -Smith & Howes Intended Category: Standards Track [Page 3] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - MatchingRuleId ::= LDAPString - - AssertionValue ::= OCTET STRING - - LDAPString ::= OCTET STRING -- UTF-8 encoded, - -- [Unicode] characters - - The AttributeDescription, as defined in [Protocol], is a string - representation of the attribute description that is discussed in - [Models]. The AttributeValue and AssertionValue OCTET STRING have - the form defined in [Syntaxes]. The Filter is encoded for - transmission over a network using the Basic Encoding Rules (BER) - defined in [X.690], with simplifications described in [Protocol]. - -3. String Search Filter Definition - - The string representation of an LDAP search filter is a string of - UTF-8 [RFC3629] encoded Unicode characters [Unicode] 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.4 (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 / greaterorequal / lessorequal - equal = EQUALS - approx = TILDE EQUALS - greaterorequal = RANGLE EQUALS - lessorequal = LANGLE EQUALS - extensible = ( attr [dnattrs] - [matchingrule] COLON EQUALS assertionvalue ) - / ( [dnattrs] - matchingrule COLON EQUALS assertionvalue ) - present = attr EQUALS ASTERISK - substring = attr EQUALS [initial] any [final] - initial = assertionvalue - any = ASTERISK *(assertionvalue ASTERISK) - final = assertionvalue - attr = attributedescription - ; The attributedescription rule is defined in - ; Section 2.5 of [Models]. - - - -Smith & Howes Intended Category: Standards Track [Page 4] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - 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, ASTERISK, and ESC. - EXCLAMATION = %x21 ; exclamation mark ("!") - AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") - ASTERISK = %x2A ; asterisk ("*") - 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 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. Implementations SHOULD accept as input strings that - are not valid UTF-8 strings. This is necessary because RFC 2254 did - - - -Smith & Howes Intended Category: Standards Track [Page 5] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - not clearly define the term "string representation" (and in - particular did not mention that the string representation of an LDAP - search filter is a string of UTF-8 encoded Unicode characters). - -4. Examples - - This section gives a few examples of search filters written using - this notation. - - (cn=Babs Jensen) - (!(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:caseExactMatch:=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) - - The first example shows use of the matching rule "caseExactMatch." - - The second example demonstrates use of a MatchingRuleAssertion form - without a matchingRule. - - The third example illustrates the use of the ":oid" notation to - indicate that matching rule identified by the OID "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 (indicated by the use of ":dn"). - - 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 has been - omitted). - - The sixth and final 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. - - - - -Smith & Howes Intended Category: Standards Track [Page 6] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - 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) - - 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 octet value - 00 00 00 04 (hex), 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. Specifically, there are - 5 characters in the portion of this example: LATIN - CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL - LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and - LATIN SMALL LETTER C WITH ACUTE (U+0107). - - The sixth and final example demonstrates assertion of a BER encoded - value. - -5. 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. - -6. IANA Considerations - - This document has no actions for IANA. - -7. Normative References - -[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and - Connection Level Security Mechanisms", - - - -Smith & Howes Intended Category: Standards Track [Page 7] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. - -[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", - draft-ietf-ldapbis-models-xx.txt, a work in progress. - -[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. - -[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - -[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - RFC 3629, November 2003. - -[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. - -[Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version 3.0" - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as - amended by the "Unicode Standard Annex #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the "Unicode - Standard Annex #28: Unicode 3.2." - -8. Informative References - -[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", - draft-ietf-ldapbis-url-xx.txt, a work in progress. - -[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and - Distinguished Encoding Rules, ITU-T Recommendation X.690, - 1994. - -9. Acknowledgments - - This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product - of the IETF ASID Working Group. - - 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. - - - -Smith & Howes Intended Category: Standards Track [Page 8] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - -10. Authors' Addresses - - Mark Smith, Editor - Pearl Crescent, LLC - 447 Marlpool Dr. - Saline, MI 48176 - USA - +1 734 944-2856 - mcs@pearlcrescent.com - - - Tim Howes - Opsware, Inc. - 599 N. Mathilda Ave. - Sunnyvale, CA 94085 - USA - +1 408 744-7509 - howes@opsware.com - -11. Appendix A: Changes Since RFC 2254 - -11.1. Technical Changes - - Replaced [ISO 10646] reference with [Unicode]. - - 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 Unicode 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]. - - Added "(" and ")" around the components of the - subproductions for clarity. - - Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more - precisely reference productions from the [Models] and [Protocol] - documents. - - "String Search Filter Definition" section: replaced "greater" and - "less" with "greaterorequal" and "lessorequal" to avoid confusion. - - - - - -Smith & Howes Intended Category: Standards Track [Page 9] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - 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 statement about expected behavior in light of RFC 2254's lack - of a clear definition of "string representation." - - - -11.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", "IANA Considerations", and "Intellectual - Property Rights" sections: added. - - Copyright: updated per latest IETF guidelines. - - "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 LDAP - 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 four additional examples: (seeAlso=), - (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and - (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a - value" with "an assertion value". Corrected the description of this - example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID - in the first extensible match example with "caseExactMatch" to - demonstrate use of the descriptive form. Used "DN" (uppercase) in - - - -Smith & Howes Intended Category: Standards Track [Page 10] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - the last extensible match example to remind the reader to treat the - production as case insensitive. Reworded the description - of the fourth escaping mechanism example to avoid making assumptions - about byte order. Added text to the fifth escaping mechanism example - to spell out what the non-ASCII characters are in Unicode terms. - - "Security Considerations" section: added references to [Protocol] and - [AuthMeth]. - - "Normative References" section: renamed from "References" per new RFC - guidelines. Changed from [1] style to [Protocol] style throughout the - document. Added entries for [Unicode], [RFC2119], [AuthMeth], - [Models], and [Roadmap] and updated the UTF-8 reference. Replaced - RFC 822 reference with a reference to RFC 2234. - - "Informative References" section: (new section) moved [X.690] to this - section. Added a reference to [LDAPURL]. - - "Acknowledgments" section: added. - - "Appendix A: Changes Since RFC 2254" section: added. - - "Appendix B: Changes Since Previous Document Revision" section: - added. - - Surrounded the names of all ABNF productions with "<" and ">" where - they are used in descriptive text. - - Replaced all occurrences of "LDAPv3" with "LDAP." - - -12. Appendix B: Changes Since Previous Document Revision - - This appendix lists all changes relative to the previously published - revision, draft-ietf-ldapbis-filter-08.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-08.txt. This section will be - removed before this document is published as an RFC. - - -12.1. Technical Changes - - Removed the third option from the "extensible" production that - allowed creation of a MatchingRuleAssertion that only had a - matchValue (disallowed By [Protocol]). Added "(" and ")" around the - components of the subproductions for clarity. - - - - -Smith & Howes Intended Category: Standards Track [Page 11] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - -12.2. Editorial Changes - - "Introduction" section: referenced [Roadmap] upon first use of LDAP - and expanded the paragraph that begins "This document is an integral - part of the LDAP technical specification..." to match the text used - in [Protocol]. - - "LDAP Search Filter Definition" section: reworded the last paragraph - for clarity. - - "Examples" section: Replaced the numeric OID in the first extensible - match example with "caseExactMatch" to demonstrate use of the - descriptive form. Used "DN" (uppercase) in the last extensible match - example to remind the reader to treat the production as - case insensitive. Reworded the description of the fourth escaping - mechanism example to avoid making assumptions about byte order. - Added text to the fifth escaping mechanism example to spell out what - the non-ASCII characters are in Unicode terms. - - References: added [LDAPURL] and moved [X.690] to "Informative - References." - - "Acknowledgements" section: added the sentence "RFC 2254 was a - product of the IETF ASID Working Group." - - Changed these two sections to unnumbered ones: "Intellectual Property - Rights" and "Full Copyright." - - Surrounded the names of all ABNF productions with "<" and ">" where - they are used in descriptive text. - - Replaced all occurrences of "LDAPv3" with "LDAP." - - -Intellectual Property Rights - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - - - -Smith & Howes Intended Category: Standards Track [Page 12] - -INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004 - - - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Full Copyright - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - -This Internet Draft expires on 16 May 2005. - - - - - - - - - - - - - - - - - - - - - - - - - -Smith & Howes Intended Category: Standards Track [Page 13] \ No newline at end of file diff --git a/doc/drafts/draft-ietf-ldapbis-models-xx.txt b/doc/drafts/draft-ietf-ldapbis-models-xx.txt deleted file mode 100644 index 43d85caa0b..0000000000 --- a/doc/drafts/draft-ietf-ldapbis-models-xx.txt +++ /dev/null @@ -1,2857 +0,0 @@ - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 21 February 2005 -Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674 - - - - LDAP: Directory Information Models - - - - -Status of this Memo - - 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 editor . - - By submitting this Internet-Draft, I accept the provisions of Section - 4 of RFC 3667. By submitting this Internet-Draft, I certify that any - applicable patent or other IPR claims of which I am aware have been - disclosed, or will be disclosed, and any of which I become aware will - be disclosed, in accordance with RFC 3668. - - 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 - - - Copyright (C) The Internet Society (2005). All Rights Reserved. - - Please see the Full Copyright section near the end of this document - for more information. - - - - - -Zeilenga LDAP Models [Page 1] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - -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. - -Table of Contents - - Status of this Memo 1 - Abstract 2 - Table of Contents - 1. Introduction 3 - 1.1. Relationship to Other LDAP Specifications - 1.2. Relationship to X.501 4 - 1.3. Conventions - 1.4. Common ABNF Productions - 2. Model of Directory User Information 6 - 2.1. The Directory Information Tree 7 - 2.2. Structure of an Entry - 2.3. Naming of Entries 8 - 2.4. Object Classes 9 - 2.5. Attribute Descriptions 12 - 2.6. Alias Entries 16 - 3. Directory Administrative and Operational Information 17 - 3.1. Subtrees - 3.2. Subentries 18 - 3.3. The 'objectClass' attribute - 3.4. Operational attributes 19 - 4. Directory Schema 22 - 4.1. Schema Definitions 23 - 4.2. Subschema Subentries 32 - 4.3. 'extensibleObject' 35 - 4.4. Subschema Discovery 36 - 5. DSA (Server) Informational Model - 5.1. Server-specific Data Requirements 37 - 6. Other Considerations 40 - 6.1. Preservation of User Information 41 - 6.2. Short Names - 6.3. Cache and Shadowing - 7. Implementation Guidelines 42 - 7.1. Server Guidelines - 7.2. Client Guidelines - 8. Security Considerations 43 - 9. IANA Considerations - 10. Acknowledgments 44 - 11. Editor's Address - 12. References - - - -Zeilenga LDAP Models [Page 2] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - 12.1. Normative References 45 - 12.2. Informative References - Appendix A. Changes - Intellectual Property Rights 51 - Full Copyright - - -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 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 - - - -Zeilenga LDAP Models [Page 3] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - 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 summarizes changes to - these sections. The remainder of RFC 2251 is obsoleted by the - [Protocol], [AuthMeth], and [Roadmap] documents. - - This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 - summarizes changes to these sections. The remainder of RFC 2252 is - obsoleted by [Syntaxes]. - - 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]. - - This document obsoletes RFC 3674 in its entirety. Appendix A.4 - summarizes changes since RFC 3674. - - -1.2. Relationship to X.501 - - This document includes material, with and without adaptation, from - [X.501] as necessary to describe this protocol. These adaptations - (and any other differences herein) apply to this protocol, and only - this protocol. - - -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 - - - -Zeilenga LDAP Models [Page 4] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - 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 " " - 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 (">") - ESC = %x5C ; backslash ("\") - USCORE = %x5F ; underscore ("_") - LCURLY = %x7B ; left curly brace "{" - RCURLY = %x7D ; right curly brace "}" - - ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character - UTF8 = UTF1 / UTFMB - UTFMB = UTF2 / UTF3 / UTF4 - UTF0 = %x80-BF - UTF1 = %x00-7F - UTF2 = %xC2-DF UTF0 - UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / - %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) - UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / - %xF4 %x80-8F 2(UTF0) - - OCTET = %x00-FF ; Any octet (8-bit data unit) - - Object identifiers (OIDs) [X.680] are represented in LDAP using a - dot-decimal format conforming to the ABNF: - - - - -Zeilenga LDAP Models [Page 5] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - numericoid = number 1*( 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 - - 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. - - Implementations SHOULD treat short names (descriptors) used in an - ambiguous manner (as discussed above) as unrecognized. - - 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 - - - -Zeilenga LDAP Models [Page 6] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - 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). - - Section 2.1 describes the Directory Information Tree - Section 2.2 discusses the structure of entries. - Section 2.3 discusses naming 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. Structure of an Entry - - An entry consists of a set of attributes which hold information about - the object which the 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 - - - -Zeilenga LDAP Models [Page 7] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - '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. - - Attribute values conform to the defined syntax of the attribute type. - - No two values of an attribute may be equivalent. Two values are - considered equivalent if and only if they would match according to the - equality matching rule of the attribute type or, if the attribute type - is defined with no equality matching rule, two values are equivalent - if and only if they are identical. (See 2.5.1 for other - restrictions.) - - For example, a 'givenName' attribute can have more than one value, - they must be Directory Strings, and they are case insensitive. A - 'givenName' attribute cannot hold both "John" and "JOHN" as these are - equivalent values per the equality matching rule of the attribute - type. - - Additionally, no attribute is to have a value which is not equivalent - to itself. For example, the 'givenName' attribute cannot have as a - value a directory string which includes the REPLACEMENT CHARACTER - (U+FFFD) code point as matching involving that directory string is - Undefined per this attribute's equality matching rule. - - When an attribute is used for naming of the entry, one and only one - value of the attribute is used in forming the Relative Distinguished - Name. This value is known as a distinguished value. - - -2.3. Naming of Entries - -2.3.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 to match attribute values - (each a distinguished value) 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 - - - -Zeilenga LDAP Models [Page 8] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - siblings). - - The following are examples of string representations of RDNs [LDAPDN]: - - 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.3.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 examples of 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.3.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.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; - - - - -Zeilenga LDAP Models [Page 9] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - - 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 - 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'. - - - - -Zeilenga LDAP Models [Page 10] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - - The following is the object class definition (see Section 4.1.1) for - the 'top' object class: - - ( 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. - - 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. - - - - - -Zeilenga LDAP Models [Page 11] - -INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005 - - -2.4.3. Auxiliary Object Classes - - Auxiliary object classes are used to augment the characteristics of - entries. They are commonly used to augment the sets of attributes - required and allowed 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 the 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 - 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