idnits 2.17.1 draft-ietf-ldapbis-protocol-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 20) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2444 -- Looks like a reference, but probably isn't: '3' on line 2383 == Missing Reference: 'LDAPURL' is mentioned on line 3194, but not defined == Missing Reference: 'APPLICATION 0' is mentioned on line 2317, but not defined == Missing Reference: 'SASLprep' is mentioned on line 680, but not defined == Missing Reference: 'Stringprep' is mentioned on line 680, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 2332, but not defined -- Looks like a reference, but probably isn't: '7' on line 2367 == Missing Reference: 'APPLICATION 2' is mentioned on line 2336, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 2338, but not defined -- Looks like a reference, but probably isn't: '1' on line 2445 -- Looks like a reference, but probably isn't: '2' on line 2382 -- Looks like a reference, but probably isn't: '4' on line 2384 -- Looks like a reference, but probably isn't: '5' on line 2365 -- Looks like a reference, but probably isn't: '6' on line 2366 -- Looks like a reference, but probably isn't: '8' on line 2368 -- Looks like a reference, but probably isn't: '9' on line 2369 == Missing Reference: 'APPLICATION 4' is mentioned on line 2386, but not defined == Missing Reference: 'APPLICATION 19' is mentioned on line 2397, but not defined == Missing Reference: 'APPLICATION 5' is mentioned on line 2402, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 2404, but not defined == Missing Reference: 'APPLICATION 7' is mentioned on line 2413, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 2415, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 2421, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2423, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 2425, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2427, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 2433, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 2435, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 2439, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 2441, but not defined == Missing Reference: 'APPLICATION 23' is mentioned on line 2443, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 2447, but not defined -- Looks like a reference, but probably isn't: '10' on line 2449 -- Looks like a reference, but probably isn't: '11' on line 2450 == Missing Reference: 'RFC2246' is mentioned on line 2004, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'AUTHMETH' is mentioned on line 3184, but not defined == Missing Reference: 'Keywords' is mentioned on line 3292, but not defined == Unused Reference: 'SASLPrep' is defined on line 1929, but no explicit reference was found in the text == Unused Reference: 'IP' is defined on line 1944, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' == Outdated reference: A later version (-07) exists of draft-ietf-ldapbis-bcp64-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- No information found for draft-ietf-sasl-saslprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 5 errors (**), 0 flaws (~~), 33 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Editor: J. Sermersheim 3 Intended Category: Standard Track Novell, Inc 4 Document: draft-ietf-ldapbis-protocol-18.txt Oct 2003 5 Obsoletes: RFC 2251 7 LDAP: The Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. Technical discussion of this 29 document will take place on the IETF LDAP Revision Working Group 30 (LDAPbis) mailing list . Please send 31 editorial comments directly to the editor . 33 Abstract 35 This document describes the protocol elements, along with their 36 semantics and encodings, of the Lightweight Directory Access Protocol 37 (LDAP). LDAP provides access to distributed directory services that 38 act in accordance with X.500 data and service models. These protocol 39 elements are based on those described in the X.500 Directory Access 40 Protocol (DAP). 42 Table of Contents 44 1. Introduction....................................................3 45 2. Conventions.....................................................3 46 3. Protocol Model..................................................3 47 4. Elements of Protocol............................................4 48 4.1. Common Elements...............................................4 49 4.1.1. Message Envelope............................................4 50 4.1.2. String Types................................................6 51 4.1.3. Distinguished Name and Relative Distinguished Name..........6 52 Lightweight Directory Access Protocol Version 3 54 4.1.4. Attribute Descriptions......................................7 55 4.1.5. Attribute Value.............................................7 56 4.1.6. Attribute Value Assertion...................................7 57 4.1.7. Attribute...................................................8 58 4.1.8. Matching Rule Identifier....................................8 59 4.1.9. Result Message..............................................8 60 4.1.10. Referral..................................................10 61 4.1.11. Controls..................................................11 62 4.2. Bind Operation...............................................12 63 4.3. Unbind Operation.............................................15 64 4.4. Unsolicited Notification.....................................15 65 4.5. Search Operation.............................................16 66 4.6. Modify Operation.............................................24 67 4.7. Add Operation................................................26 68 4.8. Delete Operation.............................................26 69 4.9. Modify DN Operation..........................................27 70 4.10. Compare Operation...........................................28 71 4.11. Abandon Operation...........................................29 72 4.12. Extended Operation..........................................29 73 4.13. Start TLS Operation.........................................31 74 5. Protocol Element Encodings and Transfer........................33 75 5.1. Protocol Encoding............................................33 76 5.2. Transfer Protocols...........................................33 77 6. Implementation Guidelines......................................33 78 6.1. Server Implementations.......................................33 79 6.2. Client Implementations.......................................34 80 7. Security Considerations........................................34 81 8. Acknowledgements...............................................35 82 9. Normative References...........................................35 83 10. Informative References........................................37 84 11. IANA Considerations...........................................37 85 12. Editor's Address..............................................37 86 Appendix A - LDAP Result Codes....................................38 87 A.1 Non-Error Result Codes........................................38 88 A.2 Result Codes..................................................38 89 Appendix C - Change History.......................................47 90 C.1 Changes made to RFC 2251:.....................................47 91 C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:...........47 92 C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:...........48 93 C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:...........48 94 C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:...........50 95 C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:...........52 96 C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:...........52 97 C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:...........53 98 C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:...........56 99 C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt:..........56 100 C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt:..........56 101 C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt:..........56 102 C.13 Changes made to draft-ietf-ldapbis-protocol-11.txt:..........57 103 C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt:..........57 104 C.15 Changes made to draft-ietf-ldapbis-protocol-13.txt...........57 105 C.16 Changes made to draft-ietf-ldapbis-protocol-14.txt...........58 106 C.17 Changes made to draft-ietf-ldapbis-protocol-15.txt...........60 107 C.18 Changes made to draft-ietf-ldapbis-protocol-16.txt...........60 108 Lightweight Directory Access Protocol Version 3 110 C.19 Changes made to draft-ietf-ldapbis-protocol-17.txt...........61 112 1. Introduction 114 The Directory is "a collection of open systems cooperating to provide 115 directory services" [X.500]. A directory user, which may be a human 116 or other entity, accesses the Directory through a client (or 117 Directory User Agent (DUA)). The client, on behalf of the directory 118 user, interacts with one or more servers (or Directory System Agents 119 (DSA)). Clients interact with servers using a directory access 120 protocol. 122 This document details the protocol elements of the Lightweight 123 Directory Access Protocol (LDAP), along with their semantics. 124 Following the description of protocol elements, it describes the way 125 in which the protocol elements are encoded and transferred. 127 This document is an integral part of the LDAP Technical Specification 128 [Roadmap]. 130 This document replaces RFC 2251. Appendix C holds a detailed log of 131 changes to RFC 2251. After Working Group Last Call, this appendix 132 will be distilled to a summary of changes to RFC 2251. 134 2. Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 138 to be interpreted as described in [Keyword]. 140 The terms "connection" and "LDAP connection" both refer to the 141 underlying transport protocol connection between two protocol peers. 143 The term "TLS connection" refers to a TLS-protected LDAP connection. 145 The terms "association" and "LDAP association" both refer to the 146 association of the LDAP connection and its current authentication and 147 authorization state. 149 3. Protocol Model 151 The general model adopted by this protocol is one of clients 152 performing protocol operations against servers. In this model, a 153 client transmits a protocol request describing the operation to be 154 performed to a server. The server is then responsible for performing 155 the necessary operation(s) in the Directory. Upon completion of the 156 operation(s), the server returns a response containing an appropriate 157 result code to the requesting client. 159 Lightweight Directory Access Protocol Version 3 161 Although servers are required to return responses whenever such 162 responses are defined in the protocol, there is no requirement for 163 synchronous behavior on the part of either clients or servers. 164 Requests and responses for multiple operations may be exchanged 165 between a client and server in any order, provided the client 166 eventually receives a response for every request that requires one. 168 The core protocol operations defined in this document can be mapped 169 to a subset of the X.500 (1993) Directory Abstract Service. However 170 there is not a one-to-one mapping between LDAP protocol operations 171 and X.500 Directory Access Protocol (DAP) operations. Server 172 implementations acting as a gateway to X.500 directories may need to 173 make multiple DAP requests to service a single LDAP request. 175 4. Elements of Protocol 177 The LDAP protocol is described using Abstract Syntax Notation One 178 [ASN.1], and is transferred using a subset of ASN.1 Basic Encoding 179 Rules [BER]. Section 5.1 specifies how the protocol elements are 180 encoded and transferred. 182 In order to support future Standards Track extensions to this 183 protocol, extensibility is implied where it is allowed (per ASN.1). 184 In addition, ellipses (...) have been supplied in ASN.1 types that 185 are explicitly extensible as discussed in [LDAPIANA]. Because of the 186 implied extensibility, clients and servers MUST (unless otherwise 187 specified) ignore trailing SEQUENCE components whose tags they do not 188 recognize. 190 Changes to the LDAP protocol other than through the extension 191 mechanisms described here require a different version number. A 192 client indicates the version it is using as part of the bind request, 193 described in section 4.2. If a client has not sent a bind, the server 194 MUST assume the client is using version 3 or later. 196 Clients may determine the protocol versions a server supports by 197 reading the supportedLDAPVersion attribute from the root DSE (DSA- 198 Specific Entry) [Models]. Servers which implement version 3 or later 199 MUST provide this attribute. 201 4.1. Common Elements 203 This section describes the LDAPMessage envelope PDU (Protocol Data 204 Unit) format, as well as data type definitions, which are used in the 205 protocol operations. 207 4.1.1. Message Envelope 209 For the purposes of protocol exchanges, all protocol operations are 210 encapsulated in a common envelope, the LDAPMessage, which is defined 211 as follows: 213 Lightweight Directory Access Protocol Version 3 215 LDAPMessage ::= SEQUENCE { 216 messageID MessageID, 217 protocolOp CHOICE { 218 bindRequest BindRequest, 219 bindResponse BindResponse, 220 unbindRequest UnbindRequest, 221 searchRequest SearchRequest, 222 searchResEntry SearchResultEntry, 223 searchResDone SearchResultDone, 224 searchResRef SearchResultReference, 225 modifyRequest ModifyRequest, 226 modifyResponse ModifyResponse, 227 addRequest AddRequest, 228 addResponse AddResponse, 229 delRequest DelRequest, 230 delResponse DelResponse, 231 modDNRequest ModifyDNRequest, 232 modDNResponse ModifyDNResponse, 233 compareRequest CompareRequest, 234 compareResponse CompareResponse, 235 abandonRequest AbandonRequest, 236 extendedReq ExtendedRequest, 237 extendedResp ExtendedResponse, 238 ... }, 239 controls [0] Controls OPTIONAL } 241 MessageID ::= INTEGER (0 .. maxInt) 243 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 245 The function of the LDAPMessage is to provide an envelope containing 246 common fields required in all protocol exchanges. At this time the 247 only common fields are the message ID and the controls. 249 If the server receives a PDU from the client in which the LDAPMessage 250 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 251 the tag of the protocolOp is not recognized as a request, or the 252 encoding structures or lengths of data fields are found to be 253 incorrect, then the server SHOULD return the Notice of Disconnection 254 described in section 4.4.1, with the resultCode set to protocolError, 255 and MUST immediately close the connection. 257 In other cases where the client or server cannot parse a PDU, it 258 SHOULD abruptly close the connection where further communication 259 (including providing notice) would be pernicious. Otherwise, server 260 implementations MUST return an appropriate response to the request, 261 with the resultCode set to protocolError. 263 The ASN.1 type Controls is defined in section 4.1.11. 265 4.1.1.1. Message ID 266 Lightweight Directory Access Protocol Version 3 268 All LDAPMessage envelopes encapsulating responses contain the 269 messageID value of the corresponding request LDAPMessage. 271 The message ID of a request MUST have a non-zero value different from 272 the values of any other requests outstanding in the LDAP association 273 of which this message is a part. The zero value is reserved for the 274 unsolicited notification message. 276 Typical clients increment a counter for each request. 278 A client MUST NOT send a request with the same message ID as an 279 earlier request on the same LDAP association unless it can be 280 determined that the server is no longer servicing the earlier 281 request. Otherwise the behavior is undefined. For operations that do 282 not return responses (unbind, abandon, and abandoned operations), the 283 client SHOULD assume the operation is in progress until a subsequent 284 bind request completes. 286 4.1.2. String Types 288 The LDAPString is a notational convenience to indicate that, although 289 strings of LDAPString type encode as OCTET STRING types, the 290 [ISO10646] character set (a superset of [Unicode]) is used, encoded 291 following the [UTF-8] algorithm. Note that Unicode characters U+0000 292 through U+007F are the same as ASCII 0 through 127, respectively, and 293 have the same single octet UTF-8 encoding. Other Unicode characters 294 have a multiple octet UTF-8 encoding. 296 LDAPString ::= OCTET STRING -- UTF-8 encoded, 297 -- [ISO10646] characters 299 The LDAPOID is a notational convenience to indicate that the 300 permitted value of this string is a (UTF-8 encoded) dotted-decimal 301 representation of an OBJECT IDENTIFIER. Although an LDAPOID is 302 encoded as an OCTET STRING, values are limited to the definition of 303 given in Section 1.3 of [Models]. 305 LDAPOID ::= OCTET STRING -- Constrained to [Models] 307 For example, 309 1.3.6.1.4.1.1466.1.2.3 311 4.1.3. Distinguished Name and Relative Distinguished Name 313 An LDAPDN is defined to be the representation of a distinguished name 314 (DN) after encoding according to the specification in [LDAPDN]. 316 LDAPDN ::= LDAPString 317 -- Constrained to [LDAPDN] 318 Lightweight Directory Access Protocol Version 3 320 A RelativeLDAPDN is defined to be the representation of a relative 321 distinguished name (RDN) after encoding according to the 322 specification in [LDAPDN]. 324 RelativeLDAPDN ::= LDAPString 325 -- Constrained to [LDAPDN] 327 4.1.4. Attribute Descriptions 329 The definition and encoding rules for attribute descriptions are 330 defined in Section 2.5 of [Models]. Briefly, an attribute description 331 is an attribute type and zero or more options. 333 AttributeDescription ::= LDAPString 334 -- Constrained to 335 -- [Models] 337 4.1.5. Attribute Value 339 A field of type AttributeValue is an OCTET STRING containing an 340 encoded attribute value. The attribute value is encoded according to 341 the LDAP-specific encoding definition of its corresponding syntax. 342 The LDAP-specific encoding definitions for different syntaxes and 343 attribute types may be found in other documents and in particular 344 [Syntaxes]. 346 AttributeValue ::= OCTET STRING 348 Note that there is no defined limit on the size of this encoding; 349 thus protocol values may include multi-megabyte attributes (e.g. 350 photographs). 352 Attributes may be defined which have arbitrary and non-printable 353 syntax. Implementations MUST NOT display nor attempt to decode a 354 value if its syntax is not known. The implementation may attempt to 355 discover the subschema of the source entry, and retrieve the 356 descriptions of attributeTypes from it [Models]. 358 Clients MUST NOT send attribute values in a request that are not 359 valid according to the syntax defined for the attributes. 361 4.1.6. Attribute Value Assertion 363 The AttributeValueAssertion type definition is similar to the one in 364 the X.500 Directory standards. It contains an attribute description 365 and a matching rule assertion value suitable for that type. 367 AttributeValueAssertion ::= SEQUENCE { 368 attributeDesc AttributeDescription, 369 assertionValue AssertionValue } 370 Lightweight Directory Access Protocol Version 3 372 AssertionValue ::= OCTET STRING 374 The syntax of the AssertionValue depends on the context of the LDAP 375 operation being performed. For example, the syntax of the EQUALITY 376 matching rule for an attribute is used when performing a Compare 377 operation. Often this is the same syntax used for values of the 378 attribute type, but in some cases the assertion syntax differs from 379 the value syntax. See objectIdentiferFirstComponentMatch in 380 [Syntaxes] for an example. 382 4.1.7. Attribute 384 An attribute consists of an attribute description and one or more 385 values of that attribute description. 387 Attribute ::= SEQUENCE { 388 type AttributeDescription, 389 vals SET SIZE (1..MAX) OF value AttributeValue } 391 Each attribute value is distinct in the set (no duplicates). The set 392 of attribute values is unordered. Implementations MUST NOT rely upon 393 the ordering being repeatable. 395 4.1.8. Matching Rule Identifier 397 Matching rules are defined in 4.1.3 of [Models]. A matching rule is 398 identified in the LDAP protocol by the printable representation of 399 either its , or one of its short name descriptors 400 [Models], e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33". 402 MatchingRuleId ::= LDAPString 404 4.1.9. Result Message 406 The LDAPResult is the construct used in this protocol to return 407 success or failure indications from servers to clients. To various 408 requests, servers will return responses of LDAPResult or responses 409 containing the components of LDAPResult to indicate the final status 410 of a protocol operation request. 412 LDAPResult ::= SEQUENCE { 413 resultCode ENUMERATED { 414 success (0), 415 operationsError (1), 416 protocolError (2), 417 timeLimitExceeded (3), 418 sizeLimitExceeded (4), 419 compareFalse (5), 420 compareTrue (6), 421 authMethodNotSupported (7), 422 strongAuthRequired (8), 423 -- 9 reserved -- 424 Lightweight Directory Access Protocol Version 3 426 referral (10), 427 adminLimitExceeded (11), 428 unavailableCriticalExtension (12), 429 confidentialityRequired (13), 430 saslBindInProgress (14), 431 noSuchAttribute (16), 432 undefinedAttributeType (17), 433 inappropriateMatching (18), 434 constraintViolation (19), 435 attributeOrValueExists (20), 436 invalidAttributeSyntax (21), 437 -- 22-31 unused -- 438 noSuchObject (32), 439 aliasProblem (33), 440 invalidDNSyntax (34), 441 -- 35 reserved for undefined isLeaf -- 442 aliasDereferencingProblem (36), 443 -- 37-47 unused -- 444 inappropriateAuthentication (48), 445 invalidCredentials (49), 446 insufficientAccessRights (50), 447 busy (51), 448 unavailable (52), 449 unwillingToPerform (53), 450 loopDetect (54), 451 -- 55-63 unused -- 452 namingViolation (64), 453 objectClassViolation (65), 454 notAllowedOnNonLeaf (66), 455 notAllowedOnRDN (67), 456 entryAlreadyExists (68), 457 objectClassModsProhibited (69), 458 -- 70 reserved for CLDAP -- 459 affectsMultipleDSAs (71), 460 -- 72-79 unused -- 461 other (80), 462 ... }, 463 -- 81-90 reserved for APIs -- 464 matchedDN LDAPDN, 465 diagnosticMessage LDAPString, 466 referral [3] Referral OPTIONAL } 468 The resultCode enumeration is extensible as defined in Section 3.5 of 469 [LDAPIANA]. The meanings of the result codes are given in Appendix A. 470 If a server detects multiple errors for an operation, only one result 471 code is returned. The server should return the result code that best 472 indicates the nature of the error encountered. 474 The diagnosticMessage field of this construct may, at the server's 475 option, be used to return a string containing a textual, human- 476 readable (terminal control and page formatting characters should be 477 avoided) diagnostic message. As this diagnostic message is not 478 standardized, implementations MUST NOT rely on the values returned. 480 Lightweight Directory Access Protocol Version 3 482 If the server chooses not to return a textual diagnostic, the 483 diagnosticMessage field MUST be empty. 485 For certain result codes (typically, but not restricted to 486 noSuchObject, aliasProblem, invalidDNSyntax and 487 aliasDereferencingProblem), the matchedDN field is set to the name of 488 the lowest entry (object or alias) in the Directory that was matched. 489 If no aliases were dereferenced while attempting to locate the entry, 490 this will be a truncated form of the name provided, or if aliases 491 were dereferenced, of the resulting name, as defined in section 12.5 492 of [X.511]. Otherwise the matchedDN field is empty. 494 4.1.10. Referral 496 The referral result code indicates that the contacted server does not 497 hold the target entry of the request. The referral field is present 498 in an LDAPResult if the resultCode field value is referral, and 499 absent with all other result codes. It contains one or more 500 references to one or more servers or services that may be accessed 501 via LDAP or other protocols. Referrals can be returned in response to 502 any operation request (except unbind and abandon which do not have 503 responses). At least one URI MUST be present in the Referral. 505 During a search operation, after the baseObject is located, and 506 entries are being evaluated, the referral is not returned. Instead, 507 continuation references, described in section 4.5.3, are returned 508 when the search scope spans multiple naming contexts, and several 509 different servers would need to be contacted to complete the 510 operation. 512 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 514 URI ::= LDAPString -- limited to characters permitted in 515 -- URIs 517 If the client wishes to progress the operation, it MUST follow the 518 referral by contacting one of the services. If multiple URIs are 519 present, the client assumes that any URI may be used to progress the 520 operation. 522 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 523 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 525 When an LDAP URL is used, the following instructions are followed: 526 - If an alias was dereferenced, the part of the URL MUST be 527 present, with the new target object name. Note that UTF-8 528 characters appearing in a DN or search filter may not be legal 529 for URLs (e.g. spaces) and MUST be escaped using the % method in 530 [URI]. 531 - If the part is present, the client MUST use this name in 532 its next request to progress the operation, and if it is not 533 present the client will use the same name as in the original 534 request. 536 Lightweight Directory Access Protocol Version 3 538 - Some servers (e.g. participating in distributed indexing) may 539 provide a different filter in a URL of a referral for a search 540 operation. 541 - If the part of the LDAP URL is present, the client MUST 542 use this filter in its next request to progress this search, and 543 if it is not present the client MUST use the same filter as it 544 used for that search. 545 - Other aspects of the new request may be the same as or different 546 from the request which generated the referral. 548 Other kinds of URIs may be returned, so long as the operation could 549 be performed using that protocol. The definition of such URIs and 550 instructions on their use is left to future specifications. 552 4.1.11. Controls 554 A control is a way to specify extension information for an LDAP 555 message. A control only alters the semantics of the message it is 556 attached to. 558 Controls ::= SEQUENCE OF control Control 560 Control ::= SEQUENCE { 561 controlType LDAPOID, 562 criticality BOOLEAN DEFAULT FALSE, 563 controlValue OCTET STRING OPTIONAL } 565 The controlType field is the UTF-8 encoded dotted-decimal 566 representation of an OBJECT IDENTIFIER which uniquely identifies the 567 control, or the request control and its paired response control. This 568 prevents conflicts between control names. 570 The criticality field is either TRUE or FALSE and only applies to 571 request messages that have a corresponding response message. For all 572 other messages (such as abandonRequest, unbindRequest and all 573 response messages), the criticality field SHOULD be FALSE. 575 If the server recognizes the control type and it is appropriate for 576 the operation, the server will make use of the control when 577 performing the operation. 579 If the server does not recognize the control type or it is not 580 appropriate for the operation, and the criticality field is TRUE, the 581 server MUST NOT perform the operation, and for operations that have a 582 response, MUST set the resultCode to unavailableCriticalExtension. 584 If the control is unrecognized or inappropriate but the criticality 585 field is FALSE, the server MUST ignore the control. 587 The controlValue contains any information associated with the 588 control. Its format is defined by the specification of the control. 589 Implementations MUST be prepared to handle arbitrary contents of the 590 controlValue octet string, including zero bytes. It is absent only if 591 Lightweight Directory Access Protocol Version 3 593 there is no value information which is associated with a control of 594 its type. controlValues that are defined in terms of ASN.1 and BER 595 encoded according to Section 5.1, also follow the extensibility rules 596 in Section 4. 598 Servers list the controlType of all request controls they recognize 599 in the supportedControl attribute [Models] in the root DSE. 601 Controls SHOULD NOT be combined unless the semantics of the 602 combination has been specified. The semantics of control 603 combinations, if specified, are generally found in the control 604 specification most recently published. In the absence of combination 605 semantics, the behavior of the operation is undefined. 606 Additionally, unless order-dependent semantics are given in a 607 specification, the order of a combination of controls in the SEQUENCE 608 is ignored. 610 This document does not specify any controls. Controls may be 611 specified in other documents. The specification of a control consists 612 of: 614 - the OBJECT IDENTIFIER assigned to the control, 616 - whether the control is always non critical, always critical, or 617 optionally critical, 619 - whether there is information associated with the control, and if 620 so, the format of the controlValue contents, 622 - the semantics of the control, and 624 - optionally, semantics regarding the combination of the control 625 with other controls. 627 4.2. Bind Operation 629 The function of the Bind Operation is to allow authentication 630 information to be exchanged between the client and server. 631 Authentication and security-related semantics of this operation are 632 given in [AuthMeth]. 634 The Bind Request is defined as follows: 636 BindRequest ::= [APPLICATION 0] SEQUENCE { 637 version INTEGER (1 .. 127), 638 name LDAPDN, 639 authentication AuthenticationChoice } 641 AuthenticationChoice ::= CHOICE { 642 simple [0] OCTET STRING, 643 -- 1 and 2 reserved 644 sasl [3] SaslCredentials, 645 ... } 646 Lightweight Directory Access Protocol Version 3 648 SaslCredentials ::= SEQUENCE { 649 mechanism LDAPString, 650 credentials OCTET STRING OPTIONAL } 652 Parameters of the Bind Request are: 654 - version: A version number indicating the version of the protocol 655 to be used in this protocol association. This document describes 656 version 3 of the LDAP protocol. Note that there is no version 657 negotiation. The client sets this parameter to the version it 658 desires. If the server does not support the specified version, it 659 MUST respond with protocolError in the resultCode field of the 660 BindResponse. 662 - name: The name of the Directory object that the client wishes to 663 bind as. This field may take on a null value (a zero length 664 string) for the purposes of anonymous binds ([AuthMeth] section 7) 665 or when using Simple Authentication and Security Layer [SASL] 666 authentication ([AuthMeth] section 4.3). Server behavior is 667 undefined when the name is a null value, simple authentication is 668 used, and a password is specified. The server SHALL NOT perform 669 alias dereferencing in determining the object to bind as. 671 - authentication: information used to authenticate the name, if any, 672 provided in the Bind Request. This type is extensible as defined 673 in Section 3.6 of [LDAPIANA]. Servers that do not support a choice 674 supplied by a client will return authMethodNotSupported in the 675 resultCode field of the BindResponse. 676 The simple form of an AuthenticationChoice specifies a simple 677 password to be used for authentication. Passwords consisting of 678 character data (text passwords) SHALL be transferred as [UTF-8] 679 encoded [Unicode]. Prior to transfer, clients SHOULD prepare text 680 passwords by applying the [SASLprep] profile of the [Stringprep] 681 algorithm. Passwords consisting of other data (such as random 682 octets) MUST NOT be altered. 684 Authorization is the use of this authentication information when 685 performing operations. Authorization MAY be affected by factors 686 outside of the LDAP Bind Request, such as those provided by lower 687 layer security services. 689 4.2.1. Processing of the Bind Request 691 Before processing a BindResponse, all outstanding operations MUST 692 either complete or be abandoned. The server may either wait for the 693 outstanding operations to complete, or abandon them. The server then 694 proceeds to authenticate the client in either a single-step, or 695 multi-step bind process. Each step requires the server to return a 696 BindResponse to indicate the status of authentication. 698 If the client did not bind before sending a request and receives an 699 operationsError to that request, it may then send a Bind Request. If 700 Lightweight Directory Access Protocol Version 3 702 this also fails or the client chooses not to bind on the existing 703 connection, it may close the connection, reopen it and begin again by 704 first sending a PDU with a Bind Request. This will aid in 705 interoperating with servers implementing other versions of LDAP. 707 Clients may send multiple Bind Requests on a connection to change the 708 authentication and/or security associations or to complete a multi- 709 stage bind process. Authentication from earlier binds is subsequently 710 ignored. 712 For some SASL authentication mechanisms, it may be necessary for the 713 client to invoke the BindRequest multiple times. This is indicated by 714 the server sending a BindResponse with the resultCode set to 715 saslBindInProgress. This indicates that the server requires the 716 client to send a new bind request, with the same sasl mechanism, to 717 continue the authentication process. If at any stage the client 718 wishes to abort the bind process it MAY unbind and then drop the 719 underlying connection. Clients MUST NOT invoke operations between two 720 Bind Requests made as part of a multi-stage bind. 722 A client may abort a SASL bind negotiation by sending a BindRequest 723 with a different value in the mechanism field of SaslCredentials, or 724 an AuthenticationChoice other than sasl. 726 If the client sends a BindRequest with the sasl mechanism field as an 727 empty string, the server MUST return a BindResponse with 728 authMethodNotSupported as the resultCode. This will allow clients to 729 abort a negotiation if it wishes to try again with the same SASL 730 mechanism. 732 A failed Bind Operation has the effect of leaving the connection in 733 an anonymous state. An abandoned Bind operation also has the effect 734 of leaving the connection in an anonymous state when (and if) the 735 server processes the abandonment of the bind. Client implementers 736 should note that the client has no way of being sure when (or if) an 737 abandon request succeeds, therefore, to arrive at a known 738 authentication state after abandoning a bind operation, clients may 739 either unbind (which results in the underlying connection being 740 closed) or by issuing a bind request and then examining the 741 BindResponse returned by the server. 743 4.2.2. Bind Response 745 The Bind Response is defined as follows. 747 BindResponse ::= [APPLICATION 1] SEQUENCE { 748 COMPONENTS OF LDAPResult, 749 serverSaslCreds [7] OCTET STRING OPTIONAL } 751 BindResponse consists simply of an indication from the server of the 752 status of the client's request for authentication. 754 A successful bind operation is indicated by a BindResponse with a 755 resultCode set to success. Otherwise, an appropriate result code is 756 Lightweight Directory Access Protocol Version 3 758 set in the BindResponse. For bind, the protocolError result code may 759 be used to indicate that the version number supplied by the client is 760 unsupported. 762 If the client receives a BindResponse response where the resultCode 763 field is protocolError, it MUST close the connection as the server 764 will be unwilling to accept further operations. (This is for 765 compatibility with earlier versions of LDAP, in which the bind was 766 always the first operation, and there was no negotiation.) 768 The serverSaslCreds are used as part of a SASL-defined bind mechanism 769 to allow the client to authenticate the server to which it is 770 communicating, or to perform "challenge-response" authentication. If 771 the client bound with the simple choice, or the SASL mechanism does 772 not require the server to return information to the client, then this 773 field SHALL NOT be included in the BindResponse. 775 4.3. Unbind Operation 777 The function of the Unbind Operation is to terminate an LDAP 778 association and connection. The Unbind Operation is defined as 779 follows: 781 UnbindRequest ::= [APPLICATION 2] NULL 783 The Unbind Operation has no response defined. Upon transmission of 784 the UnbindRequest, each protocol peer is to consider the LDAP 785 association terminated, MUST cease transmission of messages to the 786 other peer, and MUST close the connection. Any outstanding operations 787 on the server are, when possible, abandoned, and when not possible, 788 completed without transmission of the response. 790 4.4. Unsolicited Notification 792 An unsolicited notification is an LDAPMessage sent from the server to 793 the client which is not in response to any LDAPMessage received by 794 the server. It is used to signal an extraordinary condition in the 795 server or in the connection between the client and the server. The 796 notification is of an advisory nature, and the server will not expect 797 any response to be returned from the client. 799 The unsolicited notification is structured as an LDAPMessage in which 800 the messageID is zero and protocolOp is of the extendedResp form. The 801 responseName field of the ExtendedResponse always contains an LDAPOID 802 which is unique for this notification. 804 One unsolicited notification (Notice of Disconnection) is defined in 805 this document. 807 4.4.1. Notice of Disconnection 808 Lightweight Directory Access Protocol Version 3 810 This notification may be used by the server to advise the client that 811 the server is about to close the connection due to an error 812 condition. Note that this notification is NOT a response to an unbind 813 requested by the client: the server MUST follow the procedures of 814 section 4.3. This notification is intended to assist clients in 815 distinguishing between an error condition and a transient network 816 failure. As with a connection close due to network failure, the 817 client MUST NOT assume that any outstanding requests which modified 818 the Directory have succeeded or failed. 820 The responseName is 1.3.6.1.4.1.1466.20036, the response field is 821 absent, and the resultCode is used to indicate the reason for the 822 disconnection. 824 The following result codes have these meanings when used in this 825 notification: 827 - protocolError: The server has received data from the client in 828 which the LDAPMessage structure could not be parsed. 830 - strongAuthRequired: The server has detected that an established 831 security association between the client and server has 832 unexpectedly failed or been compromised, or that the server now 833 requires the client to authenticate using a strong(er) mechanism. 835 - unavailable: This server will stop accepting new connections and 836 operations on all existing connections, and be unavailable for an 837 extended period of time. The client may make use of an alternative 838 server. 840 Upon transmission of the UnbindRequest, each protocol peer is to 841 consider the LDAP association terminated, MUST cease transmission of 842 messages to the other peer, and MUST close the connection. 844 4.5. Search Operation 846 The Search Operation is used to request a server to return, subject 847 to access controls and other restrictions, a set of entries matching 848 a complex search criterion. This can be used to read attributes from 849 a single entry, from entries immediately subordinate to a particular 850 entry, or a whole subtree of entries. 852 4.5.1. Search Request 854 The Search Request is defined as follows: 856 SearchRequest ::= [APPLICATION 3] SEQUENCE { 857 baseObject LDAPDN, 858 scope ENUMERATED { 859 baseObject (0), 860 singleLevel (1), 861 wholeSubtree (2) }, 862 Lightweight Directory Access Protocol Version 3 864 derefAliases ENUMERATED { 865 neverDerefAliases (0), 866 derefInSearching (1), 867 derefFindingBaseObj (2), 868 derefAlways (3) }, 869 sizeLimit INTEGER (0 .. maxInt), 870 timeLimit INTEGER (0 .. maxInt), 871 typesOnly BOOLEAN, 872 filter Filter, 873 attributes AttributeSelection } 875 AttributeSelection ::= SEQUENCE OF selection LDAPString 876 -- constrained to the ABNF below 878 Filter ::= CHOICE { 879 and [0] SET SIZE (1..MAX) OF filter Filter, 880 or [1] SET SIZE (1..MAX) OF filter Filter, 881 not [2] Filter, 882 equalityMatch [3] AttributeValueAssertion, 883 substrings [4] SubstringFilter, 884 greaterOrEqual [5] AttributeValueAssertion, 885 lessOrEqual [6] AttributeValueAssertion, 886 present [7] AttributeDescription, 887 approxMatch [8] AttributeValueAssertion, 888 extensibleMatch [9] MatchingRuleAssertion } 890 SubstringFilter ::= SEQUENCE { 891 type AttributeDescription, 892 -- at least one must be present, 893 -- initial and final can occur at most once 894 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 895 initial [0] AssertionValue, 896 any [1] AssertionValue, 897 final [2] AssertionValue } } 899 MatchingRuleAssertion ::= SEQUENCE { 900 matchingRule [1] MatchingRuleId OPTIONAL, 901 type [2] AttributeDescription OPTIONAL, 902 matchValue [3] AssertionValue, 903 dnAttributes [4] BOOLEAN DEFAULT FALSE } 905 Parameters of the Search Request are: 907 - baseObject: The name of the base object entry relative to which 908 the search is to be performed. 910 - scope: Specifies the scope of the search to be performed. The 911 semantics (as described in [X.511]) of the possible values of this 912 field are: 914 baseObject: The scope is constrained to the entry named by 915 baseObject. 917 Lightweight Directory Access Protocol Version 3 919 oneLevel: The scope is constrained to the immediate 920 subordinates of the entry named by baseObject. 922 wholeSubtree: the scope is constrained to the entry named 923 by the baseObject, and all its subordinates. 925 - derefAliases: An indicator as to how alias objects (as defined in 926 [X.501]) are to be handled in searching. The semantics of the 927 possible values of this field are: 929 neverDerefAliases: Do not dereference aliases in searching 930 or in locating the base object of the search. 932 derefInSearching: While searching, dereference any alias 933 object subordinate to the base object which is also in the 934 search scope. The filter is applied to the dereferenced 935 object(s). If the search scope is wholeSubtree, the search 936 continues in the subtree of any dereferenced object. 937 Aliases in that subtree are also dereferenced. Servers 938 SHOULD detect looping in this process to prevent denial of 939 service attacks and duplicate entries. 941 derefFindingBaseObj: Dereference aliases in locating the 942 base object of the search, but not when searching 943 subordinates of the base object. 945 derefAlways: Dereference aliases both in searching and in 946 locating the base object of the search. 948 - sizeLimit: A size limit that restricts the maximum number of 949 entries to be returned as a result of the search. A value of 0 in 950 this field indicates that no client-requested size limit 951 restrictions are in effect for the search. Servers may enforce a 952 maximum number of entries to return. 954 - timeLimit: A time limit that restricts the maximum time (in 955 seconds) allowed for a search. A value of 0 in this field 956 indicates that no client-requested time limit restrictions are in 957 effect for the search. Servers may enforce a maximum time limit 958 for the search. 960 - typesOnly: An indicator as to whether search results are to 961 contain both attribute descriptions and values, or just attribute 962 descriptions. Setting this field to TRUE causes only attribute 963 descriptions (no values) to be returned. Setting this field to 964 FALSE causes both attribute descriptions and values to be 965 returned. 967 - filter: A filter that defines the conditions that must be 968 fulfilled in order for the search to match a given entry. 970 The 'and', 'or' and 'not' choices can be used to form combinations 971 of filters. At least one filter element MUST be present in an 972 Lightweight Directory Access Protocol Version 3 974 'and' or 'or' choice. The others match against individual 975 attribute values of entries in the scope of the search. 976 (Implementor's note: the 'not' filter is an example of a tagged 977 choice in an implicitly-tagged module. In BER this is treated as 978 if the tag was explicit.) 980 A server MUST evaluate filters according to the three-valued logic 981 of X.511 (1993) section 7.8.1. In summary, a filter is evaluated 982 to either "TRUE", "FALSE" or "Undefined". If the filter evaluates 983 to TRUE for a particular entry, then the attributes of that entry 984 are returned as part of the search result (subject to any 985 applicable access control restrictions). If the filter evaluates 986 to FALSE or Undefined, then the entry is ignored for the search. 988 A filter of the "and" choice is TRUE if all the filters in the SET 989 OF evaluate to TRUE, FALSE if at least one filter is FALSE, and 990 otherwise Undefined. A filter of the "or" choice is FALSE if all 991 of the filters in the SET OF evaluate to FALSE, TRUE if at least 992 one filter is TRUE, and Undefined otherwise. A filter of the "not" 993 choice is TRUE if the filter being negated is FALSE, FALSE if it 994 is TRUE, and Undefined if it is Undefined. 996 The present match evaluates to TRUE where there is an attribute or 997 subtype of the specified attribute description present in an 998 entry, and FALSE otherwise (including a presence test with an 999 unrecognized attribute description.) 1001 The matching rule for equalityMatch filter items is defined by the 1002 EQUALITY matching rule for the attribute type. 1004 The matching rule for AssertionValues in a substrings filter item 1005 is defined by the SUBSTR matching rule for the attribute type. 1006 Note that the AssertionValue in a substrings filter item MUST 1007 conform to the assertion syntax of the EQUALITY matching rule for 1008 the attribute type rather than the assertion syntax of the SUBSTR 1009 matching rule for the attribute type. The entire SubstringFilter 1010 is converted into an assertion value of the substrings matching 1011 rule prior to applying the rule. 1013 The matching rule for greaterOrEqual and lessOrEqual filter items 1014 is defined by the ORDERING matching rule for the attribute type. 1016 The approxMatch evaluates to TRUE when there is a value of the 1017 attribute or subtype for which some locally-defined approximate 1018 matching algorithm (e.g. spelling variations, phonetic match, 1019 etc.) returns TRUE. If an item matches for equality, it also 1020 satisfies an approximate match. If approximate matching is not 1021 supported, this filter item should be treated as an equalityMatch. 1023 An extensibleMatch is evaluated as follows: 1025 If the matchingRule field is absent, the type field MUST be 1026 present, and an equality match is performed for that type. 1028 Lightweight Directory Access Protocol Version 3 1030 If the type field is absent and the matchingRule is present, the 1031 matchValue is compared against all attributes in an entry which 1032 support that matchingRule. The matchingRule determines the 1033 syntax for the assertion value. The filter item evaluates to 1034 TRUE if it matches with at least one attribute in the entry, 1035 FALSE if it does not match any attribute in the entry, and 1036 Undefined if the matchingRule is not recognized or the 1037 assertionValue is invalid. 1039 If the type field is present and the matchingRule is present, 1040 the matchValue is compared against entry attributes of the 1041 specified type. In this case, the matchingRule MUST be one 1042 suitable for use with the specified type (see [Syntaxes]), 1043 otherwise the filter item is undefined. 1045 If the dnAttributes field is set to TRUE, the match is 1046 additionally applied against all the AttributeValueAssertions in 1047 an entry's distinguished name, and evaluates to TRUE if there is 1048 at least one attribute in the distinguished name for which the 1049 filter item evaluates to TRUE. The dnAttributes field is present 1050 to alleviate the need for multiple versions of generic matching 1051 rules (such as word matching), where one applies to entries and 1052 another applies to entries and dn attributes as well. 1054 A filter item evaluates to Undefined when the server would not be 1055 able to determine whether the assertion value matches an entry. If 1056 an attribute description in an equalityMatch, substrings, 1057 greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter 1058 is not recognized by the server, a matching rule id in the 1059 extensibleMatch is not recognized by the server, the assertion 1060 value is invalid, or the type of filtering requested is not 1061 implemented, then the filter is Undefined. Thus for example if a 1062 server did not recognize the attribute type shoeSize, a filter of 1063 (shoeSize=*) would evaluate to FALSE, and the filters 1064 (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to 1065 Undefined. 1067 Servers MUST NOT return errors if attribute descriptions or 1068 matching rule ids are not recognized, assertion values are 1069 invalid, or the assertion syntax is not supported. More details of 1070 filter processing are given in section 7.8 of [X.511]. 1072 - attributes: A list of the attributes to be returned from each 1073 entry which matches the search filter. LDAPString values of this 1074 field are constrained to the following ABNF: 1076 attributeSelection = noattrs / 1077 *( attributedescription / specialattr ) 1079 noattrs = %x31 %x2E %x31 ; "1.1" 1081 specialattr = ASTERISK 1083 ASTERISK = %x2A ; asterisk ("*") 1084 Lightweight Directory Access Protocol Version 3 1086 is defined in Section 2.5 of [Models]. 1088 There are two special values which may be used: an empty list with 1089 no attributes, and the attribute description string "*". Both of 1090 these signify that all user attributes are to be returned. (The 1091 "*" allows the client to request all user attributes in addition 1092 to any specified operational attributes). Client implementors 1093 should note that even if all user attributes are requested, some 1094 attributes and or attribute values of the entry may not be 1095 included in search results due to access controls or other 1096 restrictions. Furthermore, servers will not return operational 1097 attributes, such as objectClasses or attributeTypes, unless they 1098 are listed by name. Operational attributes are described in 1099 [Models]. 1101 Attributes MUST NOT be named more than once in the list, and are 1102 returned at most once in an entry. If there are attribute 1103 descriptions in the list which are not recognized, they are 1104 ignored by the server. 1106 If the client does not want any attributes returned, it can 1107 specify a list containing only the attribute with OID "1.1". This 1108 OID was chosen because it does not (and can not) correspond to any 1109 attribute in use. 1111 Note that an X.500 "list"-like operation can be emulated by the 1112 client requesting a one-level LDAP search operation with a filter 1113 checking for the presence of the objectClass attribute, and that an 1114 X.500 "read"-like operation can be emulated by a base object LDAP 1115 search operation with the same filter. A server which provides a 1116 gateway to X.500 is not required to use the Read or List operations, 1117 although it may choose to do so, and if it does, it must provide the 1118 same semantics as the X.500 search operation. 1120 4.5.2. Search Result 1122 The results of the search operation are returned as zero or more 1123 searchResultEntry messages, zero or more SearchResultReference 1124 messages, followed by a single searchResultDone message. 1126 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 1127 objectName LDAPDN, 1128 attributes PartialAttributeList } 1130 PartialAttributeList ::= SEQUENCE OF 1131 attribute PartialAttribute 1132 -- Note that the PartialAttributeList may hold zero elements. 1133 -- This may happen when none of the attributes of an entry 1134 -- were requested, or could be returned. 1136 PartialAttribute ::= SEQUENCE { 1137 type AttributeDescription, 1138 Lightweight Directory Access Protocol Version 3 1140 vals SET OF value AttributeValue } 1141 -- Note that the vals set may hold zero elements. 1142 -- This may happen when typesOnly is requested, access controls 1143 -- prevent the return of values, or other reasons. 1145 SearchResultReference ::= [APPLICATION 19] SEQUENCE 1146 SIZE (1..MAX) OF uri URI 1148 SearchResultDone ::= [APPLICATION 5] LDAPResult 1150 Each SearchResultEntry represents an entry found during the search. 1151 Each SearchResultReference represents an area not yet explored during 1152 the search. The SearchResultEntry and SearchResultReference PDUs may 1153 come in any order. Following all the SearchResultReference and 1154 SearchResultEntry responses, the server returns a SearchResultDone 1155 response, which contains an indication of success, or detailing any 1156 errors that have occurred. 1158 Each entry returned in a SearchResultEntry will contain all 1159 appropriate attributes as specified in the attributes field of the 1160 Search Request. Return of attributes is subject to access control and 1161 other administrative policy. 1163 Some attributes may be constructed by the server and appear in a 1164 SearchResultEntry attribute list, although they are not stored 1165 attributes of an entry. Clients SHOULD NOT assume that all attributes 1166 can be modified, even if permitted by access control. 1168 If the server's schema defines short names [Models] for an attribute 1169 type then the server SHOULD use one of those names in attribute 1170 descriptions for that attribute type (in preference to using the 1171 [Models] format of the attribute type's object 1172 identifier). The server SHOULD NOT use the short name if that name is 1173 known by the server to be ambiguous, or otherwise likely to cause 1174 interoperability problems. 1176 4.5.3. Continuation References in the Search Result 1178 If the server was able to locate the entry referred to by the 1179 baseObject but was unable to search all the entries in the scope at 1180 and subordinate to the baseObject, the server may return one or more 1181 SearchResultReference entries, each containing a reference to another 1182 set of servers for continuing the operation. A server MUST NOT return 1183 any SearchResultReference if it has not located the baseObject and 1184 thus has not searched any entries; in this case it would return a 1185 SearchResultDone containing a referral result code. 1187 If a server holds a copy or partial copy of the subordinate naming 1188 context, it may use the search filter to determine whether or not to 1189 return a SearchResultReference response. Otherwise 1190 SearchResultReference responses are always returned when in scope. 1192 The SearchResultReference is of the same data type as the Referral. 1194 Lightweight Directory Access Protocol Version 3 1196 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 1197 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 1199 When an LDAP URL is used, the following instructions are followed: 1200 - The part of the URL MUST be present, with the new target 1201 object name. The client MUST use this name when following the 1202 referral. Note that UTF-8 characters appearing in a DN or search 1203 filter may not be legal for URLs (e.g. spaces) and MUST be 1204 escaped using the % method in [URI]. 1205 - Some servers (e.g. participating in distributed indexing) may 1206 provide a different filter in a URL of a SearchResultReference. 1207 - If the part of the URL is present, the client MUST use 1208 this filter in its next request to progress this search, and if 1209 it is not present the client MUST use the same filter as it used 1210 for that search. 1211 - If the originating search scope was singleLevel, the 1212 part of the URL will be "base". 1213 - Other aspects of the new search request may be the same as or 1214 different from the search request which generated the 1215 SearchResultReference. 1216 - The name of an unexplored subtree in a SearchResultReference 1217 need not be subordinate to the base object. 1219 Other kinds of URIs may be returned, so long as the operation could 1220 be performed using that protocol. The definition of such URIs and 1221 instructions on their use is left to future specifications. 1223 In order to complete the search, the client issues a new search 1224 operation for each SearchResultReference that is returned. Note that 1225 the abandon operation described in section 4.11 applies only to a 1226 particular operation sent on an association between a client and 1227 server. The client must abandon subsequent search operations it 1228 wishes to individually. 1230 4.5.3.1. Example 1232 For example, suppose the contacted server (hosta) holds the entry 1233 "DC=Example,DC=NET" and the entry "CN=Manager,DC=Example,DC=NET". It 1234 knows that either LDAP-capable servers (hostb) or (hostc) hold 1235 "OU=People,DC=Example,DC=NET" (one is the master and the other server 1236 a shadow), and that LDAP-capable server (hostd) holds the subtree 1237 "OU=Roles,DC=Example,DC=NET". If a subtree search of 1238 "DC=Example,DC=NET" is requested to the contacted server, it may 1239 return the following: 1241 SearchResultEntry for DC=Example,DC=NET 1242 SearchResultEntry for CN=Manager,DC=Example,DC=NET 1243 SearchResultReference { 1244 ldap://hostb/OU=People,DC=Example,DC=NET 1245 ldap://hostc/OU=People,DC=Example,DC=NET } 1246 SearchResultReference { 1247 ldap://hostd/OU=Roles,DC=Example,DC=NET } 1248 Lightweight Directory Access Protocol Version 3 1250 SearchResultDone (success) 1252 Client implementors should note that when following a 1253 SearchResultReference, additional SearchResultReference may be 1254 generated. Continuing the example, if the client contacted the server 1255 (hostb) and issued the search for the subtree 1256 "OU=People,DC=Example,DC=NET", the server might respond as follows: 1258 SearchResultEntry for OU=People,DC=Example,DC=NET 1259 SearchResultReference { 1260 ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET } 1261 SearchResultReference { 1262 ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET } 1263 SearchResultDone (success) 1265 If the contacted server does not hold the base object for the search, 1266 then it will return a referral to the client. For example, if the 1267 client requests a subtree search of "DC=Example,DC=ORG" to hosta, the 1268 server may return only a SearchResultDone containing a referral. 1270 SearchResultDone (referral) { 1271 ldap://hostg/DC=Example,DC=ORG??sub } 1273 4.6. Modify Operation 1275 The Modify Operation allows a client to request that a modification 1276 of an entry be performed on its behalf by a server. The Modify 1277 Request is defined as follows: 1279 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1280 object LDAPDN, 1281 changes SEQUENCE OF change SEQUENCE { 1282 operation ENUMERATED { 1283 add (0), 1284 delete (1), 1285 replace (2) }, 1286 modification PartialAttribute } } 1288 Parameters of the Modify Request are: 1290 - object: The name of the object to be modified. The value of this 1291 field contains the DN of the entry to be modified. The server 1292 SHALL NOT perform any alias dereferencing in determining the 1293 object to be modified. 1295 - changes: A list of modifications to be performed on the entry. The 1296 entire list of modifications MUST be performed in the order they 1297 are listed, as a single atomic operation. While individual 1298 modifications may violate certain aspects of the directory schema 1299 (such as the object class definition and DIT content rule), the 1300 resulting entry after the entire list of modifications is 1301 performed MUST conform to the requirements of the directory 1302 schema. 1304 Lightweight Directory Access Protocol Version 3 1306 - operation: Used to specify the type of modification being 1307 performed. Each operation type acts on the following 1308 modification. The values of this field have the following 1309 semantics respectively: 1311 add: add values listed to the modification attribute, 1312 creating the attribute if necessary; 1314 delete: delete values listed from the modification 1315 attribute, removing the entire attribute if no values are 1316 listed, or if all current values of the attribute are 1317 listed for deletion; 1319 replace: replace all existing values of the modification 1320 attribute with the new values listed, creating the 1321 attribute if it did not already exist. A replace with no 1322 value will delete the entire attribute if it exists, and is 1323 ignored if the attribute does not exist. 1325 - modification: A PartialAttribute (which may have an empty SET of 1326 vals) used to hold the attribute type or attribute type and 1327 values being modified. 1329 Upon receipt of a Modify Request, the server attempts to perform the 1330 necessary modifications to the DIT and returns the result in a Modify 1331 Response, defined as follows: 1333 ModifyResponse ::= [APPLICATION 7] LDAPResult 1335 The server will return to the client a single Modify Response 1336 indicating either the successful completion of the DIT modification, 1337 or the reason that the modification failed. Note that due to the 1338 requirement for atomicity in applying the list of modifications in 1339 the Modify Request, the client may expect that no modifications of 1340 the DIT have been performed if the Modify Response received indicates 1341 any sort of error, and that all requested modifications have been 1342 performed if the Modify Response indicates successful completion of 1343 the Modify Operation. If the association changes or the connection 1344 fails, whether the modification occurred or not is indeterminate. 1346 The Modify Operation cannot be used to remove from an entry any of 1347 its distinguished values, i.e. those values which form the entry's 1348 relative distinguished name. An attempt to do so will result in the 1349 server returning the notAllowedOnRDN result code. The Modify DN 1350 Operation described in section 4.9 is used to rename an entry. 1352 Note that due to the simplifications made in LDAP, there is not a 1353 direct mapping of the changes in an LDAP ModifyRequest onto the 1354 changes of a DAP ModifyEntry operation, and different implementations 1355 of LDAP-DAP gateways may use different means of representing the 1356 change. If successful, the final effect of the operations on the 1357 entry MUST be identical. 1359 Lightweight Directory Access Protocol Version 3 1361 4.7. Add Operation 1363 The Add Operation allows a client to request the addition of an entry 1364 into the Directory. The Add Request is defined as follows: 1366 AddRequest ::= [APPLICATION 8] SEQUENCE { 1367 entry LDAPDN, 1368 attributes AttributeList } 1370 AttributeList ::= SEQUENCE OF attribute Attribute 1372 Parameters of the Add Request are: 1374 - entry: the name of the entry to be added. Note that the server 1375 SHALL NOT dereference any aliases in locating the entry to be 1376 added. 1378 - attributes: the list of attributes that make up the content of the 1379 entry being added. Clients MUST include distinguished values 1380 (those forming the entry's own RDN) in this list, the objectClass 1381 attribute, and values of any mandatory attributes of the listed 1382 object classes. Clients MUST NOT supply NO-USER-MODIFICATION 1383 attributes such as the createTimestamp or creatorsName attributes, 1384 since the server maintains these automatically. 1386 The entry named in the entry field of the AddRequest MUST NOT exist 1387 for the AddRequest to succeed. The immediate superior (parent) of an 1388 object or alias entry to be added MUST exist. For example, if the 1389 client attempted to add "CN=JS,DC=Example,DC=NET", the 1390 "DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did 1391 exist, then the server would return the noSuchObject result code with 1392 the matchedDN field containing "DC=NET". If the parent entry exists 1393 but is not in a naming context held by the server, the server SHOULD 1394 return a referral to the server holding the parent entry. 1396 Server implementations SHOULD NOT restrict where entries can be 1397 located in the Directory unless DIT structure rules are in place. 1398 Some servers allow the administrator to restrict the classes of 1399 entries which can be added to the Directory. 1401 Upon receipt of an Add Request, a server will attempt to add the 1402 requested entry. The result of the add attempt will be returned to 1403 the client in the Add Response, defined as follows: 1405 AddResponse ::= [APPLICATION 9] LDAPResult 1407 A response of success indicates that the new entry is present in the 1408 Directory. 1410 4.8. Delete Operation 1411 Lightweight Directory Access Protocol Version 3 1413 The Delete Operation allows a client to request the removal of an 1414 entry from the Directory. The Delete Request is defined as follows: 1416 DelRequest ::= [APPLICATION 10] LDAPDN 1418 The Delete Request consists of the name of the entry to be deleted. 1419 The server SHALL NOT dereference aliases while resolving the name of 1420 the target entry to be removed. 1422 Only leaf entries (those with no subordinate entries) can be deleted 1423 with this operation. 1425 Upon receipt of a Delete Request, a server will attempt to perform 1426 the entry removal requested and return the result in the Delete 1427 Response defined as follows: 1429 DelResponse ::= [APPLICATION 11] LDAPResult 1431 4.9. Modify DN Operation 1433 The Modify DN Operation allows a client to change the Relative 1434 Distinguished Name (RDN) of an entry in the Directory, and/or to move 1435 a subtree of entries to a new location in the Directory. The Modify 1436 DN Request is defined as follows: 1438 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1439 entry LDAPDN, 1440 newrdn RelativeLDAPDN, 1441 deleteoldrdn BOOLEAN, 1442 newSuperior [0] LDAPDN OPTIONAL } 1444 Parameters of the Modify DN Request are: 1446 - entry: the name of the entry to be changed. This entry may or may 1447 not have subordinate entries. Note that the server SHALL NOT 1448 dereference any aliases in locating the entry to be changed. 1450 - newrdn: the new RDN of the entry. 1452 - deleteoldrdn: a boolean parameter that controls whether the old 1453 RDN attribute values are to be retained as attributes of the 1454 entry, or deleted from the entry. 1456 - newSuperior: if present, this is the name of an existing object 1457 entry which becomes the immediate superior (parent) of the 1458 existing entry. 1460 Upon receipt of a ModifyDNRequest, a server will attempt to perform 1461 the name change and return the result in the Modify DN Response, 1462 defined as follows: 1464 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 1465 Lightweight Directory Access Protocol Version 3 1467 For example, if the entry named in the "entry" parameter was "cn=John 1468 Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the 1469 newSuperior parameter was absent, then this operation would attempt 1470 to rename the entry to be "cn=John Cougar Smith,c=US". If there was 1471 already an entry with that name, the operation would fail with the 1472 entryAlreadyExists result code. 1474 The object named in newSuperior MUST exist. For example, if the 1475 client attempted to add "CN=JS,DC=Example,DC=NET", the 1476 "DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did 1477 exist, then the server would return the noSuchObject result code with 1478 the matchedDN field containing "DC=NET". 1480 If the deleteoldrdn parameter is TRUE, the values forming the old RDN 1481 are deleted from the entry. If the deleteoldrdn parameter is FALSE, 1482 the values forming the old RDN will be retained as non-distinguished 1483 attribute values of the entry. The server MUST fail the operation and 1484 return an error in the result code if the setting of the deleteoldrdn 1485 parameter would cause a schema inconsistency in the entry. 1487 Note that X.500 restricts the ModifyDN operation to only affect 1488 entries that are contained within a single server. If the LDAP server 1489 is mapped onto DAP, then this restriction will apply, and the 1490 affectsMultipleDSAs result code will be returned if this error 1491 occurred. In general, clients MUST NOT expect to be able to perform 1492 arbitrary movements of entries and subtrees between servers or 1493 between naming contexts. 1495 4.10. Compare Operation 1497 The Compare Operation allows a client to compare an assertion 1498 provided with an entry in the Directory. The Compare Request is 1499 defined as follows: 1501 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1502 entry LDAPDN, 1503 ava AttributeValueAssertion } 1505 Parameters of the Compare Request are: 1507 - entry: the name of the entry to be compared. Note that the server 1508 SHALL NOT dereference any aliases in locating the entry to be 1509 compared. 1511 - ava: the assertion with which an attribute in the entry is to be 1512 compared. 1514 Upon receipt of a Compare Request, a server will attempt to perform 1515 the requested comparison using the EQUALITY matching rule for the 1516 attribute type and return the result in the Compare Response, defined 1517 as follows: 1519 CompareResponse ::= [APPLICATION 15] LDAPResult 1520 Lightweight Directory Access Protocol Version 3 1522 In the event that the attribute or subtype is not present in the 1523 entry, the resultCode field is set to noSuchAttribute. If the 1524 attribute is unknown, the resultCode is set to 1525 undefinedAttributeType. Note that errors and the result of comparison 1526 are all returned in the same construct. 1528 Note that some directory systems may establish access controls which 1529 permit the values of certain attributes (such as userPassword) to be 1530 compared but not interrogated by other means. 1532 4.11. Abandon Operation 1534 The function of the Abandon Operation is to allow a client to request 1535 that the server abandon an outstanding operation. The Abandon Request 1536 is defined as follows: 1538 AbandonRequest ::= [APPLICATION 16] MessageID 1540 The MessageID MUST be that of an operation which was requested 1541 earlier in this LDAP association. The abandon request itself has its 1542 own message id. This is distinct from the id of the earlier operation 1543 being abandoned. 1545 There is no response defined in the Abandon operation. Upon receipt 1546 of an AbandonRequest, the server MAY abandon the operation identified 1547 by the MessageID. Operation responses are not sent for successfully 1548 abandoned operations, thus the application of the Abandon operation 1549 is limited to uses where the client does not require an indication of 1550 its outcome. 1552 Abandon and Unbind operations cannot be abandoned. The ability to 1553 abandon other (particularly update) operations is at the discretion 1554 of the server. 1556 In the event that a server receives an Abandon Request on a Search 1557 Operation in the midst of transmitting responses to the search, that 1558 server MUST cease transmitting entry responses to the abandoned 1559 request immediately, and MUST NOT send the SearchResponseDone. Of 1560 course, the server MUST ensure that only properly encoded LDAPMessage 1561 PDUs are transmitted. 1563 Clients MUST NOT send abandon requests for the same operation 1564 multiple times, and MUST also be prepared to receive results from 1565 operations it has abandoned (since these may have been in transit 1566 when the abandon was requested, or are not able to be abandoned). 1568 Servers MUST discard abandon requests for message IDs they do not 1569 recognize, for operations which cannot be abandoned, and for 1570 operations which have already been abandoned. 1572 4.12. Extended Operation 1573 Lightweight Directory Access Protocol Version 3 1575 An extension mechanism has been added in this version of LDAP, in 1576 order to allow additional operations to be defined for services not 1577 available elsewhere in this protocol, for instance digitally signed 1578 operations and results. 1580 The extended operation allows clients to make requests and receive 1581 responses with predefined syntaxes and semantics. These may be 1582 defined in RFCs or be private to particular implementations. Each 1583 request MUST have a unique OBJECT IDENTIFIER assigned to it. 1585 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1586 requestName [0] LDAPOID, 1587 requestValue [1] OCTET STRING OPTIONAL } 1589 The requestName is a dotted-decimal representation of the OBJECT 1590 IDENTIFIER corresponding to the request. The requestValue is 1591 information in a form defined by that request, encapsulated inside an 1592 OCTET STRING. 1594 The server will respond to this with an LDAPMessage containing the 1595 ExtendedResponse. 1597 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 1598 COMPONENTS OF LDAPResult, 1599 responseName [10] LDAPOID OPTIONAL, 1600 responseValue [11] OCTET STRING OPTIONAL } 1602 If the server does not recognize the request name, it MUST return 1603 only the response fields from LDAPResult, containing the 1604 protocolError result code. 1606 The requestValue and responseValue fields contain any information 1607 associated with the operation. The format of these fields is defined 1608 by the specification of the extended operation. Implementations MUST 1609 be prepared to handle arbitrary contents of these fields, including 1610 zero bytes. Values that are defined in terms of ASN.1 and BER encoded 1611 according to Section 5.1, also follow the extensibility rules in 1612 Section 4. 1614 Extended operations may be specified in other documents. The 1615 specification of an extended operation consists of: 1617 - the OBJECT IDENTIFIER assigned to the ExtendedRequest.requestName 1618 (and possibly ExtendedResponse.responseName), 1620 - the format of the contents of the requestValue and responseValue 1621 (if any), 1623 - the semantics of the operation, 1625 It is RECOMMENDED that servers list the requestName of 1626 ExtendedRequests they support in the supportedExtension attribute 1627 [Models] in the root DSE. 1629 Lightweight Directory Access Protocol Version 3 1631 4.13. Start TLS Operation 1633 The Start Transport Layer Security (StartTLS) operation provides the 1634 ability to establish Transport Layer Security [RFC2246] on an LDAP 1635 connection. 1637 4.13.1. Start TLS Request 1639 A client requests TLS establishment by transmitting a Start TLS 1640 request PDU to the server. The Start TLS request is defined in terms 1641 of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", 1642 and the requestValue field is absent. 1644 The client MUST NOT send any PDUs on this connection following this 1645 request until it receives a Start TLS extended response. 1647 4.13.2. Start TLS Response 1649 When a Start TLS request is made, servers supporting the operation 1650 MUST return a Start TLS response PDU to the requestor. The Start TLS 1651 response responseName is also "1.3.6.1.4.1.1466.20037", and the 1652 response field is absent. 1654 The server MUST set the resultCode field to either success or one of 1655 the other values outlined in section 4.13.2.2. 1657 4.13.2.1. "Success" Response 1659 If the Start TLS Response contains a result code of success, this 1660 indicates that the server is willing and able to negotiate TLS. Refer 1661 to section 5.3 of [AuthMeth] for details. 1663 4.13.2.2. Response other than "success" 1665 If the ExtendedResponse contains a result code other than success, 1666 this indicates that the server is unwilling or unable to negotiate 1667 TLS. The following result codes have these meanings for this 1668 operation: 1670 - operationsError: operations sequencing incorrect; e.g. TLS already 1671 established) 1673 - protocolError: (TLS not supported or incorrect PDU structure) 1675 - unavailable: (e.g. some major problem with TLS, or server is 1676 shutting down) 1678 The server MUST return operationsError if the client violates any of 1679 the Start TLS extended operation sequencing requirements described in 1680 section 5.3 of [AuthMeth]. 1682 Lightweight Directory Access Protocol Version 3 1684 If the server does not support TLS (whether by design or by current 1685 configuration), it MUST set the resultCode field to protocolError. 1686 The client's current association is unaffected if the server does not 1687 support TLS. The client may proceed with any LDAP operation, or it 1688 may close the connection. 1690 The server MUST return unavailable if it supports TLS but cannot 1691 establish a TLS connection for some reason, e.g. the certificate 1692 server not responding, it cannot contact its TLS implementation, or 1693 if the server is in process of shutting down. The client may retry 1694 the StartTLS operation, or it may proceed with any other LDAP 1695 operation, or it may close the LDAP connection. 1697 4.13.3. Closing a TLS Connection 1699 Two forms of TLS connection closure -- graceful and abrupt -- are 1700 supported. 1702 4.13.3.1. Graceful Closure 1704 Either the client or server MAY terminate the TLS connection and 1705 leave the LDAP connection intact by sending and receiving a TLS 1706 closure alert. 1708 The initiating protocol peer sends the TLS closure alert. If it 1709 wishes to leave the LDAP connection intact, it then MUST cease to 1710 send further PDUs and MUST ignore any received PDUs until it receives 1711 a TLS closure alert from the other peer. 1713 Once the initiating protocol peer receives a TLS closure alert from 1714 the other peer it MAY send and receive LDAP PDUs. 1716 When a protocol peer receives the initial TLS closure alert, it may 1717 choose to allow the underlying LDAP connection intact. In this case, 1718 it MUST immediately transmit a TLS closure alert. Following this, it 1719 MAY send and receive LDAP PDUs. 1721 Protocol peers MAY drop the underlying LDAP connection after sending 1722 or receiving a TLS closure alert. 1724 After the TLS connection has been closed, the server MUST NOT send 1725 responses to any request message received before the TLS closure. 1726 Thus, clients wishing to receive responses to messages sent while the 1727 TLS connection is intact MUST wait for those message responses before 1728 sending the TLS closure alert. 1730 4.13.3.2. Abrupt Closure 1732 Either the client or server MAY abruptly close the TLS connection by 1733 dropping the underlying transfer protocol connection. In this 1734 circumstance, a server MAY send the client a Notice of Disconnection 1735 before dropping the underlying LDAP connection. 1737 Lightweight Directory Access Protocol Version 3 1739 5. Protocol Element Encodings and Transfer 1741 One underlying service is defined here. Clients and servers SHOULD 1742 implement the mapping of LDAP over [TCP] described in 5.2.1. 1744 5.1. Protocol Encoding 1746 The protocol elements of LDAP are encoded for exchange using the 1747 Basic Encoding Rules [BER] of [ASN.1]. However, due to the high 1748 overhead involved in using certain elements of the BER, the following 1749 additional restrictions are placed on BER-encodings of LDAP protocol 1750 elements: 1752 (1) Only the definite form of length encoding will be used. 1754 (2) OCTET STRING values will be encoded in the primitive form only. 1756 (3) If the value of a BOOLEAN type is true, the encoding MUST have 1757 its contents octets set to hex "FF". 1759 (4) If a value of a type is its default value, it MUST be absent. 1760 Only some BOOLEAN and INTEGER types have default values in this 1761 protocol definition. 1763 These restrictions do not apply to ASN.1 types encapsulated inside of 1764 OCTET STRING values, such as attribute values, unless otherwise 1765 noted. 1767 5.2. Transfer Protocols 1769 This protocol is designed to run over connection-oriented, reliable 1770 transports, with all 8 bits in an octet being significant in the data 1771 stream. 1773 5.2.1. Transmission Control Protocol (TCP) 1775 The encoded LDAPMessage PDUs are mapped directly onto the [TCP] 1776 bytestream using the BER-based encoding described in section 5.1. It 1777 is recommended that server implementations running over the TCP 1778 provide a protocol listener on the assigned port, 389. Servers may 1779 instead provide a listener on a different port number. Clients MUST 1780 support contacting servers on any valid TCP port. 1782 6. Implementation Guidelines 1784 6.1. Server Implementations 1785 Lightweight Directory Access Protocol Version 3 1787 The server MUST be capable of recognizing all the mandatory attribute 1788 types specified in [Models], and implement the syntaxes used by those 1789 attributes specified in [Syntaxes]. Servers MAY also recognize 1790 additional attribute type names. 1792 6.2. Client Implementations 1794 Clients that follow referrals or search continuation references MUST 1795 ensure that they do not loop between servers. They MUST NOT 1796 repeatedly contact the same server for the same request with the same 1797 target entry name, scope and filter. Some clients use a counter that 1798 is incremented each time referral handling occurs for an operation, 1799 and these kinds of clients MUST be able to handle at least ten nested 1800 referrals between the root and a leaf entry. 1802 In the absence of prior agreements with servers, clients SHOULD NOT 1803 assume that servers support any particular schemas beyond those 1804 referenced in section 6.1. Different schemas can have different 1805 attribute types with the same names. The client can retrieve the 1806 subschema entries referenced by the subschemaSubentry attribute in 1807 the entries held by the server. 1809 7. Security Considerations 1811 This version of the protocol provides facilities for simple 1812 authentication using a cleartext password, as well as any [SASL] 1813 mechanism. SASL allows for integrity and privacy services to be 1814 negotiated. 1816 It is also permitted that the server can return its credentials to 1817 the client, if it chooses to do so. 1819 Use of cleartext password is strongly discouraged where the 1820 underlying transport service cannot guarantee confidentiality and may 1821 result in disclosure of the password to unauthorized parties. 1823 Requirements of authentication methods, SASL mechanisms, and TLS are 1824 described in [AUTHMETH]. 1826 When used with SASL, it should be noted that the name field of the 1827 BindRequest is not protected against modification. Thus if the 1828 distinguished name of the client (an LDAPDN) is agreed through the 1829 negotiation of the credentials, it takes precedence over any value in 1830 the unprotected name field. 1832 Server implementors should plan for the possibility of an identity 1833 associated with an LDAP connection being deleted, renamed, or 1834 modified, and take appropriate actions to prevent insecure side 1835 effects. The way in which this is dealt with is implementation 1836 specific. Likewise, server implementors should plan for the 1837 possibility of an associated identity's credentials becoming invalid. 1839 Lightweight Directory Access Protocol Version 3 1841 Implementations which cache attributes and entries obtained via LDAP 1842 MUST ensure that access controls are maintained if that information 1843 is to be provided to multiple clients, since servers may have access 1844 control policies which prevent the return of entries or attributes in 1845 search results except to particular authenticated clients. For 1846 example, caches could serve result information only to the client 1847 whose request caused it to be in the cache. 1849 Protocol servers may return referrals which redirect protocol clients 1850 to peer servers. It is possible for a rogue application to inject 1851 such referrals into the data stream in an attempt to redirect a 1852 client to a rogue server. Protocol clients are advised to be aware of 1853 this, and possibly reject referrals when confidentiality measures are 1854 not in place. Protocol clients are advised to ignore referrals from 1855 the Start TLS operation. 1857 Protocol peers MUST be prepared to handle invalid and arbitrary 1858 length protocol encodings. A number of LDAP security advisories are 1859 available through [CERT]. 1861 8. Acknowledgements 1863 This document is an update to RFC 2251, by Mark Wahl, Tim Howes, and 1864 Steve Kille. Their work along with the input of individuals of the 1865 IETF LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully 1866 acknowledged. 1868 9. Normative References 1870 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 1871 Models and Service", 1993. 1873 [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", 1874 draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). 1876 [Keyword] Bradner, S., "Key words for use in RFCs to Indicate 1877 Requirement Levels", RFC 2119, March 1997. 1879 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 1880 "Information Technology - Abstract Syntax Notation One 1881 (ASN.1): Specification of basic notation" 1883 [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, 1884 "Information technology - ASN.1 encoding rules: 1885 Specification of Basic Encoding Rules (BER), Canonical 1886 Encoding Rules (CER) and Distinguished Encoding Rules 1887 (DER)", 2002. 1889 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- 1890 ldapbis-bcp64-00.txt, (a work in progress). 1892 Lightweight Directory Access Protocol Version 3 1894 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 1895 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 1896 : 1993. 1898 [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode 1899 and ISO 10646", draft-yergeau-rfc2279bis-xx.txt, (a work 1900 in progress). 1902 [Models] Zeilenga, K., "LDAP: Directory Information Models", draft- 1903 ietf-ldapbis-models-xx.txt (a work in progress). 1905 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 1906 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a 1907 work in progress). 1909 [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching 1910 Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in 1911 progress). 1913 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. 1915 [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service 1916 Definition", 1993. 1918 [URI] Berners-Lee, T., Fielding, R., and L. Masinter Uniform 1919 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1920 August 1998. 1922 [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection 1923 Level Security Mechanisms ", draft-ietf-ldapbis-authmeth- 1924 xx.txt, (a work in progress). 1926 [SASL] Meyers, J., "Simple Authentication and Security Layer", 1927 RFC 2222, October 1997. 1929 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 1930 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 1931 progress). 1933 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1934 3.2.0" is defined by "The Unicode Standard, Version 3.0" 1935 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 1936 as amended by the "Unicode Standard Annex #27: Unicode 1937 3.1" (http://www.unicode.org/reports/tr27/) and by the 1938 "Unicode Standard Annex #28: Unicode 3.2" 1939 (http://www.unicode.org/reports/tr28/). 1941 [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC 1942 793, September 1981 1944 [IP] Postel, J., "Internet Protocol", STD5 and RFC 791, 1945 September 1981 1946 Lightweight Directory Access Protocol Version 3 1948 10. Informative References 1950 [CERT] the CERT(R) Center, (http://www.cert.org) 1952 11. IANA Considerations 1953 It is requested that the Internet Assigned Numbers Authority (IANA) 1954 update the occurrence of "RFC XXXX" in Appendix B with this RFC 1955 number at publication. 1957 12. Editor's Address 1959 Jim Sermersheim 1960 Novell, Inc. 1961 1800 South Novell Place 1962 Provo, Utah 84606, USA 1963 jimse@novell.com 1964 +1 801 861-3088 1965 Lightweight Directory Access Protocol Version 3 1967 Appendix A - LDAP Result Codes 1969 This normative appendix details additional considerations regarding 1970 LDAP result codes and provides a brief, general description of each 1971 LDAP result code enumerated in Section 4.1.10. 1973 Additional result codes MAY be defined for use with extensions 1974 [LDAPIANA]. Client implementations SHALL treat any result code which 1975 they do not recognize as an unknown error condition. 1977 A.1 Non-Error Result Codes 1978 These result codes (called "non-error" result codes) do not indicate 1979 an error condition: 1980 success (0), 1981 compareTrue (6), 1982 compareFalse (7), 1983 referral (10), and 1984 saslBindInProgress (14). 1986 The success, compareTrue, and compare result codes indicate 1987 successful completion (and, hence, are referred to as "successful" 1988 result codes). 1990 The referral and saslBindInProgress result codes indicate the client 1991 is required to take additional action to complete the operation 1993 A.2 Result Codes 1994 Existing LDAP result codes are described as follows: 1996 success (0) 1997 Indicates the successful completion of an operation. 1999 operationsError (1) 2000 Indicates that the operation is not properly sequenced with 2001 relation to other operations (of same or different type). 2003 For example, this code is returned if the client attempts to 2004 Start TLS [RFC2246] while there are other operations 2005 outstanding or if TLS was already established. 2007 protocolError (2) 2008 Indicates the server received data which has incorrect 2009 structure. 2011 For bind operation only, the code may be returned to indicate 2012 the server does not support the requested protocol version. 2014 timeLimitExceeded (3) 2015 Indicates that the time limit specified by the client was 2016 exceeded before the operation could be completed. 2018 sizeLimitExceeded (4) 2019 Lightweight Directory Access Protocol Version 3 2021 Indicates that the size limit specified by the client was 2022 exceeded before the operation could be completed. 2024 compareFalse (5) 2025 Indicates that the compare operation has successfully 2026 completed and the assertion has evaluated to FALSE. 2028 compareTrue (6) 2029 Indicates that the compare operation has successfully 2030 completed and the assertion has evaluated to TRUE. 2032 authMethodNotSupported (7) 2033 Indicates that the authentication method or mechanism is not 2034 supported. 2036 strongAuthRequired (8) 2037 Indicates that the server has detected that an established 2038 security association between the client and server has 2039 unexpectedly failed or been compromised, or that the server 2040 now requires the client to authenticate using a strong(er) 2041 mechanism. 2043 referral (10) 2044 Indicates that a referral needs to be chased to complete the 2045 operation (see section 4.1.11). 2047 adminLimitExceeded (11) 2048 Indicates that an administrative limit has been exceeded. 2050 unavailableCriticalExtension (12) 2051 Indicates that server cannot perform a critical extension 2052 (see section 4.1.12). 2054 confidentialityRequired (13) 2055 Indicates that data confidentiality protections are required. 2057 saslBindInProgress (14) 2058 Indicates the server requires the client to send a new bind 2059 request, with the same SASL mechanism, to continue the 2060 authentication process (see section 4.2). 2062 noSuchAttribute (16) 2063 Indicates that the named entry does not contain the specified 2064 attribute or attribute value. 2066 undefinedAttributeType (17) 2067 Indicates that a request field contains an undefined 2068 attribute type. 2070 inappropriateMatching (18) 2071 Indicates that an attempt was made, e.g. in a filter, to use 2072 a matching rule not defined for the attribute type concerned. 2074 constraintViolation (19) 2075 Lightweight Directory Access Protocol Version 3 2077 Indicates that the client supplied an attribute value which 2078 does not conform to the constraints placed upon it by the 2079 data model. 2081 For example, this code is returned when multiple values are 2082 supplied to an attribute which has a SINGLE-VALUE constraint. 2084 attributeOrValueExists (20) 2085 Indicates that the client supplied an attribute or value to 2086 be added to an entry, but the attribute or value already 2087 exists. 2089 invalidAttributeSyntax (21) 2090 Indicates that a purported attribute value does not conform 2091 to the syntax of the attribute. 2093 noSuchObject (32) 2094 Indicates that the object does not exist in the DIT. 2096 aliasProblem (33) 2097 Indicates that an alias problem has occurred. Typically an 2098 alias has been dereferenced which names no object. 2100 invalidDNSyntax (34) 2101 Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search 2102 base, target entry, ModifyDN newrdn, etc.) of a request does 2103 not conform to the required syntax or contains attribute 2104 values which do not conform to the syntax of the attribute's 2105 type. 2107 aliasDereferencingProblem (36) 2108 Indicates that a problem occurred while dereferencing an 2109 alias. Typically an alias was encountered in a situation 2110 where it was not allowed or where access was denied. 2112 inappropriateAuthentication (48) 2113 Indicates the server requires the client which had attempted 2114 to bind anonymously or without supplying credentials to 2115 provide some form of credentials. 2117 invalidCredentials (49) 2118 Indicates the supplied password or SASL credentials are 2119 invalid. 2121 insufficientAccessRights (50) 2122 Indicates that the client does not have sufficient access 2123 rights to perform the operation. 2125 busy (51) 2126 Indicates that the server is busy. 2128 unavailable (52) 2129 Indicates that the server is shutting down or a subsystem 2130 necessary to complete the operation is offline. 2132 Lightweight Directory Access Protocol Version 3 2134 unwillingToPerform (53) 2135 Indicates that the server is unwilling to perform the 2136 operation. 2138 loopDetect (54) 2139 Indicates that the server has detected an internal loop. 2141 namingViolation (64) 2142 Indicates that the entry name violates naming restrictions. 2144 objectClassViolation (65) 2145 Indicates that the entry violates object class restrictions. 2147 notAllowedOnNonLeaf (66) 2148 Indicates that the operation is inappropriately acting upon a 2149 non-leaf entry. 2151 notAllowedOnRDN (67) 2152 Indicates that the operation is inappropriately attempting to 2153 remove a value which forms the entry's relative distinguished 2154 name. 2156 entryAlreadyExists (68) 2157 Indicates that the request cannot be fulfilled (added, moved, 2158 or renamed) as the target entry already exists. 2160 objectClassModsProhibited (69) 2161 Indicates that the attempt to modify the object class(es) of 2162 an entry's objectClass attribute is prohibited. 2164 For example, this code is returned when a client attempts to 2165 modify the structural object class of an entry. 2167 affectsMultipleDSAs (71) 2168 Indicates that the operation cannot be completed as it 2169 affects multiple servers (DSAs). 2171 other (80) 2172 Indicates the server has encountered an internal error. 2174 Lightweight Directory Access Protocol Version 3 2176 Appendix B - Complete ASN.1 Definition 2178 This appendix is normative. 2180 Lightweight-Directory-Access-Protocol-V3 2181 -- Copyright (C) The Internet Society (2003). This version of 2182 -- this ASN.1 module is part of RFC XXXX; see the RFC itself 2183 -- for full legal notices. 2184 DEFINITIONS 2185 IMPLICIT TAGS 2186 EXTENSIBILITY IMPLIED ::= 2188 BEGIN 2190 LDAPMessage ::= SEQUENCE { 2191 messageID MessageID, 2192 protocolOp CHOICE { 2193 bindRequest BindRequest, 2194 bindResponse BindResponse, 2195 unbindRequest UnbindRequest, 2196 searchRequest SearchRequest, 2197 searchResEntry SearchResultEntry, 2198 searchResDone SearchResultDone, 2199 searchResRef SearchResultReference, 2200 modifyRequest ModifyRequest, 2201 modifyResponse ModifyResponse, 2202 addRequest AddRequest, 2203 addResponse AddResponse, 2204 delRequest DelRequest, 2205 delResponse DelResponse, 2206 modDNRequest ModifyDNRequest, 2207 modDNResponse ModifyDNResponse, 2208 compareRequest CompareRequest, 2209 compareResponse CompareResponse, 2210 abandonRequest AbandonRequest, 2211 extendedReq ExtendedRequest, 2212 extendedResp ExtendedResponse, 2213 ... }, 2214 controls [0] Controls OPTIONAL } 2216 MessageID ::= INTEGER (0 .. maxInt) 2218 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 2220 LDAPString ::= OCTET STRING -- UTF-8 encoded, 2221 -- [ISO10646] characters 2223 LDAPOID ::= OCTET STRING -- Constrained to [Models] 2225 LDAPDN ::= LDAPString 2227 RelativeLDAPDN ::= LDAPString 2229 AttributeDescription ::= LDAPString 2230 Lightweight Directory Access Protocol Version 3 2232 -- Constrained to 2233 -- [Models] 2235 AttributeValue ::= OCTET STRING 2237 AttributeValueAssertion ::= SEQUENCE { 2238 attributeDesc AttributeDescription, 2239 assertionValue AssertionValue } 2241 AssertionValue ::= OCTET STRING 2243 Attribute ::= SEQUENCE { 2244 type AttributeDescription, 2245 vals SET SIZE (1..MAX) OF value AttributeValue } 2247 MatchingRuleId ::= LDAPString 2249 LDAPResult ::= SEQUENCE { 2250 resultCode ENUMERATED { 2251 success (0), 2252 operationsError (1), 2253 protocolError (2), 2254 timeLimitExceeded (3), 2255 sizeLimitExceeded (4), 2256 compareFalse (5), 2257 compareTrue (6), 2258 authMethodNotSupported (7), 2259 strongAuthRequired (8), 2260 -- 9 reserved -- 2261 referral (10), 2262 adminLimitExceeded (11), 2263 unavailableCriticalExtension (12), 2264 confidentialityRequired (13), 2265 saslBindInProgress (14), 2266 noSuchAttribute (16), 2267 undefinedAttributeType (17), 2268 inappropriateMatching (18), 2269 constraintViolation (19), 2270 attributeOrValueExists (20), 2271 invalidAttributeSyntax (21), 2272 -- 22-31 unused -- 2273 noSuchObject (32), 2274 aliasProblem (33), 2275 invalidDNSyntax (34), 2276 -- 35 reserved for undefined isLeaf -- 2277 aliasDereferencingProblem (36), 2278 -- 37-47 unused -- 2279 inappropriateAuthentication (48), 2280 invalidCredentials (49), 2281 insufficientAccessRights (50), 2282 busy (51), 2283 unavailable (52), 2284 unwillingToPerform (53), 2285 loopDetect (54), 2286 Lightweight Directory Access Protocol Version 3 2288 -- 55-63 unused -- 2289 namingViolation (64), 2290 objectClassViolation (65), 2291 notAllowedOnNonLeaf (66), 2292 notAllowedOnRDN (67), 2293 entryAlreadyExists (68), 2294 objectClassModsProhibited (69), 2295 -- 70 reserved for CLDAP -- 2296 affectsMultipleDSAs (71), 2297 -- 72-79 unused -- 2298 other (80), 2299 ... }, 2300 -- 81-90 reserved for APIs -- 2301 matchedDN LDAPDN, 2302 diagnosticMessage LDAPString, 2303 referral [3] Referral OPTIONAL } 2305 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 2307 URI ::= LDAPString -- limited to characters permitted in 2308 -- URIs 2310 Controls ::= SEQUENCE OF control Control 2312 Control ::= SEQUENCE { 2313 controlType LDAPOID, 2314 criticality BOOLEAN DEFAULT FALSE, 2315 controlValue OCTET STRING OPTIONAL } 2317 BindRequest ::= [APPLICATION 0] SEQUENCE { 2318 version INTEGER (1 .. 127), 2319 name LDAPDN, 2320 authentication AuthenticationChoice } 2322 AuthenticationChoice ::= CHOICE { 2323 simple [0] OCTET STRING, 2324 -- 1 and 2 reserved 2325 sasl [3] SaslCredentials, 2326 ... } 2328 SaslCredentials ::= SEQUENCE { 2329 mechanism LDAPString, 2330 credentials OCTET STRING OPTIONAL } 2332 BindResponse ::= [APPLICATION 1] SEQUENCE { 2333 COMPONENTS OF LDAPResult, 2334 serverSaslCreds [7] OCTET STRING OPTIONAL } 2336 UnbindRequest ::= [APPLICATION 2] NULL 2338 SearchRequest ::= [APPLICATION 3] SEQUENCE { 2339 baseObject LDAPDN, 2340 scope ENUMERATED { 2341 baseObject (0), 2342 Lightweight Directory Access Protocol Version 3 2344 singleLevel (1), 2345 wholeSubtree (2) }, 2346 derefAliases ENUMERATED { 2347 neverDerefAliases (0), 2348 derefInSearching (1), 2349 derefFindingBaseObj (2), 2350 derefAlways (3) }, 2351 sizeLimit INTEGER (0 .. maxInt), 2352 timeLimit INTEGER (0 .. maxInt), 2353 typesOnly BOOLEAN, 2354 filter Filter, 2355 attributes AttributeSelection } 2357 AttributeSelection ::= SEQUENCE OF selection LDAPString 2359 Filter ::= CHOICE { 2360 and [0] SET SIZE (1..MAX) OF filter Filter, 2361 or [1] SET SIZE (1..MAX) OF filter Filter, 2362 not [2] Filter, 2363 equalityMatch [3] AttributeValueAssertion, 2364 substrings [4] SubstringFilter, 2365 greaterOrEqual [5] AttributeValueAssertion, 2366 lessOrEqual [6] AttributeValueAssertion, 2367 present [7] AttributeDescription, 2368 approxMatch [8] AttributeValueAssertion, 2369 extensibleMatch [9] MatchingRuleAssertion } 2371 SubstringFilter ::= SEQUENCE { 2372 type AttributeDescription, 2373 -- at least one must be present, 2374 -- initial and final can occur at most once 2375 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 2376 initial [0] AssertionValue, 2377 any [1] AssertionValue, 2378 final [2] AssertionValue } } 2380 MatchingRuleAssertion ::= SEQUENCE { 2381 matchingRule [1] MatchingRuleId OPTIONAL, 2382 type [2] AttributeDescription OPTIONAL, 2383 matchValue [3] AssertionValue, 2384 dnAttributes [4] BOOLEAN DEFAULT FALSE } 2386 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 2387 objectName LDAPDN, 2388 attributes PartialAttributeList } 2390 PartialAttributeList ::= SEQUENCE OF 2391 attribute PartialAttribute 2393 PartialAttribute ::= SEQUENCE { 2394 type AttributeDescription, 2395 vals SET OF value AttributeValue } 2397 SearchResultReference ::= [APPLICATION 19] SEQUENCE 2398 Lightweight Directory Access Protocol Version 3 2400 SIZE (1..MAX) OF uri URI 2402 SearchResultDone ::= [APPLICATION 5] LDAPResult 2404 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 2405 object LDAPDN, 2406 changes SEQUENCE OF change SEQUENCE { 2407 operation ENUMERATED { 2408 add (0), 2409 delete (1), 2410 replace (2) }, 2411 modification PartialAttribute } } 2413 ModifyResponse ::= [APPLICATION 7] LDAPResult 2415 AddRequest ::= [APPLICATION 8] SEQUENCE { 2416 entry LDAPDN, 2417 attributes AttributeList } 2419 AttributeList ::= SEQUENCE OF attribute Attribute 2421 AddResponse ::= [APPLICATION 9] LDAPResult 2423 DelRequest ::= [APPLICATION 10] LDAPDN 2425 DelResponse ::= [APPLICATION 11] LDAPResult 2427 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 2428 entry LDAPDN, 2429 newrdn RelativeLDAPDN, 2430 deleteoldrdn BOOLEAN, 2431 newSuperior [0] LDAPDN OPTIONAL } 2433 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 2435 CompareRequest ::= [APPLICATION 14] SEQUENCE { 2436 entry LDAPDN, 2437 ava AttributeValueAssertion } 2439 CompareResponse ::= [APPLICATION 15] LDAPResult 2441 AbandonRequest ::= [APPLICATION 16] MessageID 2443 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 2444 requestName [0] LDAPOID, 2445 requestValue [1] OCTET STRING OPTIONAL } 2447 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 2448 COMPONENTS OF LDAPResult, 2449 responseName [10] LDAPOID OPTIONAL, 2450 responseValue [11] OCTET STRING OPTIONAL } 2452 END 2453 Lightweight Directory Access Protocol Version 3 2455 Appendix C - Change History 2456 2459 C.1 Changes made to RFC 2251: 2461 C.1.1 Editorial 2463 - Bibliography References: Changed all bibliography references to 2464 use a long name form for readability. 2465 - Changed occurrences of "unsupportedCriticalExtension" 2466 "unavailableCriticalExtension" 2467 - Fixed a small number of misspellings (mostly dropped letters). 2469 C.1.2 Section 1 2471 - Removed IESG note. 2473 C.1.3 Section 9 2475 - Added references to RFCs 1823, 2234, 2829 and 2830. 2477 C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt: 2479 C.2.1 Section 4.1.6 2481 - In the first paragraph, clarified what the contents of an 2482 AttributeValue are. There was confusion regarding whether or not 2483 an AttributeValue that is BER encoded (due to the "binary" option) 2484 is to be wrapped in an extra OCTET STRING. 2485 - To the first paragraph, added wording that doesn't restrict other 2486 transfer encoding specifiers from being used. The previous wording 2487 only allowed for the string encoding and the ;binary encoding. 2488 - To the first paragraph, added a statement restricting multiple 2489 options that specify transfer encoding from being present. This 2490 was never specified in the previous version and was seen as a 2491 potential interoperability problem. 2492 - Added a third paragraph stating that the ;binary option is 2493 currently the only option defined that specifies the transfer 2494 encoding. This is for completeness. 2496 C.2.2 Section 4.1.7 2498 - Generalized the second paragraph to read "If an option specifying 2499 the transfer encoding is present in attributeDesc, the 2500 AssertionValue is encoded as specified by the option...". 2501 Previously, only the ;binary option was mentioned. 2503 C.2.3 Sections 4.2, 4.9, 4.10 2505 - Added alias dereferencing specifications. In the case of modDN, 2506 followed precedent set on other update operations (... alias is 2507 not dereferenced...) In the case of bind and compare stated that 2508 Lightweight Directory Access Protocol Version 3 2510 servers SHOULD NOT dereference aliases. Specifications were added 2511 because they were missing from the previous version and caused 2512 interoperability problems. Concessions were made for bind and 2513 compare (neither should have ever allowed alias dereferencing) by 2514 using SHOULD NOT language, due to the behavior of some existing 2515 implementations. 2517 C.2.4 Sections 4.5 and Appendix A 2519 - Changed SubstringFilter.substrings.initial, any, and all from 2520 LDAPString to AssertionValue. This was causing an incompatibility 2521 with X.500 and confusion among other TS RFCs. 2523 C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt: 2525 C.3.1 Section 3.4 2527 - Reworded text surrounding subschemaSubentry to reflect that it is 2528 a single-valued attribute that holds the schema for the root DSE. 2529 Also noted that if the server masters entries that use differing 2530 schema, each entry's subschemaSubentry attribute must be 2531 interrogated. This may change as further fine-tuning is done to 2532 the data model. 2534 C.3.2 Section 4.1.12 2536 - Specified that the criticality field is only used for requests and 2537 not for unbind or abandon. Noted that it is ignored for all other 2538 operations. 2540 C.3.3 Section 4.2 2542 - Noted that Server behavior is undefined when the name is a null 2543 value, simple authentication is used, and a password is specified. 2545 C.3.4 Section 4.2.(various) 2547 - Changed "unauthenticated" to "anonymous" and "DN" and "LDAPDN" to 2548 "name" 2550 C.3.5 Section 4.2.2 2552 - Changed "there is no authentication or encryption being performed 2553 by a lower layer" to "the underlying transport service cannot 2554 guarantee confidentiality" 2556 C.3.6 Section 4.5.2 2558 - Removed all mention of ExtendedResponse due to lack of 2559 implementation. 2561 C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt: 2563 Lightweight Directory Access Protocol Version 3 2565 C.4.1 Section 4 2567 - Removed "typically" from "and is typically transferred" in the 2568 first paragraph. We know of no (and can conceive of no) case where 2569 this isn't true. 2570 - Added "Section 5.1 specifies how the LDAP protocol is encoded." To 2571 the first paragraph. Added this cross reference for readability. 2572 - Changed "version 3 " to "version 3 or later" in the second 2573 paragraph. This was added to clarify the original intent. 2574 - Changed "protocol version" to "protocol versions" in the third 2575 paragraph. This attribute is multi-valued with the intent of 2576 holding all supported versions, not just one. 2578 C.4.2 Section 4.1.8 2580 - Changed "when transferred in protocol" to "when transferred from 2581 the server to the client" in the first paragraph. This is to 2582 clarify that this behavior only happens when attributes are being 2583 sent from the server. 2585 C.4.3 Section 4.1.10 2587 - Changed "servers will return responses containing fields of type 2588 LDAPResult" to "servers will return responses of LDAPResult or 2589 responses containing the components of LDAPResponse". This 2590 statement was incorrect and at odds with the ASN.1. The fix here 2591 reflects the original intent. 2592 - Dropped '--new' from result codes ASN.1. This simplification in 2593 comments just reduces unneeded verbiage. 2595 C.4.4 Section 4.1.11 2597 - Changed "It contains a reference to another server (or set of 2598 servers)" to "It contains one or more references to one or more 2599 servers or services" in the first paragraph. This reflects the 2600 original intent and clarifies that the URL may point to non-LDAP 2601 services. 2603 C.4.5 Section 4.1.12 2605 - Changed "The server MUST be prepared" to "Implementations MUST be 2606 prepared" in the eighth paragraph to reflect that both client and 2607 server implementations must be able to handle this (as both parse 2608 controls). 2610 C.4.6 Section 4.4 2612 - Changed "One unsolicited notification is defined" to "One 2613 unsolicited notification (Notice of Disconnection) is defined" in 2614 the third paragraph. For clarity and readability. 2616 C.4.7 Section 4.5.1 2617 Lightweight Directory Access Protocol Version 3 2619 - Changed "checking for the existence of the objectClass attribute" 2620 to "checking for the presence of the objectClass attribute" in the 2621 last paragraph. This was done as a measure of consistency (we use 2622 the terms present and presence rather than exists and existence in 2623 search filters). 2625 C.4.8 Section 4.5.3 2627 - Changed "outstanding search operations to different servers," to 2628 "outstanding search operations" in the fifth paragraph as they may 2629 be to the same server. This is a point of clarification. 2631 C.4.9 Section 4.6 2633 - Changed "clients MUST NOT attempt to delete" to "clients MUST NOT 2634 attempt to add or delete" in the second to last paragraph. 2635 - Change "using the "delete" form" to "using the "add" or "delete" 2636 form" in the second to last paragraph. 2638 C.4.10 Section 4.7 2640 - Changed "Clients MUST NOT supply the createTimestamp or 2641 creatorsName attributes, since these will be generated 2642 automatically by the server." to "Clients MUST NOT supply NO-USER- 2643 MODIFICATION attributes such as createTimestamp or creatorsName 2644 attributes, since these are provided by the server." in the 2645 definition of the attributes field. This tightens the language to 2646 reflect the original intent and to not leave a hole in which one 2647 could interpret the two attributes mentioned as the only non- 2648 writable attributes. 2650 C.4.11 Section 4.11 2652 - Changed "has been" to "will be" in the fourth paragraph. This 2653 clarifies that the server will (not has) abandon the operation. 2655 C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt: 2657 C.5.1 Section 3.2.1 2659 - Changed "An attribute is a type with one or more associated 2660 values. The attribute type is identified by a short descriptive 2661 name and an OID (object identifier). The attribute type governs 2662 whether there can be more than one value of an attribute of that 2663 type in an entry, the syntax to which the values must conform, the 2664 kinds of matching which can be performed on values of that 2665 attribute, and other functions." to " An attribute is a 2666 description (a type and zero or more options) with one or more 2667 associated values. The attribute type governs whether the 2668 attribute can have multiple values, the syntax and matching rules 2669 used to construct and compare values of that attribute, and other 2670 functions. Options indicate modes of transfer and other 2671 Lightweight Directory Access Protocol Version 3 2673 functions.". This points out that an attribute consists of both 2674 the type and options. 2676 C.5.2 Section 4 2678 - Changed "Section 5.1 specifies the encoding rules for the LDAP 2679 protocol" to "Section 5.1 specifies how the protocol is encoded 2680 and transferred." 2682 C.5.3 Section 4.1.2 2684 - Added ABNF for the textual representation of LDAPOID. Previously, 2685 there was no formal BNF for this construct. 2687 C.5.4 Section 4.1.4 2689 - Changed "This identifier may be written as decimal digits with 2690 components separated by periods, e.g. "2.5.4.10"" to "may be 2691 written as defined by ldapOID in section 4.1.2" in the second 2692 paragraph. This was done because we now have a formal BNF 2693 definition of an oid. 2695 C.5.5 Section 4.1.5 2697 - Changed the BNF for AttributeDescription to ABNF. This was done 2698 for readability and consistency (no functional changes involved). 2699 - Changed "Options present in an AttributeDescription are never 2700 mutually exclusive." to "Options MAY be mutually exclusive. An 2701 AttributeDescription with mutually exclusive options is treated as 2702 an undefined attribute type." for clarity. It is generally 2703 understood that this is the original intent, but the wording could 2704 be easily misinterpreted. 2705 - Changed "Any option could be associated with any AttributeType, 2706 although not all combinations may be supported by a server." to 2707 "Though any option or set of options could be associated with any 2708 AttributeType, the server support for certain combinations may be 2709 restricted by attribute type, syntaxes, or other factors.". This 2710 is to clarify the meaning of 'combination' (it applies both to 2711 combination of attribute type and options, and combination of 2712 options). It also gives examples of *why* they might be 2713 unsupported. 2715 C.5.6 Section 4.1.11 2717 - Changed the wording regarding 'equally capable' referrals to "If 2718 multiple URLs are present, the client assumes that any URL may be 2719 used to progress the operation.". The previous language implied 2720 that the server MUST enforce rules that it was practically 2721 incapable of. The new language highlights the original intent-- 2722 that is, that any of the referrals may be used to progress the 2723 operation, there is no inherent 'weighting' mechanism. 2725 C.5.7 Section 4.5.1 and Appendix A 2726 Lightweight Directory Access Protocol Version 3 2728 - Added the comment "-- initial and final can occur at most once", 2729 to clarify this restriction. 2731 C.5.8 Section 5.1 2733 - Changed heading from "Mapping Onto BER-based Transport Services" 2734 to "Protocol Encoding". 2736 C.5.9 Section 5.2.1 2738 - Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs" 2739 to point out that the PDUs are encoded before being streamed to 2740 TCP. 2742 C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt: 2744 C.6.1 Section 4.5.1 and Appendix A 2746 - Changed the ASN.1 for the and and or choices of Filter to have a 2747 lower range of 1. This was an omission in the original ASN.1 2749 C.6.2 Various 2751 - Fixed various typo's 2753 C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt: 2755 C.7.1 Section 3.2.1 2757 - Added "(as defined in Section 12.4.1 of [X.501])" to the fifth 2758 paragraph when talking about "operational attributes". This is 2759 because the term "operational attributes" is never defined. 2760 Alternately, we could drag a definition into the spec, for now, 2761 I'm just pointing to the reference in X.501. 2763 C.7.2 Section 4.1.5 2765 - Changed "And is also case insensitive" to "The entire 2766 AttributeDescription is case insensitive". This is to clarify 2767 whether we're talking about the entire attribute description, or 2768 just the options. 2770 - Expounded on the definition of attribute description options. This 2771 doc now specifies a difference between transfer and tagging 2772 options and describes the semantics of each, and how and when 2773 subtyping rules apply. Now allow options to be transmitted in any 2774 order but disallow any ordering semantics to be implied. These 2775 changes are the result of ongoing input from an engineering team 2776 designed to deal with ambiguity issues surrounding attribute 2777 options. 2779 C.7.3 Sections 4.1.5.1 and 4.1.6 2780 Lightweight Directory Access Protocol Version 3 2782 - Refer to non "binary" transfer encodings as "native encoding" 2783 rather than "string" encoding to clarify and avoid confusion. 2785 C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt: 2787 C.8.1 Title 2789 - Changed to "LDAP: The Protocol" to be consisted with other working 2790 group documents 2792 C.8.2 Abstract 2794 - Moved above TOC to conform to new guidelines 2796 - Reworded to make consistent with other WG documents. 2798 - Moved 2119 conventions to "Conventions" section 2800 C.8.3 Introduction 2802 - Created to conform to new guidelines 2804 C.8.4 Models 2806 - Removed section. There is only one model in this document 2807 (Protocol Model) 2809 C.8.5 Protocol Model 2811 - Removed antiquated paragraph: "In keeping with the goal of easing 2812 the costs associated with use of the directory, it is an objective 2813 of this protocol to minimize the complexity of clients so as to 2814 facilitate widespread deployment of applications capable of using 2815 the directory." 2817 - Removed antiquated paragraph concerning LDAP v1 and v2 and 2818 referrals. 2820 C.8.6 Data Model 2822 - Removed Section 3.2 and subsections. These have been moved to 2823 [Models] 2825 C.8.7 Relationship to X.500 2827 - Removed section. It has been moved to [Roadmap] 2829 C.8.8 Server Specific Data Requirements 2831 - Removed section. It has been moved to [Models] 2833 C.8.9 Elements of Protocol 2834 Lightweight Directory Access Protocol Version 3 2836 - Added "Section 5.1 specifies how the protocol is encoded and 2837 transferred." to the end of the first paragraph for reference. 2839 - Reworded notes about extensibility, and now talk about implied 2840 extensibility and the use of ellipses in the ASN.1 2842 - Removed references to LDAPv2 in third and fourth paragraphs. 2844 C.8.10 Message ID 2846 - Reworded second paragraph to "The message ID of a request MUST 2847 have a non-zero value different from the values of any other 2848 requests outstanding in the LDAP session of which this message is 2849 a part. The zero value is reserved for the unsolicited 2850 notification message." (Added notes about non-zero and the zero 2851 value). 2853 C.8.11 String Types 2855 - Removed ABNF for LDAPOID and added "Although an LDAPOID is encoded 2856 as an OCTET STRING, values are limited to the definition of 2857 numericoid given in Section 1.3 of [Models]." 2859 C.8.12 Distinguished Name and Relative Distinguished Name 2861 - Removed ABNF and referred to [Models] and [LDAPDN] where this is 2862 defined. 2864 C.8.13 Attribute Type 2866 - Removed sections. It's now in the [Models] doc. 2868 C.8.14 Attribute Description 2870 - Removed ABNF and aligned section with [Models] 2872 - Moved AttributeDescriptionList here. 2874 C.8.15 Transfer Options 2876 - Added section and consumed much of old options language (while 2877 aligning with [Models] 2879 C.8.16 Binary Transfer Option 2881 - Clarified intent regarding exactly what is to be BER encoded. 2883 - Clarified that clients must not expect ;binary when not asking for 2884 it (;binary, as opposed to ber encoded data). 2886 C.8.17 Attribute 2888 - Use the term "attribute description" in lieu of "type" 2889 Lightweight Directory Access Protocol Version 3 2891 - Clarified the fact that clients cannot rely on any apparent 2892 ordering of attribute values. 2894 C.8.18 LDAPResult 2896 - To resultCode, added ellipses "..." to the enumeration to indicate 2897 extensibility. and added a note, pointing to [LDAPIANA] 2899 - Removed error groupings ad refer to Appendix A. 2901 C.8.19 Bind Operation 2903 - Added "Prior to the BindRequest, the implied identity is 2904 anonymous. Refer to [AuthMeth] for the authentication-related 2905 semantics of this operation." to the first paragraph. 2907 - Added ellipses "..." to AuthenticationChoice and added a note 2908 "This type is extensible as defined in Section 3.6 of [LDAPIANA]. 2909 Servers that do not support a choice supplied by a client will 2910 return authMethodNotSupported in the result code of the 2911 BindResponse." 2913 - Simplified text regarding how the server handles unknown versions. 2914 Removed references to LDAPv2 2916 C.8.20 Sequencing of the Bind Request 2918 - Aligned with [AuthMeth] In particular, paragraphs 4 and 6 were 2919 removed, while a portion of 4 was retained (see C.8.9) 2921 C.8.21 Authentication and other Security Service 2923 - Section was removed. Now in [AuthMeth] 2925 C.8.22 Continuation References in the Search Result 2927 - Added "If the originating search scope was singleLevel, the scope 2928 part of the URL will be baseObject." 2930 C.8.23 Security Considerations 2932 - Removed reference to LDAPv2 2934 C.8.24 Result Codes 2936 - Added as normative appendix A 2938 C.8.25 ASN.1 2940 - Added EXTENSIBILITY IMPLIED 2942 - Added a number of comments holding referenced to [Models] and 2943 [ISO10646]. 2945 Lightweight Directory Access Protocol Version 3 2947 - Removed AttributeType. It is not used. 2949 C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt: 2951 - Removed all mention of transfer encodings and the binary attribute 2952 option. Please refer to draft-legg-ldap-binary-00.txt and draft- 2953 legg-ldap-transfer-00.txt 2955 - Further alignment with [Models]. 2957 - Added extensibility ellipsis to protocol op choice 2959 - In 4.1.1, clarified when connections may be dropped due to 2960 malformed PDUs 2962 - Specified which matching rules and syntaxes are used for various 2963 filter items 2965 C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt: 2967 C.10.1 Section 4.1.1.1: 2969 - Clarified when it is and isn't appropriate to return an already 2970 used message id. 2972 C.10.2 Section 4.1.11: 2974 - Clarified that a control only applies to the message it's attached 2975 to. 2977 - Explained that the criticality field is only applicable to certain 2978 request messages. 2980 - Added language regarding the combination of controls. 2982 C.10.3 Section 4.11: 2984 - Explained that Abandon and Unbind cannot be abandoned, and 2985 illustrated how to determine whether an operation has been 2986 abandoned. 2988 C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt: 2990 - Fixed formatting 2992 C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt: 2994 C.12.1 Section 4.1.4: 2996 - Removed second paragraph as this language exists in MODELS 2997 Lightweight Directory Access Protocol Version 3 2999 C.12.2 Section 4.2.1: 3001 - Replaced fourth paragraph. It was accidentally removed in an 3002 earlier edit. 3004 C.12.2 Section 4.13: 3006 - Added section describing the StartTLS operation (moved from 3007 authmeth) 3009 C.13 Changes made to draft-ietf-ldapbis-protocol-11.txt: 3011 C.13.1 Section 4.1.9 3013 - Changed "errorMessage" to "diagnosticMessage". Simply to indicate 3014 that the field may be non-empty even if a non-error resultCode is 3015 present. 3017 C.13.2 Section 4.2: 3019 - Reconciled language in "name" definition with [AuthMeth] 3021 C.13.3 Section 4.2.1 3023 - Renamed to "Processing of the Bind Request", and moved some text 3024 from 4.2 into this section. 3026 - Rearranged paragraphs to flow better. 3028 - Specified that (as well as failed) an abandoned bind operation 3029 will leave the connection in an anonymous state. 3031 C.13.4 Section 4.5.3 3033 - Generalized the second paragraph which cited indexing and 3034 searchreferralreferences. 3036 C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt: 3038 - Reworked bind errors. 3039 - General clarifications and edits 3041 C.15 Changes made to draft-ietf-ldapbis-protocol-13.txt 3043 C.15.1 Section 2 & various 3044 - Added definitions for LDAP connection, TLS connection, and LDAP 3045 association, and updated appropriate fields to use proper terms. 3047 C.15.2 Section 4.2 3048 - Added text to authentication, specifying the way in which textual 3049 strings used as passwords are to be prepared. 3051 Lightweight Directory Access Protocol Version 3 3053 C.15.3 Section 4.5.1 3054 - Clarified derefInSearching. Specifically how it works in terms of 3055 subtree and one level searches 3057 C.15.4 Section 4.5.2 3059 - Changed MUST to SHOULD for returning textual attribute name, The 3060 MUST is unreasonable. There are likely cases (such as when the 3061 server knows multiple attributes in separate entries of a search 3062 result set share the same short name) where returning a numericoid 3063 is better than returning a short name. That is, the MUST may 3064 actually disallow servers from preventing misinterpretation of 3065 short names. This is not only an interop issue, but likely a 3066 security consideration. 3068 C.15.4 Section 4.9 3069 - Made modify consistent with add in regards to the need of parent 3070 entries already existing. 3072 C.15.6 Section 4.13.2.2 3073 - Removed wording indicating that referrals can be returned from 3074 StartTLS 3076 C.16 Changes made to draft-ietf-ldapbis-protocol-14.txt 3078 C.16.1 Section 4.1.9 3080 - Added: If a server detects multiple errors for an operation, only 3081 one resultCode is returned. The server should return the 3082 resultCode that best indicates the nature of the error 3083 encountered. 3085 C.16.2 Section 4.1.11 3086 - Added: controlValues that are defined in terms of ASN.1 and BER 3087 encoded according to Section 5.1, also follow the extensibility 3088 rules in Section 4. 3090 - Removed: "If a SASL transfer encryption or integrity mechanism has 3091 been negotiated, that mechanism does not support the changing of 3092 credentials from one identity to another, then the client MUST 3093 instead establish a new connection." 3095 Each SASL negotiation is, generally, independent of other SASL 3096 negotiations. If there were dependencies between multiple 3097 negotiations of a particular mechanism, the mechanism technical 3098 specification should detail how applications are to deal with 3099 them. LDAP should not require any special handling. And if an LDAP 3100 client had used such a mechanism, it would have the option of 3101 using another mechanism. 3103 C.16.3 Section 4.5.2 and Section 7 3104 - Removed: "If the LDAP association is operating over a connection- 3105 oriented transport such as TCP" 3106 Lightweight Directory Access Protocol Version 3 3108 This is always true. 3110 C.16.4 Section 4.11 3111 - Added: thus a client SHOULD NOT use the Abandon operation when it 3112 needs an indication of whether the operation was abandoned. For 3113 example, if a client performs an update operation (Add, Modify, or 3114 ModifyDN), and it needs to know whether the directory has changed 3115 due to the operation, it should not use the Abandon operation to 3116 cancel the update operation. Clients can determine that an 3117 operation has been abandoned by performing a subsequent bind 3118 operation. 3120 C.16.5 Section 4.12 3122 - Added: 3123 "The requestValue and responseValue fields contain any information 3124 associated with the operation. The format of these fields is 3125 defined by the specification of the extended operation. 3126 Implementations MUST be prepared to handle arbitrary contents of 3127 these fields, including zero bytes. Values that are defined in 3128 terms of ASN.1 and BER encoded according to Section 5.1, also 3129 follow the extensibility rules in Section 4. 3131 Extended operations may be specified in other documents. The 3132 specification of an extended operation consists of: 3134 - the OBJECT IDENTIFIER assigned to the 3135 ExtendedRequest.requestName (and possibly 3136 ExtendedResponse.responseName), 3138 - the format of the contents of the requestValue and responseValue 3139 (if any), 3141 - the semantics of the operation, 3143 Servers list the requestName of all ExtendedRequests they 3144 recognize in the supportedExtension attribute [Models] in the root 3145 DSE. 3147 requestValues and responseValues that are defined in terms of 3148 ASN.1 and BER encoded according to Section 5.1, also follow the 3149 extensibility rules in Section 4." 3151 This was to align with controls and control values. 3153 C.16.6 Section 4.13.3.1 3155 - Added: After the TLS connection has been closed, the server MUST 3156 NOT send responses to any request message received before the TLS 3157 closure. 3159 C.16.7 Section A2 3160 - Removed precedence rules 3161 Lightweight Directory Access Protocol Version 3 3163 C.17 Changes made to draft-ietf-ldapbis-protocol-15.txt 3165 C.17.1 Section 4.1.8 3166 - Removed: "Servers which support matching rules for use in the 3167 extensibleMatch search filter MUST list the matching rules they 3168 implement in subschema entries, using the matchingRules 3169 attributes. The server SHOULD also list there, using the 3170 matchingRuleUse attribute, the attribute types with which each 3171 matching rule can be used. More information is given in section 3172 4.5 of [Syntaxes]." 3174 This language is moved to [Models] 3176 C.17.2 Section 4.10 3177 - Added: "In the event that the attribute or subtype is not present 3178 in the entry, the resultCode field is set to noSuchAttribute. If 3179 the attribute is unknown, the resultCode is set to 3180 undefinedAttributeType." 3182 C.17.3 Section 7 3183 - Added: Requirements of authentication methods, SASL mechanisms, 3184 and TLS are described in [AUTHMETH]. 3186 - Added: Protocol peers MUST be prepared to handle invalid and 3187 arbitrary length protocol encodings. A number of LDAP security 3188 advisories are available through [CERT]. 3190 C.17.4 Section 10 3191 - Added as Informative References 3193 C.17.5 Various 3194 - Clarified that the [LDAPURL] form or URLs in referrals specifies 3195 LDAP servers implementing TCP/IP. 3197 C.18 Changes made to draft-ietf-ldapbis-protocol-16.txt 3199 C.18.1 Section 4.1.4 and others 3200 - Renamed AttributeDescriptionList to AttributeSelection and moved 3201 its definition to 4.5.1 (the only place it is referenced). 3203 C.18.2 Sections 4.1.10, 4.5.3 3204 - Made obvious the fact that instructions regarding LDAP URLS used 3205 as referrals and search result references only apply to LDAP URLs, 3206 and that other URLs need to define their own instructions. 3208 C.18.3 Section 4.2.1 3209 - Further clarified the authentication state of an abandoned bind 3211 C.18.4 Section 4.5.1 3212 - Added: "Note that the AssertionValue in a substrings filter item 3213 MUST conform to the assertion syntax of the EQUALITY matching rule 3214 for the attribute type rather than the assertion syntax of the 3215 SUBSTR matching rule for the attribute type. The entire 3216 Lightweight Directory Access Protocol Version 3 3218 SubstringFilter is converted into an assertion value of the 3219 substrings matching rule prior to applying the rule." 3221 C.18.5 Section 4.6 3222 - Replaced AttributeTypeAndValues with Attribute as they are 3223 equivalent. 3225 - Reformatted documentation of the various fields. 3227 - Clarified what type of modification changes might temporarily 3228 violate schema. 3230 C.18.6 Section 7 3231 - Added: "Server implementors should plan for the possibility of an 3232 identity or associated with an LDAP connection being deleted, 3233 renamed, or modified, and take appropriate actions to prevent 3234 insecure side effects. The way in which this is dealt with is 3235 implementation specific. Likewise, server implementors should plan 3236 for the possibility of an associated identities credentials 3237 becoming invalid." 3239 C.18.7 Section 9 3240 - Updated references to X.680 and X.690 3242 C.18.8 Section 11 3243 - Added IANA considerations 3245 C.18.9 Section A.2 3246 - Clarified that strongAuthRequired could be sent any time 3247 (including when credentials have been weakened or compromised. 3249 C.18.10 Appendix B 3250 - Added copyright to ASN.1 definition 3252 C.19 Changes made to draft-ietf-ldapbis-protocol-17.txt 3254 C.19.1 Section 4.1.1 3255 - Changed MAY to SHOULD when stating when a Notice of Disconnect is 3256 to be returned. 3258 C.19.2 Sections 4.1.10 and 4.5.3 3259 - Changed occurrences of URL to URI for format of referrals. 3261 C.19.3 Section 4.1.11 3262 - Dropped MUST imperative in paragraph 2, and added a SHOULD in 3263 paragraph 3 to align with [Keywords]. 3265 C.19.4 Section 4.2 3266 - Reworded section on string prep for simple passwords for clarity. 3268 C.19.5 Section 4.2.1 3269 - Dropped MUST imperative in paragraph 3 to align with [Keywords]. 3271 Lightweight Directory Access Protocol Version 3 3273 C.19.6 Section 4.2.2 3274 - Added SHALL NOT imperative to last paragraph to align with 3275 [Keywords]. 3277 C.19.7 Section 4.5.1 3278 - Added correct approxMatch semantics. 3280 C.19.8 Various 3281 - Added SHALL NOT imperative in regards to dereferencing aliases of 3282 base objects. 3284 C.19.9 Section 4.9 3285 - Allow modDN to fail when moving between naming contexts. 3287 C.19.10 Section 4.12 3288 - Added RECOMMENDED imperative to paragraph that talks about 3289 advertising supported extended operations. 3291 C.19.11 Section 4.1.11 3292 - Dropped all MAY imperative to align with [Keywords]. 3294 C.19.12 Various 3295 - Made it more obvious that Attribute contains at least one value, 3296 while PartialAttribute now allows zero values. Added appropriate 3297 references back to Attribute and PartialAttribute. 3299 Lightweight Directory Access Protocol Version 3 3301 Full Copyright Statement 3303 Copyright (C) The Internet Society (2003). All Rights Reserved. 3305 This document and translations of it may be copied and furnished to 3306 others, and derivative works that comment on or otherwise explain it 3307 or assist in its implementation may be prepared, copied, published 3308 and distributed, in whole or in part, without restriction of any 3309 kind, provided that the above copyright notice and this paragraph are 3310 included on all such copies and derivative works. However, this 3311 document itself may not be modified in any way, such as by removing 3312 the copyright notice or references to the Internet Society or other 3313 Internet organizations, except as needed for the purpose of 3314 developing Internet standards in which case the procedures for 3315 copyrights defined in the Internet Standards process must be 3316 followed, or as required to translate it into languages other than 3317 English. 3319 The limited permissions granted above are perpetual and will not be 3320 revoked by the Internet Society or its successors or assigns. 3322 This document and the information contained herein is provided on an 3323 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3324 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3325 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3326 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3327 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.