diff options
24 files changed, 27176 insertions, 0 deletions
diff --git a/source4/ldap_server/devdocs/rfc4510.txt b/source4/ldap_server/devdocs/rfc4510.txt new file mode 100644 index 0000000000..8ba41d1d93 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4510.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. Zeilenga, Ed. +Request for Comments: 4510 OpenLDAP Foundation +Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006 + 2256, 2829, 2830, 3377, 3771 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Technical Specification Road Map + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an Internet + protocol for accessing distributed directory services that act in + accordance with X.500 data and service models. This document + provides a road map of the LDAP Technical Specification. + +1. The LDAP Technical Specification + + The technical specification detailing version 3 of the Lightweight + Directory Access Protocol (LDAP), an Internet Protocol, consists of + this document and the following documents: + + LDAP: The Protocol [RFC4511] + LDAP: Directory Information Models [RFC4512] + LDAP: Authentication Methods and Security Mechanisms [RFC4513] + LDAP: String Representation of Distinguished Names [RFC4514] + LDAP: String Representation of Search Filters [RFC4515] + LDAP: Uniform Resource Locator [RFC4516] + LDAP: Syntaxes and Matching Rules [RFC4517] + LDAP: Internationalized String Preparation [RFC4518] + LDAP: Schema for User Applications [RFC4519] + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4510 LDAP: TS Road Map June 2006 + + + The terms "LDAP" and "LDAPv3" are commonly used to refer informally + to the protocol specified by this technical specification. The LDAP + suite, as defined here, should be formally identified in other + documents by a normative reference to this document. + + LDAP is an extensible protocol. Extensions to LDAP may be specified + in other documents. Nomenclature denoting such combinations of + LDAP-plus-extensions is not defined by this document but may be + defined in some future document(s). Extensions are expected to be + truly optional. Considerations for the LDAP extensions described in + BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP + Technical Specification. + + IANA (Internet Assigned Numbers Authority) considerations for LDAP + described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision + of the LDAP technical specification. + +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]. + +2. Relationship to X.500 + + This technical specification defines LDAP in terms of [X.500] as an + X.500 access mechanism. An LDAP server MUST act in accordance with + the X.500 (1993) series of International Telecommunication Union - + Telecommunication Standardization (ITU-T) Recommendations when + providing the service. However, it is not required that an LDAP + server make use of any X.500 protocols in providing this service. + For example, LDAP can be mapped onto any other directory system so + long as the X.500 data and service models [X.501][X.511], as used in + LDAP, are not violated in the LDAP interface. + + This technical specification explicitly incorporates portions of + X.500(93). Later revisions of X.500 do not automatically apply to + this technical specification. + +3. Relationship to Obsolete Specifications + + This technical specification, as defined in Section 1, obsoletes + entirely the previously defined LDAP technical specification defined + in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and + 3377 itself). The technical specification was significantly + reorganized. + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4510 LDAP: TS Road Map June 2006 + + + This document replaces RFC 3377 as well as Section 3.3 of RFC 2251. + [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256. + [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and + all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions + of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and + portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256. + [RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516] + replaces RFC 2255. + + [RFC4518] is new to this revision of the LDAP technical + specification. + + Each document of this specification contains appendices summarizing + changes to all sections of the specifications they replace. Appendix + A.1 of this document details changes made to RFC 3377. Appendix A.2 + of this document details changes made to Section 3.3 of RFC 2251. + + Additionally, portions of this technical specification update and/or + replace a number of other documents not listed above. These + relationships are discussed in the documents detailing these portions + of this technical specification. + +4. Security Considerations + + LDAP security considerations are discussed in each document + comprising the technical specification. + +5. Acknowledgements + + This document is based largely on RFC 3377 by J. Hodges and R. + Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The + document also borrows from RFC 2251 by M. Wahl, T. Howes, and S. + Kille, a product of the ASID Working Group. + + This document is a product of the IETF LDAPBIS Working Group. + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4510 LDAP: TS Road Map June 2006 + + +6. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): String Representation of Search + Filters", RFC 4515, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Internationalized String Preparation", RFC + 4518, June 2006. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP + 118, RFC 4521, June 2006. + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4510 LDAP: TS Road Map June 2006 + + + [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.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models", X.501(1993) (also ISO/IEC 9594- + 2:1994). + + [X.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993) + (also ISO/IEC 9594-3:1993). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4510 LDAP: TS Road Map June 2006 + + +Appendix A. Changes to Previous Documents + + This appendix outlines changes this document makes relative to the + documents it replaces (in whole or in part). + +A.1. Changes to RFC 3377 + + This document is nearly a complete rewrite of RFC 3377 as much of the + material of RFC 3377 is no longer applicable. The changes include + redefining the terms "LDAP" and "LDAPv3" to refer to this revision of + the technical specification. + +A.2. Changes to Section 3.3 of RFC 2251 + + The section was modified slightly (the word "document" was replaced + with "technical specification") to clarify that it applies to the + entire LDAP technical specification. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4510 LDAP: TS Road Map June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 7] + diff --git a/source4/ldap_server/devdocs/rfc4511.txt b/source4/ldap_server/devdocs/rfc4511.txt new file mode 100644 index 0000000000..8041f30544 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4511.txt @@ -0,0 +1,3811 @@ + + + + + + +Network Working Group J. Sermersheim, Ed. +Request for Comments: 4511 Novell, Inc. +Obsoletes: 2251, 2830, 3771 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): The Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes the protocol elements, along with their + semantics and encodings, of the Lightweight Directory Access Protocol + (LDAP). LDAP provides access to distributed directory services that + act in accordance with X.500 data and service models. These protocol + elements are based on those described in the X.500 Directory Access + Protocol (DAP). + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other LDAP Specifications ..................3 + 2. Conventions .....................................................3 + 3. Protocol Model ..................................................4 + 3.1. Operation and LDAP Message Layer Relationship ..............5 + 4. Elements of Protocol ............................................5 + 4.1. Common Elements ............................................5 + 4.1.1. Message Envelope ....................................6 + 4.1.2. String Types ........................................7 + 4.1.3. Distinguished Name and Relative Distinguished Name ..8 + 4.1.4. Attribute Descriptions ..............................8 + 4.1.5. Attribute Value .....................................8 + 4.1.6. Attribute Value Assertion ...........................9 + 4.1.7. Attribute and PartialAttribute ......................9 + 4.1.8. Matching Rule Identifier ...........................10 + 4.1.9. Result Message .....................................10 + 4.1.10. Referral ..........................................12 + + + +Sermersheim Standards Track [Page 1] + +RFC 4511 LDAPv3 June 2006 + + + 4.1.11. Controls ..........................................14 + 4.2. Bind Operation ............................................16 + 4.2.1. Processing of the Bind Request .....................17 + 4.2.2. Bind Response ......................................18 + 4.3. Unbind Operation ..........................................18 + 4.4. Unsolicited Notification ..................................19 + 4.4.1. Notice of Disconnection ............................19 + 4.5. Search Operation ..........................................20 + 4.5.1. Search Request .....................................20 + 4.5.2. Search Result ......................................27 + 4.5.3. Continuation References in the Search Result .......28 + 4.6. Modify Operation ..........................................31 + 4.7. Add Operation .............................................33 + 4.8. Delete Operation ..........................................34 + 4.9. Modify DN Operation .......................................34 + 4.10. Compare Operation ........................................36 + 4.11. Abandon Operation ........................................36 + 4.12. Extended Operation .......................................37 + 4.13. IntermediateResponse Message .............................39 + 4.13.1. Usage with LDAP ExtendedRequest and + ExtendedResponse ..................................40 + 4.13.2. Usage with LDAP Request Controls ..................40 + 4.14. StartTLS Operation .......................................40 + 4.14.1. StartTLS Request ..................................40 + 4.14.2. StartTLS Response .................................41 + 4.14.3. Removal of the TLS Layer ..........................41 + 5. Protocol Encoding, Connection, and Transfer ....................42 + 5.1. Protocol Encoding .........................................42 + 5.2. Transmission Control Protocol (TCP) .......................43 + 5.3. Termination of the LDAP session ...........................43 + 6. Security Considerations ........................................43 + 7. Acknowledgements ...............................................45 + 8. Normative References ...........................................46 + 9. Informative References .........................................48 + 10. IANA Considerations ...........................................48 + Appendix A. LDAP Result Codes .....................................49 + A.1. Non-Error Result Codes ....................................49 + A.2. Result Codes ..............................................49 + Appendix B. Complete ASN.1 Definition .............................54 + Appendix C. Changes ...............................................60 + C.1. Changes Made to RFC 2251 ..................................60 + C.2. Changes Made to RFC 2830 ..................................66 + C.3. Changes Made to RFC 3771 ..................................66 + + + + + + + + +Sermersheim Standards Track [Page 2] + +RFC 4511 LDAPv3 June 2006 + + +1. Introduction + + The Directory is "a collection of open systems cooperating to provide + directory services" [X.500]. 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)). Clients interact with servers using a directory access + protocol. + + This document details the protocol elements of the Lightweight + Directory Access Protocol (LDAP), along with their semantics. + Following the description of protocol elements, it describes the way + in which the protocol elements are encoded and transferred. + +1.1. Relationship to Other LDAP Specifications + + This document is an integral part of the LDAP Technical Specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document, together with [RFC4510], [RFC4513], and [RFC4512], + obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by + [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by + [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, + 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) + are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted + by this document. Appendix C.1 summarizes substantive changes in the + remainder. + + This document obsoletes RFC 2830, Sections 2 and 4. The remainder of + RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes + substantive changes to the remaining sections. + + This document also obsoletes RFC 3771 in entirety. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are + to be interpreted as described in [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 <U+0061> or <LATIN SMALL LETTER A>. + + + + + + +Sermersheim Standards Track [Page 3] + +RFC 4511 LDAPv3 June 2006 + + + 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]. + + 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 Transport Layer Security (TLS) + services used in providing security services, as well as associations + established by these services. + + The term "SASL layer" refers to Simply Authentication and Security + Layer (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 Protocol + Data Unit (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. + + See the table in Section 5 for an illustration of these four terms. + +3. Protocol Model + + The general model adopted by this protocol is one of clients + performing protocol operations against servers. In this model, a + client transmits a protocol request describing the operation to be + performed to a server. The server is then responsible for performing + the necessary operation(s) in the Directory. Upon completion of an + operation, the server typically returns a response containing + appropriate data to the requesting client. + + Protocol operations are generally independent of one another. Each + operation is processed as an atomic action, leaving the directory in + a consistent state. + + Although servers are required to return responses whenever such + responses are defined in the protocol, there is no requirement for + synchronous behavior on the part of either clients or servers. + Requests and responses for multiple operations generally may be + exchanged between a client and server in any order. If required, + synchronous behavior may be controlled by client applications. + + + + + +Sermersheim Standards Track [Page 4] + +RFC 4511 LDAPv3 June 2006 + + + The core protocol operations defined in this document can be mapped + to a subset of the X.500 (1993) Directory Abstract Service [X.511]. + However, there is not a one-to-one mapping between LDAP operations + and X.500 Directory Access Protocol (DAP) operations. Server + implementations acting as a gateway to X.500 directories may need to + make multiple DAP requests to service a single LDAP request. + +3.1. Operation and LDAP Message Layer Relationship + + Protocol operations are exchanged at the LDAP message layer. When + the transport connection is closed, any uncompleted operations at the + LDAP message layer are abandoned (when possible) or are completed + without transmission of the response (when abandoning them is not + possible). Also, when the transport connection is closed, the client + MUST NOT assume that any uncompleted update operations have succeeded + or failed. + +4. Elements of Protocol + + The protocol is described using Abstract Syntax Notation One + ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding + Rules ([BER]). Section 5 specifies how the protocol elements are + encoded and transferred. + + In order to support future extensions to this protocol, extensibility + is implied where it is allowed per ASN.1 (i.e., sequence, set, + choice, and enumerated types are extensible). In addition, ellipses + (...) have been supplied in ASN.1 types that are explicitly + extensible as discussed in [RFC4520]. Because of the implied + extensibility, clients and servers MUST (unless otherwise specified) + ignore trailing SEQUENCE components whose tags they do not recognize. + + Changes to the protocol other than through the extension mechanisms + described here require a different version number. A client + indicates the version it is using as part of the BindRequest, + described in Section 4.2. If a client has not sent a Bind, the + server MUST assume the client is using version 3 or later. + + Clients may attempt to determine the protocol versions a server + supports by reading the 'supportedLDAPVersion' attribute from the + root DSE (DSA-Specific Entry) [RFC4512]. + +4.1. Common Elements + + This section describes the LDAPMessage envelope Protocol Data Unit + (PDU) format, as well as data type definitions, which are used in the + protocol operations. + + + + +Sermersheim Standards Track [Page 5] + +RFC 4511 LDAPv3 June 2006 + + +4.1.1. Message Envelope + + For the purposes of protocol exchanges, all protocol operations are + encapsulated in a common envelope, the LDAPMessage, which is defined + as follows: + + LDAPMessage ::= SEQUENCE { + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse, + ..., + intermediateResponse IntermediateResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + The ASN.1 type Controls is defined in Section 4.1.11. + + The function of the LDAPMessage is to provide an envelope containing + common fields required in all protocol exchanges. At this time, the + only common fields are the messageID and the controls. + + If the server receives an LDAPMessage from the client in which the + LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot + be parsed, the tag of the protocolOp is not recognized as a request, + or the encoding structures or lengths of data fields are found to be + incorrect, then the server SHOULD return the Notice of Disconnection + + + +Sermersheim Standards Track [Page 6] + +RFC 4511 LDAPv3 June 2006 + + + described in Section 4.4.1, with the resultCode set to protocolError, + and MUST immediately terminate the LDAP session as described in + Section 5.3. + + In other cases where the client or server cannot parse an LDAP PDU, + it SHOULD abruptly terminate the LDAP session (Section 5.3) where + further communication (including providing notice) would be + pernicious. Otherwise, server implementations MUST return an + appropriate response to the request, with the resultCode set to + protocolError. + +4.1.1.1. MessageID + + All LDAPMessage envelopes encapsulating responses contain the + messageID value of the corresponding request LDAPMessage. + + The messageID of a request MUST have a non-zero value different from + the messageID of any other request in progress in the same LDAP + session. The zero value is reserved for the unsolicited notification + message. + + Typical clients increment a counter for each request. + + A client MUST NOT send a request with the same messageID as an + earlier request in the same LDAP session unless it can be determined + that the server is no longer servicing the earlier request (e.g., + after the final response is received, or a subsequent Bind + completes). Otherwise, the behavior is undefined. For this purpose, + note that Abandon and successfully abandoned operations do not send + responses. + +4.1.2. String Types + + The LDAPString is a notational convenience to indicate that, although + strings of LDAPString type encode as ASN.1 OCTET STRING types, the + [ISO10646] character set (a superset of [Unicode]) is used, encoded + following the UTF-8 [RFC3629] algorithm. Note that Unicode + characters U+0000 through U+007F are the same as ASCII 0 through 127, + respectively, and have the same single octet UTF-8 encoding. Other + Unicode characters have a multiple octet UTF-8 encoding. + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- [ISO10646] characters + + The LDAPOID is a notational convenience to indicate that the + permitted value of this string is a (UTF-8 encoded) dotted-decimal + representation of an OBJECT IDENTIFIER. Although an LDAPOID is + + + + +Sermersheim Standards Track [Page 7] + +RFC 4511 LDAPv3 June 2006 + + + encoded as an OCTET STRING, values are limited to the definition of + <numericoid> given in Section 1.4 of [RFC4512]. + + LDAPOID ::= OCTET STRING -- Constrained to <numericoid> + -- [RFC4512] + + For example, + + 1.3.6.1.4.1.1466.1.2.3 + +4.1.3. Distinguished Name and Relative Distinguished Name + + An LDAPDN is defined to be the representation of a Distinguished Name + (DN) after encoding according to the specification in [RFC4514]. + + LDAPDN ::= LDAPString + -- Constrained to <distinguishedName> [RFC4514] + + A RelativeLDAPDN is defined to be the representation of a Relative + Distinguished Name (RDN) after encoding according to the + specification in [RFC4514]. + + RelativeLDAPDN ::= LDAPString + -- Constrained to <name-component> [RFC4514] + +4.1.4. Attribute Descriptions + + The definition and encoding rules for attribute descriptions are + defined in Section 2.5 of [RFC4512]. Briefly, an attribute + description is an attribute type and zero or more options. + + AttributeDescription ::= LDAPString + -- Constrained to <attributedescription> + -- [RFC4512] + +4.1.5. Attribute Value + + A field of type AttributeValue is an OCTET STRING containing an + encoded attribute value. The attribute value is encoded according to + the LDAP-specific encoding definition of its corresponding syntax. + The LDAP-specific encoding definitions for different syntaxes and + attribute types may be found in other documents and in particular + [RFC4517]. + + AttributeValue ::= OCTET STRING + + + + + + +Sermersheim Standards Track [Page 8] + +RFC 4511 LDAPv3 June 2006 + + + Note that there is no defined limit on the size of this encoding; + thus, protocol values may include multi-megabyte attribute values + (e.g., photographs). + + Attribute values may be defined that have arbitrary and non-printable + syntax. Implementations MUST NOT display or attempt to decode an + attribute value if its syntax is not known. The implementation may + attempt to discover the subschema of the source entry and to retrieve + the descriptions of 'attributeTypes' from it [RFC4512]. + + Clients MUST only send attribute values in a request that are valid + according to the syntax defined for the attributes. + +4.1.6. Attribute Value Assertion + + The AttributeValueAssertion (AVA) type definition is similar to the + one in the X.500 Directory standards. It contains an attribute + description and a matching rule ([RFC4512], Section 4.1.3) assertion + value suitable for that type. Elements of this type are typically + used to assert that the value in assertionValue matches a value of an + attribute. + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + AssertionValue ::= OCTET STRING + + The syntax of the AssertionValue depends on the context of the LDAP + operation being performed. For example, the syntax of the EQUALITY + matching rule for an attribute is used when performing a Compare + operation. Often this is the same syntax used for values of the + attribute type, but in some cases the assertion syntax differs from + the value syntax. See objectIdentiferFirstComponentMatch in + [RFC4517] for an example. + +4.1.7. Attribute and PartialAttribute + + Attributes and partial attributes consist of an attribute description + and attribute values. A PartialAttribute allows zero values, while + Attribute requires at least one value. + + PartialAttribute ::= SEQUENCE { + type AttributeDescription, + vals SET OF value AttributeValue } + + + + + + +Sermersheim Standards Track [Page 9] + +RFC 4511 LDAPv3 June 2006 + + + Attribute ::= PartialAttribute(WITH COMPONENTS { + ..., + vals (SIZE(1..MAX))}) + + No two of the attribute values may be equivalent as described by + Section 2.2 of [RFC4512]. The set of attribute values is unordered. + Implementations MUST NOT rely upon the ordering being repeatable. + +4.1.8. Matching Rule Identifier + + Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching + rule is identified in the protocol by the printable representation of + either its <numericoid> or one of its short name descriptors + [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'. + + MatchingRuleId ::= LDAPString + +4.1.9. Result Message + + The LDAPResult is the construct used in this protocol to return + success or failure indications from servers to clients. To various + requests, servers will return responses containing the elements found + in LDAPResult to indicate the final status of the protocol operation + request. + + LDAPResult ::= SEQUENCE { + resultCode ENUMERATED { + success (0), + operationsError (1), + protocolError (2), + timeLimitExceeded (3), + sizeLimitExceeded (4), + compareFalse (5), + compareTrue (6), + authMethodNotSupported (7), + strongerAuthRequired (8), + -- 9 reserved -- + referral (10), + adminLimitExceeded (11), + unavailableCriticalExtension (12), + confidentialityRequired (13), + saslBindInProgress (14), + noSuchAttribute (16), + undefinedAttributeType (17), + inappropriateMatching (18), + constraintViolation (19), + attributeOrValueExists (20), + invalidAttributeSyntax (21), + + + +Sermersheim Standards Track [Page 10] + +RFC 4511 LDAPv3 June 2006 + + + -- 22-31 unused -- + noSuchObject (32), + aliasProblem (33), + invalidDNSyntax (34), + -- 35 reserved for undefined isLeaf -- + aliasDereferencingProblem (36), + -- 37-47 unused -- + inappropriateAuthentication (48), + invalidCredentials (49), + insufficientAccessRights (50), + busy (51), + unavailable (52), + unwillingToPerform (53), + loopDetect (54), + -- 55-63 unused -- + namingViolation (64), + objectClassViolation (65), + notAllowedOnNonLeaf (66), + notAllowedOnRDN (67), + entryAlreadyExists (68), + objectClassModsProhibited (69), + -- 70 reserved for CLDAP -- + affectsMultipleDSAs (71), + -- 72-79 unused -- + other (80), + ... }, + matchedDN LDAPDN, + diagnosticMessage LDAPString, + referral [3] Referral OPTIONAL } + + The resultCode enumeration is extensible as defined in Section 3.8 of + [RFC4520]. The meanings of the listed result codes are given in + Appendix A. If a server detects multiple errors for an operation, + only one result code is returned. The server should return the + result code that best indicates the nature of the error encountered. + Servers may return substituted result codes to prevent unauthorized + disclosures. + + The diagnosticMessage field of this construct may, at the server's + option, be used to return a string containing a textual, human- + readable diagnostic message (terminal control and page formatting + characters should be avoided). As this diagnostic message is not + standardized, implementations MUST NOT rely on the values returned. + Diagnostic messages typically supplement the resultCode with + additional information. If the server chooses not to return a + textual diagnostic, the diagnosticMessage field MUST be empty. + + + + + +Sermersheim Standards Track [Page 11] + +RFC 4511 LDAPv3 June 2006 + + + For certain result codes (typically, but not restricted to + noSuchObject, aliasProblem, invalidDNSyntax, and + aliasDereferencingProblem), the matchedDN field is set (subject to + access controls) to the name of the last entry (object or alias) used + in finding the target (or base) object. This will be a truncated + form of the provided name or, if an alias was dereferenced while + attempting to locate the entry, of the resulting name. Otherwise, + the matchedDN field is empty. + +4.1.10. Referral + + The referral result code indicates that the contacted server cannot + or will not perform the operation and that one or more other servers + may be able to. Reasons for this include: + + - The target entry of the request is not held locally, but the server + has knowledge of its possible existence elsewhere. + + - The operation is restricted on this server -- perhaps due to a + read-only copy of an entry to be modified. + + The referral field is present in an LDAPResult if the resultCode is + set to referral, and it is absent with all other result codes. It + contains one or more references to one or more servers or services + that may be accessed via LDAP or other protocols. Referrals can be + returned in response to any operation request (except Unbind and + Abandon, which do not have responses). At least one URI MUST be + present in the Referral. + + During a Search operation, after the baseObject is located, and + entries are being evaluated, the referral is not returned. Instead, + continuation references, described in Section 4.5.3, are returned + when other servers would need to be contacted to complete the + operation. + + Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI + + URI ::= LDAPString -- limited to characters permitted in + -- URIs + + If the client wishes to progress the operation, it contacts one of + the supported services found in the referral. If multiple URIs are + present, the client assumes that any supported URI may be used to + progress the operation. + + Clients that follow referrals MUST ensure that they do not loop + between servers. They MUST NOT repeatedly contact the same server + for the same request with the same parameters. Some clients use a + + + +Sermersheim Standards Track [Page 12] + +RFC 4511 LDAPv3 June 2006 + + + counter that is incremented each time referral handling occurs for an + operation, and these kinds of clients MUST be able to handle at least + ten nested referrals while progressing the operation. + + A URI for a server implementing LDAP and accessible via TCP/IP (v4 or + v6) [RFC793][RFC791] is written as an LDAP URL according to + [RFC4516]. + + Referral values that are LDAP URLs follow these rules: + + - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be + present, with the new target object name. + + - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. + + - If the <dn> part is present, the client uses this name in its next + request to progress the operation, and if it is not present the + client uses the same name as in the original request. + + - Some servers (e.g., participating in distributed indexing) may + provide a different filter in a URL of a referral for a Search + operation. + + - If the <filter> part of the LDAP URL is present, the client uses + this filter in its next request to progress this Search, and if it + is not present the client uses the same filter as it used for that + Search. + + - For Search, it is RECOMMENDED that the <scope> part be present to + avoid ambiguity. + + - If the <scope> part is missing, the scope of the original Search is + used by the client to progress the operation. + + - Other aspects of the new request may be the same as or different + from the request that generated the referral. + + Other kinds of URIs may be returned. The syntax and semantics of + such URIs is left to future specifications. Clients may ignore URIs + that they do not support. + + UTF-8 encoded characters appearing in the string representation of a + DN, search filter, or other fields of the referral value may not be + legal for URIs (e.g., spaces) and MUST be escaped using the % method + in [RFC3986]. + + + + + + +Sermersheim Standards Track [Page 13] + +RFC 4511 LDAPv3 June 2006 + + +4.1.11. Controls + + Controls provide a mechanism whereby the semantics and arguments of + existing LDAP operations may be extended. One or more controls may + be attached to a single LDAP message. A control only affects the + semantics of the message it is attached to. + + Controls sent by clients are termed 'request controls', and those + sent by servers are termed 'response controls'. + + Controls ::= SEQUENCE OF control Control + + Control ::= SEQUENCE { + controlType LDAPOID, + criticality BOOLEAN DEFAULT FALSE, + controlValue OCTET STRING OPTIONAL } + + The controlType field is the dotted-decimal representation of an + OBJECT IDENTIFIER that uniquely identifies the control. This + provides unambiguous naming of controls. Often, response control(s) + solicited by a request control share controlType values with the + request control. + + The criticality field only has meaning in controls attached to + request messages (except UnbindRequest). For controls attached to + response messages and the UnbindRequest, the criticality field SHOULD + be FALSE, and MUST be ignored by the receiving protocol peer. A + value of TRUE indicates that it is unacceptable to perform the + operation without applying the semantics of the control. + Specifically, the criticality field is applied as follows: + + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and if the criticality + field is TRUE, the server MUST NOT perform the operation, and for + operations that have a response message, it MUST return with the + resultCode set to unavailableCriticalExtension. + + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and if the criticality + field is FALSE, the server MUST ignore the control. + + - Regardless of criticality, if a control is applied to an + operation, it is applied consistently and impartially to the + entire operation. + + + + + +Sermersheim Standards Track [Page 14] + +RFC 4511 LDAPv3 June 2006 + + + The controlValue may contain information associated with the + controlType. Its format is defined by the specification of the + control. Implementations MUST be prepared to handle arbitrary + contents of the controlValue octet string, including zero bytes. It + is absent only if there is no value information that is associated + with a control of its type. When a controlValue is defined in terms + of ASN.1, and BER-encoded according to Section 5.1, it also follows + the extensibility rules in Section 4. + + Servers list the controlType of request controls they recognize in + the 'supportedControl' attribute in the root DSE (Section 5.1 of + [RFC4512]). + + Controls SHOULD NOT be combined unless the semantics of the + combination has been specified. The semantics of control + combinations, if specified, are generally found in the control + specification most recently published. When a combination of + controls is encountered whose semantics are invalid, not specified + (or not known), the message is considered not well-formed; thus, the + operation fails with protocolError. Controls with a criticality of + FALSE may be ignored in order to arrive at a valid combination. + Additionally, unless order-dependent semantics are given in a + specification, the order of a combination of controls in the SEQUENCE + is ignored. Where the order is to be ignored but cannot be ignored + by the server, the message is considered not well-formed, and the + operation fails with protocolError. Again, controls with a + criticality of FALSE may be ignored in order to arrive at a valid + combination. + + This document does not specify any controls. Controls may be + specified in other documents. Documents detailing control extensions + are to provide for each control: + + - the OBJECT IDENTIFIER assigned to the control, + + - direction as to what value the sender should provide for the + criticality field (note: the semantics of the criticality field are + defined above should not be altered by the control's + specification), + + - whether the controlValue field is present, and if so, the format of + its contents, + + - the semantics of the control, and + + - optionally, semantics regarding the combination of the control with + other controls. + + + + +Sermersheim Standards Track [Page 15] + +RFC 4511 LDAPv3 June 2006 + + +4.2. Bind Operation + + The function of the Bind operation is to allow authentication + information to be exchanged between the client and server. The Bind + operation should be thought of as the "authenticate" operation. + Operational, authentication, and security-related semantics of this + operation are given in [RFC4513]. + + The Bind request is defined as follows: + + BindRequest ::= [APPLICATION 0] SEQUENCE { + version INTEGER (1 .. 127), + name LDAPDN, + authentication AuthenticationChoice } + + AuthenticationChoice ::= CHOICE { + simple [0] OCTET STRING, + -- 1 and 2 reserved + sasl [3] SaslCredentials, + ... } + + SaslCredentials ::= SEQUENCE { + mechanism LDAPString, + credentials OCTET STRING OPTIONAL } + + Fields of the BindRequest are: + + - version: A version number indicating the version of the protocol to + be used at the LDAP message layer. This document describes version + 3 of the protocol. There is no version negotiation. The client + sets this field to the version it desires. If the server does not + support the specified version, it MUST respond with a BindResponse + where the resultCode is set to protocolError. + + - name: If not empty, the name of the Directory object that the + client wishes to bind as. This field may take on a null value (a + zero-length string) for the purposes of anonymous binds ([RFC4513], + Section 5.1) or when using SASL [RFC4422] authentication + ([RFC4513], Section 5.2). Where the server attempts to locate the + named object, it SHALL NOT perform alias dereferencing. + + - authentication: Information used in authentication. This type is + extensible as defined in Section 3.7 of [RFC4520]. Servers that do + not support a choice supplied by a client return a BindResponse + with the resultCode set to authMethodNotSupported. + + + + + + +Sermersheim Standards Track [Page 16] + +RFC 4511 LDAPv3 June 2006 + + + Textual passwords (consisting of a character sequence with a known + character set and encoding) transferred to the server using the + simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629] + encoded [Unicode]. Prior to transfer, clients SHOULD prepare text + passwords as "query" strings by applying the SASLprep [RFC4013] + profile of the stringprep [RFC3454] algorithm. Passwords + consisting of other data (such as random octets) MUST NOT be + altered. The determination of whether a password is textual is a + local client matter. + +4.2.1. Processing of the Bind Request + + Before processing a BindRequest, all uncompleted operations MUST + either complete or be abandoned. The server may either wait for the + uncompleted operations to complete, or abandon them. The server then + proceeds to authenticate the client in either a single-step or + multi-step Bind process. Each step requires the server to return a + BindResponse to indicate the status of authentication. + + After sending a BindRequest, clients MUST NOT send further LDAP PDUs + until receiving the BindResponse. Similarly, servers SHOULD NOT + process or respond to requests received while processing a + BindRequest. + + If the client did not bind before sending a request and receives an + operationsError to that request, it may then send a BindRequest. If + this also fails or the client chooses not to bind on the existing + LDAP session, it may terminate the LDAP session, re-establish it, and + begin again by first sending a BindRequest. This will aid in + interoperating with servers implementing other versions of LDAP. + + Clients may send multiple Bind requests to change the authentication + and/or security associations or to complete a multi-stage Bind + process. Authentication from earlier binds is subsequently ignored. + + For some SASL authentication mechanisms, it may be necessary for the + client to invoke the BindRequest multiple times ([RFC4513], Section + 5.2). Clients MUST NOT invoke operations between two Bind requests + made as part of a multi-stage Bind. + + A client may abort a SASL bind negotiation by sending a BindRequest + with a different value in the mechanism field of SaslCredentials, or + an AuthenticationChoice other than sasl. + + + + + + + + +Sermersheim Standards Track [Page 17] + +RFC 4511 LDAPv3 June 2006 + + + If the client sends a BindRequest with the sasl mechanism field as an + empty string, the server MUST return a BindResponse with the + resultCode set to authMethodNotSupported. This will allow the client + to abort a negotiation if it wishes to try again with the same SASL + mechanism. + +4.2.2. Bind Response + + The Bind response is defined as follows. + + BindResponse ::= [APPLICATION 1] SEQUENCE { + COMPONENTS OF LDAPResult, + serverSaslCreds [7] OCTET STRING OPTIONAL } + + BindResponse consists simply of an indication from the server of the + status of the client's request for authentication. + + A successful Bind operation is indicated by a BindResponse with a + resultCode set to success. Otherwise, an appropriate result code is + set in the BindResponse. For BindResponse, the protocolError result + code may be used to indicate that the version number supplied by the + client is unsupported. + + If the client receives a BindResponse where the resultCode is set to + protocolError, it is to assume that the server does not support this + version of LDAP. While the client may be able proceed with another + version of this protocol (which may or may not require closing and + re-establishing the transport connection), how to proceed with + another version of this protocol is beyond the scope of this + document. Clients that are unable or unwilling to proceed SHOULD + terminate the LDAP session. + + The serverSaslCreds field is used as part of a SASL-defined bind + mechanism to allow the client to authenticate the server to which it + is communicating, or to perform "challenge-response" authentication. + If the client bound with the simple choice, or the SASL mechanism + does not require the server to return information to the client, then + this field SHALL NOT be included in the BindResponse. + +4.3. Unbind Operation + + The function of the Unbind operation is to terminate an LDAP session. + The Unbind operation is not the antithesis of the Bind operation as + the name implies. The naming of these operations are historical. + The Unbind operation should be thought of as the "quit" operation. + + + + + + +Sermersheim Standards Track [Page 18] + +RFC 4511 LDAPv3 June 2006 + + + The Unbind operation is defined as follows: + + UnbindRequest ::= [APPLICATION 2] NULL + + The client, upon transmission of the UnbindRequest, and the server, + upon receipt of the UnbindRequest, are to gracefully terminate the + LDAP session as described in Section 5.3. Uncompleted operations are + handled as specified in Section 3.1. + +4.4. Unsolicited Notification + + An unsolicited notification is an LDAPMessage sent from the server to + the client that is not in response to any LDAPMessage received by the + server. It is used to signal an extraordinary condition in the + server or in the LDAP session between the client and the server. The + notification is of an advisory nature, and the server will not expect + any response to be returned from the client. + + The unsolicited notification is structured as an LDAPMessage in which + the messageID is zero and protocolOp is set to the extendedResp + choice using the ExtendedResponse type (See Section 4.12). The + responseName field of the ExtendedResponse always contains an LDAPOID + that is unique for this notification. + + One unsolicited notification (Notice of Disconnection) is defined in + this document. The specification of an unsolicited notification + consists of: + + - the OBJECT IDENTIFIER assigned to the notification (to be specified + in the responseName, + + - the format of the contents of the responseValue (if any), + + - the circumstances which will cause the notification to be sent, and + + - the semantics of the message. + +4.4.1. Notice of Disconnection + + This notification may be used by the server to advise the client that + the server is about to terminate the LDAP session on its own + initiative. This notification is intended to assist clients in + distinguishing between an exceptional server condition and a + transient network failure. Note that this notification is not a + response to an Unbind requested by the client. Uncompleted + operations are handled as specified in Section 3.1. + + + + + +Sermersheim Standards Track [Page 19] + +RFC 4511 LDAPv3 June 2006 + + + The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field + is absent, and the resultCode is used to indicate the reason for the + disconnection. When the strongerAuthRequired resultCode is returned + with this message, it indicates that the server has detected that an + established security association between the client and server has + unexpectedly failed or been compromised. + + Upon transmission of the Notice of Disconnection, the server + gracefully terminates the LDAP session as described in Section 5.3. + +4.5. Search Operation + + The Search operation is used to request a server to return, subject + to access controls and other restrictions, a set of entries matching + a complex search criterion. This can be used to read attributes from + a single entry, from entries immediately subordinate to a particular + entry, or from a whole subtree of entries. + +4.5.1. Search Request + + The Search request is defined as follows: + + SearchRequest ::= [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + singleLevel (1), + wholeSubtree (2), + ... }, + derefAliases ENUMERATED { + neverDerefAliases (0), + derefInSearching (1), + derefFindingBaseObj (2), + derefAlways (3) }, + sizeLimit INTEGER (0 .. maxInt), + timeLimit INTEGER (0 .. maxInt), + typesOnly BOOLEAN, + filter Filter, + attributes AttributeSelection } + + AttributeSelection ::= SEQUENCE OF selector LDAPString + -- The LDAPString is constrained to + -- <attributeSelector> in Section 4.5.1.8 + + Filter ::= CHOICE { + and [0] SET SIZE (1..MAX) OF filter Filter, + or [1] SET SIZE (1..MAX) OF filter Filter, + not [2] Filter, + + + +Sermersheim Standards Track [Page 20] + +RFC 4511 LDAPv3 June 2006 + + + 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, + substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { + initial [0] AssertionValue, -- can occur at most once + any [1] AssertionValue, + final [2] AssertionValue } -- can occur at most once + } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + Note that an X.500 "list"-like operation can be emulated by the + client requesting a singleLevel Search operation with a filter + checking for the presence of the 'objectClass' attribute, and that an + X.500 "read"-like operation can be emulated by a baseObject Search + operation with the same filter. A server that provides a gateway to + X.500 is not required to use the Read or List operations, although it + may choose to do so, and if it does, it must provide the same + semantics as the X.500 Search operation. + +4.5.1.1. SearchRequest.baseObject + + The name of the base object entry (or possibly the root) relative to + which the Search is to be performed. + +4.5.1.2. SearchRequest.scope + + Specifies the scope of the Search to be performed. The semantics (as + described in [X.511]) of the defined values of this field are: + + baseObject: The scope is constrained to the entry named by + baseObject. + + singleLevel: The scope is constrained to the immediate + subordinates of the entry named by baseObject. + + + + +Sermersheim Standards Track [Page 21] + +RFC 4511 LDAPv3 June 2006 + + + wholeSubtree: The scope is constrained to the entry named by + baseObject and to all its subordinates. + +4.5.1.3. SearchRequest.derefAliases + + An indicator as to whether or not alias entries (as defined in + [RFC4512]) are to be dereferenced during stages of the Search + operation. + + The act of dereferencing an alias includes recursively dereferencing + aliases that refer to aliases. + + Servers MUST detect looping while dereferencing aliases in order to + prevent denial-of-service attacks of this nature. + + The semantics of the defined values of this field are: + + neverDerefAliases: Do not dereference aliases in searching or in + locating the base object of the Search. + + derefInSearching: While searching subordinates of the base object, + dereference any alias within the search scope. Dereferenced + objects become the vertices of further search scopes where the + Search operation is also applied. If the search scope is + wholeSubtree, the Search continues in the subtree(s) of any + dereferenced object. If the search scope is singleLevel, the + search is applied to any dereferenced objects and is not applied + to their subordinates. Servers SHOULD eliminate duplicate entries + that arise due to alias dereferencing while searching. + + derefFindingBaseObj: Dereference aliases in locating the base + object of the Search, but not when searching subordinates of the + base object. + + derefAlways: Dereference aliases both in searching and in locating + the base object of the Search. + +4.5.1.4. SearchRequest.sizeLimit + + A size limit that restricts the maximum number of entries to be + returned as a result of the Search. A value of zero in this field + indicates that no client-requested size limit restrictions are in + effect for the Search. Servers may also enforce a maximum number of + entries to return. + + + + + + + +Sermersheim Standards Track [Page 22] + +RFC 4511 LDAPv3 June 2006 + + +4.5.1.5. SearchRequest.timeLimit + + A time limit that restricts the maximum time (in seconds) allowed for + a Search. A value of zero in this field indicates that no client- + requested time limit restrictions are in effect for the Search. + Servers may also enforce a maximum time limit for the Search. + +4.5.1.6. SearchRequest.typesOnly + + An indicator as to whether Search results are to contain both + attribute descriptions and values, or just attribute descriptions. + Setting this field to TRUE causes only attribute descriptions (and + not values) to be returned. Setting this field to FALSE causes both + attribute descriptions and values to be returned. + +4.5.1.7. SearchRequest.filter + + A filter that defines the conditions that must be fulfilled in order + for the Search to match a given entry. + + The 'and', 'or', and 'not' choices can be used to form combinations + of filters. At least one filter element MUST be present in an 'and' + or 'or' choice. The others match against individual attribute values + of entries in the scope of the Search. (Implementor's note: the + 'not' filter is an example of a tagged choice in an implicitly-tagged + module. In BER this is treated as if the tag were explicit.) + + A server MUST evaluate filters according to the three-valued logic of + [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to + "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for + a particular entry, then the attributes of that entry are returned as + part of the Search result (subject to any applicable access control + restrictions). If the filter evaluates to FALSE or Undefined, then + the entry is ignored for the Search. + + A filter of the "and" choice is TRUE if all the filters in the SET OF + evaluate to TRUE, FALSE if at least one filter is FALSE, and + Undefined otherwise. A filter of the "or" choice is FALSE if all the + filters in the SET OF evaluate to FALSE, TRUE if at least one filter + is TRUE, and Undefined otherwise. A filter of the 'not' choice is + TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and + Undefined if it is Undefined. + + A filter item evaluates to Undefined when the server would not be + able to determine whether the assertion value matches an entry. + Examples include: + + + + + +Sermersheim Standards Track [Page 23] + +RFC 4511 LDAPv3 June 2006 + + + - An attribute description in an equalityMatch, substrings, + greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter + is not recognized by the server. + + - The attribute type does not define the appropriate matching rule. + + - A MatchingRuleId in the extensibleMatch is not recognized by the + server or is not valid for the attribute type. + + - The type of filtering requested is not implemented. + + - The assertion value is invalid. + + For example, if a server did not recognize the attribute type + shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), + and (shoeSize<=12) would each evaluate to Undefined. + + Servers MUST NOT return errors if attribute descriptions or matching + rule ids are not recognized, assertion values are invalid, or the + assertion syntax is not supported. More details of filter processing + are given in Clause 7.8 of [X.511]. + +4.5.1.7.1. SearchRequest.filter.equalityMatch + + The matching rule for an equalityMatch filter is defined by the + EQUALITY matching rule for the attribute type or subtype. The filter + is TRUE when the EQUALITY rule returns TRUE as applied to the + attribute or subtype and the asserted value. + +4.5.1.7.2. SearchRequest.filter.substrings + + There SHALL be at most one 'initial' and at most one 'final' in the + 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL + be the first element of 'substrings'. If 'final' is present, it + SHALL be the last element of 'substrings'. + + The matching rule for an AssertionValue in a substrings filter item + is defined by the SUBSTR matching rule for the attribute type or + subtype. The filter is TRUE when the SUBSTR rule returns TRUE as + applied to the attribute or subtype and the asserted value. + + Note that the AssertionValue in a substrings filter item conforms to + the assertion syntax of the EQUALITY matching rule for the attribute + type rather than to the assertion syntax of the SUBSTR matching rule + for the attribute type. Conceptually, the entire SubstringFilter is + converted into an assertion value of the substrings matching rule + prior to applying the rule. + + + + +Sermersheim Standards Track [Page 24] + +RFC 4511 LDAPv3 June 2006 + + +4.5.1.7.3. SearchRequest.filter.greaterOrEqual + + The matching rule for a greaterOrEqual filter is defined by the + ORDERING matching rule for the attribute type or subtype. The filter + is TRUE when the ORDERING rule returns FALSE as applied to the + attribute or subtype and the asserted value. + +4.5.1.7.4. SearchRequest.filter.lessOrEqual + + The matching rules for a lessOrEqual filter are defined by the + ORDERING and EQUALITY matching rules for the attribute type or + subtype. The filter is TRUE when either the ORDERING or EQUALITY + rule returns TRUE as applied to the attribute or subtype and the + asserted value. + +4.5.1.7.5. SearchRequest.filter.present + + A present filter is TRUE when there is an attribute or subtype of the + specified attribute description present in an entry, FALSE when no + attribute or subtype of the specified attribute description is + present in an entry, and Undefined otherwise. + +4.5.1.7.6. SearchRequest.filter.approxMatch + + An approxMatch filter is TRUE when there is a value of the attribute + type or subtype for which some locally-defined approximate matching + algorithm (e.g., spelling variations, phonetic match, etc.) returns + TRUE. If a value matches for equality, it also satisfies an + approximate match. If approximate matching is not supported for the + attribute, this filter item should be treated as an equalityMatch. + +4.5.1.7.7. SearchRequest.filter.extensibleMatch + + The fields of the extensibleMatch filter item are evaluated as + follows: + + - If the matchingRule field is absent, the type field MUST be + present, and an equality match is performed for that type. + + - If the type field is absent and the matchingRule is present, the + matchValue is compared against all attributes in an entry that + support that matchingRule. + + - If the type field is present and the matchingRule is present, the + matchValue is compared against the specified attribute type and its + subtypes. + + + + + +Sermersheim Standards Track [Page 25] + +RFC 4511 LDAPv3 June 2006 + + + - If the dnAttributes field is set to TRUE, the match is additionally + applied against all the AttributeValueAssertions in an entry's + distinguished name, and it evaluates to TRUE if there is at least + one attribute or subtype in the distinguished name for which the + filter item evaluates to TRUE. The dnAttributes field is present + to alleviate the need for multiple versions of generic matching + rules (such as word matching), where one applies to entries and + another applies to entries and DN attributes as well. + + The matchingRule used for evaluation determines the syntax for the + assertion value. Once the matchingRule and attribute(s) have been + determined, the filter item evaluates to TRUE if it matches at least + one attribute type or subtype in the entry, FALSE if it does not + match any attribute type or subtype in the entry, and Undefined if + the matchingRule is not recognized, the matchingRule is unsuitable + for use with the specified type, or the assertionValue is invalid. + +4.5.1.8. SearchRequest.attributes + + A selection list of the attributes to be returned from each entry + that matches the search filter. Attributes that are subtypes of + listed attributes are implicitly included. LDAPString values of this + field are constrained to the following Augmented Backus-Naur Form + (ABNF) [RFC4234]: + + attributeSelector = attributedescription / selectorspecial + + selectorspecial = noattrs / alluserattrs + + noattrs = %x31.2E.31 ; "1.1" + + alluserattrs = %x2A ; asterisk ("*") + + The <attributedescription> production is defined in Section 2.5 of + [RFC4512]. + + There are three special cases that may appear in the attributes + selection list: + + 1. An empty list with no attributes requests the return of all + user attributes. + + 2. A list containing "*" (with zero or more attribute + descriptions) requests the return of all user attributes in + addition to other listed (operational) attributes. + + + + + + +Sermersheim Standards Track [Page 26] + +RFC 4511 LDAPv3 June 2006 + + + 3. A list containing only the OID "1.1" indicates that no + attributes are to be returned. If "1.1" is provided with other + attributeSelector values, the "1.1" attributeSelector is + ignored. This OID was chosen because it does not (and can not) + correspond to any attribute in use. + + Client implementors should note that even if all user attributes are + requested, some attributes and/or attribute values of the entry may + not be included in Search results due to access controls or other + restrictions. Furthermore, servers will not return operational + attributes, such as objectClasses or attributeTypes, unless they are + listed by name. Operational attributes are described in [RFC4512]. + + Attributes are returned at most once in an entry. If an attribute + description is named more than once in the list, the subsequent names + are ignored. If an attribute description in the list is not + recognized, it is ignored by the server. + +4.5.2. Search Result + + The results of the Search operation are returned as zero or more + SearchResultEntry and/or SearchResultReference messages, followed by + a single SearchResultDone message. + + SearchResultEntry ::= [APPLICATION 4] SEQUENCE { + objectName LDAPDN, + attributes PartialAttributeList } + + PartialAttributeList ::= SEQUENCE OF + partialAttribute PartialAttribute + + SearchResultReference ::= [APPLICATION 19] SEQUENCE + SIZE (1..MAX) OF uri URI + + SearchResultDone ::= [APPLICATION 5] LDAPResult + + Each SearchResultEntry represents an entry found during the Search. + Each SearchResultReference represents an area not yet explored during + the Search. The SearchResultEntry and SearchResultReference messages + may come in any order. Following all the SearchResultReference and + SearchResultEntry responses, the server returns a SearchResultDone + response, which contains an indication of success or details any + errors that have occurred. + + Each entry returned in a SearchResultEntry will contain all + appropriate attributes as specified in the attributes field of the + Search Request, subject to access control and other administrative + policy. Note that the PartialAttributeList may hold zero elements. + + + +Sermersheim Standards Track [Page 27] + +RFC 4511 LDAPv3 June 2006 + + + This may happen when none of the attributes of an entry were + requested or could be returned. Note also that the partialAttribute + vals set may hold zero elements. This may happen when typesOnly is + requested, access controls prevent the return of values, or other + reasons. + + Some attributes may be constructed by the server and appear in a + SearchResultEntry attribute list, although they are not stored + attributes of an entry. Clients SHOULD NOT assume that all + attributes can be modified, even if this is permitted by access + control. + + If the server's schema defines short names [RFC4512] for an attribute + type, then the server SHOULD use one of those names in attribute + descriptions for that attribute type (in preference to using the + <numericoid> [RFC4512] format of the attribute type's object + identifier). The server SHOULD NOT use the short name if that name + is known by the server to be ambiguous, or if it is otherwise likely + to cause interoperability problems. + +4.5.3. Continuation References in the Search Result + + If the server was able to locate the entry referred to by the + baseObject but was unable or unwilling to search one or more non- + local entries, the server may return one or more + SearchResultReference messages, each containing a reference to + another set of servers for continuing the operation. A server MUST + NOT return any SearchResultReference messages if it has not located + the baseObject and thus has not searched any entries. In this case, + it would return a SearchResultDone containing either a referral or + noSuchObject result code (depending on the server's knowledge of the + entry named in the baseObject). + + If a server holds a copy or partial copy of the subordinate naming + context (Section 5 of [RFC4512]), it may use the search filter to + determine whether or not to return a SearchResultReference response. + Otherwise, SearchResultReference responses are always returned when + in scope. + + The SearchResultReference is of the same data type as the Referral. + + If the client wishes to progress the Search, it issues a new Search + operation for each SearchResultReference that is returned. If + multiple URIs are present, the client assumes that any supported URI + may be used to progress the operation. + + + + + + +Sermersheim Standards Track [Page 28] + +RFC 4511 LDAPv3 June 2006 + + + Clients that follow search continuation references MUST ensure that + they do not loop between servers. They MUST NOT repeatedly contact + the same server for the same request with the same parameters. Some + clients use a counter that is incremented each time search result + reference handling occurs for an operation, and these kinds of + clients MUST be able to handle at least ten nested referrals while + progressing the operation. + + Note that the Abandon operation described in Section 4.11 applies + only to a particular operation sent at the LDAP message layer between + a client and server. The client must individually abandon subsequent + Search operations it wishes to. + + A URI for a server implementing LDAP and accessible via TCP/IP (v4 or + v6) [RFC793][RFC791] is written as an LDAP URL according to + [RFC4516]. + + SearchResultReference values that are LDAP URLs follow these rules: + + - The <dn> part of the LDAP URL MUST be present, with the new target + object name. The client uses this name when following the + reference. + + - Some servers (e.g., participating in distributed indexing) may + provide a different filter in the LDAP URL. + + - If the <filter> part of the LDAP URL is present, the client uses + this filter in its next request to progress this Search, and if it + is not present the client uses the same filter as it used for that + Search. + + - If the originating search scope was singleLevel, the <scope> part + of the LDAP URL will be "base". + + - It is RECOMMENDED that the <scope> part be present to avoid + ambiguity. In the absence of a <scope> part, the scope of the + original Search request is assumed. + + - Other aspects of the new Search request may be the same as or + different from the Search request that generated the + SearchResultReference. + + - The name of an unexplored subtree in a SearchResultReference need + not be subordinate to the base object. + + Other kinds of URIs may be returned. The syntax and semantics of + such URIs is left to future specifications. Clients may ignore URIs + that they do not support. + + + +Sermersheim Standards Track [Page 29] + +RFC 4511 LDAPv3 June 2006 + + + UTF-8-encoded characters appearing in the string representation of a + DN, search filter, or other fields of the referral value may not be + legal for URIs (e.g., spaces) and MUST be escaped using the % method + in [RFC3986]. + +4.5.3.1. Examples + + For example, suppose the contacted server (hosta) holds the entry + <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It + knows that both LDAP servers (hostb) and (hostc) hold + <OU=People,DC=Example,DC=NET> (one is the master and the other server + a shadow), and that LDAP-capable server (hostd) holds the subtree + <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of + <DC=Example,DC=NET> is requested to the contacted server, it may + return the following: + + SearchResultEntry for DC=Example,DC=NET + SearchResultEntry for CN=Manager,DC=Example,DC=NET + SearchResultReference { + ldap://hostb/OU=People,DC=Example,DC=NET??sub + ldap://hostc/OU=People,DC=Example,DC=NET??sub } + SearchResultReference { + ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } + SearchResultDone (success) + + Client implementors should note that when following a + SearchResultReference, additional SearchResultReference may be + generated. Continuing the example, if the client contacted the + server (hostb) and issued the Search request for the subtree + <OU=People,DC=Example,DC=NET>, the server might respond as follows: + + SearchResultEntry for OU=People,DC=Example,DC=NET + SearchResultReference { + ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } + SearchResultReference { + ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } + SearchResultDone (success) + + Similarly, if a singleLevel Search of <DC=Example,DC=NET> is + requested to the contacted server, it may return the following: + + SearchResultEntry for CN=Manager,DC=Example,DC=NET + SearchResultReference { + ldap://hostb/OU=People,DC=Example,DC=NET??base + ldap://hostc/OU=People,DC=Example,DC=NET??base } + SearchResultReference { + ldap://hostd/OU=Roles,DC=Example,DC=NET??base } + SearchResultDone (success) + + + +Sermersheim Standards Track [Page 30] + +RFC 4511 LDAPv3 June 2006 + + + If the contacted server does not hold the base object for the Search, + but has knowledge of its possible location, then it may return a + referral to the client. In this case, if the client requests a + subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a + SearchResultDone containing a referral. + + SearchResultDone (referral) { + ldap://hostg/DC=Example,DC=ORG??sub } + +4.6. Modify Operation + + The Modify operation allows a client to request that a modification + of an entry be performed on its behalf by a server. The Modify + Request is defined as follows: + + ModifyRequest ::= [APPLICATION 6] SEQUENCE { + object LDAPDN, + changes SEQUENCE OF change SEQUENCE { + operation ENUMERATED { + add (0), + delete (1), + replace (2), + ... }, + modification PartialAttribute } } + + Fields of the Modify Request are: + + - object: The value of this field contains the name of the entry to + be modified. The server SHALL NOT perform any alias dereferencing + in determining the object to be modified. + + - changes: A list of modifications to be performed on the entry. The + entire list of modifications MUST be performed in the order they + are listed as a single atomic operation. While individual + modifications may violate certain aspects of the directory schema + (such as the object class definition and Directory Information Tree + (DIT) content rule), the resulting entry after the entire list of + modifications is performed MUST conform to the requirements of the + directory model and controlling schema [RFC4512]. + + - operation: Used to specify the type of modification being + performed. Each operation type acts on the following + modification. The values of this field have the following + semantics, respectively: + + add: add values listed to the modification attribute, + creating the attribute if necessary. + + + + +Sermersheim Standards Track [Page 31] + +RFC 4511 LDAPv3 June 2006 + + + delete: delete values listed from the modification attribute. + If no values are listed, or if all current values of the + attribute are listed, the entire attribute is removed. + + replace: replace all existing values of the modification + attribute with the new values listed, creating the attribute + if it did not already exist. A replace with no value will + delete the entire attribute if it exists, and it is ignored + if the attribute does not exist. + + - modification: A PartialAttribute (which may have an empty SET + of vals) used to hold the attribute type or attribute type and + values being modified. + + Upon receipt of a Modify Request, the server attempts to perform the + necessary modifications to the DIT and returns the result in a Modify + Response, defined as follows: + + ModifyResponse ::= [APPLICATION 7] LDAPResult + + The server will return to the client a single Modify Response + indicating either the successful completion of the DIT modification, + or the reason that the modification failed. Due to the requirement + for atomicity in applying the list of modifications in the Modify + Request, the client may expect that no modifications of the DIT have + been performed if the Modify Response received indicates any sort of + error, and that all requested modifications have been performed if + the Modify Response indicates successful completion of the Modify + operation. Whether or not the modification was applied cannot be + determined by the client if the Modify Response was not received + (e.g., the LDAP session was terminated or the Modify operation was + abandoned). + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. The Modify operation cannot + be used to remove from an entry any of its distinguished values, + i.e., those values which form the entry's relative distinguished + name. An attempt to do so will result in the server returning the + notAllowedOnRDN result code. The Modify DN operation described in + Section 4.9 is used to rename an entry. + + For attribute types that specify no equality matching, the rules in + Section 2.5.1 of [RFC4512] are followed. + + Note that due to the simplifications made in LDAP, there is not a + direct mapping of the changes in an LDAP ModifyRequest onto the + changes of a DAP ModifyEntry operation, and different implementations + + + + +Sermersheim Standards Track [Page 32] + +RFC 4511 LDAPv3 June 2006 + + + of LDAP-DAP gateways may use different means of representing the + change. If successful, the final effect of the operations on the + entry MUST be identical. + +4.7. Add Operation + + The Add operation allows a client to request the addition of an entry + into the Directory. The Add Request is defined as follows: + + AddRequest ::= [APPLICATION 8] SEQUENCE { + entry LDAPDN, + attributes AttributeList } + + AttributeList ::= SEQUENCE OF attribute Attribute + + Fields of the Add Request are: + + - entry: the name of the entry to be added. The server SHALL NOT + dereference any aliases in locating the entry to be added. + + - attributes: the list of attributes that, along with those from the + RDN, make up the content of the entry being added. Clients MAY or + MAY NOT include the RDN attribute(s) in this list. Clients MUST + NOT supply NO-USER-MODIFICATION attributes such as the + createTimestamp or creatorsName attributes, since the server + maintains these automatically. + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. For attribute types that + specify no equality matching, the rules in Section 2.5.1 of [RFC4512] + are followed (this applies to the naming attribute in addition to any + multi-valued attributes being added). + + The entry named in the entry field of the AddRequest MUST NOT exist + for the AddRequest to succeed. The immediate superior (parent) of an + object or alias entry to be added MUST exist. For example, if the + client attempted to add <CN=JS,DC=Example,DC=NET>, the + <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did + exist, then the server would return the noSuchObject result code with + the matchedDN field containing <DC=NET>. + + Upon receipt of an Add Request, a server will attempt to add the + requested entry. The result of the Add attempt will be returned to + the client in the Add Response, defined as follows: + + AddResponse ::= [APPLICATION 9] LDAPResult + + + + + +Sermersheim Standards Track [Page 33] + +RFC 4511 LDAPv3 June 2006 + + + A response of success indicates that the new entry has been added to + the Directory. + +4.8. Delete Operation + + The Delete operation allows a client to request the removal of an + entry from the Directory. The Delete Request is defined as follows: + + DelRequest ::= [APPLICATION 10] LDAPDN + + The Delete Request consists of the name of the entry to be deleted. + The server SHALL NOT dereference aliases while resolving the name of + the target entry to be removed. + + Only leaf entries (those with no subordinate entries) can be deleted + with this operation. + + Upon receipt of a Delete Request, a server will attempt to perform + the entry removal requested and return the result in the Delete + Response defined as follows: + + DelResponse ::= [APPLICATION 11] LDAPResult + +4.9. Modify DN Operation + + The Modify DN operation allows a client to change the Relative + Distinguished Name (RDN) of an entry in the Directory and/or to move + a subtree of entries to a new location in the Directory. The Modify + DN Request is defined as follows: + + ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { + entry LDAPDN, + newrdn RelativeLDAPDN, + deleteoldrdn BOOLEAN, + newSuperior [0] LDAPDN OPTIONAL } + + Fields of the Modify DN Request are: + + - entry: the name of the entry to be changed. This entry may or may + not have subordinate entries. + + - newrdn: the new RDN of the entry. The value of the old RDN is + supplied when moving the entry to a new superior without changing + its RDN. Attribute values of the new RDN not matching any + attribute value of the entry are added to the entry, and an + appropriate error is returned if this fails. + + + + + +Sermersheim Standards Track [Page 34] + +RFC 4511 LDAPv3 June 2006 + + + - deleteoldrdn: a boolean field that controls whether the old RDN + attribute values are to be retained as attributes of the entry or + deleted from the entry. + + - newSuperior: if present, this is the name of an existing object + entry that becomes the immediate superior (parent) of the + existing entry. + + The server SHALL NOT dereference any aliases in locating the objects + named in entry or newSuperior. + + Upon receipt of a ModifyDNRequest, a server will attempt to perform + the name change and return the result in the Modify DN Response, + defined as follows: + + ModifyDNResponse ::= [APPLICATION 13] LDAPResult + + For example, if the entry named in the entry field was <cn=John + Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the + newSuperior field was absent, then this operation would attempt to + rename the entry as <cn=John Cougar Smith,c=US>. If there was + already an entry with that name, the operation would fail with the + entryAlreadyExists result code. + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. For attribute types that + specify no equality matching, the rules in Section 2.5.1 of [RFC4512] + are followed (this pertains to newrdn and deleteoldrdn). + + The object named in newSuperior MUST exist. For example, if the + client attempted to add <CN=JS,DC=Example,DC=NET>, the + <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did + exist, then the server would return the noSuchObject result code with + the matchedDN field containing <DC=NET>. + + If the deleteoldrdn field is TRUE, the attribute values forming the + old RDN (but not the new RDN) are deleted from the entry. If the + deleteoldrdn field is FALSE, the attribute values forming the old RDN + will be retained as non-distinguished attribute values of the entry. + + Note that X.500 restricts the ModifyDN operation to affect only + entries that are contained within a single server. If the LDAP + server is mapped onto DAP, then this restriction will apply, and the + affectsMultipleDSAs result code will be returned if this error + occurred. In general, clients MUST NOT expect to be able to perform + arbitrary movements of entries and subtrees between servers or + between naming contexts. + + + + +Sermersheim Standards Track [Page 35] + +RFC 4511 LDAPv3 June 2006 + + +4.10. Compare Operation + + The Compare operation allows a client to compare an assertion value + with the values of a particular attribute in a particular entry in + the Directory. The Compare Request is defined as follows: + + CompareRequest ::= [APPLICATION 14] SEQUENCE { + entry LDAPDN, + ava AttributeValueAssertion } + + Fields of the Compare Request are: + + - entry: the name of the entry to be compared. The server SHALL NOT + dereference any aliases in locating the entry to be compared. + + - ava: holds the attribute value assertion to be compared. + + Upon receipt of a Compare Request, a server will attempt to perform + the requested comparison and return the result in the Compare + Response, defined as follows: + + CompareResponse ::= [APPLICATION 15] LDAPResult + + The resultCode is set to compareTrue, compareFalse, or an appropriate + error. compareTrue indicates that the assertion value in the ava + field matches a value of the attribute or subtype according to the + attribute's EQUALITY matching rule. compareFalse indicates that the + assertion value in the ava field and the values of the attribute or + subtype did not match. Other result codes indicate either that the + result of the comparison was Undefined (Section 4.5.1.7), or that + some error occurred. + + Note that some directory systems may establish access controls that + permit the values of certain attributes (such as userPassword) to be + compared but not interrogated by other means. + +4.11. Abandon Operation + + The function of the Abandon operation is to allow a client to request + that the server abandon an uncompleted operation. The Abandon + Request is defined as follows: + + AbandonRequest ::= [APPLICATION 16] MessageID + + The MessageID is that of an operation that was requested earlier at + this LDAP message layer. The Abandon request itself has its own + MessageID. This is distinct from the MessageID of the earlier + operation being abandoned. + + + +Sermersheim Standards Track [Page 36] + +RFC 4511 LDAPv3 June 2006 + + + There is no response defined in the Abandon operation. Upon receipt + of an AbandonRequest, the server MAY abandon the operation identified + by the MessageID. Since the client cannot tell the difference + between a successfully abandoned operation and an uncompleted + operation, the application of the Abandon operation is limited to + uses where the client does not require an indication of its outcome. + + Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. + + In the event that a server receives an Abandon Request on a Search + operation in the midst of transmitting responses to the Search, that + server MUST cease transmitting entry responses to the abandoned + request immediately, and it MUST NOT send the SearchResultDone. Of + course, the server MUST ensure that only properly encoded LDAPMessage + PDUs are transmitted. + + The ability to abandon other (particularly update) operations is at + the discretion of the server. + + Clients should not send Abandon requests for the same operation + multiple times, and they MUST also be prepared to receive results + from operations they have abandoned (since these might have been in + transit when the Abandon was requested or might not be able to be + abandoned). + + Servers MUST discard Abandon requests for messageIDs they do not + recognize, for operations that cannot be abandoned, and for + operations that have already been abandoned. + +4.12. Extended Operation + + The Extended operation allows additional operations to be defined for + services not already available in the protocol; for example, to Add + operations to install transport layer security (see Section 4.14). + + The Extended operation allows clients to make requests and receive + responses with predefined syntaxes and semantics. These may be + defined in RFCs or be private to particular implementations. + + Each Extended operation consists of an Extended request and an + Extended response. + + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } + + + + + + +Sermersheim Standards Track [Page 37] + +RFC 4511 LDAPv3 June 2006 + + + The requestName is a dotted-decimal representation of the unique + OBJECT IDENTIFIER corresponding to the request. The requestValue is + information in a form defined by that request, encapsulated inside an + OCTET STRING. + + The server will respond to this with an LDAPMessage containing an + ExtendedResponse. + + ExtendedResponse ::= [APPLICATION 24] SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] LDAPOID OPTIONAL, + responseValue [11] OCTET STRING OPTIONAL } + + The responseName field, when present, contains an LDAPOID that is + unique for this extended operation or response. This field is + optional (even when the extension specification defines an LDAPOID + for use in this field). The field will be absent whenever the server + is unable or unwilling to determine the appropriate LDAPOID to + return, for instance, when the requestName cannot be parsed or its + value is not recognized. + + Where the requestName is not recognized, the server returns + protocolError. (The server may return protocolError in other cases.) + + The requestValue and responseValue fields contain information + associated with the operation. The format of these fields is defined + by the specification of the Extended operation. Implementations MUST + be prepared to handle arbitrary contents of these fields, including + zero bytes. Values that are defined in terms of ASN.1 and BER- + encoded according to Section 5.1 also follow the extensibility rules + in Section 4. + + Servers list the requestName of Extended Requests they recognize in + the 'supportedExtension' attribute in the root DSE (Section 5.1 of + [RFC4512]). + + Extended operations may be specified in other documents. The + specification of an Extended operation consists of: + + - the OBJECT IDENTIFIER assigned to the requestName, + + - the OBJECT IDENTIFIER (if any) assigned to the responseName (note + that the same OBJECT IDENTIFIER may be used for both the + requestName and responseName), + + + + + + + +Sermersheim Standards Track [Page 38] + +RFC 4511 LDAPv3 June 2006 + + + - the format of the contents of the requestValue and responseValue + (if any), and + + - the semantics of the operation. + +4.13. IntermediateResponse Message + + While the Search operation provides a mechanism to return multiple + response messages for a single Search request, other operations, by + nature, do not provide for multiple response messages. + + The IntermediateResponse message provides a general mechanism for + defining single-request/multiple-response operations in LDAP. This + message is intended to be used in conjunction with the Extended + operation to define new single-request/multiple-response operations + or in conjunction with a control when extending existing LDAP + operations in a way that requires them to return Intermediate + response information. + + It is intended that the definitions and descriptions of Extended + operations and controls that make use of the IntermediateResponse + message will define the circumstances when an IntermediateResponse + message can be sent by a server and the associated meaning of an + IntermediateResponse message sent in a particular circumstance. + + IntermediateResponse ::= [APPLICATION 25] SEQUENCE { + responseName [0] LDAPOID OPTIONAL, + responseValue [1] OCTET STRING OPTIONAL } + + IntermediateResponse messages SHALL NOT be returned to the client + unless the client issues a request that specifically solicits their + return. This document defines two forms of solicitation: Extended + operation and request control. IntermediateResponse messages are + specified in documents describing the manner in which they are + solicited (i.e., in the Extended operation or request control + specification that uses them). These specifications include: + + - the OBJECT IDENTIFIER (if any) assigned to the responseName, + + - the format of the contents of the responseValue (if any), and + + - the semantics associated with the IntermediateResponse message. + + Extensions that allow the return of multiple types of + IntermediateResponse messages SHALL identify those types using unique + responseName values (note that one of these may specify no value). + + + + + +Sermersheim Standards Track [Page 39] + +RFC 4511 LDAPv3 June 2006 + + + Sections 4.13.1 and 4.13.2 describe additional requirements on the + inclusion of responseName and responseValue in IntermediateResponse + messages. + +4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse + + A single-request/multiple-response operation may be defined using a + single ExtendedRequest message to solicit zero or more + IntermediateResponse messages of one or more kinds, followed by an + ExtendedResponse message. + +4.13.2. Usage with LDAP Request Controls + + A control's semantics may include the return of zero or more + IntermediateResponse messages prior to returning the final result + code for the operation. One or more kinds of IntermediateResponse + messages may be sent in response to a request control. + + All IntermediateResponse messages associated with request controls + SHALL include a responseName. This requirement ensures that the + client can correctly identify the source of IntermediateResponse + messages when: + + - two or more controls using IntermediateResponse messages are + included in a request for any LDAP operation or + + - one or more controls using IntermediateResponse messages are + included in a request with an LDAP Extended operation that uses + IntermediateResponse messages. + +4.14. StartTLS Operation + + The Start Transport Layer Security (StartTLS) operation's purpose is + to initiate installation of a TLS layer. The StartTLS operation is + defined using the Extended operation mechanism described in Section + 4.12. + +4.14.1. StartTLS Request + + A client requests TLS establishment by transmitting a StartTLS + request message to the server. The StartTLS request is defined in + terms of an ExtendedRequest. The requestName is + "1.3.6.1.4.1.1466.20037", and the requestValue field is always + absent. + + + + + + + +Sermersheim Standards Track [Page 40] + +RFC 4511 LDAPv3 June 2006 + + + The client MUST NOT send any LDAP PDUs at this LDAP message layer + following this request until it receives a StartTLS Extended response + and, in the case of a successful response, completes TLS + negotiations. + + Detected sequencing problems (particularly those detailed in Section + 3.1.1 of [RFC4513]) result in the resultCode being set to + operationsError. + + If the server does not support TLS (whether by design or by current + configuration), it returns with the resultCode set to protocolError + as described in Section 4.12. + +4.14.2. StartTLS Response + + When a StartTLS request is received, servers supporting the operation + MUST return a StartTLS response message to the requestor. The + responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section + 4.12). The responseValue is always absent. + + If the server is willing and able to negotiate TLS, it returns the + StartTLS response with the resultCode set to success. Upon client + receipt of a successful StartTLS response, protocol peers may + commence with TLS negotiation as discussed in Section 3 of [RFC4513]. + + If the server is otherwise unwilling or unable to perform this + operation, the server is to return an appropriate result code + indicating the nature of the problem. For example, if the TLS + subsystem is not presently available, the server may indicate this by + returning with the resultCode set to unavailable. In cases where a + non-success result code is returned, the LDAP session is left without + a TLS layer. + +4.14.3. Removal of the TLS Layer + + Either the client or server MAY remove the TLS layer and leave the + LDAP message layer intact by sending and receiving a TLS closure + alert. + + The initiating protocol peer sends the TLS closure alert and MUST + wait until it receives a TLS closure alert from the other peer before + sending further LDAP PDUs. + + When a protocol peer receives the initial TLS closure alert, it may + choose to allow the LDAP message layer to remain intact. In this + case, it MUST immediately transmit a TLS closure alert. Following + this, it MAY send and receive LDAP PDUs. + + + + +Sermersheim Standards Track [Page 41] + +RFC 4511 LDAPv3 June 2006 + + + Protocol peers MAY terminate the LDAP session after sending or + receiving a TLS closure alert. + +5. Protocol Encoding, Connection, and Transfer + + This protocol is designed to run over connection-oriented, reliable + transports, where the data stream is divided into octets (8-bit + units), with each octet and each bit being significant. + + One underlying service, LDAP over TCP, is defined in Section 5.2. + This service is generally applicable to applications providing or + consuming X.500-based directory services on the Internet. This + specification was generally written with the TCP mapping in mind. + Specifications detailing other mappings may encounter various + obstacles. + + Implementations of LDAP over TCP MUST implement the mapping as + described in Section 5.2. + + This table illustrates the relationship among the different layers + involved in an exchange between two protocol peers: + + +----------------------+ + | LDAP message layer | + +----------------------+ > LDAP PDUs + +----------------------+ < data + | SASL layer | + +----------------------+ > SASL-protected data + +----------------------+ < data + | TLS layer | + Application +----------------------+ > TLS-protected data + ------------+----------------------+ < data + Transport | transport connection | + +----------------------+ + +5.1. Protocol Encoding + + The protocol elements of LDAP SHALL be encoded for exchange using the + Basic Encoding Rules [BER] of [ASN.1] with the following + restrictions: + + - Only the definite form of length encoding is used. + + - OCTET STRING values are encoded in the primitive form only. + + - If the value of a BOOLEAN type is true, the encoding of the value + octet is set to hex "FF". + + + + +Sermersheim Standards Track [Page 42] + +RFC 4511 LDAPv3 June 2006 + + + - If a value of a type is its default value, it is absent. Only some + BOOLEAN and INTEGER types have default values in this protocol + definition. + + These restrictions are meant to ease the overhead of encoding and + decoding certain elements in BER. + + These restrictions do not apply to ASN.1 types encapsulated inside of + OCTET STRING values, such as attribute values, unless otherwise + stated. + +5.2. Transmission Control Protocol (TCP) + + The encoded LDAPMessage PDUs are mapped directly onto the TCP + [RFC793] bytestream using the BER-based encoding described in Section + 5.1. It is recommended that server implementations running over the + TCP provide a protocol listener on the Internet Assigned Numbers + Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may + instead provide a listener on a different port number. Clients MUST + support contacting servers on any valid TCP port. + +5.3. Termination of the LDAP session + + Termination of the LDAP session is typically initiated by the client + sending an UnbindRequest (Section 4.3), or by the server sending a + Notice of Disconnection (Section 4.4.1). In these cases, each + protocol peer gracefully terminates the LDAP session by ceasing + exchanges at the LDAP message layer, tearing down any SASL layer, + tearing down any TLS layer, and closing the transport connection. + + A protocol peer may determine that the continuation of any + communication would be pernicious, and in this case, it may abruptly + terminate the session by ceasing communication and closing the + transport connection. + + In either case, when the LDAP session is terminated, uncompleted + operations are handled as specified in Section 3.1. + +6. Security Considerations + + This version of the protocol provides facilities for simple + authentication using a cleartext password, as well as any SASL + [RFC4422] mechanism. Installing SASL and/or TLS layers can provide + integrity and other data security services. + + It is also permitted that the server can return its credentials to + the client, if it chooses to do so. + + + + +Sermersheim Standards Track [Page 43] + +RFC 4511 LDAPv3 June 2006 + + + Use of cleartext password is strongly discouraged where the + underlying transport service cannot guarantee confidentiality and may + result in disclosure of the password to unauthorized parties. + + Servers are encouraged to prevent directory modifications by clients + that have authenticated anonymously [RFC4513]. + + Security considerations for authentication methods, SASL mechanisms, + and TLS are described in [RFC4513]. + + Note that SASL authentication exchanges do not provide data + confidentiality or integrity protection for the version or name + fields of the BindRequest or the resultCode, diagnosticMessage, or + referral fields of the BindResponse, nor for any information + contained in controls attached to Bind requests or responses. Thus, + information contained in these fields SHOULD NOT be relied on unless + it is otherwise protected (such as by establishing protections at the + transport layer). + + Implementors should note that 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. For instance, + credentials could expire, authorization identities or access controls + could change, or the underlying security layer(s) could be replaced + or terminated. Implementations should be robust in the handling of + changing security factors. + + In some cases, it may be appropriate to continue the operation even + in light of security factor changes. For instance, it may be + appropriate to continue an Abandon operation regardless of the + change, or to continue an operation when the change upgraded (or + maintained) the security factor. In other cases, it may be + appropriate to fail or alter the processing of the operation. For + instance, if confidential protections were removed, it would be + appropriate either to fail a request to return sensitive data or, + minimally, to exclude the return of sensitive data. + + Implementations that cache attributes and entries obtained via LDAP + MUST ensure that access controls are maintained if that information + is to be provided to multiple clients, since servers may have access + control policies that prevent the return of entries or attributes in + Search results except to particular authenticated clients. For + example, caches could serve result information only to the client + whose request caused it to be in the cache. + + + + + + +Sermersheim Standards Track [Page 44] + +RFC 4511 LDAPv3 June 2006 + + + Servers may return referrals or Search result references that + redirect clients to peer servers. It is possible for a rogue + application to inject such referrals into the data stream in an + attempt to redirect a client to a rogue server. Clients are advised + to be aware of this and possibly reject referrals when + confidentiality measures are not in place. Clients are advised to + reject referrals from the StartTLS operation. + + The matchedDN and diagnosticMessage fields, as well as some + resultCode values (e.g., attributeOrValueExists and + entryAlreadyExists), could disclose the presence or absence of + specific data in the directory that is subject to access and other + administrative controls. Server implementations should restrict + access to protected information equally under both normal and error + conditions. + + Protocol peers MUST be prepared to handle invalid and arbitrary- + length protocol encodings. Invalid protocol encodings include: BER + encoding exceptions, format string and UTF-8 encoding exceptions, + overflow exceptions, integer value exceptions, and binary mode on/off + flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides + excellent examples of these exceptions and test cases used to + discover flaws. + + In the event that a protocol peer senses an attack that in its nature + could cause damage due to further communication at any layer in the + LDAP session, the protocol peer should abruptly terminate the LDAP + session as described in Section 5.3. + +7. Acknowledgements + + This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve + Kille. RFC 2251 was a product of the IETF ASID Working Group. + + It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and + Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group. + + It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. + RFC 3771 was an individual submission to the IETF. + + This document is a product of the IETF LDAPBIS Working Group. + Significant contributors of technical review and content include Kurt + Zeilenga, Steven Legg, and Hallvard Furuseth. + + + + + + + + +Sermersheim Standards Track [Page 45] + +RFC 4511 LDAPv3 June 2006 + + +8. Normative References + + [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- + 1:2002 "Information Technology - Abstract Syntax + Notation One (ASN.1): Specification of basic notation". + + [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, + "Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", 2002. + + [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC + 10646-1 : 1993. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3454] Hoffman P. and M. Blanchet, "Preparation of + Internationalized Strings ('stringprep')", RFC 3454, + December 2002. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version + 1.1", RFC 4346, March 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + June 2006. + + + +Sermersheim Standards Track [Page 46] + +RFC 4511 LDAPv3 June 2006 + + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [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.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, + Models and Service", 1993. + + [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service + Definition", 1993. + + + + + + + + + +Sermersheim Standards Track [Page 47] + +RFC 4511 LDAPv3 June 2006 + + +9. Informative References + + [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report + #17, Character Encoding Model", UTR17, + <http://www.unicode.org/unicode/reports/tr17/>, August + 2000. + + [Glossary] The Unicode Consortium, "Unicode Glossary", + <http://www.unicode.org/glossary/>. + + [PortReg] IANA, "Port Numbers", + <http://www.iana.org/assignments/port-numbers>. + + [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" + <http://www.ee.oulu.fi/research/ouspg/protos/testing/ + c06/ldapv3/>. + +10. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + result code registry to indicate that this document provides the + definitive technical specification for result codes 0-36, 48-54, 64- + 70, 80-90. It is also noted that one resultCode value + (strongAuthRequired) has been renamed (to strongerAuthRequired). + + The IANA has also updated the LDAP Protocol Mechanism registry to + indicate that this document and [RFC4513] provides the definitive + technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) + Extended operation. + + IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the + ASN.1 module defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Jim Sermersheim <jimse@novell.com> + Specification: RFC 4511 + Author/Change Controller: IESG + Comments: + Identifies the LDAP ASN.1 module + + + + + + + + + + + +Sermersheim Standards Track [Page 48] + +RFC 4511 LDAPv3 June 2006 + + +Appendix A. LDAP Result Codes + + This normative appendix details additional considerations regarding + LDAP result codes and provides a brief, general description of each + LDAP result code enumerated in Section 4.1.9. + + Additional result codes MAY be defined for use with extensions + [RFC4520]. Client implementations SHALL treat any result code that + they do not recognize as an unknown error condition. + + The descriptions provided here do not fully account for result code + substitutions used to prevent unauthorized disclosures (such as + substitution of noSuchObject for insufficientAccessRights, or + invalidCredentials for insufficientAccessRights). + +A.1. Non-Error Result Codes + + These result codes (called "non-error" result codes) do not indicate + an error condition: + + success (0), + compareFalse (5), + compareTrue (6), + referral (10), and + saslBindInProgress (14). + + The success, compareTrue, and compareFalse result codes indicate + successful completion (and, hence, are referred to as "successful" + result codes). + + The referral and saslBindInProgress result codes indicate the client + needs to take additional action to complete the operation. + +A.2. Result Codes + + Existing LDAP result codes are described as follows: + + success (0) + Indicates the successful completion of an operation. Note: + this code is not used with the Compare operation. See + compareFalse (5) and compareTrue (6). + + + + + + + + + + +Sermersheim Standards Track [Page 49] + +RFC 4511 LDAPv3 June 2006 + + + operationsError (1) + Indicates that the operation is not properly sequenced with + relation to other operations (of same or different type). + + For example, this code is returned if the client attempts to + StartTLS [RFC4346] while there are other uncompleted operations + or if a TLS layer was already installed. + + protocolError (2) + Indicates the server received data that is not well-formed. + + For Bind operation only, this code is also used to indicate + that the server does not support the requested protocol + version. + + For Extended operations only, this code is also used to + indicate that the server does not support (by design or + configuration) the Extended operation associated with the + requestName. + + For request operations specifying multiple controls, this may + be used to indicate that the server cannot ignore the order + of the controls as specified, or that the combination of the + specified controls is invalid or unspecified. + + timeLimitExceeded (3) + Indicates that the time limit specified by the client was + exceeded before the operation could be completed. + + sizeLimitExceeded (4) + Indicates that the size limit specified by the client was + exceeded before the operation could be completed. + + compareFalse (5) + Indicates that the Compare operation has successfully + completed and the assertion has evaluated to FALSE or + Undefined. + + compareTrue (6) + Indicates that the Compare operation has successfully + completed and the assertion has evaluated to TRUE. + + authMethodNotSupported (7) + Indicates that the authentication method or mechanism is not + supported. + + + + + + +Sermersheim Standards Track [Page 50] + +RFC 4511 LDAPv3 June 2006 + + + strongerAuthRequired (8) + Indicates the server requires strong(er) authentication in + order to complete the operation. + + When used with the Notice of Disconnection operation, this + code indicates that the server has detected that an + established security association between the client and + server has unexpectedly failed or been compromised. + + referral (10) + Indicates that a referral needs to be chased to complete the + operation (see Section 4.1.10). + + adminLimitExceeded (11) + Indicates that an administrative limit has been exceeded. + + unavailableCriticalExtension (12) + Indicates a critical control is unrecognized (see Section + 4.1.11). + + confidentialityRequired (13) + Indicates that data confidentiality protections are required. + + saslBindInProgress (14) + Indicates the server requires the client to send a new bind + request, with the same SASL mechanism, to continue the + authentication process (see Section 4.2). + + noSuchAttribute (16) + Indicates that the named entry does not contain the specified + attribute or attribute value. + + undefinedAttributeType (17) + Indicates that a request field contains an unrecognized + attribute description. + + inappropriateMatching (18) + Indicates that an attempt was made (e.g., in an assertion) to + use a matching rule not defined for the attribute type + concerned. + + constraintViolation (19) + Indicates that the client supplied an attribute value that + does not conform to the constraints placed upon it by the + data model. + + For example, this code is returned when multiple values are + supplied to an attribute that has a SINGLE-VALUE constraint. + + + +Sermersheim Standards Track [Page 51] + +RFC 4511 LDAPv3 June 2006 + + + attributeOrValueExists (20) + Indicates that the client supplied an attribute or value to + be added to an entry, but the attribute or value already + exists. + + invalidAttributeSyntax (21) + Indicates that a purported attribute value does not conform + to the syntax of the attribute. + + noSuchObject (32) + Indicates that the object does not exist in the DIT. + + aliasProblem (33) + Indicates that an alias problem has occurred. For example, + the code may used to indicate an alias has been dereferenced + that names no object. + + invalidDNSyntax (34) + Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search + base, target entry, ModifyDN newrdn, etc.) of a request does + not conform to the required syntax or contains attribute + values that do not conform to the syntax of the attribute's + type. + + aliasDereferencingProblem (36) + Indicates that a problem occurred while dereferencing an + alias. Typically, an alias was encountered in a situation + where it was not allowed or where access was denied. + + inappropriateAuthentication (48) + Indicates the server requires the client that had attempted + to bind anonymously or without supplying credentials to + provide some form of credentials. + + invalidCredentials (49) + Indicates that the provided credentials (e.g., the user's name + and password) are invalid. + + insufficientAccessRights (50) + Indicates that the client does not have sufficient access + rights to perform the operation. + + busy (51) + Indicates that the server is too busy to service the + operation. + + + + + + +Sermersheim Standards Track [Page 52] + +RFC 4511 LDAPv3 June 2006 + + + unavailable (52) + Indicates that the server is shutting down or a subsystem + necessary to complete the operation is offline. + + unwillingToPerform (53) + Indicates that the server is unwilling to perform the + operation. + + loopDetect (54) + Indicates that the server has detected an internal loop (e.g., + while dereferencing aliases or chaining an operation). + + namingViolation (64) + Indicates that the entry's name violates naming restrictions. + + objectClassViolation (65) + Indicates that the entry violates object class restrictions. + + notAllowedOnNonLeaf (66) + Indicates that the operation is inappropriately acting upon a + non-leaf entry. + + notAllowedOnRDN (67) + Indicates that the operation is inappropriately attempting to + remove a value that forms the entry's relative distinguished + name. + + entryAlreadyExists (68) + Indicates that the request cannot be fulfilled (added, moved, + or renamed) as the target entry already exists. + + objectClassModsProhibited (69) + Indicates that an attempt to modify the object class(es) of + an entry's 'objectClass' attribute is prohibited. + + For example, this code is returned when a client attempts to + modify the structural object class of an entry. + + affectsMultipleDSAs (71) + Indicates that the operation cannot be performed as it would + affect multiple servers (DSAs). + + other (80) + Indicates the server has encountered an internal error. + + + + + + + +Sermersheim Standards Track [Page 53] + +RFC 4511 LDAPv3 June 2006 + + +Appendix B. Complete ASN.1 Definition + + This appendix is normative. + + Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18} + -- Copyright (C) The Internet Society (2006). This version of + -- this ASN.1 module is part of RFC 4511; see the RFC itself + -- for full legal notices. + DEFINITIONS + IMPLICIT TAGS + EXTENSIBILITY IMPLIED ::= + + BEGIN + + LDAPMessage ::= SEQUENCE { + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse, + ..., + intermediateResponse IntermediateResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- [ISO10646] characters + + + + +Sermersheim Standards Track [Page 54] + +RFC 4511 LDAPv3 June 2006 + + + LDAPOID ::= OCTET STRING -- Constrained to <numericoid> + -- [RFC4512] + + LDAPDN ::= LDAPString -- Constrained to <distinguishedName> + -- [RFC4514] + + RelativeLDAPDN ::= LDAPString -- Constrained to <name-component> + -- [RFC4514] + + AttributeDescription ::= LDAPString + -- Constrained to <attributedescription> + -- [RFC4512] + + AttributeValue ::= OCTET STRING + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + AssertionValue ::= OCTET STRING + + PartialAttribute ::= SEQUENCE { + type AttributeDescription, + vals SET OF value AttributeValue } + + Attribute ::= PartialAttribute(WITH COMPONENTS { + ..., + vals (SIZE(1..MAX))}) + + MatchingRuleId ::= LDAPString + + LDAPResult ::= SEQUENCE { + resultCode ENUMERATED { + success (0), + operationsError (1), + protocolError (2), + timeLimitExceeded (3), + sizeLimitExceeded (4), + compareFalse (5), + compareTrue (6), + authMethodNotSupported (7), + strongerAuthRequired (8), + -- 9 reserved -- + referral (10), + adminLimitExceeded (11), + unavailableCriticalExtension (12), + confidentialityRequired (13), + saslBindInProgress (14), + + + +Sermersheim Standards Track [Page 55] + +RFC 4511 LDAPv3 June 2006 + + + noSuchAttribute (16), + undefinedAttributeType (17), + inappropriateMatching (18), + constraintViolation (19), + attributeOrValueExists (20), + invalidAttributeSyntax (21), + -- 22-31 unused -- + noSuchObject (32), + aliasProblem (33), + invalidDNSyntax (34), + -- 35 reserved for undefined isLeaf -- + aliasDereferencingProblem (36), + -- 37-47 unused -- + inappropriateAuthentication (48), + invalidCredentials (49), + insufficientAccessRights (50), + busy (51), + unavailable (52), + unwillingToPerform (53), + loopDetect (54), + -- 55-63 unused -- + namingViolation (64), + objectClassViolation (65), + notAllowedOnNonLeaf (66), + notAllowedOnRDN (67), + entryAlreadyExists (68), + objectClassModsProhibited (69), + -- 70 reserved for CLDAP -- + affectsMultipleDSAs (71), + -- 72-79 unused -- + other (80), + ... }, + matchedDN LDAPDN, + diagnosticMessage LDAPString, + referral [3] Referral OPTIONAL } + + Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI + + URI ::= LDAPString -- limited to characters permitted in + -- URIs + + Controls ::= SEQUENCE OF control Control + + Control ::= SEQUENCE { + controlType LDAPOID, + criticality BOOLEAN DEFAULT FALSE, + controlValue OCTET STRING OPTIONAL } + + + + +Sermersheim Standards Track [Page 56] + +RFC 4511 LDAPv3 June 2006 + + + BindRequest ::= [APPLICATION 0] SEQUENCE { + version INTEGER (1 .. 127), + name LDAPDN, + authentication AuthenticationChoice } + + AuthenticationChoice ::= CHOICE { + simple [0] OCTET STRING, + -- 1 and 2 reserved + sasl [3] SaslCredentials, + ... } + + SaslCredentials ::= SEQUENCE { + mechanism LDAPString, + credentials OCTET STRING OPTIONAL } + + BindResponse ::= [APPLICATION 1] SEQUENCE { + COMPONENTS OF LDAPResult, + serverSaslCreds [7] OCTET STRING OPTIONAL } + + UnbindRequest ::= [APPLICATION 2] NULL + + SearchRequest ::= [APPLICATION 3] SEQUENCE { + baseObject LDAPDN, + scope ENUMERATED { + baseObject (0), + singleLevel (1), + wholeSubtree (2), + ... }, + derefAliases ENUMERATED { + neverDerefAliases (0), + derefInSearching (1), + derefFindingBaseObj (2), + derefAlways (3) }, + sizeLimit INTEGER (0 .. maxInt), + timeLimit INTEGER (0 .. maxInt), + typesOnly BOOLEAN, + filter Filter, + attributes AttributeSelection } + + AttributeSelection ::= SEQUENCE OF selector LDAPString + -- The LDAPString is constrained to + -- <attributeSelector> in Section 4.5.1.8 + + 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, + + + +Sermersheim Standards Track [Page 57] + +RFC 4511 LDAPv3 June 2006 + + + substrings [4] SubstringFilter, + greaterOrEqual [5] AttributeValueAssertion, + lessOrEqual [6] AttributeValueAssertion, + present [7] AttributeDescription, + approxMatch [8] AttributeValueAssertion, + extensibleMatch [9] MatchingRuleAssertion, + ... } + + SubstringFilter ::= SEQUENCE { + type AttributeDescription, + substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { + initial [0] AssertionValue, -- can occur at most once + any [1] AssertionValue, + final [2] AssertionValue } -- can occur at most once + } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + SearchResultEntry ::= [APPLICATION 4] SEQUENCE { + objectName LDAPDN, + attributes PartialAttributeList } + + PartialAttributeList ::= SEQUENCE OF + partialAttribute PartialAttribute + + SearchResultReference ::= [APPLICATION 19] SEQUENCE + SIZE (1..MAX) OF uri URI + + SearchResultDone ::= [APPLICATION 5] LDAPResult + + ModifyRequest ::= [APPLICATION 6] SEQUENCE { + object LDAPDN, + changes SEQUENCE OF change SEQUENCE { + operation ENUMERATED { + add (0), + delete (1), + replace (2), + ... }, + modification PartialAttribute } } + + ModifyResponse ::= [APPLICATION 7] LDAPResult + + + + + + +Sermersheim Standards Track [Page 58] + +RFC 4511 LDAPv3 June 2006 + + + AddRequest ::= [APPLICATION 8] SEQUENCE { + entry LDAPDN, + attributes AttributeList } + + AttributeList ::= SEQUENCE OF attribute Attribute + + AddResponse ::= [APPLICATION 9] LDAPResult + + DelRequest ::= [APPLICATION 10] LDAPDN + + DelResponse ::= [APPLICATION 11] LDAPResult + + ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { + entry LDAPDN, + newrdn RelativeLDAPDN, + deleteoldrdn BOOLEAN, + newSuperior [0] LDAPDN OPTIONAL } + + ModifyDNResponse ::= [APPLICATION 13] LDAPResult + + CompareRequest ::= [APPLICATION 14] SEQUENCE { + entry LDAPDN, + ava AttributeValueAssertion } + + CompareResponse ::= [APPLICATION 15] LDAPResult + + AbandonRequest ::= [APPLICATION 16] MessageID + + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } + + ExtendedResponse ::= [APPLICATION 24] SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] LDAPOID OPTIONAL, + responseValue [11] OCTET STRING OPTIONAL } + + IntermediateResponse ::= [APPLICATION 25] SEQUENCE { + responseName [0] LDAPOID OPTIONAL, + responseValue [1] OCTET STRING OPTIONAL } + + END + + + + + + + + + +Sermersheim Standards Track [Page 59] + +RFC 4511 LDAPv3 June 2006 + + +Appendix C. Changes + + This appendix is non-normative. + + This appendix summarizes substantive changes made to RFC 2251, RFC + 2830, and RFC 3771. + +C.1. Changes Made to RFC 2251 + + This section summarizes the substantive changes made to Sections 1, + 2, 3.1, and 4, and the remainder of RFC 2251. Readers should + consult [RFC4512] and [RFC4513] for summaries of changes to other + sections. + +C.1.1. Section 1 (Status of this Memo) + + - Removed IESG note. Post publication of RFC 2251, mandatory LDAP + authentication mechanisms have been standardized which are + sufficient to remove this note. See [RFC4513] for authentication + mechanisms. + +C.1.2. Section 3.1 (Protocol Model) and others + + - Removed notes giving history between LDAP v1, v2, and v3. Instead, + added sufficient language so that this document can stand on its + own. + +C.1.3. Section 4 (Elements of Protocol) + + - Clarified where the extensibility features of ASN.1 apply to the + protocol. This change affected various ASN.1 types by the + inclusion of ellipses (...) to certain elements. + - Removed the requirement that servers that implement version 3 or + later MUST provide the 'supportedLDAPVersion' attribute. This + statement provided no interoperability advantages. + +C.1.4. Section 4.1.1 (Message Envelope) + + - There was a mandatory requirement for the server to return a + Notice of Disconnection and drop the transport connection when a + PDU is malformed in a certain way. This has been updated such that + the server SHOULD return the Notice of Disconnection, and it MUST + terminate the LDAP Session. + +C.1.5. Section 4.1.1.1 (Message ID) + + - Required that the messageID of requests MUST be non-zero as the + zero is reserved for Notice of Disconnection. + + + +Sermersheim Standards Track [Page 60] + +RFC 4511 LDAPv3 June 2006 + + + - Specified when it is and isn't appropriate to return an already + used messageID. RFC 2251 accidentally imposed synchronous server + behavior in its wording of this. + +C.1.6. Section 4.1.2 (String Types) + + - Stated that LDAPOID is constrained to <numericoid> from [RFC4512]. + +C.1.7. Section 4.1.5.1 (Binary Option) and others + + - Removed the Binary Option from the specification. There are + numerous interoperability problems associated with this method of + alternate attribute type encoding. Work to specify a suitable + replacement is ongoing. + +C.1.8. Section 4.1.8 (Attribute) + + - Combined the definitions of PartialAttribute and Attribute here, + and defined Attribute in terms of PartialAttribute. + +C.1.9. Section 4.1.10 (Result Message) + + - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to + be sent for non-error results. + - Moved some language into Appendix A, and referred the reader there. + - Allowed matchedDN to be present for other result codes than those + listed in RFC 2251. + - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to + clarify that this code may often be returned to indicate that a + stronger authentication is needed to perform a given operation. + +C.1.10. Section 4.1.11 (Referral) + + - Defined referrals in terms of URIs rather than URLs. + - Removed the requirement that all referral URIs MUST be equally + capable of progressing the operation. The statement was ambiguous + and provided no instructions on how to carry it out. + - Added the requirement that clients MUST NOT loop between servers. + - Clarified the instructions for using LDAPURLs in referrals, and in + doing so added a recommendation that the scope part be present. + - Removed imperatives which required clients to use URLs in specific + ways to progress an operation. These did nothing for + interoperability. + + + + + + + + +Sermersheim Standards Track [Page 61] + +RFC 4511 LDAPv3 June 2006 + + +C.1.11. Section 4.1.12 (Controls) + + - Specified how control values defined in terms of ASN.1 are to be + encoded. + - Noted that the criticality field is only applied to request + messages (except UnbindRequest), and must be ignored when present + on response messages and UnbindRequest. + - Specified that non-critical controls may be ignored at the + server's discretion. There was confusion in the original wording + which led some to believe that recognized controls may not be + ignored as long as they were associated with a proper request. + - Added language regarding combinations of controls and the ordering + of controls on a message. + - Specified that when the semantics of the combination of controls + is undefined or unknown, it results in a protocolError. + - Changed "The server MUST be prepared" to "Implementations MUST be + prepared" in paragraph 8 to reflect that both client and server + implementations must be able to handle this (as both parse + controls). + +C.1.12. Section 4.2 (Bind Operation) + + - Mandated that servers return protocolError when the version is not + supported. + - Disambiguated behavior when the simple authentication is used, the + name is empty, and the password is non-empty. + - Required servers to not dereference aliases for Bind. This was + added for consistency with other operations and to help ensure + data consistency. + - Required that textual passwords be transferred as UTF-8 encoded + Unicode, and added recommendations on string preparation. This was + to help ensure interoperability of passwords being sent from + different clients. + +C.1.13. Section 4.2.1 (Sequencing of the Bind Request) + + - This section was largely reorganized for readability, and language + was added to clarify the authentication state of failed and + abandoned Bind operations. + - Removed: "If a SASL transfer encryption or integrity mechanism has + been negotiated, that mechanism does not support the changing of + credentials from one identity to another, then the client MUST + instead establish a new connection." + If there are dependencies between multiple negotiations of a + particular SASL mechanism, the technical specification for that + SASL mechanism details how applications are to deal with them. + LDAP should not require any special handling. + - Dropped MUST imperative in paragraph 3 to align with [RFC2119]. + + + +Sermersheim Standards Track [Page 62] + +RFC 4511 LDAPv3 June 2006 + + + - Mandated that clients not send non-Bind operations while a Bind is + in progress, and suggested that servers not process them if they + are received. This is needed to ensure proper sequencing of the + Bind in relationship to other operations. + +C.1.14. Section 4.2.3 (Bind Response) + + - Moved most error-related text to Appendix A, and added text + regarding certain errors used in conjunction with the Bind + operation. + - Prohibited the server from specifying serverSaslCreds when not + appropriate. + +C.1.15. Section 4.3 (Unbind Operation) + + - Specified that both peers are to cease transmission and terminate + the LDAP session for the Unbind operation. + +C.1.16. Section 4.4 (Unsolicited Notification) + + - Added instructions for future specifications of Unsolicited + Notifications. + +C.1.17. Section 4.5.1 (Search Request) + + - SearchRequest attributes is now defined as an AttributeSelection + type rather than AttributeDescriptionList, and an ABNF is + provided. + - SearchRequest attributes may contain duplicate attribute + descriptions. This was previously prohibited. Now servers are + instructed to ignore subsequent names when they are duplicated. + This was relaxed in order to allow different short names and also + OIDs to be requested for an attribute. + - The present search filter now evaluates to Undefined when the + specified attribute is not known to the server. It used to + evaluate to FALSE, which caused behavior inconsistent with what + most would expect, especially when the 'not' operator was used. + - The Filter choice SubstringFilter substrings type is now defined + with a lower bound of 1. + - The SubstringFilter substrings 'initial, 'any', and 'final' types + are now AssertionValue rather than LDAPString. Also, added + imperatives stating that 'initial' (if present) must be listed + first, and 'final' (if present) must be listed last. + - Disambiguated the semantics of the derefAliases choices. There was + question as to whether derefInSearching applied to the base object + in a wholeSubtree Search. + - Added instructions for equalityMatch, substrings, greaterOrEqual, + lessOrEqual, and approxMatch. + + + +Sermersheim Standards Track [Page 63] + +RFC 4511 LDAPv3 June 2006 + + + +C.1.18. Section 4.5.2 (Search Result) + + - Recommended that servers not use attribute short names when it + knows they are ambiguous or may cause interoperability problems. + - Removed all mention of ExtendedResponse due to lack of + implementation. + +C.1.19. Section 4.5.3 (Continuation References in the Search Result) + + - Made changes similar to those made to Section 4.1.11. + +C.1.20. Section 4.5.3.1 (Example) + + - Fixed examples to adhere to changes made to Section 4.5.3. + +C.1.21. Section 4.6 (Modify Operation) + + - Replaced AttributeTypeAndValues with Attribute as they are + equivalent. + - Specified the types of modification changes that might + temporarily violate schema. Some readers were under the impression + that any temporary schema violation was allowed. + +C.1.22. Section 4.7 (Add Operation) + + - Aligned Add operation with X.511 in that the attributes of the RDN + are used in conjunction with the listed attributes to create the + entry. Previously, Add required that the distinguished values be + present in the listed attributes. + - Removed requirement that the objectClass attribute MUST be + specified as some DSE types do not require this attribute. + Instead, generic wording was added, requiring the added entry to + adhere to the data model. + - Removed recommendation regarding placement of objects. This is + covered in the data model document. + +C.1.23. Section 4.9 (Modify DN Operation) + + - Required servers to not dereference aliases for Modify DN. This + was added for consistency with other operations and to help ensure + data consistency. + - Allow Modify DN to fail when moving between naming contexts. + - Specified what happens when the attributes of the newrdn are not + present on the entry. + + + + + + +Sermersheim Standards Track [Page 64] + +RFC 4511 LDAPv3 June 2006 + + +C.1.24. Section 4.10 (Compare Operation) + + - Specified that compareFalse means that the Compare took place and + the result is false. There was confusion that led people to + believe that an Undefined match resulted in compareFalse. + - Required servers to not dereference aliases for Compare. This was + added for consistency with other operations and to help ensure + data consistency. + +C.1.25. Section 4.11 (Abandon Operation) + + - Explained that since Abandon returns no response, clients should + not use it if they need to know the outcome. + - Specified that Abandon and Unbind cannot be abandoned. + +C.1.26. Section 4.12 (Extended Operation) + + - Specified how values of Extended operations defined in terms of + ASN.1 are to be encoded. + - Added instructions on what Extended operation specifications + consist of. + - Added a recommendation that servers advertise supported Extended + operations. + +C.1.27. Section 5.2 (Transfer Protocols) + + - Moved referral-specific instructions into referral-related + sections. + +C.1.28. Section 7 (Security Considerations) + + - Reworded notes regarding SASL not protecting certain aspects of + the LDAP Bind messages. + - Noted that Servers are encouraged to prevent directory + modifications by clients that have authenticated anonymously + [RFC4513]. + - Added a note regarding the possibility of changes to security + factors (authentication, authorization, and data confidentiality). + - Warned against following referrals that may have been injected in + the data stream. + - Noted that servers should protect information equally, whether in + an error condition or not, and mentioned matchedDN, + diagnosticMessage, and resultCodes specifically. + - Added a note regarding malformed and long encodings. + + + + + + + +Sermersheim Standards Track [Page 65] + +RFC 4511 LDAPv3 June 2006 + + +C.1.29. Appendix A (Complete ASN.1 Definition) + + - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. + - Removed AttributeType. It is not used. + +C.2. Changes Made to RFC 2830 + + This section summarizes the substantive changes made to Sections of + RFC 2830. Readers should consult [RFC4513] for summaries of changes + to other sections. + +C.2.1. Section 2.3 (Response other than "success") + + - Removed wording indicating that referrals can be returned from + StartTLS. + - Removed requirement that only a narrow set of result codes can be + returned. Some result codes are required in certain scenarios, but + any other may be returned if appropriate. + - Removed requirement that the ExtendedResponse.responseName MUST be + present. There are circumstances where this is impossible, and + requiring this is at odds with language in Section 4.12. + +C.2.1. Section 4 (Closing a TLS Connection) + + - Reworded most of this section to align with definitions of the + LDAP protocol layers. + - Removed instructions on abrupt closure as this is covered in other + areas of the document (specifically, Section 5.3) + +C.3. Changes Made to RFC 3771 + + - Rewrote to fit into this document. In general, semantics were + preserved. Supporting and background language seen as redundant + due to its presence in this document was omitted. + + - Specified that Intermediate responses to a request may be of + different types, and one of the response types may be specified to + have no response value. + + + + + + + + + + + + + +Sermersheim Standards Track [Page 66] + +RFC 4511 LDAPv3 June 2006 + + +Editor's Address + + Jim Sermersheim + Novell, Inc. + 1800 South Novell Place + Provo, Utah 84606, USA + + Phone: +1 801 861-3088 + EMail: jimse@novell.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim Standards Track [Page 67] + +RFC 4511 LDAPv3 June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Sermersheim Standards Track [Page 68] + diff --git a/source4/ldap_server/devdocs/rfc4512.txt b/source4/ldap_server/devdocs/rfc4512.txt new file mode 100644 index 0000000000..f45a3f3e73 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4512.txt @@ -0,0 +1,2915 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4512 OpenLDAP Foundation +Obsoletes: 2251, 2252, 2256, 3674 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Directory Information Models + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is an Internet + protocol for accessing distributed directory services that act in + accordance with X.500 data and service models. This document + describes the X.500 Directory Information Models, as used in LDAP. + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4512 LDAP Models June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other LDAP Specifications ..................3 + 1.2. Relationship to X.501 ......................................4 + 1.3. Conventions ................................................4 + 1.4. Common ABNF Productions ....................................4 + 2. Model of Directory User Information .............................6 + 2.1. The Directory Information Tree .............................7 + 2.2. Structure of an Entry ......................................7 + 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 ..................................................17 + 3.2. Subentries ................................................18 + 3.3. The 'objectClass' attribute ...............................18 + 3.4. Operational Attributes ....................................19 + 4. Directory Schema ...............................................22 + 4.1. Schema Definitions ........................................23 + 4.2. Subschema Subentries ......................................32 + 4.3. 'extensibleObject' object class ...........................35 + 4.4. Subschema Discovery .......................................35 + 5. DSA (Server) Informational Model ...............................36 + 5.1. Server-Specific Data Requirements .........................36 + 6. Other Considerations ...........................................40 + 6.1. Preservation of User Information ..........................40 + 6.2. Short Names ...............................................41 + 6.3. Cache and Shadowing .......................................41 + 7. Implementation Guidelines ......................................42 + 7.1. Server Guidelines .........................................42 + 7.2. Client Guidelines .........................................42 + 8. Security Considerations ........................................43 + 9. IANA Considerations ............................................43 + 10. Acknowledgements ..............................................44 + 11. Normative References ..........................................45 + Appendix A. Changes ...............................................47 + A.1. Changes to RFC 2251 .......................................47 + A.2. Changes to RFC 2252 .......................................49 + A.3. Changes to RFC 2256 .......................................50 + A.4. Changes to RFC 3674 .......................................51 + + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4512 LDAP Models June 2006 + + +1. Introduction + + This document discusses the X.500 Directory Information Models + [X.501], as used by the Lightweight Directory Access Protocol (LDAP) + [RFC4510]. + + 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 + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as + portions of Sections 4 and 6. Appendix A.1 summarizes changes to + these sections. The remainder of RFC 2251 is obsoleted by the + [RFC4511], [RFC4513], and [RFC4510] documents. + + + + +Zeilenga Standards Track [Page 3] + +RFC 4512 LDAP Models June 2006 + + + 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 [RFC4517]. + + 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 [RFC4519] and [RFC4517]. + + 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 [RFC4517]. + +1.4. Common ABNF Productions + + A number of syntaxes in this document are described using Augmented + Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a + number of syntaxes defined in other documents) rely on the following + common productions: + + keystring = leadkeychar *keychar + leadkeychar = ALPHA + keychar = ALPHA / DIGIT / HYPHEN + number = DIGIT / ( LDIGIT 1*DIGIT ) + + ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" + DIGIT = %x30 / LDIGIT ; "0"-"9" + LDIGIT = %x31-39 ; "1"-"9" + HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" + + SP = 1*SPACE ; one or more " " + WSP = 0*SPACE ; zero or more " " + + + +Zeilenga Standards Track [Page 4] + +RFC 4512 LDAP Models June 2006 + + + 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 [RFC3629] 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: + + 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 + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4512 LDAP Models June 2006 + + + Where either an object identifier or a short name may be specified, + the following production is used: + + oid = descr / numericoid + + While the <descr> form is generally preferred when the usage is + restricted to short names referring to object identifiers that + identify like kinds of objects (e.g., attribute type descriptions, + matching rule descriptions, object class descriptions), the + <numericoid> 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 + 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. + + + +Zeilenga Standards Track [Page 6] + +RFC 4512 LDAP Models June 2006 + + + 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 that have the same parent are known + as siblings. + +2.2. Structure of an Entry + + An entry consists of a set of attributes that hold information about + the object that 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 + 'givenName' attribute is the attribute that consists of the attribute + description 'givenName' (the 'givenName' attribute type [RFC4519] 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. + + + +Zeilenga Standards Track [Page 7] + +RFC 4512 LDAP Models June 2006 + + + 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 that is not equivalent + to itself. For example, the 'givenName' attribute cannot have as a + value a directory string that 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 + siblings). + + The following are examples of string representations of RDNs + [RFC4514]: + + 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. + + + + +Zeilenga Standards Track [Page 8] + +RFC 4512 LDAP Models June 2006 + + +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 + [RFC4514]: + + 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) that share certain characteristics" [X.501]. + + As defined in [X.501]: + + Object classes are used in the Directory for a number of purposes: + + - describing and categorizing objects and the entries that + correspond to these objects; + + - where appropriate, controlling the operation of the Directory; + + - regulating, in conjunction with DIT structure rule + specifications, the position of entries in the DIT; + + - regulating, in conjunction with DIT content rule + specifications, the attributes that are contained in entries; + + - identifying classes of entry that are to be associated with a + particular policy by the appropriate administrative authority. + + An object class (a subclass) may be derived from an object class + (its direct superclass) which is itself derived from an even more + generic object class. For structural object classes, this process + stops at the most generic object class, 'top' (defined in Section + 2.4.1). An ordered set of superclasses up to the most superior + object class of an object class is its superclass chain. + + + + + +Zeilenga Standards Track [Page 9] + +RFC 4512 LDAP Models June 2006 + + + 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 that inherits + from that abstract class. + + Abstract object classes cannot derive from structural or 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'. + + 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. + + + + + + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4512 LDAP Models June 2006 + + +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 characterized 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. + +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. + + + + +Zeilenga Standards Track [Page 11] + +RFC 4512 LDAP Models June 2006 + + + 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 that 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 <attributetype> identifies the attribute type and each <option> + identifies an attribute option. Both <attributetype> and <option> + productions are case insensitive. The order in which <option>s + appear is irrelevant. That is, any two <attributedescription>s that + consist of the same <attributetype> and same set of <option>s are + equivalent. + + Examples of valid attribute descriptions: + + 2.5.4.0 + cn;lang-de;lang-en + owner + + An attribute description with an unrecognized attribute type is to be + treated as unrecognized. Servers SHALL treat an attribute + description with an unrecognized attribute option as unrecognized. + Clients MAY treat an unrecognized attribute option as a tagging + option (see Section 2.5.2.1). + + All attributes of an entry must have distinct attribute descriptions. + +2.5.1. Attribute Types + + An 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. + + + +Zeilenga Standards Track [Page 12] + +RFC 4512 LDAP Models June 2006 + + + If no equality matching is specified for the attribute type: + + - the attribute (of the type) cannot be used for naming; + - when adding the attribute (or replacing all values), no two + values may be equivalent (see 2.2); + - individual values of a multi-valued attribute are not to be + independently added or deleted; + - attribute value assertions (such as matching in search filters + and comparisons) using values of such a type cannot be + performed. + + Otherwise, the specified equality matching rule is to be used to + evaluate attribute value assertions concerning the attribute type. + The specified equality rule is to be transitive and commutative. + + The attribute type indicates whether the attribute is a user + attribute or an operational attribute. If operational, the attribute + type indicates the operational usage and whether or not the attribute + is modifiable by users. Operational attributes are discussed in + Section 3.4. + + An attribute type (a subtype) may derive from a more generic + attribute type (a direct supertype). The following restrictions + apply to subtyping: + + - a subtype must have the same usage as its direct supertype, + - a subtype's syntax must be the same, or a refinement of, its + supertype's syntax, and + - a subtype must be collective [RFC3671] if its supertype is + collective. + + An attribute description consisting of a subtype and no options is + said to be the direct description subtype of the attribute + description consisting of the subtype's direct supertype and no + options. + + Each attribute type is identified by an object identifier (OID) and, + optionally, one or more short names (descriptors). + +2.5.2. Attribute Options + + There are multiple kinds of attribute description options. The LDAP + technical specification details one kind: tagging options. + + Not all options can be associated with attributes held in the + directory. Tagging options can be. + + + + + +Zeilenga Standards Track [Page 13] + +RFC 4512 LDAP Models June 2006 + + + Not all options can be used in conjunction with all attribute types. + In such cases, the attribute description is to be treated as + unrecognized. + + An attribute description that contains mutually exclusive options + shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where + "x-foo" and "x-bar" are mutually exclusive, is to be treated as + unrecognized. + + Other kinds of options may be specified in future documents. These + documents must detail how new kinds of options they define relate to + tagging options. In particular, these documents must detail whether + or not new kinds of options can be associated with attributes held in + the directory, how new kinds of options affect transfer of attribute + values, and how new kinds of options are treated in attribute + description hierarchies. + + Options are represented as short, case-insensitive textual strings + conforming to the <option> production defined in Section 2.5 of this + document. + + Procedures for registering options are detailed in BCP 64, RFC 4520 + [RFC4520]. + +2.5.2.1. Tagging Options + + Attributes held in the directory can have attribute descriptions with + any number of tagging options. Tagging options are never mutually + exclusive. + + An attribute description with N tagging options is a direct + (description) subtype of all attribute descriptions of the same + attribute type and all but one of the N options. If the attribute + type has a supertype, then the attribute description is also a direct + (description) subtype of the attribute description of the supertype + and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct + (description) subtype of 'cn;lang-de', 'cn;lang-en', and + 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined + in [RFC4519]). + +2.5.3. Attribute Description Hierarchies + + An attribute description can be the direct subtype of zero or more + other attribute descriptions as indicated by attribute type subtyping + (as described in Section 2.5.1) or attribute tagging option subtyping + (as described in Section 2.5.2.1). These subtyping relationships are + used to form hierarchies of attribute descriptions and attributes. + + + + +Zeilenga Standards Track [Page 14] + +RFC 4512 LDAP Models June 2006 + + + As adapted from [X.501]: + + Attribute hierarchies allow access to the DIB with varying degrees + of granularity. This is achieved by allowing the value components + of attributes to be accessed by using either their specific + attribute description (a direct reference to the attribute) or a + more generic attribute description (an indirect reference). + + Semantically related attributes may be placed in a hierarchical + relationship, the more specialized being placed subordinate to the + more generalized. Searching for or retrieving attributes and + their values is made easier by quoting the more generalized + attribute description; a filter item so specified is evaluated for + the more specialized descriptions as well as for the quoted + description. + + Where subordinate specialized descriptions are selected to be + returned as part of a search result these descriptions shall be + returned if available. Where the more general descriptions are + selected to be returned as part of a search result both the + general and the specialized descriptions shall be returned, if + available. An attribute value shall always be returned as a value + of its own attribute description. + + All of the attribute descriptions in an attribute hierarchy are + treated as distinct and unrelated descriptions for user + modification of entry content. + + An attribute value stored in an object or alias entry is of + precisely one attribute description. The description is indicated + when the value is originally added to the entry. + + For the purpose of subschema administration of the entry, a + specification that an attribute is required is fulfilled if the entry + contains a value of an attribute description belonging to an + attribute hierarchy where the attribute type of that description is + the same as the required attribute's type. That is, a "MUST name" + specification is fulfilled by 'name' or 'name;x-tag-option', but is + not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a + subtype of 'name'). Likewise, an entry may contain a value of an + attribute description belonging to an attribute hierarchy where the + attribute type of that description is either explicitly included in + the definition of an object class to which the entry belongs or + allowed by the DIT content rule applicable to that entry. That is, + 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST + name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" + (or by "MUST name"). + + + + +Zeilenga Standards Track [Page 15] + +RFC 4512 LDAP Models June 2006 + + + For the purposes of other policy administration, unless stated + otherwise in the specification of the particular administrative + model, all of the attribute descriptions in an attribute hierarchy + are treated as distinct and unrelated descriptions. + +2.6. Alias Entries + + As adapted from [X.501]: + + An alias, or an alias name, for an object is an alternative name + for an object or object entry which is provided by the use of + alias entries. + + Each alias entry contains, within the 'aliasedObjectName' + attribute (known as the 'aliasedEntryName' attribute in X.500), a + name of some object. The distinguished name of the alias entry is + thus also a name for this object. + + NOTE - The name within the 'aliasedObjectName' is said to be + pointed to by the alias. It does not have to be the + distinguished name of any entry. + + The conversion of an alias name to an object name is termed + (alias) dereferencing and comprises the systematic replacement of + alias names, where found within a purported name, by the value of + the corresponding 'aliasedObjectName' attribute. The process may + require the examination of more than one alias entry. + + Any particular entry in the DIT may have zero or more alias names. + It therefore follows that several alias entries may point to the + same entry. An alias entry may point to an entry that is not a + leaf entry and may point to another alias entry. + + An alias entry shall have no subordinates, so that an alias entry + is always a leaf entry. + + Every alias entry shall belong to the 'alias' object class. + + An entry with the 'alias' object class must also belong to an object + class (or classes), or be governed by a DIT content rule, which + allows suitable naming attributes to be present. + + Example: + + dn: cn=bar,dc=example,dc=com + objectClass: top + objectClass: alias + objectClass: extensibleObject + + + +Zeilenga Standards Track [Page 16] + +RFC 4512 LDAP Models June 2006 + + + cn: bar + aliasedObjectName: cn=foo,dc=example,dc=com + +2.6.1. 'alias' Object Class + + Alias entries belong to the 'alias' object class. + + ( 2.5.6.1 NAME 'alias' + SUP top STRUCTURAL + MUST aliasedObjectName ) + +2.6.2. 'aliasedObjectName' Attribute Type + + The 'aliasedObjectName' attribute holds the name of the entry an + alias points to. The 'aliasedObjectName' attribute is known as the + 'aliasedEntryName' attribute in X.500. + + ( 2.5.4.1 NAME 'aliasedObjectName' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE ) + + The 'distinguishedNameMatch' matching rule and the DistinguishedName + (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. + +3. Directory Administrative and Operational Information + + This section discusses select aspects of the X.500 Directory + Administrative and Operational Information model [X.501]. LDAP + implementations MAY support other aspects of this model. + +3.1. Subtrees + + As defined in [X.501]: + + A subtree is a collection of object and alias entries situated at + the vertices of a tree. Subtrees do not contain subentries. The + prefix sub, in subtree, emphasizes that the base (or root) vertex + of this tree is usually subordinate to the root of the DIT. + + A subtree begins at some vertex and extends to some identifiable + lower boundary, possibly extending to leaves. A subtree is always + defined within a context which implicitly bounds the subtree. For + example, the vertex and lower boundaries of a subtree defining a + replicated area are bounded by a naming context. + + + + + + +Zeilenga Standards Track [Page 17] + +RFC 4512 LDAP Models June 2006 + + +3.2. Subentries + + A subentry is a "special sort of entry, known by the Directory, used + to hold information associated with a subtree or subtree refinement" + [X.501]. Subentries are used in Directory to hold for administrative + and operational purposes as defined in [X.501]. Their use in LDAP is + detailed in [RFC3672]. + + The term "(sub)entry" in this specification indicates that servers + implementing X.500(93) models are, in accordance with X.500(93) as + described in [RFC3672], to use a subentry and that other servers are + to use an object entry belonging to the appropriate auxiliary class + normally used with the subentry (e.g., 'subschema' for subschema + subentries) to mimic the subentry. This object entry's RDN SHALL be + formed from a value of the 'cn' (commonName) attribute [RFC4519] (as + all subentries are named with 'cn'). + +3.3. The 'objectClass' attribute + + Each entry in the DIT has an 'objectClass' attribute. + + ( 2.5.4.0 NAME 'objectClass' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER + (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517]. + + The 'objectClass' attribute specifies the object classes of an entry, + which (among other things) are used in conjunction with the + controlling schema to determine the permitted attributes of an entry. + Values of this attribute can be modified by clients, but the + 'objectClass' attribute cannot be removed. + + Servers that follow X.500(93) models SHALL restrict modifications of + this attribute to prevent the basic structural class of the entry + from being changed. That is, one cannot change a 'person' into a + 'country'. + + When creating an entry or adding an 'objectClass' value to an entry, + all superclasses of the named classes SHALL be implicitly added as + well if not already present. That is, if the auxiliary class 'x-a' + is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' + causes 'x-b' to be implicitly added (if is not already present). + + Servers SHALL restrict modifications of this attribute to prevent + superclasses of remaining 'objectClass' values from being deleted. + That is, if the auxiliary class 'x-a' is a subclass of the auxiliary + + + +Zeilenga Standards Track [Page 18] + +RFC 4512 LDAP Models June 2006 + + + class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', + an attempt to delete only 'x-b' from the 'objectClass' attribute is + an error. + +3.4. Operational Attributes + + Some attributes, termed operational attributes, are used or + maintained by servers for administrative and operational purposes. + As stated in [X.501]: "There are three varieties of operational + attributes: Directory operational attributes, DSA-shared operational + attributes, and DSA-specific operational attributes". + + A directory operational attribute is used to represent operational + and/or administrative information in the Directory Information Model. + This includes operational attributes maintained by the server (e.g., + 'createTimestamp') as well as operational attributes that hold values + administrated by the user (e.g., 'ditContentRules'). + + A DSA-shared operational attribute is used to represent information + of the DSA Information Model that is shared between DSAs. + + A DSA-specific operational attribute is used to represent information + of the DSA Information Model that is specific to the DSA (though, in + some cases, may be derived from information shared between DSAs; + e.g., 'namingContexts'). + + The DSA Information Model operational attributes are detailed in + [X.501]. + + Operational attributes are not normally visible. They are not + returned in search results unless explicitly requested by name. + + Not all operational attributes are user modifiable. + + Entries may contain, among others, the following operational + attributes: + + - creatorsName: the Distinguished Name of the user who added this + entry to the directory, + + - createTimestamp: the time this entry was added to the directory, + + - modifiersName: the Distinguished Name of the user who last + modified this entry, and + + - modifyTimestamp: the time this entry was last modified. + + + + + +Zeilenga Standards Track [Page 19] + +RFC 4512 LDAP Models June 2006 + + + Servers SHOULD maintain the 'creatorsName', 'createTimestamp', + 'modifiersName', and 'modifyTimestamp' attributes for all entries of + the DIT. + +3.4.1. 'creatorsName' + + This attribute appears in entries that were added using the protocol + (e.g., using the Add operation). The value is the distinguished name + of the creator. + + ( 2.5.18.3 NAME 'creatorsName' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'distinguishedNameMatch' matching rule and the DistinguishedName + (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. + +3.4.2. 'createTimestamp' + + This attribute appears in entries that were added using the protocol + (e.g., using the Add operation). The value is the time the entry was + added. + + ( 2.5.18.1 NAME 'createTimestamp' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' + matching rules and the GeneralizedTime + (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. + +3.4.3. 'modifiersName' + + This attribute appears in entries that have been modified using the + protocol (e.g., using the Modify operation). The value is the + distinguished name of the last modifier. + + ( 2.5.18.4 NAME 'modifiersName' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + + + +Zeilenga Standards Track [Page 20] + +RFC 4512 LDAP Models June 2006 + + + The 'distinguishedNameMatch' matching rule and the DistinguishedName + (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. + +3.4.4. 'modifyTimestamp' + + This attribute appears in entries that have been modified using the + protocol (e.g., using the Modify operation). The value is the time + the entry was last modified. + + ( 2.5.18.2 NAME 'modifyTimestamp' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' + matching rules and the GeneralizedTime + (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. + +3.4.5. 'structuralObjectClass' + + This attribute indicates the structural object class of the entry. + + ( 2.5.21.9 NAME 'structuralObjectClass' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER + (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517]. + +3.4.6. 'governingStructureRule' + + This attribute indicates the structure rule governing the entry. + + ( 2.5.21.10 NAME 'governingStructureRule' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'integerMatch' matching rule and INTEGER + (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517]. + + + + + + +Zeilenga Standards Track [Page 21] + +RFC 4512 LDAP Models June 2006 + + +4. Directory Schema + + As defined in [X.501]: + + The Directory Schema is a set of definitions and constraints + concerning the structure of the DIT, the possible ways entries are + named, the information that can be held in an entry, the + attributes used to represent that information and their + organization into hierarchies to facilitate search and retrieval + of the information and the ways in which values of attributes may + be matched in attribute value and matching rule assertions. + + NOTE 1 - The schema enables the Directory system to, for example: + + - prevent the creation of subordinate entries of the wrong + object-class (e.g., a country as a subordinate of a person); + + - prevent the addition of attribute-types to an entry + inappropriate to the object-class (e.g., a serial number to a + person's entry); + + - prevent the addition of an attribute value of a syntax not + matching that defined for the attribute-type (e.g., a printable + string to a bit string). + + Formally, the Directory Schema comprises a set of: + + a) Name Form definitions that define primitive naming relations + for structural object classes; + + b) DIT Structure Rule definitions that define the names that + entries may have and the ways in which the entries may be + related to one another in the DIT; + + c) DIT Content Rule definitions that extend the specification of + allowable attributes for entries beyond those indicated by the + structural object classes of the entries; + + d) Object Class definitions that define the basic set of mandatory + and optional attributes that shall be present, and may be + present, respectively, in an entry of a given class, and which + indicate the kind of object class that is being defined; + + + + + + + + + +Zeilenga Standards Track [Page 22] + +RFC 4512 LDAP Models June 2006 + + + e) Attribute Type definitions that identify the object identifier + by which an attribute is known, its syntax, associated matching + rules, whether it is an operational attribute and if so its + type, whether it is a collective attribute, whether it is + permitted to have multiple values and whether or not it is + derived from another attribute type; + + f) Matching Rule definitions that define matching rules. + + And in LDAP: + + g) LDAP Syntax definitions that define encodings used in LDAP. + +4.1. Schema Definitions + + Schema definitions in this section are described using ABNF and rely + on the common productions specified in Section 1.2 as well as these: + + noidlen = numericoid [ LCURLY len RCURLY ] + len = number + + oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) + oidlist = oid *( WSP DOLLAR WSP oid ) + + extensions = *( SP xstring SP qdstrings ) + xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE ) + + qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) + qdescrlist = [ qdescr *( SP qdescr ) ] + qdescr = SQUOTE descr SQUOTE + + qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) + qdstringlist = [ qdstring *( SP qdstring ) ] + qdstring = SQUOTE dstring SQUOTE + dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string + + QQ = ESC %x32 %x37 ; "\27" + QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c" + + ; Any UTF-8 encoded Unicode character + ; except %x27 ("\'") and %x5C ("\") + QUTF8 = QUTF1 / UTFMB + + ; Any ASCII character except %x27 ("\'") and %x5C ("\") + QUTF1 = %x00-26 / %x28-5B / %x5D-7F + + Schema definitions in this section also share a number of common + terms. + + + +Zeilenga Standards Track [Page 23] + +RFC 4512 LDAP Models June 2006 + + + The NAME field provides a set of short names (descriptors) that are + to be used as aliases for the OID. + + The DESC field optionally allows a descriptive string to be provided + by the directory administrator and/or implementor. While + specifications may suggest a descriptive string, there is no + requirement that the suggested (or any) descriptive string be used. + + The OBSOLETE field, if present, indicates the element is not active. + + Implementors should note that future versions of this document may + expand these definitions to include additional terms. Terms whose + identifier begins with "X-" are reserved for private experiments and + are followed by <SP> and <qdstrings> tokens. + +4.1.1. Object Class Definitions + + Object Class definitions are written according to the ABNF: + + ObjectClassDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + [ SP "SUP" SP oids ] ; superior object classes + [ SP kind ] ; kind of class + [ SP "MUST" SP oids ] ; attribute types + [ SP "MAY" SP oids ] ; attribute types + extensions WSP RPAREN + + kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" + + where: + <numericoid> is object identifier assigned to this object class; + NAME <qdescrs> are short names (descriptors) identifying this + object class; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this object class is not active; + SUP <oids> specifies the direct superclasses of this object class; + the kind of object class is indicated by one of ABSTRACT, + STRUCTURAL, or AUXILIARY (the default is STRUCTURAL); + MUST and MAY specify the sets of required and allowed attribute + types, respectively; and + <extensions> describe extensions. + + + + + + + +Zeilenga Standards Track [Page 24] + +RFC 4512 LDAP Models June 2006 + + +4.1.2. Attribute Types + + Attribute Type definitions are written according to the ABNF: + + AttributeTypeDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + [ SP "SUP" SP oid ] ; supertype + [ SP "EQUALITY" SP oid ] ; equality matching rule + [ SP "ORDERING" SP oid ] ; ordering matching rule + [ SP "SUBSTR" SP oid ] ; substrings matching rule + [ SP "SYNTAX" SP noidlen ] ; value syntax + [ SP "SINGLE-VALUE" ] ; single-value + [ SP "COLLECTIVE" ] ; collective + [ SP "NO-USER-MODIFICATION" ] ; not user modifiable + [ SP "USAGE" SP usage ] ; usage + extensions WSP RPAREN ; extensions + + usage = "userApplications" / ; user + "directoryOperation" / ; directory operational + "distributedOperation" / ; DSA-shared operational + "dSAOperation" ; DSA-specific operational + + where: + <numericoid> is object identifier assigned to this attribute type; + NAME <qdescrs> are short names (descriptors) identifying this + attribute type; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this attribute type is not active; + SUP oid specifies the direct supertype of this type; + EQUALITY, ORDERING, and SUBSTR provide the oid of the equality, + ordering, and substrings matching rules, respectively; + SYNTAX identifies value syntax by object identifier and may suggest + a minimum upper bound; + SINGLE-VALUE indicates attributes of this type are restricted to a + single value; + COLLECTIVE indicates this attribute type is collective + [X.501][RFC3671]; + NO-USER-MODIFICATION indicates this attribute type is not user + modifiable; + USAGE indicates the application of this attribute type; and + <extensions> describe extensions. + + Each attribute type description must contain at least one of the SUP + or SYNTAX fields. If no SYNTAX field is provided, the attribute type + description takes its value from the supertype. + + + +Zeilenga Standards Track [Page 25] + +RFC 4512 LDAP Models June 2006 + + + If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING + fields, if not specified, take their value from the supertype. + + Usage of userApplications, the default, indicates that attributes of + this type represent user information. That is, they are user + attributes. + + A usage of directoryOperation, distributedOperation, or dSAOperation + indicates that attributes of this type represent operational and/or + administrative information. That is, they are operational + attributes. + + directoryOperation usage indicates that the attribute of this type is + a directory operational attribute. distributedOperation usage + indicates that the attribute of this type is a DSA-shared usage + operational attribute. dSAOperation usage indicates that the + attribute of this type is a DSA-specific operational attribute. + + COLLECTIVE requires usage userApplications. Use of collective + attribute types in LDAP is discussed in [RFC3671]. + + NO-USER-MODIFICATION requires an operational usage. + + Note that the <AttributeTypeDescription> does not list the matching + rules that can be used with that attribute type in an extensibleMatch + search filter [RFC4511]. This is done using the 'matchingRuleUse' + attribute described in Section 4.1.4. + + This document refines the schema description of X.501 by requiring + that the SYNTAX field in an <AttributeTypeDescription> be a string + representation of an object identifier for the LDAP string syntax + definition, with an optional indication of the suggested minimum + bound of a value of this attribute. + + A suggested minimum upper bound on the number of characters in a + value with a string-based syntax, or the number of bytes in a value + for all other syntaxes, may be indicated by appending this bound + count inside of curly braces following the syntax's OBJECT IDENTIFIER + in an Attribute Type Description. This bound is not part of the + syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests + that server implementations should allow a string to be 64 characters + long, although they may allow longer strings. Note that a single + character of the Directory String syntax may be encoded in more than + one octet since UTF-8 [RFC3629] is a variable-length encoding. + + + + + + + +Zeilenga Standards Track [Page 26] + +RFC 4512 LDAP Models June 2006 + + +4.1.3. Matching Rules + + Matching rules are used in performance of attribute value assertions, + such as in performance of a Compare operation. They are also used in + evaluating search filters, determining which individual values are to + be added or deleted during performance of a Modify operation, and in + comparing distinguished names. + + Each matching rule is identified by an object identifier (OID) and, + optionally, one or more short names (descriptors). + + Matching rule definitions are written according to the ABNF: + + MatchingRuleDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + SP "SYNTAX" SP numericoid ; assertion syntax + extensions WSP RPAREN ; extensions + + where: + <numericoid> is object identifier assigned to this matching rule; + NAME <qdescrs> are short names (descriptors) identifying this + matching rule; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this matching rule is not active; + SYNTAX identifies the assertion syntax (the syntax of the assertion + value) by object identifier; and + <extensions> describe extensions. + +4.1.4. Matching Rule Uses + + A matching rule use lists the attribute types that are suitable for + use with an extensibleMatch search filter. + + Matching rule use descriptions are written according to the following + ABNF: + + MatchingRuleUseDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + SP "APPLIES" SP oids ; attribute types + extensions WSP RPAREN ; extensions + + + + + +Zeilenga Standards Track [Page 27] + +RFC 4512 LDAP Models June 2006 + + + where: + <numericoid> is the object identifier of the matching rule + associated with this matching rule use description; + NAME <qdescrs> are short names (descriptors) identifying this + matching rule use; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this matching rule use is not active; + APPLIES provides a list of attribute types the matching rule + applies to; and + <extensions> describe extensions. + +4.1.5. LDAP Syntaxes + + LDAP Syntaxes of (attribute and assertion) values are described in + terms of ASN.1 [X.680] and, optionally, have an octet string encoding + known as the LDAP-specific encoding. Commonly, the LDAP-specific + encoding is constrained to a string of Unicode [Unicode] characters + in UTF-8 [RFC3629] form. + + Each LDAP syntax is identified by an object identifier (OID). + + LDAP syntax definitions are written according to the ABNF: + + SyntaxDescription = LPAREN WSP + numericoid ; object identifier + [ SP "DESC" SP qdstring ] ; description + extensions WSP RPAREN ; extensions + + where: + <numericoid> is the object identifier assigned to this LDAP syntax; + DESC <qdstring> is a short descriptive string; and + <extensions> describe extensions. + +4.1.6. DIT Content Rules + + A DIT content rule is a "rule governing the content of entries of a + particular structural object class" [X.501]. + + For DIT entries of a particular structural object class, a DIT + content rule specifies which auxiliary object classes the entries are + allowed to belong to and which additional attributes (by type) are + required, allowed, or not allowed to appear in the entries. + + The list of precluded attributes cannot include any attribute listed + as mandatory in the rule, the structural object class, or any of the + allowed auxiliary object classes. + + + + + +Zeilenga Standards Track [Page 28] + +RFC 4512 LDAP Models June 2006 + + + Each content rule is identified by the object identifier, as well as + any short names (descriptors), of the structural object class it + applies to. + + An entry may only belong to auxiliary object classes listed in the + governing content rule. + + An entry must contain all attributes required by the object classes + the entry belongs to as well as all attributes required by the + governing content rule. + + An entry may contain any non-precluded attributes allowed by the + object classes the entry belongs to as well as all attributes allowed + by the governing content rule. + + An entry cannot include any attribute precluded by the governing + content rule. + + An entry is governed by (if present and active in the subschema) the + DIT content rule that applies to the structural object class of the + entry (see Section 2.4.2). If no active rule is present for the + entry's structural object class, the entry's content is governed by + the structural object class (and possibly other aspects of user and + system schema). DIT content rules for superclasses of the structural + object class of an entry are not applicable to that entry. + + DIT content rule descriptions are written according to the ABNF: + + DITContentRuleDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + [ SP "AUX" SP oids ] ; auxiliary object classes + [ SP "MUST" SP oids ] ; attribute types + [ SP "MAY" SP oids ] ; attribute types + [ SP "NOT" SP oids ] ; attribute types + extensions WSP RPAREN ; extensions + + where: + <numericoid> is the object identifier of the structural object + class associated with this DIT content rule; + NAME <qdescrs> are short names (descriptors) identifying this DIT + content rule; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this DIT content rule use is not active; + AUX specifies a list of auxiliary object classes that entries + subject to this DIT content rule may belong to; + + + +Zeilenga Standards Track [Page 29] + +RFC 4512 LDAP Models June 2006 + + + MUST, MAY, and NOT specify lists of attribute types that are + required, allowed, or precluded, respectively, from appearing + in entries subject to this DIT content rule; and + <extensions> describe extensions. + +4.1.7. DIT Structure Rules and Name Forms + + It is sometimes desirable to regulate where object and alias entries + can be placed in the DIT and how they can be named based upon their + structural object class. + +4.1.7.1. DIT Structure Rules + + A DIT structure rule is a "rule governing the structure of the DIT by + specifying a permitted superior to subordinate entry relationship. A + structure rule relates a name form, and therefore a structural object + class, to superior structure rules. This permits entries of the + structural object class identified by the name form to exist in the + DIT as subordinates to entries governed by the indicated superior + structure rules" [X.501]. + + DIT structure rule descriptions are written according to the ABNF: + + DITStructureRuleDescription = LPAREN WSP + ruleid ; rule identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + SP "FORM" SP oid ; NameForm + [ SP "SUP" ruleids ] ; superior rules + extensions WSP RPAREN ; extensions + + ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) + ruleidlist = ruleid *( SP ruleid ) + ruleid = number + + where: + <ruleid> is the rule identifier of this DIT structure rule; + NAME <qdescrs> are short names (descriptors) identifying this DIT + structure rule; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this DIT structure rule use is not active; + FORM is specifies the name form associated with this DIT structure + rule; + SUP identifies superior rules (by rule id); and + <extensions> describe extensions. + + + + + +Zeilenga Standards Track [Page 30] + +RFC 4512 LDAP Models June 2006 + + + If no superior rules are identified, the DIT structure rule applies + to an autonomous administrative point (e.g., the root vertex of the + subtree controlled by the subschema) [X.501]. + +4.1.7.2. Name Forms + + A name form "specifies a permissible RDN for entries of a particular + structural object class. A name form identifies a named object class + and one or more attribute types to be used for naming (i.e., for the + RDN). Name forms are primitive pieces of specification used in the + definition of DIT structure rules" [X.501]. + + Each name form indicates the structural object class to be named, a + set of required attribute types, and a set of allowed attribute + types. A particular attribute type cannot be in both sets. + + Entries governed by the form must be named using a value from each + required attribute type and zero or more values from the allowed + attribute types. + + Each name form is identified by an object identifier (OID) and, + optionally, one or more short names (descriptors). + + Name form descriptions are written according to the ABNF: + + NameFormDescription = LPAREN WSP + numericoid ; object identifier + [ SP "NAME" SP qdescrs ] ; short names (descriptors) + [ SP "DESC" SP qdstring ] ; description + [ SP "OBSOLETE" ] ; not active + SP "OC" SP oid ; structural object class + SP "MUST" SP oids ; attribute types + [ SP "MAY" SP oids ] ; attribute types + extensions WSP RPAREN ; extensions + + where: + <numericoid> is object identifier that identifies this name form; + NAME <qdescrs> are short names (descriptors) identifying this name + form; + DESC <qdstring> is a short descriptive string; + OBSOLETE indicates this name form is not active; + OC identifies the structural object class this rule applies to, + MUST and MAY specify the sets of required and allowed, + respectively, naming attributes for this name form; and + <extensions> describe extensions. + + All attribute types in the required ("MUST") and allowed ("MAY") + lists shall be different. + + + +Zeilenga Standards Track [Page 31] + +RFC 4512 LDAP Models June 2006 + + +4.2. Subschema Subentries + + Subschema (sub)entries are used for administering information about + the directory schema. A single subschema (sub)entry contains all + schema definitions (see Section 4.1) used by entries in a particular + part of the directory tree. + + Servers that follow X.500(93) models SHOULD implement subschema using + the X.500 subschema mechanisms (as detailed in Section 12 of + [X.501]), so these are not ordinary object entries but subentries + (see Section 3.2). LDAP clients SHOULD NOT assume that servers + implement any of the other aspects of X.500 subschema. + + Servers MAY allow subschema modification. Procedures for subschema + modification are discussed in Section 14.5 of [X.501]. + + A server that masters entries and permits clients to modify these + entries SHALL implement and provide access to these subschema + (sub)entries including providing a 'subschemaSubentry' attribute in + each modifiable entry. This is so clients may discover the + attributes and object classes that are permitted to be present. It + is strongly RECOMMENDED that all other servers implement this as + well. + + The value of the 'subschemaSubentry' attribute is the name of the + subschema (sub)entry holding the subschema controlling the entry. + + ( 2.5.18.10 NAME 'subschemaSubentry' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The 'distinguishedNameMatch' matching rule and the DistinguishedName + (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. + + Subschema is held in (sub)entries belonging to the subschema + auxiliary object class. + + ( 2.5.20.1 NAME 'subschema' AUXILIARY + MAY ( dITStructureRules $ nameForms $ ditContentRules $ + objectClasses $ attributeTypes $ matchingRules $ + matchingRuleUse ) ) + + The 'ldapSyntaxes' operational attribute may also be present in + subschema entries. + + + + + +Zeilenga Standards Track [Page 32] + +RFC 4512 LDAP Models June 2006 + + + Servers MAY provide additional attributes (described in other + documents) in subschema (sub)entries. + + Servers SHOULD provide the attributes 'createTimestamp' and + 'modifyTimestamp' in subschema (sub)entries, in order to allow + clients to maintain their caches of schema information. + + The following subsections provide attribute type definitions for each + of schema definition attribute types. + +4.2.1. 'objectClasses' + + This attribute holds definitions of object classes. + + ( 2.5.21.6 NAME 'objectClasses' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are + defined in [RFC4517]. + +4.2.2. 'attributeTypes' + + This attribute holds definitions of attribute types. + + ( 2.5.21.5 NAME 'attributeTypes' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are + defined in [RFC4517]. + +4.2.3. 'matchingRules' + + This attribute holds definitions of matching rules. + + ( 2.5.21.4 NAME 'matchingRules' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are + defined in [RFC4517]. + + + +Zeilenga Standards Track [Page 33] + +RFC 4512 LDAP Models June 2006 + + +4.2.4 'matchingRuleUse' + + This attribute holds definitions of matching rule uses. + + ( 2.5.21.8 NAME 'matchingRuleUse' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are + defined in [RFC4517]. + +4.2.5. 'ldapSyntaxes' + + This attribute holds definitions of LDAP syntaxes. + + ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined + in [RFC4517]. + +4.2.6. 'dITContentRules' + + This attribute lists DIT Content Rules that are present in the + subschema. + + ( 2.5.21.2 NAME 'dITContentRules' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are + defined in [RFC4517]. + + + + + + + + + + + + +Zeilenga Standards Track [Page 34] + +RFC 4512 LDAP Models June 2006 + + +4.2.7. 'dITStructureRules' + + This attribute lists DIT Structure Rules that are present in the + subschema. + + ( 2.5.21.1 NAME 'dITStructureRules' + EQUALITY integerFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 + USAGE directoryOperation ) + + The 'integerFirstComponentMatch' matching rule and the + DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax + are defined in [RFC4517]. + +4.2.8 'nameForms' + + This attribute lists Name Forms that are in force. + + ( 2.5.21.7 NAME 'nameForms' + EQUALITY objectIdentifierFirstComponentMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 + USAGE directoryOperation ) + + The 'objectIdentifierFirstComponentMatch' matching rule and the + NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are + defined in [RFC4517]. + +4.3. 'extensibleObject' object class + + The 'extensibleObject' auxiliary object class allows entries that + belong to it to hold any user attribute. The set of allowed + attribute types of this object class is implicitly the set of all + attribute types of userApplications usage. + + ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' + SUP top AUXILIARY ) + + The mandatory attributes of the other object classes of this entry + are still required to be present, and any precluded attributes are + still not allowed to be present. + +4.4. Subschema Discovery + + To discover the DN of the subschema (sub)entry holding the subschema + controlling a particular entry, a client reads that entry's + 'subschemaSubentry' operational attribute. To read schema attributes + from the subschema (sub)entry, clients MUST issue a Search operation + [RFC4511] where baseObject is the DN of the subschema (sub)entry, + + + +Zeilenga Standards Track [Page 35] + +RFC 4512 LDAP Models June 2006 + + + scope is baseObject, filter is "(objectClass=subschema)" [RFC4515], + and the attributes field lists the names of the desired schema + attributes (as they are operational). Note: the + "(objectClass=subschema)" filter allows LDAP servers that gateway to + X.500 to detect that subentry information is being requested. + + Clients SHOULD NOT assume that a published subschema is complete, + that the server supports all of the schema elements it publishes, or + that the server does not support an unpublished element. + +5. DSA (Server) Informational Model + + The LDAP protocol assumes there are one or more servers that jointly + provide access to a Directory Information Tree (DIT). The server + holding the original information is called the "master" (for that + information). Servers that hold copies of the original information + are referred to as "shadowing" or "caching" servers. + + + As defined in [X.501]: + + context prefix: The sequence of RDNs leading from the Root of the + DIT to the initial vertex of a naming context; corresponds to + the distinguished name of that vertex. + + naming context: A subtree of entries held in a single master DSA. + + That is, a naming context is the largest collection of entries, + starting at an entry that is mastered by a particular server, and + including all its subordinates and their subordinates, down to the + entries that are mastered by different servers. The context prefix + is the name of the initial entry. + + The root of the DIT is a DSA-specific Entry (DSE) and not part of any + naming context (or any subtree); each server has different attribute + values in the root DSE. + +5.1. Server-Specific Data Requirements + + An LDAP server SHALL provide information about itself and other + information that is specific to each server. This is represented as + a group of attributes located in the root DSE, which is named with + the DN with zero RDNs (whose [RFC4514] representation is as the + zero-length string). + + These attributes are retrievable, subject to access control and other + restrictions, if a client performs a Search operation [RFC4511] with + an empty baseObject, scope of baseObject, the filter + + + +Zeilenga Standards Track [Page 36] + +RFC 4512 LDAP Models June 2006 + + + "(objectClass=*)" [RFC4515], and the attributes field listing the + names of the desired attributes. It is noted that root DSE + attributes are operational and, like other operational attributes, + are not returned in search requests unless requested by name. + + The root DSE SHALL NOT be included if the client performs a subtree + search starting from the root. + + Servers may allow clients to modify attributes of the root DSE, where + appropriate. + + The following attributes of the root DSE are defined below. + Additional attributes may be defined in other documents. + + - altServer: alternative servers; + + - namingContexts: naming contexts; + + - supportedControl: recognized LDAP controls; + + - supportedExtension: recognized LDAP extended operations; + + - supportedFeatures: recognized LDAP features; + + - supportedLDAPVersion: LDAP versions supported; and + + - supportedSASLMechanisms: recognized Simple Authentication and + Security Layers (SASL) [RFC4422] mechanisms. + + The values provided for these attributes may depend on session- + specific and other factors. For example, a server supporting the + SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's + identity has been established by a lower level. See [RFC4513]. + + The root DSE may also include a 'subschemaSubentry' attribute. If it + does, the attribute refers to the subschema (sub)entry holding the + schema controlling the root DSE. Clients SHOULD NOT assume that this + subschema (sub)entry controls other entries held by the server. + General subschema discovery procedures are provided in Section 4.4. + + + + + + + + + + + + +Zeilenga Standards Track [Page 37] + +RFC 4512 LDAP Models June 2006 + + +5.1.1. 'altServer' + + The 'altServer' attribute lists URIs referring to alternative servers + that may be contacted when this server becomes unavailable. URIs for + servers implementing the LDAP are written according to [RFC4516]. + Other kinds of URIs may be provided. If the server does not know of + any other servers that could be used, this attribute will be absent. + Clients may cache this information in case their preferred server + later becomes unavailable. + + ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + USAGE dSAOperation ) + + The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in + [RFC4517]. + +5.1.2. 'namingContexts' + + The 'namingContexts' attribute lists the context prefixes of the + naming contexts the server masters or shadows (in part or in whole). + If the server is a first-level DSA [X.501], it should list (in + addition) an empty string (indicating the root of the DIT). If the + server does not master or shadow any information (e.g., it is an LDAP + gateway to a public X.500 directory) this attribute will be absent. + If the server believes it masters or shadows the entire directory, + the attribute will have a single value, and that value will be the + empty string (indicating the root of the DIT). + + This attribute may be used, for example, to select a suitable entry + name for subsequent operations with this server. + + ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + USAGE dSAOperation ) + + The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is + defined in [RFC4517]. + +5.1.3. 'supportedControl' + + The 'supportedControl' attribute lists object identifiers identifying + the request controls [RFC4511] the server supports. If the server + does not support any request controls, this attribute will be absent. + Object identifiers identifying response controls need not be listed. + + Procedures for registering object identifiers used to discovery of + protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. + + + +Zeilenga Standards Track [Page 38] + +RFC 4512 LDAP Models June 2006 + + + ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE dSAOperation ) + + The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is + defined in [RFC4517]. + +5.1.4. 'supportedExtension' + + The 'supportedExtension' attribute lists object identifiers + identifying the extended operations [RFC4511] that the server + supports. If the server does not support any extended operations, + this attribute will be absent. + + An extended operation generally consists of an extended request and + an extended response but may also include other protocol data units + (such as intermediate responses). The object identifier assigned to + the extended request is used to identify the extended operation. + Other object identifiers used in the extended operation need not be + listed as values of this attribute. + + Procedures for registering object identifiers used to discovery of + protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. + + ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE dSAOperation ) + + The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is + defined in [RFC4517]. + +5.1.5. 'supportedFeatures' + + The 'supportedFeatures' attribute lists object identifiers + identifying elective features that the server supports. If the + server does not support any discoverable elective features, this + attribute will be absent. + + ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + USAGE dSAOperation ) + + Procedures for registering object identifiers used to discovery of + protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. + + The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and + objectIdentifierMatch matching rule are defined in [RFC4517]. + + + +Zeilenga Standards Track [Page 39] + +RFC 4512 LDAP Models June 2006 + + +5.1.6. 'supportedLDAPVersion' + + The 'supportedLDAPVersion' attribute lists the versions of LDAP that + the server supports. + + ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + USAGE dSAOperation ) + + The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in + [RFC4517]. + +5.1.7. 'supportedSASLMechanisms' + + The 'supportedSASLMechanisms' attribute lists the SASL mechanisms + [RFC4422] that the server recognizes and/or supports [RFC4513]. The + contents of this attribute may depend on the current session state. + If the server does not support any SASL mechanisms, this attribute + will not be present. + + ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + USAGE dSAOperation ) + + The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is + defined in [RFC4517]. + +6. Other Considerations + +6.1. Preservation of User Information + + Syntaxes may be defined that have specific value and/or value form + (representation) preservation requirements. For example, a syntax + containing digitally signed data can mandate that the server preserve + both the value and form of value presented to ensure that the + signature is not invalidated. + + Where such requirements have not been explicitly stated, servers + SHOULD preserve the value of user information but MAY return the + value in a different form. And where a server is unable (or + unwilling) to preserve the value of user information, the server + SHALL ensure that an equivalent value (per Section 2.3) is returned. + + + + + + + + + +Zeilenga Standards Track [Page 40] + +RFC 4512 LDAP Models June 2006 + + +6.2. Short Names + + Short names, also known as descriptors, are used as more readable + aliases for object identifiers and are used to identify various + schema elements. However, it is not expected that LDAP + implementations with human user interface would display these short + names (or the object identifiers they refer to) to the user. + Instead, they would most likely be performing translations (such as + expressing the short name in one of the local national languages). + For example, the short name "st" (stateOrProvinceName) might be + displayed to a German-speaking user as "Land". + + The same short name might have different meaning in different + subschemas, and, within a particular subschema, the same short name + might refer to different object identifiers each identifying a + different kind of schema element. + + Implementations MUST be prepared that the same short name might be + used in a subschema to refer to the different kinds of schema + elements. That is, there might be an object class 'x-fubar' and an + attribute type 'x-fubar' in a subschema. + + Implementations MUST be prepared that the same short name might be + used in the different subschemas to refer to the different schema + elements. That is, there might be two matching rules 'x-fubar', each + in different subschemas. + + Procedures for registering short names (descriptors) are detailed in + BCP 64, RFC 4520 [RFC4520]. + +6.3. Cache and Shadowing + + Some servers may hold cache or shadow copies of entries, which can be + used to answer search and comparison queries, but will return + referrals or contact other servers if modification operations are + requested. Servers that perform shadowing or caching MUST ensure + that they do not violate any access control constraints placed on the + data by the originating server. + + + + + + + + + + + + + +Zeilenga Standards Track [Page 41] + +RFC 4512 LDAP Models June 2006 + + +7. Implementation Guidelines + +7.1. Server Guidelines + + Servers MUST recognize all names of attribute types and object + classes defined in this document but, unless stated otherwise, need + not support the associated functionality. Servers SHOULD recognize + all the names of attribute types and object classes defined in + Section 3 and 4, respectively, of [RFC4519]. + + Servers MUST ensure that entries conform to user and system schema + rules or other data model constraints. + + Servers MAY support DIT Content Rules. Servers MAY support DIT + Structure Rules and Name Forms. + + Servers MAY support alias entries. + + Servers MAY support the 'extensibleObject' object class. + + Servers MAY support subentries. If so, they MUST do so in accordance + with [RFC3672]. Servers that do not support subentries SHOULD use + object entries to mimic subentries as detailed in Section 3.2. + + Servers MAY implement additional schema elements. Servers SHOULD + provide definitions of all schema elements they support in subschema + (sub)entries. + +7.2. Client Guidelines + + In the absence of prior agreements with servers, clients SHOULD NOT + assume that servers support any particular schema elements beyond + those referenced in Section 7.1. The client can retrieve subschema + information as described in Section 4.4. + + Clients MUST NOT display or attempt to decode a value as ASN.1 if the + value's syntax is not known. Clients MUST NOT assume the LDAP- + specific string encoding is restricted to a UTF-8 encoded string of + Unicode characters or any particular subset of Unicode (such as a + printable subset) unless such restriction is explicitly stated. + Clients SHOULD NOT send attribute values in a request that are not + valid according to the syntax defined for the attributes. + + + + + + + + + +Zeilenga Standards Track [Page 42] + +RFC 4512 LDAP Models June 2006 + + +8. Security Considerations + + Attributes of directory entries are used to provide descriptive + information about the real-world objects they represent, which can be + people, organizations, or devices. Most countries have privacy laws + regarding the publication of information about people. + + General security considerations for accessing directory information + with LDAP are discussed in [RFC4511] and [RFC4513]. + +9. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry as indicated in the following template: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comment + Object Identifier: see comment + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: see comment + Specification: RFC 4512 + Author/Change Controller: IESG + Comments: + + The following descriptors (short names) has been added to + the registry. + + NAME Type OID + ------------------------ ---- ----------------- + governingStructureRule A 2.5.21.10 + structuralObjectClass A 2.5.21.9 + + The following descriptors (short names) have been updated to + refer to this RFC. + + NAME Type OID + ------------------------ ---- ----------------- + alias O 2.5.6.1 + aliasedObjectName A 2.5.4.1 + altServer A 1.3.6.1.4.1.1466.101.120.6 + attributeTypes A 2.5.21.5 + createTimestamp A 2.5.18.1 + creatorsName A 2.5.18.3 + dITContentRules A 2.5.21.2 + dITStructureRules A 2.5.21.1 + extensibleObject O 1.3.6.1.4.1.1466.101.120.111 + ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 + + + +Zeilenga Standards Track [Page 43] + +RFC 4512 LDAP Models June 2006 + + + matchingRuleUse A 2.5.21.8 + matchingRules A 2.5.21.4 + modifiersName A 2.5.18.4 + modifyTimestamp A 2.5.18.2 + nameForms A 2.5.21.7 + namingContexts A 1.3.6.1.4.1.1466.101.120.5 + objectClass A 2.5.4.0 + objectClasses A 2.5.21.6 + subschema O 2.5.20.1 + subschemaSubentry A 2.5.18.10 + supportedControl A 1.3.6.1.4.1.1466.101.120.13 + supportedExtension A 1.3.6.1.4.1.1466.101.120.7 + supportedFeatures A 1.3.6.1.4.1.4203.1.3.5 + supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 + supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 + top O 2.5.6.0 + +10. Acknowledgements + + This document is based in part on RFC 2251 by M. Wahl, T. Howes, and + S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and + RFC 2556 by M. Wahl, all products of the IETF Access, Searching and + Indexing of Directories (ASID) Working Group. This document is also + based in part on "The Directory: Models" [X.501], a product of the + International Telephone Union (ITU). Additional text was borrowed + from RFC 2253 by M. Wahl, T. Howes, and S. Kille. + + This document is a product of the IETF LDAP Revision (LDAPBIS) + Working Group. + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 44] + +RFC 4512 LDAP Models June 2006 + + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight + Directory Access Protocol (LDAP)", RFC 3671, December + 2003. + + [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory + Access Protocol (LDAP)", RFC 3672, December 2003. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + June 2006. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): String Representation of Search + Filters", RFC 4515, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + + +Zeilenga Standards Track [Page 45] + +RFC 4512 LDAP Models June 2006 + + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [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.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.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(2002) (also ISO/IEC 8824-1:2002). + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 46] + +RFC 4512 LDAP Models June 2006 + + +Appendix A. Changes + + This appendix is non-normative. + + This document amounts to nearly a complete rewrite of portions of RFC + 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve + overall clarity of technical specification. This appendix provides a + summary of substantive changes made to the portions of these + documents incorporated into this document. Readers should consult + [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of + remaining portions of these documents. + +A.1. Changes to RFC 2251 + + This document incorporates from RFC 2251, Sections 3.2 and 3.4, and + portions of Sections 4 and 6 as summarized below. + +A.1.1. Section 3.2 of RFC 2251 + + Section 3.2 of RFC 2251 provided a brief introduction to the X.500 + data model, as used by LDAP. The previous specification relied on + [X.501] but lacked clarity in how X.500 models are adapted for use by + LDAP. This document describes the X.500 data models, as used by + LDAP, in greater detail, especially in areas where adaptation is + needed. + + Section 3.2.1 of RFC 2251 described an attribute as "a type with one + or more associated values". In LDAP, an attribute is better + described as an attribute description, a type with zero or more + options, and one or more associated values. + + Section 3.2.2 of RFC 2251 mandated that subschema subentries contain + objectClasses and attributeTypes attributes, yet X.500(93) treats + these attributes as optional. While generally all implementations + that support X.500(93) subschema mechanisms will provide both of + these attributes, it is not absolutely required for interoperability + that all servers do. The mandate was removed for consistency with + X.500(93). The subschema discovery mechanism was also clarified to + indicate that subschema controlling an entry is obtained by reading + the (sub)entry referred to by that entry's 'subschemaSubentry' + attribute. + + + + + + + + + + +Zeilenga Standards Track [Page 47] + +RFC 4512 LDAP Models June 2006 + + +A.1.2. Section 3.4 of RFC 2251 + + Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". + This material, with changes, was incorporated in Section 5.1 of this + document. + + Changes: + + - Clarify that attributes of the root DSE are subject to "other + restrictions" in addition to access controls. + + - Clarify that only recognized extended requests need to be + enumerated 'supportedExtension'. + + - Clarify that only recognized request controls need to be enumerated + 'supportedControl'. + + - Clarify that root DSE attributes are operational and, like other + operational attributes, will not be returned in search requests + unless requested by name. + + - Clarify that not all root DSE attributes are user modifiable. + + - Remove inconsistent text regarding handling of the + 'subschemaSubentry' attribute within the root DSE. The previous + specification stated that the 'subschemaSubentry' attribute held in + the root DSE referred to "subschema entries (or subentries) known + by this server". This is inconsistent with the attribute's + intended use as well as its formal definition as a single valued + attribute [X.501]. It is also noted that a simple (possibly + incomplete) list of subschema (sub)entries is not terribly useful. + This document (in Section 5.1) specifies that the + 'subschemaSubentry' attribute of the root DSE refers to the + subschema controlling the root DSE. It is noted that the general + subschema discovery mechanism remains available (see Section 4.4 of + this document). + +A.1.3. Section 4 of RFC 2251 + + Portions of Section 4 of RFC 2251 detailing aspects of the + information model used by LDAP were incorporated in this document, + including: + + - Restriction of distinguished values to attributes whose + descriptions have no options (from Section 4.1.3); + + + + + + +Zeilenga Standards Track [Page 48] + +RFC 4512 LDAP Models June 2006 + + + - Data model aspects of Attribute Types (from Section 4.1.4), + Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), + Matching Rule Identifier (from 4.1.9); and + + - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7). + + Clarifications to these portions include: + + - Subtyping and AttributeDescriptions with options. + +A.1.4. Section 6 of RFC 2251 + + The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 + where incorporated into this document. + +A.2. Changes to RFC 2252 + + This document incorporates Sections 4, 5, and 7 from RFC 2252. + +A.2.1. Section 4 of RFC 2252 + + The specification was updated to use Augmented BNF [RFC4234]. The + string representation of an OBJECT IDENTIFIER was tightened to + disallow leading zeros as described in RFC 2252. + + The <descr> syntax was changed to disallow semicolon (U+003B) + characters in order to appear to be consistent its natural language + specification "descr is the syntactic representation of an object + descriptor, which consists of letters and digits, starting with a + letter". In a related change, the statement "an AttributeDescription + can be used as the value in a NAME part of an + AttributeTypeDescription" was deleted. RFC 2252 provided no + specification of the semantics of attribute options appearing in NAME + fields. + + RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred + over the <numericoid> form. However, <descr> form can be ambiguous. + To address this issue, the imperative was replaced with a statement + (in Section 1.4) that while the <descr> form is generally preferred, + <numericoid> should be used where an unambiguous <descr> is not + available. Additionally, an expanded discussion of descriptor issues + is in Section 6.2 ("Short Names"). + + The ABNF for a quoted string (qdstring) was updated to reflect + support for the escaping mechanism described in Section 4.3 of RFC + 2252. + + + + + +Zeilenga Standards Track [Page 49] + +RFC 4512 LDAP Models June 2006 + + +A.2.2. Section 5 of RFC 2252 + + Definitions of operational attributes provided in Section 5 of RFC + 2252 where incorporated into this document. + + The 'namingContexts' description was clarified. A first-level DSA + should publish, in addition to other values, "" indicating the root + of the DIT. + + The 'altServer' description was clarified. It may hold any URI. + + The 'supportedExtension' description was clarified. A server need + only list the OBJECT IDENTIFIERs associated with the extended + requests of the extended operations it recognizes. + + The 'supportedControl' description was clarified. A server need only + list the OBJECT IDENTIFIERs associated with the request controls it + recognizes. + + Descriptions for the 'structuralObjectClass' and + 'governingStructureRule' operational attribute types were added. + + The attribute definition of 'subschemaSubentry' was corrected to list + the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order. + +A.2.3. Section 7 of RFC 2252 + + Section 7 of RFC 2252 provides definitions of the 'subschema' and + 'extensibleObject' object classes. These definitions where + integrated into Section 4.2 and Section 4.3 of this document, + respectively. Section 7 of RFC 2252 also contained the object class + implementation requirement. This was incorporated into Section 7 of + this document. + + The specification of 'extensibleObject' was clarified regarding how + it interacts with precluded attributes. + +A.3. Changes to RFC 2256 + + This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC + 2256. + + Section 5.1 of RFC 2256 provided the definition of the 'objectClass' + attribute type. This was integrated into Section 2.4.1 of this + document. The statement "One of the values is either 'top' or + 'alias'" was replaced with statement that one of the values is 'top' + as entries belonging to 'alias' also belong to 'top'. + + + + +Zeilenga Standards Track [Page 50] + +RFC 4512 LDAP Models June 2006 + + + Section 5.2 of RFC 2256 provided the definition of the + 'aliasedObjectName' attribute type. This was integrated into Section + 2.6.2 of this document. + + Section 7.1 of RFC 2256 provided the definition of the 'top' object + class. This was integrated into Section 2.4.1 of this document. + + Section 7.2 of RFC 2256 provided the definition of the 'alias' object + class. This was integrated into Section 2.6.1 of this document. + +A.4. Changes to RFC 3674 + + This document made no substantive change to the 'supportedFeatures' + technical specification provided in RFC 3674. + +Editor's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 51] + +RFC 4512 LDAP Models June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 52] + diff --git a/source4/ldap_server/devdocs/rfc4513.txt b/source4/ldap_server/devdocs/rfc4513.txt new file mode 100644 index 0000000000..7e6e7eb4bd --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4513.txt @@ -0,0 +1,1907 @@ + + + + + + +Network Working Group R. Harrison, Ed. +Request for Comments: 4513 Novell, Inc. +Obsoletes: 2251, 2829, 2830 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Authentication Methods and Security Mechanisms + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes authentication methods and security + mechanisms of the Lightweight Directory Access Protocol (LDAP). 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 the specification's road map), + obsoletes RFC 2251, RFC 2829, and RFC 2830. + + + + + + + + + + + +Harrison Standards Track [Page 1] + +RFC 4513 LDAP Authentication Methods June 2006 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Relationship to Other Documents ............................6 + 1.2. Conventions ................................................6 + 2. Implementation Requirements .....................................7 + 3. StartTLS Operation ..............................................8 + 3.1. TLS Establishment Procedures ..............................8 + 3.1.1. StartTLS Request Sequencing .........................8 + 3.1.2. Client Certificate ..................................9 + 3.1.3. Server Identity Check ...............................9 + 3.1.3.1. Comparison of DNS Names ...................10 + 3.1.3.2. Comparison of IP Addresses ................11 + 3.1.3.3. Comparison of Other subjectName Types .....11 + 3.1.4. Discovery of Resultant Security Level ..............11 + 3.1.5. Refresh of Server Capabilities Information .........11 + 3.2. Effect of TLS on Authorization State .....................12 + 3.3. TLS Ciphersuites ..........................................12 + 4. Authorization State ............................................13 + 5. Bind Operation .................................................14 + 5.1. Simple Authentication Method ..............................14 + 5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14 + 5.1.2. Unauthenticated Authentication Mechanism of + Simple Bind ........................................14 + 5.1.3. Name/Password Authentication Mechanism of + Simple Bind ........................................15 + 5.2. SASL Authentication Method ................................16 + 5.2.1. SASL Protocol Profile ..............................16 + 5.2.1.1. SASL Service Name for LDAP ................16 + 5.2.1.2. SASL Authentication Initiation and + Protocol Exchange .........................16 + 5.2.1.3. Optional Fields ...........................17 + 5.2.1.4. Octet Where Negotiated Security + Layers Take Effect ........................18 + 5.2.1.5. Determination of Supported SASL + Mechanisms ................................18 + 5.2.1.6. Rules for Using SASL Layers ...............19 + 5.2.1.7. Support for Multiple Authentications ......19 + 5.2.1.8. SASL Authorization Identities .............19 + 5.2.2. SASL Semantics within LDAP .........................20 + 5.2.3. SASL EXTERNAL Authentication Mechanism .............20 + 5.2.3.1. Implicit Assertion ........................21 + 5.2.3.2. Explicit Assertion ........................21 + 6. Security Considerations ........................................21 + 6.1. General LDAP Security Considerations ......................21 + 6.2. StartTLS Security Considerations ..........................22 + 6.3. Bind Operation Security Considerations ....................23 + 6.3.1. Unauthenticated Mechanism Security Considerations ..23 + + + +Harrison Standards Track [Page 2] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 6.3.2. Name/Password Mechanism Security Considerations ....23 + 6.3.3. Password-Related Security Considerations ...........23 + 6.3.4. Hashed Password Security Considerations ............24 + 6.4. SASL Security Considerations ..............................24 + 6.5. Related Security Considerations ...........................25 + 7. IANA Considerations ............................................25 + 8. Acknowledgements ...............................................25 + 9. Normative References ...........................................26 + 10. Informative References ........................................27 + Appendix A. Authentication and Authorization Concepts .............28 + A.1. Access Control Policy .....................................28 + A.2. Access Control Factors ....................................28 + A.3. Authentication, Credentials, Identity .....................28 + A.4. Authorization Identity ....................................29 + Appendix B. Summary of Changes ....................................29 + B.1. Changes Made to RFC 2251 ..................................30 + B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30 + B.1.2. Section 4.2.2 ("Authentication and Other Security + Services") .........................................30 + B.2. Changes Made to RFC 2829 ..................................30 + B.2.1. Section 4 ("Required security mechanisms") .........30 + B.2.2. Section 5.1 ("Anonymous authentication + procedure") ........................................31 + B.2.3. Section 6 ("Password-based authentication") ........31 + B.2.4. Section 6.1 ("Digest authentication") ..............31 + B.2.5. Section 6.2 ("'simple' authentication choice under + TLS encryption") ...................................31 + B.2.6. Section 6.3 ("Other authentication choices with + TLS") ..............................................31 + B.2.7. Section 7.1 ("Certificate-based authentication + with TLS") .........................................31 + B.2.8. Section 8 ("Other mechanisms") .....................32 + B.2.9. Section 9 ("Authorization Identity") ...............32 + B.2.10. Section 10 ("TLS Ciphersuites") ...................32 + B.3. Changes Made to RFC 2830 ..................................32 + B.3.1. Section 3.6 ("Server Identity Check") ..............32 + B.3.2. Section 3.7 ("Refresh of Server Capabilities + Information") ......................................33 + B.3.3. Section 5 ("Effects of TLS on a Client's + Authorization Identity") ...........................33 + B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33 + + + + + + + + + + +Harrison Standards Track [Page 3] + +RFC 4513 LDAP Authentication Methods June 2006 + + +1. Introduction + + The Lightweight Directory Access Protocol (LDAP) [RFC4510] 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), and (8) are active attacks. Threats + (2) and (3) are passive attacks. + + + + + + +Harrison Standards Track [Page 4] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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: + + (1) Authentication by means of the Bind operation. The Bind + operation provides a simple method that 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 layer 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][RFC4512], in string form [RFC4514], 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. + + + + +Harrison Standards Track [Page 5] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 + [RFC4510]. + + This document, together with [RFC4510], [RFC4511], and [RFC4512], + 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 [RFC4511]. 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 that 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. + + + + +Harrison Standards Track [Page 6] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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. + +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 they 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 StartTLS operation (Section + 3). (Other servers MUST support TLS per the second paragraph of this + section.) + + + + + + + + +Harrison Standards Track [Page 7] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 [RFC4511] provides the ability to establish TLS + [RFC4346] in an LDAP session. + + The goals of using the 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 + + 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 [RFC4511], 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 + + + + + +Harrison Standards Track [Page 8] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 + + 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 + + + +Harrison Standards Track [Page 9] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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) [RFC4519] value in the leaf Relative + Distinguished Name (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. + +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). + + + + + +Harrison Standards Track [Page 10] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 + + 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 [RFC4511], 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 that it + obtained prior to the initiation of the TLS negotiation and that it + did not obtain 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. + + + + + +Harrison Standards Track [Page 11] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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. + + - 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 they are + not, the TLS layer should be closed. + + + + + + +Harrison Standards Track [Page 12] + +RFC 4513 LDAP Authentication Methods June 2006 + + +4. Authorization State + + Every LDAP session has an associated authorization state. This state + is comprised of numerous factors such as what (if any) authentication + 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 that + 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 [RFC4511] 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. + + 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. + + + + + + +Harrison Standards Track [Page 13] + +RFC 4513 LDAP Authentication Methods June 2006 + + +5. Bind Operation + + The Bind operation ([RFC4511], 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 + [RFC4514]) 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 + + 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 [RFC4514] of non-zero length) and specifying + the simple authentication choice containing a password value of zero + length. + + + + +Harrison Standards Track [Page 14] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 [RFC4514] 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, that the password is not + valid for the DN, or that the server otherwise considers the + credentials invalid. A resultCode of success indicates that the + credentials are valid and that 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 Standards Track [Page 15] + +RFC 4513 LDAP Authentication Methods June 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 [RFC4422]. As LDAP + includes native anonymous and name/password (plain text) + authentication methods, the ANONYMOUS [RFC4505] 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 ([RFC4422], Section 4). This section explains how each of + these profiling requirements is 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 + ([RFC4511], 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 + [RFC4422], Sections 3 and 5). + + 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 + + + +Harrison Standards Track [Page 16] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 that + 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 the 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 Standards Track [Page 17] + +RFC 4513 LDAP Authentication Methods June 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 + include 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) ([RFC4512], 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 [RFC4422], 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. + + + + +Harrison Standards Track [Page 18] + +RFC 4513 LDAP Authentication Methods June 2006 + + +5.2.1.6. Rules for Using SASL Layers + + Upon installing a SASL layer, the client SHOULD discard or refresh + all information about the server that it obtained prior to the + initiation of the SASL negotiation and that it did not obtain 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 [RFC4422], + Section 4. + +5.2.1.8. SASL Authorization Identities + + Some SASL mechanisms allow clients to request a desired authorization + identity for the LDAP session ([RFC4422], 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 Augmented + Backus-Naur Form (ABNF) [RFC4234] 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 [RFC4514] + and the UTF8 rule is defined in Section 1.4 of [RFC4512]. + + 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 ([RFC4517], Section 4.2.15). + There is no requirement that the asserted distinguishedName value be + that of an entry in the directory. + + + + + +Harrison Standards Track [Page 19] + +RFC 4513 LDAP Authentication Methods June 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 ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm, + 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 [RFC4520] 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 + [DIGEST-MD5] utilizes an authentication identity and a realm that are + syntactically simple strings and semantically simple username + [RFC4013] and realm values. 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 ([RFC4422], Appendix A) 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. + + + + + + +Harrison Standards Track [Page 20] + +RFC 4513 LDAP Authentication Methods June 2006 + + +5.2.3.1. Implicit Assertion + + 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 means other 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 + + + +Harrison Standards Track [Page 21] + +RFC 4513 LDAP Authentication Methods June 2006 + + + confidentialityRequired indicates that the server requires + establishment of (stronger) data confidentiality protection in order + to perform the requested operation. + + 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 [RFC4346]. + + + +Harrison Standards Track [Page 22] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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 + + 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 + [DIGEST-MD5], 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 [RFC4422] + + + + + +Harrison Standards Track [Page 23] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 that: + + A TLS layer has been successfully installed. + + 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 + + + +Harrison Standards Track [Page 24] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 [RFC4422], [RFC4013], [RFC3454], and + [RFC3629]. + +7. IANA Considerations + + The IANA has updated the LDAP Protocol Mechanism registry to indicate + that this document and [RFC4511] provide the definitive technical + specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended + operation. + + The IANA has updated the LDAP LDAPMessage types registry to indicate + that this document and [RFC4511] provide the definitive technical + specification for the bindRequest (0) and bindResponse (1) message + types. + + The IANA has updated the LDAP Bind Authentication Method registry to + indicate that this document and [RFC4511] provide the definitive + technical specification for the simple (0) and sasl (3) bind + authentication methods. + + The IANA has updated the LDAP authzid prefixes registry to indicate + that this document provides the definitive technical specification + for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes. + +8. Acknowledgements + + This document combines information originally contained in RFC 2251, + RFC 2829, and RFC 2830. RFC 2251 was a product of the Access, + Searching, and Indexing of Directories (ASID) Working Group. RFC + 2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT) + Working Group. + + This document is a product of the IETF LDAP Revision (LDAPBIS) + working group. + + + + + + +Harrison Standards Track [Page 25] + +RFC 4513 LDAP Authentication Methods June 2006 + + +9. Normative References + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version + 1.1", RFC 4346, March 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + June 2006. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + + + + + +Harrison Standards Track [Page 26] + +RFC 4513 LDAP Authentication Methods June 2006 + + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [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.501] ITU-T Rec. X.501, "The Directory: Models", 1993. + +10. Informative References + + [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest + Authentication as a SASL Mechanism", Work in Progress, + March 2006. + + [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in + Progress, March 2005. + + [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC + 2828, May 2000. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, + June 2006. + + + + + + + + +Harrison Standards Track [Page 27] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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. 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; and others (e.g., + time of day) may be "environmental". + + 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 + + + +Harrison Standards Track [Page 28] + +RFC 4513 LDAP Authentication Methods June 2006 + + + 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 [RFC4422]. + 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, thus 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. + + 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. + + + + + + +Harrison Standards Track [Page 29] + +RFC 4513 LDAP Authentication Methods June 2006 + + + - 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 + [RFC4511]. + +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 + + 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 [DIGEST-MD5]. + + + + + + + + +Harrison Standards Track [Page 30] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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 under TLS + encryption") + + - 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") + + - See Section B.2.5. + +B.2.7. Section 7.1 ("Certificate-based authentication with TLS") + + - See Section B.2.5. + + + + + + + + +Harrison Standards Track [Page 31] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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 now support the + TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to + 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 [RFC4511] for summaries of + changes to other sections. + +B.3.1. Section 3.6 ("Server Identity Check") + + - 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. + + + + + + + + +Harrison Standards Track [Page 32] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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. This is to allow + for situations where this information was obtained through a secure + mechanism. + +B.3.3. Section 5 ("Effects of TLS on a Client's 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.2 ("TLS Connection 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 + change the authentication and authorization states to anonymous + upon TLS closure. + + - Replaced references to RFC 2401 with RFC 4301. + +Author's Address + + Roger Harrison + Novell, Inc. + 1800 S. Novell Place + Provo, UT 84606 + USA + + Phone: +1 801 861 2642 + EMail: roger_harrison@novell.com + + + + + + + + + + + + + + + + + + +Harrison Standards Track [Page 33] + +RFC 4513 LDAP Authentication Methods June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Harrison Standards Track [Page 34] + diff --git a/source4/ldap_server/devdocs/rfc4514.txt b/source4/ldap_server/devdocs/rfc4514.txt new file mode 100644 index 0000000000..036c077cbf --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4514.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group K. Zeilenga, Ed. +Request for Comments: 4514 OpenLDAP Foundation +Obsoletes: 2253 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + String Representation of Distinguished Names + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +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) [RFC4510], + distinguished names (DNs) are used to unambiguously refer to + directory entries [X.501][RFC4512]. + + 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 + + + +Zeilenga Standards Track [Page 1] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + implementations with a human user interface would display these + strings directly to the user, but that they 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 [RFC4511][RFC4517]. 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 an 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 that 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 [RFC4517]. + + This document is a integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + 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][RFC4512]. + +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 <U+0061> or <LATIN SMALL LETTER A>. + + 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]. + + + + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4514 LDAP: Distinguished Names June 2006 + + +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 a 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 that conform to the + grammar defined in Section 3 SHALL be produced by LDAP + implementations. + +2.1. Converting the RDNSequence + + If the RDNSequence is an empty sequence, the result is the empty or + zero-length string. + + Otherwise, the output consists of the string encodings of each + RelativeDistinguishedName in the RDNSequence (according to Section + 2.2), starting with the last element of the sequence and moving + backwards toward the first. + + The encodings of adjoining RelativeDistinguishedNames are separated + by a comma (',' U+002C) character. + +2.2. Converting RelativeDistinguishedName + + 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. + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4514 LDAP: Distinguished Names June 2006 + + +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) + [RFC4512] and that short name is known to be registered [REGISTRY] + [RFC4520] as identifying the AttributeType, that short name, a + <descr>, is used. Otherwise the AttributeType is encoded as the + dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. + The <descr> and <numericoid> are defined in [RFC4512]. + + Implementations are not expected to dynamically update their + knowledge of registered short names. However, implementations SHOULD + provide a mechanism to allow their knowledge of registered short + names to be updated. + +2.4. Converting an AttributeValue from ASN.1 to a String + + If the AttributeType is of the dotted-decimal form, the + AttributeValue is represented by an number sign ('#' U+0023) + character followed by the hexadecimal encoding of each of the octets + of the BER encoding of the X.500 AttributeValue. This form is also + used when the syntax of the AttributeValue does not have an LDAP- + specific ([RFC4517], 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 that has a LDAP- + specific string encoding, the value is converted first to a UTF-8- + encoded Unicode string according to its syntax specification (see + [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode + string does not have any of the following characters that 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; + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + - 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 + Augmented BNF [RFC4234] 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 <escaped>, 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 / + + + +Zeilenga Standards Track [Page 5] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + %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 <descr>, <numericoid>, <COMMA>, <DQUOTE>, + <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, + <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512]. + + Each <attributeType>, either a <descr> or a <numericoid>, refers to + an attribute type of an attribute value assertion (AVA). The + <attributeType> is followed by an <EQUALS> and an <attributeValue>. + The <attributeValue> is either in <string> or <hexstring> form. + + If in <string> form, a LDAP string representation asserted value can + be obtained by replacing (left to right, non-recursively) each <pair> + appearing in the <string> as follows: + + replace <ESC><ESC> with <ESC>; + replace <ESC><special> with <special>; + replace <ESC><hexpair> with the octet indicated by the <hexpair>. + + If in <hexstring> form, a BER representation can be obtained from + converting each <hexpair> of the <hexstring> to the octet indicated + by the <hexpair>. + + There is one or more attribute value assertions, separated by <PLUS>, + for a relative distinguished name. + + There is zero or more relative distinguished names, separated by + <COMMA>, for a distinguished name. + + Implementations MUST recognize AttributeType name strings + (descriptors) listed in the following table, but MAY recognize other + name strings. + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + 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) + + These attribute types are described in [RFC4519]. + + Implementations MAY recognize other DN string representations. + However, as there is no requirement that alternative DN string + representations 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 of a name containing three RDNs, in which the + first RDN is multi-valued: + + OU=Sales+CN=J. Smith,DC=example,DC=net + + This example shows the method of escaping of a 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 that 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. + + + + +Zeilenga Standards Track [Page 7] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + 1.3.6.1.4.1.1466.0=#04024869 + + Finally, this example shows an RDN whose commonName value consists 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 + + This could be encoded in printable ASCII [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 + [RFC4511] and other documents comprising the LDAP Technical + Specification [RFC4510]. + +5.1. Disclosure + + Distinguished Names typically consist of descriptive information + about the entries they name, which can be people, organizations, + devices, or other real-world objects. This frequently includes some + of the following kinds of information: + + - the common name of the object (i.e., a person's full name) + - an email or TCP/IP address + - its physical location (country, locality, city, street address) + - organizational attributes (such as department name or + affiliation) + + In some cases, such information can be considered sensitive. In many + countries, privacy laws exist that prohibit disclosure of certain + kinds of descriptive information (e.g., email addresses). Hence, + server implementers are encouraged to support Directory Information + Tree (DIT) structural rules and name forms [RFC4512], as these + provide a mechanism for administrators to select appropriate naming + attributes for entries. Administrators are encouraged to use + mechanisms, access controls, and other administrative controls that + may be available to restrict use of attributes containing sensitive + information in naming of entries. Additionally, use of + + + +Zeilenga Standards Track [Page 8] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + authentication and data security services in LDAP [RFC4513][RFC4511] + 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 that requires the DER form of a + distinguished name is the verification of an X.509 certificate. + + For example, a distinguished name consisting of one RDN with one AVA, + in which the type is commonName and the value is of the TeletexString + choice with the letters 'Sam', would be represented in LDAP as the + string <CN=Sam>. Another distinguished name in which the value is + still 'Sam', but is of the PrintableString choice, would have the + same representation <CN=Sam>. + + Applications that 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. Acknowledgements + + This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and + Steve Kille. RFC 2253 was a product of the IETF ASID Working Group. + + This document is a product of the IETF LDAPBIS Working Group. + +7. References + +7.1. Normative References + + [REGISTRY] IANA, Object Identifier Descriptors Registry, + <http://www.iana.org/assignments/ldap-parameters>. + + [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/). + + + + + +Zeilenga Standards Track [Page 9] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + [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, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4514 LDAP: Distinguished Names June 2006 + + +7.2. Informative References + + [ASCII] Coded Character Set--7-bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report + #17, Character Encoding Model", UTR17, + <http://www.unicode.org/unicode/reports/tr17/>, August + 2000. + + [Glossary] The Unicode Consortium, "Unicode Glossary", + <http://www.unicode.org/glossary/>. + + [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.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993) + (also ISO/IEC 9594-3:1993). + + [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. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 11] + +RFC 4514 LDAP: Distinguished Names June 2006 + + +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. Issues with presentation of translated DN strings 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 that implementers 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 that 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 whitespace (as demonstrated in Section 4), it + is noted that DN strings may end with whitespace. Careful readers of + Section 3 will note that the 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, <CN=Sam\ > distinguishes the string + representation of the DN composed 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 whitespace after the RDN separator character or, if + necessary, after the AVA separator character. It should be noted to + the user that the inserted whitespace 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 Standards Track [Page 12] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + 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 whitespace is + to be removed before the DN string is used in LDAP. + + Inserting whitespace is not advised because it may not be obvious to + the user which whitespace is part of the DN string and which + whitespace 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". Removed + "as an example" language. Added statement (in Section 3) + allowing recognition of additional names but require recognition + of those names in the published table. The table now appears in + Section 3. + - Removed specification of additional requirements for LDAPv2 + implementations which also support LDAPv3 (RFC 2253, Section 4) + as LDAPv2 is now Historic. + - Allowed 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 + + + +Zeilenga Standards Track [Page 13] + +RFC 4514 LDAP: Distinguished Names June 2006 + + + are present. Indicated that null (U+0000) character is to be + escaped. Indicated that equals sign ('=' U+003D) character may + be escaped as '\='. + - Rewrote Section 3 to use ABNF as defined in RFC 4234. + - Updated the Section 3 ABNF. Changes include: + + allowed AttributeType short names of length 1 (e.g., 'L'), + + used more restrictive <oid> production in AttributeTypes, + + did not require escaping of equals sign ('=' U+003D) + characters, + + did not require escaping of non-leading number sign ('#' + U+0023) characters, + + allowed space (' ' U+0020) to be escaped as '\ ', + + required 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. + +Editor's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 14] + +RFC 4514 LDAP: Distinguished Names June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 15] + diff --git a/source4/ldap_server/devdocs/rfc4515.txt b/source4/ldap_server/devdocs/rfc4515.txt new file mode 100644 index 0000000000..86f03ebcd3 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4515.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group M. Smith, Ed. +Request for Comments: 4515 Pearl Crescent, LLC +Obsoletes: 2254 T. Howes +Category: Standards Track Opsware, Inc. + June 2006 + + + Lightweight Directory Access Protocol (LDAP): + String Representation of Search Filters + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Lightweight Directory Access Protocol (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 (RFC 4516) and in other + applications. + +Table of Contents + + 1. Introduction ....................................................2 + 2. LDAP Search Filter Definition ...................................2 + 3. String Search Filter Definition .................................3 + 4. Examples ........................................................5 + 5. Security Considerations .........................................7 + 6. Normative References ............................................7 + 7. Informative References ..........................................8 + 8. Acknowledgements ................................................8 + Appendix A: Changes Since RFC 2254 .................................9 + A.1. Technical Changes ..........................................9 + A.2. Editorial Changes ..........................................9 + + + + + + + +Smith and Howes Standards Track [Page 1] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + +1. Introduction + + The Lightweight Directory Access Protocol (LDAP) [RFC4510] 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 + [RFC4516] 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 + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + 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 [RFC4511] 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 } } + + + + + +Smith and Howes Standards Track [Page 2] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + AttributeValueAssertion ::= SEQUENCE { + attributeDesc AttributeDescription, + assertionValue AssertionValue } + + MatchingRuleAssertion ::= SEQUENCE { + matchingRule [1] MatchingRuleId OPTIONAL, + type [2] AttributeDescription OPTIONAL, + matchValue [3] AssertionValue, + dnAttributes [4] BOOLEAN DEFAULT FALSE } + + AttributeDescription ::= LDAPString + -- Constrained to <attributedescription> + -- [RFC4512] + + AttributeValue ::= OCTET STRING + + MatchingRuleId ::= LDAPString + + AssertionValue ::= OCTET STRING + + LDAPString ::= OCTET STRING -- UTF-8 encoded, + -- [Unicode] characters + + The AttributeDescription, as defined in [RFC4511], is a string + representation of the attribute description that is discussed in + [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have + the form defined in [RFC4517]. The Filter is encoded for + transmission over a network using the Basic Encoding Rules (BER) + defined in [X.690], with simplifications described in [RFC4511]. + +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 + [RFC4234]. The productions used that are not defined here are + defined in Section 1.4 (Common ABNF Productions) of [RFC4512] 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 + + + +Smith and Howes Standards Track [Page 3] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + 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 [RFC4512]. + dnattrs = COLON "dn" + matchingrule = COLON oid + assertionvalue = valueencoding + ; The <valueencoding> rule is used to encode an <AssertionValue> + ; from Section 4.1.6 of [RFC4511]. + 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 <substring> and <present> productions in + the grammar above can produce the "attr=*" construct, this construct + is used only to denote a presence filter. + + The <valueencoding> 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. + + + + + + + +Smith and Howes Standards Track [Page 4] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + 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 <normal> set may be escaped using this mechanism, for example, + non-printing ASCII characters. + + For AssertionValues that contain UTF-8 character data, each octet of + the character to be escaped is replaced by a backslash and two hex + digits, which form a single octet in the code of the character. For + example, the filter checking whether the "cn" attribute contained a + value with the character "*" anywhere in it would be represented as + "(cn=*\2a*)". + + As indicated by the <valueencoding> rule, implementations MUST escape + all octets greater than 0x7F that are not part of a valid UTF-8 + encoding sequence when they generate a string representation of a + search filter. Implementations SHOULD accept as input strings that + are not valid UTF-8 strings. This is necessary because RFC 2254 did + 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. + + + + + +Smith and Howes Standards Track [Page 5] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + The third example illustrates the use of the ":oid" notation to + indicate that the 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 <attr> 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. + + 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 <assertionvalue> 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. + + + + +Smith and Howes Standards Track [Page 6] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + +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 [RFC4511] and + [RFC4513] for more information. + +6. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [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." + + + + +Smith and Howes Standards Track [Page 7] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + +7. Informative References + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, + and Distinguished Encoding Rules, ITU-T Recommendation + X.690, 1994. + +8. Acknowledgements + + 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 and Howes Standards Track [Page 8] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + +Appendix A: Changes Since RFC 2254 + +A.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 [RFC4512]. + + 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 [RFC4517]. + + Added "(" and ")" around the components of the <extensible> + subproductions for clarity. + + Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more + precisely reference productions from the [RFC4512] and [RFC4511] + documents. + + "String Search Filter Definition" section: replaced "greater" and + "less" with "greaterorequal" and "lessorequal" to avoid confusion. + + 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." + +A.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" and "Intellectual Property" sections: added. + + Copyright: updated per latest IETF guidelines. + + + +Smith and Howes Standards Track [Page 9] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + "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 + [RFC4510] document. + + "LDAP Search Filter Definition" section: made corrections to the LDAP + search filter ABNF so it matches that used in [RFC4511]. + + Clarified the definition of 'value' (now 'assertionvalue') to take + into account the fact that it is not precisely an AttributeAssertion + from [RFC4511] 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 + the last extensible match example to remind the reader to treat the + <dnattrs> 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 [RFC4511] and + [RFC4513]. + + "Normative References" section: renamed from "References" per new RFC + guidelines. Changed from [1] style to [RFC4511] style throughout the + document. Added entries for [Unicode], [RFC2119], [RFC4513], + [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced + RFC 822 reference with a reference to RFC 4234. + + "Informative References" section: (new section) moved [X.690] to this + section. Added a reference to [RFC4516]. + + "Acknowledgements" section: added. + + "Appendix A: Changes Since RFC 2254" section: added. + + Surrounded the names of all ABNF productions with "<" and ">" where + they are used in descriptive text. + + + +Smith and Howes Standards Track [Page 10] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + + Replaced all occurrences of "LDAPv3" with "LDAP." + +Authors' Addresses + + Mark Smith, Editor + Pearl Crescent, LLC + 447 Marlpool Dr. + Saline, MI 48176 + USA + + Phone: +1 734 944-2856 + EMail: mcs@pearlcrescent.com + + + Tim Howes + Opsware, Inc. + 599 N. Mathilda Ave. + Sunnyvale, CA 94085 + USA + + Phone: +1 408 744-7509 + EMail: howes@opsware.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smith and Howes Standards Track [Page 11] + +RFC 4515 LDAP: String Representation of Search Filters June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Smith and Howes Standards Track [Page 12] + diff --git a/source4/ldap_server/devdocs/rfc4516.txt b/source4/ldap_server/devdocs/rfc4516.txt new file mode 100644 index 0000000000..6de1e1d08a --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4516.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group M. Smith, Ed. +Request for Comments: 4516 Pearl Crescent, LLC +Obsoletes: 2255 T. Howes +Category: Standards Track Opsware, Inc. + June 2006 + + + Lightweight Directory Access Protocol (LDAP): + Uniform Resource Locator + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a format for a Lightweight Directory Access + Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL + describes an LDAP search operation that is used to retrieve + information from an LDAP directory, or, in the context of an LDAP + referral or reference, an LDAP URL describes a service where an LDAP + operation may be progressed. + +Table of Contents + + 1. Introduction ....................................................2 + 2. URL Definition ..................................................2 + 2.1. Percent-Encoding ...........................................4 + 3. Defaults for Fields of the LDAP URL .............................5 + 4. Examples ........................................................6 + 5. Security Considerations .........................................8 + 6. Normative References ............................................9 + 7. Informative References .........................................10 + 8. Acknowledgements ...............................................10 + Appendix A: Changes Since RFC 2255 ................................11 + A.1. Technical Changes .........................................11 + A.2. Editorial Changes .........................................11 + + + + + + +Smith & Howes Standards Track [Page 1] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +1. Introduction + + LDAP is the Lightweight Directory Access Protocol [RFC4510]. This + document specifies the LDAP URL format for version 3 of LDAP and + clarifies how LDAP URLs are resolved. This document also defines an + extension mechanism for LDAP URLs. This mechanism may be used to + provide access to new LDAP extensions. + + Note that not all the parameters of the LDAP search operation + described in [RFC4511] can be expressed using the format defined in + this document. Note also that URLs may be used to represent + reference knowledge, including that for non-search operations. + + This document is an integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + This document replaces RFC 2255. See Appendix A for a list of + changes relative to RFC 2255. + + 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. URL Definition + + An LDAP URL begins with the protocol prefix "ldap" and is defined by + the following grammar, following the ABNF notation defined in + [RFC4234]. + + ldapurl = scheme COLON SLASH SLASH [host [COLON port]] + [SLASH dn [QUESTION [attributes] + [QUESTION [scope] [QUESTION [filter] + [QUESTION extensions]]]]] + ; <host> and <port> are defined + ; in Sections 3.2.2 and 3.2.3 + ; of [RFC3986]. + ; <filter> is from Section 3 of + ; [RFC4515], subject to the + ; provisions of the + ; "Percent-Encoding" section + ; below. + + scheme = "ldap" + + + + + + + +Smith & Howes Standards Track [Page 2] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + dn = distinguishedName ; From Section 3 of [RFC4514], + ; subject to the provisions of + ; the "Percent-Encoding" + ; section below. + + attributes = attrdesc *(COMMA attrdesc) + attrdesc = selector *(COMMA selector) + selector = attributeSelector ; From Section 4.5.1 of + ; [RFC4511], subject to the + ; provisions of the + ; "Percent-Encoding" section + ; below. + + scope = "base" / "one" / "sub" + extensions = extension *(COMMA extension) + extension = [EXCLAMATION] extype [EQUALS exvalue] + extype = oid ; From section 1.4 of [RFC4512]. + + exvalue = LDAPString ; From section 4.1.2 of + ; [RFC4511], subject to the + ; provisions of the + ; "Percent-Encoding" section + ; below. + + EXCLAMATION = %x21 ; exclamation mark ("!") + SLASH = %x2F ; forward slash ("/") + COLON = %x3A ; colon (":") + QUESTION = %x3F ; question mark ("?") + + The "ldap" prefix indicates an entry or entries accessible from the + LDAP server running on the given hostname at the given portnumber. + Note that the <host> may contain literal IPv6 addresses as specified + in Section 3.2.2 of [RFC3986]. + + The <dn> is an LDAP Distinguished Name using the string format + described in [RFC4514]. It identifies the base object of the LDAP + search or the target of a non-search operation. + + The <attributes> construct is used to indicate which attributes + should be returned from the entry or entries. + + The <scope> construct is used to specify the scope of the search to + perform in the given LDAP server. The allowable scopes are "base" + for a base object search, "one" for a one-level search, or "sub" for + a subtree search. + + + + + + +Smith & Howes Standards Track [Page 3] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + The <filter> is used to specify the search filter to apply to entries + within the specified scope during the search. It has the format + specified in [RFC4515]. + + The <extensions> construct provides the LDAP URL with an + extensibility mechanism, allowing the capabilities of the URL to be + extended in the future. Extensions are a simple comma-separated list + of type=value pairs, where the =value portion MAY be omitted for + options not requiring it. Each type=value pair is a separate + extension. These LDAP URL extensions are not necessarily related to + any of the LDAP extension mechanisms. Extensions may be supported or + unsupported by the client resolving the URL. An extension prefixed + with a '!' character (ASCII 0x21) is critical. An extension not + prefixed with a '!' character is non-critical. + + If an LDAP URL extension is implemented (that is, if the + implementation understands it and is able to use it), the + implementation MUST make use of it. If an extension is not + implemented and is marked critical, the implementation MUST NOT + process the URL. If an extension is not implemented and is not + marked critical, the implementation MUST ignore the extension. + + The extension type (<extype>) MAY be specified using the numeric OID + <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form + (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be + restricted to registered object identifier descriptive names. See + [RFC4520] for registration details and usage guidelines for + descriptive names. + + No LDAP URL extensions are defined in this document. Other documents + or a future version of this document MAY define one or more + extensions. + +2.1. Percent-Encoding + + A generated LDAP URL MUST consist only of the restricted set of + characters included in one of the following three productions defined + in [RFC3986]: + + <reserved> + <unreserved> + <pct-encoded> + + Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as + input. An octet MUST be encoded using the percent-encoding mechanism + described in section 2.1 of [RFC3986] in any of these situations: + + + + + +Smith & Howes Standards Track [Page 4] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + The octet is not in the reserved set defined in section 2.2 of + [RFC3986] or in the unreserved set defined in section 2.3 of + [RFC3986]. + + It is the single Reserved character '?' and occurs inside a <dn>, + <filter>, or other element of an LDAP URL. + + It is a comma character ',' that occurs inside an <exvalue>. + + Note that before the percent-encoding mechanism is applied, the + extensions component of the LDAP URL may contain one or more null + (zero) bytes. No other component may. + +3. Defaults for Fields of the LDAP URL + + Some fields of the LDAP URL are optional, as described above. In the + absence of any other specification, the following general defaults + SHOULD be used when a field is absent. Note that other documents MAY + specify different defaulting rules; for example, section 4.1.10 of + [RFC4511] specifies a different rule for determining the correct DN + to use when it is absent in an LDAP URL that is returned as a + referral. + + <host> + If no <host> is given, the client must have some a priori + knowledge of an appropriate LDAP server to contact. + + <port> + The default LDAP port is TCP port 389. + + <dn> + If no <dn> is given, the default is the zero-length DN, "". + + <attributes> + If the <attributes> part is omitted, all user attributes of the + entry or entries should be requested (e.g., by setting the + attributes field AttributeDescriptionList in the LDAP search + request to a NULL list, or by using the special <alluserattrs> + selector "*"). + + <scope> + If <scope> is omitted, a <scope> of "base" is assumed. + + <filter> + If <filter> is omitted, a filter of "(objectClass=*)" is assumed. + + <extensions> + If <extensions> is omitted, no extensions are assumed. + + + +Smith & Howes Standards Track [Page 5] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +4. Examples + + The following are some example LDAP URLs that use the format defined + above. The first example is an LDAP URL referring to the University + of Michigan entry, available from an LDAP server of the client's + choosing: + + ldap:///o=University%20of%20Michigan,c=US + + The next example is an LDAP URL referring to the University of + Michigan entry in a particular ldap server: + + ldap://ldap1.example.net/o=University%20of%20Michigan,c=US + + Both of these URLs correspond to a base object search of the + "o=University of Michigan,c=US" entry using a filter of + "(objectclass=*)", requesting all attributes. + + The next example is an LDAP URL referring to only the postalAddress + attribute of the University of Michigan entry: + + ldap://ldap1.example.net/o=University%20of%20Michigan, + c=US?postalAddress + + The corresponding LDAP search operation is the same as in the + previous example, except that only the postalAddress attribute is + requested. + + The next example is an LDAP URL referring to the set of entries found + by querying the given LDAP server on port 6666 and doing a subtree + search of the University of Michigan for any entry with a common name + of "Babs Jensen", retrieving all attributes: + + ldap://ldap1.example.net:6666/o=University%20of%20Michigan, + c=US??sub?(cn=Babs%20Jensen) + + The next example is an LDAP URL referring to all children of the c=GB + entry: + + LDAP://ldap1.example.com/c=GB?objectClass?ONE + + The objectClass attribute is requested to be returned along with the + entries, and the default filter of "(objectclass=*)" is used. + + The next example is an LDAP URL to retrieve the mail attribute for + the LDAP entry named "o=Question?,c=US", illustrating the use of the + percent-encoding mechanism on the reserved character '?'. + + + + +Smith & Howes Standards Track [Page 6] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + ldap://ldap2.example.com/o=Question%3f,c=US?mail + + The next example (which is broken into two lines for readability) + illustrates the interaction between the LDAP string representation of + the filters-quoting mechanism and the URL-quoting mechanisms. + + ldap://ldap3.example.com/o=Babsco,c=US + ???(four-octet=%5c00%5c00%5c00%5c04) + + The filter in this example uses the LDAP escaping mechanism of \ to + encode three zero or null bytes in the value. In LDAP, the filter + would be written as (four-octet=\00\00\00\04). Because the \ + character must be escaped in a URL, the \s are percent-encoded as %5c + (or %5C) in the URL encoding. + + The next example illustrates the interaction between the LDAP string + representation of the DNs-quoting mechanism and URL-quoting + mechanisms. + + ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US + + The DN encoded in the above URL is: + + o=An Example\2C Inc.,c=US + + That is, the left-most RDN value is: + + An Example, Inc. + + The following three URLs are equivalent, assuming that the defaulting + rules specified in Section 3 of this document are used: + + ldap://ldap.example.net + ldap://ldap.example.net/ + ldap://ldap.example.net/? + + These three URLs point to the root DSE on the ldap.example.net + server. + + The final two examples show use of a hypothetical, experimental bind + name extension (the value associated with the extension is an LDAP + DN). + + ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com + ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com + + + + + + +Smith & Howes Standards Track [Page 7] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + The two URLs are the same, except that the second one marks the + e-bindname extension as critical. Notice the use of the percent- + encoding mechanism to encode the commas within the distinguished name + value in the e-bindname extension. + +5. Security Considerations + + The general URL security considerations discussed in [RFC3986] are + relevant for LDAP URLs. + + The use of security mechanisms when processing LDAP URLs requires + particular care, since clients may encounter many different servers + via URLs, and since URLs are likely to be processed automatically, + without user intervention. A client SHOULD have a user-configurable + policy that controls which servers the client will establish LDAP + sessions with and with which security mechanisms, and SHOULD NOT + establish LDAP sessions that are inconsistent with this policy. If a + client chooses to reuse an existing LDAP session when resolving one + or more LDAP URLs, it MUST ensure that the session is compatible with + the URL and that no security policies are violated. + + Sending authentication information, no matter the mechanism, may + violate a user's privacy requirements. In the absence of specific + policy permitting authentication information to be sent to a server, + a client should use an anonymous LDAP session. (Note that clients + conforming to previous LDAP URL specifications, where all LDAP + sessions are anonymous and unprotected, are consistent with this + specification; they simply have the default security policy.) Simply + opening a transport connection to another server may violate some + users' privacy requirements, so clients should provide the user with + a way to control URL processing. + + Some authentication methods, in particular, reusable passwords sent + to the server, may reveal easily-abused information to the remote + server or to eavesdroppers in transit and should not be used in URL + processing unless they are explicitly permitted by policy. + Confirmation by the human user of the use of authentication + information is appropriate in many circumstances. Use of strong + authentication methods that do not reveal sensitive information is + much preferred. If the URL represents a referral for an update + operation, strong authentication methods SHOULD be used. Please + refer to the Security Considerations section of [RFC4513] for more + information. + + The LDAP URL format allows the specification of an arbitrary LDAP + search operation to be performed when evaluating the LDAP URL. + Following an LDAP URL may cause unexpected results, for example, the + retrieval of large amounts of data or the initiation of a long-lived + + + +Smith & Howes Standards Track [Page 8] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + search. The security implications of resolving an LDAP URL are the + same as those of resolving an LDAP search query. + +6. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", RFC + 4514, June 2006. + + [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access + Protocol (LDAP): String Representation of Search Filters", + RFC 4515, June 2006. + + + + + + + + + + + +Smith & Howes Standards Track [Page 9] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +7. Informative References + + [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + +8. Acknowledgements + + The LDAP URL format was originally defined at the University of + Michigan. This material is based upon work supported by the National + Science Foundation under Grant No. NCR-9416667. The support of both + the University of Michigan and the National Science Foundation is + gratefully acknowledged. + + This document obsoletes RFC 2255 by Tim Howes and Mark Smith. + 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. Several people in particular have + made valuable comments on this document: RL "Bob" Morgan, Mark Wahl, + Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special + thanks for their contributions. + + + + + + + + + + + + + + + + + + + + + + + + +Smith & Howes Standards Track [Page 10] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +Appendix A: Changes Since RFC 2255 + +A.1. Technical Changes + + The following technical changes were made to the contents of the "URL + Definition" section: + + Revised all of the ABNF to use common productions from [RFC4512]. + + Replaced references to [RFC2396] with a reference to [RFC3986] (this + allows literal IPv6 addresses to be used inside the <host> portion of + the URL, and a note was added to remind the reader of this + enhancement). Referencing [RFC3986] required changes to the ABNF and + text so that productions that are no longer defined by [RFC3986] are + not used. For example, <hostport> is not defined by [RFC3986] so it + has been replaced with host [COLON port]. Note that [RFC3986] + includes new definitions for the "Reserved" and "Unreserved" sets of + characters, and the net result is that the following two additional + characters should be percent-encoded when they appear anywhere in the + data used to construct an LDAP URL: "[" and "]" (these two characters + were first added to the Reserved set by RFC 2732). + + Changed the definition of <attrdesc> to refer to <attributeSelector> + from [RFC4511]. This allows the use of "*" in the <attrdesc> part of + the URL. It is believed that existing implementations of RFC 2255 + already support this. + + Avoided use of <prose-val> (bracketed-string) productions in the + <dn>, <host>, <attrdesc>, and <exvalue> rules. + + Changed the ABNF for <ldapurl> to group the <dn> component with the + preceding <SLASH>. + + Changed the <extype> rule to be an <oid> from [RFC4512]. + + Changed the text about extension types so it references [RFC4520]. + Reordered rules to more closely follow the order in which the + elements appear in the URL. + + "Bindname Extension": removed due to lack of known implementations. + +A.2. Editorial Changes + + Changed document title to include "LDAP:" prefix. + + IESG Note: removed note about lack of satisfactory mandatory + authentication mechanisms. + + + + +Smith & Howes Standards Track [Page 11] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + "Status of this Memo" section: updated boilerplate to match current + I-D guidelines. + + "Abstract" section: separated from introductory material. + + "Table of Contents" and "Intellectual Property" sections: added. + + "Introduction" section: new section; separated from the Abstract. + Changed the text indicate that RFC 2255 is replaced by this document + (instead of RFC 1959). Added text to indicate that LDAP URLs are + used for references and referrals. Fixed typo (replaced the nonsense + phrase "to perform to retrieve" with "used to retrieve"). Added a + note to let the reader know that not all of the parameters of the + LDAP search operation described in [RFC4511] can be expressed using + this format. + + "URL Definition" section: removed second copy of <ldapurl> grammar + and following two paragraphs (editorial error in RFC 2255). Fixed + line break within '!' sequence. Reformatted the ABNF to improve + readability by aligning comments and adding some blank lines. + Replaced "residing in the LDAP server" with "accessible from the LDAP + server" in the sentence immediately following the ABNF. Removed the + sentence "Individual attrdesc names are as defined for + AttributeDescription in [RFC4511]." because [RFC4511]'s + <attributeSelector> is now used directly in the ABNF. Reworded last + paragraph to clarify which characters must be percent-encoded. Added + text to indicate that LDAP URLs are used for references and + referrals. Added text that refers to the ABNF from RFC 4234. + Clarified and strengthened the requirements with respect to + processing of URLs that contain implemented and not implemented + extensions (the approach now closely matches that specified in + [RFC4511] for LDAP controls). + + "Defaults for Fields of the LDAP URL" section: added; formed by + moving text about defaults out of the "URL Definition" section. + Replaced direct reference to the attribute name "*" with a reference + to the special <alluserattrs> selector "*" defined in [RFC4511]. + + "URL Processing" section: removed. + + "Examples" section: Modified examples to use example.com and + example.net hostnames. Added missing '?' to the LDAP URL example + whose filter contains three null bytes. Removed space after one + comma within a DN. Revised the bindname example to use e-bindname. + Changed the name of an attribute used in one example from "int" to + "four-octet" to avoid potential confusion. Added an example that + demonstrates the interaction between DN escaping and URL percent- + encoding. Added some examples to show URL equivalence with respect + + + +Smith & Howes Standards Track [Page 12] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + + to the <dn> portion of the URL. Used uppercase in some examples to + remind the reader that some tokens are case-insensitive. + + "Security Considerations" section: Added a note about connection + reuse. Added a note about using strong authentication methods for + updates. Added a reference to [RFC4513]. Added note that simply + opening a connection may violate some users' privacy requirements. + Adopted the working group's revised LDAP terminology specification by + replacing the word "connection" with "LDAP session" or "LDAP + connection" as appropriate. + + "Acknowledgements" section: added statement that this document + obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and + Hallvard Furuseth. + + "Normative References" section: renamed from "References" per new RFC + guidelines. Changed from [1] style to [RFC4511] style throughout the + document. Added references to RFC 4234 and RFC 3629. Updated all + RFC 1738 references to point to the appropriate sections within + [RFC3986]. Updated the LDAP references to refer to LDAPBis WG + documents. Removed the reference to the LDAP Attribute Syntaxes + document and added references to the [RFC4513], [RFC4520], and + [RFC4510] documents. + + "Informative References" section: added. + + Header and "Authors' Addresses" sections: added "editor" next to Mark + Smith's name. Updated affiliation and contact information. + + Copyright: updated the year. + + Throughout the document: surrounded the names of all ABNF productions + with "<" and ">" where they are used in descriptive text. + + + + + + + + + + + + + + + + + + +Smith & Howes Standards Track [Page 13] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +Authors' Addresses + + Mark Smith, Editor + Pearl Crescent, LLC + 447 Marlpool Dr. + Saline, MI 48176 + USA + + Phone: +1 734 944-2856 + EMail: mcs@pearlcrescent.com + + + Tim Howes + Opsware, Inc. + 599 N. Mathilda Ave. + Sunnyvale, CA 94085 + USA + + Phone: +1 408 744-7509 + EMail: howes@opsware.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smith & Howes Standards Track [Page 14] + +RFC 4516 LDAP: Uniform Resource Locator June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Smith & Howes Standards Track [Page 15] + diff --git a/source4/ldap_server/devdocs/rfc4517.txt b/source4/ldap_server/devdocs/rfc4517.txt new file mode 100644 index 0000000000..177e08b2ac --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4517.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group S. Legg, Ed. +Request for Comments: 4517 eB2Bcom +Obsoletes: 2252, 2256 June 2006 +Updates: 3698 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Syntaxes and Matching Rules + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory, whose values may be transferred in the LDAP + protocol, has a defined syntax that constrains the structure and + format of its values. The comparison semantics for values of a + syntax are not part of the syntax definition but are instead provided + through separately defined matching rules. Matching rules specify an + argument, an assertion value, which also has a defined syntax. This + document defines a base set of syntaxes and matching rules for use in + defining attributes for LDAP directories. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions .....................................................4 + 3. Syntaxes ........................................................4 + 3.1. General Considerations .....................................5 + 3.2. Common Definitions .........................................5 + 3.3. Syntax Definitions .........................................6 + 3.3.1. Attribute Type Description ..........................6 + 3.3.2. Bit String ..........................................6 + 3.3.3. Boolean .............................................7 + 3.3.4. Country String ......................................7 + 3.3.5. Delivery Method .....................................8 + + + +Legg Standards Track [Page 1] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 3.3.6. Directory String ....................................8 + 3.3.7. DIT Content Rule Description ........................9 + 3.3.8. DIT Structure Rule Description .....................10 + 3.3.9. DN .................................................10 + 3.3.10. Enhanced Guide ....................................11 + 3.3.11. Facsimile Telephone Number ........................12 + 3.3.12. Fax ...............................................12 + 3.3.13. Generalized Time ..................................13 + 3.3.14. Guide .............................................14 + 3.3.15. IA5 String ........................................15 + 3.3.16. Integer ...........................................15 + 3.3.17. JPEG ..............................................15 + 3.3.18. LDAP Syntax Description ...........................16 + 3.3.19. Matching Rule Description .........................16 + 3.3.20. Matching Rule Use Description .....................17 + 3.3.21. Name and Optional UID .............................17 + 3.3.22. Name Form Description .............................18 + 3.3.23. Numeric String ....................................18 + 3.3.24. Object Class Description ..........................18 + 3.3.25. Octet String ......................................19 + 3.3.26. OID ...............................................19 + 3.3.27. Other Mailbox .....................................20 + 3.3.28. Postal Address ....................................20 + 3.3.29. Printable String ..................................21 + 3.3.30. Substring Assertion ...............................22 + 3.3.31. Telephone Number ..................................23 + 3.3.32. Teletex Terminal Identifier .......................23 + 3.3.33. Telex Number ......................................24 + 3.3.34. UTC Time ..........................................24 + 4. Matching Rules .................................................25 + 4.1. General Considerations ....................................25 + 4.2. Matching Rule Definitions .................................27 + 4.2.1. bitStringMatch .....................................27 + 4.2.2. booleanMatch .......................................28 + 4.2.3. caseExactIA5Match ..................................28 + 4.2.4. caseExactMatch .....................................29 + 4.2.5. caseExactOrderingMatch .............................29 + 4.2.6. caseExactSubstringsMatch ...........................30 + 4.2.7. caseIgnoreIA5Match .................................30 + 4.2.8. caseIgnoreIA5SubstringsMatch .......................31 + 4.2.9. caseIgnoreListMatch ................................31 + 4.2.10. caseIgnoreListSubstringsMatch .....................32 + 4.2.11. caseIgnoreMatch ...................................33 + 4.2.12. caseIgnoreOrderingMatch ...........................33 + 4.2.13. caseIgnoreSubstringsMatch .........................34 + 4.2.14. directoryStringFirstComponentMatch ................34 + 4.2.15. distinguishedNameMatch ............................35 + 4.2.16. generalizedTimeMatch ..............................36 + + + +Legg Standards Track [Page 2] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 4.2.17. generalizedTimeOrderingMatch ......................36 + 4.2.18. integerFirstComponentMatch ........................36 + 4.2.19. integerMatch ......................................37 + 4.2.20. integerOrderingMatch ..............................37 + 4.2.21. keywordMatch ......................................38 + 4.2.22. numericStringMatch ................................38 + 4.2.23. numericStringOrderingMatch ........................39 + 4.2.24. numericStringSubstringsMatch ......................39 + 4.2.25. objectIdentifierFirstComponentMatch ...............40 + 4.2.26. objectIdentifierMatch .............................40 + 4.2.27. octetStringMatch ..................................41 + 4.2.28. octetStringOrderingMatch ..........................41 + 4.2.29. telephoneNumberMatch ..............................42 + 4.2.30. telephoneNumberSubstringsMatch ....................42 + 4.2.31. uniqueMemberMatch .................................43 + 4.2.32. wordMatch .........................................44 + 5. Security Considerations ........................................44 + 6. Acknowledgements ...............................................44 + 7. IANA Considerations ............................................45 + 8. References .....................................................46 + 8.1. Normative References ......................................46 + 8.2. Informative References ....................................48 + Appendix A. Summary of Syntax Object Identifiers ..................49 + Appendix B. Changes from RFC 2252 .................................49 + +1. Introduction + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory [RFC4510], whose values may be transferred in the + LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that + constrains the structure and format of its values. The comparison + semantics for values of a syntax are not part of the syntax + definition but are instead provided through separately defined + matching rules. Matching rules specify an argument, an assertion + value, which also has a defined syntax. This document defines a base + set of syntaxes and matching rules for use in defining attributes for + LDAP directories. + + Readers are advised to familiarize themselves with the Directory + Information Models [RFC4512] before reading the rest of this + document. Section 3 provides definitions for the base set of LDAP + syntaxes. Section 4 provides definitions for the base set of + matching rules for LDAP. + + This document is an integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + + + +Legg Standards Track [Page 3] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The + remainder of RFC 2252 is obsoleted by this document. Sections 6 and + 8 of RFC 2256 are obsoleted by this document. The remainder of RFC + 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 + of RFC 3698 is obsoleted by this document. + + A number of schema elements that were included in the previous + revision of the LDAP technical specification are not included in this + revision of LDAP. Public Key Infrastructure schema elements are now + specified in [RFC4523]. Unless reintroduced in future technical + specifications, the remainder are to be considered Historic. + + The changes with respect to RFC 2252 are described in Appendix B of + this document. + +2. Conventions + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + + Syntax definitions are written according to the <SyntaxDescription> + ABNF [RFC4234] rule specified in [RFC4512], and matching rule + definitions are written according to the <MatchingRuleDescription> + ABNF rule specified in [RFC4512], except that the syntax and matching + rule definitions provided in this document are line-wrapped for + readability. When such definitions are transferred as attribute + values in the LDAP protocol (e.g., as values of the ldapSyntaxes and + matchingRules attributes [RFC4512], respectively), then those values + would not contain line breaks. + +3. Syntaxes + + Syntax definitions constrain the structure of attribute values stored + in an LDAP directory, and determine the representation of attribute + and assertion values transferred in the LDAP protocol. + + Syntaxes that are required for directory operation, or that are in + common use, are specified in this section. Servers SHOULD recognize + all the syntaxes listed in this document, but are not required to + otherwise support them, and MAY recognise or support other syntaxes. + However, the definition of additional arbitrary syntaxes is + discouraged since it will hinder interoperability. Client and server + implementations typically do not have the ability to dynamically + recognize new syntaxes. + + + + + +Legg Standards Track [Page 4] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.1. General Considerations + + The description of each syntax specifies how attribute or assertion + values conforming to the syntax are to be represented when + transferred in the LDAP protocol [RFC4511]. This representation is + referred to as the LDAP-specific encoding to distinguish it from + other methods of encoding attribute values (e.g., the Basic Encoding + Rules (BER) encoding [BER] used by X.500 [X.500] directories). + + The LDAP-specific encoding of a given attribute syntax always + produces octet-aligned values. To the greatest extent possible, + encoding rules for LDAP syntaxes should produce character strings + that can be displayed with little or no translation by clients + implementing LDAP. However, clients MUST NOT assume that the LDAP- + specific encoding of a value of an unrecognized syntax is a human- + readable character string. There are a few cases (e.g., the JPEG + syntax) when it is not reasonable to produce a human-readable + representation. + + Each LDAP syntax is uniquely identified with an object identifier + [ASN.1] represented in the dotted-decimal format (short descriptive + names are not defined for syntaxes). These object identifiers are + not intended to be displayed to users. The object identifiers for + the syntaxes defined in this document are summarized in Appendix A. + + A suggested minimum upper bound on the number of characters in an + attribute value with a string-based syntax, or the number of octets + in a value for all other syntaxes, MAY be indicated by appending the + bound inside of curly braces following the syntax's OBJECT IDENTIFIER + in an attribute type definition (see the <noidlen> rule in + [RFC4512]). Such a bound is not considered part of the syntax + identifier. + + For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute + definition suggests that the directory server will allow a value of + the attribute to be up to 64 characters long, although it may allow + longer character strings. Note that a single character of the + Directory String syntax can be encoded in more than one octet, since + UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- + character string may be more than 64 octets in length. + +3.2. Common Definitions + + The following ABNF rules are used in a number of the syntax + definitions in Section 3.3. + + PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / + PLUS / COMMA / HYPHEN / DOT / EQUALS / + + + +Legg Standards Track [Page 5] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + SLASH / COLON / QUESTION / SPACE + PrintableString = 1*PrintableCharacter + IA5String = *(%x00-7F) + SLASH = %x2F ; forward slash ("/") + COLON = %x3A ; colon (":") + QUESTION = %x3F ; question mark ("?") + + The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, + <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in + [RFC4512]. + +3.3. Syntax Definitions + +3.3.1. Attribute Type Description + + A value of the Attribute Type Description syntax is the definition of + an attribute type. The LDAP-specific encoding of a value of this + syntax is defined by the <AttributeTypeDescription> rule in + [RFC4512]. + + For example, the following definition of the createTimestamp + attribute type from [RFC4512] is also a value of the Attribute + Type Description syntax. (Note: Line breaks have been added for + readability; they are not part of the value when transferred in + protocol.) + + ( 2.5.18.1 NAME 'createTimestamp' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The LDAP definition for the Attribute Type Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) + + This syntax corresponds to the AttributeTypeDescription ASN.1 type + from [X.501]. + +3.3.2. Bit String + + A value of the Bit String syntax is a sequence of binary digits. The + LDAP-specific encoding of a value of this syntax is defined by the + following ABNF: + + BitString = SQUOTE *binary-digit SQUOTE "B" + binary-digit = "0" / "1" + + + +Legg Standards Track [Page 6] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The <SQUOTE> rule is defined in [RFC4512]. + + Example: + '0101111101'B + + The LDAP definition for the Bit String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) + + This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. + +3.3.3. Boolean + + A value of the Boolean syntax is one of the Boolean values, true or + false. The LDAP-specific encoding of a value of this syntax is + defined by the following ABNF: + + Boolean = "TRUE" / "FALSE" + + The LDAP definition for the Boolean syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) + + This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. + +3.3.4. Country String + + A value of the Country String syntax is one of the two-character + codes from ISO 3166 [ISO3166] for representing a country. The LDAP- + specific encoding of a value of this syntax is defined by the + following ABNF: + + CountryString = 2(PrintableCharacter) + + The <PrintableCharacter> rule is defined in Section 3.2. + + Examples: + + US + AU + + The LDAP definition for the Country String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) + + This syntax corresponds to the following ASN.1 type from [X.520]: + + PrintableString (SIZE (2)) -- ISO 3166 codes only + + + +Legg Standards Track [Page 7] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.5. Delivery Method + + A value of the Delivery Method syntax is a sequence of items that + indicate, in preference order, the service(s) by which an entity is + willing and/or capable of receiving messages. The LDAP-specific + encoding of a value of this syntax is defined by the following ABNF: + + DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) + + pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / + "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" + + The <WSP> and <DOLLAR> rules are defined in [RFC4512]. + + Example: + telephone $ videotex + + The LDAP definition for the Delivery Method syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) + + This syntax corresponds to the following ASN.1 type from [X.520]: + + SEQUENCE OF INTEGER { + any-delivery-method (0), + mhs-delivery (1), + physical-delivery (2), + telex-delivery (3), + teletex-delivery (4), + g3-facsimile-delivery (5), + g4-facsimile-delivery (6), + ia5-terminal-delivery (7), + videotex-delivery (8), + telephone-delivery (9) } + +3.3.6. Directory String + + A value of the Directory String syntax is a string of one or more + arbitrary characters from the Universal Character Set (UCS) [UCS]. A + zero-length character string is not permitted. The LDAP-specific + encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of + the character string. Such encodings conform to the following ABNF: + + DirectoryString = 1*UTF8 + + The <UTF8> rule is defined in [RFC4512]. + + + + + +Legg Standards Track [Page 8] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Example: + This is a value of Directory String containing #!%#@. + + Servers and clients MUST be prepared to receive arbitrary UCS code + points, including code points outside the range of printable ASCII + and code points not presently assigned to any character. + + Attribute type definitions using the Directory String syntax should + not restrict the format of Directory String values, e.g., by + requiring that the character string conforms to specific patterns + described by ABNF. A new syntax should be defined in such cases. + + The LDAP definition for the Directory String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) + + This syntax corresponds to the DirectoryString parameterized ASN.1 + type from [X.520]. + + The DirectoryString ASN.1 type allows a choice between the + TeletexString, PrintableString, or UniversalString ASN.1 types from + [ASN.1]. However, note that the chosen alternative is not indicated + in the LDAP-specific encoding of a Directory String value. + + Implementations that convert Directory String values from the LDAP- + specific encoding to the BER encoding used by X.500 must choose an + alternative that permits the particular characters in the string and + must convert the characters from the UTF-8 encoding into the + character encoding of the chosen alternative. When converting + Directory String values from the BER encoding to the LDAP-specific + encoding, the characters must be converted from the character + encoding of the chosen alternative into the UTF-8 encoding. These + conversions SHOULD be done in a manner consistent with the Transcode + step of the string preparation algorithms [RFC4518] for LDAP. + +3.3.7. DIT Content Rule Description + + A value of the DIT Content Rule Description syntax is the definition + of a DIT (Directory Information Tree) content rule. The LDAP- + specific encoding of a value of this syntax is defined by the + <DITContentRuleDescription> rule in [RFC4512]. + + Example: + ( 2.5.6.4 DESC 'content rule for organization' + NOT ( x121Address $ telexNumber ) ) + + Note: A line break has been added for readability; it is not part + of the value. + + + +Legg Standards Track [Page 9] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the DIT Content Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.16 + DESC 'DIT Content Rule Description' ) + + This syntax corresponds to the DITContentRuleDescription ASN.1 type + from [X.501]. + +3.3.8. DIT Structure Rule Description + + A value of the DIT Structure Rule Description syntax is the + definition of a DIT structure rule. The LDAP-specific encoding of a + value of this syntax is defined by the <DITStructureRuleDescription> + rule in [RFC4512]. + + Example: + ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) + + The LDAP definition for the DIT Structure Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.17 + DESC 'DIT Structure Rule Description' ) + + This syntax corresponds to the DITStructureRuleDescription ASN.1 type + from [X.501]. + +3.3.9. DN + + A value of the DN syntax is the (purported) distinguished name (DN) + of an entry [RFC4512]. The LDAP-specific encoding of a value of this + syntax is defined by the <distinguishedName> rule from the string + representation of distinguished names [RFC4514]. + + Examples (from [RFC4514]): + UID=jsmith,DC=example,DC=net + OU=Sales+CN=J. Smith,DC=example,DC=net + CN=John Smith\, III,DC=example,DC=net + CN=Before\0dAfter,DC=example,DC=net + 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com + CN=Lu\C4\8Di\C4\87 + + The LDAP definition for the DN syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) + + The DN syntax corresponds to the DistinguishedName ASN.1 type from + [X.501]. Note that a BER encoded distinguished name (as used by + X.500) re-encoded into the LDAP-specific encoding is not necessarily + + + +Legg Standards Track [Page 10] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + reversible to the original BER encoding since the chosen string type + in any DirectoryString components of the distinguished name is not + indicated in the LDAP-specific encoding of the distinguished name + (see Section 3.3.6). + +3.3.10. Enhanced Guide + + A value of the Enhanced Guide syntax suggests criteria, which consist + of combinations of attribute types and filter operators, to be used + in constructing filters to search for entries of particular object + classes. The Enhanced Guide syntax improves upon the Guide syntax by + allowing the recommended depth of the search to be specified. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + EnhancedGuide = object-class SHARP WSP criteria WSP + SHARP WSP subset + object-class = WSP oid WSP + subset = "baseobject" / "oneLevel" / "wholeSubtree" + + criteria = and-term *( BAR and-term ) + and-term = term *( AMPERSAND term ) + term = EXCLAIM term / + attributetype DOLLAR match-type / + LPAREN criteria RPAREN / + true / + false + match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" + true = "?true" + false = "?false" + BAR = %x7C ; vertical bar ("|") + AMPERSAND = %x26 ; ampersand ("&") + EXCLAIM = %x21 ; exclamation mark ("!") + + The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and + <DOLLAR> rules are defined in [RFC4512]. + + The LDAP definition for the Enhanced Guide syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) + + Example: + person#(sn$EQ)#oneLevel + + The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type + from [X.520]. The EnhancedGuide type references the Criteria ASN.1 + type, also from [X.520]. The <true> rule, above, represents an empty + + + +Legg Standards Track [Page 11] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + "and" expression in a value of the Criteria type. The <false> rule, + above, represents an empty "or" expression in a value of the Criteria + type. + +3.3.11. Facsimile Telephone Number + + A value of the Facsimile Telephone Number syntax is a subscriber + number of a facsimile device on the public switched telephone + network. The LDAP-specific encoding of a value of this syntax is + defined by the following ABNF: + + fax-number = telephone-number *( DOLLAR fax-parameter ) + telephone-number = PrintableString + fax-parameter = "twoDimensional" / + "fineResolution" / + "unlimitedLength" / + "b4Length" / + "a3Width" / + "b4Width" / + "uncompressed" + + The <telephone-number> is a string of printable characters that + complies with the internationally agreed format for representing + international telephone numbers [E.123]. The <PrintableString> rule + is defined in Section 3.2. The <DOLLAR> rule is defined in + [RFC4512]. + + The LDAP definition for the Facsimile Telephone Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') + + The Facsimile Telephone Number syntax corresponds to the + FacsimileTelephoneNumber ASN.1 type from [X.520]. + +3.3.12. Fax + + A value of the Fax syntax is an image that is produced using the + Group 3 facsimile process [FAX] to duplicate an object, such as a + memo. The LDAP-specific encoding of a value of this syntax is the + string of octets for a Group 3 Fax image as defined in [FAX]. + + The LDAP definition for the Fax syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) + + The ASN.1 type corresponding to the Fax syntax is defined as follows, + assuming EXPLICIT TAGS: + + + + +Legg Standards Track [Page 12] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Fax ::= CHOICE { + g3-facsimile [3] G3FacsimileBodyPart + } + + The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. + +3.3.13. Generalized Time + + A value of the Generalized Time syntax is a character string + representing a date and time. The LDAP-specific encoding of a value + of this syntax is a restriction of the format defined in [ISO8601], + and is described by the following ABNF: + + GeneralizedTime = century year month day hour + [ minute [ second / leap-second ] ] + [ fraction ] + g-time-zone + + century = 2(%x30-39) ; "00" to "99" + year = 2(%x30-39) ; "00" to "99" + month = ( %x30 %x31-39 ) ; "01" (January) to "09" + / ( %x31 %x30-32 ) ; "10" to "12" + day = ( %x30 %x31-39 ) ; "01" to "09" + / ( %x31-32 %x30-39 ) ; "10" to "29" + / ( %x33 %x30-31 ) ; "30" to "31" + hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" + minute = %x30-35 %x30-39 ; "00" to "59" + + second = ( %x30-35 %x30-39 ) ; "00" to "59" + leap-second = ( %x36 %x30 ) ; "60" + + fraction = ( DOT / COMMA ) 1*(%x30-39) + g-time-zone = %x5A ; "Z" + / g-differential + g-differential = ( MINUS / PLUS ) hour [ minute ] + MINUS = %x2D ; minus sign ("-") + + The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512]. + + The above ABNF allows character strings that do not represent valid + dates (in the Gregorian calendar) and/or valid times (e.g., February + 31, 1994). Such character strings SHOULD be considered invalid for + this syntax. + + The time value represents coordinated universal time (equivalent to + Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; + otherwise, the value represents a local time in the time zone + indicated by <g-differential>. In the latter case, coordinated + + + +Legg Standards Track [Page 13] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + universal time can be calculated by subtracting the differential from + the local time. The "Z" form of <g-time-zone> SHOULD be used in + preference to <g-differential>. + + If <minute> is omitted, then <fraction> represents a fraction of an + hour; otherwise, if <second> and <leap-second> are omitted, then + <fraction> represents a fraction of a minute; otherwise, <fraction> + represents a fraction of a second. + + Examples: + 199412161032Z + 199412160532-0500 + + Both example values represent the same coordinated universal time: + 10:32 AM, December 16, 1994. + + The LDAP definition for the Generalized Time syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) + + This syntax corresponds to the GeneralizedTime ASN.1 type from + [ASN.1], with the constraint that local time without a differential + SHALL NOT be used. + +3.3.14. Guide + + A value of the Guide syntax suggests criteria, which consist of + combinations of attribute types and filter operators, to be used in + constructing filters to search for entries of particular object + classes. The Guide syntax is obsolete and should not be used for + defining new attribute types. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + Guide = [ object-class SHARP ] criteria + + The <object-class> and <criteria> rules are defined in Section + 3.3.10. The <SHARP> rule is defined in [RFC4512]. + + The LDAP definition for the Guide syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) + + The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. + + + + + + +Legg Standards Track [Page 14] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.15. IA5 String + + A value of the IA5 String syntax is a string of zero, one, or more + characters from International Alphabet 5 (IA5) [T.50], the + international version of the ASCII character set. The LDAP-specific + encoding of a value of this syntax is the unconverted string of + characters, which conforms to the <IA5String> rule in Section 3.2. + + The LDAP definition for the IA5 String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) + + This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. + +3.3.16. Integer + + A value of the Integer syntax is a whole number of unlimited + magnitude. The LDAP-specific encoding of a value of this syntax is + the optionally signed decimal digit character string representation + of the number (for example, the number 1321 is represented by the + character string "1321"). The encoding is defined by the following + ABNF: + + Integer = ( HYPHEN LDIGIT *DIGIT ) / number + + The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in + [RFC4512]. + + The LDAP definition for the Integer syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) + + This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. + +3.3.17. JPEG + + A value of the JPEG syntax is an image in the JPEG File Interchange + Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of + a value of this syntax is the sequence of octets of the JFIF encoding + of the image. + + The LDAP definition for the JPEG syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) + + The JPEG syntax corresponds to the following ASN.1 type: + + + + + +Legg Standards Track [Page 15] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + JPEG ::= OCTET STRING (CONSTRAINED BY + { -- contents octets are an image in the -- + -- JPEG File Interchange Format -- }) + +3.3.18. LDAP Syntax Description + + A value of the LDAP Syntax Description syntax is the description of + an LDAP syntax. The LDAP-specific encoding of a value of this syntax + is defined by the <SyntaxDescription> rule in [RFC4512]. + + The LDAP definition for the LDAP Syntax Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) + + The above LDAP definition for the LDAP Syntax Description syntax is + itself a legal value of the LDAP Syntax Description syntax. + + The ASN.1 type corresponding to the LDAP Syntax Description syntax is + defined as follows, assuming EXPLICIT TAGS: + + LDAPSyntaxDescription ::= SEQUENCE { + identifier OBJECT IDENTIFIER, + description DirectoryString { ub-schema } OPTIONAL } + + The DirectoryString parameterized ASN.1 type is defined in [X.520]. + + The value of ub-schema (an integer) is implementation defined. A + non-normative definition appears in [X.520]. + +3.3.19. Matching Rule Description + + A value of the Matching Rule Description syntax is the definition of + a matching rule. The LDAP-specific encoding of a value of this + syntax is defined by the <MatchingRuleDescription> rule in [RFC4512]. + + Example: + ( 2.5.13.2 NAME 'caseIgnoreMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + Note: A line break has been added for readability; it is not part of + the syntax. + + The LDAP definition for the Matching Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) + + This syntax corresponds to the MatchingRuleDescription ASN.1 type + from [X.501]. + + + +Legg Standards Track [Page 16] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.20. Matching Rule Use Description + + A value of the Matching Rule Use Description syntax indicates the + attribute types to which a matching rule may be applied in an + extensibleMatch search filter [RFC4511]. The LDAP-specific encoding + of a value of this syntax is defined by the + <MatchingRuleUseDescription> rule in [RFC4512]. + + Example: + ( 2.5.13.16 APPLIES ( givenName $ surname ) ) + + The LDAP definition for the Matching Rule Use Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.31 + DESC 'Matching Rule Use Description' ) + + This syntax corresponds to the MatchingRuleUseDescription ASN.1 type + from [X.501]. + +3.3.21. Name and Optional UID + + A value of the Name and Optional UID syntax is the distinguished name + [RFC4512] of an entity optionally accompanied by a unique identifier + that serves to differentiate the entity from others with an identical + distinguished name. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + NameAndOptionalUID = distinguishedName [ SHARP BitString ] + + The <BitString> rule is defined in Section 3.3.2. The + <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule + is defined in [RFC4512]. + + Note that although the '#' character may occur in the string + representation of a distinguished name, no additional escaping of + this character is performed when a <distinguishedName> is encoded in + a <NameAndOptionalUID>. + + Example: + 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B + + The LDAP definition for the Name and Optional UID syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) + + + + + +Legg Standards Track [Page 17] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This syntax corresponds to the NameAndOptionalUID ASN.1 type from + [X.520]. + +3.3.22. Name Form Description + + A value of the Name Form Description syntax is the definition of a + name form, which regulates how entries may be named. The LDAP- + specific encoding of a value of this syntax is defined by the + <NameFormDescription> rule in [RFC4512]. + + Example: + ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) + + The LDAP definition for the Name Form Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) + + This syntax corresponds to the NameFormDescription ASN.1 type from + [X.501]. + +3.3.23. Numeric String + + A value of the Numeric String syntax is a sequence of one or more + numerals and spaces. The LDAP-specific encoding of a value of this + syntax is the unconverted string of characters, which conforms to the + following ABNF: + + NumericString = 1*(DIGIT / SPACE) + + The <DIGIT> and <SPACE> rules are defined in [RFC4512]. + + Example: + 15 079 672 281 + + The LDAP definition for the Numeric String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) + + This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. + +3.3.24. Object Class Description + + A value of the Object Class Description syntax is the definition of + an object class. The LDAP-specific encoding of a value of this + syntax is defined by the <ObjectClassDescription> rule in [RFC4512]. + + + + + + +Legg Standards Track [Page 18] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Example: + ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c + MAY ( searchGuide $ description ) ) + + Note: A line break has been added for readability; it is not part of + the syntax. + + The LDAP definition for the Object Class Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) + + This syntax corresponds to the ObjectClassDescription ASN.1 type from + [X.501]. + +3.3.25. Octet String + + A value of the Octet String syntax is a sequence of zero, one, or + more arbitrary octets. The LDAP-specific encoding of a value of this + syntax is the unconverted sequence of octets, which conforms to the + following ABNF: + + OctetString = *OCTET + + The <OCTET> rule is defined in [RFC4512]. Values of this syntax are + not generally human-readable. + + The LDAP definition for the Octet String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) + + This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. + +3.3.26. OID + + A value of the OID syntax is an object identifier: a sequence of two + or more non-negative integers that uniquely identify some object or + item of specification. Many of the object identifiers used in LDAP + also have IANA registered names [RFC4520]. + + The LDAP-specific encoding of a value of this syntax is defined by + the <oid> rule in [RFC4512]. + + Examples: + 1.2.3.4 + cn + + The LDAP definition for the OID syntax is: + + + + +Legg Standards Track [Page 19] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) + + This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from + [ASN.1]. + +3.3.27. Other Mailbox + + A value of the Other Mailbox syntax identifies an electronic mailbox, + in a particular named mail system. The LDAP-specific encoding of a + value of this syntax is defined by the following ABNF: + + OtherMailbox = mailbox-type DOLLAR mailbox + mailbox-type = PrintableString + mailbox = IA5String + + The <mailbox-type> rule represents the type of mail system in which + the mailbox resides (for example, "MCIMail"), and <mailbox> is the + actual mailbox in the mail system described by <mailbox-type>. The + <PrintableString> and <IA5String> rules are defined in Section 3.2. + The <DOLLAR> rule is defined in [RFC4512]. + + The LDAP definition for the Other Mailbox syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) + + The ASN.1 type corresponding to the Other Mailbox syntax is defined + as follows, assuming EXPLICIT TAGS: + + OtherMailbox ::= SEQUENCE { + mailboxType PrintableString, + mailbox IA5String + } + +3.3.28. Postal Address + + A value of the Postal Address syntax is a sequence of strings of one + or more arbitrary UCS characters, which form an address in a physical + mail system. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + + + + + + + + + +Legg Standards Track [Page 20] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + PostalAddress = line *( DOLLAR line ) + line = 1*line-char + line-char = %x00-23 + / (%x5C "24") ; escaped "$" + / %x25-5B + / (%x5C "5C") ; escaped "\" + / %x5D-7F + / UTFMB + + Each character string (i.e., <line>) of a postal address value is + encoded as a UTF-8 [RFC3629] string, except that "\" and "$" + characters, if they occur in the string, are escaped by a "\" + character followed by the two hexadecimal digit code for the + character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512]. + + Many servers limit the postal address to no more than six lines of no + more than thirty characters each. + + Example: + 1234 Main St.$Anytown, CA 12345$USA + \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA + + The LDAP definition for the Postal Address syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) + + This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; + that is + + PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF + DirectoryString { ub-postal-string } + + The values of ub-postal-line and ub-postal-string (both integers) are + implementation defined. Non-normative definitions appear in [X.520]. + +3.3.29. Printable String + + A value of the Printable String syntax is a string of one or more + latin alphabetic, numeric, and selected punctuation characters as + specified by the <PrintableCharacter> rule in Section 3.2. + + The LDAP-specific encoding of a value of this syntax is the + unconverted string of characters, which conforms to the + <PrintableString> rule in Section 3.2. + + Example: + This is a PrintableString. + + + + +Legg Standards Track [Page 21] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the PrintableString syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) + + This syntax corresponds to the PrintableString ASN.1 type from + [ASN.1]. + +3.3.30. Substring Assertion + + A value of the Substring Assertion syntax is a sequence of zero, one, + or more character substrings used as an argument for substring + extensible matching of character string attribute values; i.e., as + the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring + is a string of one or more arbitrary characters from the Universal + Character Set (UCS) [UCS]. A zero-length substring is not permitted. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + SubstringAssertion = [ initial ] any [ final ] + + initial = substring + any = ASTERISK *(substring ASTERISK) + final = substring + ASTERISK = %x2A ; asterisk ("*") + + substring = 1*substring-character + substring-character = %x00-29 + / (%x5C "2A") ; escaped "*" + / %x2B-5B + / (%x5C "5C") ; escaped "\" + / %x5D-7F + / UTFMB + + Each <substring> of a Substring Assertion value is encoded as a UTF-8 + [RFC3629] string, except that "\" and "*" characters, if they occur + in the substring, are escaped by a "\" character followed by the two + hexadecimal digit code for the character. + + The Substring Assertion syntax is used only as the syntax of + assertion values in the extensible match. It is not used as an + attribute syntax, or in the SubstringFilter [RFC4511]. + + The LDAP definition for the Substring Assertion syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) + + + + + +Legg Standards Track [Page 22] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This syntax corresponds to the SubstringAssertion ASN.1 type from + [X.520]. + +3.3.31. Telephone Number + + A value of the Telephone Number syntax is a string of printable + characters that complies with the internationally agreed format for + representing international telephone numbers [E.123]. + + The LDAP-specific encoding of a value of this syntax is the + unconverted string of characters, which conforms to the + <PrintableString> rule in Section 3.2. + + Examples: + +1 512 315 0280 + +1-512-315-0280 + +61 3 9896 7830 + + The LDAP definition for the Telephone Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) + + The Telephone Number syntax corresponds to the following ASN.1 type + from [X.520]: + + PrintableString (SIZE(1..ub-telephone-number)) + + The value of ub-telephone-number (an integer) is implementation + defined. A non-normative definition appears in [X.520]. + +3.3.32. Teletex Terminal Identifier + + A value of this syntax specifies the identifier and (optionally) + parameters of a teletex terminal. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + teletex-id = ttx-term *(DOLLAR ttx-param) + ttx-term = PrintableString ; terminal identifier + ttx-param = ttx-key COLON ttx-value ; parameter + ttx-key = "graphic" / "control" / "misc" / "page" / "private" + ttx-value = *ttx-value-octet + + ttx-value-octet = %x00-23 + / (%x5C "24") ; escaped "$" + / %x25-5B + / (%x5C "5C") ; escaped "\" + + + +Legg Standards Track [Page 23] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + / %x5D-FF + + The <PrintableString> and <COLON> rules are defined in Section 3.2. + The <DOLLAR> rule is defined in [RFC4512]. + + The LDAP definition for the Teletex Terminal Identifier syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.51 + DESC 'Teletex Terminal Identifier' ) + + This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type + from [X.520]. + +3.3.33. Telex Number + + A value of the Telex Number syntax specifies the telex number, + country code, and answerback code of a telex terminal. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + telex-number = actual-number DOLLAR country-code + DOLLAR answerback + actual-number = PrintableString + country-code = PrintableString + answerback = PrintableString + + The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> + rule is defined in [RFC4512]. + + The LDAP definition for the Telex Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) + + This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. + +3.3.34. UTC Time + + A value of the UTC Time syntax is a character string representing a + date and time to a precision of one minute or one second. The year + is given as a two-digit number. The LDAP-specific encoding of a + value of this syntax follows the format defined in [ASN.1] for the + UTCTime type and is described by the following ABNF: + + UTCTime = year month day hour minute [ second ] + [ u-time-zone ] + u-time-zone = %x5A ; "Z" + / u-differential + + + +Legg Standards Track [Page 24] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + u-differential = ( MINUS / PLUS ) hour minute + + The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> + rules are defined in Section 3.3.13. The <PLUS> rule is defined in + [RFC4512]. + + The above ABNF allows character strings that do not represent valid + dates (in the Gregorian calendar) and/or valid times. Such character + strings SHOULD be considered invalid for this syntax. + + The time value represents coordinated universal time if the "Z" form + of <u-time-zone> is used; otherwise, the value represents a local + time. In the latter case, if <u-differential> is provided, then + coordinated universal time can be calculated by subtracting the + differential from the local time. The <u-time-zone> SHOULD be + present in time values, and the "Z" form of <u-time-zone> SHOULD be + used in preference to <u-differential>. + + The LDAP definition for the UTC Time syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) + + Note: This syntax is deprecated in favor of the Generalized Time + syntax. + + The UTC Time syntax corresponds to the UTCTime ASN.1 type from + [ASN.1]. + +4. Matching Rules + + Matching rules are used by directory implementations to compare + attribute values against assertion values when performing Search and + Compare operations [RFC4511]. They are also used when comparing a + purported distinguished name [RFC4512] with the name of an entry. + When modifying entries, matching rules are used to identify values to + be deleted and to prevent an attribute from containing two equal + values. + + Matching rules that are required for directory operation, or that are + in common use, are specified in this section. + +4.1. General Considerations + + A matching rule is applied to attribute values through an + AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The + conditions under which an AttributeValueAssertion or + MatchingRuleAssertion evaluates to Undefined are specified elsewhere + [RFC4511]. If an assertion is not Undefined, then the result of the + + + +Legg Standards Track [Page 25] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + assertion is the result of applying the selected matching rule. A + matching rule evaluates to TRUE, and in some cases Undefined, as + specified in the description of the matching rule; otherwise, it + evaluates to FALSE. + + Each assertion contains an assertion value. The definition of each + matching rule specifies the syntax for the assertion value. The + syntax of the assertion value is typically, but not necessarily, the + same as the syntax of the attribute values to which the matching rule + may be applied. Note that an AssertionValue in a SubstringFilter + [RFC4511] conforms to the assertion syntax of the equality matching + rule for the attribute type rather than to the assertion syntax of + the substrings matching rule for the attribute type. Conceptually, + the entire SubstringFilter is converted into an assertion value of + the substrings matching rule prior to applying the rule. + + The definition of each matching rule indicates the attribute syntaxes + to which the rule may be applied, by specifying conditions the + corresponding ASN.1 type of a candidate attribute syntax must + satisfy. These conditions are also satisfied if the corresponding + ASN.1 type is a tagged or constrained derivative of the ASN.1 type + explicitly mentioned in the rule description (i.e., ASN.1 tags and + constraints are ignored in checking applicability), or is an + alternative reference notation for the explicitly mentioned type. + Each rule description lists, as examples of applicable attribute + syntaxes, the complete list of the syntaxes defined in this document + to which the matching rule applies. A matching rule may be + applicable to additional syntaxes defined in other documents if those + syntaxes satisfy the conditions on the corresponding ASN.1 type. + + The description of each matching rule indicates whether the rule is + suitable for use as the equality matching rule (EQUALITY), ordering + matching rule (ORDERING), or substrings matching rule (SUBSTR) in an + attribute type definition [RFC4512]. + + Each matching rule is uniquely identified with an object identifier. + The definition of a matching rule should not subsequently be changed. + If a change is desirable, then a new matching rule with a different + object identifier should be defined instead. + + Servers MAY implement the wordMatch and keywordMatch matching rules, + but they SHOULD implement the other matching rules in Section 4.2. + Servers MAY implement additional matching rules. + + Servers that implement the extensibleMatch filter SHOULD allow the + matching rules listed in Section 4.2 to be used in the + extensibleMatch filter and SHOULD allow matching rules to be used + with all attribute types known to the server, where the assertion + + + +Legg Standards Track [Page 26] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + syntax of the matching rule is the same as the value syntax of the + attribute. + + Servers MUST publish, in the matchingRules attribute, the definitions + of matching rules referenced by values of the attributeTypes and + matchingRuleUse attributes in the same subschema entry. Other + unreferenced matching rules MAY be published in the matchingRules + attribute. + + If the server supports the extensibleMatch filter, then the server + MAY use the matchingRuleUse attribute to indicate the applicability + (in an extensibleMatch filter) of selected matching rules to + nominated attribute types. + +4.2. Matching Rule Definitions + + Nominated character strings in assertion and attribute values are + prepared according to the string preparation algorithms [RFC4518] for + LDAP when evaluating the following matching rules: + + numericStringMatch, + numericStringSubstringsMatch, + caseExactMatch, + caseExactOrderingMatch, + caseExactSubstringsMatch, + caseExactIA5Match, + caseIgnoreIA5Match, + caseIgnoreIA5SubstringsMatch, + caseIgnoreListMatch, + caseIgnoreListSubstringsMatch, + caseIgnoreMatch, + caseIgnoreOrderingMatch, + caseIgnoreSubstringsMatch, + directoryStringFirstComponentMatch, + telephoneNumberMatch, + telephoneNumberSubstringsMatch and + wordMatch. + + The Transcode, Normalize, Prohibit, and Check bidi steps are the same + for each of the matching rules. However, the Map and Insignificant + Character Handling steps depend on the specific rule, as detailed in + the description of these matching rules in the sections that follow. + +4.2.1. bitStringMatch + + The bitStringMatch rule compares an assertion value of the Bit String + syntax to an attribute value of a syntax (e.g., the Bit String + syntax) whose corresponding ASN.1 type is BIT STRING. + + + +Legg Standards Track [Page 27] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + If the corresponding ASN.1 type of the attribute syntax does not have + a named bit list [ASN.1] (which is the case for the Bit String + syntax), then the rule evaluates to TRUE if and only if the attribute + value has the same number of bits as the assertion value and the bits + match on a bitwise basis. + + If the corresponding ASN.1 type does have a named bit list, then + bitStringMatch operates as above, except that trailing zero bits in + the attribute and assertion values are treated as absent. + + The LDAP definition for the bitStringMatch rule is: + + ( 2.5.13.16 NAME 'bitStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) + + The bitStringMatch rule is an equality matching rule. + +4.2.2. booleanMatch + + The booleanMatch rule compares an assertion value of the Boolean + syntax to an attribute value of a syntax (e.g., the Boolean syntax) + whose corresponding ASN.1 type is BOOLEAN. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are both TRUE or both FALSE. + + The LDAP definition for the booleanMatch rule is: + + ( 2.5.13.13 NAME 'booleanMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) + + The booleanMatch rule is an equality matching rule. + +4.2.3. caseExactIA5Match + + The caseExactIA5Match rule compares an assertion value of the IA5 + String syntax to an attribute value of a syntax (e.g., the IA5 String + syntax) whose corresponding ASN.1 type is IA5String. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + + +Legg Standards Track [Page 28] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the caseExactIA5Match rule is: + + ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + The caseExactIA5Match rule is an equality matching rule. + +4.2.4. caseExactMatch + + The caseExactMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String, Printable String, Country String, or Telephone Number syntax) + whose corresponding ASN.1 type is DirectoryString or one of the + alternative string types of DirectoryString, such as PrintableString + (the other alternatives do not correspond to any syntax defined in + this document). + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseExactMatch rule is: + + ( 2.5.13.5 NAME 'caseExactMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseExactMatch rule is an equality matching rule. + +4.2.5. caseExactOrderingMatch + + The caseExactOrderingMatch rule compares an assertion value of the + Directory String syntax to an attribute value of a syntax (e.g., the + Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + + + + +Legg Standards Track [Page 29] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseExactOrderingMatch rule is: + + ( 2.5.13.6 NAME 'caseExactOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseExactOrderingMatch rule is an ordering matching rule. + +4.2.6. caseExactSubstringsMatch + + The caseExactSubstringsMatch rule compares an assertion value of the + Substring Assertion syntax to an attribute value of a syntax (e.g., + the Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are not case folded in the Map preparation + step, and only Insignificant Space Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the caseExactSubstringsMatch rule is: + + ( 2.5.13.7 NAME 'caseExactSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseExactSubstringsMatch rule is a substrings matching rule. + +4.2.7. caseIgnoreIA5Match + + The caseIgnoreIA5Match rule compares an assertion value of the IA5 + String syntax to an attribute value of a syntax (e.g., the IA5 String + syntax) whose corresponding ASN.1 type is IA5String. + + + + +Legg Standards Track [Page 30] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreIA5Match rule is: + + ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + The caseIgnoreIA5Match rule is an equality matching rule. + +4.2.8. caseIgnoreIA5SubstringsMatch + + The caseIgnoreIA5SubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the IA5 String syntax) whose corresponding ASN.1 type is + IA5String. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. + +4.2.9. caseIgnoreListMatch + + The caseIgnoreListMatch rule compares an assertion value that is a + sequence of strings to an attribute value of a syntax (e.g., the + + + +Legg Standards Track [Page 31] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE + OF the DirectoryString ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value have the same number of strings and corresponding + strings (by position) match according to the caseIgnoreMatch matching + rule. + + In [X.520], the assertion syntax for this matching rule is defined to + be: + + SEQUENCE OF DirectoryString {ub-match} + + That is, it is different from the corresponding type for the Postal + Address syntax. The choice of the Postal Address syntax for the + assertion syntax of the caseIgnoreListMatch in LDAP should not be + seen as limiting the matching rule to apply only to attributes with + the Postal Address syntax. + + The LDAP definition for the caseIgnoreListMatch rule is: + + ( 2.5.13.11 NAME 'caseIgnoreListMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) + + The caseIgnoreListMatch rule is an equality matching rule. + +4.2.10. caseIgnoreListSubstringsMatch + + The caseIgnoreListSubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a + SEQUENCE OF the DirectoryString ASN.1 type. + + The rule evaluates to TRUE if and only if the assertion value + matches, per the caseIgnoreSubstringsMatch rule, the character string + formed by concatenating the strings of the attribute value, except + that none of the <initial>, <any>, or <final> substrings of the + assertion value are considered to match a substring of the + concatenated string which spans more than one of the original strings + of the attribute value. + + Note that, in terms of the LDAP-specific encoding of the Postal + Address syntax, the concatenated string omits the <DOLLAR> line + separator and the escaping of "\" and "$" characters. + + The LDAP definition for the caseIgnoreListSubstringsMatch rule is: + + ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' + + + +Legg Standards Track [Page 32] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreListSubstringsMatch rule is a substrings matching rule. + +4.2.11. caseIgnoreMatch + + The caseIgnoreMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String, Printable String, Country String, or Telephone Number syntax) + whose corresponding ASN.1 type is DirectoryString or one of its + alternative string types. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreMatch rule is: + + ( 2.5.13.2 NAME 'caseIgnoreMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseIgnoreMatch rule is an equality matching rule. + +4.2.12. caseIgnoreOrderingMatch + + The caseIgnoreOrderingMatch rule compares an assertion value of the + Directory String syntax to an attribute value of a syntax (e.g., the + Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreOrderingMatch rule is: + + + +Legg Standards Track [Page 33] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseIgnoreOrderingMatch rule is an ordering matching rule. + +4.2.13. caseIgnoreSubstringsMatch + + The caseIgnoreSubstringsMatch rule compares an assertion value of the + Substring Assertion syntax to an attribute value of a syntax (e.g., + the Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreSubstringsMatch rule is: + + ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreSubstringsMatch rule is a substrings matching rule. + +4.2.14. directoryStringFirstComponentMatch + + The directoryStringFirstComponentMatch rule compares an assertion + value of the Directory String syntax to an attribute value of a + syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory + first component of the DirectoryString ASN.1 type. + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + + + + + +Legg Standards Track [Page 34] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the assertion value matches + the first component of the attribute value using the rules of + caseIgnoreMatch. + + The LDAP definition for the directoryStringFirstComponentMatch + matching rule is: + + ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The directoryStringFirstComponentMatch rule is an equality matching + rule. When using directoryStringFirstComponentMatch to compare two + attribute values (of an applicable syntax), an assertion value must + first be derived from one of the attribute values. An assertion + value can be derived from an attribute value by taking the first + component of that attribute value. + +4.2.15. distinguishedNameMatch + + The distinguishedNameMatch rule compares an assertion value of the DN + syntax to an attribute value of a syntax (e.g., the DN syntax) whose + corresponding ASN.1 type is DistinguishedName. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value have the same number of relative distinguished names + and corresponding relative distinguished names (by position) are the + same. A relative distinguished name (RDN) of the assertion value is + the same as an RDN of the attribute value if and only if they have + the same number of attribute value assertions and each attribute + value assertion (AVA) of the first RDN is the same as the AVA of the + second RDN with the same attribute type. The order of the AVAs is + not significant. Also note that a particular attribute type may + appear in at most one AVA in an RDN. Two AVAs with the same + attribute type are the same if their values are equal according to + the equality matching rule of the attribute type. If one or more of + the AVA comparisons evaluate to Undefined and the remaining AVA + comparisons return TRUE then the distinguishedNameMatch rule + evaluates to Undefined. + + The LDAP definition for the distinguishedNameMatch rule is: + + ( 2.5.13.1 NAME 'distinguishedNameMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The distinguishedNameMatch rule is an equality matching rule. + + + + + + +Legg Standards Track [Page 35] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.16. generalizedTimeMatch + + The generalizedTimeMatch rule compares an assertion value of the + Generalized Time syntax to an attribute value of a syntax (e.g., the + Generalized Time syntax) whose corresponding ASN.1 type is + GeneralizedTime. + + The rule evaluates to TRUE if and only if the attribute value + represents the same universal coordinated time as the assertion + value. If a time is specified with the minutes or seconds absent, + then the number of minutes or seconds (respectively) is assumed to be + zero. + + The LDAP definition for the generalizedTimeMatch rule is: + + ( 2.5.13.27 NAME 'generalizedTimeMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) + + The generalizedTimeMatch rule is an equality matching rule. + +4.2.17. generalizedTimeOrderingMatch + + The generalizedTimeOrderingMatch rule compares the time ordering of + an assertion value of the Generalized Time syntax to an attribute + value of a syntax (e.g., the Generalized Time syntax) whose + corresponding ASN.1 type is GeneralizedTime. + + The rule evaluates to TRUE if and only if the attribute value + represents a universal coordinated time that is earlier than the + universal coordinated time represented by the assertion value. + + The LDAP definition for the generalizedTimeOrderingMatch rule is: + + ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) + + The generalizedTimeOrderingMatch rule is an ordering matching rule. + +4.2.18. integerFirstComponentMatch + + The integerFirstComponentMatch rule compares an assertion value of + the Integer syntax to an attribute value of a syntax (e.g., the DIT + Structure Rule Description syntax) whose corresponding ASN.1 type is + a SEQUENCE with a mandatory first component of the INTEGER ASN.1 + type. + + + + + + +Legg Standards Track [Page 36] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + The rule evaluates to TRUE if and only if the assertion value and the + first component of the attribute value are the same integer value. + + The LDAP definition for the integerFirstComponentMatch matching rule + is: + + ( 2.5.13.29 NAME 'integerFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerFirstComponentMatch rule is an equality matching rule. + When using integerFirstComponentMatch to compare two attribute values + (of an applicable syntax), an assertion value must first be derived + from one of the attribute values. An assertion value can be derived + from an attribute value by taking the first component of that + attribute value. + +4.2.19. integerMatch + + The integerMatch rule compares an assertion value of the Integer + syntax to an attribute value of a syntax (e.g., the Integer syntax) + whose corresponding ASN.1 type is INTEGER. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are the same integer value. + + The LDAP definition for the integerMatch matching rule is: + + ( 2.5.13.14 NAME 'integerMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerMatch rule is an equality matching rule. + +4.2.20. integerOrderingMatch + + The integerOrderingMatch rule compares an assertion value of the + Integer syntax to an attribute value of a syntax (e.g., the Integer + syntax) whose corresponding ASN.1 type is INTEGER. + + The rule evaluates to TRUE if and only if the integer value of the + attribute value is less than the integer value of the assertion + value. + + The LDAP definition for the integerOrderingMatch matching rule is: + + + + +Legg Standards Track [Page 37] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 2.5.13.15 NAME 'integerOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerOrderingMatch rule is an ordering matching rule. + +4.2.21. keywordMatch + + The keywordMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String syntax) whose corresponding ASN.1 type is DirectoryString. + + The rule evaluates to TRUE if and only if the assertion value + character string matches any keyword in the attribute value. The + identification of keywords in the attribute value and the exactness + of the match are both implementation specific. + + The LDAP definition for the keywordMatch rule is: + + ( 2.5.13.33 NAME 'keywordMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + +4.2.22. numericStringMatch + + The numericStringMatch rule compares an assertion value of the + Numeric String syntax to an attribute value of a syntax (e.g., the + Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the numericStringMatch matching rule is: + + ( 2.5.13.8 NAME 'numericStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + The numericStringMatch rule is an equality matching rule. + + + + + + + +Legg Standards Track [Page 38] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.23. numericStringOrderingMatch + + The numericStringOrderingMatch rule compares an assertion value of + the Numeric String syntax to an attribute value of a syntax (e.g., + the Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The rule is identical to the caseIgnoreOrderingMatch rule except that + all space characters are skipped during comparison (case is + irrelevant as the characters are numeric). + + The LDAP definition for the numericStringOrderingMatch matching rule + is: + + ( 2.5.13.9 NAME 'numericStringOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + The numericStringOrderingMatch rule is an ordering matching rule. + +4.2.24. numericStringSubstringsMatch + + The numericStringSubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + + + +Legg Standards Track [Page 39] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the numericStringSubstringsMatch matching + rule is: + + ( 2.5.13.10 NAME 'numericStringSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The numericStringSubstringsMatch rule is a substrings matching rule. + +4.2.25. objectIdentifierFirstComponentMatch + + The objectIdentifierFirstComponentMatch rule compares an assertion + value of the OID syntax to an attribute value of a syntax (e.g., the + Attribute Type Description, DIT Content Rule Description, LDAP Syntax + Description, Matching Rule Description, Matching Rule Use + Description, Name Form Description, or Object Class Description + syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory + first component of the OBJECT IDENTIFIER ASN.1 type. + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + The rule evaluates to TRUE if and only if the assertion value matches + the first component of the attribute value using the rules of + objectIdentifierMatch. + + The LDAP definition for the objectIdentifierFirstComponentMatch + matching rule is: + + ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The objectIdentifierFirstComponentMatch rule is an equality matching + rule. When using objectIdentifierFirstComponentMatch to compare two + attribute values (of an applicable syntax), an assertion value must + first be derived from one of the attribute values. An assertion + value can be derived from an attribute value by taking the first + component of that attribute value. + +4.2.26. objectIdentifierMatch + + The objectIdentifierMatch rule compares an assertion value of the OID + syntax to an attribute value of a syntax (e.g., the OID syntax) whose + corresponding ASN.1 type is OBJECT IDENTIFIER. + + + + +Legg Standards Track [Page 40] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the assertion value and the + attribute value represent the same object identifier; that is, the + same sequence of integers, whether represented explicitly in the + <numericoid> form of <oid> or implicitly in the <descr> form (see + [RFC4512]). + + If an LDAP client supplies an assertion value in the <descr> form and + the chosen descriptor is not recognized by the server, then the + objectIdentifierMatch rule evaluates to Undefined. + + The LDAP definition for the objectIdentifierMatch matching rule is: + + ( 2.5.13.0 NAME 'objectIdentifierMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The objectIdentifierMatch rule is an equality matching rule. + +4.2.27. octetStringMatch + + The octetStringMatch rule compares an assertion value of the Octet + String syntax to an attribute value of a syntax (e.g., the Octet + String or JPEG syntax) whose corresponding ASN.1 type is the OCTET + STRING ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are the same length and corresponding octets (by + position) are the same. + + The LDAP definition for the octetStringMatch matching rule is: + + ( 2.5.13.17 NAME 'octetStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + + The octetStringMatch rule is an equality matching rule. + +4.2.28. octetStringOrderingMatch + + The octetStringOrderingMatch rule compares an assertion value of the + Octet String syntax to an attribute value of a syntax (e.g., the + Octet String or JPEG syntax) whose corresponding ASN.1 type is the + OCTET STRING ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value appears + earlier in the collation order than the assertion value. The rule + compares octet strings from the first octet to the last octet, and + from the most significant bit to the least significant bit within the + octet. The first occurrence of a different bit determines the + ordering of the strings. A zero bit precedes a one bit. If the + + + +Legg Standards Track [Page 41] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + strings contain different numbers of octets but the longer string is + identical to the shorter string up to the length of the shorter + string, then the shorter string precedes the longer string. + + The LDAP definition for the octetStringOrderingMatch matching rule + is: + + ( 2.5.13.18 NAME 'octetStringOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + + The octetStringOrderingMatch rule is an ordering matching rule. + +4.2.29. telephoneNumberMatch + + The telephoneNumberMatch rule compares an assertion value of the + Telephone Number syntax to an attribute value of a syntax (e.g., the + Telephone Number syntax) whose corresponding ASN.1 type is a + PrintableString representing a telephone number. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + telephoneNumber Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the telephoneNumberMatch matching rule is: + + ( 2.5.13.20 NAME 'telephoneNumberMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + The telephoneNumberMatch rule is an equality matching rule. + +4.2.30. telephoneNumberSubstringsMatch + + The telephoneNumberSubstringsMatch rule compares an assertion value + of the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is + a PrintableString representing a telephone number. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + + + +Legg Standards Track [Page 42] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only telephoneNumber Insignificant Character Handling is applied + in the Insignificant Character Handling step. + + The LDAP definition for the telephoneNumberSubstringsMatch matching + rule is: + + ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The telephoneNumberSubstringsMatch rule is a substrings matching + rule. + +4.2.31. uniqueMemberMatch + + The uniqueMemberMatch rule compares an assertion value of the Name + And Optional UID syntax to an attribute value of a syntax (e.g., the + Name And Optional UID syntax) whose corresponding ASN.1 type is + NameAndOptionalUID. + + The rule evaluates to TRUE if and only if the <distinguishedName> + components of the assertion value and attribute value match according + to the distinguishedNameMatch rule and either, (1) the <BitString> + component is absent from both the attribute value and assertion + value, or (2) the <BitString> component is present in both the + attribute value and the assertion value and the <BitString> component + of the assertion value matches the <BitString> component of the + attribute value according to the bitStringMatch rule. + + Note that this matching rule has been altered from its description in + X.520 [X.520] in order to make the matching rule commutative. Server + implementors should consider using the original X.520 semantics + (where the matching was less exact) for approximate matching of + attributes with uniqueMemberMatch as the equality matching rule. + + The LDAP definition for the uniqueMemberMatch matching rule is: + + ( 2.5.13.23 NAME 'uniqueMemberMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) + + The uniqueMemberMatch rule is an equality matching rule. + + + + +Legg Standards Track [Page 43] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.32. wordMatch + + The wordMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String syntax) whose corresponding ASN.1 type is DirectoryString. + + The rule evaluates to TRUE if and only if the assertion value word + matches, according to the semantics of caseIgnoreMatch, any word in + the attribute value. The precise definition of a word is + implementation specific. + + The LDAP definition for the wordMatch rule is: + + ( 2.5.13.32 NAME 'wordMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + +5. Security Considerations + + In general, the LDAP-specific encodings for syntaxes defined in this + document do not define canonical encodings. That is, a + transformation from an LDAP-specific encoding into some other + encoding (e.g., BER) and back into the LDAP-specific encoding will + not necessarily reproduce exactly the original octets of the LDAP- + specific encoding. Therefore, an LDAP-specific encoding should not + be used where a canonical encoding is required. + + Furthermore, the LDAP-specific encodings do not necessarily enable an + alternative encoding of values of the Directory String and DN + syntaxes to be reconstructed; e.g., a transformation from a + Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific + encoding and back to a DER encoding may not reproduce the original + DER encoding. Therefore, LDAP-specific encodings should not be used + where reversibility to DER is needed; e.g., for the verification of + digital signatures. Instead, DER or a DER-reversible encoding should + be used. + + When interpreting security-sensitive fields (in particular, fields + used to grant or deny access), implementations MUST ensure that any + matching rule comparisons are done on the underlying abstract value, + regardless of the particular encoding used. + +6. Acknowledgements + + This document is primarily a revision of RFC 2252 by M. Wahl, A. + Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF + ASID Working Group. + + + + + +Legg Standards Track [Page 44] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This document is based on input from the IETF LDAPBIS working group. + The author would like to thank Kathy Dally for editing the early + drafts of this document, and Jim Sermersheim and Kurt Zeilenga for + their significant contributions to this revision. + +7. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry [BCP64] as indicated by the following templates: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comment + Object Identifier: see comment + Person & email address to contact for further information: + Steven Legg <steven.legg@eb2bcom.com> + Usage: see comment + Specification: RFC 4517 + Author/Change Controller: IESG + + NAME Type OID + ------------------------------------------------------------------ + bitStringMatch M 2.5.13.16 + booleanMatch M 2.5.13.13 + caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 + caseExactMatch M 2.5.13.5 + caseExactOrderingMatch M 2.5.13.6 + caseExactSubstringsMatch M 2.5.13.7 + caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 + caseIgnoreListMatch M 2.5.13.11 + caseIgnoreListSubstringsMatch M 2.5.13.12 + caseIgnoreMatch M 2.5.13.2 + caseIgnoreOrderingMatch M 2.5.13.3 + caseIgnoreSubstringsMatch M 2.5.13.4 + directoryStringFirstComponentMatch M 2.5.13.31 + distinguishedNameMatch M 2.5.13.1 + generalizedTimeMatch M 2.5.13.27 + generalizedTimeOrderingMatch M 2.5.13.28 + integerFirstComponentMatch M 2.5.13.29 + integerMatch M 2.5.13.14 + integerOrderingMatch M 2.5.13.15 + keywordMatch M 2.5.13.33 + numericStringMatch M 2.5.13.8 + numericStringOrderingMatch M 2.5.13.9 + numericStringSubstringsMatch M 2.5.13.10 + objectIdentifierFirstComponentMatch M 2.5.13.30 + octetStringMatch M 2.5.13.17 + octetStringOrderingMatch M 2.5.13.18 + telephoneNumberMatch M 2.5.13.20 + + + +Legg Standards Track [Page 45] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + telephoneNumberSubstringsMatch M 2.5.13.21 + uniqueMemberMatch M 2.5.13.23 + wordMatch M 2.5.13.32 + + The descriptor for the object identifier 2.5.13.0 was incorrectly + registered as objectIdentifiersMatch (extraneous \`s') in BCP 64. + It has been changed to the following, with a reference to + RFC 4517. + + NAME Type OID + ------------------------------------------------------------------ + objectIdentifierMatch M 2.5.13.0 + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): caseIgnoreIA5SubstringsMatch + Object Identifier: 1.3.6.1.4.1.1466.109.114.3 + Person & email address to contact for further information: + Steven Legg <steven.legg@eb2bcom.com> + Usage: other (M) + Specification: RFC 4517 + Author/Change Controller: IESG + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + + + + + +Legg Standards Track [Page 46] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", RFC + 4514, June 2006. + + [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Internationalized String Preparation", RFC 4518, + June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [E.123] Notation for national and international telephone numbers, + ITU-T Recommendation E.123, 1988. + + [FAX] Standardization of Group 3 facsimile apparatus for + document transmission - Terminal Equipment and Protocols + for Telematic Services, ITU-T Recommendation T.4, 1993 + + [T.50] International Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) Information + Technology - 7-Bit Coded Character Set for Information + Interchange, ITU-T Recommendation T.50, 1992 + + [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, + Information Technology - Message Handling Systems (MHS): + Interpersonal messaging system + + [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, + Information Technology - Open Systems Interconnection - + The Directory: Models + + [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information Technology - Open Systems Interconnection - + The Directory: Selected attribute types + + [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation + + [ISO3166] ISO 3166, "Codes for the representation of names of + countries". + + [ISO8601] ISO 8601:2004, "Data elements and interchange formats -- + Information interchange -- Representation of dates and + times". + + + + + +Legg Standards Track [Page 47] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + [UCS] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC 10646- + 1: 1993 (with amendments). + + [JPEG] JPEG File Interchange Format (Version 1.02). Eric + Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, + 1992. + +8.2. Informative References + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol + (LDAP): Schema for User Applications", RFC 4519, June + 2006. + + [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Schema Definitions for X.509 Certificates", RFC + 4523, June 2006. + + [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - + The Directory: Overview of concepts, models and services + + [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER) + + + + + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 48] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +Appendix A. Summary of Syntax Object Identifiers + + The following list summarizes the object identifiers assigned to the + syntaxes defined in this document. + + Syntax OBJECT IDENTIFIER + ============================================================== + Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 + Bit String 1.3.6.1.4.1.1466.115.121.1.6 + Boolean 1.3.6.1.4.1.1466.115.121.1.7 + Country String 1.3.6.1.4.1.1466.115.121.1.11 + Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 + Directory String 1.3.6.1.4.1.1466.115.121.1.15 + DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 + DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 + DN 1.3.6.1.4.1.1466.115.121.1.12 + Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 + Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 + Fax 1.3.6.1.4.1.1466.115.121.1.23 + Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 + Guide 1.3.6.1.4.1.1466.115.121.1.25 + IA5 String 1.3.6.1.4.1.1466.115.121.1.26 + Integer 1.3.6.1.4.1.1466.115.121.1.27 + JPEG 1.3.6.1.4.1.1466.115.121.1.28 + LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 + Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 + Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 + Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 + Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 + Numeric String 1.3.6.1.4.1.1466.115.121.1.36 + Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 + Octet String 1.3.6.1.4.1.1466.115.121.1.40 + OID 1.3.6.1.4.1.1466.115.121.1.38 + Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 + Postal Address 1.3.6.1.4.1.1466.115.121.1.41 + Printable String 1.3.6.1.4.1.1466.115.121.1.44 + Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 + Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 + Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 + Telex Number 1.3.6.1.4.1.1466.115.121.1.52 + UTC Time 1.3.6.1.4.1.1466.115.121.1.53 + +Appendix B. Changes from RFC 2252 + + This annex lists the significant differences between this + specification and RFC 2252. + + + + + +Legg Standards Track [Page 49] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This annex is provided for informational purposes only. It is not a + normative part of this specification. + + 1. The IESG Note has been removed. + + 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] + and revised. Changes to the parts of these sections moved to + [RFC4512] are detailed in [RFC4512]. + + 3. BNF descriptions of syntax formats have been replaced by ABNF + [RFC4234] specifications. + + 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the + use of a backslash quoting mechanism to escape separator symbols + has been removed. The escaping mechanism is now explicitly + represented in the ABNF for the syntaxes where this provision + applies. + + 5. The description of each of the LDAP syntaxes has been expanded so + that they are less dependent on knowledge of X.500 for + interpretation. + + 6. The relationship of LDAP syntaxes to corresponding ASN.1 type + definitions has been made explicit. + + 7. The set of characters allowed in a <PrintableString> (formerly + <printablestring>) has been corrected to align with the + PrintableString ASN.1 type in [ASN.1]. Specifically, the double + quote character has been removed and the single quote character + and equals sign have been added. + + 8. Values of the Directory String, Printable String and Telephone + Number syntaxes are now required to have at least one character. + + 9. The <DITContentRuleDescription>, <NameFormDescription> and + <DITStructureRuleDescription> rules have been moved to [RFC4512]. + + 10. The corresponding ASN.1 type for the Other Mailbox syntax has + been incorporated from RFC 1274. + + 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax + has been invented. + + 12. The Binary syntax has been removed because it was not adequately + specified, implementations with different incompatible + interpretations exist, and it was confused with the ;binary + transfer encoding. + + + + +Legg Standards Track [Page 50] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 13. All discussion of transfer options, including the ";binary" + option, has been removed. All imperatives regarding binary + transfer of values have been removed. + + 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex + Terminal Identifier and Telex Number syntaxes from RFC 2256 have + been incorporated. + + 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has + been extended to accommodate empty "and" and "or" expressions. + + 16. An encoding for the <ttx-value> rule in the Teletex Terminal + Identifier syntax has been defined. + + 17. The PKI-related syntaxes (Certificate, Certificate List and + Certificate Pair) have been removed. They are reintroduced in + [RFC4523] (as is the Supported Algorithm syntax from RFC 2256). + + 18. The MHS OR Address syntax has been removed since its + specification (in RFC 2156) is not at draft standard maturity. + + 19. The DL Submit Permission syntax has been removed as it depends on + the MHS OR Address syntax. + + 20. The Presentation Address syntax has been removed since its + specification (in RFC 1278) is not at draft standard maturity. + + 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE + Type, LDAP Schema Description, Master And Shadow Access Points, + Modify Rights, Protocol Information, Subtree Specification, + Supplier Information, Supplier Or Consumer and Supplier And + Consumer syntaxes have been removed. These syntaxes are + referenced in RFC 2252, but not defined. + + 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the + Mail Preference syntax have been removed on the grounds that they + are out of scope for the core specification. + + 23. The description of each of the matching rules has been expanded + so that they are less dependent on knowledge of X.500 for + interpretation. + + 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has + been added. + + 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and + caseIgnoreSubstringsMatch matching rules have been added to the + list of matching rules for which the provisions for handling + + + +Legg Standards Track [Page 51] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + leading, trailing and multiple adjoining whitespace characters + apply (now through string preparation). This is consistent with + the definitions of these matching rules in X.500. The + caseIgnoreIA5SubstringsMatch rule has also been added to the + list. + + 26. The specification of the octetStringMatch matching rule from + RFC 2256 has been added to this document. + + 27. The presentationAddressMatch matching rule has been removed as it + depends on an assertion syntax (Presentation Address) that is not + at draft standard maturity. + + 28. The protocolInformationMatch matching rule has been removed as it + depends on an undefined assertion syntax (Protocol Information). + + 29. The definitive reference for ASN.1 has been changed from X.208 to + X.680 since X.680 is the version of ASN.1 referred to by X.500. + + 30. The specification of the caseIgnoreListSubstringsMatch matching + rule from RFC 2798 & X.520 has been added. + + 31. String preparation algorithms have been applied to the character + string matching rules. + + 32. The specifications of the booleanMatch, caseExactMatch, + caseExactOrderingMatch, caseExactSubstringsMatch, + directoryStringFirstComponentMatch, integerOrderingMatch, + keywordMatch, numericStringOrderingMatch, + octetStringOrderingMatch and wordMatch matching rules from + RFC 3698 & X.520 have been added. + +Author's Address + + Steven Legg + eB2Bcom + Suite3, Woodhouse Corporate Centre + 935 Station Street + Box Hill North, Victoria 3129 + AUSTRALIA + + Phone: +61 3 9896 7830 + Fax: +61 3 9896 7801 + EMail: steven.legg@eb2bcom.com + + + + + + + +Legg Standards Track [Page 52] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Legg Standards Track [Page 53] + diff --git a/source4/ldap_server/devdocs/rfc4518.txt b/source4/ldap_server/devdocs/rfc4518.txt new file mode 100644 index 0000000000..f886bdfb5d --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4518.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4518 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP): + Internationalized String Preparation + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The previous Lightweight Directory Access Protocol (LDAP) technical + specifications did not precisely define how character string matching + is to be performed. This led to a number of usability and + interoperability problems. This document defines string preparation + algorithms for character-based matching rules defined for use in + LDAP. + +1. Introduction + +1.1. Background + + A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching + rule [RFC4517] defines an algorithm for determining whether a + presented value matches an attribute value in accordance with the + criteria defined for the rule. The proposition may be evaluated to + True, False, or Undefined. + + True - the attribute contains a matching value, + + False - the attribute contains no matching value, + + Undefined - it cannot be determined whether the attribute contains + a matching value. + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + For instance, the caseIgnoreMatch matching rule may be used to + compare whether the commonName attribute contains a particular value + without regard for case and insignificant spaces. + +1.2. X.500 String Matching Rules + + "X.520: Selected attribute types" [X.520] provides (among other + things) value syntaxes and matching rules for comparing values + commonly used in the directory [X.500]. These specifications are + inadequate for strings composed of Unicode [Unicode] characters. + + The caseIgnoreMatch matching rule [X.520], for example, is simply + defined as being a case-insensitive comparison where insignificant + spaces are ignored. For printableString, there is only one space + character and case mapping is bijective, hence this definition is + sufficient. However, for Unicode string types such as + universalString, this is not sufficient. For example, a case- + insensitive matching implementation that folded lowercase characters + to uppercase would yield different results than an implementation + that used uppercase to lowercase folding. Or one implementation may + view space as referring to only SPACE (U+0020), a second + implementation may view any character with the space separator (Zs) + property as a space, and another implementation may view any + character with the whitespace (WS) category as a space. + + The lack of precise specification for character string matching has + led to significant interoperability problems. When used in + certificate chain validation, security vulnerabilities can arise. To + address these problems, this document defines precise algorithms for + preparing character strings for matching. + +1.3. Relationship to "stringprep" + + The character string preparation algorithms described in this + document are based upon the "stringprep" approach [RFC3454]. In + "stringprep", presented and stored values are first prepared for + comparison so that a character-by-character comparison yields the + "correct" result. + + The approach used here is a refinement of the "stringprep" [RFC3454] + approach. Each algorithm involves two additional preparation steps. + + a) Prior to applying the Unicode string preparation steps outlined in + "stringprep", the string is transcoded to Unicode. + + b) After applying the Unicode string preparation steps outlined in + "stringprep", the string is modified to appropriately handle + characters insignificant to the matching rule. + + + +Zeilenga Standards Track [Page 2] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + Hence, preparation of character strings for X.500 [X.500] matching + [X.501] involves the following steps: + + 1) Transcode + 2) Map + 3) Normalize + 4) Prohibit + 5) Check Bidi (Bidirectional) + 6) Insignificant Character Handling + + These steps are described in Section 2. + + It is noted that while various tables of Unicode characters included + or referenced by this specification are derived from Unicode + [Unicode] data, these tables are to be considered definitive for the + purpose of implementing this specification. + +1.4. Relationship to the LDAP Technical Specification + + This document is an integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification [RFC3377] in its entirety. + + This document details new LDAP internationalized character string + preparation algorithms used by [RFC4517] and possible other technical + specifications defining LDAP syntaxes and/or matching rules. + +1.5. Relationship to X.500 + + LDAP is defined [RFC4510] in X.500 terms as an X.500 access + mechanism. As such, there is a strong desire for alignment between + LDAP and X.500 syntax and semantics. The character string + preparation algorithms described in this document are based upon + "Internationalized String Matching Rules for X.500" [XMATCH] proposal + to ITU/ISO Joint Study Group 2. + +1.6. Conventions and Terms + + 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 <U+0061> or <LATIN SMALL LETTER A>. + In the lists of mappings and the prohibited characters, the "U+" is + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + left off to make the lists easier to read. The comments for + character ranges are shown in square brackets (such as "[CONTROL + CHARACTERS]") and do not come from the standard. + + 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]. + + The term "combining mark", as used in this specification, refers to + any Unicode [Unicode] code point that has a mark property (Mn, Mc, + Me). Appendix A provides a definitive list of combining marks. + +2. String Preparation + + The following six-step process SHALL be applied to each presented and + attribute value in preparation for character string matching rule + evaluation. + + 1) Transcode + 2) Map + 3) Normalize + 4) Prohibit + 5) Check bidi + 6) Insignificant Character Handling + + Failure in any step causes the assertion to evaluate to Undefined. + + The character repertoire of this process is Unicode 3.2 [Unicode]. + + Note that this six-step process specification is intended to describe + expected matching behavior. Implementations are free to use + alternative processes so long as the matching rule evaluation + behavior provided is consistent with the behavior described by this + specification. + +2.1. Transcode + + Each non-Unicode string value is transcoded to Unicode. + + PrintableString [X.680] values are transcoded directly to Unicode. + + UniversalString, UTF8String, and bmpString [X.680] values need not be + transcoded as they are Unicode-based strings (in the case of + bmpString, a subset of Unicode). + + TeletexString [X.680] values are transcoded to Unicode. As there is + no standard for mapping TeletexString values to Unicode, the mapping + is left a local matter. + + + +Zeilenga Standards Track [Page 4] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + For these and other reasons, use of TeletexString is NOT RECOMMENDED. + + The output is the transcoded string. + +2.2. Map + + SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code + points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and + VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also + mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is + mapped to nothing. + + CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE + TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR) + (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020). + + All other control code (e.g., Cc) points or code points with a + control function (e.g., Cf) are mapped to nothing. The following is + a complete list of these code points: U+0000-0008, 000E-001F, 007F- + 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063, + 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F. + + ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code + points with Separator (space, line, or paragraph) property (e.g., Zs, + Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete + list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, + 202F, 205F, 3000. + + For case ignore, numeric, and stored prefix string matching rules, + characters are case folded per B.2 of [RFC3454]. + + The output is the mapped string. + +2.3. Normalize + + The input string is to be normalized to Unicode Form KC + (compatibility composed) as described in [UAX15]. The output is the + normalized string. + +2.4. Prohibit + + All Unassigned code points are prohibited. Unassigned code points + are listed in Table A.1 of [RFC3454]. + + Characters that, per Section 5.8 of [RFC3454], change display + properties or are deprecated are prohibited. These characters are + listed in Table C.8 of [RFC3454]. + + + + +Zeilenga Standards Track [Page 5] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + Private Use code points are prohibited. These characters are listed + in Table C.3 of [RFC3454]. + + All non-character code points are prohibited. These code points are + listed in Table C.4 of [RFC3454]. + + Surrogate codes are prohibited. These characters are listed in Table + C.5 of [RFC3454]. + + The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited. + + The step fails if the input string contains any prohibited code + point. Otherwise, the output is the input string. + +2.5. Check bidi + + Bidirectional characters are ignored. + +2.6. Insignificant Character Handling + + In this step, the string is modified to ensure proper handling of + characters insignificant to the matching rule. This modification + differs from matching rule to matching rule. + + Section 2.6.1 applies to case ignore and exact string matching. + Section 2.6.2 applies to numericString matching. + Section 2.6.3 applies to telephoneNumber matching. + +2.6.1. Insignificant Space Handling + + For the purposes of this section, a space is defined to be the SPACE + (U+0020) code point followed by no combining marks. + + NOTE - The previous steps ensure that the string cannot contain + any code points in the separator class, other than SPACE + (U+0020). + + For input strings that are attribute values or non-substring + assertion values: If the input string contains no non-space + character, then the output is exactly two SPACEs. Otherwise (the + input string contains at least one non-space character), the string + is modified such that the string starts with exactly one space + character, ends with exactly one SPACE character, and any inner + (non-empty) sequence of space characters is replaced with exactly two + SPACE characters. For instance, the input strings + "foo<SPACE>bar<SPACE><SPACE>", result in the output + "<SPACE>foo<SPACE><SPACE>bar<SPACE>". + + + + +Zeilenga Standards Track [Page 6] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + For input strings that are substring assertion values: If the string + being prepared contains no non-space characters, then the output + string is exactly one SPACE. Otherwise, the following steps are + taken: + + - If the input string is an initial substring, it is modified to + start with exactly one SPACE character; + + - If the input string is an initial or an any substring that ends in + one or more space characters, it is modified to end with exactly + one SPACE character; + + - If the input string is an any or a final substring that starts in + one or more space characters, it is modified to start with exactly + one SPACE character; and + + - If the input string is a final substring, it is modified to end + with exactly one SPACE character. + + For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as + an initial substring, the output would be + "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring, + the same input would result in "foo<SPACE>bar<SPACE>". + + Appendix B discusses the rationale for the behavior. + +2.6.2. numericString Insignificant Character Handling + + For the purposes of this section, a space is defined to be the SPACE + (U+0020) code point followed by no combining marks. + + All spaces are regarded as insignificant and are to be removed. + + For example, removal of spaces from the Form KC string: + "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" + would result in the output string: + "123456" + and the Form KC string: + "<SPACE><SPACE><SPACE>" + would result in the output string: + "" (an empty string). + +2.6.3. telephoneNumber Insignificant Character Handling + + For the purposes of this section, a hyphen is defined to be a + HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010), + NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS + (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by + + + +Zeilenga Standards Track [Page 7] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + no combining marks and a space is defined to be the SPACE (U+0020) + code point followed by no combining marks. + + All hyphens and spaces are considered insignificant and are to be + removed. + + For example, removal of hyphens and spaces from the Form KC string: + "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>" + would result in the output string: + "123456" + and the Form KC string: + "<HYPHEN><HYPHEN><HYPHEN>" + would result in the (empty) output string: + "". + +3. Security Considerations + + "Preparation of Internationalized Strings ("stringprep")" [RFC3454] + security considerations generally apply to the algorithms described + here. + +4. Acknowledgements + + The approach used in this document is based upon design principles + and algorithms described in "Preparation of Internationalized Strings + ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some + additional guidance was drawn from Unicode Technical Standards, + Technical Reports, and Notes. + + This document is a product of the IETF LDAP Revision (LDAPBIS) + Working Group. + +5. References + +5.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, + June 2006. + + + + + +Zeilenga Standards Track [Page 8] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [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/). + + [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: + Unicode Normalization Forms, Version 3.2.0". + <http://www.unicode.org/unicode/reports/tr15/tr15- + 22.html>, March 2002. + + [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). + +5.2. Informative References + + [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.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models," X.501(1993) (also ISO/IEC 9594- + 2:1994). + + [X.520] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Selected Attribute Types", X.520(1993) (also + ISO/IEC 9594-6:1994). + + [Glossary] The Unicode Consortium, "Unicode Glossary", + <http://www.unicode.org/glossary/>. + + [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report + #17, Character Encoding Model", UTR17, + <http://www.unicode.org/unicode/reports/tr17/>, August + 2000. + + + + +Zeilenga Standards Track [Page 9] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): String Representation of Search + Filters", RFC 4515, June 2006. + + [XMATCH] Zeilenga, K., "Internationalized String Matching Rules + for X.500", Work in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + +Appendix A. Combining Marks + + This appendix is normative. + + This table was derived from Unicode [Unicode] data files; it lists + all code points with the Mn, Mc, or Me properties. This table is to + be considered definitive for the purposes of implementation of this + specification. + + 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1 + 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670 + 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A + 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963 + 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7 + 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D + 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD + 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57 + 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03 + 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83 + 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03 + 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA + 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A + 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19 + 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97 + 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714 + 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9 + 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23 + 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B + 1D1AA-1D1AD + +Appendix B. Substrings Matching + + This appendix is non-normative. + + In the absence of substrings matching, the insignificant space + handling for case ignore/exact matching could be simplified. + Specifically, the handling could be to require that all sequences of + one or more spaces be replaced with one space and, if the string + contains non-space characters, removal of all leading spaces and + trailing spaces. + + In the presence of substrings matching, this simplified space + handling would lead to unexpected and undesirable matching behavior. + For instance: + + 1) (CN=foo\20*\20bar) would match the CN value "foobar"; + + + + + +Zeilenga Standards Track [Page 11] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + 2) (CN=*\20foobar\20*) would match "foobar", but + (CN=*\20*foobar*\20*) would not. + + Note to readers not familiar with LDAP substrings matching: the LDAP + filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of + the attribute CN) that begins with A, contains B after A, ends with C + where C is also after B." + + The first case illustrates that this simplified space handling would + cause leading and trailing spaces in substrings of the string to be + regarded as insignificant. However, only leading and trailing (as + well as multiple consecutive spaces) of the string (as a whole) are + insignificant. + + The second case illustrates that this simplified space handling would + cause sub-partitioning failures. That is, if a prepared any + substring matches a partition of the attribute value, then an + assertion constructed by subdividing that substring into multiple + substrings should also match. + + In designing an appropriate approach for space handling for + substrings matching, one must study key aspects of X.500 case + exact/ignore matching. X.520 [X.520] says: + + The [substrings] rule returns TRUE if there is a partitioning of + the attribute value (into portions) such that: + + - the specified substrings (initial, any, final) match + different portions of the value in the order of the strings + sequence; + + - initial, if present, matches the first portion of the value; + + - final, if present, matches the last portion of the value; + + - any, if present, matches some arbitrary portion of the + value. + + That is, the substrings assertion (CN=foo\20*\20bar) matches the + attribute value "foo<SPACE><SPACE>bar" as the value can be + partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting + the above requirements. + + + + + + + + + +Zeilenga Standards Track [Page 12] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + + X.520 also says: + + [T]he following spaces are regarded as not significant: + + - leading spaces (i.e., those preceding the first character + that is not a space); + + - trailing spaces (i.e., those following the last character + that is not a space); + + - multiple consecutive spaces (these are taken as equivalent + to a single space character). + + This statement applies to the assertion values and attribute values + as whole strings, and not individually to substrings of an assertion + value. In particular, the statements should be taken to mean that if + an assertion value and attribute value match without any + consideration to insignificant characters, then that assertion value + should also match any attribute value that differs only by inclusion + nor removal of insignificant characters. + + Hence the assertion (CN=foo\20*\20bar) matches + "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values + only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal + of insignificant spaces. + + Astute readers of this text will also note that there are special + cases where the specified space handling does not ignore spaces that + could be considered insignificant. For instance, the assertion + (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>" + (insignificant spaces present in value) or " " (insignificant spaces + not present in value). However, as these cases have no practical + application that cannot be met by simple assertions, e.g., (cn=\20), + and this minor anomaly can only be fully addressed by a preparation + algorithm to be used in conjunction with character-by-character + partitioning and matching, the anomaly is considered acceptable. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + +Zeilenga Standards Track [Page 13] + +RFC 4518 LDAP: Internationalized String Preparation June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 14] + diff --git a/source4/ldap_server/devdocs/rfc4519.txt b/source4/ldap_server/devdocs/rfc4519.txt new file mode 100644 index 0000000000..f2e9b7c4b6 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4519.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group A. Sciberras, Ed. +Request for Comments: 4519 eB2Bcom +Obsoletes: 2256 June 2006 +Updates: 2247, 2798, 2377 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Schema for User Applications + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document is an integral part of the Lightweight Directory Access + Protocol (LDAP) technical specification. It provides a technical + specification of attribute types and object classes intended for use + by LDAP directory clients for many directory services, such as White + Pages. These objects are widely used as a basis for the schema in + many LDAP directories. This document does not cover attributes used + for the administration of directory servers, nor does it include + directory objects defined for specific uses in other documents. + + + + + + + + + + + + + + + + + + + +Sciberras Standards Track [Page 1] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship with Other Specifications .....................3 + 1.2. Conventions ................................................4 + 1.3. General Issues .............................................4 + 2. Attribute Types .................................................4 + 2.1. 'businessCategory' .........................................5 + 2.2. 'c' ........................................................5 + 2.3. 'cn' .......................................................5 + 2.4. 'dc' .......................................................6 + 2.5. 'description' ..............................................6 + 2.6. 'destinationIndicator' .....................................7 + 2.7. 'distinguishedName' ........................................7 + 2.8. 'dnQualifier' ..............................................8 + 2.9. 'enhancedSearchGuide' ......................................8 + 2.10. 'facsimileTelephoneNumber' ................................9 + 2.11. 'generationQualifier' .....................................9 + 2.12. 'givenName' ...............................................9 + 2.13. 'houseIdentifier' .........................................9 + 2.14. 'initials' ...............................................10 + 2.15. 'internationalISDNNumber' ................................10 + 2.16. 'l' ......................................................10 + 2.17. 'member' .................................................11 + 2.18. 'name' ...................................................11 + 2.19. 'o' ......................................................11 + 2.20. 'ou' .....................................................12 + 2.21. 'owner' ..................................................12 + 2.22. 'physicalDeliveryOfficeName' .............................12 + 2.23. 'postalAddress' ..........................................13 + 2.24. 'postalCode' .............................................13 + 2.25. 'postOfficeBox' ..........................................14 + 2.26. 'preferredDeliveryMethod' ................................14 + 2.27. 'registeredAddress' ......................................14 + 2.28. 'roleOccupant' ...........................................15 + 2.29. 'searchGuide' ............................................15 + 2.30. 'seeAlso' ................................................15 + 2.31. 'serialNumber' ...........................................16 + 2.32. 'sn' .....................................................16 + 2.33. 'st' .....................................................16 + 2.34. 'street' .................................................17 + 2.35. 'telephoneNumber' ........................................17 + 2.36. 'teletexTerminalIdentifier' ..............................17 + 2.37. 'telexNumber' ............................................18 + 2.38. 'title' ..................................................18 + 2.39. 'uid' ....................................................18 + 2.40. 'uniqueMember' ...........................................19 + 2.41. 'userPassword' ...........................................19 + + + +Sciberras Standards Track [Page 2] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + 2.42. 'x121Address' ............................................20 + 2.43. 'x500UniqueIdentifier' ...................................20 + 3. Object Classes .................................................20 + 3.1. 'applicationProcess' ......................................21 + 3.2. 'country' .................................................21 + 3.3. 'dcObject' ................................................21 + 3.4. 'device' ..................................................21 + 3.5. 'groupOfNames' ............................................22 + 3.6. 'groupOfUniqueNames' ......................................22 + 3.7. 'locality' ................................................23 + 3.8. 'organization' ............................................23 + 3.9. 'organizationalPerson' ....................................24 + 3.10. 'organizationalRole' .....................................24 + 3.11. 'organizationalUnit' .....................................24 + 3.12. 'person' .................................................25 + 3.13. 'residentialPerson' ......................................25 + 3.14. 'uidObject' ..............................................26 + 4. IANA Considerations ............................................26 + 5. Security Considerations ........................................28 + 6. Acknowledgements ...............................................28 + 7. References .....................................................29 + 7.1. Normative References ......................................29 + 7.2. Informative References ....................................30 + Appendix A Changes Made Since RFC 2256 ...........................32 + +1. Introduction + + This document provides an overview of attribute types and object + classes intended for use by Lightweight Directory Access Protocol + (LDAP) directory clients for many directory services, such as White + Pages. Originally specified in the X.500 [X.500] documents, these + objects are widely used as a basis for the schema in many LDAP + directories. This document does not cover attributes used for the + administration of directory servers, nor does it include directory + objects defined for specific uses in other documents. + +1.1. Relationship with Other Specifications + + This document is an integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. In terms of RFC 2256, + Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections + 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The + remainder of RFC 2256 is obsoleted by this document. The technical + specification for the 'dc' attribute type and 'dcObject' object class + found in RFC 2247 are superseded by sections 2.4 and 3.3 of this + document. The remainder of RFC 2247 remains in force. + + + + +Sciberras Standards Track [Page 3] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + This document updates RFC 2798 by replacing the informative + description of the 'uid' attribute type with the definitive + description provided in Section 2.39 of this document. + + This document updates RFC 2377 by replacing the informative + description of the 'uidObject' object class with the definitive + description provided in Section 3.14 of this document. + + A number of schema elements that were included in the previous + revision of the LDAP Technical Specification are not included in this + revision of LDAP. PKI-related schema elements are now specified in + [RFC4523]. Unless reintroduced in future technical specifications, + the remainder are to be considered Historic. + + The descriptions in this document SHALL be considered definitive for + use in LDAP. + +1.2. 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 RFC 2119 [RFC2119]. + +1.3. General Issues + + This document references Syntaxes defined in Section 3 of [RFC4517] + and Matching Rules defined in Section 4 of [RFC4517]. + + The definitions of Attribute Types and Object Classes are written + using the Augmented Backus-Naur Form (ABNF) [RFC4234] of + AttributeTypeDescription and ObjectClassDescription given in + [RFC4512]. Lines have been folded for readability. When such values + are transferred as attribute values in the LDAP Protocol, the values + will not contain line breaks. + +2. Attribute Types + + The attribute types contained in this section hold user information. + + There is no requirement that servers implement the 'searchGuide' and + 'teletexTerminalIdentifier' attribute types. In fact, their use is + greatly discouraged. + + An LDAP server implementation SHOULD recognize the rest of the + attribute types described in this section. + + + + + + +Sciberras Standards Track [Page 4] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.1. 'businessCategory' + + The 'businessCategory' attribute type describes the kinds of business + performed by an organization. Each kind is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.15 NAME 'businessCategory' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Examples: "banking", "transportation", and "real estate". + +2.2. 'c' + + The 'c' ('countryName' in X.500) attribute type contains a two-letter + ISO 3166 [ISO3166] country code. + (Source: X.520 [X.520]) + + ( 2.5.4.6 NAME 'c' + SUP name + SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 + SINGLE-VALUE ) + + 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax + [RFC4517]. + + Examples: "DE", "AU" and "FR". + +2.3. 'cn' + + The 'cn' ('commonName' in X.500) attribute type contains names of an + object. Each name is one value of this multi-valued attribute. If + the object corresponds to a person, it is typically the person's full + name. + (Source: X.520 [X.520]) + + ( 2.5.4.3 NAME 'cn' + SUP name ) + + Examples: "Martin K Smith", "Marty Smith" and "printer12". + + + + + + +Sciberras Standards Track [Page 5] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.4. 'dc' + + The 'dc' ('domainComponent' in RFC 1274) attribute type is a string + holding one component, a label, of a DNS domain name + [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this + attribute is a string of ASCII characters adhering to the following + ABNF [RFC4234]: + + label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)] + ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" + DIGIT = %x30-39 ; "0"-"9" + HYPHEN = %x2D ; hyphen ("-") + + The encoding of IA5String for use in LDAP is simply the characters of + the ASCII label. The equality matching rule is case insensitive, as + is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274]) + + ( 0.9.2342.19200300.100.1.25 NAME 'dc' + EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax + [RFC4517]. + + Examples: Valid values include "example" and "com" but not + "example.com". The latter is invalid as it contains multiple domain + components. + + It is noted that the directory service will not ensure that values of + this attribute conform to the host label restrictions [RFC1123] + illustrated by the <label> production provided above. It is the + directory client's responsibility to ensure that the labels it stores + in this attribute are appropriately restricted. + + Directory applications supporting International Domain Names SHALL + use the ToASCII method [RFC3490] to produce the domain component + label. The special considerations discussed in Section 4 of RFC 3490 + [RFC3490] should be taken, depending on whether the domain component + is used for "stored" or "query" purposes. + +2.5. 'description' + + The 'description' attribute type contains human-readable descriptive + phrases about the object. Each description is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + + +Sciberras Standards Track [Page 6] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.4.13 NAME 'description' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Examples: "a color printer", "Maintenance is done every Monday, at + 1pm.", and "distribution list for all technical staff". + +2.6. 'destinationIndicator' + + The 'destinationIndicator' attribute type contains country and city + strings associated with the object (the addressee) needed to provide + the Public Telegram Service. The strings are composed in accordance + with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.27 NAME 'destinationIndicator' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) + + 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax + [RFC4517]. + + Examples: "AASD" as a destination indicator for Sydney, Australia. + "GBLD" as a destination indicator for London, United + Kingdom. + + It is noted that the directory will not ensure that values of this + attribute conform to the F.1 and F.31 CCITT Recommendations. It is + the application's responsibility to ensure destination indicators + that it stores in this attribute are appropriately constructed. + +2.7. 'distinguishedName' + + The 'distinguishedName' attribute type is not used as the name of the + object itself, but it is instead a base type from which some user + attribute types with a DN syntax can inherit. + + It is unlikely that values of this type itself will occur in an + entry. LDAP server implementations that do not support attribute + subtyping need not recognize this attribute in requests. Client + implementations MUST NOT assume that LDAP servers are capable of + performing attribute subtyping. + + + +Sciberras Standards Track [Page 7] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + (Source: X.520 [X.520]) + + ( 2.5.4.49 NAME 'distinguishedName' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517]. + +2.8. 'dnQualifier' + + The 'dnQualifier' attribute type contains disambiguating information + strings to add to the relative distinguished name of an entry. The + information is intended for use when merging data from multiple + sources in order to prevent conflicts between entries that would + otherwise have the same name. Each string is one value of this + multi-valued attribute. It is recommended that a value of the + 'dnQualifier' attribute be the same for all entries from a particular + source. + (Source: X.520 [X.520]) + + ( 2.5.4.46 NAME 'dnQualifier' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) + + 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax + [RFC4517]. + + Examples: "20050322123345Z" - timestamps can be used to disambiguate + information. + "123456A" - serial numbers can be used to disambiguate + information. + +2.9. 'enhancedSearchGuide' + + The 'enhancedSearchGuide' attribute type contains sets of information + for use by directory clients in constructing search filters. Each + set is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.47 NAME 'enhancedSearchGuide' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) + + 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax + [RFC4517]. + + + + + +Sciberras Standards Track [Page 8] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + Examples: "person#(sn$APPROX)#wholeSubtree" and + "organizationalUnit#(ou$SUBSTR)#oneLevel". + +2.10. 'facsimileTelephoneNumber' + + The 'facsimileTelephoneNumber' attribute type contains telephone + numbers (and, optionally, the parameters) for facsimile terminals. + Each telephone number is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.23 NAME 'facsimileTelephoneNumber' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) + + 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone + Number syntax [RFC4517]. + + Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". + +2.11. 'generationQualifier' + + The 'generationQualifier' attribute type contains name strings that + are typically the suffix part of a person's name. Each string is one + value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.44 NAME 'generationQualifier' + SUP name ) + + Examples: "III", "3rd", and "Jr.". + +2.12. 'givenName' + + The 'givenName' attribute type contains name strings that are the + part of a person's name that is not their surname. Each string is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.42 NAME 'givenName' + SUP name ) + + Examples: "Andrew", "Charles", and "Joanne". + +2.13. 'houseIdentifier' + + The 'houseIdentifier' attribute type contains identifiers for a + building within a location. Each identifier is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + + +Sciberras Standards Track [Page 9] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.4.51 NAME 'houseIdentifier' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Example: "20" to represent the house number 20. + +2.14. 'initials' + + The 'initials' attribute type contains strings of initials of some or + all of an individual's names, except the surname(s). Each string is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.43 NAME 'initials' + SUP name ) + + Examples: "K. A." and "K". + +2.15. 'internationalISDNNumber' + + The 'internationalISDNNumber' attribute type contains Integrated + Services Digital Network (ISDN) addresses, as defined in the + International Telecommunication Union (ITU) Recommendation E.164 + [E.164]. Each address is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.25 NAME 'internationalISDNNumber' + EQUALITY numericStringMatch + SUBSTR numericStringSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax + [RFC4517]. + + Example: "0198 333 333". + +2.16. 'l' + + The 'l' ('localityName' in X.500) attribute type contains names of a + locality or place, such as a city, county, or other geographic + region. Each name is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + + + + +Sciberras Standards Track [Page 10] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.4.7 NAME 'l' + SUP name ) + + Examples: "Geneva", "Paris", and "Edinburgh". + +2.17. 'member' + + The 'member' attribute type contains the distinguished names of + objects that are on a list or in a group. Each name is one value of + this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.31 NAME 'member' + SUP distinguishedName ) + + Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and + "cn=John Xerri,ou=Finance,o=Widget\, Inc." may + be two members of the financial team (group) at Widget, + Inc., in which case, both of these distinguished names + would be present as individual values of the member + attribute. + +2.18. 'name' + + The 'name' attribute type is the attribute supertype from which user + attribute types with the name syntax inherit. Such attribute types + are typically used for naming. The attribute type is multi-valued. + + It is unlikely that values of this type itself will occur in an + entry. LDAP server implementations that do not support attribute + subtyping need not recognize this attribute in requests. Client + implementations MUST NOT assume that LDAP servers are capable of + performing attribute subtyping. + (Source: X.520 [X.520]) + + ( 2.5.4.41 NAME 'name' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + +2.19. 'o' + + The 'o' ('organizationName' in X.500) attribute type contains the + names of an organization. Each name is one value of this + multi-valued attribute. + + + +Sciberras Standards Track [Page 11] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + (Source: X.520 [X.520]) + + ( 2.5.4.10 NAME 'o' + SUP name ) + + Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.". + +2.20. 'ou' + + The 'ou' ('organizationalUnitName' in X.500) attribute type contains + the names of an organizational unit. Each name is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.11 NAME 'ou' + SUP name ) + + Examples: "Finance", "Human Resources", and "Research and + Development". + +2.21. 'owner' + + The 'owner' attribute type contains the distinguished names of + objects that have an ownership responsibility for the object that is + owned. Each owner's name is one value of this multi-valued + attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.32 NAME 'owner' + SUP distinguishedName ) + + Example: The mailing list object, whose DN is "cn=All Employees, + ou=Mailing List,o=Widget\, Inc.", is owned by the Human + Resources Director. + + Therefore, the value of the 'owner' attribute within the + mailing list object, would be the DN of the director (role): + "cn=Human Resources Director,ou=employee,o=Widget\, Inc.". + +2.22. 'physicalDeliveryOfficeName' + + The 'physicalDeliveryOfficeName' attribute type contains names that a + Postal Service uses to identify a post office. + (Source: X.520 [X.520]) + + + + + + + +Sciberras Standards Track [Page 12] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse". + +2.23. 'postalAddress' + + The 'postalAddress' attribute type contains addresses used by a + Postal Service to perform services for the object. Each address is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.16 NAME 'postalAddress' + EQUALITY caseIgnoreListMatch + SUBSTR caseIgnoreListSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) + + 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax + [RFC4517]. + + Example: "15 Main St.$Ottawa$Canada". + +2.24. 'postalCode' + + The 'postalCode' attribute type contains codes used by a Postal + Service to identify postal service zones. Each code is one value of + this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.17 NAME 'postalCode' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Example: "22180", to identify Vienna, VA, in the USA. + + + + + + + + +Sciberras Standards Track [Page 13] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.25. 'postOfficeBox' + + The 'postOfficeBox' attribute type contains postal box identifiers + that a Postal Service uses when a customer arranges to receive mail + at a box on the premises of the Postal Service. Each postal box + identifier is a single value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.18 NAME 'postOfficeBox' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Example: "Box 45". + +2.26. 'preferredDeliveryMethod' + + The 'preferredDeliveryMethod' attribute type contains an indication + of the preferred method of getting a message to the object. + (Source: X.520 [X.520]) + + ( 2.5.4.28 NAME 'preferredDeliveryMethod' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 + SINGLE-VALUE ) + + 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax + [RFC4517]. + + Example: If the mhs-delivery Delivery Method is preferred over + telephone-delivery, which is preferred over all other + methods, the value would be: "mhs $ telephone". + +2.27. 'registeredAddress' + + The 'registeredAddress' attribute type contains postal addresses + suitable for reception of telegrams or expedited documents, where it + is necessary to have the recipient accept delivery. Each address is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.26 NAME 'registeredAddress' + SUP postalAddress + SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) + + + + + +Sciberras Standards Track [Page 14] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax + [RFC4517]. + + Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada". + +2.28. 'roleOccupant' + + The 'roleOccupant' attribute type contains the distinguished names of + objects (normally people) that fulfill the responsibilities of a role + object. Each distinguished name is one value of this multi-valued + attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.33 NAME 'roleOccupant' + SUP distinguishedName ) + + Example: The role object, "cn=Human Resources + Director,ou=Position,o=Widget\, Inc.", is fulfilled by two + people whose object names are "cn=Mary + Smith,ou=employee,o=Widget\, Inc." and "cn=James + Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant' + attribute will contain both of these distinguished names, + since they are the occupants of this role. + +2.29. 'searchGuide' + + The 'searchGuide' attribute type contains sets of information for use + by clients in constructing search filters. It is superseded by + 'enhancedSearchGuide', described above in Section 2.9. Each set is + one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.14 NAME 'searchGuide' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) + + 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517]. + + Example: "person#sn$EQ". + +2.30. 'seeAlso' + + The 'seeAlso' attribute type contains the distinguished names of + objects that are related to the subject object. Each related object + name is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.34 NAME 'seeAlso' + SUP distinguishedName ) + + + +Sciberras Standards Track [Page 15] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + Example: The person object "cn=James Brown,ou=employee,o=Widget\, + Inc." is related to the role objects "cn=Football Team + Captain,ou=sponsored activities,o=Widget\, Inc." and + "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". + Since the role objects are related to the person object, the + 'seeAlso' attribute will contain the distinguished name of + each role object as separate values. + +2.31. 'serialNumber' + + The 'serialNumber' attribute type contains the serial numbers of + devices. Each serial number is one value of this multi-valued + attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.5 NAME 'serialNumber' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) + + 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax + [RFC4517]. + + Examples: "WI-3005" and "XF551426". + +2.32. 'sn' + + The 'sn' ('surname' in X.500) attribute type contains name strings + for the family names of a person. Each string is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.4 NAME 'sn' + SUP name ) + + Example: "Smith". + +2.33. 'st' + + The 'st' ('stateOrProvinceName' in X.500) attribute type contains the + full names of states or provinces. Each name is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.8 NAME 'st' + SUP name ) + + Example: "California". + + + +Sciberras Standards Track [Page 16] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.34. 'street' + + The 'street' ('streetAddress' in X.500) attribute type contains site + information from a postal address (i.e., the street name, place, + avenue, and the house number). Each street is one value of this + multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.9 NAME 'street' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Example: "15 Main St.". + +2.35. 'telephoneNumber' + + The 'telephoneNumber' attribute type contains telephone numbers that + comply with the ITU Recommendation E.123 [E.123]. Each number is one + value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.20 NAME 'telephoneNumber' + EQUALITY telephoneNumberMatch + SUBSTR telephoneNumberSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax + [RFC4517]. + + Example: "+1 234 567 8901". + +2.36. 'teletexTerminalIdentifier' + + The withdrawal of Recommendation F.200 has resulted in the withdrawal + of this attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.22 NAME 'teletexTerminalIdentifier' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) + + 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal + Identifier syntax [RFC4517]. + + + + + +Sciberras Standards Track [Page 17] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.37. 'telexNumber' + + The 'telexNumber' attribute type contains sets of strings that are a + telex number, country code, and answerback code of a telex terminal. + Each set is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.21 NAME 'telexNumber' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) + + 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax + [RFC4517]. + + Example: "12345$023$ABCDE". + +2.38. 'title' + + The 'title' attribute type contains the title of a person in their + organizational context. Each title is one value of this multi-valued + attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.12 NAME 'title' + SUP name ) + Examples: "Vice President", "Software Engineer", and "CEO". + +2.39. 'uid' + + The 'uid' ('userid' in RFC 1274) attribute type contains computer + system login names associated with the object. Each name is one + value of this multi-valued attribute. + (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274]) + + ( 0.9.2342.19200300.100.1.1 NAME 'uid' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax + [RFC4517]. + + Examples: "s9709015", "admin", and "Administrator". + + + + + + + + + +Sciberras Standards Track [Page 18] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +2.40. 'uniqueMember' + + The 'uniqueMember' attribute type contains the distinguished names of + an object that is on a list or in a group, where the relative + distinguished names of the object include a value that distinguishes + between objects when a distinguished name has been reused. Each + distinguished name is one value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.50 NAME 'uniqueMember' + EQUALITY uniqueMemberMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) + + 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID + syntax [RFC4517]. + + Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was + disbanded, establishing a new battalion with the "same" name + would have a unique identifier value added, resulting in + "ou=1st Battalion, o=Defense,c=US#'010101'B". + +2.41. 'userPassword' + + The 'userPassword' attribute contains octet strings that are known + only to the user and the system to which the user has access. Each + string is one value of this multi-valued attribute. + + The application SHOULD prepare textual strings used as passwords by + transcoding them to Unicode, applying SASLprep [RFC4013], and + encoding as UTF-8. The determination of whether a password is + textual is a local client matter. + (Source: X.509 [X.509]) + + ( 2.5.4.35 NAME 'userPassword' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + + 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax + [RFC4517]. + + Passwords are stored using an Octet String syntax and are not + encrypted. Transfer of cleartext passwords is strongly discouraged + where the underlying transport service cannot guarantee + confidentiality and may result in disclosure of the password to + unauthorized parties. + + An example of a need for multiple values in the 'userPassword' + attribute is an environment where every month the user is expected to + + + +Sciberras Standards Track [Page 19] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + use a different password generated by some automated system. During + transitional periods, like the last and first day of the periods, it + may be necessary to allow two passwords for the two consecutive + periods to be valid in the system. + +2.42. 'x121Address' + + The 'x121Address' attribute type contains data network addresses as + defined by ITU Recommendation X.121 [X.121]. Each address is one + value of this multi-valued attribute. + (Source: X.520 [X.520]) + + ( 2.5.4.24 NAME 'x121Address' + EQUALITY numericStringMatch + SUBSTR numericStringSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax + [RFC4517]. + + Example: "36111222333444555". + +2.43. 'x500UniqueIdentifier' + + The 'x500UniqueIdentifier' attribute type contains binary strings + that are used to distinguish between objects when a distinguished + name has been reused. Each string is one value of this multi-valued + attribute. + + In X.520 [X.520], this attribute type is called 'uniqueIdentifier'. + This is a different attribute type from both the 'uid' and + 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier' + attribute type is defined in [RFC4524]. + (Source: X.520 [X.520]) + + ( 2.5.4.45 NAME 'x500UniqueIdentifier' + EQUALITY bitStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) + + 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax + [RFC4517]. + +3. Object Classes + + LDAP servers SHOULD recognize all the Object Classes listed here as + values of the 'objectClass' attribute (see [RFC4512]). + + + + + +Sciberras Standards Track [Page 20] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +3.1. 'applicationProcess' + + The 'applicationProcess' object class definition is the basis of an + entry that represents an application executing in a computer system. + (Source: X.521 [X.521]) + + ( 2.5.6.11 NAME 'applicationProcess' + SUP top + STRUCTURAL + MUST cn + MAY ( seeAlso $ + ou $ + l $ + description ) ) + +3.2. 'country' + + The 'country' object class definition is the basis of an entry that + represents a country. + (Source: X.521 [X.521]) + + ( 2.5.6.2 NAME 'country' + SUP top + STRUCTURAL + MUST c + MAY ( searchGuide $ + description ) ) + +3.3. 'dcObject' + + The 'dcObject' object class permits an entry to contains domain + component information. This object class is defined as auxiliary, + because it will be used in conjunction with an existing structural + object class. + (Source: RFC 2247 [RFC2247]) + + ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' + SUP top + AUXILIARY + MUST dc ) + +3.4. 'device' + + The 'device' object class is the basis of an entry that represents an + appliance, computer, or network element. + (Source: X.521 [X.521]) + + + + + +Sciberras Standards Track [Page 21] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.6.14 NAME 'device' + SUP top + STRUCTURAL + MUST cn + MAY ( serialNumber $ + seeAlso $ + owner $ + ou $ + o $ + l $ + description ) ) + +3.5. 'groupOfNames' + + The 'groupOfNames' object class is the basis of an entry that + represents a set of named objects including information related to + the purpose or maintenance of the set. + (Source: X.521 [X.521]) + + ( 2.5.6.9 NAME 'groupOfNames' + SUP top + STRUCTURAL + MUST ( member $ + cn ) + MAY ( businessCategory $ + seeAlso $ + owner $ + ou $ + o $ + description ) ) + +3.6. 'groupOfUniqueNames' + + The 'groupOfUniqueNames' object class is the same as the + 'groupOfNames' object class except that the object names are not + repeated or reassigned within a set scope. + (Source: X.521 [X.521]) + + + + + + + + + + + + + + +Sciberras Standards Track [Page 22] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.6.17 NAME 'groupOfUniqueNames' + SUP top + STRUCTURAL + MUST ( uniqueMember $ + cn ) + MAY ( businessCategory $ + seeAlso $ + owner $ + ou $ + o $ + description ) ) + +3.7. 'locality' + + The 'locality' object class is the basis of an entry that represents + a place in the physical world. + (Source: X.521 [X.521]) + + ( 2.5.6.3 NAME 'locality' + SUP top + STRUCTURAL + MAY ( street $ + seeAlso $ + searchGuide $ + st $ + l $ + description ) ) + +3.8. 'organization' + + The 'organization' object class is the basis of an entry that + represents a structured group of people. + (Source: X.521 [X.521]) + + ( 2.5.6.4 NAME 'organization' + SUP top + STRUCTURAL + MUST o + MAY ( userPassword $ searchGuide $ seeAlso $ + businessCategory $ x121Address $ registeredAddress $ + destinationIndicator $ preferredDeliveryMethod $ + telexNumber $ teletexTerminalIdentifier $ + telephoneNumber $ internationalISDNNumber $ + facsimileTelephoneNumber $ street $ postOfficeBox $ + postalCode $ postalAddress $ physicalDeliveryOfficeName $ + st $ l $ description ) ) + + + + + +Sciberras Standards Track [Page 23] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +3.9. 'organizationalPerson' + + The 'organizationalPerson' object class is the basis of an entry that + represents a person in relation to an organization. + (Source: X.521 [X.521]) + + ( 2.5.6.7 NAME 'organizationalPerson' + SUP person + STRUCTURAL + MAY ( title $ x121Address $ registeredAddress $ + destinationIndicator $ preferredDeliveryMethod $ + telexNumber $ teletexTerminalIdentifier $ + telephoneNumber $ internationalISDNNumber $ + facsimileTelephoneNumber $ street $ postOfficeBox $ + postalCode $ postalAddress $ physicalDeliveryOfficeName $ + ou $ st $ l ) ) + +3.10. 'organizationalRole' + + The 'organizationalRole' object class is the basis of an entry that + represents a job, function, or position in an organization. + (Source: X.521 [X.521]) + + ( 2.5.6.8 NAME 'organizationalRole' + SUP top + STRUCTURAL + MUST cn + MAY ( x121Address $ registeredAddress $ destinationIndicator $ + preferredDeliveryMethod $ telexNumber $ + teletexTerminalIdentifier $ telephoneNumber $ + internationalISDNNumber $ facsimileTelephoneNumber $ + seeAlso $ roleOccupant $ preferredDeliveryMethod $ + street $ postOfficeBox $ postalCode $ postalAddress $ + physicalDeliveryOfficeName $ ou $ st $ l $ + description ) ) + +3.11. 'organizationalUnit' + + The 'organizationalUnit' object class is the basis of an entry that + represents a piece of an organization. + (Source: X.521 [X.521]) + + + + + + + + + + +Sciberras Standards Track [Page 24] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + ( 2.5.6.5 NAME 'organizationalUnit' + SUP top + STRUCTURAL + MUST ou + MAY ( businessCategory $ description $ destinationIndicator $ + facsimileTelephoneNumber $ internationalISDNNumber $ l $ + physicalDeliveryOfficeName $ postalAddress $ postalCode $ + postOfficeBox $ preferredDeliveryMethod $ + registeredAddress $ searchGuide $ seeAlso $ st $ street $ + telephoneNumber $ teletexTerminalIdentifier $ + telexNumber $ userPassword $ x121Address ) ) + +3.12 'person' + + The 'person' object class is the basis of an entry that represents a + human being. + (Source: X.521 [X.521]) + + ( 2.5.6.6 NAME 'person' + SUP top + STRUCTURAL + MUST ( sn $ + cn ) + MAY ( userPassword $ + telephoneNumber $ + seeAlso $ description ) ) + +3.13. 'residentialPerson' + + The 'residentialPerson' object class is the basis of an entry that + includes a person's residence in the representation of the person. + (Source: X.521 [X.521]) + + ( 2.5.6.10 NAME 'residentialPerson' + SUP person + STRUCTURAL + MUST l + MAY ( businessCategory $ x121Address $ registeredAddress $ + destinationIndicator $ preferredDeliveryMethod $ + telexNumber $ teletexTerminalIdentifier $ + telephoneNumber $ internationalISDNNumber $ + facsimileTelephoneNumber $ preferredDeliveryMethod $ + street $ postOfficeBox $ postalCode $ postalAddress $ + physicalDeliveryOfficeName $ st $ l ) ) + + + + + + + +Sciberras Standards Track [Page 25] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +3.14. 'uidObject' + + The 'uidObject' object class permits an entry to contains user + identification information. This object class is defined as + auxiliary, because it will be used in conjunction with an existing + structural object class. + (Source: RFC 2377 [RFC2377]) + + ( 1.3.6.1.1.3.1 NAME 'uidObject' + SUP top + AUXILIARY + MUST uid ) + +4. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry as indicated in the following template: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comments + Object Identifier: see comments + Person & email address to contact for further information: + Andrew Sciberras <andrew.sciberras@eb2bcom.com> + Usage: (A = attribute type, O = Object Class) see comment + Specification: RFC 4519 + Author/Change Controller: IESG + + Comments + + In the LDAP descriptors registry, the following descriptors (short + names) have been updated to refer to RFC 4519. Names that need to + be reserved, rather than assigned to an Object Identifier, will + contain an Object Identifier value of RESERVED. + + NAME Type OID + ------------------------ ---- ---------------------------- + applicationProcess O 2.5.6.11 + businessCategory A 2.5.4.15 + c A 2.5.4.6 + cn A 2.5.4.3 + commonName A 2.5.4.3 + country O 2.5.6.2 + countryName A 2.5.4.6 + dc A 0.9.2342.19200300.100.1.25 + dcObject O 1.3.6.1.4.1.1466.344 + description A 2.5.4.13 + destinationIndicator A 2.5.4.27 + device O 2.5.6.14 + + + +Sciberras Standards Track [Page 26] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + NAME Type OID + ------------------------ ---- ---------------------------- + distinguishedName A 2.5.4.49 + dnQualifier A 2.5.4.46 + domainComponent A 0.9.2342.19200300.100.1.25 + enhancedSearchGuide A 2.5.4.47 + facsimileTelephoneNumber A 2.5.4.23 + generationQualifier A 2.5.4.44 + givenName A 2.5.4.42 + gn A RESERVED + groupOfNames O 2.5.6.9 + groupOfUniqueNames O 2.5.6.17 + houseIdentifier A 2.5.4.51 + initials A 2.5.4.43 + internationalISDNNumber A 2.5.4.25 + l A 2.5.4.7 + locality O 2.5.6.3 + localityName A 2.5.4.7 + member A 2.5.4.31 + name A 2.5.4.41 + o A 2.5.4.10 + organization O 2.5.6.4 + organizationName A 2.5.4.10 + organizationalPerson O 2.5.6.7 + organizationalRole O 2.5.6.8 + organizationalUnit O 2.5.6.5 + organizationalUnitName A 2.5.4.11 + ou A 2.5.4.11 + owner A 2.5.4.32 + person O 2.5.6.6 + physicalDeliveryOfficeName A 2.5.4.19 + postalAddress A 2.5.4.16 + postalCode A 2.5.4.17 + postOfficeBox A 2.5.4.18 + preferredDeliveryMethod A 2.5.4.28 + registeredAddress A 2.5.4.26 + residentialPerson O 2.5.6.10 + roleOccupant A 2.5.4.33 + searchGuide A 2.5.4.14 + seeAlso A 2.5.4.34 + serialNumber A 2.5.4.5 + sn A 2.5.4.4 + st A 2.5.4.8 + street A 2.5.4.9 + surname A 2.5.4.4 + telephoneNumber A 2.5.4.20 + teletexTerminalIdentifier A 2.5.4.22 + telexNumber A 2.5.4.21 + + + +Sciberras Standards Track [Page 27] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + NAME Type OID + ------------------------ ---- ---------------------------- + title A 2.5.4.12 + uid A 0.9.2342.19200300.100.1.1 + uidObject O 1.3.6.1.1.3.1 + uniqueMember A 2.5.4.50 + userid A 0.9.2342.19200300.100.1.1 + userPassword A 2.5.4.35 + x121Address A 2.5.4.24 + x500UniqueIdentifier A 2.5.4.45 + +5. Security Considerations + + Attributes of directory entries are used to provide descriptive + information about the real-world objects they represent, which can be + people, organizations, or devices. Most countries have privacy laws + regarding the publication of information about people. + + Transfer of cleartext passwords is strongly discouraged where the + underlying transport service cannot guarantee confidentiality and + integrity, since this may result in disclosure of the password to + unauthorized parties. + + Multiple attribute values for the 'userPassword' attribute need to be + used with care. Especially reset/deletion of a password by an + administrator without knowing the old user password gets tricky or + impossible if multiple values for different applications are present. + + Certainly, applications that intend to replace the 'userPassword' + value(s) with new value(s) should use modify/replaceValues (or + modify/deleteAttribute+addAttribute). In addition, server + implementations are encouraged to provide administrative controls + that, if enabled, restrict the 'userPassword' attribute to one value. + + Note that when used for authentication purposes [RFC4513], the user + need only prove knowledge of one of the values, not all of the + values. + +6. Acknowledgements + + The definitions, on which this document is based, have been developed + by committees for telecommunications and international standards. + + This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a + product of the IETF ASID Working Group. + + + + + + +Sciberras Standards Track [Page 28] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + The 'dc' attribute type definition and the 'dcObject' object class + definition in this document supersede the specification in RFC 2247 + by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri. + + The 'uid' attribute type definition in this document supersedes the + specification of the 'userid' in RFC 1274 by P. Barker and S. Kille + and of the uid in RFC 2798 by M. Smith. + + The 'uidObject' object class definition in this document supersedes + the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. + Huber, S. Sataluri, and M. Wahl. + + This document is based upon input of the IETF LDAPBIS working group. + The author wishes to thank S. Legg and K. Zeilenga for their + significant contribution to this update. The author would also like + to thank Kathy Dally, who edited early versions of this document. + +7. References + +7.1. Normative References + + [E.123] Notation for national and international telephone numbers, + ITU-T Recommendation E.123, 1988 + + [E.164] The international public telecommunication numbering plan, + ITU-T Recommendation E.164, 1997 + + [F.1] Operational Provisions For The International Public + Telegram Service Transmission System, CCITT Recommendation + F.1, 1992 + + [F.31] Telegram Retransmission System, CCITT Recommendation F.31, + 1988 + + [ISO3166] ISO 3166, "Codes for the representation of names of + countries". + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + +Sciberras Standards Track [Page 29] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names + and Passwords", RFC 4013, February 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. + + [X.121] International numbering plan for public data networks, + ITU-T Recommendation X.121, 1996 + + [X.509] The Directory: Authentication Framework, ITU-T + Recommendation X.509, 1993 + + [X.520] The Directory: Selected Attribute Types, ITU-T + Recommendation X.520, 1993 + + [X.521] The Directory: Selected Object Classes. ITU-T + Recommendation X.521, 1993 + +7.2. Informative References + + [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500 + Schema", RFC 1274, November 1991. + + [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. + Sataluri, "Using Domains in LDAP/X.500 Distinguished + Names", RFC 2247, January 1998. + + [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl, + "Naming Plan for Internet Directory-Enabled Applications", + RFC 2377, September 1998. + + [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object + Class", RFC 2798, April 2000. + + + +Sciberras Standards Track [Page 30] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Schema Definitions for X.509 Certificates", RFC + 4523, June 2006. + + [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524, + June 2006. + + [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - + The Directory: Overview of concepts, models and services. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sciberras Standards Track [Page 31] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +Appendix A. Changes Made Since RFC 2256 + + This appendix lists the changes that have been made from RFC 2256 to + RFC 4519. + + This appendix is not a normative part of this specification, which + has been provided for informational purposes only. + + 1. Replaced the document title. + + 2. Removed the IESG Note. + + 3. Dependencies on RFC 1274 have been eliminated. + + 4. Added a Security Considerations section and an IANA + Considerations section. + + 5. Deleted the conformance requirement for subschema object + classes in favor of a statement in [RFC4517]. + + 6. Added explanation to attribute types and to each object class. + + 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules, + (moved to [RFC4517]). + + 8. Removed the certificate-related attribute types: + authorityRevocationList, cACertificate, + certificateRevocationList, crossCertificatePair, + deltaRevocationList, supportedAlgorithms, and userCertificate. + + Removed the certificate-related Object Classes: + certificationAuthority, certificationAuthority-V2, + cRLDistributionPoint, strongAuthenticationUser, and + userSecurityInformation + + LDAP PKI is now discussed in [RFC4523]. + + 9. Removed the dmdName, knowledgeInformation, + presentationAddress, protocolInformation, and + supportedApplicationContext attribute types and the dmd, + applicationEntity, and dSA object classes. + + 10. Deleted the aliasedObjectName and objectClass attribute type + definitions. Deleted the alias and top object class + definitions. They are included in [RFC4512]. + + + + + + +Sciberras Standards Track [Page 32] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + 11. Added the 'dc' attribute type from RFC 2247, making the + distinction between 'stored' and 'query' values when preparing + IDN strings. + + 12. Numerous editorial changes. + + 13. Removed upper bound after the SYNTAX oid in all attribute + definitions where it appeared. + + 14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for + userPassword. + + 15. Included definitions, comments and references for 'dcObject' + and 'uidObject'. + + 16. Replaced PKI schema references to use RFC 4523. + + 17. Spelt out and referenced ABNF on first usage. + + 18. Removed Section 2.4 (Source). Replaced the source table with + explicit references for each definition. + + 19. All references to an attribute type or object class are + enclosed in single quotes. + + 20. The layout of attribute type definitions has been changed to + provide consistency throughout the document: + > Section Heading + > Description of Attribute type + > Multivalued description + > Source Information + > Definition + > Example + > Additional Comments + + Adding this consistent output included the addition of + examples to some definitions. + + 21. References to alternate names for attributes types are + provided with a reference to where they were originally + specified. + + 22. Clarification of the description of 'distinguishedName' and + 'name', in regards to these attribute types being supertypes. + + 23. Spelt out ISDN on first usage. + + + + + +Sciberras Standards Track [Page 33] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + + 24. Inserted a reference to [RFC4517] for the + 'teletexTerminalIdentifier' definition's SYNTAX OID. + + 25. Additional names were added to the IANA Considerations. Names + include 'commonName', 'dcObject', 'domainComponent', 'GN', + 'localityName', 'organizationName', 'organizationUnitName', + 'surname', 'uidObject' and 'userid'. + + 26. Renamed all instances of supercede to supersede. + + 27. Moved [F.1], [F.31] and [RFC4013] from informative to + normative references. + + 28. Changed the 'c' definition to be consistent with X.500. + +Author's Address + + Andrew Sciberras + eB2Bcom + Suite 3, Woodhouse Corporate Centre, + 935 Station Street, + Box Hill North, Victoria 3129 + AUSTRALIA + + Phone: +61 3 9896 7833 + EMail: andrew.sciberras@eb2bcom.com + + + + + + + + + + + + + + + + + + + + + + + + + +Sciberras Standards Track [Page 34] + +RFC 4519 LDAP: Schema for User Applications June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Sciberras Standards Track [Page 35] + diff --git a/source4/ldap_server/devdocs/rfc4520.txt b/source4/ldap_server/devdocs/rfc4520.txt new file mode 100644 index 0000000000..9ef5daadea --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4520.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4520 OpenLDAP Foundation +BCP: 64 June 2006 +Obsoletes: 3383 +Category: Best Current Practice + + + Internet Assigned Numbers Authority (IANA) Considerations for + the Lightweight Directory Access Protocol (LDAP) + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document provides procedures for registering extensible elements + of the Lightweight Directory Access Protocol (LDAP). The document + also provides guidelines to the Internet Assigned Numbers Authority + (IANA) describing conditions under which new values can be assigned. + +1. Introduction + + The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an + extensible protocol. LDAP supports: + + - the addition of new operations, + - the extension of existing operations, and + - the extensible schema. + + This document details procedures for registering values used to + unambiguously identify extensible elements of the protocol, including + the following: + + - LDAP message types + - LDAP extended operations and controls + - LDAP result codes + - LDAP authentication methods + - LDAP attribute description options + - Object Identifier descriptors + + + + + +Zeilenga Best Current Practice [Page 1] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + 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]. + + The term "registration owner" (or "owner") refers to the party + authorized to change a value's registration. + +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 + [RFC4234]. 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 + keyword = keystring + + Keywords are case insensitive. + + + + +Zeilenga Best Current Practice [Page 2] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +3. IANA Considerations for LDAP + + This section details each kind of protocol value that 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 that assign OIDs to + elements SHOULD state who delegated the OIDs for their use. + + 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 <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA + assignment of Internet Private Enterprise Numbers are 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 + are detailed in RFC 2578 [RFC2578]. + +3.2. Protocol Mechanisms + + LDAP provides a number of Root DSA-Specific Entry (DSE) attributes + for discovery of protocol mechanisms identified by OIDs, including + the supportedControl, supportedExtension, and supportedFeatures + attributes [RFC4512]. + + + +Zeilenga Best Current Practice [Page 3] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + A registry of OIDs used for discovery 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 [RFC4512]. Each + LDAP syntax is identified by an OID. This registry is provided to + allow implementors and others to locate the technical specification + describing a particular LDAP Syntax. + + 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 [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516] + extensions, and other objects. + + Although 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 [RFC3629] 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 following ABNF: + + + +Zeilenga Best Current Practice [Page 4] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + 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 that + start with that value. For example, the registration of the option + "descrFamily-" reserves all options that 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 + 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 [RFC4512] can contain zero or more options + specifying additional semantics. An option SHALL be restricted to a + string of 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 that start + with the name. For example, the registration of the option + "optionFamily-" reserves all options that start with "optionFamily-" + for some related purpose. + + Options beginning with "x-" are for Private Use and cannot be + registered. + + + + + +Zeilenga Best Current Practice [Page 5] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + 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 + [RFC4511. 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 + encoding. The choice numbers for existing protocol messages are + implicit in the protocol's ASN.1 defined in [RFC4511]. + + New values will be registered upon Standards Action. + + Note: LDAP provides extensible messages that reduce but do not + eliminate the need to add new message types. + +3.7. LDAP Authentication Method + + The LDAP Bind operation supports multiple authentication methods + [RFC4511]. 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 the 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 + + + +Zeilenga Best Current Practice [Page 6] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + 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 + [RFC4422] as an authentication choice. SASL is an extensible + authentication framework. + +3.8. LDAP Result Codes + + LDAP result messages carry a resultCode enumerated value to indicate + the outcome of the operation [RFC4511]. Each result code consists of + an 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 extent of search within the DIT [RFC4511]. Each search + value consists of an 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 [RFC4511]. 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. + + + +Zeilenga Best Current Practice [Page 7] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + 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 + + The LDAP ModifyRequest carries a sequence of modification operations + [RFC4511]. Each kind (e.g., add, delete, replace) of operation + consists of an 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 + <authzId> production [RFC4513]. 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. + + + +Zeilenga Best Current Practice [Page 8] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +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]. + + Directory systems names are not known to be used in any other + context. LDAPv3 [RFC4514] 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 regarded as the + registration owner of all values requiring Standards Action. + + If the policy is Expert Review, the requester SHALL post the + completed form to the <directory@apps.ietf.org> 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 <directory- + request@apps.ietf.org>. During the review, objections may be raised + by anyone (including the Expert) on the list. After completion of + the review, the Expert, based on 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 Directors. The requester is viewed + as the registration 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: <iana@iana.org>. The + requester is viewed as the registration owner of values registered + under First Come First Served. + + + +Zeilenga Best Current Practice [Page 9] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + Neither the Expert nor IANA will take position on the claims of + copyright or trademark 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 + 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 its web site: <http://www.iana.org/>. + +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 registration owner is unable or is unwilling to make + necessary updates, the IESG MAY assume ownership of the registration + in order to update the registration. + +5.3. Comments + + For cases where others (anyone other than the registration owner) + have significant objections to the claims in a registration and the + registration 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 of 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 [RFC4510]. + + + + + +Zeilenga Best Current Practice [Page 10] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +7. Acknowledgement + + 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. References + +8.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Structure of Management Information Version 2 (SMIv2)", + STD 58, RFC 2578, April 1999. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + + +Zeilenga Best Current Practice [Page 11] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access + Protocol (LDAP): Uniform Resource Locator", RFC 4516, June + 2006. + + [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). + +8.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. + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", RFC + 4514, June 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, June + 2006. + + [IANADSN] IANA, "Directory Systems Names", + http://www.iana.org/assignments/directory-system-names. + + + + + + + + + + + + + + + +Zeilenga Best Current Practice [Page 12] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +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 Best Current Practice [Page 13] + +RFC 4520 IANA Considerations for LDAP June 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.) + + + + + + + + + + + + + +Zeilenga Best Current Practice [Page 14] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +A.5. LDAP Attribute Description Option Registration Template + + Subject: Request for LDAP Attribute Description Option Registration + Option Name: + + Family of Options: (YES or NO) + + 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.) + + + +Zeilenga Best Current Practice [Page 15] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +A.8. LDAP Result Code Registration Template + + Subject: Request for LDAP Result Code Registration + + 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.) + + + + + + + + + + + + + + + + + + +Zeilenga Best Current Practice [Page 16] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +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.) + +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. + + + + + +Zeilenga Best Current Practice [Page 17] + +RFC 4520 IANA Considerations for LDAP June 2006 + + + - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest + operation, and authzId prefixes registries were added. + + - 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. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Best Current Practice [Page 18] + +RFC 4520 IANA Considerations for LDAP June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Best Current Practice [Page 19] + diff --git a/source4/ldap_server/devdocs/rfc4521.txt b/source4/ldap_server/devdocs/rfc4521.txt new file mode 100644 index 0000000000..813ff1e30f --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4521.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4521 OpenLDAP Foundation +BCP: 118 June 2006 +Category: Best Current Practice + + + Considerations for + Lightweight Directory Access Protocol (LDAP) Extensions + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) is extensible. It + provides mechanisms for adding new operations, extending existing + operations, and expanding user and system schemas. This document + discusses considerations for designers of LDAP extensions. + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Best Current Practice [Page 1] + +RFC 4521 LDAP Extensions June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................3 + 2. General Considerations ..........................................4 + 2.1. Scope of Extension .........................................4 + 2.2. Interaction between extensions .............................4 + 2.3. Discovery Mechanism ........................................4 + 2.4. Internationalization Considerations ........................5 + 2.5. Use of the Basic Encoding Rules ............................5 + 2.6. Use of Formal Languages ....................................5 + 2.7. Examples ...................................................5 + 2.8. Registration of Protocol Values ............................5 + 3. LDAP Operation Extensions .......................................6 + 3.1. Controls ...................................................6 + 3.1.1. Extending Bind Operation with Controls ..............6 + 3.1.2. Extending the Start TLS Operation with Controls .....7 + 3.1.3. Extending the Search Operation with Controls ........7 + 3.1.4. Extending the Update Operations with Controls .......8 + 3.1.5. Extending the Responseless Operations with Controls..8 + 3.2. Extended Operations ........................................8 + 3.3. Intermediate Responses .....................................8 + 3.4. Unsolicited Notifications ..................................9 + 4. Extending the LDAP ASN.1 Definition .............................9 + 4.1. Result Codes ...............................................9 + 4.2. LDAP Message Types .........................................9 + 4.3. Authentication Methods ....................................10 + 4.4. General ASN.1 Extensibility ...............................10 + 5. Schema Extensions ..............................................10 + 5.1. LDAP Syntaxes .............................................11 + 5.2. Matching Rules ............................................11 + 5.3. Attribute Types ...........................................12 + 5.4. Object Classes ............................................12 + 6. Other Extension Mechanisms .....................................12 + 6.1. Attribute Description Options .............................12 + 6.2. Authorization Identities ..................................12 + 6.3. LDAP URL Extensions .......................................12 + 7. Security Considerations ........................................12 + 8. Acknowledgements ...............................................13 + 9. References .....................................................13 + 9.1. Normative References ......................................13 + 9.2. Informative References ....................................15 + + + + + + + + + +Zeilenga Best Current Practice [Page 2] + +RFC 4521 LDAP Extensions June 2006 + + +1. Introduction + + The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an + extensible protocol. + + LDAP allows for new operations to be added and for existing + operations to be enhanced [RFC4511]. + + LDAP allows additional schema to be defined [RFC4512][RFC4517]. This + can include additional object classes, attribute types, matching + rules, additional syntaxes, and other elements of schema. LDAP + provides an ability to extend attribute types with options [RFC4512]. + + LDAP supports a Simple Authentication and Security Layer (SASL) + authentication method [RFC4511][RFC4513]. SASL [RFC4422] is + extensible. LDAP may be extended to support additional + authentication methods [RFC4511]. + + LDAP supports establishment of Transport Layer Security (TLS) + [RFC4511][RFC4513]. TLS [RFC4346] is extensible. + + LDAP has an extensible Uniform Resource Locator (URL) format + [RFC4516]. + + Lastly, LDAP allows for certain extensions to the protocol's Abstract + Syntax Notation - One (ASN.1) [X.680] definition to be made. This + facilitates a wide range of protocol enhancements, for example, new + result codes needed to support extensions to be added through + extension of the protocol's ASN.1 definition. + + This document describes practices that engineers should consider when + designing extensions to LDAP. + +1.1. 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 document, "the specification", as used by BCP 14, RFC 2119, + refers to the engineering of LDAP extensions. + + The term "Request Control" refers to a control attached to a client- + generated message sent to a server. The term "Response Control" + refers to a control attached to a server-generated message sent to a + client. + + + + + + +Zeilenga Best Current Practice [Page 3] + +RFC 4521 LDAP Extensions June 2006 + + + DIT stands for Directory Information Tree. + DSA stands for Directory System Agent, a server. + DSE stands for DSA-Specific Entry. + DUA stands for Directory User Agent, a client. + DN stands for Distinguished Name. + +2. General Considerations + +2.1. Scope of Extension + + Mutually agreeing peers may, within the confines of an extension, + agree to significant changes in protocol semantics. However, + designers MUST consider the impact of an extension upon protocol + peers that have not agreed to implement or otherwise recognize and + support the extension. Extensions MUST be "truly optional" + [RFC2119]. + +2.2. Interaction between extensions + + Designers SHOULD consider how extensions they engineer interact with + other extensions. + + Designers SHOULD consider the extensibility of extensions they + specify. Extensions to LDAP SHOULD themselves be extensible. + + Except where it is stated otherwise, extensibility is implied. + +2.3. Discovery Mechanism + + Extensions SHOULD provide adequate discovery mechanisms. + + As LDAP design is based upon the client-request/server-response + paradigm, the general discovery approach is for the client to + discover the capabilities of the server before utilizing a particular + extension. Commonly, this discovery involves querying the root DSE + and/or other DSEs for operational information associated with the + extension. LDAP provides no mechanism for a server to discover the + capabilities of a client. + + The 'supportedControl' attribute [RFC4512] is used to advertise + supported controls. The 'supportedExtension' attribute [RFC4512] is + used to advertise supported extended operations. The + 'supportedFeatures' attribute [RFC4512] is used to advertise + features. Other root DSE attributes MAY be defined to advertise + other capabilities. + + + + + + +Zeilenga Best Current Practice [Page 4] + +RFC 4521 LDAP Extensions June 2006 + + +2.4. Internationalization Considerations + + LDAP is designed to support the full Unicode [Unicode] repertory of + characters. Extensions SHOULD avoid unnecessarily restricting + applications to subsets of Unicode (e.g., Basic Multilingual Plane, + ISO 8859-1, ASCII, Printable String). + + LDAP Language Tag options [RFC3866] provide a mechanism for tagging + text (and other) values with language information. Extensions that + define attribute types SHOULD allow use of language tags with these + attributes. + +2.5. Use of the Basic Encoding Rules + + Numerous elements of LDAP are described using ASN.1 [X.680] and are + encoded using a particular subset [Protocol, Section 5.2] of the + Basic Encoding Rules (BER) [X.690]. To allow reuse of + parsers/generators used in implementing the LDAP "core" technical + specification [RFC4510], it is RECOMMENDED that extension elements + (e.g., extension specific contents of controlValue, requestValue, + responseValue fields) described by ASN.1 and encoded using BER be + subjected to the restrictions of [Protocol, Section 5.2]. + +2.6. Use of Formal Languages + + Formal languages SHOULD be used in specifications in accordance with + IESG guidelines [FORMAL]. + +2.7. Examples + + Example DN strings SHOULD conform to the syntax defined in [RFC4518]. + Example LDAP filter strings SHOULD conform to the syntax defined in + [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in + [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849]. + +2.8. Registration of Protocol Values + + Designers SHALL register protocol values of their LDAP extensions in + accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that + create new extensible protocol elements SHALL extend existing + registries or establish new registries for values of these elements + in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434 + [RFC2434]. + + + + + + + + +Zeilenga Best Current Practice [Page 5] + +RFC 4521 LDAP Extensions June 2006 + + +3. LDAP Operation Extensions + + Extensions SHOULD use controls in defining extensions that complement + existing operations. Where the extension to be defined does not + complement an existing operation, designers SHOULD consider defining + an extended operation instead. + + For example, a subtree delete operation could be designed as either + an extension of the delete operation or as a new operation. As the + feature complements the existing delete operation, use of the control + mechanism to extend the delete operation is likely more appropriate. + + As a counter (and contrived) example, a locate services operation (an + operation that would return for a DN a set of LDAP URLs to services + that may hold the entry named by this DN) could be designed as either + a search operation or a new operation. As the feature doesn't + complement the search operation (e.g., the operation is not contrived + to search for entries held in the Directory Information Tree), it is + likely more appropriate to define a new operation using the extended + operation mechanism. + +3.1. Controls + + Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for + extending existing operations. The existing operation can be a base + operation defined in [RFC4511] (e.g., search, modify) , an extended + operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or + an operation defined as an extension to a base or extended operation. + + Extensions SHOULD NOT return Response controls unless the server has + specific knowledge that the client can make use of the control. + Generally, the client requests the return of a particular response + control by providing a related request control. + + An existing operation MAY be extended to return IntermediateResponse + messages [Protocol, Section 4.13]. + + Specifications of controls SHALL NOT attach additional semantics to + the criticality of controls beyond those defined in [Protocol, + Section 4.1.11]. A specification MAY mandate the criticality take on + a particular value (e.g., TRUE or FALSE), where appropriate. + +3.1.1. Extending Bind Operation with Controls + + Controls attached to the request and response messages of a Bind + Operation [RFC4511] are not protected by any security layers + established by that Bind operation. + + + + +Zeilenga Best Current Practice [Page 6] + +RFC 4521 LDAP Extensions June 2006 + + + Specifications detailing controls extending the Bind operation SHALL + detail that the Bind negotiated security layers do not protect the + information contained in these controls and SHALL detail how the + information in these controls is protected or why the information + does not need protection. + + It is RECOMMENDED that designers consider alternative mechanisms for + providing the function. For example, an extended operation issued + subsequent to the Bind operation (hence, protected by the security + layers negotiated by the Bind operation) might be used to provide the + desired function. + + Additionally, designers of Bind control extensions MUST also consider + how the controls' semantics interact with individual steps of a + multi-step Bind operation. Note that some steps are optional and + thus may require special attention in the design. + +3.1.2. Extending the Start TLS Operation with Controls + + Controls attached to the request and response messages of a Start TLS + Operation [RFC4511] are not protected by the security layers + established by the Start TLS operation. + + Specifications detailing controls extending the Start TLS operation + SHALL detail that the Start TLS negotiated security layers do not + protect the information contained in these controls and SHALL detail + how the information in these controls is protected or why the + information does not need protection. + + It is RECOMMENDED that designers consider alternative mechanisms for + providing the function. For example, an extended operation issued + subsequent to the Start TLS operation (hence, protected by the + security layers negotiated by the Start TLS operation) might be used + to provided the desired function. + +3.1.3. Extending the Search Operation with Controls + + The Search operation processing has two distinct phases: + + - finding the base object; and + + - searching for objects at or under that base object. + + Specifications of controls extending the Search Operation should + clearly state in which phase(s) the control's semantics apply. + Semantics of controls that are not specific to the Search Operation + SHOULD apply in the finding phase. + + + + +Zeilenga Best Current Practice [Page 7] + +RFC 4521 LDAP Extensions June 2006 + + +3.1.4. Extending the Update Operations with Controls + + Update operations have properties of atomicity, consistency, + isolation, and durability ([ACID]). + + - atomicity: All or none of the DIT changes requested are made. + + - consistency: The resulting DIT state must be conform to schema + and other constraints. + + - isolation: Intermediate states are not exposed. + + - durability: The resulting DIT state is preserved until + subsequently updated. + + When defining a control that requests additional (or other) DIT + changes be made to the DIT, these additional changes SHOULD NOT be + treated as part of a separate transaction. The specification MUST be + clear as to whether the additional DIT changes are part of the same + or a separate transaction as the DIT changes expressed in the request + of the base operation. + + When defining a control that requests additional (or other) DIT + changes be made to the DIT, the specification MUST be clear as to the + order in which these and the base changes are to be applied to the + DIT. + +3.1.5. Extending the Responseless Operations with Controls + + The Abandon and Unbind operations do not include a response message. + For this reason, specifications for controls designed to be attached + to Abandon and Unbind requests SHOULD mandate that the control's + criticality be FALSE. + +3.2. Extended Operations + + Extended Operations [Protocol, Section 4.12] are the RECOMMENDED + mechanism for defining new operations. An extended operation + consists of an ExtendedRequest message, zero or more + IntermediateResponse messages, and an ExtendedResponse message. + +3.3. Intermediate Responses + + Extensions SHALL use IntermediateResponse messages instead of + ExtendedResponse messages to return intermediate results. + + + + + + +Zeilenga Best Current Practice [Page 8] + +RFC 4521 LDAP Extensions June 2006 + + +3.4. Unsolicited Notifications + + Unsolicited notifications [Protocol, Section 4.4] offer a capability + for the server to notify the client of events not associated with the + operation currently being processed. + + Extensions SHOULD be designed such that unsolicited notifications are + not returned unless the server has specific knowledge that the client + can make use of the notification. Generally, the client requests the + return of a particular unsolicited notification by performing a + related extended operation. + + For example, a time hack extension could be designed to return + unsolicited notifications at regular intervals that were enabled by + an extended operation (which possibly specified the desired + interval). + +4. Extending the LDAP ASN.1 Definition + + LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 + definition [Protocol, Appendix B] to be made. + +4.1. Result Codes + + Extensions that specify new operations or enhance existing operations + often need to define new result codes. The extension SHOULD be + designed such that a client has a reasonably clear indication of the + nature of the successful or non-successful result. + + Extensions SHOULD use existing result codes to indicate conditions + that are consistent with the intended meaning [RFC4511][X.511] of + these codes. Extensions MAY introduce new result codes [RFC4520] + where no existing result code provides an adequate indication of the + nature of the result. + + Extensions SHALL NOT disallow or otherwise restrict the return of + general service result codes, especially those reporting a protocol, + service, or security problem, or indicating that the server is unable + or unwilling to complete the operation. + +4.2. LDAP Message Types + + While extensions can specify new types of LDAP messages by extending + the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally + unnecessary and inappropriate. Existing operation extension + mechanisms (e.g., extended operations, unsolicited notifications, and + intermediate responses) SHOULD be used instead. However, there may + be cases where an extension does not fit well into these mechanisms. + + + +Zeilenga Best Current Practice [Page 9] + +RFC 4521 LDAP Extensions June 2006 + + + In such cases, a new extension mechanism SHOULD be defined that can + be used by multiple extensions that have similar needs. + +4.3. Authentication Methods + + The Bind operation currently supports two authentication methods, + simple and SASL. SASL [RFC4422] is an extensible authentication + framework used by multiple application-level protocols (e.g., BEEP, + IMAP, SMTP). It is RECOMMENDED that new authentication processes be + defined as SASL mechanisms. New LDAP authentication methods MAY be + added to support new authentication frameworks. + + The Bind operation's primary function is to establish the LDAP + association [RFC4513]. No other operation SHALL be defined (or + extended) to establish the LDAP association. However, other + operations MAY be defined to establish other security associations + (e.g., IPsec). + +4.4. General ASN.1 Extensibility + + Section 4 of [RFC4511] states the following: + + In order to support future extensions to this protocol, + extensibility is implied where it is allowed per ASN.1 (i.e., + sequence, set, choice, and enumerated types are extensible). In + addition, ellipses (...) have been supplied in ASN.1 types that + are explicitly extensible as discussed in [RFC4520]. Because of + the implied extensibility, clients and servers MUST (unless + otherwise specified) ignore trailing SEQUENCE components whose + tags they do not recognize. + + Designers SHOULD avoid introducing extensions that rely on + unsuspecting implementations to ignore trailing components of + SEQUENCE whose tags they do not recognize. + +5. Schema Extensions + + Extensions defining LDAP schema elements SHALL provide schema + definitions conforming with syntaxes defined in [Models, Section + 4.1]. While provided definitions MAY be reformatted (line wrapped) + for readability, this SHALL be noted in the specification. + + For definitions that allow a NAME field, new schema elements SHOULD + provide one and only one name. The name SHOULD be short. + + Each schema definition allows a DESC field. The DESC field, if + provided, SHOULD contain a short descriptive phrase. The DESC field + MUST be regarded as informational. That is, the specification MUST + + + +Zeilenga Best Current Practice [Page 10] + +RFC 4521 LDAP Extensions June 2006 + + + be written such that its interpretation is the same with and without + the provided DESC fields. + + The extension SHALL NOT mandate that implementations provide the same + DESC field in the schema they publish. Implementors MAY replace or + remove the DESC field. + + Published schema elements SHALL NOT be redefined. Replacement schema + elements (new OIDs, new NAMEs) SHOULD be defined as needed. + + Schema designers SHOULD reuse existing schema elements, where + appropriate. However, any reuse MUST not alter the semantics of the + element. + +5.1. LDAP Syntaxes + + Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680]. + Each extension detailing an LDAP syntax MUST specify the ASN.1 data + definition associated with the syntax. A distinct LDAP syntax SHOULD + be created for each distinct ASN.1 data definition (including + constraints). + + Each LDAP syntax SHOULD have a string encoding defined for it. It is + RECOMMENDED that this string encoding be restricted to UTF-8 + [RFC3629] encoded Unicode [Unicode] characters. Use of Generic + String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic + string encoding rules to provide string encodings for complex ASN.1 + data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that + the string encoding be described using a formal language (e.g., ABNF + [RFC4234]). Formal languages SHOULD be used in specifications in + accordance with IESG guidelines [FORMAL]. + + If no string encoding is defined, the extension SHALL specify how the + transfer encoding is to be indicated. Generally, the extension + SHOULD mandate use of binary or other transfer encoding option. + +5.2. Matching Rules + + Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and + SUBSTRING) may be associated with an attribute type. In addition, + LDAP provides an extensible matching rule mechanism. + + The matching rule specification SHOULD detail which kind of matching + rule it is and SHOULD describe which kinds of values it can be used + with. + + In addition to requirements stated in the LDAP technical + specification, equality matching rules SHOULD be commutative. + + + +Zeilenga Best Current Practice [Page 11] + +RFC 4521 LDAP Extensions June 2006 + + +5.3. Attribute Types + + Designers SHOULD carefully consider how the structure of values is to + be restricted. Designers SHOULD consider that servers will only + enforce constraints of the attribute's syntax. That is, an attribute + intended to hold URIs, but that has directoryString syntax, is not + restricted to values that are URIs. + + Designers SHOULD carefully consider which matching rules, if any, are + appropriate for the attribute type. Matching rules specified for an + attribute type MUST be compatible with the attribute type's syntax. + + Extensions specifying operational attributes MUST detail how servers + are to maintain and/or utilize values of each operational attribute. + +5.4. Object Classes + + Designers SHOULD carefully consider whether each attribute of an + object class is required ("MUST") or allowed ("MAY"). + + Extensions specifying object classes that allow (or require) + operational attributes MUST specify how servers are to maintain + and/or utilize entries belonging to these object classes. + +6. Other Extension Mechanisms + +6.1. Attribute Description Options + + Each option is identified by a string of letters, numbers, and + hyphens. This string SHOULD be short. + +6.2. Authorization Identities + + Extensions interacting with authorization identities SHALL support + the LDAP authzId format [RFC4513]. The authzId format is extensible. + +6.3. LDAP URL Extensions + + LDAP URL extensions are identified by a short string, a descriptor. + Like other descriptors, the string SHOULD be short. + +7. Security Considerations + + LDAP does not place undue restrictions on the kinds of extensions + that can be implemented. While this document attempts to outline + some specific issues that designers need to consider, it is not (and + + + + + +Zeilenga Best Current Practice [Page 12] + +RFC 4521 LDAP Extensions June 2006 + + + cannot be) all encompassing. Designers MUST do their own evaluations + of the security considerations applicable to their extensions. + + Designers MUST NOT assume that the LDAP "core" technical + specification [RFC4510] adequately addresses the specific concerns + surrounding their extensions or assume that their extensions have no + specific concerns. + + Extension specifications, however, SHOULD note whether security + considerations specific to the feature they are extending, as well as + general LDAP security considerations, apply to the extension. + +8. Acknowledgements + + The author thanks the IETF LDAP community for their thoughtful + comments. + + This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce + Greenblatt. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - + Technical Specification", RFC 2849, June 2000. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + + [RFC3642] Legg, S., "Common Elements of Generic String Encoding + Rules (GSER) Encodings", RFC 3642, October 2003. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + + + + +Zeilenga Best Current Practice [Page 13] + +RFC 4521 LDAP Extensions June 2006 + + + [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the + Lightweight Directory Access Protocol (LDAP)", RFC 3866, + July 2004. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access + Protocol (LDAP): String Representation of Search Filters", + RFC 4515, June 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access + Protocol (LDAP): Uniform Resource Locator", RFC 4516, June + 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. + + [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", RFC + 4518, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, June + 2006. + + + + + + + +Zeilenga Best Current Practice [Page 14] + +RFC 4521 LDAP Extensions June 2006 + + + [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/). + + [FORMAL] IESG, "Guidelines for the use of formal languages in IETF + specifications", + <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in- + specs.txt>, 2001. + + [X.511] International Telecommunication Union - Telecommunication + Standardization Sector, "The Directory: Abstract Service + Definition", X.511(1993) (also ISO/IEC 9594-3:1993). + + [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). + + [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(2002) (also ISO/IEC 8825-1:2002). + +9.2. Informative References + + [ACID] Section 4 of ISO/IEC 10026-1:1992. + + [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in + Progress. + + [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", + RFC 3062, February 2001. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + +Zeilenga Best Current Practice [Page 15] + +RFC 4521 LDAP Extensions June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Best Current Practice [Page 16] + diff --git a/source4/ldap_server/devdocs/rfc4522.txt b/source4/ldap_server/devdocs/rfc4522.txt new file mode 100644 index 0000000000..11156a07f1 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4522.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Legg +Request for Comments: 4522 eB2Bcom +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP): + The Binary Encoding Option + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory has a defined syntax (i.e., data type). A syntax + definition specifies how attribute values conforming to the syntax + are normally represented when transferred in LDAP operations. This + representation is referred to as the LDAP-specific encoding to + distinguish it from other methods of encoding attribute values. This + document defines an attribute option, the binary option, that can be + used to specify that the associated attribute values are instead + encoded according to the Basic Encoding Rules (BER) used by X.500 + directories. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions .....................................................2 + 3. The Binary Option ...............................................2 + 4. Syntaxes Requiring Binary Transfer ..............................3 + 5. Attributes Returned in a Search .................................4 + 6. All User Attributes .............................................4 + 7. Conflicting Requests ............................................5 + 8. Security Considerations .........................................5 + 9. IANA Considerations .............................................5 + 10. References .....................................................5 + 10.1. Normative References ......................................5 + 10.2. Informative References ....................................6 + + + + +Legg Standards Track [Page 1] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + +1. Introduction + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory [RFC4510] has a defined syntax (i.e., data type) + which constrains the structure and format of its values. + + The description of each syntax [RFC4517] specifies how attribute or + assertion values [RFC4512] conforming to the syntax are normally + represented when transferred in LDAP operations [RFC4511]. This + representation is referred to as the LDAP-specific encoding to + distinguish it from other methods of encoding attribute values. + + This document defines an attribute option, the binary option, which + can be used in an attribute description [RFC4512] in an LDAP + operation to specify that the associated attribute values or + assertion values are, or are requested to be, encoded according to + the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500] + directories, instead of the usual LDAP-specific encoding. + + The binary option was originally defined in RFC 2251 [RFC2251]. The + LDAP technical specification [RFC4510] has obsoleted the previously + defined LDAP technical specification [RFC3377], which included RFC + 2251. The binary option was not included in the revised LDAP + technical specification for a variety of reasons including + implementation inconsistencies. No attempt is made here to resolve + the known inconsistencies. + + This document reintroduces the binary option for use with certain + attribute syntaxes, such as certificate syntax [RFC4523], that + specifically require it. No attempt has been made to address use of + the binary option with attributes of syntaxes that do not require its + use. Unless addressed in a future specification, this use is to be + avoided. + +2. 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, RFC 2119 + [BCP14]. + +3. The Binary Option + + The binary option is indicated with the attribute option string + "binary" in an attribute description. Note that, like all attribute + options, the string representing the binary option is case + insensitive. + + + + +Legg Standards Track [Page 2] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + + Where the binary option is present in an attribute description, the + associated attribute values or assertion values MUST be BER encoded + (otherwise the values are encoded according to the LDAP-specific + encoding [RFC4517] for the attribute's syntax). Note that it is + possible for a syntax to be defined such that its LDAP-specific + encoding is exactly the same as its BER encoding. + + In terms of the protocol [RFC4511], the binary option specifies that + the contents octets of the associated AttributeValue or + AssertionValue OCTET STRING are a complete BER encoding of the + relevant value. + + The binary option is not a tagging option [RFC4512], so the presence + of the binary option does not specify an attribute subtype. An + attribute description containing the binary option references exactly + the same attribute as the attribute description without the binary + option. The supertype/subtype relationships of attributes with + tagging options are not altered in any way by the presence or absence + of the binary option. + + An attribute description SHALL be treated as unrecognized if it + contains the binary option and the syntax of the attribute does not + have an associated ASN.1 type [RFC4517], or the BER encoding of + values of that type is not supported. + + The presence or absence of the binary option only affects the + transfer of attribute and assertion values in the protocol; servers + store any particular attribute value in a format of their choosing. + +4. Syntaxes Requiring Binary Transfer + + The attribute values of certain attribute syntaxes are defined + without an LDAP-specific encoding and are required to be transferred + in the BER-encoded form. For the purposes of this document, these + syntaxes are said to have a binary transfer requirement. The + certificate, certificate list, certificate pair, and supported + algorithm syntaxes [RFC4523] are examples of syntaxes with a binary + transfer requirement. These syntaxes also have an additional + requirement that the exact BER encoding must be preserved. Note that + this is a property of the syntaxes themselves, and not a property of + the binary option. In the absence of this requirement, LDAP clients + would need to re-encode values using the Distinguished Encoding Rules + (DER). + + + + + + + + +Legg Standards Track [Page 3] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + +5. Attributes Returned in a Search + + An LDAP search request [RFC4511] contains a list of the attributes + (the requested attributes list) to be returned from each entry + matching the search filter. An attribute description in the + requested attributes list also implicitly requests all subtypes of + the attribute type in the attribute description, whether through + attribute subtyping or attribute tagging option subtyping [RFC4512]. + + The requested attributes list MAY contain attribute descriptions with + the binary option, but MUST NOT contain two attribute descriptions + with the same attribute type and the same tagging options (even if + only one of them has the binary option). The binary option in an + attribute description in the requested attributes list implicitly + applies to all the subtypes of the attribute type in the attribute + description (however, see Section 7). + + Attributes of a syntax with the binary transfer requirement, if + returned, SHALL be returned in the binary form (i.e., with the binary + option in the attribute description and the associated attribute + values BER encoded) regardless of whether the binary option was + present in the request (for the attribute or for one of its + supertypes). + + Attributes of a syntax without the binary transfer requirement, if + returned, SHOULD be returned in the form explicitly requested. That + is, if the attribute description in the requested attributes list + contains the binary option, then the corresponding attribute in the + result SHOULD be in the binary form. If the attribute description in + the request does not contain the binary option, then the + corresponding attribute in the result SHOULD NOT be in the binary + form. A server MAY omit an attribute from the result if it does not + support the requested encoding. + + Regardless of the encoding chosen, a particular attribute value is + returned at most once. + +6. All User Attributes + + If the list of attributes in a search request is empty or contains + the special attribute description string "*", then all user + attributes are requested to be returned. + + Attributes of a syntax with the binary transfer requirement, if + returned, SHALL be returned in the binary form. + + + + + + +Legg Standards Track [Page 4] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + + Attributes of a syntax without the binary transfer requirement and + having a defined LDAP-specific encoding SHOULD NOT be returned in the + binary form. + + Attributes of a syntax without the binary transfer requirement and + without a defined LDAP-specific encoding may be returned in the + binary form or omitted from the result. + +7. Conflicting Requests + + A particular attribute could be explicitly requested by an attribute + description and/or implicitly requested by the attribute descriptions + of one or more of its supertypes, or by the special attribute + description string "*". If the binary option is present in at least + one, but not all, of these attribute descriptions then the effect of + the request with respect to binary transfer is implementation + defined. + +8. Security Considerations + + When interpreting security-sensitive fields, and in particular fields + used to grant or deny access, implementations MUST ensure that any + matching rule comparisons are done on the underlying abstract value, + regardless of the particular encoding used. + +9. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + attribute description option registry [BCP64] as indicated by the + following template: + + Subject: + Request for LDAP Attribute Description Option Registration + Option Name: binary + Family of Options: NO + Person & email address to contact for further information: + Steven Legg <steven.legg@eb2bcom.com> + Specification: RFC 4522 + Author/Change Controller: IESG + +10. References + +10.1. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Legg Standards Track [Page 5] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + + [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC RFC 4510, + June 2006. + + [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol + (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Schema Definitions for X.509 Certificates", RFC + 4523, June 2006. + + [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, + Information Technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER). + +10.2. Informative References + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, + Information technology - Open Systems Interconnection - + The Directory: Overview of concepts, models and services + + + + + + + + + + +Legg Standards Track [Page 6] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + +Author's Address + + Dr. Steven Legg + eB2Bcom + Suite 3, Woodhouse Corporate Centre + 935 Station Street + Box Hill North, Victoria 3129 + AUSTRALIA + + Phone: +61 3 9896 7830 + Fax: +61 3 9896 7801 + EMail: steven.legg@eb2bcom.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 7] + +RFC 4522 LDAP: The Binary Encoding Option June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Legg Standards Track [Page 8] + diff --git a/source4/ldap_server/devdocs/rfc4523.txt b/source4/ldap_server/devdocs/rfc4523.txt new file mode 100644 index 0000000000..d2589811c7 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4523.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4523 OpenLDAP Foundation +Obsoletes: 2252, 2256, 2587 June 2006 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP) + Schema Definitions for X.509 Certificates + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + Abstract + + This document describes schema for representing X.509 certificates, + X.521 security information, and related elements in directories + accessible using the Lightweight Directory Access Protocol (LDAP). + The LDAP definitions for these X.509 and X.521 schema elements + replace those provided in RFCs 2252 and 2256. + +1. Introduction + + This document provides LDAP [RFC4510] schema definitions [RFC4512] + for a subset of elements specified in X.509 [X.509] and X.521 + [X.521], including attribute types for certificates, cross + certificate pairs, and certificate revocation lists; matching rules + to be used with these attribute types; and related object classes. + LDAP syntax definitions are also provided for associated assertion + and attribute values. + + As the semantics of these elements are as defined in X.509 and X.521, + knowledge of X.509 and X.521 is necessary to make use of the LDAP + schema definitions provided herein. + + This document, together with [RFC4510], obsoletes RFCs 2252 and 2256 + in their entirety. The changes (in this document) made since RFC + 2252 and RFC 2256 include: + + - addition of pkiUser, pkiCA, and deltaCRL classes; + + + +Zeilenga Standards Track [Page 1] + +RFC 4523 LDAP X.509 Schema June 2006 + + + - update of attribute types to include equality matching rules in + accordance with their X.500 specifications; + + - addition of certificate, certificate pair, certificate list, + and algorithm identifier matching rules; and + + - addition of LDAP syntax for assertion syntaxes for these + matching rules. + + This document obsoletes RFC 2587. The X.509 schema descriptions for + LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494]. + + 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 + [RFC4512]. Definitions provided here are formatted (line wrapped) + for readability. + +2. Syntaxes + + This section describes various syntaxes used in LDAP to transfer + certificates and related data types. + +2.1. Certificate + + ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' ) + + A value of this syntax is an X.509 Certificate [X.509, clause 7]. + + Due to changes made to the definition of a Certificate through time, + no LDAP-specific encoding is defined for this syntax. Values of this + syntax SHOULD be encoded using Distinguished Encoding Rules (DER) + [X.690] and MUST only be transferred using the ;binary transfer + option [RFC4522]; that is, by requesting and returning values using + attribute descriptions such as "userCertificate;binary". + + As values of this syntax contain digitally signed data, values of + this syntax and the form of each value MUST be preserved as + presented. + +2.2. CertificateList + + ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' ) + + A value of this syntax is an X.509 CertificateList [X.509, clause + 7.3]. + + + +Zeilenga Standards Track [Page 2] + +RFC 4523 LDAP X.509 Schema June 2006 + + + Due to changes made to the definition of a CertificateList through + time, no LDAP-specific encoding is defined for this syntax. Values + of this syntax SHOULD be encoded using DER [X.690] and MUST only be + transferred using the ;binary transfer option [RFC4522]; that is, by + requesting and returning values using attribute descriptions such as + "certificateRevocationList;binary". + + As values of this syntax contain digitally signed data, values of + this syntax and the form of each value MUST be preserved as + presented. + +2.3. CertificatePair + + ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' ) + + A value of this syntax is an X.509 CertificatePair [X.509, clause + 11.2.3]. + + Due to changes made to the definition of an X.509 CertificatePair + through time, no LDAP-specific encoding is defined for this syntax. + Values of this syntax SHOULD be encoded using DER [X.690] and MUST + only be transferred using the ;binary transfer option [RFC4522]; that + is, by requesting and returning values using attribute descriptions + such as "crossCertificatePair;binary". + + As values of this syntax contain digitally signed data, values of + this syntax and the form of each value MUST be preserved as + presented. + +2.4. SupportedAlgorithm + + ( 1.3.6.1.4.1.1466.115.121.1.49 + DESC 'X.509 Supported Algorithm' ) + + A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause + 11.2.7]. + + Due to changes made to the definition of an X.509 SupportedAlgorithm + through time, no LDAP-specific encoding is defined for this syntax. + Values of this syntax SHOULD be encoded using DER [X.690] and MUST + only be transferred using the ;binary transfer option [RFC4522]; that + is, by requesting and returning values using attribute descriptions + such as "supportedAlgorithms;binary". + + As values of this syntax contain digitally signed data, values of + this syntax and the form of the value MUST be preserved as presented. + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4523 LDAP X.509 Schema June 2006 + + +2.5. CertificateExactAssertion + + ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' ) + + A value of this syntax is an X.509 CertificateExactAssertion [X.509, + clause 11.3.1]. Values of this syntax MUST be encoded using the + Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 + provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234] + grammar for this syntax. + +2.6. CertificateAssertion + + ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' ) + + A value of this syntax is an X.509 CertificateAssertion [X.509, + clause 11.3.2]. Values of this syntax MUST be encoded using GSER + [RFC3641]. Appendix A.2 provides an equivalent ABNF [RFC4234] + grammar for this syntax. + +2.7. CertificatePairExactAssertion + + ( 1.3.6.1.1.15.3 + DESC 'X.509 Certificate Pair Exact Assertion' ) + + A value of this syntax is an X.509 CertificatePairExactAssertion + [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using + GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [RFC4234] + grammar for this syntax. + +2.8. CertificatePairAssertion + + ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' ) + + A value of this syntax is an X.509 CertificatePairAssertion [X.509, + clause 11.3.4]. Values of this syntax MUST be encoded using GSER + [RFC3641]. Appendix A.4 provides an equivalent ABNF [RFC4234] + grammar for this syntax. + +2.9. CertificateListExactAssertion + + ( 1.3.6.1.1.15.5 + DESC 'X.509 Certificate List Exact Assertion' ) + + A value of this syntax is an X.509 CertificateListExactAssertion + [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using + GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for + this syntax. + + + + +Zeilenga Standards Track [Page 4] + +RFC 4523 LDAP X.509 Schema June 2006 + + +2.10. CertificateListAssertion + + ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' ) + + A value of this syntax is an X.509 CertificateListAssertion [X.509, + clause 11.3.6]. Values of this syntax MUST be encoded using GSER + [RFC3641]. Appendix A.6 provides an equivalent ABNF [RFC4234] + grammar for this syntax. + +2.11. AlgorithmIdentifier + + ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' ) + + A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause + 7]. Values of this syntax MUST be encoded using GSER [RFC3641]. + + Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this + syntax. + +3. Matching Rules + + This section introduces a set of certificate and related matching + rules for use in LDAP. These rules are intended to act in accordance + with their X.500 counterparts. + +3.1. certificateExactMatch + + The certificateExactMatch matching rule compares the presented + certificate exact assertion value with an attribute value of the + certificate syntax as described in clause 11.3.1 of [X.509]. + + ( 2.5.13.34 NAME 'certificateExactMatch' + DESC 'X.509 Certificate Exact Match' + SYNTAX 1.3.6.1.1.15.1 ) + +3.2. certificateMatch + + The certificateMatch matching rule compares the presented certificate + assertion value with an attribute value of the certificate syntax as + described in clause 11.3.2 of [X.509]. + + ( 2.5.13.35 NAME 'certificateMatch' + DESC 'X.509 Certificate Match' + SYNTAX 1.3.6.1.1.15.2 ) + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4523 LDAP X.509 Schema June 2006 + + +3.3. certificatePairExactMatch + + The certificatePairExactMatch matching rule compares the presented + certificate pair exact assertion value with an attribute value of the + certificate pair syntax as described in clause 11.3.3 of [X.509]. + + ( 2.5.13.36 NAME 'certificatePairExactMatch' + DESC 'X.509 Certificate Pair Exact Match' + SYNTAX 1.3.6.1.1.15.3 ) + +3.4. certificatePairMatch + + The certificatePairMatch matching rule compares the presented + certificate pair assertion value with an attribute value of the + certificate pair syntax as described in clause 11.3.4 of [X.509]. + + ( 2.5.13.37 NAME 'certificatePairMatch' + DESC 'X.509 Certificate Pair Match' + SYNTAX 1.3.6.1.1.15.4 ) + +3.5. certificateListExactMatch + + The certificateListExactMatch matching rule compares the presented + certificate list exact assertion value with an attribute value of the + certificate pair syntax as described in clause 11.3.5 of [X.509]. + + ( 2.5.13.38 NAME 'certificateListExactMatch' + DESC 'X.509 Certificate List Exact Match' + SYNTAX 1.3.6.1.1.15.5 ) + +3.6. certificateListMatch + + The certificateListMatch matching rule compares the presented + certificate list assertion value with an attribute value of the + certificate pair syntax as described in clause 11.3.6 of [X.509]. + + ( 2.5.13.39 NAME 'certificateListMatch' + DESC 'X.509 Certificate List Match' + SYNTAX 1.3.6.1.1.15.6 ) + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4523 LDAP X.509 Schema June 2006 + + +3.7. algorithmIdentifierMatch + + The algorithmIdentifierMatch mating rule compares a presented + algorithm identifier with an attribute value of the supported + algorithm as described in clause 11.3.7 of [X.509]. + + ( 2.5.13.40 NAME 'algorithmIdentifier' + DESC 'X.509 Algorithm Identifier Match' + SYNTAX 1.3.6.1.1.15.7 ) + +4. Attribute Types + + This section details a set of certificate and related attribute types + for use in LDAP. + +4.1. userCertificate + + The userCertificate attribute holds the X.509 certificates issued to + the user by one or more certificate authorities, as discussed in + clause 11.2.1 of [X.509]. + + ( 2.5.4.36 NAME 'userCertificate' + DESC 'X.509 user certificate' + EQUALITY certificateExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) + + As required by this attribute type's syntax, values of this attribute + are requested and transferred using the attribute description + "userCertificate;binary". + +4.2. cACertificate + + The cACertificate attribute holds the X.509 certificates issued to + the certificate authority (CA), as discussed in clause 11.2.2 of + [X.509]. + + ( 2.5.4.37 NAME 'cACertificate' + DESC 'X.509 CA certificate' + EQUALITY certificateExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) + + As required by this attribute type's syntax, values of this attribute + are requested and transferred using the attribute description + "cACertificate;binary". + + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 4523 LDAP X.509 Schema June 2006 + + +4.3. crossCertificatePair + + The crossCertificatePair attribute holds an X.509 certificate pair, + as discussed in clause 11.2.3 of [X.509]. + + ( 2.5.4.40 NAME 'crossCertificatePair' + DESC 'X.509 cross certificate pair' + EQUALITY certificatePairExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) + + As required by this attribute type's syntax, values of this attribute + are requested and transferred using the attribute description + "crossCertificatePair;binary". + +4.4. certificateRevocationList + + The certificateRevocationList attribute holds certificate lists, as + discussed in 11.2.4 of [X.509]. + + ( 2.5.4.39 NAME 'certificateRevocationList' + DESC 'X.509 certificate revocation list' + EQUALITY certificateListExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) + + As required by this attribute type's syntax, values of this attribute + are requested and transferred using the attribute description + "certificateRevocationList;binary". + +4.5. authorityRevocationList + + The authorityRevocationList attribute holds certificate lists, as + discussed in 11.2.5 of [X.509]. + + ( 2.5.4.38 NAME 'authorityRevocationList' + DESC 'X.509 authority revocation list' + EQUALITY certificateListExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) + + As required by this attribute type's syntax, values of this attribute + are requested and transferred using the attribute description + "authorityRevocationList;binary". + + + + + + + + + + +Zeilenga Standards Track [Page 8] + +RFC 4523 LDAP X.509 Schema June 2006 + + +4.6. deltaRevocationList + + The deltaRevocationList attribute holds certificate lists, as + discussed in 11.2.6 of [X.509]. + + ( 2.5.4.53 NAME 'deltaRevocationList' + DESC 'X.509 delta revocation list' + EQUALITY certificateListExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) + + As required by this attribute type's syntax, values of this attribute + MUST be requested and transferred using the attribute description + "deltaRevocationList;binary". + +4.7. supportedAlgorithms + + The supportedAlgorithms attribute holds supported algorithms, as + discussed in 11.2.7 of [X.509]. + + ( 2.5.4.52 NAME 'supportedAlgorithms' + DESC 'X.509 supported algorithms' + EQUALITY algorithmIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) + + As required by this attribute type's syntax, values of this attribute + MUST be requested and transferred using the attribute description + "supportedAlgorithms;binary". + +5. Object Classes + + This section details a set of certificate-related object classes for + use in LDAP. + +5.1. pkiUser + + This object class is used in augment entries for objects that may be + subject to certificates, as defined in clause 11.1.1 of [X.509]. + + ( 2.5.6.21 NAME 'pkiUser' + DESC 'X.509 PKI User' + SUP top AUXILIARY + MAY userCertificate ) + + + + + + + + + +Zeilenga Standards Track [Page 9] + +RFC 4523 LDAP X.509 Schema June 2006 + + +5.2. pkiCA + + This object class is used to augment entries for objects that act as + certificate authorities, as defined in clause 11.1.2 of [X.509] + + ( 2.5.6.22 NAME 'pkiCA' + DESC 'X.509 PKI Certificate Authority' + SUP top AUXILIARY + MAY ( cACertificate $ certificateRevocationList $ + authorityRevocationList $ crossCertificatePair ) ) + +5.3. cRLDistributionPoint + + This class is used to represent objects that act as CRL distribution + points, as discussed in clause 11.1.3 of [X.509]. + + ( 2.5.6.19 NAME 'cRLDistributionPoint' + DESC 'X.509 CRL distribution point' + SUP top STRUCTURAL + MUST cn + MAY ( certificateRevocationList $ + authorityRevocationList $ deltaRevocationList ) ) + +5.4. deltaCRL + + The deltaCRL object class is used to augment entries to hold delta + revocation lists, as discussed in clause 11.1.4 of [X.509]. + + ( 2.5.6.23 NAME 'deltaCRL' + DESC 'X.509 delta CRL' + SUP top AUXILIARY + MAY deltaRevocationList ) + +5.5. strongAuthenticationUser + + This object class is used to augment entries for objects + participating in certificate-based authentication, as defined in + clause 6.15 of [X.521]. This object class is deprecated in favor of + pkiUser. + + ( 2.5.6.15 NAME 'strongAuthenticationUser' + DESC 'X.521 strong authentication user' + SUP top AUXILIARY + MUST userCertificate ) + + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4523 LDAP X.509 Schema June 2006 + + +5.6. userSecurityInformation + + This object class is used to augment entries with needed additional + associated security information, as defined in clause 6.16 of + [X.521]. + + ( 2.5.6.18 NAME 'userSecurityInformation' + DESC 'X.521 user security information' + SUP top AUXILIARY + MAY ( supportedAlgorithms ) ) + +5.7. certificationAuthority + + This object class is used to augment entries for objects that act as + certificate authorities, as defined in clause 6.17 of [X.521]. This + object class is deprecated in favor of pkiCA. + + ( 2.5.6.16 NAME 'certificationAuthority' + DESC 'X.509 certificate authority' + SUP top AUXILIARY + MUST ( authorityRevocationList $ + certificateRevocationList $ cACertificate ) + MAY crossCertificatePair ) + +5.8. certificationAuthority-V2 + + This object class is used to augment entries for objects that act as + certificate authorities, as defined in clause 6.18 of [X.521]. This + object class is deprecated in favor of pkiCA. + + ( 2.5.6.16.2 NAME 'certificationAuthority-V2' + DESC 'X.509 certificate authority, version 2' + SUP certificationAuthority AUXILIARY + MAY deltaRevocationList ) + +6. Security Considerations + + General certificate considerations [RFC3280] apply to LDAP-aware + certificate applications. General LDAP security considerations + [RFC4510] apply as well. + + While elements of certificate information are commonly signed, these + signatures only protect the integrity of the signed information. In + the absence of data integrity protections in LDAP (or lower layer, + e.g., IPsec), a server is not assured that client certificate request + (or other request) was unaltered in transit. Likewise, a client + cannot be assured that the results of the query were unaltered in + + + + +Zeilenga Standards Track [Page 11] + +RFC 4523 LDAP X.509 Schema June 2006 + + + transit. Hence, it is generally recommended that implementations + make use of authentication and data integrity services in LDAP + [RFC4513][RFC4511]. + +7. IANA Considerations + +7.1. Object Identifier Registration + + The IANA has registered an LDAP Object Identifier [RFC4520] for use + in this technical specification. + + Subject: Request for LDAP OID Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4523 + Author/Change Controller: IESG + Comments: + Identifies the LDAP X.509 Certificate schema elements + introduced in this document. + +7.2. Descriptor Registration + + The IANA has updated the LDAP + Descriptor registry [RFC44520] as indicated below. + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): see table + Object Identifier: see table + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: see table + Specification: RFC 4523 + Author/Change Controller: IESG + + algorithmIdentifierMatch M 2.5.13.40 + authorityRevocationList A 2.5.4.38 * + cACertificate A 2.5.4.37 * + cRLDistributionPoint O 2.5.6.19 * + certificateExactMatch M 2.5.13.34 + certificateListExactMatch M 2.5.13.38 + certificateListMatch M 2.5.13.39 + certificateMatch M 2.5.13.35 + certificatePairExactMatch M 2.5.13.36 + certificatePairMatch M 2.5.13.37 + certificateRevocationList A 2.5.4.39 * + certificationAuthority O 2.5.6.16 * + certificationAuthority-V2 O 2.5.6.16.2 * + crossCertificatePair A 2.5.4.40 * + + + +Zeilenga Standards Track [Page 12] + +RFC 4523 LDAP X.509 Schema June 2006 + + + deltaCRL O 2.5.6.23 * + deltaRevocationList A 2.5.4.53 * + pkiCA O 2.5.6.22 * + pkiUser O 2.5.6.21 * + strongAuthenticationUser O 2.5.6.15 * + supportedAlgorithms A 2.5.4.52 * + userCertificate A 2.5.4.36 * + userSecurityInformation O 2.5.6.18 * + + * Updates previous registration + +8. Acknowledgements + + This document is based on X.509, a product of the ITU-T. A number of + LDAP schema definitions were based on those found in RFCs 2252 and + 2256, both products of the IETF ASID WG. The ABNF productions in + Appendix A were provided by Steven Legg. Additional material was + borrowed from prior works by David Chadwick and Steven Legg to refine + the LDAP X.509 schema. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 + Types", RFC 3641, October 2003. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): + The Binary Encoding Option", RFC 4522, June 2006. + + [X.509] International Telecommunication Union - Telecommunication + Standardization Sector, "The Directory: Authentication + Framework", X.509(2000). + + + + + + + +Zeilenga Standards Track [Page 13] + +RFC 4523 LDAP X.509 Schema June 2006 + + + [X.521] International Telecommunication Union - Telecommunication + Standardization Sector, "The Directory: Selected Object + Classes", X.521(2000). + + [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(2002) (also ISO/IEC 8825-1:2002). + +9.2. Informative References + + [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol", RFC 1777, March 1995. + + [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): + Mapping between X.400 and RFC 822/MIME", RFC 2156, January + 1998. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol + version 2 (LDAPv2) to Historic Status", RFC 3494, March + 2003. + + [RFC3642] Legg, S., "Common Elements of Generic String Encoding + Rules (GSER) Encodings", RFC 3642, October 2003. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4513] Harrison, R. Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + + + + + + +Zeilenga Standards Track [Page 14] + +RFC 4523 LDAP X.509 Schema June 2006 + + +Appendix A. + + This appendix is informative. + + This appendix provides ABNF [RFC4234] grammars for GSER-based + [RFC3641] LDAP-specific encodings specified in this document. These + grammars where produced using, and relying on, Common Elements for + GSER Encodings [RFC3642]. + +A.1. CertificateExactAssertion + + CertificateExactAssertion = "{" sp cea-serialNumber "," + sp cea-issuer sp "}" + + cea-serialNumber = id-serialNumber msp CertificateSerialNumber + cea-issuer = id-issuer msp Name + + id-serialNumber = + %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber' + id-issuer = %x69.73.73.75.65.72 ; 'issuer' + + Name = id-rdnSequence ":" RDNSequence + id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence' + + CertificateSerialNumber = INTEGER + +A.2. CertificateAssertion + +CertificateAssertion = "{" [ sp ca-serialNumber ] + [ sep sp ca-issuer ] + [ sep sp ca-subjectKeyIdentifier ] + [ sep sp ca-authorityKeyIdentifier ] + [ sep sp ca-certificateValid ] + [ sep sp ca-privateKeyValid ] + [ sep sp ca-subjectPublicKeyAlgID ] + [ sep sp ca-keyUsage ] + [ sep sp ca-subjectAltName ] + [ sep sp ca-policy ] + [ sep sp ca-pathToName ] + [ sep sp ca-subject ] + [ sep sp ca-nameConstraints ] sp "}" + +ca-serialNumber = id-serialNumber msp CertificateSerialNumber +ca-issuer = id-issuer msp Name +ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp + SubjectKeyIdentifier +ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp + AuthorityKeyIdentifier + + + +Zeilenga Standards Track [Page 15] + +RFC 4523 LDAP X.509 Schema June 2006 + + +ca-certificateValid = id-certificateValid msp Time +ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime +ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp + OBJECT-IDENTIFIER +ca-keyUsage = id-keyUsage msp KeyUsage +ca-subjectAltName = id-subjectAltName msp AltNameType +ca-policy = id-policy msp CertPolicySet +ca-pathToName = id-pathToName msp Name +ca-subject = id-subject msp Name +ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax + +id-subjectKeyIdentifier = + %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72 + ; 'subjectKeyIdentifier' +id-authorityKeyIdentifier = + %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72 + ; 'authorityKeyIdentifier' +id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64 + ; 'certificateValid' +id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64 + ; 'privateKeyValid' +id-subjectPublicKeyAlgID = + %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44 + ; 'subjectPublicKeyAlgID' +id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage' +id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65 + ; 'subjectAltName' +id-policy = %x70.6F.6C.69.63.79 ; 'policy' +id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName' +id-subject = %x73.75.62.6A.65.63.74 ; 'subject' +id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73 + ; 'nameConstraints' + +SubjectKeyIdentifier = KeyIdentifier + +KeyIdentifier = OCTET-STRING + +AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ] + [ sep sp aki-authorityCertIssuer ] + [ sep sp aki-authorityCertSerialNumber ] sp "}" + +aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier +aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames + +GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}" +GeneralName = gn-otherName + / gn-rfc822Name + / gn-dNSName + + + +Zeilenga Standards Track [Page 16] + +RFC 4523 LDAP X.509 Schema June 2006 + + + / gn-x400Address + / gn-directoryName + / gn-ediPartyName + / gn-uniformResourceIdentifier + / gn-iPAddress + / gn-registeredID + +gn-otherName = id-otherName ":" OtherName +gn-rfc822Name = id-rfc822Name ":" IA5String +gn-dNSName = id-dNSName ":" IA5String +gn-x400Address = id-x400Address ":" ORAddress +gn-directoryName = id-directoryName ":" Name +gn-ediPartyName = id-ediPartyName ":" EDIPartyName +gn-iPAddress = id-iPAddress ":" OCTET-STRING +gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER + +gn-uniformResourceIdentifier = id-uniformResourceIdentifier + ":" IA5String + +id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName' +gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44 + ; 'registeredID' + +OtherName = "{" sp on-type-id "," sp on-value sp "}" +on-type-id = id-type-id msp OBJECT-IDENTIFIER +on-value = id-value msp Value + ;; <Value> as defined in Section 3 of [RFC3641] + +id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id' +id-value = %x76.61.6C.75.65 ; 'value' + +ORAddress = dquote *SafeIA5Character dquote +SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote + dquote dquote ; escaped double quote +dquote = %x22 ; '"' (double quote) + +;; Note: The <ORAddress> rule encodes the x400Address component +;; of a GeneralName as a character string between double quotes. +;; The character string is first derived according to Section 4.1 +;; of [RFC2156], and then any embedded double quotes are escaped +;; by being repeated. This resulting string is output between +;; double quotes. + +EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}" +nameAssigner = id-nameAssigner msp DirectoryString +partyName = id-partyName msp DirectoryString +id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72 + ; 'nameAssigner' + + + +Zeilenga Standards Track [Page 17] + +RFC 4523 LDAP X.509 Schema June 2006 + + +id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName' + +aki-authorityCertSerialNumber = id-authorityCertSerialNumber + msp CertificateSerialNumber + +id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72 + ; 'keyIdentifier' +id-authorityCertIssuer = + %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72 + ; 'authorityCertIssuer' + +id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43 + %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72 + ; 'authorityCertSerialNumber' + +Time = time-utcTime / time-generalizedTime +time-utcTime = id-utcTime ":" UTCTime +time-generalizedTime = id-generalizedTime ":" GeneralizedTime +id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime' +id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65 + ; 'generalizedTime' + +KeyUsage = BIT-STRING / key-usage-bit-list +key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}" + +;; Note: The <key-usage-bit-list> rule encodes the one bits in +;; a KeyUsage value as a comma separated list of identifiers. + +key-usage = id-digitalSignature + / id-nonRepudiation + / id-keyEncipherment + / id-dataEncipherment + / id-keyAgreement + / id-keyCertSign + / id-cRLSign + / id-encipherOnly + / id-decipherOnly + +id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74 + %x75.72.65 ; 'digitalSignature' +id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E + ; 'nonRepudiation' +id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74 + ; 'keyEncipherment' +id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E + %x74 ; "dataEncipherment' +id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74 + ; 'keyAgreement' + + + +Zeilenga Standards Track [Page 18] + +RFC 4523 LDAP X.509 Schema June 2006 + + +id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E + ; 'keyCertSign' +id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign" +id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79 + ; 'encipherOnly' +id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79 + ; 'decipherOnly' + +AltNameType = ant-builtinNameForm / ant-otherNameForm + +ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm +ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER + +id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D + ; 'builtinNameForm' +id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D + ; 'otherNameForm' + +BuiltinNameForm = id-rfc822Name + / id-dNSName + / id-x400Address + / id-directoryName + / id-ediPartyName + / id-uniformResourceIdentifier + / id-iPAddress + / id-registeredId + +id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name' +id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName' +id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address' +id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65 + ; 'directoryName' +id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65 + ; 'ediPartyName' +id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress' +id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64 + ; 'registeredId' + +id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75 + %x72.63.65.49.64.65.6E.74.69.66.69.65.72 + ; 'uniformResourceIdentifier' + +CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}" +CertPolicyId = OBJECT-IDENTIFIER + +NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ] + [ sep sp ncs-excludedSubtrees ] sp "}" + + + + +Zeilenga Standards Track [Page 19] + +RFC 4523 LDAP X.509 Schema June 2006 + + +ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees +ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees + +id-permittedSubtrees = + %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73 + ; 'permittedSubtrees' +id-excludedSubtrees = + %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73 + ; 'excludedSubtrees' + +GeneralSubtrees = "{" sp GeneralSubtree + *( "," sp GeneralSubtree ) sp "}" +GeneralSubtree = "{" sp gs-base + [ "," sp gs-minimum ] + [ "," sp gs-maximum ] sp "}" + +gs-base = id-base msp GeneralName +gs-minimum = id-minimum msp BaseDistance +gs-maximum = id-maximum msp BaseDistance + +id-base = %x62.61.73.65 ; 'base' +id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum' +id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum' + +BaseDistance = INTEGER-0-MAX + +A.3. CertificatePairExactAssertion + + CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ] + [sep sp cpea-issuedBy ] sp "}" + ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present. + + cpea-issuedTo = id-issuedToThisCAAssertion msp + CertificateExactAssertion + cpea-issuedBy = id-issuedByThisCAAssertion msp + CertificateExactAssertion + + id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73 + %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion' + id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73 + %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion' + + + + + + + + + + +Zeilenga Standards Track [Page 20] + +RFC 4523 LDAP X.509 Schema June 2006 + + +A.4. CertificatePairAssertion + + CertificatePairAssertion = "{" [ sp cpa-issuedTo ] + [sep sp cpa-issuedBy ] sp "}" + ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present. + + cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion + cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion + +A.5. CertificateListExactAssertion + + CertificateListExactAssertion = "{" sp clea-issuer "," + sp clea-thisUpdate + [ "," sp clea-distributionPoint ] sp "}" + + clea-issuer = id-issuer msp Name + clea-thisUpdate = id-thisUpdate msp Time + clea-distributionPoint = id-distributionPoint msp + DistributionPointName + + id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate' + id-distributionPoint = + %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74 + ; 'distributionPoint' + + DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer + + dpn-fullName = id-fullName ":" GeneralNames + dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":" + RelativeDistinguishedName + + id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName' + id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65 + %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer' + +A.6. CertificateListAssertion + + CertificateListAssertion = "{" [ sp cla-issuer ] + [ sep sp cla-minCRLNumber ] + [ sep sp cla-maxCRLNumber ] + [ sep sp cla-reasonFlags ] + [ sep sp cla-dateAndTime ] + [ sep sp cla-distributionPoint ] + [ sep sp cla-authorityKeyIdentifier ] sp "}" + + cla-issuer = id-issuer msp Name + cla-minCRLNumber = id-minCRLNumber msp CRLNumber + cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber + + + +Zeilenga Standards Track [Page 21] + +RFC 4523 LDAP X.509 Schema June 2006 + + + cla-reasonFlags = id-reasonFlags msp ReasonFlags + cla-dateAndTime = id-dateAndTime msp Time + + cla-distributionPoint = id-distributionPoint msp + DistributionPointName + + cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp + AuthorityKeyIdentifier + + id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72 + ; 'minCRLNumber' + id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72 + ; 'maxCRLNumber' + id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags' + id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime' + + CRLNumber = INTEGER-0-MAX + + ReasonFlags = BIT-STRING + / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}" + + reason-flag = id-unused + / id-keyCompromise + / id-cACompromise + / id-affiliationChanged + / id-superseded + / id-cessationOfOperation + / id-certificateHold + / id-privilegeWithdrawn + / id-aACompromise + + id-unused = %x75.6E.75.73.65.64 ; 'unused' + id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65 + ; 'keyCompromise' + id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65 + ; 'cACompromise' + id-affiliationChanged = + %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64 + ; 'affiliationChanged' + id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded' + id-cessationOfOperation = + %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E + ; 'cessationOfOperation' + id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64 + ; 'certificateHold' + id-privilegeWithdrawn = + %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E + ; 'privilegeWithdrawn' + + + +Zeilenga Standards Track [Page 22] + +RFC 4523 LDAP X.509 Schema June 2006 + + + id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65 + ; 'aACompromise' + +A.7. AlgorithmIdentifier + + AlgorithmIdentifier = "{" sp ai-algorithm + [ "," sp ai-parameters ] sp "}" + + ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER + ai-parameters = id-parameters msp Value + id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm' + id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters' + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 23] + +RFC 4523 LDAP X.509 Schema June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 24] + diff --git a/source4/ldap_server/devdocs/rfc4524.txt b/source4/ldap_server/devdocs/rfc4524.txt new file mode 100644 index 0000000000..fa36be27a3 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4524.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group K. Zeilenga, Ed. +Request for Comments: 4524 OpenLDAP Foundation +Obsoletes: 1274 June 2006 +Updates: 2247, 2798 +Category: Standards Track + + + COSINE LDAP/X.500 Schema + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document provides a collection of schema elements for use with + the Lightweight Directory Access Protocol (LDAP) from the COSINE and + Internet X.500 pilot projects. + + This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship to Other Documents ............................3 + 1.2. Terminology and Conventions ................................4 + 2. COSINE Attribute Types ..........................................4 + 2.1. associatedDomain ...........................................4 + 2.2. associatedName .............................................5 + 2.3. buildingName ...............................................5 + 2.4. co .........................................................5 + 2.5. documentAuthor .............................................6 + 2.6. documentIdentifier .........................................6 + 2.7. documentLocation ...........................................6 + 2.8. documentPublisher ..........................................7 + 2.9. documentTitle ..............................................7 + 2.10. documentVersion ...........................................7 + 2.11. drink .....................................................8 + 2.12. homePhone .................................................8 + 2.13. homePostalAddress .........................................8 + + + +Zeilenga Standards Track [Page 1] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + 2.14. host ......................................................9 + 2.15. info ......................................................9 + 2.16. mail ......................................................9 + 2.17. manager ..................................................10 + 2.18. mobile ...................................................10 + 2.19. organizationalStatus .....................................11 + 2.20. pager ....................................................11 + 2.21. personalTitle ............................................11 + 2.22. roomNumber ...............................................12 + 2.23. secretary ................................................12 + 2.24. uniqueIdentifier .........................................12 + 2.25. userClass ................................................13 + 3. COSINE Object Classes ..........................................13 + 3.1. account ...................................................13 + 3.2. document ..................................................14 + 3.3. documentSeries ............................................14 + 3.4. domain ....................................................15 + 3.5. domainRelatedObject .......................................16 + 3.6. friendlyCountry ...........................................16 + 3.7. rFC822LocalPart ...........................................17 + 3.8. room ......................................................18 + 3.9. simpleSecurityObject ......................................18 + 4. Security Considerations ........................................18 + 5. IANA Considerations ............................................19 + 6. Acknowledgements ...............................................20 + 7. References .....................................................20 + 7.1. Normative References ......................................20 + 7.2. Informative References ....................................21 + Appendix A. Changes since RFC 1274 ...............................23 + A.1. LDAP Short Names .........................................23 + A.2. pilotObject ..............................................23 + A.3. pilotPerson ..............................................23 + A.4. dNSDomain ................................................24 + A.5. pilotDSA and qualityLabelledData .........................24 + A.6. Attribute Syntaxes .......................................24 + Appendix B. Changes since RFC 2247 ...............................24 + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +1. Introduction + + In the late 1980s, X.500 Directory Services were standardized by the + CCITT (Commite' Consultatif International de Telegraphique et + Telephonique), now a part of the ITU (International Telephone Union). + This lead to Directory Service piloting activities in the early + 1990s, including the COSINE (Co-operation and Open Systems + Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in + Europe. Motivated by needs for large-scale directory pilots, RFC + 1274 was published to standardize the directory schema and naming + architecture for use in the COSINE and other Internet X.500 pilots + [RFC1274]. + + In the years that followed, X.500 Directory Services have evolved to + incorporate new capabilities and even new protocols. In particular, + the Lightweight Directory Access Protocol (LDAP) [RFC4510] was + introduced in the early 1990s [RFC1487], with Version 3 of LDAP + introduced in the late 1990s [RFC2251] and subsequently revised in + 2005 [RFC4510]. + + While much of the material in RFC 1274 has been superceded by + subsequently published ITU-T Recommendations and IETF RFCs, many of + the schema elements lack standardized schema descriptions for use in + modern X.500 and LDAP directory services despite the fact that these + schema elements are in wide use today. As the old schema + descriptions cannot be used without adaptation, interoperability + issues may arise due to lack of standardized modern schema + descriptions. + + This document addresses these issues by offering standardized schema + descriptions, where needed, for widely used COSINE schema elements. + +1.1. Relationship to Other Documents + + This document, together with [RFC4519] and [RFC4517], obsoletes RFC + 1274 in its entirety. [RFC4519] replaces Sections 9.3.1 (Userid) and + 9.3.21 (Domain Component) of RFC 1274. [RFC4517] replaces Section + 9.4 (Generally useful syntaxes) of RFC 1274. + + This document replaces the remainder of RFC 1274. Appendix A + discusses changes since RFC 1274, as well as why certain schema + elements were not brought forward in this revision of the COSINE + schema. All elements not brought are to be regarded as Historic. + + The description of the 'domain' object class provided in this + document supercedes that found in RFC 2247. That is, Section 3.4 of + this document replaces Section 5.2 of [RFC2247]. + + + + +Zeilenga Standards Track [Page 3] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + Some of the schema elements specified here were described in RFC 2798 + (inetOrgPerson schema). This document supersedes these descriptions. + This document, together with [RFC4519], replaces Section 9.1.3 of RFC + 2798. + +1.2. Terminology and 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]. + + DIT stands for Directory Information Tree. + DN stands for Distinguished Name. + DSA stands for Directory System Agent, a server. + DSE stands for DSA-Specific Entry. + DUA stands for Directory User Agent, a client. + + These terms are discussed in [RFC4512]. + + Schema definitions are provided using LDAP description formats + [RFC4512]. Definitions provided here are formatted (line wrapped) + for readability. + +2. COSINE Attribute Types + + This section details COSINE attribute types for use in LDAP. + +2.1. associatedDomain + + The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] + host names [RFC1123] that are associated with an object. That is, + values of this attribute should conform to the following ABNF: + + domain = root / label *( DOT label ) + root = SPACE + label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] + LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" + SPACE = %x20 ; space (" ") + HYPHEN = %x2D ; hyphen ("-") + DOT = %x2E ; period (".") + + For example, the entry in the DIT with a DN <DC=example,DC=com> might + have an associated domain of "example.com". + + ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' + EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + + +Zeilenga Standards Track [Page 4] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the + 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are + described in [RFC4517]. + + Note that the directory will not ensure that values of this attribute + conform to the <domain> production provided above. It is the + application's responsibility to ensure that domains it stores in this + attribute are appropriately represented. + + Also note that applications supporting Internationalized Domain Names + SHALL use the ToASCII method [RFC3490] to produce <label> components + of the <domain> production. + +2.2. associatedName + + The 'associatedName' attribute specifies names of entries in the + organizational DIT associated with a DNS domain [RFC1034][RFC2181]. + + ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the + 'distinguishedNameMatch' rule are described in [RFC4517]. + +2.3. buildingName + + The 'buildingName' attribute specifies names of the buildings where + an organization or organizational unit is based, for example, "The + White House". + + ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.4. co + + The 'co' (Friendly Country Name) attribute specifies names of + countries in human-readable format, for example, "Germany" and + "Federal Republic of Germany". It is commonly used in conjunction + with the 'c' (Country Name) [RFC4519] attribute (whose values are + restricted to the two-letter codes defined in [ISO3166]). + + + + +Zeilenga Standards Track [Page 5] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + ( 0.9.2342.19200300.100.1.43 NAME 'co' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.5. documentAuthor + + The 'documentAuthor' attribute specifies the distinguished names of + authors (or editors) of a document. For example, + + ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the + 'distinguishedNameMatch' rule are described in [RFC4517]. + +2.6. documentIdentifier + + The 'documentIdentifier' attribute specifies unique identifiers for a + document. A document may be identified by more than one unique + identifier. For example, RFC 3383 and BCP 64 are unique identifiers + that (presently) refer to the same document. + + ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.7. documentLocation + + The 'documentLocation' attribute specifies locations of the document + original. + + ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.8. documentPublisher + + The 'documentPublisher' attribute is the persons and/or organizations + that published the document. Documents that are jointly published + have one value for each publisher. + + ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.9. documentTitle + + The 'documentTitle' attribute specifies the titles of a document. + Multiple values are allowed to accommodate both long and short + titles, or other situations where a document has multiple titles, for + example, "The Lightweight Directory Access Protocol Technical + Specification" and "The LDAP Technical Specification". + + ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.10. documentVersion + + The 'documentVersion' attribute specifies the version information of + a document. + + ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.11. drink + + The 'drink' (favoriteDrink) attribute specifies the favorite drinks + of an object (or person), for instance, "cola" and "beer". + + ( 0.9.2342.19200300.100.1.5 NAME 'drink' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.12. homePhone + + The 'homePhone' (Home Telephone Number) attribute specifies home + telephone numbers (e.g., "+1 775 555 1234") associated with a person. + + ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' + EQUALITY telephoneNumberMatch + SUBSTR telephoneNumberSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the + 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are + described in [RFC4517]. + +2.13. homePostalAddress + + The 'homePostalAddress' attribute specifies home postal addresses for + an object. Each value should be limited to up to 6 directory strings + of 30 characters each. (Note: It is not intended that the directory + service enforce these limits.) + + ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' + EQUALITY caseIgnoreListMatch + SUBSTR caseIgnoreListSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) + + The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the + 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are + described in [RFC4517]. + + + + +Zeilenga Standards Track [Page 8] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +2.14. host + + The 'host' attribute specifies host computers, generally by their + primary fully qualified domain name (e.g., my-host.example.com). + + ( 0.9.2342.19200300.100.1.9 NAME 'host' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.15. info + + The 'info' attribute specifies any general information pertinent to + an object. This information is not necessarily descriptive of the + object. + + Applications should not attach specific semantics to values of this + attribute. The 'description' attribute [RFC4519] is available for + specifying descriptive information pertinent to an object. + + ( 0.9.2342.19200300.100.1.4 NAME 'info' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.16. mail + + The 'mail' (rfc822mailbox) attribute type holds Internet mail + addresses in Mailbox [RFC2821] form (e.g., user@example.com). + + ( 0.9.2342.19200300.100.1.3 NAME 'mail' + EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) + + The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the + 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are + described in [RFC4517]. + + + + + +Zeilenga Standards Track [Page 9] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + Note that the directory will not ensure that values of this attribute + conform to the <Mailbox> production [RFC2821]. It is the + application's responsibility to ensure that domains it stores in this + attribute are appropriately represented. + + Additionally, the directory will compare values per the matching + rules named in the above attribute type description. As these rules + differ from rules that normally apply to <Mailbox> comparisons, + operational issues may arise. For example, the assertion + (mail=joe@example.com) will match "JOE@example.com" even though the + <local-parts> differ. Also, where a user has two <Mailbox>es whose + addresses differ only by case of the <local-part>, both cannot be + listed as values of the user's mail attribute (as they are considered + equal by the 'caseIgnoreIA5Match' rule). + + Also note that applications supporting internationalized domain names + SHALL use the ToASCII method [RFC3490] to produce <sub-domain> + components of the <Mailbox> production. + +2.17. manager + + The 'manager' attribute specifies managers, by distinguished name, of + the person (or entity). + + ( 0.9.2342.19200300.100.1.10 NAME 'manager' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the + 'distinguishedNameMatch' rule are described in [RFC4517]. + +2.18. mobile + + The 'mobile' (mobileTelephoneNumber) attribute specifies mobile + telephone numbers (e.g., "+1 775 555 6789") associated with a person + (or entity). + + ( 0.9.2342.19200300.100.1.41 NAME 'mobile' + EQUALITY telephoneNumberMatch + SUBSTR telephoneNumberSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the + 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are + described in [RFC4517]. + + + + + + +Zeilenga Standards Track [Page 10] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +2.19. organizationalStatus + + The 'organizationalStatus' attribute specifies categories by which a + person is often referred to in an organization. Examples of usage in + academia might include "undergraduate student", "researcher", + "professor", and "staff". Multiple values are allowed where the + person is in multiple categories. + + Directory administrators and application designers SHOULD consider + carefully the distinctions between this and the 'title' and + 'userClass' attributes. + + ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.20. pager + + The 'pager' (pagerTelephoneNumber) attribute specifies pager + telephone numbers (e.g., "+1 775 555 5555") for an object. + + ( 0.9.2342.19200300.100.1.42 NAME 'pager' + EQUALITY telephoneNumberMatch + SUBSTR telephoneNumberSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the + 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are + described in [RFC4517]. + +2.21. personalTitle + + The 'personalTitle' attribute specifies personal titles for a person. + Examples of personal titles are "Frau", "Dr.", "Herr", and + "Professor". + + ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + + + + + +Zeilenga Standards Track [Page 11] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.22. roomNumber + + The 'roomNumber' attribute specifies the room number of an object. + During periods of renumbering, or in other circumstances where a room + has multiple valid room numbers associated with it, multiple values + may be provided. Note that the 'cn' (commonName) attribute type + SHOULD be used for naming room objects. + + ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +2.23. secretary + + The 'secretary' attribute specifies secretaries and/or administrative + assistants, by distinguished name. + + ( 0.9.2342.19200300.100.1.21 NAME 'secretary' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the + 'distinguishedNameMatch' rule are described in [RFC4517]. + +2.24. uniqueIdentifier + + The 'uniqueIdentifier' attribute specifies a unique identifier for an + object represented in the Directory. The domain within which the + identifier is unique and the exact semantics of the identifier are + for local definition. For a person, this might be an institution- + wide payroll number. For an organizational unit, it might be a + department code. + + ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + + + + +Zeilenga Standards Track [Page 12] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + + Note: X.520 also describes an attribute called 'uniqueIdentifier' + (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP + [RFC4519]. The attribute detailed here ought not be confused + with 'x500UniqueIdentifier'. + +2.25. userClass + + The 'userClass' attribute specifies categories of computer or + application user. The semantics placed on this attribute are for + local interpretation. Examples of current usage of this attribute in + academia are "student", "staff", and "faculty". Note that the + 'organizationalStatus' attribute type is now often preferred, as it + makes no distinction between persons as opposed to users. + + ( 0.9.2342.19200300.100.1.8 NAME 'userClass' + EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) + + The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the + 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described + in [RFC4517]. + +3. COSINE Object Classes + + This section details COSINE object classes for use in LDAP. + +3.1. account + + The 'account' object class is used to define entries representing + computer accounts. The 'uid' attribute SHOULD be used for naming + entries of this object class. + + ( 0.9.2342.19200300.100.4.5 NAME 'account' + SUP top STRUCTURAL + MUST uid + MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) + + The 'top' object class is described in [RFC4512]. The 'description', + 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in + [RFC4519]. The 'host' attribute type is described in Section 2 of + this document. + + + + + +Zeilenga Standards Track [Page 13] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + 3.3. documentSeriesExample: + + dn: uid=kdz,cn=Accounts,dc=Example,dc=COM + objectClass: account + uid: kdz + seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM + +3.2. document + + The 'document' object class is used to define entries that represent + documents. + + ( 0.9.2342.19200300.100.4.6 NAME 'document' + SUP top STRUCTURAL + MUST documentIdentifier + MAY ( cn $ description $ seeAlso $ l $ o $ ou $ + documentTitle $ documentVersion $ documentAuthor $ + documentLocation $ documentPublisher ) ) + + The 'top' object class is described in [RFC4512]. The 'cn', + 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are + described in [RFC4519]. The 'documentIdentifier', 'documentTitle', + 'documentVersion', 'documentAuthor', 'documentLocation', and + 'documentPublisher' attribute types are described in Section 2 of + this document. + + Example: + + dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM + objectClass: document + documentIdentifier: RFC 4524 + documentTitle: COSINE LDAP/X.500 Schema + documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM + documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt + documentPublisher: Internet Engineering Task Force + description: A collection of schema elements for use in LDAP + description: Obsoletes RFC 1274 + seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM + seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM + +3.3. documentSeries + + The 'documentSeries' object class is used to define an entry that + represents a series of documents (e.g., The Request For Comments + memos). + + + + + + +Zeilenga Standards Track [Page 14] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' + SUP top STRUCTURAL + MUST cn + MAY ( description $ l $ o $ ou $ seeAlso $ + telephonenumber ) ) + + The 'top' object class is described in [RFC4512]. The 'description', + 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are + described in [RFC4519]. + + Example: + + dn: cn=RFC,dc=Example,dc=COM + objectClass: documentSeries + cn: Request for Comments + cn: RFC + description: a series of memos about the Internet + +3.4. domain + + The 'domain' object class is used to define entries that represent + DNS domains for objects that are not organizations, organizational + units, or other kinds of objects more appropriately defined using an + object class specific to the kind of object being defined (e.g., + 'organization', 'organizationUnit'). + + The 'dc' attribute should be used for naming entries of the 'domain' + object class. + + ( 0.9.2342.19200300.100.4.13 NAME 'domain' + SUP top STRUCTURAL + MUST dc + MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ + x121Address $ registeredAddress $ destinationIndicator $ + preferredDeliveryMethod $ telexNumber $ + teletexTerminalIdentifier $ telephoneNumber $ + internationaliSDNNumber $ facsimileTelephoneNumber $ street $ + postOfficeBox $ postalCode $ postalAddress $ + physicalDeliveryOfficeName $ st $ l $ description $ o $ + associatedName ) ) + + The 'top' object class and the 'dc', 'userPassword', 'searchGuide', + 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', + 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', + 'teletexTerminalIdentifier', 'telephoneNumber', + 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', + 'postOfficeBox', 'postalCode', 'postalAddress', + 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types + + + +Zeilenga Standards Track [Page 15] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + are described in [RFC4519]. The 'associatedName' attribute type is + described in Section 2 of this document. + + Example: + + dn: dc=com + objectClass: domain + dc: com + description: the .COM TLD + +3.5. domainRelatedObject + + The 'domainRelatedObject' object class is used to define entries that + represent DNS domains that are "equivalent" to an X.500 domain, e.g., + an organization or organizational unit. + + ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' + SUP top AUXILIARY + MUST associatedDomain ) + + The 'top' object class is described in [RFC4512]. The + 'associatedDomain' attribute type is described in Section 2 of this + document. + + Example: + + dn: dc=example,dc=com + objectClass: organization + objectClass: dcObject + objectClass: domainRelatedObject + dc: example + associatedDomain: example.com + o: Example Organization + + The 'organization' and 'dcObject' object classes and the 'dc' and 'o' + attribute types are described in [RFC4519]. + +3.6. friendlyCountry + + The 'friendlyCountry' object class is used to define entries + representing countries in the DIT. The object class is used to allow + friendlier naming of countries than that allowed by the object class + 'country' [RFC4519]. + + ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' + SUP country STRUCTURAL + MUST co ) + + + + +Zeilenga Standards Track [Page 16] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The 'country' object class is described in [RFC4519]. The 'co' + attribute type is described in Section 2 of this document. + + Example: + + dn: c=DE + objectClass: country + objectClass: friendlyCountry + c: DE + co: Deutschland + co: Germany + co: Federal Republic of Germany + co: FRG + + The 'c' attribute type is described in [RFC4519]. + +3.7. rFC822LocalPart + + The 'rFC822LocalPart' object class is used to define entries that + represent the local part of Internet mail addresses [RFC2822]. This + treats the local part of the address as a 'domain' object. + + ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' + SUP domain STRUCTURAL + MAY ( cn $ description $ destinationIndicator $ + facsimileTelephoneNumber $ internationaliSDNNumber $ + physicalDeliveryOfficeName $ postalAddress $ postalCode $ + postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ + seeAlso $ sn $ street $ telephoneNumber $ + teletexTerminalIdentifier $ telexNumber $ x121Address ) ) + + The 'domain' object class is described in Section 3.4 of this + document. The 'cn', 'description', 'destinationIndicator', + 'facsimileTelephoneNumber', 'internationaliSDNNumber, + 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', + 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', + 'seeAlso', 'sn, 'street', 'telephoneNumber', + 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' + attribute types are described in [RFC4519]. + + Example: + + dn: dc=kdz,dc=example,dc=com + objectClass: domain + objectClass: rFC822LocalPart + dc: kdz + associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM + + + + +Zeilenga Standards Track [Page 17] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + The 'dc' attribute type is described in [RFC4519]. + +3.8. room + + The 'room' object class is used to define entries representing rooms. + The 'cn' (commonName) attribute SHOULD be used for naming entries of + this object class. + + ( 0.9.2342.19200300.100.4.7 NAME 'room' + SUP top STRUCTURAL + MUST cn + MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) + + The 'top' object class is described in [RFC4512]. The 'cn', + 'description', 'seeAlso', and 'telephoneNumber' attribute types are + described in [RFC4519]. The 'roomNumber' attribute type is described + in Section 2 of this document. + + dn: cn=conference room,dc=example,dc=com + objectClass: room + cn: conference room + telephoneNumber: +1 755 555 1111 + +3.9. simpleSecurityObject + + The 'simpleSecurityObject' object class is used to require an entry + to have a 'userPassword' attribute when the entry's structural object + class does not require (or allow) the 'userPassword attribute'. + + ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' + SUP top AUXILIARY + MUST userPassword ) + + The 'top' object class is described in [RFC4512]. The 'userPassword' + attribute type is described in [RFC4519]. + + dn: dc=kdz,dc=Example,dc=COM + objectClass: account + objectClass: simpleSecurityObject + uid: kdz + userPassword: My Password + seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM + +4. Security Considerations + + General LDAP security considerations [RFC4510] are applicable to the + use of this schema. Additional considerations are noted above where + appropriate. + + + +Zeilenga Standards Track [Page 18] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + Directories administrators should ensure that access to sensitive + information be restricted to authorized entities and that appropriate + data security services, including data integrity and data + confidentiality, are used to protect against eavesdropping. + + Simple authentication (e.g., plain text passwords) mechanisms should + only be used when adequate data security services are in place. LDAP + offers reasonably strong authentication and data security services + [RFC4513]. + +5. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry [RFC4520] as indicated in the following + template: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comment + Object Identifier: see comments + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: see comments + Specification: RFC 4524 + Author/Change Controller: IESG + Comments: + + The following descriptors have been updated to refer to RFC 4524. + + NAME Type OID + ------------------------ ---- -------------------------- + account O 0.9.2342.19200300.100.4.5 + associatedDomain A 0.9.2342.19200300.100.1.37 + associatedName A 0.9.2342.19200300.100.1.38 + buildingName A 0.9.2342.19200300.100.1.48 + co A 0.9.2342.19200300.100.1.43 + document O 0.9.2342.19200300.100.4.6 + documentAuthor A 0.9.2342.19200300.100.1.14 + documentIdentifier A 0.9.2342.19200300.100.1.11 + documentLocation A 0.9.2342.19200300.100.1.15 + documentPublisher A 0.9.2342.19200300.100.1.56 + documentSeries O 0.9.2342.19200300.100.4.8 + documentTitle A 0.9.2342.19200300.100.1.12 + documentVersion A 0.9.2342.19200300.100.1.13 + domain O 0.9.2342.19200300.100.4.13 + domainRelatedObject O 0.9.2342.19200300.100.4.17 + drink A 0.9.2342.19200300.100.1.5 + favouriteDrink A* 0.9.2342.19200300.100.1.5 + friendlyCountry O 0.9.2342.19200300.100.4.18 + + + +Zeilenga Standards Track [Page 19] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + friendlyCountryName A* 0.9.2342.19200300.100.1.43 + homePhone A 0.9.2342.19200300.100.1.20 + homePostalAddress A 0.9.2342.19200300.100.1.39 + homeTelephone A* 0.9.2342.19200300.100.1.20 + host A 0.9.2342.19200300.100.1.9 + info A 0.9.2342.19200300.100.1.4 + mail A 0.9.2342.19200300.100.1.3 + manager A 0.9.2342.19200300.100.1.10 + mobile A 0.9.2342.19200300.100.1.41 + mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41 + organizationalStatus A 0.9.2342.19200300.100.1.45 + pager A 0.9.2342.19200300.100.1.42 + pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42 + personalTitle A 0.9.2342.19200300.100.1.40 + rFC822LocalPart O 0.9.2342.19200300.100.4.14 + rfc822Mailbox A* 0.9.2342.19200300.100.1.3 + room O 0.9.2342.19200300.100.4.7 + roomNumber A 0.9.2342.19200300.100.1.6 + secretary A 0.9.2342.19200300.100.1.21 + simpleSecurityObject O 0.9.2342.19200300.100.4.19 + singleLevelQuality A 0.9.2342.19200300.100.1.50 + uniqueIdentifier A 0.9.2342.19200300.100.1.44 + userClass A 0.9.2342.19200300.100.1.8 + + where Type A is Attribute, Type O is ObjectClass, and * + indicates that the registration is historic in nature. + +6. Acknowledgements + + This document is based on RFC 1274, by Paul Barker and Steve Kille, + as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick + Huber, and Sri Satulari. + +7. References + +7.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October + 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Zeilenga Standards Track [Page 20] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. + Sataluri, "Using Domains in LDAP/X.500 Distinguished + Names", RFC 2247, January 1998. + + [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC + 2821, April 2001. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4513] Harrison, R., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RC 4517, June + 2006. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [X.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models," X.501(1993) (also ISO/IEC 9594- + 2:1994). + +7.2. Informative References + + [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991 + INTERNET MONTHLY REPORTS (p. 28-29), + http://www.iana.org/periodic-reports/imr-mar91.txt + + + + +Zeilenga Standards Track [Page 21] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + + [ISO3166] International Organization for Standardization, "Codes + for the representation of names of countries", ISO + 3166. + + [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500 + Schema", RFC 1274, November 1991. + + [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, + November 1991. + + [RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight + Directory Access Protocol", RFC 1487, July 1993. + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight + Directory Access Protocol (v3)", RFC 2251, December + 1997. + + [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object + Class", RFC 2798, April 2000. + + [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol + version 2 (LDAPv2) to Historic Status", RFC 3494, March + 2003. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520. + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 22] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +Appendix A. Changes since RFC 1274 + + This document represents a substantial rewrite of RFC 1274. The + following sections summarize the substantive changes. + +A.1. LDAP Short Names + + A number of COSINE attribute types have short names in LDAP. + + X.500 Name LDAP Short Name + ------------- --------------- + domainComponent dc + favoriteDrink drink + friendCountryName co + homeTelephoneNumber homePhone + mobileTelephoneNumber mobile + pagerTelephoneNumber pager + rfc822Mailbox mail + userid uid + + While the LDAP short names are generally used in LDAP, some + implementations may (for legacy reasons [RFC3494]) recognize the + attribute type by its X.500 name. Hence, the X.500 names have been + reserved solely for this purpose. + + Note: 'uid' and 'dc' are described in [RFC4519]. + +A.2. pilotObject + + The 'pilotObject' object class was not brought forward as its + function is largely replaced by operational attributes introduced in + X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the + function of the 'lastModifiedBy' and 'lastModifiedTime' attribute + types is now served by the 'creatorsName', 'createTimestamp', + 'modifiersName', and 'modifyTimestamp' operational attributes + [RFC4512]. + +A.3. pilotPerson + + The 'pilotPerson' object class was not brought forward as its + function is largely replaced by the 'organizationalPerson' [RFC4512] + object class and its subclasses, such as 'inetOrgPerson' [RFC2798]. + + Most of the related attribute types (e.g., 'mail', 'manager') were + brought forward as they are used in other object classes. + + + + + + +Zeilenga Standards Track [Page 23] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +A.4. dNSDomain + + The 'dNSDomain' object class and related attribute types were not + brought forward as its use is primarily experimental [RFC1279]. + +A.5. pilotDSA and qualityLabelledData + + The 'pilotDSA' and 'qualityLabelledData' object classes, as well as + related attribute types, were not brought forward as its use is + primarily experimental [QoS]. + +A.6. Attribute Syntaxes + + RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax. + This has been replaced with the IA5String syntax and appropriate + matching rules in 'mail' and 'associatedDomain'. + + RFC 1274 restricted 'mail' to have non-zero length values. This + restriction is not reflected in the IA5String syntax used in the + definitions provided in this specification. However, as values are + to conform to the <Mailbox> production, the 'mail' should not contain + zero-length values. Unfortunately, the directory service will not + enforce this restriction. + +Appendix B. Changes since RFC 2247 + + The 'domainNameForm' name form was not brought forward as + specification of name forms used in LDAP is left to a future + specification. + +Editor's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 24] + +RFC 4524 COSINE LDAP/X.500 Schema June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 25] + diff --git a/source4/ldap_server/devdocs/rfc4525.txt b/source4/ldap_server/devdocs/rfc4525.txt new file mode 100644 index 0000000000..6e15e4f6e9 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4525.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4525 OpenLDAP Foundation +Category: Informational June 2006 + + + Lightweight Directory Access Protocol (LDAP) + Modify-Increment Extension + + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes an extension to the Lightweight Directory + Access Protocol (LDAP) Modify operation to support an increment + capability. This extension is useful in provisioning applications, + especially when combined with the assertion control and/or the pre- + read or post-read control extension. + +Table of Contents + + 1. Background and Intended Use .....................................1 + 2. The Modify-Increment Extension ..................................2 + 3. LDIF Support ....................................................2 + 4. Security Considerations .........................................3 + 5. IANA Considerations .............................................3 + 5.1. Object Identifier ..........................................3 + 5.2. LDAP Protocol Mechanism ....................................3 + 5.3. LDAP Protocol Mechanism ....................................4 + 6. References ......................................................4 + 6.1. Normative References .......................................4 + 6.2. Informative References .....................................5 + +1. Background and Intended Use + + The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not + currently provide an operation to increment values of an attribute. + A client must read the values of the attribute and then modify those + values to increment them by the desired amount. As the values may be + updated by other clients between this add and modify, the client must + + + +Zeilenga Informational [Page 1] + +RFC 4525 LDAP Modify-Increment Extension June 2006 + + + be careful to construct the modify request so that it fails in this + case, and upon failure, to re-read the values and construct a new + modify request. + + This document extends the LDAP Modify Operation [RFC4511] to support + an increment values capability. This feature is intended to be used + with either the LDAP pre-read or post-read control extensions + [RFC4527]. This feature may also be used with the LDAP assertion + control extension [RFC4528] to provide test-and-increment + functionality. + + In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]. + +2. The Modify-Increment Extension + + This document extends the LDAP Modify request to support a increment + values capability. Implementations of this extension SHALL support + an additional ModifyRequest operation enumeration value increment + (3), as described herein. Implementations not supporting this + extension will treat this value as they would an unlisted value, + e.g., as a protocol error. + + The increment (3) operation value specifies that an increment values + modification is requested. All existing values of the modification + attribute are to be incremented by the listed value. The + modification attribute must be appropriate for the request (e.g., it + must have INTEGER or other increment-able values), and the + modification must provide one and only one value. If the attribute + is not appropriate for the request, a constraintViolation or other + appropriate error is to be returned. If multiple values are + provided, a protocolError is to be returned. + + Servers supporting this feature SHOULD publish the object identifier + (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512] + attribute in the root DSE. Clients supporting this feature SHOULD + NOT use the feature unless they know the server supports it. + +3. LDIF Support + + To represent Modify-Increment requests in LDAP Data Interchange + Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is + extended as follows: + + mod-spec =/ "increment:" FILL AttributeDescription SEP + attrval-spec "-" SEP + + + + +Zeilenga Informational [Page 2] + +RFC 4525 LDAP Modify-Increment Extension June 2006 + + + For example, + + # Increment uidNumber + dn: cn=max-assigned uidNumber,dc=example,dc=com + changetype: modify + increment: uidNumber + uidNumber: 1 + - + + This LDIF fragment represents a Modify request to increment the + value(s) of uidNumber by 1. + +4. Security Considerations + + General LDAP security considerations [RFC4510], as well as those + specific to the LDAP Modify [RFC4511], apply to this Modify-Increment + extension. Beyond these considerations, it is noted that + introduction of this extension should reduce application complexity + (by providing one operation for what presently requires multiple + operations) and, hence, it may aid in the production of correct and + secure implementations. + +5. IANA Considerations + + Registration of the following values [RFC4520] have been completed. + +5.1. Object Identifier + + The IANA has assigned an LDAP Object Identifier to identify the LDAP + Modify-Increment feature, as defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4525 + Author/Change Controller: Author + Comments: + Identifies the LDAP Modify-Increment feature + +5.2. LDAP Protocol Mechanism + + The following LDAP Protocol Mechanism has been registered. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.1.14 + Description: Modify-Increment + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + + + +Zeilenga Informational [Page 3] + +RFC 4525 LDAP Modify-Increment Extension June 2006 + + + Usage: Feature + Specification: RFC 4525 + Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> + Comments: none + +5.3. LDAP Protocol Mechanism + + The IANA has assigned an LDAP ModifyRequest Operation Type (3) + [RFC4520] for use in this document. + + Subject: Request for LDAP Protocol Mechanism Registration + ModifyRequest Operation Name: increment + Description: Modify-Increment + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Feature + Specification: RFC 4525 + Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> + Comments: none + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - + Technical Specification", RFC 2849, June 2000. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + + + + + + + +Zeilenga Informational [Page 4] + +RFC 4525 LDAP Modify-Increment Extension June 2006 + + +6.2. Informative References + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Read Entry Controls", RFC 4527, June 2006. + + [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Assertion Control", RFC 4528, June 2006. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Informational [Page 5] + +RFC 4525 LDAP Modify-Increment Extension June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Informational [Page 6] + diff --git a/source4/ldap_server/devdocs/rfc4526.txt b/source4/ldap_server/devdocs/rfc4526.txt new file mode 100644 index 0000000000..9795632b99 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4526.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4526 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP) + Absolute True and False Filters + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document extends the Lightweight Directory Access Protocol + (LDAP) to support absolute True and False filters based upon similar + capabilities found in X.500 directory systems. The document also + extends the String Representation of LDAP Search Filters to support + these filters. + +Table of Contents + + 1. Background ......................................................1 + 2. Absolute True and False Filters .................................2 + 3. Security Considerations .........................................2 + 4. IANA Considerations .............................................3 + 5. References ......................................................3 + 5.1. Normative References .......................................3 + 5.2. Informative References .....................................3 + +1. Background + + The X.500 Directory Access Protocol (DAP) [X.511] supports absolute + True and False assertions. An 'and' filter with zero elements always + evaluates to True. An 'or' filter with zero elements always + evaluates to False. These filters are commonly used when requesting + DSA-specific Entries (DSEs) that do not necessarily have + 'objectClass' attributes; that is, where "(objectClass=*)" may + evaluate to False. + + + + +Zeilenga Standards Track [Page 1] + +RFC 4526 LDAP Absolute True and False Filters June 2006 + + + Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the + number of elements in 'and' and 'or' filter sets, the LDAPv2 string + representation [RFC1960][RFC3494] could not represent empty 'and' and + 'or' filter sets. Due to this, absolute True or False filters were + (unfortunately) eliminated from LDAPv3 [RFC4510]. + + This documents extends LDAPv3 to support absolute True and False + assertions by allowing empty 'and' and 'or' in Search filters + [RFC4511] and extends the filter string representation [RFC4515] to + allow empty filter lists. + + It is noted that certain search operations, such as those used to + retrieve subschema information [RFC4512], require use of particular + filters. This document does not change these requirements. + + This feature is intended to allow a more direct mapping between DAP + and LDAP (as needed to implement DAP-to-LDAP gateways). + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14 + [RFC2119]. + +2. Absolute True and False Filters + + Implementations of this extension SHALL allow 'and' and 'or' choices + with zero filter elements. + + An 'and' filter consisting of an empty set of filters SHALL evaluate + to True. This filter is represented by the string "(&)". + + An 'or' filter consisting of an empty set of filters SHALL evaluate + to False. This filter is represented by the string "(|)". + + Servers supporting this feature SHOULD publish the Object Identifier + 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' + [RFC4512] attribute in the root DSE. + + Clients supporting this feature SHOULD NOT use the feature unless + they know that the server supports it. + +3. Security Considerations + + The (re)introduction of absolute True and False filters is not + believed to raise any new security considerations. + + Implementors of this (or any) LDAPv3 extension should be familiar + with general LDAPv3 security considerations [RFC4510]. + + + +Zeilenga Standards Track [Page 2] + +RFC 4526 LDAP Absolute True and False Filters June 2006 + + +4. IANA Considerations + + Registration of this feature has been completed by the IANA + [RFC4520]. + + Subject: Request for LDAP Protocol Mechanism Registration Object + Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification: + RFC 4526 Author/Change Controller: IESG Comments: none + + This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its + IANA-assigned private enterprise allocation [PRIVATE], for use in + this specification. + +5. References + +5.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): String Representation of Search + Filters", RFC 4515, June 2006. + +5.2. Informative References + + [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight + Directory Access Protocol", RFC 1777, March 1995. + + [RFC1960] Howes, T., "A String Representation of LDAP Search + Filters", RFC 1960, June 1996. + + [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol + version 2 (LDAPv2) to Historic Status", RFC 3494, March + 2003. + + + +Zeilenga Standards Track [Page 3] + +RFC 4526 LDAP Absolute True and False Filters June 2006 + + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [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.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models," X.501(1993) (also ISO/IEC 9594- + 2:1994). + + [X.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993) + (also ISO/IEC 9594-3:1993). + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4526 LDAP Absolute True and False Filters June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 5] + diff --git a/source4/ldap_server/devdocs/rfc4527.txt b/source4/ldap_server/devdocs/rfc4527.txt new file mode 100644 index 0000000000..de6e5d0d54 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4527.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4527 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP) + Read Entry Controls + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies an extension to the Lightweight Directory + Access Protocol (LDAP) to allow the client to read the target entry + of an update operation. The client may request to read the entry + before and/or after the modifications are applied. These reads are + done as an atomic part of the update operation. + +Table of Contents + + 1. Background and Intent of Use ....................................2 + 2. Terminology .....................................................2 + 3. Read Entry Controls .............................................3 + 3.1. The Pre-Read Controls ......................................3 + 3.2. The Post-Read Controls .....................................3 + 4. Interaction with Other Controls .................................4 + 5. Security Considerations .........................................4 + 6. IANA Considerations .............................................5 + 6.1. Object Identifier ..........................................5 + 6.2. LDAP Protocol Mechanisms ...................................5 + 7. Acknowledgement .................................................5 + 8. References ......................................................6 + 8.1. Normative References .......................................6 + 8.2. Informative References .....................................7 + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +1. Background and Intent of Use + + This document specifies an extension to the Lightweight Directory + Access Protocol (LDAP) [RFC4510] to allow the client to read the + target entry of an update operation (e.g., Add, Delete, Modify, + ModifyDN). The extension utilizes controls [RFC4511] attached to + update requests to request and return copies of the target entry. + One request control, called the Pre-Read request control, indicates + that a copy of the entry before application of update is to be + returned. Another control, called the Post-Read request control, + indicates that a copy of the entry after application of the update is + to be returned. Each request control has a corresponding response + control used to return the entry. + + To ensure proper isolation, the controls are processed as an atomic + part of the update operation. + + The functionality offered by these controls is based upon similar + functionality in the X.500 Directory Access Protocol (DAP) [X.511]. + + The Pre-Read controls may be used to obtain replaced or deleted + values of modified attributes or a copy of the entry being deleted. + + The Post-Read controls may be used to obtain values of operational + attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp' + [RFC4512] attributes, updated by the server as part of the update + operation. + +2. Terminology + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded + using the Basic Encoding Rules [X.690] under the restrictions + detailed in Section 5.1 of [RFC4511]. + + DN stands for Distinguished Name. + DSA stands for Directory System Agent (i.e., a directory server). + DSE stands for DSA-specific Entry. + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14 + [RFC2119]. + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +3. Read Entry Controls + +3.1. The Pre-Read Controls + + The Pre-Read request and response controls are identified by the + 1.3.6.1.1.13.1 object identifier. Servers implementing these + controls SHOULD publish 1.3.6.1.1.13.1 as a value of the + 'supportedControl' [RFC4512] in their root DSE. + + The Pre-Read request control is a LDAP Control [RFC4511] whose + controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded + AttributeSelection [RFC4511], as extended by [RFC3673]. The + criticality may be TRUE or FALSE. This control is appropriate for + the modifyRequest, delRequest, and modDNRequest LDAP messages. + + The corresponding response control is a LDAP Control whose + controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET + STRING, contains a BER-encoded SearchResultEntry. The criticality + may be TRUE or FALSE. This control is appropriate for the + modifyResponse, delResponse, and modDNResponse LDAP messages with a + resultCode of success (0). + + When the request control is attached to an appropriate update LDAP + request, the control requests the return of a copy of the target + entry prior to the application of the update. The AttributeSelection + indicates, as discussed in [RFC4511][RFC3673], which attributes are + requested to appear in the copy. The server is to return a + SearchResultEntry containing, subject to access controls and other + constraints, values of the requested attributes. + + The normal processing of the update operation and the processing of + this control MUST be performed as one atomic action isolated from + other update operations. + + If the update operation fails (in either normal or control + processing), no Pre-Read response control is provided. + +3.2. The Post-Read Controls + + The Post-Read request and response controls are identified by the + 1.3.6.1.1.13.2 object identifier. Servers implementing these + controls SHOULD publish 1.3.6.1.1.13.2 as a value of the + 'supportedControl' [RFC4512] in their root DSE. + + The Post-Read request control is a LDAP Control [RFC4511] whose + controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET + STRING, contains a BER-encoded AttributeSelection [RFC4511], as + extended by [RFC3673]. The criticality may be TRUE or FALSE. This + + + +Zeilenga Standards Track [Page 3] + +RFC 4527 LDAP Read Entry Controls June 2006 + + + control is appropriate for the addRequest, modifyRequest, and + modDNRequest LDAP messages. + + The corresponding response control is a LDAP Control whose + controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded + SearchResultEntry. The criticality may be TRUE or FALSE. This + control is appropriate for the addResponse, modifyResponse, and + modDNResponse LDAP messages with a resultCode of success (0). + + When the request control is attached to an appropriate update LDAP + request, the control requests the return of a copy of the target + entry after the application of the update. The AttributeSelection + indicates, as discussed in [RFC4511][RFC3673], which attributes are + requested to appear in the copy. The server is to return a + SearchResultEntry containing, subject to access controls and other + constraints, values of the requested attributes. + + The normal processing of the update operation and the processing of + this control MUST be performed as one atomic action isolated from + other update operations. + + If the update operation fails (in either normal or control + processing), no Post-Read response control is provided. + +4. Interaction with Other Controls + + The Pre-Read and Post-Read controls may be combined with each other + and/or with a variety of other controls. When combined with the + assertion control [RFC4528] and/or the manageDsaIT control [RFC3296], + the semantics of each control included in the combination applies. + The Pre-Read and Post-Read controls may be combined with other + controls as detailed in other technical specifications. + +5. Security Considerations + + The controls defined in this document extend update operations to + support read capabilities. Servers MUST ensure that the client is + authorized for reading of the information provided in this control + and that the client is authorized to perform the requested directory + update. + + Security considerations for the update operations [RFC4511] extended + by this control, as well as general LDAP security considerations + [RFC4510], generally apply to implementation and use of this + extension + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +6. IANA Considerations + + Registration of the following protocol values [RFC4520] have been + completed by the IANA. + +6.1. Object Identifier + + The IANA has registered an LDAP Object Identifier to identify LDAP + protocol elements defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4527 + Author/Change Controller: IESG + Comments: Identifies the LDAP Read Entry Controls + +6.2. LDAP Protocol Mechanisms + + The IANA has registered the LDAP Protocol Mechanism described in this + document. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.1.13.1 + Description: LDAP Pre-read Control + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Control + Specification: RFC 4527 + Author/Change Controller: IESG + Comments: none + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.1.13.2 + Description: LDAP Post-read Control + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Control + Specification: RFC 4527 + Author/Change Controller: IESG + Comments: none + +7. Acknowledgement + + The LDAP Pre-Read and Post-Read controls are modeled after similar + capabilities offered in the DAP [X.511]. + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3296] Zeilenga, K., "Named Subordinate References in + Lightweight Directory Access Protocol (LDAP) + Directories", RFC 3296, July 2002. + + [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol + version 3 (LDAPv3): All Operational Attributes", RFC + 3673, December 2003. + + [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Assertion Control", RFC 4528, June 2006. + + [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). + + [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). + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +8.2. Informative References + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) EntryUUID Operational Attribute", RFC 4530, June + 2006. + + [X.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993) + (also ISO/IEC 9594-3:1993). + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 4527 LDAP Read Entry Controls June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 8] + diff --git a/source4/ldap_server/devdocs/rfc4528.txt b/source4/ldap_server/devdocs/rfc4528.txt new file mode 100644 index 0000000000..5b1fee0c1b --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4528.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4528 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP) + Assertion Control + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines the Lightweight Directory Access Protocol + (LDAP) Assertion Control, which allows a client to specify that a + directory operation should only be processed if an assertion applied + to the target entry of the operation is true. It can be used to + construct "test and set", "test and clear", and other conditional + operations. + +Table of Contents + + 1. Overview ........................................................2 + 2. Terminology .....................................................2 + 3. The Assertion Control ...........................................2 + 4. Security Considerations .........................................3 + 5. IANA Considerations .............................................4 + 5.1. Object Identifier ..........................................4 + 5.2. LDAP Protocol Mechanism ....................................4 + 5.3. LDAP Result Code ...........................................4 + 6. Acknowledgements ................................................5 + 7. References ......................................................5 + 7.1. Normative References .......................................5 + 7.2. Informative References .....................................5 + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4528 LDAP Assertion Control June 2006 + + +1. Overview + + This document defines the Lightweight Directory Access Protocol + (LDAP) [RFC4510] assertion control. The assertion control allows the + client to specify a condition that must be true for the operation to + be processed normally. Otherwise, the operation is not performed. + For instance, the control can be used with the Modify operation + [RFC4511] to perform atomic "test and set" and "test and clear" + operations. + + The control may be attached to any update operation to support + conditional addition, deletion, modification, and renaming of the + target object. The asserted condition is evaluated as an integral + part the operation. + + The control may also be used with the search operation. Here, the + assertion is applied to the base object of the search before + searching for objects that match the search scope and filter. + + The control may also be used with the compare operation. Here, it + extends the compare operation to allow a more complex assertion. + +2. Terminology + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded + using the Basic Encoding Rules [X.690] under the restrictions + detailed in Section 5.1 of [RFC4511]. + + DSA stands for Directory System Agent (or server). + DSE stands for DSA-specific Entry. + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14 + [RFC2119]. + +3. The Assertion Control + + The assertion control is an LDAP Control [RFC4511] whose controlType + is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter + [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE. + There is no corresponding response control. + + The control is appropriate for both LDAP interrogation and update + operations [RFC4511], including Add, Compare, Delete, Modify, + ModifyDN (rename), and Search. It is inappropriate for Abandon, + Bind, Unbind, and StartTLS operations. + + + +Zeilenga Standards Track [Page 2] + +RFC 4528 LDAP Assertion Control June 2006 + + + When the control is attached to an LDAP request, the processing of + the request is conditional on the evaluation of the Filter as applied + against the target of the operation. If the Filter evaluates to + TRUE, then the request is processed normally. If the Filter + evaluates to FALSE or Undefined, then assertionFailed (122) + resultCode is returned, and no further processing is performed. + + For Add, Compare, and ModifyDN operations, the target is indicated by + the entry field in the request. For Modify operations, the target is + indicated by the object field. For Delete operations, the target is + indicated by the DelRequest type. For Compare operations and all + update operations, the evaluation of the assertion MUST be performed + as an integral part of the operation. That is, the evaluation of the + assertion and the normal processing of the operation SHALL be done as + one atomic action. + + For Search operations, the target is indicated by the baseObject + field, and the evaluation is done after "finding" but before + "searching" [RFC4511]. Hence, no entries or continuations references + are returned if the assertion fails. + + Servers implementing this technical specification SHOULD publish the + object identifier 1.3.6.1.1.12 as a value of the 'supportedControl' + attribute [RFC4512] in their root DSE. A server MAY choose to + advertise this extension only when the client is authorized to use + it. + + Other documents may specify how this control applies to other LDAP + operations. In doing so, they must state how the target entry is + determined. + +4. Security Considerations + + The filter may, like other components of the request, contain + sensitive information. When it does, this information should be + appropriately protected. + + As with any general assertion mechanism, the mechanism can be used to + determine directory content. Hence, this mechanism SHOULD be subject + to appropriate access controls. + + Some assertions may be very complex, requiring significant time and + resources to evaluate. Hence, this mechanism SHOULD be subject to + appropriate administrative controls. + + + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4528 LDAP Assertion Control June 2006 + + + Security considerations for the base operations [RFC4511] extended by + this control, as well as general LDAP security considerations + [RFC4510], generally apply to implementation and use of this + extension. + +5. IANA Considerations + +5.1. Object Identifier + + The IANA has assigned an LDAP Object Identifier [RFC4520] to identify + the LDAP Assertion Control defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4528 + Author/Change Controller: IESG + Comments: + Identifies the LDAP Assertion Control + +5.2. LDAP Protocol Mechanism + + Registration of this protocol mechanism [RFC4520] is requested. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.1.12 + Description: Assertion Control + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Control + Specification: RFC 4528 + Author/Change Controller: IESG + Comments: none + +5.3. LDAP Result Code + + The IANA has assigned an LDAP Result Code [RFC4520] called + 'assertionFailed' (122). + + Subject: LDAP Result Code Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Result Code Name: assertionFailed + Specification: RFC 4528 + Author/Change Controller: IESG + Comments: none + + + + + +Zeilenga Standards Track [Page 4] + +RFC 4528 LDAP Assertion Control June 2006 + + +6. Acknowledgements + + The assertion control concept is attributed to Morteza Ansari. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [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). + + [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(2002) (also + ISO/IEC 8825-1:2002). + +7.2. Informative References + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4528 LDAP Assertion Control June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 6] + diff --git a/source4/ldap_server/devdocs/rfc4529.txt b/source4/ldap_server/devdocs/rfc4529.txt new file mode 100644 index 0000000000..47449c040f --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4529.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4529 OpenLDAP Foundation +Category: Informational June 2006 + + + Requesting Attributes by Object Class in the + Lightweight Directory Access Protocol (LDAP) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Lightweight Directory Access Protocol (LDAP) search operation + provides mechanisms for clients to request all user application + attributes, all operational attributes, and/or attributes selected by + their description. This document extends LDAP to support a mechanism + that LDAP clients may use to request the return of all attributes of + an object class. + +Table of Contents + + 1. Background and Intended Use .....................................1 + 2. Terminology .....................................................2 + 3. Return of all Attributes of an Object Class .....................2 + 4. Security Considerations .........................................3 + 5. IANA Considerations .............................................3 + 6. References ......................................................4 + 6.1. Normative References .......................................4 + 6.2. Informative References .....................................4 + +1. Background and Intended Use + + In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the + search operation [RFC4511] supports requesting the return of a set of + attributes. This set is determined by a list of attribute + descriptions. Two special descriptors are defined to request all + user attributes ("*") [RFC4511] and all operational attributes ("+") + [RFC3673]. However, there is no convenient mechanism for requesting + pre-defined sets of attributes such as the set of attributes used to + represent a particular class of object. + + + +Zeilenga Informational [Page 1] + +RFC 4529 Requesting Attributes by Object Class June 2006 + + + This document extends LDAP to allow an object class identifier to be + specified in attributes lists, such as in Search requests, to request + the return of all attributes belonging to an object class. The + COMMERCIAL AT ("@", U+0040) character is used to distinguish an + object class identifier from an attribute descriptions. + + For example, the attribute list of "@country" is equivalent to the + attribute list of 'c', 'searchGuide', 'description', and + 'objectClass'. This object class is described in [RFC4519]. + + This extension is intended primarily to be used where the user is in + direct control of the parameters of the LDAP search operation, for + instance when entering an LDAP URL [RFC4516] into a web browser, such + as <ldap:///dc=example,dc=com?@organization?base>. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14 + [RFC2119]. + + DSA stands for Directory System Agent (or server). + DSE stands for DSA-specific Entry. + +3. Return of All Attributes of an Object Class + + This extension allows object class identifiers to be provided in the + attributes field of the LDAP SearchRequest [RFC4511] or other request + values of the AttributeSelection data type (e.g., attributes field in + pre/post read controls [ReadEntry]) and/or <attributeSelector> + production (e.g., attributes of an LDAP URL [RFC4516]). For each + object class identified in the attributes field, the request is to be + treated as if each attribute allowed by that class (by "MUST" or + "MAY", directly or by "SUP"erior) [RFC4512] were itself listed. + + This extension extends the <attributeSelector> [RFC4511] production + as indicated by the following ABNF [RFC4234]: + + attributeSelector =/ objectclassdescription + objectclassdescription = ATSIGN oid options + ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040) + + where <oid> and <options> productions are as defined in [RFC4512]. + + + + + + + +Zeilenga Informational [Page 2] + +RFC 4529 Requesting Attributes by Object Class June 2006 + + + The <oid> component of an <objectclassdescription> production + identifies the object class by short name (descr) or object + identifier (numericoid). If the value of the <oid> component is + unrecognized or does not refer to an object class, the object class + description is to be treated as an unrecognized attribute + description. + + The <options> production is included in the grammar for extensibility + purposes. An object class description with an unrecognized or + inappropriate option is to be treated as unrecognized. + + Although object class description options and attribute description + options share the same syntax, they are not semantically related. + This document does not define any object description option. + + Servers supporting this feature SHOULD publish the object identifier + (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures' + [RFC4512] attribute in the root DSE. Clients supporting this feature + SHOULD NOT use the feature unless they know that the server supports + it. + +4. Security Considerations + + This extension provides a shorthand for requesting all attributes of + an object class. Because these attributes could have been listed + individually, introduction of this shorthand is not believed to raise + additional security considerations. + + Implementors of this LDAP extension should be familiar with security + considerations applicable to the LDAP search operation [RFC4511], as + well as with general LDAP security considerations [RFC4510]. + +5. IANA Considerations + + Registration of the LDAP Protocol Mechanism [RFC4520] defined in this + document has been completed. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.4.1.4203.1.5.2 + Description: OC AD Lists + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Feature + Specification: RFC 4529 + Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> + Comments: none + + + + + +Zeilenga Informational [Page 3] + +RFC 4529 Requesting Attributes by Object Class June 2006 + + + This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its + IANA-assigned private enterprise allocation [PRIVATE], for use in + this specification. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory + Access Protocol (LDAP): Uniform Resource Locator", RFC + 4516, June 2006. + + [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). + +6.2. Informative References + + [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol + version 3 (LDAPv3): All Operational Attributes", RFC + 3673, December 2003. + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", RFC + 4519, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + + + +Zeilenga Informational [Page 4] + +RFC 4529 Requesting Attributes by Object Class June 2006 + + + [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Read Entry Controls", RFC 4527, June 2006. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Informational [Page 5] + +RFC 4529 Requesting Attributes by Object Class June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Informational [Page 6] + diff --git a/source4/ldap_server/devdocs/rfc4530.txt b/source4/ldap_server/devdocs/rfc4530.txt new file mode 100644 index 0000000000..219a7c2d0c --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4530.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4530 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP) + entryUUID Operational Attribute + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes the LDAP/X.500 'entryUUID' operational + attribute and associated matching rules and syntax. The attribute + holds a server-assigned Universally Unique Identifier (UUID) for the + object. Directory clients may use this attribute to distinguish + objects identified by a distinguished name or to locate an object + after renaming. + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4530 LDAP entryUUID June 2006 + + +Table of Contents + + 1. Background and Intended Use .....................................2 + 2. UUID Schema Elements ............................................3 + 2.1. UUID Syntax ................................................3 + 2.2. 'uuidMatch' Matching Rule ..................................3 + 2.3. 'uuidOrderingMatch' Matching Rule ..........................3 + 2.4. 'entryUUID' Attribute ......................................4 + 3. Security Considerations .........................................4 + 4. IANA Considerations .............................................5 + 4.1. Object Identifier Registration .............................5 + 4.2. UUID Syntax Registration ...................................5 + 4.3. 'uuidMatch' Descriptor Registration ........................5 + 4.4. 'uuidOrderingMatch' Descriptor Registration ................5 + 4.5. 'entryUUID' Descriptor Registration ........................6 + 5. Acknowledgements ................................................6 + 6. References ......................................................6 + 6.1. Normative References .......................................6 + 6.2. Informative References .....................................7 + +1. Background and Intended Use + + In X.500 Directory Services [X.501], such as those accessible using + the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object + is identified by its distinguished name (DN). However, DNs are not + stable identifiers. That is, a new object may be identified by a DN + that previously identified another (now renamed or deleted) object. + + A Universally Unique Identifier (UUID) is "an identifier unique + across both space and time, with respect to the space of all UUIDs" + [RFC4122]. UUIDs are used in a wide range of systems. + + This document describes the 'entryUUID' operational attribute, which + holds the UUID assigned to the object by the server. Clients may use + this attribute to distinguish objects identified by a particular + distinguished name or to locate a particular object after renaming. + + This document defines the UUID syntax, the 'uuidMatch' and + 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute + type. + + Schema definitions are provided using LDAP description formats + [RFC4512]. Definitions provided here are formatted (line wrapped) + for readability. + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4530 LDAP entryUUID June 2006 + + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14 + [RFC2119]. + +2. UUID Schema Elements + +2.1. UUID Syntax + + A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128- + bit) value that identifies an object. The ASN.1 [X.680] type UUID is + defined to represent UUIDs as follows: + + UUID ::= OCTET STRING (SIZE(16)) + -- constrained to an UUID [RFC4122] + + In LDAP, UUID values are encoded using the [ASCII] character string + representation described in [RFC4122]. For example, + "597ae2f6-16a6-1027-98f4-d28b5365dc14". + + The following is an LDAP syntax description suitable for publication + in subschema subentries. + + ( 1.3.6.1.1.16.1 DESC 'UUID' ) + +2.2. 'uuidMatch' Matching Rule + + The 'uuidMatch' matching rule compares an asserted UUID with a stored + UUID for equality. Its semantics are the same as the + 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs + from 'octetStringMatch' in that the assertion value is encoded using + the UUID string representation instead of the normal OCTET STRING + string representation. + + The following is an LDAP matching rule description suitable for + publication in subschema subentries. + + ( 1.3.6.1.1.16.2 NAME 'uuidMatch' + SYNTAX 1.3.6.1.1.16.1 ) + +2.3. 'uuidOrderingMatch' Matching Rule + + The 'uuidOrderingMatch' matching rule compares an asserted UUID with + a stored UUID for ordering. Its semantics are the same as the + 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule + differs from 'octetStringOrderingMatch' in that the assertion value + is encoded using the UUID string representation instead of the normal + OCTET STRING string representation. + + + +Zeilenga Standards Track [Page 3] + +RFC 4530 LDAP entryUUID June 2006 + + + The following is an LDAP matching rule description suitable for + publication in subschema subentries. + + ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' + SYNTAX 1.3.6.1.1.16.1 ) + + Note that not all UUID variants have a defined ordering; and even + where it does, servers are not obligated to assign UUIDs in any + particular order. This matching rule is provided for completeness. + +2.4. 'entryUUID' Attribute + + The 'entryUUID' operational attribute provides the Universally Unique + Identifier (UUID) assigned to the entry. + + The following is an LDAP attribute type description suitable for + publication in subschema subentries. + + ( 1.3.6.1.1.16.4 NAME 'entryUUID' + DESC 'UUID of the entry' + EQUALITY uuidMatch + ORDERING uuidOrderingMatch + SYNTAX 1.3.6.1.1.16.1 + SINGLE-VALUE + NO-USER-MODIFICATION + USAGE directoryOperation ) + + Servers SHALL generate and assign a new UUID to each entry upon its + addition to the directory and provide that UUID as the value of the + 'entryUUID' operational attribute. An entry's UUID is immutable. + + UUID are to be generated in accordance with Section 4 of [RFC4122]. + In particular, servers MUST ensure that each generated UUID is unique + in space and time. + +3. Security Considerations + + An entry's relative distinguish name (RDN) is composed from attribute + values of the entry, which are commonly descriptive of the object the + entry represents. Although deployers are encouraged to use naming + attributes whose values are widely disclosable [RFC4514], entries are + often named using information that cannot be disclosed to all + parties. As UUIDs do not contain any descriptive information of the + object they identify, UUIDs may be used to identify a particular + entry without disclosure of its contents. + + General UUID security considerations [RFC4122] apply. + + + + +Zeilenga Standards Track [Page 4] + +RFC 4530 LDAP entryUUID June 2006 + + + General LDAP security considerations [RFC4510] apply. + +4. IANA Considerations + + The IANA has registered the LDAP values [RFC4520] specified in this + document. + +4.1. Object Identifier Registration + + Subject: Request for LDAP OID Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4530 + Author/Change Controller: IESG + Comments: + Identifies the UUID schema elements + +4.2. UUID Syntax Registration + + Subject: Request for LDAP Syntax Registration + Object Identifier: 1.3.6.1.1.16.1 + Description: UUID + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4530 + Author/Change Controller: IESG + Comments: + Identifies the UUID syntax + +4.3. 'uuidMatch' Descriptor Registration + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): uuidMatch + Object Identifier: 1.3.6.1.1.16.2 + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: Matching Rule + Specification: RFC 4530 + Author/Change Controller: IESG + +4.4. 'uuidOrderingMatch' Descriptor Registration + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): uuidOrderingMatch + Object Identifier: 1.3.6.1.1.16.3 + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: Matching Rule + + + +Zeilenga Standards Track [Page 5] + +RFC 4530 LDAP entryUUID June 2006 + + + Specification: RFC 4530 + Author/Change Controller: IESG + +4.5. 'entryUUID' Descriptor Registration + + The IANA has registered the LDAP 'entryUUID' descriptor. + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): entryUUID + Object Identifier: 1.3.6.1.1.16.4 + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Usage: Attribute Type + Specification: RFC 4530 + Author/Change Controller: IESG + +5. Acknowledgements + + This document is based upon discussions in the LDAP Update and + Duplication Protocols (LDUP) WG. Members of the LDAP Directorate + provided review. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, July + 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol + (LDAP): Syntaxes and Matching Rules", RFC 4517, June + 2006. + + [ASCII] Coded Character Set--7-bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + + + +Zeilenga Standards Track [Page 6] + +RFC 4530 LDAP entryUUID June 2006 + + + [X.501] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory -- Models," X.501(1993) (also ISO/IEC 9594- + 2:1994). + + [X.520] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Selected Attribute Types", X.520(1993) (also + ISO/IEC 9594-6:1994). + + [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). + +6.2. Informative References + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of Distinguished + Names", RFC 4514, June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 7] + +RFC 4530 LDAP entryUUID June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 8] + diff --git a/source4/ldap_server/devdocs/rfc4531.txt b/source4/ldap_server/devdocs/rfc4531.txt new file mode 100644 index 0000000000..b551d441cb --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4531.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4531 OpenLDAP Foundation +Category: Experimental June 2006 + + + Lightweight Directory Access Protocol (LDAP) + Turn Operation + + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This specification describes a Lightweight Directory Access Protocol + (LDAP) extended operation to reverse (or "turn") the roles of client + and server for subsequent protocol exchanges in the session, or to + enable each peer to act as both client and server with respect to the + other. + +Table of Contents + + 1. Background and Intent of Use ....................................2 + 1.1. Terminology ................................................2 + 2. Turn Operation ..................................................2 + 2.1. Turn Request ...............................................3 + 2.2. Turn Response ..............................................3 + 3. Authentication ..................................................3 + 3.1. Use with TLS and Simple Authentication .....................4 + 3.2. Use with TLS and SASL EXTERNAL .............................4 + 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4 + 4. TLS and SASL Security Layers ....................................5 + 5. Security Considerations .........................................6 + 6. IANA Considerations .............................................6 + 6.1. Object Identifier ..........................................6 + 6.2. LDAP Protocol Mechanism ....................................7 + 7. References ......................................................7 + 7.1. Normative References .......................................7 + 7.2. Informative References .....................................8 + + + + +Zeilenga Experimental [Page 1] + +RFC 4531 LDAP Turn Operation June 2006 + + +1. Background and Intent of Use + + The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511] + is a client-server protocol that typically operates over reliable + octet-stream transports, such as the Transport Control Protocol + (TCP). Generally, the client initiates the stream by connecting to + the server's listener at some well-known address. + + There are cases where it is desirable for the server to initiate the + stream. Although it certainly is possible to write a technical + specification detailing how to implement server-initiated LDAP + sessions, this would require the design of new authentication and + other security mechanisms to support server-initiated LDAP sessions. + + Instead, this document introduces an operation, the Turn operation, + which may be used to reverse the client-server roles of the protocol + peers. This allows the initiating protocol peer to become the server + (after the reversal). + + As an additional feature, the Turn operation may be used to allow + both peers to act in both roles. This is useful where both peers are + directory servers that desire to request, as LDAP clients, that + operations be performed by the other. This may be useful in + replicated and/or distributed environments. + + This operation is intended to be used between protocol peers that + have established a mutual agreement, by means outside of the + protocol, that requires reversal of client-server roles, or allows + both peers to act both as client and server. + +1.1. Terminology + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded + using the Basic Encoding Rules [X.690] under the restrictions + detailed in Section 5.1 of [RFC4511]. + +2. Turn Operation + + The Turn operation is defined as an LDAP-Extended Operation + [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The + function of the Turn Operation is to request that the client-server + roles be reversed, or, optionally, to request that both protocol + peers be able to act both as client and server in respect to the + other. + + + + + + +Zeilenga Experimental [Page 2] + +RFC 4531 LDAP Turn Operation June 2006 + + +2.1. Turn Request + + The Turn request is an ExtendedRequest where the requestName field + contains the 1.3.6.1.1.19 OID and the requestValue field is a BER- + encoded turnValue: + + turnValue ::= SEQUENCE { + mutual BOOLEAN DEFAULT FALSE, + identifier LDAPString + } + + A TRUE mutual field value indicates a request to allow both peers to + act both as client and server. A FALSE mutual field value indicates + a request to reserve the client and server roles. + + The value of the identifier field is a locally defined policy + identifier (typically associated with a mutual agreement for which + this turn is be executed as part of). + +2.2. Turn Response + + A Turn response is an ExtendedResponse where the responseName and + responseValue fields are absent. A resultCode of success is returned + if and only if the responder is willing and able to turn the session + as requested. Otherwise, a different resultCode is returned. + +3. Authentication + + This extension's authentication model assumes separate authentication + of the peers in each of their roles. A separate Bind exchange is + expected between the peers in their new roles to establish identities + in these roles. + + Upon completion of the Turn, the responding peer in its new client + role has an anonymous association at the initiating peer in its new + server role. If the turn was mutual, the authentication association + of the initiating peer in its pre-existing client role is left intact + at the responding peer in its pre-existing server role. If the turn + was not mutual, this association is void. + + The responding peer may establish its identity in its client role by + requesting and successfully completing a Bind operation. + + The remainder of this section discusses some authentication + scenarios. In the protocol exchange illustrations, A refers to the + initiating peer (the original client) and B refers to the responding + peer (the original server). + + + + +Zeilenga Experimental [Page 3] + +RFC 4531 LDAP Turn Operation June 2006 + + +3.1. Use with TLS and Simple Authentication + + A->B: StartTLS Request + B->A: StartTLS(success) Response + A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request + B->A: Bind(success) Response + A->B: Turn(TRUE,"XXYYZ") Request + B->A: Turn(success) Response + B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request + A->B: Bind(success) Response + + In this scenario, TLS (Transport Layer Security) [RFC4346] is started + and the initiating peer (the original client) establishes its + identity with the responding peer prior to the Turn using the + DN/password mechanism of the Simple method of the Bind operation. + After the turn, the responding peer, in its new client role, + establishes its identity with the initiating peer in its new server + role. + +3.2. Use with TLS and SASL EXTERNAL + + A->B: StartTLS Request + B->A: StartTLS(success) Response + A->B: Bind(SASL(EXTERNAL)) Request + B->A: Bind(success) Response + A->B: Turn(TRUE,"XXYYZ") Request + B->A: Turn(success) Response + B->A: Bind(SASL(EXTERNAL)) Request + A->B: Bind(success) Response + + In this scenario, TLS is started (with each peer providing a valid + certificate), and the initiating peer (the original client) + establishes its identity through the use of the EXTERNAL mechanism of + the SASL (Simple Authentication and Security Layer) [RFC4422] method + of the Bind operation prior to the Turn. After the turn, the + responding peer, in its new client role, establishes its identity + with the initiating peer in its new server role. + +3.3. Use of Mutual Authentication and SASL EXTERNAL + + A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual + authentication. The initiating peer, in its new server role, may use + the identity of the responding peer, established by a prior + authentication exchange, as its source for "external" identity in + subsequent EXTERNAL exchange. + + A->B: Bind(SASL(GSSAPI)) Request + <intermediate messages> + + + +Zeilenga Experimental [Page 4] + +RFC 4531 LDAP Turn Operation June 2006 + + + B->A: Bind(success) Response + A->B: Turn(TRUE,"XXYYZ") Request + B->A: Turn(success) Response + B->A: Bind(SASL(EXTERNAL)) Request + A->B: Bind(success) Response + + In this scenario, a GSSAPI mutual-authentication exchange is + completed between the initiating peer (the original client) and the + responding server (the original server) prior to the turn. After the + turn, the responding peer, in its new client role, requests that the + initiating peer utilize an "external" identity to establish its LDAP + authorization identity. + +4. TLS and SASL Security Layers + + As described in [RFC4511], LDAP supports both Transport Layer + Security (TLS) [RFC4346] and Simple Authentication and Security Layer + (SASL) [RFC4422] security frameworks. The following table + illustrates the relationship between the LDAP message layer, SASL + layer, TLS layer, and transport connection within an LDAP session. + + +----------------------+ + | LDAP message layer | + +----------------------+ > LDAP PDUs + +----------------------+ < data + | SASL layer | + +----------------------+ > SASL-protected data + +----------------------+ < data + | TLS layer | + Application +----------------------+ > TLS-protected data + ------------+----------------------+ < data + Transport | transport connection | + +----------------------+ + + This extension does not alter this relationship, nor does it remove + the general restriction against multiple TLS layers, nor does it + remove the general restriction against multiple SASL layers. + + As specified in [RFC4511], the StartTLS operation is used to initiate + negotiation of a TLS layer. If a TLS is already installed, the + StartTLS operation must fail. Upon establishment of the TLS layer, + regardless of which peer issued the request to start TLS, the peer + that initiated the LDAP session (the original client) performs the + "server identity check", as described in Section 3.1.5 of [RFC4513], + treating itself as the "client" and its peer as the "server". + + As specified in [RFC4422], a newly negotiated SASL security layer + replaces the installed SASL security layer. Though the client/server + + + +Zeilenga Experimental [Page 5] + +RFC 4531 LDAP Turn Operation June 2006 + + + roles in LDAP, and hence SASL, may be reversed in subsequent + exchanges, only one SASL security layer may be installed at any + instance. + +5. Security Considerations + + Implementors should be aware that the reversing of client/server + roles and/or allowing both peers to act as client and server likely + introduces security considerations not foreseen by the authors of + this document. In particular, the security implications of the + design choices made in the authentication and data security models + for this extension (discussed in Sections 3 and 4, respectively) are + not fully studied. It is hoped that experimentation with this + extension will lead to better understanding of the security + implications of these models and other aspects of this extension, and + that appropriate considerations will be documented in a future + document. The following security considerations are apparent at this + time. + + Implementors should take special care to process LDAP, SASL, TLS, and + other events in the appropriate roles for the peers. Note that while + the Turn reverses the client/server roles with LDAP, and in SASL + authentication exchanges, it does not reverse the roles within the + TLS layer or the transport connection. + + The responding server (the original server) should restrict use of + this operation to authorized clients. Client knowledge of a valid + identifier should not be the sole factor in determining authorization + to turn. + + Where the peers except to establish TLS, TLS should be started prior + to the Turn and any request to authenticate via the Bind operation. + + LDAP security considerations [RFC4511][RFC4513] generally apply to + this extension. + +6. IANA Considerations + + The following values [RFC4520] have been registered by the IANA. + +6.1. Object Identifier + + The IANA has assigned an LDAP Object Identifier to identify the LDAP + Turn Operation, as defined in this document. + + + + + + + +Zeilenga Experimental [Page 6] + +RFC 4531 LDAP Turn Operation June 2006 + + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Specification: RFC 4531 + Author/Change Controller: Author + Comments: + Identifies the LDAP Turn Operation + +6.2. LDAP Protocol Mechanism + + The IANA has registered the LDAP Protocol Mechanism described in this + document. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.1.19 + Description: LDAP Turn Operation + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Extended Operation + Specification: RFC 4531 + Author/Change Controller: Author + Comments: none + +7. References + +7.1. Normative References + + [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.1", RFC 4346, April + 2006. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + June 2006. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): Technical Specification Road Map", RFC + 4510, June 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access + Protocol (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + + + + + +Zeilenga Experimental [Page 7] + +RFC 4531 LDAP Turn Operation June 2006 + + + [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). + + [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(2002) (also + ISO/IEC 8825-1:2002). + +7.2. Informative References + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority + (IANA) Considerations for the Lightweight Directory + Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL + Mechanism", Work in Progress, May 2006. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Experimental [Page 8] + +RFC 4531 LDAP Turn Operation June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Experimental [Page 9] + diff --git a/source4/ldap_server/devdocs/rfc4532.txt b/source4/ldap_server/devdocs/rfc4532.txt new file mode 100644 index 0000000000..277b3b7442 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4532.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4532 OpenLDAP Foundation +Category: Standards Track June 2006 + + + Lightweight Directory Access Protocol (LDAP) + "Who am I?" Operation + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This specification provides a mechanism for Lightweight Directory + Access Protocol (LDAP) clients to obtain the authorization identity + the server has associated with the user or application entity. This + mechanism is specified as an LDAP extended operation called the LDAP + "Who am I?" operation. + +1. Background and Intent of Use + + This specification describes a Lightweight Directory Access Protocol + (LDAP) [RFC4510] operation that clients can use to obtain the primary + authorization identity, in its primary form, that the server has + associated with the user or application entity. The operation is + called the "Who am I?" operation. + + This specification is intended to replace the existing Authorization + Identity Controls [RFC3829] mechanism, which uses Bind request and + response controls to request and return the authorization identity. + Bind controls are not protected by security layers established by the + Bind operation that includes them. While it is possible to establish + security layers using StartTLS [RFC4511][RFC4513] prior to the Bind + operation, it is often desirable to use security layers established + by the Bind operation. An extended operation sent after a Bind + operation is protected by the security layers established by the Bind + operation. + + + + + +Zeilenga Standards Track [Page 1] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + + There are other cases where it is desirable to request the + authorization identity that the server associated with the client + separately from the Bind operation. For example, the "Who am I?" + operation can be augmented with a Proxied Authorization Control + [RFC4370] to determine the authorization identity that the server + associates with the identity asserted in the Proxied Authorization + Control. The "Who am I?" operation can also be used prior to the + Bind operation. + + Servers often associate multiple authorization identities with the + client, and each authorization identity may be represented by + multiple authzId [RFC4513] strings. This operation requests and + returns the authzId that the server considers primary. In the + specification, the term "the authorization identity" and "the + authzId" are generally to be read as "the primary authorization + identity" and the "the primary authzId", respectively. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. The "Who am I?" Operation + + The "Who am I?" operation is defined as an LDAP Extended Operation + [RFC4511] identified by the whoamiOID Object Identifier (OID). This + section details the syntax of the operation's whoami request and + response messages. + + whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3" + +2.1. The whoami Request + + The whoami request is an ExtendedRequest with a requestName field + containing the whoamiOID OID and an absent requestValue field. For + example, a whoami request could be encoded as the sequence of octets + (in hex): + + 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 + 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 + + + + + + + + + + +Zeilenga Standards Track [Page 2] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + +2.2. The whoami Response + + The whoami response is an ExtendedResponse where the responseName + field is absent and the response field, if present, is empty or an + authzId [RFC4513]. For example, a whoami response returning the + authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request) + would be encoded as the sequence of octets (in hex): + + 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 + 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e + 4e 45 54 + +3. Operational Semantics + + The "Who am I?" operation provides a mechanism, a whoami Request, for + the client to request that the server return the authorization + identity it currently associates with the client. It also provides a + mechanism, a whoami Response, for the server to respond to that + request. + + Servers indicate their support for this extended operation by + providing a whoamiOID object identifier as a value of the + 'supportedExtension' attribute type in their root DSE. The server + SHOULD advertise this extension only when the client is willing and + able to perform this operation. + + If the server is willing and able to provide the authorization + identity it associates with the client, the server SHALL return a + whoami Response with a success resultCode. If the server is treating + the client as an anonymous entity, the response field is present but + empty. Otherwise, the server provides the authzId [RFC4513] + representing the authorization identity it currently associates with + the client in the response field. + + If the server is unwilling or unable to provide the authorization + identity it associates with the client, the server SHALL return a + whoami Response with an appropriate non-success resultCode (such as + operationsError, protocolError, confidentialityRequired, + insufficientAccessRights, busy, unavailable, unwillingToPerform, or + other) and an absent response field. + + As described in [RFC4511] and [RFC4513], an LDAP session has an + "anonymous" association until the client has been successfully + authenticated using the Bind operation. Clients MUST NOT invoke the + "Who am I?" operation while any Bind operation is in progress, + including between two Bind requests made as part of a multi-stage + + + + + +Zeilenga Standards Track [Page 3] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + + Bind operation. Where a whoami Request is received in violation of + this absolute prohibition, the server should return a whoami Response + with an operationsError resultCode. + +4. Extending the "Who am I?" Operation with Controls + + Future specifications may extend the "Who am I?" operation using the + control mechanism [RFC4511]. When extended by controls, the "Who am + I?" operation requests and returns the authorization identity the + server associates with the client in a particular context indicated + by the controls. + +4.1. Proxied Authorization Control + + The Proxied Authorization Control [RFC4370] is used by clients to + request that the operation it is attached to operate under the + authorization of an assumed identity. The client provides the + identity to assume in the Proxied Authorization request control. If + the client is authorized to assume the requested identity, the server + executes the operation as if the requested identity had issued the + operation. + + As servers often map the asserted authzId to another identity + [RFC4513], it is desirable to request that the server provide the + authzId it associates with the assumed identity. + + When a Proxied Authorization Control is be attached to the "Who am + I?" operation, the operation requests the return of the authzId the + server associates with the identity asserted in the Proxied + Authorization Control. The authorizationDenied (123) result code is + used to indicate that the server does not allow the client to assume + the asserted identity. + +5. Security Considerations + + Identities associated with users may be sensitive information. When + they are, security layers [RFC4511][RFC4513] should be established to + protect this information. This mechanism is specifically designed to + allow security layers established by a Bind operation to protect the + integrity and/or confidentiality of the authorization identity. + + Servers may place access control or other restrictions upon the use + of this operation. As stated in Section 3, the server SHOULD + advertise this extension when it is willing and able to perform the + operation. + + As with any other extended operations, general LDAP security + considerations [RFC4510] apply. + + + +Zeilenga Standards Track [Page 4] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + +6. IANA Considerations + + The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am + I?" extended operation. This OID was assigned [ASSIGN] by the + OpenLDAP Foundation, under its IANA-assigned private enterprise + allocation [PRIVATE], for use in this specification. + + Registration of this protocol mechanism [RFC4520] has been completed + by the IANA. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.4.1.4203.1.11.3 + Description: Who am I? + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Extended Operation + Specification: RFC 4532 + Author/Change Controller: IESG + Comments: none + +7. Acknowledgement + + This document borrows from prior work in this area, including + "Authentication Response Control" [RFC3829] by Rob Weltman, Mark + Smith, and Mark Wahl. + + The LDAP "Who am I?" operation takes it's name from the UNIX + whoami(1) command. The whoami(1) command displays the effective user + ID. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP) + Proxied Authorization Control", RFC 4370, February 2006. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + + + + +Zeilenga Standards Track [Page 5] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + + [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security Mechanisms", + RFC 4513, June 2006. + +8.2. Informative References + + [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory + Access Protocol (LDAP) Authorization Identity Request and + Response Controls", RFC 3829, July 2004. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + +Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] + +RFC 4532 LDAP "Who am I?" Operation June 2006 + + +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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga Standards Track [Page 7] + diff --git a/source4/ldap_server/devdocs/rfc4533.txt b/source4/ldap_server/devdocs/rfc4533.txt new file mode 100644 index 0000000000..5f507ceae8 --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4533.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 4533 OpenLDAP Foundation +Category: Experimental J.H. Choi + IBM Corporation + June 2006 + + + The Lightweight Directory Access Protocol (LDAP) + Content Synchronization Operation + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + The IESG notes that this work was originally discussed in the LDUP + working group. The group came to consensus on a different approach, + documented in RFC 3928; that document is on the standards track and + should be reviewed by those considering implementation of this + proposal. + +Abstract + + This specification describes the Lightweight Directory Access + Protocol (LDAP) Content Synchronization Operation. The operation + allows a client to maintain a copy of a fragment of the Directory + Information Tree (DIT). It supports both polling for changes and + listening for changes. The operation is defined as an extension of + the LDAP Search Operation. + + + + + + + + + + + + + + +Zeilenga & Choi Experimental [Page 1] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Background .................................................3 + 1.2. Intended Usage .............................................4 + 1.3. Overview ...................................................5 + 1.4. Conventions ................................................8 + 2. Elements of the Sync Operation ..................................8 + 2.1. Common ASN.1 Elements ......................................9 + 2.2. Sync Request Control .......................................9 + 2.3. Sync State Control ........................................10 + 2.4. Sync Done Control .........................................10 + 2.5. Sync Info Message .........................................11 + 2.6. Sync Result Codes .........................................11 + 3. Content Synchronization ........................................11 + 3.1. Synchronization Session ...................................12 + 3.2. Content Determination .....................................12 + 3.3. refreshOnly Mode ..........................................13 + 3.4. refreshAndPersist Mode ....................................16 + 3.5. Search Request Parameters .................................17 + 3.6. objectName ................................................18 + 3.7. Canceling the Sync Operation ..............................19 + 3.8. Refresh Required ..........................................19 + 3.9. Chattiness Considerations .................................20 + 3.10. Operation Multiplexing ...................................21 + 4. Meta Information Considerations ................................22 + 4.1. Entry DN ..................................................22 + 4.2. Operational Attributes ....................................22 + 4.3. Collective Attributes .....................................23 + 4.4. Access and Other Administrative Controls ..................23 + 5. Interaction with Other Controls ................................23 + 5.1. ManageDsaIT Control .......................................24 + 5.2. Subentries Control ........................................24 + 6. Shadowing Considerations .......................................24 + 7. Security Considerations ........................................25 + 8. IANA Considerations ............................................26 + 8.1. Object Identifier .........................................26 + 8.2. LDAP Protocol Mechanism ...................................26 + 8.3. LDAP Result Codes .........................................26 + 9. Acknowledgements ...............................................26 + 10. Normative References ..........................................27 + 11. Informative References ........................................28 + Appendix A. CSN-based Implementation Considerations ..............29 + + + + + + + + +Zeilenga & Choi Experimental [Page 2] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +1. Introduction + + The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a + mechanism, the search operation [RFC4511], that allows a client to + request directory content matching a complex set of assertions and to + request that the server return this content, subject to access + control and other restrictions, to the client. However, LDAP does + not provide (despite the introduction of numerous extensions in this + area) an effective and efficient mechanism for maintaining + synchronized copies of directory content. This document introduces a + new mechanism specifically designed to meet the content + synchronization requirements of sophisticated directory applications. + + This document defines the LDAP Content Synchronization Operation, or + Sync Operation for short, which allows a client to maintain a + synchronized copy of a fragment of a Directory Information Tree + (DIT). The Sync Operation is defined as a set of controls and other + protocol elements that extend the Search Operation. + +1.1. Background + + Over the years, a number of content synchronization approaches have + been suggested for use in LDAP directory services. These approaches + are inadequate for one or more of the following reasons: + + - failure to ensure a reasonable level of convergence; + + - failure to detect that convergence cannot be achieved (without + reload); + + - require pre-arranged synchronization agreements; + + - require the server to maintain histories of past changes to DIT + content and/or meta information; + + - require the server to maintain synchronization state on a per- + client basis; and/or + + - are overly chatty. + + The Sync Operation provides eventual convergence of synchronized + content when possible and, when not, notification that a full reload + is required. + + The Sync Operation does not require pre-arranged synchronization + agreements. + + + + + +Zeilenga & Choi Experimental [Page 3] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + The Sync Operation does not require that servers maintain or use any + history of past changes to the DIT or to meta information. However, + servers may maintain and use histories (e.g., change logs, + tombstones, DIT snapshots) to reduce the number of messages generated + and to reduce their size. As it is not always feasible to maintain + and use histories, the operation may be implemented using purely + (current) state-based approaches. The Sync Operation allows use of + either the state-based approach or the history-based approach on an + operation-by-operation basis to balance the size of history and the + amount of traffic. The Sync Operation also allows the combined use + of the state-based and the history-based approaches. + + The Sync Operation does not require that servers maintain + synchronization state on a per-client basis. However, servers may + maintain and use per-client state information to reduce the number of + messages generated and the size of such messages. + + A synchronization mechanism can be considered overly chatty when + synchronization traffic is not reasonably bounded. The Sync + Operation traffic is bounded by the size of updated (or new) entries + and the number of unchanged entries in the content. The operation is + designed to avoid full content exchanges, even when the history + information available to the server is insufficient to determine the + client's state. The operation is also designed to avoid transmission + of out-of-content history information, as its size is not bounded by + the content and it is not always feasible to transmit such history + information due to security reasons. + + This document includes a number of non-normative appendices providing + additional information to server implementors. + +1.2. Intended Usage + + The Sync Operation is intended to be used in applications requiring + eventually-convergent content synchronization. Upon completion of + each synchronization stage of the operation, all information to + construct a synchronized client copy of the content has been provided + to the client or the client has been notified that a complete content + reload is necessary. Except for transient inconsistencies due to + concurrent operation (or other) processing at the server, the client + copy is an accurate reflection of the content held by the server. + Transient inconsistencies will be resolved by subsequent + synchronization operations. + + + + + + + + +Zeilenga & Choi Experimental [Page 4] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Possible uses include the following: + + - White page service applications may use the Sync Operation to + maintain a current copy of a DIT fragment, for example, a mail + user agent that uses the sync operation to maintain a local + copy of an enterprise address book. + + - Meta-information engines may use the Sync Operation to maintain + a copy of a DIT fragment. + + - Caching proxy services may use the Sync Operation to maintain a + coherent content cache. + + - Lightweight master-slave replication between heterogeneous + directory servers. For example, the Sync Operation can be used + by a slave server to maintain a shadow copy of a DIT fragment. + (Note: The International Telephone Union (ITU) has defined the + X.500 Directory [X.500] Information Shadowing Protocol (DISP) + [X.525], which may be used for master-slave replication between + directory servers. Other experimental LDAP replication + protocols also exist.) + + This protocol is not intended to be used in applications requiring + transactional data consistency. + + As this protocol transfers all visible values of entries belonging to + the content upon change instead of change deltas, this protocol is + not appropriate for bandwidth-challenged applications or deployments. + +1.3. Overview + + This section provides an overview of basic ways the Sync Operation + can be used to maintain a synchronized client copy of a DIT fragment. + + - Polling for changes: refreshOnly mode + + - Listening for changes: refreshAndPersist mode + +1.3.1. Polling for Changes (refreshOnly) + + To obtain its initial client copy, the client issues a Sync request: + a search request with the Sync Request Control with mode set to + refreshOnly. The server, much like it would with a normal search + operation, returns (subject to access controls and other + restrictions) the content matching the search criteria (baseObject, + scope, filter, attributes). Additionally, with each entry returned, + the server provides a Sync State Control indicating state add. This + control contains the Universally Unique Identifier (UUID) [UUID] of + + + +Zeilenga & Choi Experimental [Page 5] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + the entry [RFC4530]. Unlike the Distinguished Name (DN), which may + change over time, an entry's UUID is stable. The initial content is + followed by a SearchResultDone with a Sync Done Control. The Sync + Done Control provides a syncCookie. The syncCookie represents + session state. + + To poll for updates to the client copy, the client reissues the Sync + Operation with the syncCookie previously returned. The server, much + as it would with a normal search operation, determines which content + would be returned as if the operation were a normal search operation. + However, using the syncCookie as an indicator of what content the + client was sent previously, the server sends copies of entries that + have changed with a Sync State Control indicating state add. For + each changed entry, all (modified or unmodified) attributes belonging + to the content are sent. + + The server may perform either or both of the two distinct + synchronization phases that are distinguished by how to synchronize + entries deleted from the content: the present and the delete phases. + When the server uses a single phase for the refresh stage, each phase + is marked as ended by a SearchResultDone with a Sync Done Control. A + present phase is identified by a FALSE refreshDeletes value in the + Sync Done Control. A delete phase is identified by a TRUE + refreshDeletes value. The present phase may be followed by a delete + phase. The two phases are delimited by a refreshPresent Sync Info + Message having a FALSE refreshDone value. In the case that both the + phases are used, the present phase is used to bring the client copy + up to the state at which the subsequent delete phase can begin. + + In the present phase, the server sends an empty entry (i.e., no + attributes) with a Sync State Control indicating state present for + each unchanged entry. + + The delete phase may be used when the server can reliably determine + which entries in the prior client copy are no longer present in the + content and the number of such entries is less than or equal to the + number of unchanged entries. In the delete mode, the server sends an + empty entry with a Sync State Control indicating state delete for + each entry that is no longer in the content, instead of returning an + empty entry with state present for each present entry. + + The server may send syncIdSet Sync Info Messages containing the set + of UUIDs of either unchanged present entries or deleted entries, + instead of sending multiple individual messages. If refreshDeletes + of syncIdSet is set to FALSE, the UUIDs of unchanged present entries + are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is + set to TRUE, the UUIDs of the entries no longer present in the + content are contained in the syncUUIDs set. An optional cookie can + + + +Zeilenga & Choi Experimental [Page 6] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + be included in the syncIdSet to represent the state of the content + after synchronizing the presence or the absence of the entries + contained in the syncUUIDs set. + + The synchronized copy of the DIT fragment is constructed by the + client. + + If refreshDeletes of syncDoneValue is FALSE, the new copy includes + all changed entries returned by the reissued Sync Operation, as well + as all unchanged entries identified as being present by the reissued + Sync Operation, but whose content is provided by the previous Sync + Operation. The unchanged entries not identified as being present are + deleted from the client content. They had been either deleted, + moved, or otherwise scoped-out from the content. + + If refreshDeletes of syncDoneValue is TRUE, the new copy includes all + changed entries returned by the reissued Sync Operation, as well as + all other entries of the previous copy except for those that are + identified as having been deleted from the content. + + The client can, at some later time, re-poll for changes to this + synchronized client copy. + +1.3.2. Listening for Changes (refreshAndPersist) + + Polling for changes can be expensive in terms of server, client, and + network resources. The refreshAndPersist mode allows for active + updates of changed entries in the content. + + By selecting the refreshAndPersist mode, the client requests that the + server send updates of entries that are changed after the initial + refresh content is determined. Instead of sending a SearchResultDone + Message as in polling, the server sends a Sync Info Message to the + client indicating that the refresh stage is complete and then enters + the persist stage. After receipt of this Sync Info Message, the + client will construct a synchronized copy as described in Section + 1.3.1. + + The server may then send change notifications as the result of the + original Sync search request, which now remains persistent in the + server. For entries to be added to the returned content, the server + sends a SearchResultEntry (with attributes) with a Sync State Control + indicating state add. For entries to be deleted from the content, + the server sends a SearchResultEntry containing no attributes and a + Sync State Control indicating state delete. For entries to be + modified in the return content, the server sends a SearchResultEntry + (with attributes) with a Sync State Control indicating state modify. + + + + +Zeilenga & Choi Experimental [Page 7] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Upon modification of an entry, all (modified or unmodified) + attributes belonging to the content are sent. + + Note that renaming an entry of the DIT may cause an add state change + where the entry is renamed into the content, a delete state change + where the entry is renamed out of the content, and a modify state + change where the entry remains in the content. Also note that a + modification of an entry of the DIT may cause an add, delete, or + modify state change to the content. + + Upon receipt of a change notification, the client updates its copy of + the content. + + If the server desires to update the syncCookie during the persist + stage, it may include the syncCookie in any Sync State Control or + Sync Info Message returned. + + The operation persists until canceled [RFC3909] by the client or + terminated by the server. A Sync Done Control shall be attached to + SearchResultDone Message to provide a new syncCookie. + +1.4. 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]. + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded + using the Basic Encoding Rules [X.690] under the restrictions + detailed in Section 5.1 of [RFC4511]. + +2. Elements of the Sync Operation + + The Sync Operation is defined as an extension to the LDAP Search + Operation [RFC4511] where the directory user agent (DUA or client) + submits a SearchRequest Message with a Sync Request Control and the + directory system agent (DSA or server) responds with zero or more + SearchResultEntry Messages, each with a Sync State Control; zero or + more SearchResultReference Messages, each with a Sync State Control; + zero or more Sync Info Intermediate Response Messages; and a + SearchResultDone Message with a Sync Done Control. + + To allow clients to discover support for this operation, servers + implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1 + as a value of the 'supportedControl' attribute [RFC4512] of the root + DSA-specific entry (DSE). A server MAY choose to advertise this + extension only when the client is authorized to use it. + + + +Zeilenga & Choi Experimental [Page 8] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +2.1. Common ASN.1 Elements + +2.1.1. syncUUID + + The syncUUID data type is an OCTET STRING holding a 128-bit + (16-octet) Universally Unique Identifier (UUID) [UUID]. + + syncUUID ::= OCTET STRING (SIZE(16)) + -- constrained to UUID + +2.1.2. syncCookie + + The syncCookie is a notational convenience to indicate that, while + the syncCookie type is encoded as an OCTET STRING, its value is an + opaque value containing information about the synchronization session + and its state. Generally, the session information would include a + hash of the operation parameters that the server requires not be + changed and the synchronization state information would include a + commit (log) sequence number, a change sequence number, or a time + stamp. For convenience of description, the term "no cookie" refers + either to a null cookie or to a cookie with pre-initialized + synchronization state. + + syncCookie ::= OCTET STRING + +2.2. Sync Request Control + + The Sync Request Control is an LDAP Control [RFC4511] where the + controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the + controlValue, an OCTET STRING, contains a BER-encoded + syncRequestValue. The criticality field is either TRUE or FALSE. + + syncRequestValue ::= SEQUENCE { + mode ENUMERATED { + -- 0 unused + refreshOnly (1), + -- 2 reserved + refreshAndPersist (3) + }, + cookie syncCookie OPTIONAL, + reloadHint BOOLEAN DEFAULT FALSE + } + + The Sync Request Control is only applicable to the SearchRequest + Message. + + + + + + +Zeilenga & Choi Experimental [Page 9] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +2.3. Sync State Control + + The Sync State Control is an LDAP Control [RFC4511] where the + controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the + controlValue, an OCTET STRING, contains a BER-encoded syncStateValue. + The criticality is FALSE. + + syncStateValue ::= SEQUENCE { + state ENUMERATED { + present (0), + add (1), + modify (2), + delete (3) + }, + entryUUID syncUUID, + cookie syncCookie OPTIONAL + } + + The Sync State Control is only applicable to SearchResultEntry and + SearchResultReference Messages. + +2.4. Sync Done Control + + The Sync Done Control is an LDAP Control [RFC4511] where the + controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the + controlValue contains a BER-encoded syncDoneValue. The criticality + is FALSE (and hence absent). + + syncDoneValue ::= SEQUENCE { + cookie syncCookie OPTIONAL, + refreshDeletes BOOLEAN DEFAULT FALSE + } + + The Sync Done Control is only applicable to the SearchResultDone + Message. + + + + + + + + + + + + + + + + +Zeilenga & Choi Experimental [Page 10] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +2.5. Sync Info Message + + The Sync Info Message is an LDAP Intermediate Response Message + [RFC4511] where responseName is the object identifier + 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded + syncInfoValue. The criticality is FALSE (and hence absent). + + syncInfoValue ::= CHOICE { + newcookie [0] syncCookie, + refreshDelete [1] SEQUENCE { + cookie syncCookie OPTIONAL, + refreshDone BOOLEAN DEFAULT TRUE + }, + refreshPresent [2] SEQUENCE { + cookie syncCookie OPTIONAL, + refreshDone BOOLEAN DEFAULT TRUE + }, + syncIdSet [3] SEQUENCE { + cookie syncCookie OPTIONAL, + refreshDeletes BOOLEAN DEFAULT FALSE, + syncUUIDs SET OF syncUUID + } + } + +2.6. Sync Result Codes + + The following LDAP resultCode [RFC4511] is defined: + + e-syncRefreshRequired (4096) + +3. Content Synchronization + + The Sync Operation is invoked when the client sends a SearchRequest + Message with a Sync Request Control. + + The absence of a cookie or an initialized synchronization state in a + cookie indicates a request for initial content, while the presence of + a cookie representing a state of a client copy indicates a request + for a content update. Synchronization Sessions are discussed in + Section 3.1. Content Determination is discussed in Section 3.2. + + The mode is either refreshOnly or refreshAndPersist. The refreshOnly + and refreshAndPersist modes are discussed in Sections 3.3 and 3.4, + respectively. The refreshOnly mode consists only of a refresh stage, + while the refreshAndPersist mode consists of a refresh stage and a + subsequent persist stage. + + + + + +Zeilenga & Choi Experimental [Page 11] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +3.1. Synchronization Session + + A sequence of Sync Operations where the last cookie returned by the + server for one operation is provided by the client in the next + operation is said to belong to the same Synchronization Session. + + The client MUST specify the same content-controlling parameters (see + Section 3.5) in each Search Request of the session. The client + SHOULD also issue each Sync request of a session under the same + authentication and authorization associations with equivalent + integrity and protections. If the server does not recognize the + request cookie or the request is made under different associations or + non-equivalent protections, the server SHALL return the initial + content as if no cookie had been provided or return an empty content + with the e-syncRefreshRequired LDAP result code. The decision + between the return of the initial content and the return of the empty + content with the e-syncRefreshRequired result code MAY be based on + reloadHint in the Sync Request Control from the client. If the + server recognizes the request cookie as representing empty or initial + synchronization state of the client copy, the server SHALL return the + initial content. + + A Synchronization Session may span multiple LDAP sessions between the + client and the server. The client SHOULD issue each Sync request of + a session to the same server. (Note: Shadowing considerations are + discussed in Section 6.) + +3.2. Content Determination + + The content to be provided is determined by parameters of the Search + Request, as described in [RFC4511], and possibly other controls. The + same content parameters SHOULD be used in each Sync request of a + session. If different content is requested and the server is + unwilling or unable to process the request, the server SHALL return + the initial content as if no cookie had been provided or return an + empty content with the e-syncRefreshRequired LDAP result code. The + decision between the return of the initial content and the return of + the empty content with the e-syncRefreshRequired result code MAY be + based on reloadHint in the Sync Request Control from the client. + + The content may not necessarily include all entries or references + that would be returned by a normal search operation, nor, for those + entries included, all attributes returned by a normal search. When + the server is unwilling or unable to provide synchronization for any + attribute for a set of entries, the server MUST treat all filter + components matching against these attributes as Undefined and MUST + NOT return these attributes in SearchResultEntry responses. + + + + +Zeilenga & Choi Experimental [Page 12] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Servers SHOULD support synchronization for all non-collective user- + application attributes for all entries. + + The server may also return continuation references to other servers + or to itself. The latter is allowed as the server may partition the + entries it holds into separate synchronization contexts. + + The client may chase all or some of these continuations, each as a + separate content synchronization session. + +3.3. refreshOnly Mode + + A Sync request with mode refreshOnly and with no cookie is a poll for + initial content. A Sync request with mode refreshOnly and with a + cookie representing a synchronization state is a poll for content + update. + +3.3.1. Initial Content Poll + + Upon receipt of the request, the server provides the initial content + using a set of zero or more SearchResultEntry and + SearchResultReference Messages followed by a SearchResultDone + Message. + + Each SearchResultEntry Message SHALL include a Sync State Control of + state add, an entryUUID containing the entry's UUID, and no cookie. + Each SearchResultReference Message SHALL include a Sync State Control + of state add, an entryUUID containing the UUID associated with the + reference (normally the UUID of the associated named referral + [RFC3296] object), and no cookie. The SearchResultDone Message SHALL + include a Sync Done Control having refreshDeletes set to FALSE. + + A resultCode value of success indicates that the operation + successfully completed. Otherwise, the result code indicates the + nature of the failure. The server may return e-syncRefreshRequired + result code on the initial content poll if it is safe to do so when + it is unable to perform the operation due to various reasons. + reloadHint is set to FALSE in the SearchRequest Message requesting + the initial content poll. + + If the operation is successful, a cookie representing the + synchronization state of the current client copy SHOULD be returned + for use in subsequent Sync Operations. + +3.3.2. Content Update Poll + + Upon receipt of the request, the server provides the content refresh + using a set of zero or more SearchResultEntry and + + + +Zeilenga & Choi Experimental [Page 13] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + SearchResultReference Messages followed by a SearchResultDone + Message. + + The server is REQUIRED to: + + a) provide the sequence of messages necessary for eventual + convergence of the client's copy of the content to the server's + copy, + + b) treat the request as an initial content request (e.g., ignore + the cookie or the synchronization state represented in the + cookie), + + c) indicate that the incremental convergence is not possible by + returning e-syncRefreshRequired, + + d) return a resultCode other than success or e- + syncRefreshRequired. + + A Sync Operation may consist of a single present phase, a single + delete phase, or a present phase followed by a delete phase. + + In each phase, for each entry or reference that has been added to the + content or been changed since the previous Sync Operation indicated + by the cookie, the server returns a SearchResultEntry or + SearchResultReference Message, respectively, each with a Sync State + Control consisting of state add, an entryUUID containing the UUID of + the entry or reference, and no cookie. Each SearchResultEntry + Message represents the current state of a changed entry. Each + SearchResultReference Message represents the current state of a + changed reference. + + In the present phase, for each entry that has not been changed since + the previous Sync Operation, an empty SearchResultEntry is returned + whose objectName reflects the entry's current DN, whose attributes + field is empty, and whose Sync State Control consists of state + present, an entryUUID containing the UUID of the entry, and no + cookie. For each reference that has not been changed since the + previous Sync Operation, an empty SearchResultReference containing an + empty SEQUENCE OF LDAPURL is returned with a Sync State Control + consisting of state present, an entryUUID containing the UUID of the + entry, and no cookie. No messages are sent for entries or references + that are no longer in the content. + + Multiple empty entries with a Sync State Control of state present + SHOULD be coalesced into one or more Sync Info Messages of syncIdSet + value with refreshDeletes set to FALSE. syncUUIDs contain a set of + UUIDs of the entries and references unchanged since the last Sync + + + +Zeilenga & Choi Experimental [Page 14] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Operation. syncUUIDs may be empty. The Sync Info Message of + syncIdSet may contain a cookie to represent the state of the content + after performing the synchronization of the entries in the set. + + In the delete phase, for each entry no longer in the content, the + server returns a SearchResultEntry whose objectName reflects a past + DN of the entry or is empty, whose attributes field is empty, and + whose Sync State Control consists of state delete, an entryUUID + containing the UUID of the deleted entry, and no cookie. For each + reference no longer in the content, a SearchResultReference + containing an empty SEQUENCE OF LDAPURL is returned with a Sync State + Control consisting of state delete, an entryUUID containing the UUID + of the deleted reference, and no cookie. + + Multiple empty entries with a Sync State Control of state delete + SHOULD be coalesced into one or more Sync Info Messages of syncIdSet + value with refreshDeletes set to TRUE. syncUUIDs contain a set of + UUIDs of the entries and references that have been deleted from the + content since the last Sync Operation. syncUUIDs may be empty. The + Sync Info Message of syncIdSet may contain a cookie to represent the + state of the content after performing the synchronization of the + entries in the set. + + When a present phase is followed by a delete phase, the two phases + are delimited by a Sync Info Message containing syncInfoValue of + refreshPresent, which may contain a cookie representing the state + after completing the present phase. The refreshPresent contains + refreshDone, which is always FALSE in the refreshOnly mode of Sync + Operation because it is followed by a delete phase. + + If a Sync Operation consists of a single phase, each phase and hence + the Sync Operation are marked as ended by a SearchResultDone Message + with Sync Done Control, which SHOULD contain a cookie representing + the state of the content after completing the Sync Operation. The + Sync Done Control contains refreshDeletes, which is set to FALSE for + the present phase and set to TRUE for the delete phase. + + If a Sync Operation consists of a present phase followed by a delete + phase, the Sync Operation is marked as ended at the end of the delete + phase by a SearchResultDone Message with Sync Done Control, which + SHOULD contain a cookie representing the state of the content after + completing the Sync Operation. The Sync Done Control contains + refreshDeletes, which is set to TRUE. + + The client can specify whether it prefers to receive an initial + content by supplying reloadHint of TRUE or to receive a e- + syncRefreshRequired resultCode by supplying reloadHint of FALSE + (hence absent), in the case that the server determines that it is + + + +Zeilenga & Choi Experimental [Page 15] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + impossible or inefficient to achieve the eventual convergence by + continuing the current incremental synchronization thread. + + A resultCode value of success indicates that the operation is + successfully completed. A resultCode value of e-syncRefreshRequired + indicates that a full or partial refresh is needed. Otherwise, the + result code indicates the nature of failure. A cookie is provided in + the Sync Done Control for use in subsequent Sync Operations for + incremental synchronization. + +3.4. refreshAndPersist Mode + + A Sync request with mode refreshAndPersist asks for initial content + or content update (during the refresh stage) followed by change + notifications (during the persist stage). + +3.4.1. refresh Stage + + The content refresh is provided as described in Section 3.3, except + that the successful completion of content refresh is indicated by + sending a Sync Info Message of refreshDelete or refreshPresent with a + refreshDone value set to TRUE instead of a SearchResultDone Message + with resultCode success. A cookie SHOULD be returned in the Sync + Info Message to represent the state of the content after finishing + the refresh stage of the Sync Operation. + +3.4.2. persist Stage + + Change notifications are provided during the persist stage. + + As updates are made to the DIT, the server notifies the client of + changes to the content. DIT updates may cause entries and references + to be added to the content, deleted from the content, or modified + within the content. DIT updates may also cause references to be + added, deleted, or modified within the content. + + Where DIT updates cause an entry to be added to the content, the + server provides a SearchResultEntry Message that represents the entry + as it appears in the content. The message SHALL include a Sync State + Control with state of add, an entryUUID containing the entry's UUID, + and an optional cookie. + + Where DIT updates cause a reference to be added to the content, the + server provides a SearchResultReference Message that represents the + reference in the content. The message SHALL include a Sync State + Control with state of add, an entryUUID containing the UUID + associated with the reference, and an optional cookie. + + + + +Zeilenga & Choi Experimental [Page 16] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Where DIT updates cause an entry to be modified within the content, + the server provides a SearchResultEntry Message that represents the + entry as it appears in the content. The message SHALL include a Sync + State Control with state of modify, an entryUUID containing the + entry's UUID, and an optional cookie. + + Where DIT updates cause a reference to be modified within the + content, the server provides a SearchResultReference Message that + represents the reference in the content. The message SHALL include a + Sync State Control with state of modify, an entryUUID containing the + UUID associated with the reference, and an optional cookie. + + Where DIT updates cause an entry to be deleted from the content, the + server provides a SearchResultEntry Message with no attributes. The + message SHALL include a Sync State Control with state of delete, an + entryUUID containing the entry's UUID, and an optional cookie. + + Where DIT updates cause a reference to be deleted from the content, + the server provides a SearchResultReference Message with an empty + SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control + with state of delete, an entryUUID containing the UUID associated + with the reference, and an optional cookie. + + Multiple empty entries with a Sync State Control of state delete + SHOULD be coalesced into one or more Sync Info Messages of syncIdSet + value with refreshDeletes set to TRUE. syncUUIDs contain a set of + UUIDs of the entries and references that have been deleted from the + content. The Sync Info Message of syncIdSet may contain a cookie to + represent the state of the content after performing the + synchronization of the entries in the set. + + With each of these messages, the server may provide a new cookie to + be used in subsequent Sync Operations. Additionally, the server may + also return Sync Info Messages of choice newCookie to provide a new + cookie. The client SHOULD use the newest (last) cookie it received + from the server in subsequent Sync Operations. + +3.5. Search Request Parameters + + As stated in Section 3.1, the client SHOULD specify the same + content-controlling parameters in each Search Request of the session. + All fields of the SearchRequest Message are considered content- + controlling parameters except for sizeLimit and timeLimit. + + + + + + + + +Zeilenga & Choi Experimental [Page 17] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +3.5.1. baseObject + + As with the normal search operation, the refresh and persist stages + are not isolated from DIT changes. It is possible that the entry + referred to by the baseObject is deleted, renamed, or moved. It is + also possible that the alias object used in finding the entry + referred to by the baseObject is changed such that the baseObject + refers to a different entry. + + If the DIT is updated during processing of the Sync Operation in a + manner that causes the baseObject no longer to refer to any entry or + in a manner that changes the entry the baseObject refers to, the + server SHALL return an appropriate non-success result code, such as + noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or + e-syncRefreshRequired. + +3.5.2. derefAliases + + This operation does not support alias dereferencing during searching. + The client SHALL specify neverDerefAliases or derefFindingBaseObj for + the SearchRequest derefAliases parameter. The server SHALL treat + other values (e.g., derefInSearching, derefAlways) as protocol + errors. + +3.5.3. sizeLimit + + The sizeLimit applies only to entries (regardless of their state in + Sync State Control) returned during the refreshOnly operation or the + refresh stage of the refreshAndPersist operation. + +3.5.4. timeLimit + + For a refreshOnly Sync Operation, the timeLimit applies to the whole + operation. For a refreshAndPersist operation, the timeLimit applies + only to the refresh stage including the generation of the Sync Info + Message with a refreshDone value of TRUE. + +3.5.5. filter + + The client SHOULD avoid filter assertions that apply to the values of + the attributes likely to be considered by the server as ones holding + meta-information. See Section 4. + +3.6. objectName + + The Sync Operation uses entryUUID values provided in the Sync State + Control as the primary keys to entries. The client MUST use these + entryUUIDs to correlate synchronization messages. + + + +Zeilenga & Choi Experimental [Page 18] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + In some circumstances, the DN returned may not reflect the entry's + current DN. In particular, when the entry is being deleted from the + content, the server may provide an empty DN if the server does not + wish to disclose the entry's current DN (or, if deleted from the DIT, + the entry's last DN). + + Also note that the entry's DN may be viewed as meta information (see + Section 4.1). + +3.7. Canceling the Sync Operation + + Servers MUST implement the LDAP Cancel [RFC3909] Operation and + support cancellation of outstanding Sync Operations as described + here. + + To cancel an outstanding Sync Operation, the client issues an LDAP + Cancel [RFC3909] Operation. + + If at any time the server becomes unwilling or unable to continue + processing a Sync Operation, the server SHALL return a + SearchResultDone with a non-success resultCode indicating the reason + for the termination of the operation. + + Whether the client or the server initiated the termination, the + server may provide a cookie in the Sync Done Control for use in + subsequent Sync Operations. + +3.8. Refresh Required + + In order to achieve the eventually-convergent synchronization, the + server may terminate the Sync Operation in the refresh or persist + stages by returning an e-syncRefreshRequired resultCode to the + client. If no cookie is provided, a full refresh is needed. If a + cookie representing a synchronization state is provided in this + response, an incremental refresh is needed. + + To obtain a full refresh, the client then issues a new + synchronization request with no cookie. To obtain an incremental + reload, the client issues a new synchronization with the provided + cookie. + + The server may choose to provide a full copy in the refresh stage + (e.g., ignore the cookie or the synchronization state represented in + the cookie) instead of providing an incremental refresh in order to + achieve the eventual convergence. + + + + + + +Zeilenga & Choi Experimental [Page 19] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + The decision between the return of the initial content and the return + of the e-syncRefreshRequired result code may be based on reloadHint + in the Sync Request Control from the client. + + In the case of persist stage Sync, the server returns the resultCode + of e-syncRefreshRequired to the client to indicate that the client + needs to issue a new Sync Operation in order to obtain a synchronized + copy of the content. If no cookie is provided, a full refresh is + needed. If a cookie representing a synchronization state is + provided, an incremental refresh is needed. + + The server may also return e-syncRefreshRequired if it determines + that a refresh would be more efficient than sending all the messages + required for convergence. + + Note that the client may receive one or more of SearchResultEntry, + SearchResultReference, and/or Sync Info Messages before it receives a + SearchResultDone Message with the e-syncRefreshRequired result code. + +3.9. Chattiness Considerations + + The server MUST ensure that the number of entry messages generated to + refresh the client content does not exceed the number of entries + presently in the content. While there is no requirement for servers + to maintain history information, if the server has sufficient history + to allow it to reliably determine which entries in the prior client + copy are no longer present in the content and the number of such + entries is less than or equal to the number of unchanged entries, the + server SHOULD generate delete entry messages instead of present entry + messages (see Section 3.3.2). + + When the amount of history information maintained in the server is + not enough for the clients to perform infrequent refreshOnly Sync + Operations, it is likely that the server has incomplete history + information (e.g., due to truncation) by the time those clients + connect again. + + The server SHOULD NOT resort to full reload when the history + information is not enough to generate delete entry messages. The + server SHOULD generate either present entry messages only or present + entry messages followed by delete entry messages to bring the client + copy to the current state. In the latter case, the present entry + messages bring the client copy to a state covered by the history + information maintained in the server. + + The server SHOULD maintain enough (current or historical) state + information (such as a context-wide last modify time stamp) to + determine if no changes were made in the context since the content + + + +Zeilenga & Choi Experimental [Page 20] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + refresh was provided and, when no changes were made, generate zero + delete entry messages instead of present messages. + + The server SHOULD NOT use the history information when its use does + not reduce the synchronization traffic or when its use can expose + sensitive information not allowed to be received by the client. + + The server implementor should also consider chattiness issues that + span multiple Sync Operations of a session. As noted in Section 3.8, + the server may return e-syncRefreshRequired if it determines that a + reload would be more efficient than continuing under the current + operation. If reloadHint in the Sync Request is TRUE, the server may + initiate a reload without directing the client to request a reload. + + The server SHOULD transfer a new cookie frequently to avoid having to + transfer information already provided to the client. Even where DIT + changes do not cause content synchronization changes to be + transferred, it may be advantageous to provide a new cookie using a + Sync Info Message. However, the server SHOULD avoid overloading the + client or network with Sync Info Messages. + + During persist mode, the server SHOULD coalesce multiple outstanding + messages updating the same entry. The server MAY delay generation of + an entry update in anticipation of subsequent changes to that entry + that could be coalesced. The length of the delay should be long + enough to allow coalescing of update requests issued back to back but + short enough that the transient inconsistency induced by the delay is + corrected in a timely manner. + + The server SHOULD use the syncIdSet Sync Info Message when there are + multiple delete or present messages to reduce the amount of + synchronization traffic. + + Also note that there may be many clients interested in a particular + directory change, and that servers attempting to service all of these + at once may cause congestion on the network. The congestion issues + are magnified when the change requires a large transfer to each + interested client. Implementors and deployers of servers should take + steps to prevent and manage network congestion. + +3.10. Operation Multiplexing + + The LDAP protocol model [RFC4511] allows operations to be multiplexed + over a single LDAP session. Clients SHOULD NOT maintain multiple + LDAP sessions with the same server. Servers SHOULD ensure that + responses from concurrently processed operations are interleaved + fairly. + + + + +Zeilenga & Choi Experimental [Page 21] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Clients SHOULD combine Sync Operations whose result set is largely + overlapping. This avoids having to return multiple messages, once + for each overlapping session, for changes to entries in the overlap. + + Clients SHOULD NOT combine Sync Operations whose result sets are + largely non-overlapping. This ensures that an event requiring an + e-syncRefreshRequired response can be limited to as few result sets + as possible. + +4. Meta Information Considerations + +4.1. Entry DN + + As an entry's DN is constructed from its relative DN (RDN) and the + entry's parent's DN, it is often viewed as meta information. + + While renaming or moving to a new superior causes the entry's DN to + change, that change SHOULD NOT, by itself, cause synchronization + messages to be sent for that entry. However, if the renaming or the + moving could cause the entry to be added or deleted from the content, + appropriate synchronization messages should be generated to indicate + this to the client. + + When a server treats the entry's DN as meta information, the server + SHALL either + + - evaluate all MatchingRuleAssertions [RFC4511] to TRUE if + matching a value of an attribute of the entry, otherwise + Undefined, or + + - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as + Undefined. + + The latter choice is offered for ease of server implementation. + +4.2. Operational Attributes + + Where values of an operational attribute are determined by values not + held as part of the entry it appears in, the operational attribute + SHOULD NOT support synchronization of that operational attribute. + + For example, in servers that implement the X.501 subschema model + [X.501], servers should not support synchronization of the + subschemaSubentry attribute as its value is determined by values held + and administrated in subschema subentries. + + + + + + +Zeilenga & Choi Experimental [Page 22] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + As a counter example, servers that implement aliases [RFC4512][X.501] + can support synchronization of the aliasedObjectName attribute as its + values are held and administrated as part of the alias entries. + + Servers SHOULD support synchronization of the following operational + attributes: createTimestamp, modifyTimestamp, creatorsName, + modifiersName [RFC4512]. Servers MAY support synchronization of + other operational attributes. + +4.3. Collective Attributes + + A collective attribute is "a user attribute whose values are the same + for each member of an entry collection" [X.501]. Use of collective + attributes in LDAP is discussed in [RFC3671]. + + Modification of a collective attribute generally affects the content + of multiple entries, which are the members of the collection. It is + inefficient to include values of collective attributes visible in + entries of the collection, as a single modification of a collective + attribute requires transmission of multiple SearchResultEntry (one + for each entry of the collection that the modification affected). + + Servers SHOULD NOT synchronize collective attributes appearing in + entries of any collection. Servers MAY support synchronization of + collective attributes appearing in collective attribute subentries. + +4.4. Access and Other Administrative Controls + + Entries are commonly subject to access and other administrative + Controls. While portions of the policy information governing a + particular entry may be held in the entry, policy information is + often held elsewhere (in superior entries, in subentries, in the root + DSE, in configuration files, etc.). Because of this, changes to + policy information make it difficult to ensure eventual convergence + during incremental synchronization. + + Where it is impractical or infeasible to generate content changes + resulting from a change to policy information, servers may opt to + return e-syncRefreshRequired or to treat the Sync Operation as an + initial content request (e.g., ignore the cookie or the + synchronization state represented in the cookie). + +5. Interaction with Other Controls + + The Sync Operation may be used with: + + - ManageDsaIT Control [RFC3296] + + + + +Zeilenga & Choi Experimental [Page 23] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + - Subentries Control [RFC3672] + + as described below. The Sync Operation may be used with other LDAP + extensions as detailed in other documents. + +5.1. ManageDsaIT Control + + The ManageDsaIT Control [RFC3296] indicates that the operation acts + upon the DSA Information Tree and causes referral and other special + entries to be treated as object entries with respect to the + operation. + +5.2. Subentries Control + + The Subentries Control is used with the search operation "to control + the visibility of entries and subentries which are within scope" + [RFC3672]. When used with the Sync Operation, the subentries control + and other factors (search scope, filter, etc.) are used to determine + whether an entry or subentry appears in the content. + +6. Shadowing Considerations + + As noted in [RFC4511], some servers may hold shadow copies of entries + that can be used to answer search and comparison queries. Such + servers may also support content synchronization requests. This + section discusses considerations for implementors and deployers for + the implementation and deployment of the Sync operation in shadowed + directories. + + While a client may know of multiple servers that are equally capable + of being used to obtain particular directory content from, a client + SHOULD NOT assume that each of these servers is equally capable of + continuing a content synchronization session. As stated in Section + 3.1, the client SHOULD issue each Sync request of a Sync session to + the same server. + + However, through domain naming or IP address redirection or other + techniques, multiple physical servers can be made to appear as one + logical server to a client. Only servers that are equally capable in + regards to their support for the Sync operation and that hold equally + complete copies of the entries should be made to appear as one + logical server. In particular, each physical server acting as one + logical server SHOULD be equally capable of continuing a content + synchronization based upon cookies provided by any of the other + physical servers without requiring a full reload. Because there is + no standard LDAP shadowing mechanism, the specification of how to + independently implement equally capable servers (as well as the + precise definition of "equally capable") is left to future documents. + + + +Zeilenga & Choi Experimental [Page 24] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + Note that it may be difficult for the server to reliably determine + what content was provided to the client by another server, especially + in the shadowing environments that allow shadowing events to be + coalesced. For these servers, the use of the delete phase discussed + in Section 3.3.2 may not be applicable. + +7. Security Considerations + + In order to maintain a synchronized copy of the content, a client is + to delete information from its copy of the content as described + above. However, the client may maintain knowledge of information + disclosed to it by the server separate from its copy of the content + used for synchronization. Management of this knowledge is beyond the + scope of this document. Servers should be careful not to disclose + information for content the client is not authorized to have + knowledge of and/or about. + + While the information provided by a series of refreshOnly Sync + Operations is similar to that provided by a series of Search + Operations, persist stage may disclose additional information. A + client may be able to discern information about the particular + sequence of update operations that caused content change. + + Implementors should take precautions against malicious cookie + content, including malformed cookies or valid cookies used with + different security associations and/or protections in an attempt to + obtain unauthorized access to information. Servers may include a + digital signature in the cookie to detect tampering. + + The operation may be the target of direct denial-of-service attacks. + Implementors should provide safeguards to ensure the operation is not + abused. Servers may place access control or other restrictions upon + the use of this operation. + + Note that even small updates to the directory may cause a significant + amount of traffic to be generated to clients using this operation. A + user could abuse its update privileges to mount an indirect denial of + service to these clients, other clients, and/or portions of the + network. Servers should provide safeguards to ensure that update + operations are not abused. + + Implementors of this (or any) LDAP extension should be familiar with + general LDAP security considerations [RFC4510]. + + + + + + + + +Zeilenga & Choi Experimental [Page 25] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +8. IANA Considerations + + Registration of the following values have been completed by the IANA + [RFC4520]. + +8.1. Object Identifier + + The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the + OpenLDAP Foundation, under its IANA-assigned private enterprise + allocation [PRIVATE], for use in this specification. + +8.2. LDAP Protocol Mechanism + + The IANA has registered the LDAP Protocol Mechanism described in this + document. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1 + Description: LDAP Content Synchronization Control + Person & email address to contact for further information: + Kurt Zeilenga <kurt@openldap.org> + Usage: Control + Specification: RFC 4533 + Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi + Comments: none + +8.3. LDAP Result Codes + + The IANA has registered the LDAP Result Code described in this + document. + + Subject: LDAP Result Code Registration + Person & email address to contact for further information: + Kurt Zeilenga <kurt@OpenLDAP.org> + Result Code Name: e-syncRefreshRequired (4096) + Specification: RFC 4533 + Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi + Comments: none + +9. Acknowledgements + + This document borrows significantly from the LDAP Client Update + Protocol [RFC3928], a product of the IETF LDUP working group. This + document also benefited from Persistent Search [PSEARCH], Triggered + Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. + This document also borrows from "Lightweight Directory Access + Protocol (v3)" [RFC2251]. + + + + +Zeilenga & Choi Experimental [Page 26] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +10. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3296] Zeilenga, K., "Named Subordinate References in + Lightweight Directory Access Protocol (LDAP) + Directories", RFC 3296, July 2002. + + [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight + Directory Access Protocol (LDAP)", RFC 3671, December + 2003. + + [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory + Access Protocol (LDAP)", RFC 3672, December 2003. + + [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Cancel Operation", RFC 3909, October 2004. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) entryUUID Operational Attribute", RFC 4530, June + 2006. + + [UUID] International Organization for Standardization (ISO), + "Information technology - Open Systems Interconnection - + Remote Procedure Call", ISO/IEC 11578:1996 + + [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). + + + + + +Zeilenga & Choi Experimental [Page 27] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + [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). + +11. Informative References + + [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J. + Parham, "Lightweight Directory Access Protocol (LDAP) + Client Update Protocol (LCUP)", RFC 3928, October 2004. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [PRIVATE] IANA, "Private Enterprise Numbers", + http://www.iana.org/assignments/enterprise-numbers. + + [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", + http://www.openldap.org/foundation/oid-delegate.txt. + + [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.525] International Telecommunication Union - Telecommunication + Standardization Sector, "The Directory: Replication", + X.525(1993). + + [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory + Synchronization", Work in Progress. + + [PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP + Change Notification Mechanism", Work in Progress. + + [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in + Progress. + + + + + + + + + +Zeilenga & Choi Experimental [Page 28] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +Appendix A. CSN-based Implementation Considerations + + This appendix is provided for informational purposes only; it is not + a normative part of the LDAP Content Synchronization Operation's + technical specification. + + This appendix discusses LDAP Content Synchronization Operation server + implementation considerations associated with Change Sequence Number + based approaches. + + Change Sequence Number based approaches are targeted for use in + servers that do not maintain history information (e.g., change logs, + state snapshots) about changes made to the Directory and hence, must + rely on current directory state and minimal synchronization state + information embedded in Sync Cookie. Servers that maintain history + information should consider other approaches that exploit the history + information. + + A Change Sequence Number is effectively a time stamp that has + sufficient granularity to ensure that the precedence relationship in + time of two updates to the same object can be determined. Change + Sequence Numbers are not to be confused with Commit Sequence Numbers + or Commit Log Record Numbers. A Commit Sequence Number allows one to + determine how two commits (to the same object or different objects) + relate to each other in time. A Change Sequence Number associated + with different entries may be committed out of order. In the + remainder of this Appendix, the term CSN refers to a Change Sequence + Number. + + In these approaches, the server not only maintains a CSN for each + directory entry (the entry CSN) but also maintains a value that we + will call the context CSN. The context CSN is the greatest committed + entry CSN that is not greater than any outstanding (uncommitted) + entry CSNs for all entries in a directory context. The values of + context CSN are used in syncCookie values as synchronization state + indicators. + + As search operations are not isolated from individual directory + update operations and individual update operations cannot be assumed + to be serialized, one cannot assume that the returned content + incorporates each relevant change whose change sequence number is + less than or equal to the greatest entry CSN in the content. The + content incorporates all the relevant changes whose change sequence + numbers are less than or equal to context CSN before search + processing. The content may also incorporate any subset of the + changes whose change sequence number is greater than context CSN + before search processing but less than or equal to the context CSN + after search processing. The content does not incorporate any of the + + + +Zeilenga & Choi Experimental [Page 29] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + + changes whose CSN is greater than the context CSN after search + processing. + + A simple server implementation could use the value of the context CSN + before search processing to indicate state. Such an implementation + would embed this value into each SyncCookie returned. We'll call + this the cookie CSN. When a refresh was requested, the server would + simply generate "update" messages for all entries in the content + whose CSN is greater than the supplied cookie CSN and generate + "present" messages for all other entries in the content. However, if + the current context CSN is the same as the cookie CSN, the server + should instead generate zero "updates" and zero "delete" messages and + indicate a refreshDeletes of TRUE, as the directory has not changed. + + The implementation should also consider the impact of changes to meta + information, such as access controls, that affect content + determination. One approach is for the server to maintain a + context-wide meta information CSN or meta CSN. This meta CSN would + be updated whenever meta information affecting content determination + was changed. If the value of the meta CSN is greater than the cookie + CSN, the server should ignore the cookie and treat the request as an + initial request for content. + + Additionally, servers may want to consider maintaining some per- + session history information to reduce the number of messages needed + to be transferred during incremental refreshes. Specifically, a + server could record information about entries as they leave the scope + of a disconnected sync session and later use this information to + generate delete messages instead of present messages. + + When the history information is truncated, the CSN of the latest + truncated history information entry may be recorded as the truncated + CSN of the history information. The truncated CSN may be used to + determine whether a client copy can be covered by the history + information by comparing it to the synchronization state contained in + the cookie supplied by the client. + + When there is a large number of sessions, it may make sense to + maintain such history only for the selected clients. Also, servers + taking this approach need to consider resource consumption issues to + ensure reasonable server operation and to protect against abuse. It + may be appropriate to restrict this mode of operation by policy. + + + + + + + + + +Zeilenga & Choi Experimental [Page 30] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +Authors' Addresses + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + Jong Hyuk Choi + IBM Corporation + + EMail: jongchoi@us.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga & Choi Experimental [Page 31] + +RFC 4533 LDAP Content Synchronization Operation June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Zeilenga & Choi Experimental [Page 32] + |