summaryrefslogtreecommitdiff
path: root/source4/ldap_server
diff options
context:
space:
mode:
authorSimo Sorce <idra@samba.org>2006-07-22 19:26:52 +0000
committerGerald (Jerry) Carter <jerry@samba.org>2007-10-10 14:10:17 -0500
commit3faab3e6dd2c804ae81a910275339f6ce8237e77 (patch)
tree96d089d38b9f95111b99b19500f385d53b70b8bc /source4/ldap_server
parent7718ef4c6649bfed415b4034e960f1f3dcc07bdb (diff)
downloadsamba-3faab3e6dd2c804ae81a910275339f6ce8237e77.tar.gz
samba-3faab3e6dd2c804ae81a910275339f6ce8237e77.tar.bz2
samba-3faab3e6dd2c804ae81a910275339f6ce8237e77.zip
r17189: Add the new LDAP rfc series
(This used to be commit d3f8b813b33d1338e62f099017a1d4a32745e7a2)
Diffstat (limited to 'source4/ldap_server')
-rw-r--r--source4/ldap_server/devdocs/rfc4510.txt395
-rw-r--r--source4/ldap_server/devdocs/rfc4511.txt3811
-rw-r--r--source4/ldap_server/devdocs/rfc4512.txt2915
-rw-r--r--source4/ldap_server/devdocs/rfc4513.txt1907
-rw-r--r--source4/ldap_server/devdocs/rfc4514.txt843
-rw-r--r--source4/ldap_server/devdocs/rfc4515.txt675
-rw-r--r--source4/ldap_server/devdocs/rfc4516.txt843
-rw-r--r--source4/ldap_server/devdocs/rfc4517.txt2971
-rw-r--r--source4/ldap_server/devdocs/rfc4518.txt787
-rw-r--r--source4/ldap_server/devdocs/rfc4519.txt1963
-rw-r--r--source4/ldap_server/devdocs/rfc4520.txt1067
-rw-r--r--source4/ldap_server/devdocs/rfc4521.txt899
-rw-r--r--source4/ldap_server/devdocs/rfc4522.txt451
-rw-r--r--source4/ldap_server/devdocs/rfc4523.txt1347
-rw-r--r--source4/ldap_server/devdocs/rfc4524.txt1403
-rw-r--r--source4/ldap_server/devdocs/rfc4525.txt339
-rw-r--r--source4/ldap_server/devdocs/rfc4526.txt283
-rw-r--r--source4/ldap_server/devdocs/rfc4527.txt451
-rw-r--r--source4/ldap_server/devdocs/rfc4528.txt339
-rw-r--r--source4/ldap_server/devdocs/rfc4529.txt339
-rw-r--r--source4/ldap_server/devdocs/rfc4530.txt451
-rw-r--r--source4/ldap_server/devdocs/rfc4531.txt507
-rw-r--r--source4/ldap_server/devdocs/rfc4532.txt395
-rw-r--r--source4/ldap_server/devdocs/rfc4533.txt1795
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]
+