idnits 2.17.1 draft-ietf-ldapbis-protocol-24.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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. -- The draft header indicates that this document obsoletes RFC2251, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2830, but the abstract doesn't seem to mention this, which it should. 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: - attributes: the list of attributes that, along with those from the RDN, make up the content of the entry being added. Clients MAY or MAY NOT include the RDN attribute in this list. Clients MUST include the 'objectClass' attribute, and values of any mandatory attributes of the listed object classes. Clients MUST NOT supply NO-USER-MODIFICATION attributes such as the createTimestamp or creatorsName attributes, since the server maintains these automatically. -- 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 (May 2004) is 7258 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 2755 -- Looks like a reference, but probably isn't: '3' on line 2688 == Missing Reference: 'APPLICATION 0' is mentioned on line 2621, but not defined == Missing Reference: 'SASLprep' is mentioned on line 752, but not defined == Missing Reference: 'Stringprep' is mentioned on line 752, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 2636, but not defined -- Looks like a reference, but probably isn't: '7' on line 2672 == Missing Reference: 'APPLICATION 2' is mentioned on line 2641, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 2643, but not defined -- Looks like a reference, but probably isn't: '1' on line 2756 -- Looks like a reference, but probably isn't: '2' on line 2687 -- Looks like a reference, but probably isn't: '4' on line 2689 -- Looks like a reference, but probably isn't: '5' on line 2670 -- Looks like a reference, but probably isn't: '6' on line 2671 -- Looks like a reference, but probably isn't: '8' on line 2673 -- Looks like a reference, but probably isn't: '9' on line 2674 == Missing Reference: 'APPLICATION 4' is mentioned on line 2691, but not defined == Missing Reference: 'APPLICATION 19' is mentioned on line 2699, but not defined == Missing Reference: 'APPLICATION 5' is mentioned on line 2702, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 2704, but not defined == Missing Reference: 'APPLICATION 7' is mentioned on line 2713, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 2715, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 2721, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2723, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 2725, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2727, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 2733, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 2735, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 2739, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 2741, but not defined == Missing Reference: 'APPLICATION 23' is mentioned on line 2743, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 2747, but not defined -- Looks like a reference, but probably isn't: '10' on line 2749 -- Looks like a reference, but probably isn't: '11' on line 2752 == Missing Reference: 'APPLICATION 25' is mentioned on line 2754, but not defined == Missing Reference: 'Keywords' is mentioned on line 2906, but not defined == Unused Reference: 'IP' is defined on line 2134, but no explicit reference was found in the text == Unused Reference: 'SASLPrep' is defined on line 2165, but no explicit reference was found in the text == Unused Reference: 'StringPrep' is defined on line 2169, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- 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-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- 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-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-sasl-saslprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- No information found for draft-hoffman-rfc3454bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'StringPrep' -- 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 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 4 errors (**), 0 flaws (~~), 32 warnings (==), 42 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Editor: J. Sermersheim 2 Intended Category: Standard Track Novell, Inc 3 Document: draft-ietf-ldapbis-protocol-24.txt May 2004 4 Obsoletes: RFCs 2251, 2830, 3771 6 LDAP: The Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. Technical discussion of this 28 document will take place on the IETF LDAP Revision Working Group 29 (LDAPbis) mailing list . Please send 30 editorial comments directly to the editor . 32 Abstract 34 This document describes the protocol elements, along with their 35 semantics and encodings, of the Lightweight Directory Access Protocol 36 (LDAP). LDAP provides access to distributed directory services that 37 act in accordance with X.500 data and service models. These protocol 38 elements are based on those described in the X.500 Directory Access 39 Protocol (DAP). 41 Table of Contents 43 1. Introduction....................................................2 44 1.1. Relationship to Obsolete Specifications.......................3 45 2. Conventions.....................................................3 46 3. Protocol Model..................................................4 47 4. Elements of Protocol............................................4 48 4.1. Common Elements...............................................5 49 4.1.1. Message Envelope............................................5 50 4.1.2. String Types................................................6 51 Lightweight Directory Access Protocol Version 3 53 4.1.3. Distinguished Name and Relative Distinguished Name..........7 54 4.1.4. Attribute Descriptions......................................7 55 4.1.5. Attribute Value.............................................7 56 4.1.6. Attribute Value Assertion...................................8 57 4.1.7. Attribute and PartialAttribute..............................8 58 4.1.8. Matching Rule Identifier....................................8 59 4.1.9. Result Message..............................................9 60 4.1.10. Referral..................................................10 61 4.1.11. Controls..................................................12 62 4.2. Bind Operation...............................................13 63 4.3. Unbind Operation.............................................16 64 4.4. Unsolicited Notification.....................................16 65 4.5. Search Operation.............................................18 66 4.6. Modify Operation.............................................26 67 4.7. Add Operation................................................28 68 4.8. Delete Operation.............................................29 69 4.9. Modify DN Operation..........................................29 70 4.10. Compare Operation...........................................30 71 4.11. Abandon Operation...........................................31 72 4.12. Extended Operation..........................................32 73 4.13. IntermediateResponse Message................................33 74 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......34 75 4.13.2. Usage with LDAP Request Controls..........................34 76 4.14. StartTLS Operation..........................................35 77 5. Protocol Encoding, Connection, and Transfer....................37 78 5.1 Operation and LDAP exchange Relationship......................37 79 5.2. Protocol Encoding............................................38 80 5.3. Transmission Control Protocol (TCP)..........................38 81 6. Security Considerations........................................38 82 7. Acknowledgements...............................................39 83 8. Normative References...........................................40 84 9. Informative References.........................................41 85 10. IANA Considerations...........................................41 86 11. Editor's Address..............................................42 87 Appendix A - LDAP Result Codes....................................43 88 A.1 Non-Error Result Codes........................................43 89 A.2 Result Codes..................................................43 90 Appendix B - Complete ASN.1 Definition............................48 91 Appendix C - Changes..............................................54 92 C.1 Changes made to RFC 2251:.....................................54 93 C.2 Changes made to RFC 2830:.....................................59 94 C.3 Changes made to RFC 3771:.....................................60 96 1. Introduction 98 The Directory is "a collection of open systems cooperating to provide 99 directory services" [X.500]. A directory user, which may be a human 100 or other entity, accesses the Directory through a client (or 101 Directory User Agent (DUA)). The client, on behalf of the directory 102 user, interacts with one or more servers (or Directory System Agents 103 (DSA)). Clients interact with servers using a directory access 104 protocol. 106 Lightweight Directory Access Protocol Version 3 108 This document details the protocol elements of the Lightweight 109 Directory Access Protocol (LDAP), along with their semantics. 110 Following the description of protocol elements, it describes the way 111 in which the protocol elements are encoded and transferred. 113 1.1. Relationship to Obsolete Specifications 115 This document is an integral part of the LDAP Technical Specification 116 [Roadmap] which obsoletes the previously defined LDAP technical 117 specification, RFC 3377, in its entirety. 119 This document obsoletes all of RFC 2251 except the following: 120 Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 121 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are 122 obsoleted by [Models]. 123 Section 3.3 is obsoleted by [Roadmap]. 124 Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth]. 126 Appendix C.1 summarizes substantive changes to the remaining 127 sections. 129 This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The 130 remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 131 summarizes substantive changes to the remaining sections. 133 This document also obsoletes RFC 3771 in entirety. 135 2. Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 139 to be interpreted as described in [Keyword]. 141 The term "connection" refers to the underlying transport service used 142 to carry the protocol exchange. 144 The term "LDAP exchange" refers to application layer where LDAP PDUs 145 are exchanged between protocol peers. 147 The term "TLS layer" refers to a layer inserted between the 148 connection and the LDAP exchange that utilizes [TLS] to protect the 149 exchange of LDAP PDUs. 151 The term "SASL layer" refers to a layer inserted between the 152 connection and the LDAP exchange that utilizes [SASL] to protect the 153 exchange of LDAP PDUs. 155 See the table in Section 5 for an illustration of these four terms. 157 The term "TLS-protected LDAP exchange" refers to an LDAP exchange 158 protected by a TLS-layer. 160 Lightweight Directory Access Protocol Version 3 162 The term "association" refers to the association of the LDAP exchange 163 and its current authentication and authorization state. 165 3. Protocol Model 167 The general model adopted by this protocol is one of clients 168 performing protocol operations against servers. In this model, a 169 client transmits a protocol request describing the operation to be 170 performed to a server. The server is then responsible for performing 171 the necessary operation(s) in the Directory. Upon completion of an 172 operation, the server typically returns a response containing 173 appropriate data to the requesting client. 175 Although servers are required to return responses whenever such 176 responses are defined in the protocol, there is no requirement for 177 synchronous behavior on the part of either clients or servers. 178 Requests and responses for multiple operations generally may be 179 exchanged between a client and server in any order, provided the 180 client eventually receives a response for every request that requires 181 one. 183 The core protocol operations defined in this document can be mapped 184 to a subset of the X.500 (1993) Directory Abstract Service [X.511]. 185 However there is not a one-to-one mapping between LDAP operations and 186 X.500 Directory Access Protocol (DAP) operations. Server 187 implementations acting as a gateway to X.500 directories may need to 188 make multiple DAP requests to service a single LDAP request. 190 4. Elements of Protocol 192 The protocol is described using Abstract Syntax Notation One 193 ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding 194 Rules ([BER]). Section 5 specifies how the protocol elements are 195 encoded and transferred. 197 In order to support future extensions to this protocol, extensibility 198 is implied where it is allowed per ASN.1 (i.e. sequence, set, choice, 199 and enumerated types are extensible). In addition, ellipses (...) 200 have been supplied in ASN.1 types that are explicitly extensible as 201 discussed in [LDAPIANA]. Because of the implied extensibility, 202 clients and servers MUST (unless otherwise specified) ignore trailing 203 SEQUENCE components whose tags they do not recognize. 205 Changes to the protocol other than through the extension mechanisms 206 described here require a different version number. A client indicates 207 the version it is using as part of the bind request, described in 208 Section 4.2. If a client has not sent a bind, the server MUST assume 209 the client is using version 3 or later. 211 Clients may determine the protocol versions a server supports by 212 reading the 'supportedLDAPVersion' attribute from the root DSE (DSA- 213 Specific Entry) [Models]. 215 Lightweight Directory Access Protocol Version 3 217 4.1. Common Elements 219 This section describes the LDAPMessage envelope Protocol Data Unit 220 (PDU) format, as well as data type definitions, which are used in the 221 protocol operations. 223 4.1.1. Message Envelope 225 For the purposes of protocol exchanges, all protocol operations are 226 encapsulated in a common envelope, the LDAPMessage, which is defined 227 as follows: 229 LDAPMessage ::= SEQUENCE { 230 messageID MessageID, 231 protocolOp CHOICE { 232 bindRequest BindRequest, 233 bindResponse BindResponse, 234 unbindRequest UnbindRequest, 235 searchRequest SearchRequest, 236 searchResEntry SearchResultEntry, 237 searchResDone SearchResultDone, 238 searchResRef SearchResultReference, 239 modifyRequest ModifyRequest, 240 modifyResponse ModifyResponse, 241 addRequest AddRequest, 242 addResponse AddResponse, 243 delRequest DelRequest, 244 delResponse DelResponse, 245 modDNRequest ModifyDNRequest, 246 modDNResponse ModifyDNResponse, 247 compareRequest CompareRequest, 248 compareResponse CompareResponse, 249 abandonRequest AbandonRequest, 250 extendedReq ExtendedRequest, 251 extendedResp ExtendedResponse, 252 intermediateResponse IntermediateResponse 253 ... }, 254 controls [0] Controls OPTIONAL } 256 MessageID ::= INTEGER (0 .. maxInt) 258 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 260 The ASN.1 type Controls is defined in Section 4.1.11. 262 The function of the LDAPMessage is to provide an envelope containing 263 common fields required in all protocol exchanges. At this time the 264 only common fields are the message ID and the controls. 266 If the server receives a PDU from the client in which the LDAPMessage 267 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 268 Lightweight Directory Access Protocol Version 3 270 the tag of the protocolOp is not recognized as a request, or the 271 encoding structures or lengths of data fields are found to be 272 incorrect, then the server SHOULD return the Notice of Disconnection 273 described in Section 4.4.1, with the resultCode set to protocolError, 274 and MUST immediately close the connection. 276 In other cases where the client or server cannot parse a PDU, it 277 SHOULD abruptly close the connection where further communication 278 (including providing notice) would be pernicious. Otherwise, server 279 implementations MUST return an appropriate response to the request, 280 with the resultCode set to protocolError. 282 4.1.1.1. Message ID 284 All LDAPMessage envelopes encapsulating responses contain the 285 messageID value of the corresponding request LDAPMessage. 287 The message ID of a request MUST have a non-zero value different from 288 the values of any other requests outstanding in the LDAP association 289 of which this message is a part. The zero value is reserved for the 290 unsolicited notification message. 292 Typical clients increment a counter for each request. 294 A client MUST NOT send a request with the same message ID as an 295 earlier request on the same LDAP association unless it can be 296 determined that the server is no longer servicing the earlier request 297 (e.g. after the final response is received, or a subsequent bind 298 completes). Otherwise the behavior is undefined. For this purpose, 299 note that abandon and abandoned operations do not send responses. 301 4.1.2. String Types 303 The LDAPString is a notational convenience to indicate that, although 304 strings of LDAPString type encode as ASN.1 OCTET STRING types, the 305 [ISO10646] character set (a superset of [Unicode]) is used, encoded 306 following the [UTF-8] algorithm. Note that Unicode characters U+0000 307 through U+007F are the same as ASCII 0 through 127, respectively, and 308 have the same single octet UTF-8 encoding. Other Unicode characters 309 have a multiple octet UTF-8 encoding. 311 LDAPString ::= OCTET STRING -- UTF-8 encoded, 312 -- [ISO10646] characters 314 The LDAPOID is a notational convenience to indicate that the 315 permitted value of this string is a (UTF-8 encoded) dotted-decimal 316 representation of an OBJECT IDENTIFIER. Although an LDAPOID is 317 encoded as an OCTET STRING, values are limited to the definition of 318 given in Section 1.4 of [Models]. 320 LDAPOID ::= OCTET STRING -- Constrained to [Models] 321 Lightweight Directory Access Protocol Version 3 323 For example, 325 1.3.6.1.4.1.1466.1.2.3 327 4.1.3. Distinguished Name and Relative Distinguished Name 329 An LDAPDN is defined to be the representation of a Distinguished Name 330 (DN) after encoding according to the specification in [LDAPDN]. 332 LDAPDN ::= LDAPString 333 -- Constrained to [LDAPDN] 335 A RelativeLDAPDN is defined to be the representation of a Relative 336 Distinguished Name (RDN) after encoding according to the 337 specification in [LDAPDN]. 339 RelativeLDAPDN ::= LDAPString 340 -- Constrained to [LDAPDN] 342 4.1.4. Attribute Descriptions 344 The definition and encoding rules for attribute descriptions are 345 defined in Section 2.5 of [Models]. Briefly, an attribute description 346 is an attribute type and zero or more options. 348 AttributeDescription ::= LDAPString 349 -- Constrained to 350 -- [Models] 352 4.1.5. Attribute Value 354 A field of type AttributeValue is an OCTET STRING containing an 355 encoded attribute value. The attribute value is encoded according to 356 the LDAP-specific encoding definition of its corresponding syntax. 357 The LDAP-specific encoding definitions for different syntaxes and 358 attribute types may be found in other documents and in particular 359 [Syntaxes]. 361 AttributeValue ::= OCTET STRING 363 Note that there is no defined limit on the size of this encoding; 364 thus protocol values may include multi-megabyte attribute values 365 (e.g. photographs). 367 Attribute values may be defined which have arbitrary and non- 368 printable syntax. Implementations MUST NOT display nor attempt to 369 decode an attribute value if its syntax is not known. The 370 implementation may attempt to discover the subschema of the source 371 entry, and retrieve the descriptions of 'attributeTypes' from it 372 [Models]. 374 Lightweight Directory Access Protocol Version 3 376 Clients MUST only send attribute values in a request that are valid 377 according to the syntax defined for the attributes. 379 4.1.6. Attribute Value Assertion 381 The AttributeValueAssertion (AVA) type definition is similar to the 382 one in the X.500 Directory standards. It contains an attribute 383 description and a matching rule ([Models Section 4.1.3) assertion 384 value suitable for that type. Elements of this type are typically 385 used to assert that the value in assertionValue matches a value of an 386 attribute. 388 AttributeValueAssertion ::= SEQUENCE { 389 attributeDesc AttributeDescription, 390 assertionValue AssertionValue } 392 AssertionValue ::= OCTET STRING 394 The syntax of the AssertionValue depends on the context of the LDAP 395 operation being performed. For example, the syntax of the EQUALITY 396 matching rule for an attribute is used when performing a Compare 397 operation. Often this is the same syntax used for values of the 398 attribute type, but in some cases the assertion syntax differs from 399 the value syntax. See objectIdentiferFirstComponentMatch in 400 [Syntaxes] for an example. 402 4.1.7. Attribute and PartialAttribute 404 Attributes and partial attributes consist of an attribute description 405 and attribute values. A PartialAttribute allows zero values, while 406 Attribute requires at least one value. 408 PartialAttribute ::= SEQUENCE { 409 type AttributeDescription, 410 vals SET OF value AttributeValue } 412 Attribute ::= PartialAttribute(WITH COMPONENTS { 413 ..., 414 vals (SIZE(1..MAX))}) 416 No two attribute values may be equivalent as described by Section 2.3 417 of [Models]. The set of attribute values is unordered. 418 Implementations MUST NOT rely upon the ordering being repeatable. 420 4.1.8. Matching Rule Identifier 422 Matching rules are defined in Section 4.1.3 of [Models]. A matching 423 rule is identified in the protocol by the printable representation of 424 either its , or one of its short name descriptors 425 [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'. 427 Lightweight Directory Access Protocol Version 3 429 MatchingRuleId ::= LDAPString 431 4.1.9. Result Message 433 The LDAPResult is the construct used in this protocol to return 434 success or failure indications from servers to clients. To various 435 requests, servers will return responses of LDAPResult or responses 436 containing the components of LDAPResult to indicate the final status 437 of a protocol operation request. 439 LDAPResult ::= SEQUENCE { 440 resultCode ENUMERATED { 441 success (0), 442 operationsError (1), 443 protocolError (2), 444 timeLimitExceeded (3), 445 sizeLimitExceeded (4), 446 compareFalse (5), 447 compareTrue (6), 448 authMethodNotSupported (7), 449 strongAuthRequired (8), 450 -- 9 reserved -- 451 referral (10), 452 adminLimitExceeded (11), 453 unavailableCriticalExtension (12), 454 confidentialityRequired (13), 455 saslBindInProgress (14), 456 noSuchAttribute (16), 457 undefinedAttributeType (17), 458 inappropriateMatching (18), 459 constraintViolation (19), 460 attributeOrValueExists (20), 461 invalidAttributeSyntax (21), 462 -- 22-31 unused -- 463 noSuchObject (32), 464 aliasProblem (33), 465 invalidDNSyntax (34), 466 -- 35 reserved for undefined isLeaf -- 467 aliasDereferencingProblem (36), 468 -- 37-47 unused -- 469 inappropriateAuthentication (48), 470 invalidCredentials (49), 471 insufficientAccessRights (50), 472 busy (51), 473 unavailable (52), 474 unwillingToPerform (53), 475 loopDetect (54), 476 -- 55-63 unused -- 477 namingViolation (64), 478 objectClassViolation (65), 479 notAllowedOnNonLeaf (66), 480 notAllowedOnRDN (67), 481 entryAlreadyExists (68), 483 Lightweight Directory Access Protocol Version 3 485 objectClassModsProhibited (69), 486 -- 70 reserved for CLDAP -- 487 affectsMultipleDSAs (71), 488 -- 72-79 unused -- 489 other (80), 490 ... }, 491 matchedDN LDAPDN, 492 diagnosticMessage LDAPString, 493 referral [3] Referral OPTIONAL } 495 The resultCode enumeration is extensible as defined in Section 3.6 of 496 [LDAPIANA]. The meanings of the listed result codes are given in 497 Appendix A. If a server detects multiple errors for an operation, 498 only one result code is returned. The server should return the result 499 code that best indicates the nature of the error encountered. 501 The diagnosticMessage field of this construct may, at the server's 502 option, be used to return a string containing a textual, human- 503 readable (terminal control and page formatting characters should be 504 avoided) diagnostic message. As this diagnostic message is not 505 standardized, implementations MUST NOT rely on the values returned. 506 If the server chooses not to return a textual diagnostic, the 507 diagnosticMessage field MUST be empty. 509 For certain result codes (typically, but not restricted to 510 noSuchObject, aliasProblem, invalidDNSyntax and 511 aliasDereferencingProblem), the matchedDN field is set to the name of 512 the lowest entry (object or alias) in the Directory that was matched. 513 If no aliases were dereferenced while attempting to locate the entry, 514 this will be a truncated form of the name provided, or if aliases 515 were dereferenced, of the resulting name, as defined in Section 12.5 516 of [X.511]. Otherwise the matchedDN field is empty. 518 4.1.10. Referral 520 The referral result code indicates that the contacted server cannot 521 or will not perform the operation and that one or more other servers 522 may be able to. Reasons for this include: 524 - The target entry of the request is not held locally, but the 525 server has knowledge of its possible existence elsewhere. 527 - The operation is restricted on this server -- perhaps due to a 528 read-only copy of an entry to be modified. 530 The referral field is present in an LDAPResult if the resultCode 531 field value is referral, and absent with all other result codes. It 532 contains one or more references to one or more servers or services 533 that may be accessed via LDAP or other protocols. Referrals can be 534 returned in response to any operation request (except unbind and 535 abandon which do not have responses). At least one URI MUST be 536 present in the Referral. 538 Lightweight Directory Access Protocol Version 3 540 During a search operation, after the baseObject is located, and 541 entries are being evaluated, the referral is not returned. Instead, 542 continuation references, described in Section 4.5.3, are returned 543 when other servers would need to be contacted to complete the 544 operation. 546 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 548 URI ::= LDAPString -- limited to characters permitted in 549 -- URIs 551 If the client wishes to progress the operation, it MUST follow the 552 referral by contacting one of the supported services. If multiple 553 URIs are present, the client assumes that any supported URI may be 554 used to progress the operation. 556 Protocol peers that follow referrals MUST ensure that they do not 557 loop between servers. They MUST NOT repeatedly contact the same 558 server for the same request with the same target entry name, scope 559 and filter. Some implementations use a counter that is incremented 560 each time referral handling occurs for an operation, and these kinds 561 of implementations MUST be able to handle at least ten nested 562 referrals between the root and a leaf entry. 564 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 565 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 567 When an LDAP URL is used, the following instructions are followed: 569 - If an alias was dereferenced, the part of the URL MUST be 570 present, with the new target object name. UTF-8 encoded characters 571 appearing in the string representation of a DN or search filter 572 may not be legal for URLs (e.g. spaces) and MUST be escaped using 573 the % method in [URI]. 575 - It is RECOMMENDED that the part be present to avoid 576 ambiguity. 578 - If the part is present, the client MUST use this name in its 579 next request to progress the operation, and if it is not present 580 the client will use the same name as in the original request. 582 - Some servers (e.g. participating in distributed indexing) may 583 provide a different filter in a URL of a referral for a search 584 operation. 586 - If the part of the LDAP URL is present, the client MUST 587 use this filter in its next request to progress this search, and 588 if it is not present the client MUST use the same filter as it 589 used for that search. 591 - For search, it is RECOMMENDED that the part be present to 592 avoid ambiguity. 594 Lightweight Directory Access Protocol Version 3 596 - If the part is missing, the scope of the original search 597 is used by the client to progress the operation. 599 - Other aspects of the new request may be the same as or different 600 from the request which generated the referral. 602 Other kinds of URIs may be returned. The syntax and semantics of such 603 URIs is left to future specifications. Clients may ignore URIs that 604 they do not support. 606 4.1.11. Controls 608 Controls provide a mechanism whereby the semantics and arguments of 609 existing LDAP operations may be extended. One or more controls may be 610 attached to a single LDAP message. A control only affects the 611 semantics of the message it is attached to. 613 Controls sent by clients are termed 'request controls' and those sent 614 by servers are termed 'response controls'. 616 Controls ::= SEQUENCE OF control Control 618 Control ::= SEQUENCE { 619 controlType LDAPOID, 620 criticality BOOLEAN DEFAULT FALSE, 621 controlValue OCTET STRING OPTIONAL } 623 The controlType field is the dotted-decimal representation of an 624 OBJECT IDENTIFIER which uniquely identifies the control. This 625 provides unambiguous naming of controls. Often, response control(s) 626 solicited by a request control share controlType values with the 627 request control. 629 The criticality field only has meaning in controls attached to 630 request messages (except unbindRequest). For controls attached to 631 response messages and the unbindRequest, the criticality field SHOULD 632 be FALSE, and MUST be ignored by the receiving protocol peer. A value 633 of TRUE indicates that it is unacceptable to perform the operation 634 without applying the semantics of the control and FALSE otherwise. 635 Specifically, the criticality field is applied as follows: 637 - Regardless of the value of the criticality field, if the server 638 recognizes the control type and it is appropriate for the 639 operation, the server is to make use of the control when 640 performing the operation. 642 - If the server does not recognize the control type or it is not 643 appropriate for the operation, and the criticality field is TRUE, 644 the server MUST NOT perform the operation, and for operations that 645 have a response message, MUST return unavailableCriticalExtension 646 in the resultCode. 648 Lightweight Directory Access Protocol Version 3 650 - If the server does not recognize the control type or it is not 651 appropriate for the operation, and the criticality field is FALSE, 652 the server MUST ignore the control. 654 The controlValue may contain information associated with the 655 controlType. Its format is defined by the specification of the 656 control. Implementations MUST be prepared to handle arbitrary 657 contents of the controlValue octet string, including zero bytes. It 658 is absent only if there is no value information which is associated 659 with a control of its type. When a controlValue is defined in terms 660 of ASN.1, and BER encoded according to Section 5.2, it also follows 661 the extensibility rules in Section 4. 663 Servers list the controlType of all request controls they recognize 664 in the supportedControl attribute in the root DSE (Section 5.1 of 665 [Models]). 667 Controls SHOULD NOT be combined unless the semantics of the 668 combination has been specified. The semantics of control 669 combinations, if specified, are generally found in the control 670 specification most recently published. When a combination of controls 671 is encountered whose semantics are not defined (or not known), the 672 operation fails with protocolError. Additionally, unless order- 673 dependent semantics are given in a specification, the order of a 674 combination of controls in the SEQUENCE is ignored. Where the order 675 is to be ignored but cannot be ignored by the server, the operation 676 fails with protocolError. 678 This document does not specify any controls. Controls may be 679 specified in other documents. Documents detailing control extensions 680 are to provide for each control: 682 - the OBJECT IDENTIFIER assigned to the control, 684 - direction as to what value the sender should provide for the 685 criticality field (note: the semantics of the criticality field 686 are defined above should not be altered by the control's 687 specification), 689 - whether information is to be present in the controlValue field, 690 and if so, the format of the controlValue contents, 692 - the semantics of the control, and 694 - optionally, semantics regarding the combination of the control 695 with other controls. 697 4.2. Bind Operation 699 The function of the Bind Operation is to allow authentication 700 information to be exchanged between the client and server. The Bind 701 operation should be thought of as the "authenticate" operation. 703 Lightweight Directory Access Protocol Version 3 705 Operational, authentication, and security-related semantics of this 706 operation are given in [AuthMeth]. 708 The Bind Request is defined as follows: 710 BindRequest ::= [APPLICATION 0] SEQUENCE { 711 version INTEGER (1 .. 127), 712 name LDAPDN, 713 authentication AuthenticationChoice } 715 AuthenticationChoice ::= CHOICE { 716 simple [0] OCTET STRING, 717 -- 1 and 2 reserved 718 sasl [3] SaslCredentials, 719 ... } 721 SaslCredentials ::= SEQUENCE { 722 mechanism LDAPString, 723 credentials OCTET STRING OPTIONAL } 725 Fields of the Bind Request are: 727 - version: A version number indicating the version of the protocol 728 to be used in this LDAP association. This document describes 729 version 3 of the protocol. There is no version negotiation. The 730 client sets this field to the version it desires. If the server 731 does not support the specified version, it MUST respond with 732 protocolError in the resultCode field of the BindResponse. 734 - name: The name of the Directory object that the client wishes to 735 bind as. This field may take on a null value (a zero length 736 string) for the purposes of anonymous binds ([AuthMeth] Section 737 5.1) or when using Simple Authentication and Security Layer [SASL] 738 authentication ([AuthMeth] Section 3.3.2). Where the server 739 attempts to locate the named object, it SHALL NOT perform alias 740 dereferencing. 742 - authentication: information used in authentication. This type is 743 extensible as defined in Section 3.7 of [LDAPIANA]. Servers that 744 do not support a choice supplied by a client return 745 authMethodNotSupported in the resultCode field of the 746 BindResponse. 748 Textual passwords (consisting of a character sequence with a known 749 character set and encoding) transferred to the server using the 750 simple AuthenticationChoice SHALL be transferred as [UTF-8] 751 encoded [Unicode]. Prior to transfer, clients SHOULD prepare text 752 passwords by applying the [SASLprep] profile of the [Stringprep] 753 algorithm. Passwords consisting of other data (such as random 754 octets) MUST NOT be altered. The determination of whether a 755 password is textual is a local client matter. 757 Authorization is the process of enforcing policy while performing 758 operations. Among other things, the process of authorization takes as 759 Lightweight Directory Access Protocol Version 3 761 input authentication information obtained during the bind operation 762 and/or other acts of authentication (such as lower layer security 763 services). 765 4.2.1. Processing of the Bind Request 767 Before processing a BindRequest, all outstanding operations MUST 768 either complete or be abandoned. The server may either wait for the 769 outstanding operations to complete, or abandon them. The server then 770 proceeds to authenticate the client in either a single-step, or 771 multi-step bind process. Each step requires the server to return a 772 BindResponse to indicate the status of authentication. 774 After sending a BindRequest, clients MUST NOT send further LDAP PDUs 775 until receiving the BindResponse. Similarly, servers SHOULD NOT 776 process or respond to requests received while processing a 777 BindRequest. 779 If the client did not bind before sending a request and receives an 780 operationsError to that request, it may then send a Bind Request. If 781 this also fails or the client chooses not to bind on the existing 782 LDAP exchange, it may close the connection, reopen it and begin again 783 by first sending a PDU with a Bind Request. This will aid in 784 interoperating with servers implementing other versions of LDAP. 786 Clients may send multiple Bind Requests on an LDAP exchange to change 787 the authentication and/or security associations or to complete a 788 multi-stage bind process. Authentication from earlier binds is 789 subsequently ignored. 791 For some SASL authentication mechanisms, it may be necessary for the 792 client to invoke the BindRequest multiple times ([AuthMeth] Section 793 8.2). Clients MUST NOT invoke operations between two Bind Requests 794 made as part of a multi-stage bind. 796 A client may abort a SASL bind negotiation by sending a BindRequest 797 with a different value in the mechanism field of SaslCredentials, or 798 an AuthenticationChoice other than sasl. 800 If the client sends a BindRequest with the sasl mechanism field as an 801 empty string, the server MUST return a BindResponse with 802 authMethodNotSupported as the resultCode. This will allow clients to 803 abort a negotiation if it wishes to try again with the same SASL 804 mechanism. 806 4.2.2. Bind Response 808 The Bind Response is defined as follows. 810 BindResponse ::= [APPLICATION 1] SEQUENCE { 811 COMPONENTS OF LDAPResult, 812 serverSaslCreds [7] OCTET STRING OPTIONAL } 813 Lightweight Directory Access Protocol Version 3 815 BindResponse consists simply of an indication from the server of the 816 status of the client's request for authentication. 818 A successful bind operation is indicated by a BindResponse with a 819 resultCode set to success. Otherwise, an appropriate result code is 820 set in the BindResponse. For bind, the protocolError result code may 821 be used to indicate that the version number supplied by the client is 822 unsupported. 824 If the client receives a BindResponse where the resultCode field is 825 protocolError, it is to assume that the server does not support this 826 version of LDAP. While the client may be able proceed with another 827 version of this protocol (this may or may not require closing and re- 828 establishing the connection), how to proceed with another version of 829 this protocol is beyond the scope of this document. Clients which are 830 unable or unwilling to proceed SHOULD close the connection. 832 The serverSaslCreds field is used as part of a SASL-defined bind 833 mechanism to allow the client to authenticate the server to which it 834 is communicating, or to perform "challenge-response" authentication. 835 If the client bound with the simple choice, or the SASL mechanism 836 does not require the server to return information to the client, then 837 this field SHALL NOT be included in the BindResponse. 839 4.3. Unbind Operation 841 The function of the Unbind Operation is to terminate an LDAP 842 association and close the connection. The Unbind operation is not the 843 antithesis of the Bind operation as the name implies. The naming of 844 these operations is historical. The Unbind operation should be 845 thought of as the "quit" operation. 847 The Unbind Operation is defined as follows: 849 UnbindRequest ::= [APPLICATION 2] NULL 851 The Unbind Operation has no response defined. Upon transmission of 852 the UnbindRequest, each protocol peer is to consider the LDAP 853 association terminated, MUST cease transmission of messages to the 854 other peer, and MUST close the connection. Outstanding operations are 855 handled as specified in Section 5.1. 857 4.4. Unsolicited Notification 859 An unsolicited notification is an LDAPMessage sent from the server to 860 the client which is not in response to any LDAPMessage received by 861 the server. It is used to signal an extraordinary condition in the 862 server or in the LDAP exchange or connection between the client and 863 the server. The notification is of an advisory nature, and the server 864 will not expect any response to be returned from the client. 866 Lightweight Directory Access Protocol Version 3 868 The unsolicited notification is structured as an LDAPMessage in which 869 the messageID is zero and protocolOp is of the extendedResp form (See 870 Section 4.12). The responseName field of the ExtendedResponse always 871 contains an LDAPOID which is unique for this notification. 873 One unsolicited notification (Notice of Disconnection) is defined in 874 this document. The specification of an unsolicited notification 875 consists of: 877 - the OBJECT IDENTIFIER assigned to the notification (to be 878 specified in the responseName, 880 - the format of the contents (if any) of the responseValue, 882 - the circumstances which will cause the notification to be 883 returned, and 885 - the semantics of the operation. 887 4.4.1. Notice of Disconnection 889 This notification may be used by the server to advise the client that 890 the server is about to close the connection due to an error 891 condition. This notification is intended to assist clients in 892 distinguishing between an error condition and a transient network 893 failure. Note that this notification is not a response to an unbind 894 requested by the client. Outstanding operations are handled as 895 specified in Section 5.1. 897 The responseName is 1.3.6.1.4.1.1466.20036, the response field is 898 absent, and the resultCode is used to indicate the reason for the 899 disconnection. 901 The following result codes have these meanings when used in this 902 notification: 904 - protocolError: The server has received data from the client in 905 which the LDAPMessage structure could not be parsed. 907 - strongAuthRequired: The server has detected that an established 908 security association between the client and server has 909 unexpectedly failed or been compromised, or that the server now 910 requires the client to authenticate using a strong(er) mechanism. 912 - unavailable: This server will stop accepting new connections and 913 operations on all existing LDAP exchanges, and be unavailable for 914 an extended period of time. The client may make use of an 915 alternative server. 917 Upon transmission of the Notice of Disconnection, the server is to 918 consider the LDAP association terminated, MUST cease transmission of 919 messages to the client, and MUST close the connection. 921 Lightweight Directory Access Protocol Version 3 923 4.5. Search Operation 925 The Search Operation is used to request a server to return, subject 926 to access controls and other restrictions, a set of entries matching 927 a complex search criterion. This can be used to read attributes from 928 a single entry, from entries immediately subordinate to a particular 929 entry, or a whole subtree of entries. 931 4.5.1. Search Request 933 The Search Request is defined as follows: 935 SearchRequest ::= [APPLICATION 3] SEQUENCE { 936 baseObject LDAPDN, 937 scope ENUMERATED { 938 baseObject (0), 939 singleLevel (1), 940 wholeSubtree (2) }, 941 derefAliases ENUMERATED { 942 neverDerefAliases (0), 943 derefInSearching (1), 944 derefFindingBaseObj (2), 945 derefAlways (3) }, 946 sizeLimit INTEGER (0 .. maxInt), 947 timeLimit INTEGER (0 .. maxInt), 948 typesOnly BOOLEAN, 949 filter Filter, 950 attributes AttributeSelection } 952 AttributeSelection ::= SEQUENCE OF selector LDAPString 953 -- The LDAPString is constrained to 954 -- below 956 Filter ::= CHOICE { 957 and [0] SET SIZE (1..MAX) OF filter Filter, 958 or [1] SET SIZE (1..MAX) OF filter Filter, 959 not [2] Filter, 960 equalityMatch [3] AttributeValueAssertion, 961 substrings [4] SubstringFilter, 962 greaterOrEqual [5] AttributeValueAssertion, 963 lessOrEqual [6] AttributeValueAssertion, 964 present [7] AttributeDescription, 965 approxMatch [8] AttributeValueAssertion, 966 extensibleMatch [9] MatchingRuleAssertion } 968 SubstringFilter ::= SEQUENCE { 969 type AttributeDescription, 970 -- initial and final can occur at most once 971 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 972 initial [0] AssertionValue, 973 any [1] AssertionValue, 974 final [2] AssertionValue } } 976 Lightweight Directory Access Protocol Version 3 978 MatchingRuleAssertion ::= SEQUENCE { 979 matchingRule [1] MatchingRuleId OPTIONAL, 980 type [2] AttributeDescription OPTIONAL, 981 matchValue [3] AssertionValue, 982 dnAttributes [4] BOOLEAN DEFAULT FALSE } 984 Fields of the Search Request are: 986 - baseObject: The name of the base object entry relative to which 987 the search is to be performed. 989 - scope: Specifies the scope of the search to be performed. The 990 semantics (as described in [X.511]) of the possible values of this 991 field are: 993 baseObject: The scope is constrained to the entry named by 994 baseObject. 996 singleLevel: The scope is constrained to the immediate 997 subordinates of the entry named by baseObject. 999 wholeSubtree: the scope is constrained to the entry named by 1000 the baseObject, and all its subordinates. 1002 - derefAliases: An indicator as to how alias entries (as defined in 1003 [Models]) are to be handled in searching. The semantics of the 1004 possible values of this field are: 1006 neverDerefAliases: Do not dereference aliases in searching or 1007 in locating the base object of the search. 1009 derefInSearching: While searching, dereference any alias entry 1010 subordinate to the base object which is also in the search 1011 scope. The filter is applied to the dereferenced object(s). If 1012 the search scope is wholeSubtree, the search continues in the 1013 subtree of any dereferenced object. Aliases in that subtree are 1014 also dereferenced. Servers SHOULD eliminate duplicate entries 1015 that arise due to alias dereferencing while searching. 1017 derefFindingBaseObj: Dereference aliases in locating the base 1018 object of the search, but not when searching subordinates of 1019 the base object. 1021 derefAlways: Dereference aliases both in searching and in 1022 locating the base object of the search. 1023 Servers MUST detect looping while dereferencing aliases in order 1024 to prevent denial of service attacks of this nature. 1026 - sizeLimit: A size limit that restricts the maximum number of 1027 entries to be returned as a result of the search. A value of zero 1028 in this field indicates that no client-requested size limit 1029 Lightweight Directory Access Protocol Version 3 1031 restrictions are in effect for the search. Servers may also 1032 enforce a maximum number of entries to return. 1034 - timeLimit: A time limit that restricts the maximum time (in 1035 seconds) allowed for a search. A value of zero in this field 1036 indicates that no client-requested time limit restrictions are in 1037 effect for the search. Servers may also enforce a maximum time 1038 limit for the search. 1040 - typesOnly: An indicator as to whether search results are to 1041 contain both attribute descriptions and values, or just attribute 1042 descriptions. Setting this field to TRUE causes only attribute 1043 descriptions (no values) to be returned. Setting this field to 1044 FALSE causes both attribute descriptions and values to be 1045 returned. 1047 - filter: A filter that defines the conditions that must be 1048 fulfilled in order for the search to match a given entry. 1050 The 'and', 'or' and 'not' choices can be used to form combinations 1051 of filters. At least one filter element MUST be present in an 1052 'and' or 'or' choice. The others match against individual 1053 attribute values of entries in the scope of the search. 1054 (Implementor's note: the 'not' filter is an example of a tagged 1055 choice in an implicitly-tagged module. In BER this is treated as 1056 if the tag was explicit.) 1058 A server MUST evaluate filters according to the three-valued logic 1059 of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated 1060 to either "TRUE", "FALSE" or "Undefined". If the filter evaluates 1061 to TRUE for a particular entry, then the attributes of that entry 1062 are returned as part of the search result (subject to any 1063 applicable access control restrictions). If the filter evaluates 1064 to FALSE or Undefined, then the entry is ignored for the search. 1066 A filter of the "and" choice is TRUE if all the filters in the SET 1067 OF evaluate to TRUE, FALSE if at least one filter is FALSE, and 1068 otherwise Undefined. A filter of the "or" choice is FALSE if all 1069 of the filters in the SET OF evaluate to FALSE, TRUE if at least 1070 one filter is TRUE, and Undefined otherwise. A filter of the 'not' 1071 choice is TRUE if the filter being negated is FALSE, FALSE if it 1072 is TRUE, and Undefined if it is Undefined. 1074 The present match evaluates to TRUE where there is an attribute or 1075 subtype of the specified attribute description present in an 1076 entry, and FALSE otherwise (including a presence test with an 1077 unrecognized attribute description.) 1079 The matching rule for equalityMatch filter items is defined by the 1080 EQUALITY matching rule for the attribute type. 1082 There SHALL be at most one 'initial', and at most one 'final' in 1083 the 'substrings' of a SubstringFilter. If 'initial' is present, it 1084 Lightweight Directory Access Protocol Version 3 1086 SHALL be the first element of 'substrings'. If 'final' is present, 1087 it SHALL be the last element of 'substrings'. 1088 The matching rule for AssertionValues in a substrings filter item 1089 is defined by the SUBSTR matching rule for the attribute type. 1090 Note that the AssertionValue in a substrings filter item conforms 1091 to the assertion syntax of the EQUALITY matching rule for the 1092 attribute type rather than the assertion syntax of the SUBSTR 1093 matching rule for the attribute type. Conceptually, the entire 1094 SubstringFilter is converted into an assertion value of the 1095 substrings matching rule prior to applying the rule. 1097 The matching rule for the greaterOrEqual filter item is defined by 1098 the ORDERING and EQUALITY matching rules for the attribute type. 1100 The matching rule for the lessOrEqual filter item is defined by 1101 the ORDERING matching rule for the attribute type. 1103 An approxMatch filter item evaluates to TRUE when there is a value 1104 of the attribute or subtype for which some locally-defined 1105 approximate matching algorithm (e.g. spelling variations, phonetic 1106 match, etc.) returns TRUE. If an item matches for equality, it 1107 also satisfies an approximate match. If approximate matching is 1108 not supported, this filter item should be treated as an 1109 equalityMatch. 1111 An extensibleMatch filter item is evaluated as follows: 1113 If the matchingRule field is absent, the type field MUST be 1114 present, and an equality match is performed for that type. 1116 If the type field is absent and the matchingRule is present, the 1117 matchValue is compared against all attributes in an entry which 1118 support that matchingRule. The matchingRule determines the 1119 syntax for the assertion value. The filter item evaluates to 1120 TRUE if it matches with at least one attribute in the entry, 1121 FALSE if it does not match any attribute in the entry, and 1122 Undefined if the matchingRule is not recognized or the 1123 assertionValue is invalid. 1125 If the type field is present and the matchingRule is present, 1126 the matchValue is compared against entry attributes of the 1127 specified type. In this case, the matchingRule MUST be one 1128 suitable for use with the specified type (see [Syntaxes]), 1129 otherwise the filter item is Undefined. 1131 If the dnAttributes field is set to TRUE, the match is 1132 additionally applied against all the AttributeValueAssertions in 1133 an entry's distinguished name, and evaluates to TRUE if there is 1134 at least one attribute in the distinguished name for which the 1135 filter item evaluates to TRUE. The dnAttributes field is present 1136 to alleviate the need for multiple versions of generic matching 1137 rules (such as word matching), where one applies to entries and 1138 another applies to entries and dn attributes as well. 1140 Lightweight Directory Access Protocol Version 3 1142 A filter item evaluates to Undefined when the server would not be 1143 able to determine whether the assertion value matches an entry. If 1144 an attribute description in an equalityMatch, substrings, 1145 greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter 1146 is not recognized by the server, a matching rule id in the 1147 extensibleMatch is not recognized by the server, the assertion 1148 value is invalid, or the type of filtering requested is not 1149 implemented, then the filter is Undefined. Thus for example if a 1150 server did not recognize the attribute type shoeSize, a filter of 1151 (shoeSize=*) would evaluate to FALSE, and the filters 1152 (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to 1153 Undefined. 1155 Servers MUST NOT return errors if attribute descriptions or 1156 matching rule ids are not recognized, assertion values are 1157 invalid, or the assertion syntax is not supported. More details of 1158 filter processing are given in Section 7.8 of [X.511]. 1160 - attributes: A selection list of the attributes to be returned from 1161 each entry which matches the search filter. LDAPString values of 1162 this field are constrained to the following Augmented Backus-Naur 1163 Form ([ABNF]): 1165 attributeSelector = attributedescription / selectorpecial 1167 selectorspecial = noattrs / alluserattrs 1169 noattrs = %x31.2E.31 ; "1.1" 1171 alluserattrs = %x2A ; asterisk ("*") 1173 The production is defined in Section 2.5 of 1174 [Models]. 1176 There are three special cases which may exist in the attribute 1177 selection: 1179 - an empty list with no attributes, 1181 - a list containing "*" (with zero or more attribute 1182 descriptions), and 1184 - a list containing only "1.1". 1186 An empty list requests the return of all user attributes. 1188 A list containing "*" requests all user attributes in addition to 1189 other listed (operational) attributes. 1191 A list containing only the OID "1.1" indicates that no values are 1192 to be returned. If "1.1" is provided with other values, the "1.1" 1193 value is ignored. This OID was chosen because it does not (and can 1194 not) correspond to any attribute in use. 1196 Lightweight Directory Access Protocol Version 3 1198 Client implementors should note that even if all user attributes 1199 are requested, some attributes and/or attribute values of the 1200 entry may not be included in search results due to access controls 1201 or other restrictions. Furthermore, servers will not return 1202 operational attributes, such as objectClasses or attributeTypes, 1203 unless they are listed by name. Operational attributes are 1204 described in [Models]. 1206 Attributes are returned at most once in an entry. If an attribute 1207 description is named more than once in the list, the subsequent 1208 names are ignored. If an attribute description in the list is not 1209 recognized, it is ignored by the server. 1211 Note that an X.500 "list"-like operation can be emulated by the 1212 client requesting a one-level LDAP search operation with a filter 1213 checking for the presence of the 'objectClass' attribute, and that an 1214 X.500 "read"-like operation can be emulated by a base object LDAP 1215 search operation with the same filter. A server which provides a 1216 gateway to X.500 is not required to use the Read or List operations, 1217 although it may choose to do so, and if it does, it must provide the 1218 same semantics as the X.500 search operation. 1220 4.5.2. Search Result 1222 The results of the search operation are returned as zero or more 1223 searchResultEntry messages, zero or more SearchResultReference 1224 messages, followed by a single searchResultDone message. 1226 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 1227 objectName LDAPDN, 1228 attributes PartialAttributeList } 1230 PartialAttributeList ::= SEQUENCE OF 1231 partialAttribute PartialAttribute 1232 -- Note that the PartialAttributeList may hold zero elements. 1233 -- This may happen when none of the attributes of an entry 1234 -- were requested, or could be returned. 1235 -- Note also that the partialAttribute vals set may hold zero 1236 -- elements. This may happen when typesOnly is requested, access 1237 -- controls prevent the return of values, or other reasons. 1239 SearchResultReference ::= [APPLICATION 19] SEQUENCE 1240 SIZE (1..MAX) OF uri URI 1242 SearchResultDone ::= [APPLICATION 5] LDAPResult 1244 Each SearchResultEntry represents an entry found during the search. 1245 Each SearchResultReference represents an area not yet explored during 1246 the search. The SearchResultEntry and SearchResultReference PDUs may 1247 come in any order. Following all the SearchResultReference and 1248 SearchResultEntry responses, the server returns a SearchResultDone 1249 response, which contains an indication of success, or detailing any 1250 errors that have occurred. 1252 Lightweight Directory Access Protocol Version 3 1254 Each entry returned in a SearchResultEntry will contain all 1255 appropriate attributes as specified in the attributes field of the 1256 Search Request. Return of attributes is subject to access control and 1257 other administrative policy. 1259 Some attributes may be constructed by the server and appear in a 1260 SearchResultEntry attribute list, although they are not stored 1261 attributes of an entry. Clients SHOULD NOT assume that all attributes 1262 can be modified, even if permitted by access control. 1264 If the server's schema defines short names [Models] for an attribute 1265 type then the server SHOULD use one of those names in attribute 1266 descriptions for that attribute type (in preference to using the 1267 [Models] format of the attribute type's object 1268 identifier). The server SHOULD NOT use the short name if that name is 1269 known by the server to be ambiguous, or otherwise likely to cause 1270 interoperability problems. 1272 4.5.3. Continuation References in the Search Result 1274 If the server was able to locate the entry referred to by the 1275 baseObject but was unable to search one or more non-local entries, 1276 the server may return one or more SearchResultReference entries, each 1277 containing a reference to another set of servers for continuing the 1278 operation. A server MUST NOT return any SearchResultReference if it 1279 has not located the baseObject and thus has not searched any entries; 1280 in this case it would return a SearchResultDone containing either a 1281 referral or noSuchObject result code (depending on the server's 1282 knowledge of the entry named in the baseObject). 1284 If a server holds a copy or partial copy of the subordinate naming 1285 context [Section 5 of Models], it may use the search filter to 1286 determine whether or not to return a SearchResultReference response. 1287 Otherwise SearchResultReference responses are always returned when in 1288 scope. 1290 The SearchResultReference is of the same data type as the Referral. 1292 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 1293 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 1295 In order to complete the search, the client issues a new search 1296 operation for each SearchResultReference that is returned. Note that 1297 the abandon operation described in Section 4.11 applies only to a 1298 particular operation sent on an association between a client and 1299 server. The client must abandon subsequent search operations it 1300 wishes to individually. 1302 Clients that follow search continuation references MUST ensure that 1303 they do not loop between servers. They MUST NOT repeatedly contact 1304 the same server for the same request with the same target entry name, 1305 scope and filter. Some clients use a counter that is incremented each 1306 Lightweight Directory Access Protocol Version 3 1308 time search result reference handling occurs for an operation, and 1309 these kinds of clients MUST be able to handle at least ten nested 1310 search result references between the root and a leaf entry. 1312 When an LDAP URL is used, the following instructions are followed: 1314 - The part of the URL MUST be present, with the new target 1315 object name. The client MUST use this name when following the 1316 reference. UTF-8 encoded characters appearing in the string 1317 representation of a DN or search filter may not be legal for URLs 1318 (e.g. spaces) and MUST be escaped using the % method in [URI]. 1320 - Some servers (e.g. participating in distributed indexing) may 1321 provide a different filter in a URL of a SearchResultReference. 1323 - If the part of the URL is present, the client MUST use 1324 this filter in its next request to progress this search, and if it 1325 is not present the client MUST use the same filter as it used for 1326 that search. 1328 - If the originating search scope was singleLevel, the part 1329 of the URL will be "base". 1331 - it is RECOMMENDED that the part be present to avoid 1332 ambiguity. 1334 - Other aspects of the new search request may be the same as or 1335 different from the search request which generated the 1336 SearchResultReference. 1338 - The name of an unexplored subtree in a SearchResultReference need 1339 not be subordinate to the base object. 1341 Other kinds of URIs may be returned. The syntax and semantics of such 1342 URIs is left to future specifications. Clients may ignore URIs that 1343 they do not support. 1345 4.5.3.1. Examples 1347 For example, suppose the contacted server (hosta) holds the entry 1348 and the entry . It 1349 knows that either LDAP-capable servers (hostb) or (hostc) hold 1350 (one is the master and the other server 1351 a shadow), and that LDAP-capable server (hostd) holds the subtree 1352 . If a wholeSubtree search of 1353 is requested to the contacted server, it may 1354 return the following: 1356 SearchResultEntry for DC=Example,DC=NET 1357 SearchResultEntry for CN=Manager,DC=Example,DC=NET 1358 SearchResultReference { 1359 ldap://hostb/OU=People,DC=Example,DC=NET??sub 1360 ldap://hostc/OU=People,DC=Example,DC=NET??sub } 1361 Lightweight Directory Access Protocol Version 3 1363 SearchResultReference { 1364 ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } 1365 SearchResultDone (success) 1367 Client implementors should note that when following a 1368 SearchResultReference, additional SearchResultReference may be 1369 generated. Continuing the example, if the client contacted the server 1370 (hostb) and issued the search for the subtree 1371 , the server might respond as follows: 1373 SearchResultEntry for OU=People,DC=Example,DC=NET 1374 SearchResultReference { 1375 ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } 1376 SearchResultReference { 1377 ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } 1378 SearchResultDone (success) 1380 Similarly, if a singleLevel search of is 1381 requested to the contacted server, it may return the following: 1383 SearchResultEntry for CN=Manager,DC=Example,DC=NET 1384 SearchResultReference { 1385 ldap://hostb/OU=People,DC=Example,DC=NET??base 1386 ldap://hostc/OU=People,DC=Example,DC=NET??base } 1387 SearchResultReference { 1388 ldap://hostd/OU=Roles,DC=Example,DC=NET??base } 1389 SearchResultDone (success) 1391 If the contacted server does not hold the base object for the search, 1392 but has knowledge of its possible location, then it may return a 1393 referral to the client. In this case, if the client requests a 1394 subtree search of to hosta, the server returns a 1395 SearchResultDone containing a referral. 1397 SearchResultDone (referral) { 1398 ldap://hostg/DC=Example,DC=ORG??sub } 1400 4.6. Modify Operation 1402 The Modify Operation allows a client to request that a modification 1403 of an entry be performed on its behalf by a server. The Modify 1404 Request is defined as follows: 1406 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1407 object LDAPDN, 1408 changes SEQUENCE OF change SEQUENCE { 1409 operation ENUMERATED { 1410 add (0), 1411 delete (1), 1412 replace (2) }, 1413 modification PartialAttribute } } 1415 Fields of the Modify Request are: 1417 Lightweight Directory Access Protocol Version 3 1419 - object: The name of the object to be modified. The value of this 1420 field contains the DN of the entry to be modified. The server 1421 SHALL NOT perform any alias dereferencing in determining the 1422 object to be modified. 1424 - changes: A list of modifications to be performed on the entry. The 1425 entire list of modifications MUST be performed in the order they 1426 are listed as a single atomic operation. While individual 1427 modifications may violate certain aspects of the directory schema 1428 (such as the object class definition and DIT content rule), the 1429 resulting entry after the entire list of modifications is 1430 performed MUST conform to the requirements of the directory model 1431 and controlling schema [Models]. 1433 - operation: Used to specify the type of modification being 1434 performed. Each operation type acts on the following 1435 modification. The values of this field have the following 1436 semantics respectively: 1438 add: add values listed to the modification attribute, 1439 creating the attribute if necessary; 1441 delete: delete values listed from the modification attribute, 1442 removing the entire attribute if no values are listed, or if 1443 all current values of the attribute are listed for deletion; 1445 replace: replace all existing values of the modification 1446 attribute with the new values listed, creating the attribute 1447 if it did not already exist. A replace with no value will 1448 delete the entire attribute if it exists, and is ignored if 1449 the attribute does not exist. 1451 - modification: A PartialAttribute (which may have an empty SET 1452 of vals) used to hold the attribute type or attribute type and 1453 values being modified. 1455 Upon receipt of a Modify Request, the server attempts to perform the 1456 necessary modifications to the DIT and returns the result in a Modify 1457 Response, defined as follows: 1459 ModifyResponse ::= [APPLICATION 7] LDAPResult 1461 The server will return to the client a single Modify Response 1462 indicating either the successful completion of the DIT modification, 1463 or the reason that the modification failed. Due to the requirement 1464 for atomicity in applying the list of modifications in the Modify 1465 Request, the client may expect that no modifications of the DIT have 1466 been performed if the Modify Response received indicates any sort of 1467 error, and that all requested modifications have been performed if 1468 the Modify Response indicates successful completion of the Modify 1469 Operation. If the association changes or the connection fails, 1470 whether the modification occurred or not is indeterminate. 1472 Lightweight Directory Access Protocol Version 3 1474 The Modify Operation cannot be used to remove from an entry any of 1475 its distinguished values, i.e. those values which form the entry's 1476 relative distinguished name. An attempt to do so will result in the 1477 server returning the notAllowedOnRDN result code. The Modify DN 1478 Operation described in Section 4.9 is used to rename an entry. 1480 Note that due to the simplifications made in LDAP, there is not a 1481 direct mapping of the changes in an LDAP ModifyRequest onto the 1482 changes of a DAP ModifyEntry operation, and different implementations 1483 of LDAP-DAP gateways may use different means of representing the 1484 change. If successful, the final effect of the operations on the 1485 entry MUST be identical. 1487 4.7. Add Operation 1489 The Add Operation allows a client to request the addition of an entry 1490 into the Directory. The Add Request is defined as follows: 1492 AddRequest ::= [APPLICATION 8] SEQUENCE { 1493 entry LDAPDN, 1494 attributes AttributeList } 1496 AttributeList ::= SEQUENCE OF attribute Attribute 1498 Fields of the Add Request are: 1500 - entry: the name of the entry to be added. The server SHALL NOT 1501 dereference any aliases in locating the entry to be added. 1503 - attributes: the list of attributes that, along with those from the 1504 RDN, make up the content of the entry being added. Clients MAY or 1505 MAY NOT include the RDN attribute in this list. Clients MUST 1506 include the 'objectClass' attribute, and values of any mandatory 1507 attributes of the listed object classes. Clients MUST NOT supply 1508 NO-USER-MODIFICATION attributes such as the createTimestamp or 1509 creatorsName attributes, since the server maintains these 1510 automatically. 1512 The entry named in the entry field of the AddRequest MUST NOT exist 1513 for the AddRequest to succeed. The immediate superior (parent) of an 1514 object or alias entry to be added MUST exist. For example, if the 1515 client attempted to add , the 1516 entry did not exist, and the entry did 1517 exist, then the server would return the noSuchObject result code with 1518 the matchedDN field containing . 1520 Server implementations SHOULD NOT restrict where entries can be 1521 located in the Directory unless DIT structure rules are in place. 1522 Some servers allow the administrator to restrict the classes of 1523 entries which can be added to the Directory. 1525 Lightweight Directory Access Protocol Version 3 1527 Upon receipt of an Add Request, a server will attempt to add the 1528 requested entry. The result of the add attempt will be returned to 1529 the client in the Add Response, defined as follows: 1531 AddResponse ::= [APPLICATION 9] LDAPResult 1533 A response of success indicates that the new entry has been added to 1534 the Directory. 1536 4.8. Delete Operation 1538 The Delete Operation allows a client to request the removal of an 1539 entry from the Directory. The Delete Request is defined as follows: 1541 DelRequest ::= [APPLICATION 10] LDAPDN 1543 The Delete Request consists of the name of the entry to be deleted. 1544 The server SHALL NOT dereference aliases while resolving the name of 1545 the target entry to be removed. 1547 Only leaf entries (those with no subordinate entries) can be deleted 1548 with this operation. 1550 Upon receipt of a Delete Request, a server will attempt to perform 1551 the entry removal requested and return the result in the Delete 1552 Response defined as follows: 1554 DelResponse ::= [APPLICATION 11] LDAPResult 1556 4.9. Modify DN Operation 1558 The Modify DN Operation allows a client to change the Relative 1559 Distinguished Name (RDN) of an entry in the Directory, and/or to move 1560 a subtree of entries to a new location in the Directory. The Modify 1561 DN Request is defined as follows: 1563 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1564 entry LDAPDN, 1565 newrdn RelativeLDAPDN, 1566 deleteoldrdn BOOLEAN, 1567 newSuperior [0] LDAPDN OPTIONAL } 1569 Fields of the Modify DN Request are: 1571 - entry: the name of the entry to be changed. This entry may or may 1572 not have subordinate entries. 1574 - newrdn: the new RDN of the entry. If the operation moves the entry 1575 to a new superior without changing its RDN, the value of the old 1576 RDN is supplied for this parameter. 1578 Lightweight Directory Access Protocol Version 3 1580 Attribute values of the new RDN not matching any attribute value 1581 of the entry are added to the entry and an appropriate error is 1582 returned if this fails. 1584 - deleteoldrdn: a boolean field that controls whether the old RDN 1585 attribute values are to be retained as attributes of the entry, or 1586 deleted from the entry. 1588 - newSuperior: if present, this is the name of an existing object 1589 entry which becomes the immediate superior (parent) of the 1590 existing entry. 1592 The server SHALL NOT dereference any aliases in locating the objects 1593 named in entry or newSuperior. 1595 Upon receipt of a ModifyDNRequest, a server will attempt to perform 1596 the name change and return the result in the Modify DN Response, 1597 defined as follows: 1599 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 1601 For example, if the entry named in the entry field was , the newrdn field was , and the 1603 newSuperior field was absent, then this operation would attempt to 1604 rename the entry to be . If there was 1605 already an entry with that name, the operation would fail with the 1606 entryAlreadyExists result code. 1608 The object named in newSuperior MUST exist. For example, if the 1609 client attempted to add , the 1610 entry did not exist, and the entry did 1611 exist, then the server would return the noSuchObject result code with 1612 the matchedDN field containing . 1614 If the deleteoldrdn field is TRUE, the attribute values forming the 1615 old RDN but not the new RDN are deleted from the entry. If the 1616 deleteoldrdn field is FALSE, the attribute values forming the old RDN 1617 will be retained as non-distinguished attribute values of the entry. 1618 The server MUST fail the operation and return an error in the result 1619 code if the setting of the deleteoldrdn field would cause a schema 1620 inconsistency in the entry. 1622 Note that X.500 restricts the ModifyDN operation to only affect 1623 entries that are contained within a single server. If the LDAP server 1624 is mapped onto DAP, then this restriction will apply, and the 1625 affectsMultipleDSAs result code will be returned if this error 1626 occurred. In general, clients MUST NOT expect to be able to perform 1627 arbitrary movements of entries and subtrees between servers or 1628 between naming contexts. 1630 4.10. Compare Operation 1631 Lightweight Directory Access Protocol Version 3 1633 The Compare Operation allows a client to compare an assertion value 1634 with the values of a particular attribute in a particular entry in 1635 the Directory. The Compare Request is defined as follows: 1637 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1638 entry LDAPDN, 1639 ava AttributeValueAssertion } 1641 Fields of the Compare Request are: 1643 - entry: the name of the entry to be compared. The server SHALL NOT 1644 dereference any aliases in locating the entry to be compared. 1646 - ava: holds the attribute value assertion to be compared. 1648 Upon receipt of a Compare Request, a server will attempt to perform 1649 the requested comparison and return the result in the Compare 1650 Response, defined as follows: 1652 CompareResponse ::= [APPLICATION 15] LDAPResult 1654 The resultCode field is set to compareTrue, compareFalse, or an 1655 appropriate error. compareTrue indicates that the assertion value in 1656 the ava field matches a value of the attribute or subtype according 1657 to the attribute's EQUALITY matching rule. compareFalse indicates 1658 that the assertion value in the ava field and the values of the 1659 attribute or subtype did not match. Other result codes indicate 1660 either that the result of the comparison was Undefined (Section 1661 4.5.1), or that some error occurred. 1663 Note that some directory systems may establish access controls which 1664 permit the values of certain attributes (such as userPassword) to be 1665 compared but not interrogated by other means. 1667 4.11. Abandon Operation 1669 The function of the Abandon Operation is to allow a client to request 1670 that the server abandon an outstanding operation. The Abandon Request 1671 is defined as follows: 1673 AbandonRequest ::= [APPLICATION 16] MessageID 1675 The MessageID is that of an operation which was requested earlier in 1676 this LDAP association. The abandon request itself has its own message 1677 id. This is distinct from the id of the earlier operation being 1678 abandoned. 1680 There is no response defined in the Abandon operation. Upon receipt 1681 of an AbandonRequest, the server MAY abandon the operation identified 1682 by the MessageID. Since the client cannot tell the difference between 1683 a successfully abandoned operation and an outstanding operation, the 1684 application of the Abandon operation is limited to uses where the 1685 client does not require an indication of its outcome. 1687 Lightweight Directory Access Protocol Version 3 1689 Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. 1691 In the event that a server receives an Abandon Request on a Search 1692 Operation in the midst of transmitting responses to the search, that 1693 server MUST cease transmitting entry responses to the abandoned 1694 request immediately, and MUST NOT send the SearchResponseDone. Of 1695 course, the server MUST ensure that only properly encoded LDAPMessage 1696 PDUs are transmitted. 1698 The ability to abandon other (particularly update) operations is at 1699 the discretion of the server. 1701 Clients should not send abandon requests for the same operation 1702 multiple times, and MUST also be prepared to receive results from 1703 operations it has abandoned (since these may have been in transit 1704 when the abandon was requested, or are not able to be abandoned). 1706 Servers MUST discard abandon requests for message IDs they do not 1707 recognize, for operations which cannot be abandoned, and for 1708 operations which have already been abandoned. 1710 4.12. Extended Operation 1712 The extended operation allows additional operations to be defined for 1713 services not already available in the protocol. For example, to add 1714 operations to install transport layer security (see Section 4.14). 1716 The extended operation allows clients to make requests and receive 1717 responses with predefined syntaxes and semantics. These may be 1718 defined in RFCs or be private to particular implementations. 1720 Each extended operation consists of an extended request and an 1721 extended response. 1723 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1724 requestName [0] LDAPOID, 1725 requestValue [1] OCTET STRING OPTIONAL } 1727 The requestName is a dotted-decimal representation of the unique 1728 OBJECT IDENTIFIER corresponding to the request. The requestValue is 1729 information in a form defined by that request, encapsulated inside an 1730 OCTET STRING. 1732 The server will respond to this with an LDAPMessage containing an 1733 ExtendedResponse. 1735 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 1736 COMPONENTS OF LDAPResult, 1737 responseName [10] LDAPOID OPTIONAL, 1738 responseValue [11] OCTET STRING OPTIONAL } 1739 Lightweight Directory Access Protocol Version 3 1741 The responseName is typically not required to be present as the 1742 syntax and semantics of the response (including the format of the 1743 responseValue) is implicitly known and associated with the request by 1744 the messageID. 1746 If the requestName is not recognized by the server, the server MUST 1747 NOT provide a responseName nor a responseValue and MUST return a 1748 resultCode of protocolError. 1750 The requestValue and responseValue fields contain any information 1751 associated with the operation. The format of these fields is defined 1752 by the specification of the extended operation. Implementations MUST 1753 be prepared to handle arbitrary contents of these fields, including 1754 zero bytes. Values that are defined in terms of ASN.1 and BER encoded 1755 according to Section 5.2, also follow the extensibility rules in 1756 Section 4. 1758 It is RECOMMENDED that servers list the requestName of extended 1759 operations they support in the 'supportedExtension' attribute of the 1760 root DSE [Models]. 1762 Extended operations may be specified in other documents. The 1763 specification of an extended operation consists of: 1765 - the OBJECT IDENTIFIER assigned to the requestName, 1767 - the OBJECT IDENTIFIER (if any) assigned to the responseName (note 1768 that the same OBJECT IDENTIFIER my be used for both the 1769 requestName and responseName), 1771 - the format of the contents of the requestValue and responseValue 1772 (if any), and 1774 - the semantics of the operation. 1776 4.13. IntermediateResponse Message 1778 While the Search operation provides a mechanism to return multiple 1779 response messages for a single search request, other operations, by 1780 nature, do not provide for multiple response messages. 1782 The IntermediateResponse message provides a general mechanism for 1783 defining single-request/multiple-response operations in LDAP. This 1784 message is intended to be used in conjunction with the extended 1785 operation to define new single-request/multiple-response operations 1786 or in conjunction with a control when extending existing LDAP 1787 operations in a way that requires them to return intermediate 1788 response information. 1790 It is intended that the definitions and descriptions of extended 1791 operations and controls that make use of the IntermediateResponse 1792 message will define the circumstances when an IntermediateResponse 1793 Lightweight Directory Access Protocol Version 3 1795 message can be sent by a server and the associated meaning of an 1796 IntermediateResponse message sent in a particular circumstance. 1798 IntermediateResponse ::= [APPLICATION 25] SEQUENCE { 1799 responseName [0] LDAPOID OPTIONAL, 1800 responseValue [1] OCTET STRING OPTIONAL } 1802 IntermediateResponse messages SHALL NOT be returned to the client 1803 unless the client issues a request that specifically solicits their 1804 return. This document defines two forms of solicitation: extended 1805 operation and request control. IntermediateResponse messages are 1806 specified in documents describing the manner in which they are 1807 solicited (i.e. in the extended operation or request control 1808 specification that uses them). These specifications include: 1810 - the OBJECT IDENTIFIER (if any) assigned to the responseName, 1812 - the format of the contents of the responseValue, and 1814 - the semantics associated with the IntermediateResponse message. 1816 Extensions that allow the return of multiple types of 1817 IntermediateResponse messages SHALL identify those types using unique 1818 responseName values (note that one of these may specify no value). 1820 Sections 4.13.1 and 4.13.2 describe additional requirements on the 1821 inclusion of responseName and responseValue in IntermediateResponse 1822 messages. 1824 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse 1826 A single-request/multiple-response operation may be defined using a 1827 single ExtendedRequest message to solicit zero or more 1828 IntermediateResponse messages of one or more kinds followed by an 1829 ExtendedResponse message. 1831 4.13.2. Usage with LDAP Request Controls 1833 A control's semantics may include the return of zero or more 1834 IntermediateResponse messages prior to returning the final result 1835 code for the operation. One or more kinds of IntermediateResponse 1836 messages may be sent in response to a request control. 1838 All IntermediateResponse messages associated with request controls 1839 SHALL include a responseName. This requirement ensures that the 1840 client can correctly identify the source of IntermediateResponse 1841 messages when: 1843 - two or more controls using IntermediateResponse messages are 1844 included in a request for any LDAP operation or 1845 Lightweight Directory Access Protocol Version 3 1847 - one or more controls using IntermediateResponse messages are 1848 included in a request with an LDAP extended operation that uses 1849 IntermediateResponse messages. 1851 4.14. StartTLS Operation 1853 The Start Transport Layer Security (StartTLS) operation provides the 1854 ability to establish a TLS-protected LDAP exchange. The StartTLS 1855 operation is defined using the extended operation mechanism described 1856 in Section 4.12. 1858 4.14.1. StartTLS Request 1860 A client requests TLS establishment by transmitting a StartTLS 1861 request PDU to the server. The StartTLS request is defined in terms 1862 of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", 1863 and the requestValue field is always absent. 1865 The client MUST NOT send any PDUs on this LDAP exchange following 1866 this request until it receives a StartTLS extended response and, in 1867 the case of a successful response, completes TLS negotiations. 1869 4.14.2. StartTLS Response 1871 When a StartTLS request is made, servers supporting the operation 1872 MUST return a StartTLS response PDU to the requestor. The 1873 responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue 1874 field is absent. 1876 The server provides a resultCode field to either success or one of 1877 the other values outlined in Section 4.14.2.2. 1879 4.14.2.1. "Success" Response 1881 If the StartTLS Response contains a resultCode of success, this 1882 indicates that the server is willing and able to negotiate TLS. Refer 1883 to Section 4 of [AuthMeth] for details. 1885 4.14.2.2. Response other than "success" 1887 If the ExtendedResponse contains a result code other than success, 1888 this indicates that the server is unwilling or unable to negotiate 1889 TLS. The following result codes have these meanings for this 1890 operation: 1892 - operationsError: operations sequencing incorrect; e.g. TLS is 1893 already established. 1895 Lightweight Directory Access Protocol Version 3 1897 - protocolError: TLS is not supported or incorrect PDU structure. 1899 - unavailable: Some major problem with TLS, or the server is 1900 shutting down. 1902 The server MUST return operationsError if the client violates any of 1903 the StartTLS extended operation sequencing requirements described in 1904 Section 4 of [AuthMeth]. 1906 If the server does not support TLS (whether by design or by current 1907 configuration), it MUST return the protocolError resultCode. In this 1908 event, the client may proceed with any LDAP operation, or it may 1909 close the connection. 1911 The server MUST return unavailable if it supports TLS but cannot 1912 install the TLS layer for some reason, e.g. the certificate server 1913 not responding, it cannot contact its TLS implementation, or if the 1914 server is in process of shutting down. The client may retry the 1915 StartTLS operation, or it may proceed with any other LDAP operation, 1916 or it may close the connection. 1918 4.14.3. Removal of the TLS Layer 1920 Two forms of TLS layer -- graceful and abrupt -- are supported. These 1921 do not involve LDAP PDUs, but are preformed at the underlying layers. 1923 If the connection is closed, outstanding operations are handled as 1924 specified in Section 5.1. 1926 4.14.3.1. Graceful Removal 1928 Either the client or server MAY remove the TLS layer and leave the 1929 LDAP exchange intact by sending and receiving a TLS closure alert. 1931 The initiating protocol peer sends the TLS closure alert. If it 1932 wishes to leave the LDAP exchange intact, it then MUST cease to send 1933 further PDUs and MUST ignore any received LDAP PDUs until it receives 1934 a TLS closure alert from the other peer. 1936 Once the initiating protocol peer receives a TLS closure alert from 1937 the other peer it MAY send and receive LDAP PDUs. 1939 When a protocol peer receives the initial TLS closure alert, it may 1940 choose to allow the LDAP exchange to remain intact. In this case, it 1941 MUST immediately transmit a TLS closure alert. Following this, it MAY 1942 send and receive LDAP PDUs. 1944 Protocol peers MAY close the connection after sending or receiving a 1945 TLS closure alert. 1947 Lightweight Directory Access Protocol Version 3 1949 After the TLS layer has been removed, the server MUST NOT send 1950 responses to any request message received before the TLS closure 1951 alert. Thus, clients wishing to receive responses to messages sent 1952 while the TLS layer is intact MUST wait for those message responses 1953 before sending the TLS closure alert. 1955 4.14.3.2. Abrupt Removal 1957 Either the client or server MAY abruptly remove the TLS layer by 1958 closing the connection. In this circumstance, a server MAY send the 1959 client a Notice of Disconnection before closing the connection. 1961 5. Protocol Encoding, Connection, and Transfer 1963 This protocol is designed to run over connection-oriented, reliable 1964 transports, where the data stream is divided into octets (8-bit 1965 units), with each octet being significant. 1967 One underlying service, LDAP over TCP, is defined in Section 1968 5.3. This service is generally applicable to applications providing 1969 or consuming X.500-based directory services on the Internet. This 1970 specification was generally written with the TCP mapping in mind. 1971 Specifications detailing other mappings may encounter various 1972 obstacles. 1974 Implementations of LDAP over TCP MUST implement the mapping as 1975 described in Section 5.3 1977 This table illustrates the relationship between the different layers 1978 involved in an exchange between two protocol peers: 1979 +---------------+ | 1980 | LDAP exchange | | 1981 +---------------+ > LDAP PDU | 1982 +---------------+ < data | 1983 | SASL layer | | 1984 +---------------+ > SASL-protected data | 1985 +---------------+ < data | 1986 | TLS layer | | 1987 +---------------+ > TLS-protected data | Application 1988 +---------------+ < data +------------ 1989 | connection | | Transport 1990 +---------------+ 1992 5.1 Operation and LDAP exchange Relationship 1994 Protocol operations are tied to an LDAP exchange. If the connection 1995 is closed, any outstanding operations tied to the LDAP exchange are, 1996 when possible, abandoned, and when not possible, completed without 1997 transmission of the response. Also, if the connection is closed, the 1998 client MUST NOT assume that any outstanding update operations tied to 1999 the LDAP exchange have succeeded or failed. 2001 Lightweight Directory Access Protocol Version 3 2003 5.2. Protocol Encoding 2005 The protocol elements of LDAP SHALL be encoded for exchange using the 2006 Basic Encoding Rules [BER] of [ASN.1] with the following 2007 restrictions: 2009 - Only the definite form of length encoding is used. 2011 - OCTET STRING values are encoded in the primitive form only. 2013 - If the value of a BOOLEAN type is true, the encoding of the value 2014 octet is set to hex "FF". 2016 - If a value of a type is its default value, it is absent. Only some 2017 BOOLEAN and INTEGER types have default values in this protocol 2018 definition. 2020 These restrictions are meant to ease the overhead of encoding and 2021 decoding certain elements in BER. 2023 These restrictions do not apply to ASN.1 types encapsulated inside of 2024 OCTET STRING values, such as attribute values, unless otherwise 2025 stated. 2027 5.3. Transmission Control Protocol (TCP) 2029 The encoded LDAPMessage PDUs are mapped directly onto the [TCP] 2030 bytestream using the BER-based encoding described in Section 5.2. It 2031 is recommended that server implementations running over the TCP 2032 provide a protocol listener on the Internet Assigned Numbers 2033 Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may 2034 instead provide a listener on a different port number. Clients MUST 2035 support contacting servers on any valid TCP port. 2037 6. Security Considerations 2039 This version of the protocol provides facilities for simple 2040 authentication using a cleartext password, as well as any [SASL] 2041 mechanism. Installing SASL layers can provide integrity and privacy 2042 services. 2044 It is also permitted that the server can return its credentials to 2045 the client, if it chooses to do so. 2047 Use of cleartext password is strongly discouraged where the 2048 underlying transport service cannot guarantee confidentiality and may 2049 result in disclosure of the password to unauthorized parties. 2051 Servers are encouraged to prevent directory modifications by clients 2052 that have authenticated anonymously [AuthMeth]. 2054 Lightweight Directory Access Protocol Version 3 2056 Security considerations for authentication methods, SASL mechanisms, 2057 and TLS are described in [AuthMeth]. 2059 It should be noted that SASL authentication exchanges do not provide 2060 data confidentiality nor integrity protection for the version or name 2061 fields of the bind request nor the resultCode, diagnosticMessage, or 2062 referral fields of the bind response nor of any information contained 2063 in controls attached to bind request or responses. Thus information 2064 contained in these fields SHOULD NOT be relied on unless otherwise 2065 protected (such as by establishing protections at the transport 2066 layer). 2068 Server implementors should plan for the possibility of an identity in 2069 and association being deleted, renamed, or modified, and take 2070 appropriate actions to prevent insecure side effects. Likewise, 2071 server implementors should plan for the possibility of an associated 2072 identity's credentials becoming invalid, or an identity's privileges 2073 being changed. The ways in which these issues are addressed are 2074 application and/or implementation specific. 2076 Implementations which cache attributes and entries obtained via LDAP 2077 MUST ensure that access controls are maintained if that information 2078 is to be provided to multiple clients, since servers may have access 2079 control policies which prevent the return of entries or attributes in 2080 search results except to particular authenticated clients. For 2081 example, caches could serve result information only to the client 2082 whose request caused it to be in the cache. 2084 Servers may return referrals or search result references which 2085 redirect clients to peer servers. It is possible for a rogue 2086 application to inject such referrals into the data stream in an 2087 attempt to redirect a client to a rogue server. Clients are advised 2088 to be aware of this, and possibly reject referrals when 2089 confidentiality measures are not in place. Clients are advised to 2090 reject referrals from the StartTLS operation. 2092 The matchedDN and diagnosticMessage fields, as well as some 2093 resultCode values (e.g., attributeOrValueExists and 2094 entryAlreadyExists), could disclose the presence the specific data in 2095 the directory which is subject to access and other administrative 2096 controls. Server implementations should restrict access to protected 2097 information equally under both normal and error conditions. 2099 Protocol peers MUST be prepared to handle invalid and arbitrary 2100 length protocol encodings. A number of LDAP security advisories are 2101 available through [CERT]. 2103 7. Acknowledgements 2105 This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve 2106 Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, 2107 and Mark Wahl. It is also based on RFC 3771 by Roger Harrison, and 2108 Lightweight Directory Access Protocol Version 3 2110 Kurt Zeilenga. Notable amounts of technical reviews and content were 2111 provided by Kurt Zeilenga, Steven Legg, and Hallvard Furuseth. Their 2112 work along with the input of individuals of the IETF ASID, LDAPEXT, 2113 LDUP, LDAPBIS, and other Working Groups is gratefully acknowledged. 2115 8. Normative References 2117 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2118 Specifications: ABNF", RFC 2234, November 1997. 2120 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 2121 "Information Technology - Abstract Syntax Notation One 2122 (ASN.1): Specification of basic notation" 2124 [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection 2125 Level Security Mechanisms", draft-ietf-ldapbis-authmeth- 2126 xx.txt, (a work in progress). 2128 [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, 2129 "Information technology - ASN.1 encoding rules: 2130 Specification of Basic Encoding Rules (BER), Canonical 2131 Encoding Rules (CER) and Distinguished Encoding Rules 2132 (DER)", 2002. 2134 [IP] Postel, J., "Internet Protocol", STD5 and RFC 791, 2135 September 1981 2137 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 2138 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 2139 : 1993. 2141 [Keyword] Bradner, S., "Key words for use in RFCs to Indicate 2142 Requirement Levels", RFC 2119, March 1997. 2144 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 2145 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a 2146 work in progress). 2148 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- 2149 ldapbis-bcp64-xx.txt, (a work in progress). 2151 [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf- 2152 ldapbis-url-xx.txt, (a work in progress). 2154 [Models] Zeilenga, K., "LDAP: Directory Information Models", draft- 2155 ietf-ldapbis-models-xx.txt (a work in progress). 2157 [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", 2158 draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). 2160 [SASL] Melnikov, A., "Simple Authentication and Security Layer", 2161 draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). 2163 Lightweight Directory Access Protocol Version 3 2165 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 2166 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 2167 progress). 2169 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of 2170 Internationalized Strings ('stringprep')", draft-hoffman- 2171 rfc3454bis-xx.txt, a work in progress. 2173 [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching 2174 Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in 2175 progress). 2177 [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC 2178 793, September 1981 2180 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", 2181 draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. 2183 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 2184 3.2.0" is defined by "The Unicode Standard, Version 3.0" 2185 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 2186 as amended by the "Unicode Standard Annex #27: Unicode 2187 3.1" (http://www.unicode.org/reports/tr27/) and by the 2188 "Unicode Standard Annex #28: Unicode 3.2" 2189 (http://www.unicode.org/reports/tr28/). 2191 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2192 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2193 August 1998. 2195 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2196 10646", STD63 and RFC3629, November 2003. 2198 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 2199 Models and Service", 1993. 2201 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. 2203 [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service 2204 Definition", 1993. 2206 9. Informative References 2208 [CERT] The CERT(R) Center, http://www.cert.org 2210 [PortReg] IANA, "Port Numbers", 2211 http://www.iana.org/assignments/port-numbers 2213 10. IANA Considerations 2215 It is requested that the Internet Assigned Numbers Authority (IANA) 2216 update the LDAP result code registry to indicate that this document 2217 Lightweight Directory Access Protocol Version 3 2219 provides the definitive technical specification for result codes 0- 2220 36, 48-54, 64-70, 80-90. 2222 It is requested that the IANA update the LDAP Protocol Mechanism 2223 registry to indicate that this document and [AuthMeth] provides the 2224 definitive technical specification for the Start TLS 2225 (1.3.6.1.4.1.1466.20037) extended operation. 2227 It is requested that the IANA update the occurrence of "RFC XXXX" in 2228 Appendix B with this RFC number at publication. 2230 11. Editor's Address 2232 Jim Sermersheim 2233 Novell, Inc. 2234 1800 South Novell Place 2235 Provo, Utah 84606, USA 2236 jimse@novell.com 2237 +1 801 861-3088 2238 Lightweight Directory Access Protocol Version 3 2240 Appendix A - LDAP Result Codes 2242 This normative appendix details additional considerations regarding 2243 LDAP result codes and provides a brief, general description of each 2244 LDAP result code enumerated in Section 4.1.9. 2246 Additional result codes MAY be defined for use with extensions 2247 [LDAPIANA]. Client implementations SHALL treat any result code which 2248 they do not recognize as an unknown error condition. 2250 A.1 Non-Error Result Codes 2252 These result codes (called "non-error" result codes) do not indicate 2253 an error condition: 2254 success (0), 2255 compareFalse (5), 2256 compareTrue (6), 2257 referral (10), and 2258 saslBindInProgress (14). 2260 The success, compareTrue, and compareFalse result codes indicate 2261 successful completion (and, hence, are referred to as "successful" 2262 result codes). 2264 The referral and saslBindInProgress result codes indicate the client 2265 is required to take additional action to complete the operation. 2267 A.2 Result Codes 2269 Existing LDAP result codes are described as follows: 2271 success (0) 2272 Indicates the successful completion of an operation. Note: 2273 this code is not used with the compare operation. See 2274 compareFalse (5) and compareTrue (6). 2276 operationsError (1) 2277 Indicates that the operation is not properly sequenced with 2278 relation to other operations (of same or different type). 2280 For example, this code is returned if the client attempts to 2281 StartTLS [TLS] while there are other operations outstanding 2282 or if a TLS layer was already installed. 2284 protocolError (2) 2285 Indicates the server received data which has incorrect 2286 structure. 2288 For bind operation only, this code is also used to indicate 2289 that the server does not support the requested protocol 2290 version. 2292 Lightweight Directory Access Protocol Version 3 2294 For the extended operation only, this code indicates that the 2295 server does not recognize the requestName. 2297 For the Start TLS operation, this code may also indicate that 2298 the server does not currently support Start TLS (even though 2299 it may recognize the requestName). 2301 For request operations specifying multiple controls, this may 2302 be used to indicate that the server cannot ignore the order 2303 of the controls as specified, or that the combination of the 2304 specified controls is not supported. 2306 timeLimitExceeded (3) 2307 Indicates that the time limit specified by the client was 2308 exceeded before the operation could be completed. 2310 sizeLimitExceeded (4) 2311 Indicates that the size limit specified by the client was 2312 exceeded before the operation could be completed. 2314 compareFalse (5) 2315 Indicates that the compare operation has successfully 2316 completed and the assertion has evaluated to FALSE or 2317 Undefined. 2319 compareTrue (6) 2320 Indicates that the compare operation has successfully 2321 completed and the assertion has evaluated to TRUE. 2323 authMethodNotSupported (7) 2324 Indicates that the authentication method or mechanism is not 2325 supported. 2327 strongAuthRequired (8) 2328 Indicates that the server has detected that an established 2329 security association between the client and server has 2330 unexpectedly failed or been compromised, or that the server 2331 now requires the client to authenticate using a strong(er) 2332 mechanism. 2334 referral (10) 2335 Indicates that a referral needs to be chased to complete the 2336 operation (see Section 4.1.10). 2338 adminLimitExceeded (11) 2339 Indicates that an administrative limit has been exceeded. 2341 unavailableCriticalExtension (12) 2342 Indicates that the server is unable or unwilling to perform a 2343 critical control (see Section 4.1.11). 2345 confidentialityRequired (13) 2346 Indicates that data confidentiality protections are required. 2348 Lightweight Directory Access Protocol Version 3 2350 saslBindInProgress (14) 2351 Indicates the server requires the client to send a new bind 2352 request, with the same SASL mechanism, to continue the 2353 authentication process (see Section 4.2). 2355 noSuchAttribute (16) 2356 Indicates that the named entry does not contain the specified 2357 attribute or attribute value. 2359 undefinedAttributeType (17) 2360 Indicates that a request field contains an unrecognized 2361 attribute description. 2363 inappropriateMatching (18) 2364 Indicates that an attempt was made (e.g. in an assertion) to 2365 use a matching rule not defined for the attribute type 2366 concerned. 2368 constraintViolation (19) 2369 Indicates that the client supplied an attribute value which 2370 does not conform to the constraints placed upon it by the 2371 data model. 2373 For example, this code is returned when multiple values are 2374 supplied to an attribute which has a SINGLE-VALUE constraint. 2376 attributeOrValueExists (20) 2377 Indicates that the client supplied an attribute or value to 2378 be added to an entry, but the attribute or value already 2379 exists. 2381 invalidAttributeSyntax (21) 2382 Indicates that a purported attribute value does not conform 2383 to the syntax of the attribute. 2385 noSuchObject (32) 2386 Indicates that the object does not exist in the DIT. 2388 aliasProblem (33) 2389 Indicates that an alias problem has occurred. For example, 2390 the code may used to indicate an alias has been dereferenced 2391 which names no object. 2393 invalidDNSyntax (34) 2394 Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search 2395 base, target entry, ModifyDN newrdn, etc.) of a request does 2396 not conform to the required syntax or contains attribute 2397 values which do not conform to the syntax of the attribute's 2398 type. 2400 aliasDereferencingProblem (36) 2401 Indicates that a problem occurred while dereferencing an 2402 alias. Typically an alias was encountered in a situation 2403 where it was not allowed or where access was denied. 2405 Lightweight Directory Access Protocol Version 3 2407 inappropriateAuthentication (48) 2408 Indicates the server requires the client which had attempted 2409 to bind anonymously or without supplying credentials to 2410 provide some form of credentials. 2412 invalidCredentials (49) 2413 Indicates that the provided credentials (e.g. the user's name 2414 and password) are invalid. 2416 insufficientAccessRights (50) 2417 Indicates that the client does not have sufficient access 2418 rights to perform the operation. 2420 busy (51) 2421 Indicates that the server is too busy to service the 2422 operation. 2424 unavailable (52) 2425 Indicates that the server is shutting down or a subsystem 2426 necessary to complete the operation is offline. 2428 unwillingToPerform (53) 2429 Indicates that the server is unwilling to perform the 2430 operation. 2432 loopDetect (54) 2433 Indicates that the server has detected an internal loop (e.g. 2434 while dereferencing aliases or chaining an operation). 2436 namingViolation (64) 2437 Indicates that the entry's name violates naming restrictions. 2439 objectClassViolation (65) 2440 Indicates that the entry violates object class restrictions. 2442 notAllowedOnNonLeaf (66) 2443 Indicates that the operation is inappropriately acting upon a 2444 non-leaf entry. 2446 notAllowedOnRDN (67) 2447 Indicates that the operation is inappropriately attempting to 2448 remove a value which forms the entry's relative distinguished 2449 name. 2451 entryAlreadyExists (68) 2452 Indicates that the request cannot be fulfilled (added, moved, 2453 or renamed) as the target entry already exists. 2455 objectClassModsProhibited (69) 2456 Indicates that an attempt to modify the object class(es) of 2457 an entry's 'objectClass' attribute is prohibited. 2459 Lightweight Directory Access Protocol Version 3 2461 For example, this code is returned when a client attempts to 2462 modify the structural object class of an entry. 2464 affectsMultipleDSAs (71) 2465 Indicates that the operation cannot be performed as it would 2466 affect multiple servers (DSAs). 2468 other (80) 2469 Indicates the server has encountered an internal error. 2471 Lightweight Directory Access Protocol Version 3 2473 Appendix B - Complete ASN.1 Definition 2475 This appendix is normative. 2477 Lightweight-Directory-Access-Protocol-V3 2478 -- Copyright (C) The Internet Society (2003). This version of 2479 -- this ASN.1 module is part of RFC XXXX; see the RFC itself 2480 -- for full legal notices. 2481 DEFINITIONS 2482 IMPLICIT TAGS 2483 EXTENSIBILITY IMPLIED ::= 2485 BEGIN 2487 LDAPMessage ::= SEQUENCE { 2488 messageID MessageID, 2489 protocolOp CHOICE { 2490 bindRequest BindRequest, 2491 bindResponse BindResponse, 2492 unbindRequest UnbindRequest, 2493 searchRequest SearchRequest, 2494 searchResEntry SearchResultEntry, 2495 searchResDone SearchResultDone, 2496 searchResRef SearchResultReference, 2497 modifyRequest ModifyRequest, 2498 modifyResponse ModifyResponse, 2499 addRequest AddRequest, 2500 addResponse AddResponse, 2501 delRequest DelRequest, 2502 delResponse DelResponse, 2503 modDNRequest ModifyDNRequest, 2504 modDNResponse ModifyDNResponse, 2505 compareRequest CompareRequest, 2506 compareResponse CompareResponse, 2507 abandonRequest AbandonRequest, 2508 extendedReq ExtendedRequest, 2509 extendedResp ExtendedResponse, 2510 intermediateResponse IntermediateResponse 2511 ... }, 2512 controls [0] Controls OPTIONAL } 2514 MessageID ::= INTEGER (0 .. maxInt) 2516 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 2518 LDAPString ::= OCTET STRING -- UTF-8 encoded, 2519 -- [ISO10646] characters 2521 LDAPOID ::= OCTET STRING -- Constrained to [Models] 2523 LDAPDN ::= LDAPString -- Constrained to 2524 -- [LDAPDN] 2526 RelativeLDAPDN ::= LDAPString -- Constrained to 2527 Lightweight Directory Access Protocol Version 3 2529 -- [LDAPDN] 2531 AttributeDescription ::= LDAPString 2532 -- Constrained to 2533 -- [Models] 2535 AttributeValue ::= OCTET STRING 2537 AttributeValueAssertion ::= SEQUENCE { 2538 attributeDesc AttributeDescription, 2539 assertionValue AssertionValue } 2541 AssertionValue ::= OCTET STRING 2543 PartialAttribute ::= SEQUENCE { 2544 type AttributeDescription, 2545 vals SET OF value AttributeValue } 2547 Attribute ::= PartialAttribute(WITH COMPONENTS { 2548 ..., 2549 vals (SIZE(1..MAX))}) 2551 MatchingRuleId ::= LDAPString 2553 LDAPResult ::= SEQUENCE { 2554 resultCode ENUMERATED { 2555 success (0), 2556 operationsError (1), 2557 protocolError (2), 2558 timeLimitExceeded (3), 2559 sizeLimitExceeded (4), 2560 compareFalse (5), 2561 compareTrue (6), 2562 authMethodNotSupported (7), 2563 strongAuthRequired (8), 2564 -- 9 reserved -- 2565 referral (10), 2566 adminLimitExceeded (11), 2567 unavailableCriticalExtension (12), 2568 confidentialityRequired (13), 2569 saslBindInProgress (14), 2570 noSuchAttribute (16), 2571 undefinedAttributeType (17), 2572 inappropriateMatching (18), 2573 constraintViolation (19), 2574 attributeOrValueExists (20), 2575 invalidAttributeSyntax (21), 2576 -- 22-31 unused -- 2577 noSuchObject (32), 2578 aliasProblem (33), 2579 invalidDNSyntax (34), 2580 -- 35 reserved for undefined isLeaf -- 2581 aliasDereferencingProblem (36), 2582 -- 37-47 unused -- 2584 Lightweight Directory Access Protocol Version 3 2586 inappropriateAuthentication (48), 2587 invalidCredentials (49), 2588 insufficientAccessRights (50), 2589 busy (51), 2590 unavailable (52), 2591 unwillingToPerform (53), 2592 loopDetect (54), 2593 -- 55-63 unused -- 2594 namingViolation (64), 2595 objectClassViolation (65), 2596 notAllowedOnNonLeaf (66), 2597 notAllowedOnRDN (67), 2598 entryAlreadyExists (68), 2599 objectClassModsProhibited (69), 2600 -- 70 reserved for CLDAP -- 2601 affectsMultipleDSAs (71), 2602 -- 72-79 unused -- 2603 other (80), 2604 ... }, 2605 matchedDN LDAPDN, 2606 diagnosticMessage LDAPString, 2607 referral [3] Referral OPTIONAL } 2609 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 2611 URI ::= LDAPString -- limited to characters permitted in 2612 -- URIs 2614 Controls ::= SEQUENCE OF control Control 2616 Control ::= SEQUENCE { 2617 controlType LDAPOID, 2618 criticality BOOLEAN DEFAULT FALSE, 2619 controlValue OCTET STRING OPTIONAL } 2621 BindRequest ::= [APPLICATION 0] SEQUENCE { 2622 version INTEGER (1 .. 127), 2623 name LDAPDN, 2624 authentication AuthenticationChoice } 2626 AuthenticationChoice ::= CHOICE { 2627 simple [0] OCTET STRING, 2628 -- 1 and 2 reserved 2629 sasl [3] SaslCredentials, 2630 ... } 2632 SaslCredentials ::= SEQUENCE { 2633 mechanism LDAPString, 2634 credentials OCTET STRING OPTIONAL } 2636 BindResponse ::= [APPLICATION 1] SEQUENCE { 2637 COMPONENTS OF LDAPResult, 2638 serverSaslCreds [7] OCTET STRING OPTIONAL } 2639 Lightweight Directory Access Protocol Version 3 2641 UnbindRequest ::= [APPLICATION 2] NULL 2643 SearchRequest ::= [APPLICATION 3] SEQUENCE { 2644 baseObject LDAPDN, 2645 scope ENUMERATED { 2646 baseObject (0), 2647 singleLevel (1), 2648 wholeSubtree (2) }, 2649 derefAliases ENUMERATED { 2650 neverDerefAliases (0), 2651 derefInSearching (1), 2652 derefFindingBaseObj (2), 2653 derefAlways (3) }, 2654 sizeLimit INTEGER (0 .. maxInt), 2655 timeLimit INTEGER (0 .. maxInt), 2656 typesOnly BOOLEAN, 2657 filter Filter, 2658 attributes AttributeSelection } 2660 AttributeSelection ::= SEQUENCE OF selector LDAPString 2661 -- The LDAPString is constrained to 2662 -- in Section 4.5.1 2664 Filter ::= CHOICE { 2665 and [0] SET SIZE (1..MAX) OF filter Filter, 2666 or [1] SET SIZE (1..MAX) OF filter Filter, 2667 not [2] Filter, 2668 equalityMatch [3] AttributeValueAssertion, 2669 substrings [4] SubstringFilter, 2670 greaterOrEqual [5] AttributeValueAssertion, 2671 lessOrEqual [6] AttributeValueAssertion, 2672 present [7] AttributeDescription, 2673 approxMatch [8] AttributeValueAssertion, 2674 extensibleMatch [9] MatchingRuleAssertion } 2676 SubstringFilter ::= SEQUENCE { 2677 type AttributeDescription, 2678 -- at least one must be present, 2679 -- initial and final can occur at most once 2680 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 2681 initial [0] AssertionValue, 2682 any [1] AssertionValue, 2683 final [2] AssertionValue } } 2685 MatchingRuleAssertion ::= SEQUENCE { 2686 matchingRule [1] MatchingRuleId OPTIONAL, 2687 type [2] AttributeDescription OPTIONAL, 2688 matchValue [3] AssertionValue, 2689 dnAttributes [4] BOOLEAN DEFAULT FALSE } 2691 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 2692 objectName LDAPDN, 2693 attributes PartialAttributeList } 2694 Lightweight Directory Access Protocol Version 3 2696 PartialAttributeList ::= SEQUENCE OF 2697 partialAttribute PartialAttribute 2699 SearchResultReference ::= [APPLICATION 19] SEQUENCE 2700 SIZE (1..MAX) OF uri URI 2702 SearchResultDone ::= [APPLICATION 5] LDAPResult 2704 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 2705 object LDAPDN, 2706 changes SEQUENCE OF change SEQUENCE { 2707 operation ENUMERATED { 2708 add (0), 2709 delete (1), 2710 replace (2) }, 2711 modification PartialAttribute } } 2713 ModifyResponse ::= [APPLICATION 7] LDAPResult 2715 AddRequest ::= [APPLICATION 8] SEQUENCE { 2716 entry LDAPDN, 2717 attributes AttributeList } 2719 AttributeList ::= SEQUENCE OF attribute Attribute 2721 AddResponse ::= [APPLICATION 9] LDAPResult 2723 DelRequest ::= [APPLICATION 10] LDAPDN 2725 DelResponse ::= [APPLICATION 11] LDAPResult 2727 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 2728 entry LDAPDN, 2729 newrdn RelativeLDAPDN, 2730 deleteoldrdn BOOLEAN, 2731 newSuperior [0] LDAPDN OPTIONAL } 2733 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 2735 CompareRequest ::= [APPLICATION 14] SEQUENCE { 2736 entry LDAPDN, 2737 ava AttributeValueAssertion } 2739 CompareResponse ::= [APPLICATION 15] LDAPResult 2741 AbandonRequest ::= [APPLICATION 16] MessageID 2743 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 2744 requestName [0] LDAPOID, 2745 requestValue [1] OCTET STRING OPTIONAL } 2747 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 2748 COMPONENTS OF LDAPResult, 2749 responseName [10] LDAPOID OPTIONAL, 2750 Lightweight Directory Access Protocol Version 3 2752 responseValue [11] OCTET STRING OPTIONAL } 2754 IntermediateResponse ::= [APPLICATION 25] SEQUENCE { 2755 responseName [0] LDAPOID OPTIONAL, 2756 responseValue [1] OCTET STRING OPTIONAL } 2758 END 2759 Lightweight Directory Access Protocol Version 3 2761 Appendix C - Changes 2763 This appendix is non-normative. 2765 This appendix summarizes substantive changes made to RFC 2251 and RFC 2766 2830. 2768 C.1 Changes made to RFC 2251: 2770 This section summarizes the substantive changes made to Sections 1, 2771 2, 3.1, and 4 through the remainder of RFC 2251. Readers should 2772 consult [Models] and [AuthMeth] for summaries of changes to other 2773 sections. 2775 C.1.1 Section 1 2777 - Removed IESG note. Post publication of RFC 2251, mandatory LDAP 2778 authentication mechanisms have been standardized which are 2779 sufficient to remove this note. See [AuthMeth] for authentication 2780 mechanisms. 2782 C.1.2 Section 3.1 and others 2784 - Removed notes giving history between LDAP v1, v2 and v3. Instead, 2785 added sufficient language so that this document can stand on its 2786 own. 2788 C.1.3 Section 4 2790 - Clarified where the extensibility features of ASN.1 apply to the 2791 protocol. This change also affected various ASN.1 types. 2792 - Removed the requirement that servers which implement version 3 or 2793 later MUST provide the 'supportedLDAPVersion' attribute. This 2794 statement provided no interoperability advantages. 2796 C.1.4 Section 4.1.1 2798 - There was a mandatory requirement for the server to return a 2799 Notice of Disconnection and drop the connection when a PDU is 2800 malformed in a certain way. This has been clarified such that the 2801 server SHOULD return the Notice of Disconnection, and MUST drop 2802 the connection. 2804 C.1.5 Section 4.1.1.1 2806 - Clarified that the messageID of requests MUST be non-zero. 2808 Lightweight Directory Access Protocol Version 3 2810 - Clarified when it is and isn't appropriate to return an already 2811 used message id. RFC 2251 accidentally imposed synchronous server 2812 behavior in its wording of this. 2814 C.1.6 Section 4.1.2 2816 - Stated that LDAPOID is constrained to from [Models]. 2818 C.1.7 Section 4.1.5.1 2820 - Removed the Binary Option from the specification. There are 2821 numerous interoperability problems associated with this method of 2822 alternate attribute type encoding. Work to specify a suitable 2823 replacement is ongoing. 2825 C.1.8 Section 4.1.6 2827 - Removed references to the "binary" encoding as it has been removed 2828 from the specification. 2830 C.1.9 Section 4.1.7 2832 - Removed references to the "binary" encoding as it has been removed 2833 from the specification. 2835 C.1.10 Section 4.1.8 2837 - Combined the definitions of PartialAttribute and Attribute here, 2838 and defined Attribute in terms of PartialAttribute. 2840 C.1.11 Section 4.1.10 2842 - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to 2843 be sent for non-error results. 2844 - Moved some language into Appendix A, and refer the reader there. 2845 - Allowed matchedDN to be present for other result codes than those 2846 listed in RFC 2251. 2848 C.1.12 Section 4.1.11 2850 - Defined referrals in terms of URIs rather than URLs. 2851 - Removed the requirement that all referral URIs MUST be equally 2852 capable of progressing the operation. The statement was ambiguous 2853 and provided no instructions on how to carry it out. 2854 - Added the requirement that clients MUST NOT loop between servers. 2855 - Clarified the instructions for using LDAPURLs in referrals, and in 2856 doing so added a recommendation that the scope part be present. 2858 Lightweight Directory Access Protocol Version 3 2860 C.1.13 Section 4.1.12 2862 - Specified how control values defined in terms of ASN.1 are to be 2863 encoded. 2864 - Noted that the criticality field is only applied to request 2865 messages (except unbindRequest), and must be ignored when present 2866 on response messages and unbindRequest. 2867 - Added language regarding combinations of controls and the ordering 2868 of controls on a message. 2869 - Specified that when the semantics of the combination of controls 2870 is undefined or unknown, it results in a protocolError. 2871 - Changed "The server MUST be prepared" to "Implementations MUST be 2872 prepared" in the eighth paragraph to reflect that both client and 2873 server implementations must be able to handle this (as both parse 2874 controls). 2876 C.1.14 Section 4.2 2878 - Mandated that servers return protocolError when the version is not 2879 supported. 2880 - Clarified behavior when the simple authentication is used, the 2881 name is empty and the password is non-empty. 2882 - Required servers to not dereference aliases for bind. This was 2883 added for consistency with other operations and to help ensure 2884 data consistency. 2885 - Required that textual passwords be transferred as UTF-8 encoded 2886 Unicode, and added recommendations on string preparation. This was 2887 to help ensure interoperability of passwords being sent from 2888 different clients. 2890 C.1.15 Section 4.2.1 2892 - This section was largely reorganized for readability and language 2893 was added to clarify the authentication state of failed and 2894 abandoned bind operations. 2895 - Removed: "If a SASL transfer encryption or integrity mechanism has 2896 been negotiated, that mechanism does not support the changing of 2897 credentials from one identity to another, then the client MUST 2898 instead establish a new connection." 2899 Each SASL negotiation is, generally, independent of other SASL 2900 negotiations. If there were dependencies between multiple 2901 negotiations of a particular mechanism, the mechanism technical 2902 specification should detail how applications are to deal with 2903 them. LDAP should not require any special handling. And if an LDAP 2904 client had used such a mechanism, it would have the option of 2905 using another mechanism. 2906 - Dropped MUST imperative in paragraph 3 to align with [Keywords]. 2907 - Mandated that clients not send non-bind operations while a bind is 2908 in progress, and suggested that servers not process them if they 2909 Lightweight Directory Access Protocol Version 3 2911 are received. This is needed to ensure proper sequencing of the 2912 bind in relationship to other operations. 2914 C.1.16 Section 4.2.3 2916 - Moved most error-related text to Appendix A, and added text 2917 regarding certain errors used in conjunction with the bind 2918 operation. 2919 - Prohibited the server from specifying serverSaslCreds when not 2920 appropriate. 2922 C.1.17 Section 4.3 2924 - Required both peers to cease transmission and close the LDAP 2925 exchange for the unbind operation. 2927 C.1.18 Section 4.4 2929 - Added instructions for future specifications of Unsolicited 2930 Notifications. 2932 C.1.19 Section 4.5.1 2934 - SearchRequest attributes is now defined as an AttributeSelection 2935 type rather than AttributeDescriptionList, and an ABNF is 2936 provided. 2937 - SearchRequest attributes may contain duplicate attribute 2938 descriptions. This was previously prohibited. Now servers are 2939 instructed to ignore subsequent names when they are duplicated. 2940 This was relaxed in order to allow different short names and also 2941 OIDs to be requested for an attribute. 2942 - The Filter choices 'and' and 'or', and the SubstringFilter 2943 substrings types are now defined with a lower bound of 1. 2944 - The SubstringFilter substrings 'initial, 'any', and 'final' types 2945 are now AssertionValue rather than LDAPString. Also, added 2946 imperatives stating that 'initial' (if present) must be listed 2947 first, and 'final' (if present) must be listed last. 2948 - Clarified the semantics of the derefAliases choices. 2949 - Added instructions for equalityMatch, substrings, greaterOrEqual, 2950 lessOrEqual, and approxMatch. 2952 C.1.20 Section 4.5.2 2954 - Recommended that servers not use attribute short names when it 2955 knows they are ambiguous or may cause interoperability problems. 2956 - Removed all mention of ExtendedResponse due to lack of 2957 implementation. 2959 Lightweight Directory Access Protocol Version 3 2961 C.1.21 Section 4.5.3 2963 - Made changes similar to those made to Section 4.1.11. 2965 C.1.22 Section 4.5.3.1 2967 - Fixed examples to adhere to changes made to Section 4.5.3. 2969 C.1.23 Section 4.6 2971 - Removed restriction that required an EQUALITY matching rule in 2972 order to perform value delete modifications. It is sufficiently 2973 documented that in absence of an equality matching rule, octet 2974 equality is used. 2975 - Replaced AttributeTypeAndValues with Attribute as they are 2976 equivalent. 2977 - Clarified what type of modification changes might temporarily 2978 violate schema. 2980 C.1.24 Section 4.7 2982 - Aligned Add operation with X.511 in that the attributes of the RDN 2983 are used in conjunction with the listed attributes to create the 2984 entry. Previously, Add required that the distinguished values be 2985 present in the listed attributes. 2987 C.1.25 Section 4.9 2989 - Required servers to not dereference aliases for modify DN. This 2990 was added for consistency with other operations and to help ensure 2991 data consistency. 2992 - Allow modify DN to fail when moving between naming contexts. 2993 - Specified what happens when the attributes of the newrdn are no 2994 present on the entry. 2996 C.1.26 Section 4.10 2998 - Clarified that compareFalse means that the compare took place and 2999 the result is false. There was confusion which lead people to 3000 believe that an Undefined match resulted in compareFalse. 3001 - Required servers to not dereference aliases for compare. This was 3002 added for consistency with other operations and to help ensure 3003 data consistency. 3005 C.1.27 Section 4.11 3007 - Explained that since abandon returns no response, clients should 3008 not use it if they need to know the outcome. 3010 Lightweight Directory Access Protocol Version 3 3012 - Specified that Abandon and Unbind cannot be abandoned. 3014 C.1.28 Section 4.12 3016 - Specified how values of extended operations defined in terms of 3017 ASN.1 are to be encoded. 3018 - Added instructions on what extended operation specifications 3019 consist of. 3020 - Added a recommendation that servers advertise supported extended 3021 operations. 3023 C.1.29 Section 5.2 3025 - Moved referral-specific instructions into referral-related 3026 sections. 3028 C.1.30 Section 7 3030 - Reworded notes regarding SASL not protecting certain aspects of 3031 the LDAP bind PDU. 3032 - Noted that Servers are encouraged to prevent directory 3033 modifications by clients that have authenticated anonymously 3034 [AuthMeth]. 3035 - Added a note regarding the scenario where an identity is changed 3036 (deleted, privileges or credentials modified, etc.). 3037 - Warned against following referrals that may have been injected in 3038 the data stream. 3039 - Noted that servers should protect information equally, whether in 3040 an error condition or not, and mentioned specifically; matchedDN, 3041 diagnosticMessage, and resultCodes. 3042 - Added a note regarding malformed and long encodings. 3044 C.1.31 Appendix A 3046 - Added "EXTESIBILITY IMPLIED" to ASN.1 definition. 3047 - Removed AttributeType. It is not used. 3049 C.2 Changes made to RFC 2830: 3051 This section summarizes the substantive changes made to Sections of 3052 RFC 2830. Readers should consult [AuthMeth] for summaries of changes 3053 to other sections. 3055 C.2.1 Section 2.3 3057 - Removed wording indicating that referrals can be returned from 3058 StartTLS 3059 Lightweight Directory Access Protocol Version 3 3061 - Removed requirement that only a narrow set of result codes can be 3062 returned. Some result codes are required in certain scenarios, but 3063 any other may be returned if appropriate. 3065 C.2.1 Section 4.13.3.1 3067 - Reworded most of this section and added the requirement that after 3068 the TLS connection has been closed, the server MUST NOT send 3069 responses to any request message received before the TLS closure. 3071 C.3 Changes made to RFC 3771: 3073 - In general, all technical language was transferred in whole. 3074 Supporting and background language seen as redundant due to its 3075 presence in this document was omitted. 3077 Lightweight Directory Access Protocol Version 3 3079 Intellectual Property Rights 3081 The IETF takes no position regarding the validity or scope of any 3082 intellectual property or other rights that might be claimed to 3083 pertain to the implementation or use of the technology described in 3084 this document or the extent to which any license under such rights 3085 might or might not be available; neither does it represent that it 3086 has made any effort to identify any such rights. Information on the 3087 IETF's procedures with respect to rights in standards-track and 3088 standards-related documentation can be found in BCP-11. Copies of 3089 claims of rights made available for publication and any assurances of 3090 licenses to be made available, or the result of an attempt made to 3091 obtain a general license or permission for the use of such 3092 proprietary rights by implementors or users of this specification can 3093 be obtained from the IETF Secretariat. 3095 The IETF invites any interested party to bring to its attention any 3096 copyrights, patents or patent applications, or other proprietary 3097 rights which may cover technology that may be required to practice 3098 this standard. Please address the information to the IETF Executive 3099 Director. 3101 Full Copyright Statement 3103 Copyright (C) The Internet Society (2003). All Rights Reserved. 3105 This document and translations of it may be copied and furnished to 3106 others, and derivative works that comment on or otherwise explain it 3107 or assist in its implementation may be prepared, copied, published 3108 and distributed, in whole or in part, without restriction of any 3109 kind, provided that the above copyright notice and this paragraph are 3110 included on all such copies and derivative works. However, this 3111 document itself may not be modified in any way, such as by removing 3112 the copyright notice or references to the Internet Society or other 3113 Internet organizations, except as needed for the purpose of 3114 developing Internet standards in which case the procedures for 3115 copyrights defined in the Internet Standards process must be 3116 followed, or as required to translate it into languages other than 3117 English. 3119 The limited permissions granted above are perpetual and will not be 3120 revoked by the Internet Society or its successors or assigns. 3122 This document and the information contained herein is provided on an 3123 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3124 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3125 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3126 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3127 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.