idnits 2.17.1 draft-ietf-ldapbis-protocol-22.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 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 (Feb 2004) is 7375 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 2699 -- Looks like a reference, but probably isn't: '3' on line 2643 == Missing Reference: 'APPLICATION 0' is mentioned on line 2576, but not defined == Missing Reference: 'SASLprep' is mentioned on line 728, but not defined == Missing Reference: 'Stringprep' is mentioned on line 728, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 2591, but not defined -- Looks like a reference, but probably isn't: '7' on line 2627 == Missing Reference: 'APPLICATION 2' is mentioned on line 2596, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 2598, but not defined -- Looks like a reference, but probably isn't: '1' on line 2700 -- Looks like a reference, but probably isn't: '2' on line 2642 -- Looks like a reference, but probably isn't: '4' on line 2644 -- Looks like a reference, but probably isn't: '5' on line 2625 -- Looks like a reference, but probably isn't: '6' on line 2626 -- Looks like a reference, but probably isn't: '8' on line 2628 -- Looks like a reference, but probably isn't: '9' on line 2629 == Missing Reference: 'APPLICATION 4' is mentioned on line 2646, but not defined == Missing Reference: 'APPLICATION 19' is mentioned on line 2654, but not defined == Missing Reference: 'APPLICATION 5' is mentioned on line 2657, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 2659, but not defined == Missing Reference: 'APPLICATION 7' is mentioned on line 2668, but not defined == Missing Reference: 'APPLICATION 8' is mentioned on line 2670, but not defined == Missing Reference: 'APPLICATION 9' is mentioned on line 2676, but not defined == Missing Reference: 'APPLICATION 10' is mentioned on line 2678, but not defined == Missing Reference: 'APPLICATION 11' is mentioned on line 2680, but not defined == Missing Reference: 'APPLICATION 12' is mentioned on line 2682, but not defined == Missing Reference: 'APPLICATION 13' is mentioned on line 2688, but not defined == Missing Reference: 'APPLICATION 14' is mentioned on line 2690, but not defined == Missing Reference: 'APPLICATION 15' is mentioned on line 2694, but not defined == Missing Reference: 'APPLICATION 16' is mentioned on line 2696, but not defined == Missing Reference: 'APPLICATION 23' is mentioned on line 2698, but not defined == Missing Reference: 'APPLICATION 24' is mentioned on line 2702, but not defined -- Looks like a reference, but probably isn't: '10' on line 2704 -- Looks like a reference, but probably isn't: '11' on line 2707 == Missing Reference: 'APPLICATION 25' is mentioned on line 1767, but not defined == Missing Reference: 'RFC2251' is mentioned on line 1808, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Missing Reference: 'Keywords' is mentioned on line 2854, but not defined == Unused Reference: 'IP' is defined on line 2100, but no explicit reference was found in the text == Unused Reference: 'SASLPrep' is defined on line 2136, but no explicit reference was found in the text == Unused Reference: 'StringPrep' is defined on line 2140, 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-rharrison-ldap-intermediate-resp-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LIMR' -- 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: 5 errors (**), 0 flaws (~~), 32 warnings (==), 43 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-22.txt Feb 2004 4 Obsoletes: RFC 2251, 2830, [LIMR] 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..................................................3 47 4. Elements of Protocol............................................4 48 4.1. Common Elements...............................................4 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..........6 54 4.1.4. Attribute Descriptions......................................7 55 4.1.5. Attribute Value.............................................7 56 4.1.6. Attribute Value Assertion...................................7 57 4.1.7. Attribute and PartialAttribute..............................8 58 4.1.8. Matching Rule Identifier....................................8 59 4.1.9. Result Message..............................................8 60 4.1.10. Referral..................................................10 61 4.1.11. Controls..................................................11 62 4.2. Bind Operation...............................................13 63 4.3. Unbind Operation.............................................16 64 4.4. Unsolicited Notification.....................................16 65 4.5. Search Operation.............................................17 66 4.6. Modify Operation.............................................26 67 4.7. Add Operation................................................27 68 4.8. Delete Operation.............................................28 69 4.9. Modify DN Operation..........................................29 70 4.10. Compare Operation...........................................30 71 4.11. Abandon Operation...........................................31 72 4.12. Extended Operation..........................................31 73 4.13. IntermediateResponse Message................................33 74 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......33 75 4.13.2. Usage with LDAP Request Controls..........................34 76 4.14. StartTLS Operation..........................................34 77 5. Protocol Element Encodings and Transfer........................36 78 5.1. Protocol Encoding............................................37 79 5.2. Transfer Protocols...........................................37 80 6. Security Considerations........................................38 81 7. Acknowledgements...............................................39 82 8. Normative References...........................................39 83 9. Informative References.........................................41 84 10. IANA Considerations...........................................41 85 11. Editor's Address..............................................41 86 Appendix A - LDAP Result Codes....................................42 87 A.1 Non-Error Result Codes........................................42 88 A.2 Result Codes..................................................42 89 Appendix B - Complete ASN.1 Definition............................46 90 Appendix C - Changes..............................................52 91 C.1 Changes made to made to RFC 2251:.............................52 92 C.2 Changes made to made to RFC 2830:.............................57 93 C.3 Changes made to made to [LIMR]:...............................58 95 1. Introduction 97 The Directory is "a collection of open systems cooperating to provide 98 directory services" [X.500]. A directory user, which may be a human 99 or other entity, accesses the Directory through a client (or 100 Directory User Agent (DUA)). The client, on behalf of the directory 101 user, interacts with one or more servers (or Directory System Agents 102 (DSA)). Clients interact with servers using a directory access 103 protocol. 105 Lightweight Directory Access Protocol Version 3 107 This document details the protocol elements of the Lightweight 108 Directory Access Protocol (LDAP), along with their semantics. 109 Following the description of protocol elements, it describes the way 110 in which the protocol elements are encoded and transferred. 112 1.1. Relationship to Obsolete Specifications 114 This document is an integral part of the LDAP Technical Specification 115 [Roadmap] which obsoletes the previously defined LDAP technical 116 specification, RFC 3377, in its entirety. 118 This document obsoletes all of RFC 2251 except the following: 119 Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, 120 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are 121 obsoleted by [Models]. 122 Section 3.3 is obsoleted by [Roadmap]. 123 Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth]. 125 Appendix C.1 summarizes substantive changes to the remaining 126 sections. 128 This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The 129 remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 130 summarizes substantive changes to the remaining sections. 132 This document also obsoletes [LIMR] in entirety. 133 <> 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 141 to be interpreted as described in [Keyword]. 143 The terms "connection" and "LDAP connection" both refer to the 144 underlying transport protocol connection between two protocol peers. 146 The term "TLS connection" refers to a [TLS]-protected LDAP 147 connection. 149 The terms "association" and "LDAP association" both refer to the 150 association of the LDAP connection and its current authentication and 151 authorization state. 153 3. Protocol Model 155 The general model adopted by this protocol is one of clients 156 performing protocol operations against servers. In this model, a 157 client transmits a protocol request describing the operation to be 158 Lightweight Directory Access Protocol Version 3 160 performed to a server. The server is then responsible for performing 161 the necessary operation(s) in the Directory. Upon completion of an 162 operation, the server typically returns a response containing 163 appropriate data to the requesting client. 165 Although servers are required to return responses whenever such 166 responses are defined in the protocol, there is no requirement for 167 synchronous behavior on the part of either clients or servers. 168 Requests and responses for multiple operations generally may be 169 exchanged between a client and server in any order, provided the 170 client eventually receives a response for every request that requires 171 one. 173 The core protocol operations defined in this document can be mapped 174 to a subset of the X.500 (1993) Directory Abstract Service [X.511]. 175 However there is not a one-to-one mapping between LDAP operations and 176 X.500 Directory Access Protocol (DAP) operations. Server 177 implementations acting as a gateway to X.500 directories may need to 178 make multiple DAP requests to service a single LDAP request. 180 4. Elements of Protocol 182 The protocol is described using Abstract Syntax Notation One 183 ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding 184 Rules ([BER]). Section 5.1 specifies how the protocol elements are 185 encoded and transferred. 187 In order to support future extensions to this protocol, extensibility 188 is implied where it is allowed per ASN.1 (i.e. sequence, set, choice, 189 and enumerated types are extensible). In addition, ellipses (...) 190 have been supplied in ASN.1 types that are explicitly extensible as 191 discussed in [LDAPIANA]. Because of the implied extensibility, 192 clients and servers MUST (unless otherwise specified) ignore trailing 193 SEQUENCE components whose tags they do not recognize. 195 Changes to the protocol other than through the extension mechanisms 196 described here require a different version number. A client indicates 197 the version it is using as part of the bind request, described in 198 Section 4.2. If a client has not sent a bind, the server MUST assume 199 the client is using version 3 or later. 201 Clients may determine the protocol versions a server supports by 202 reading the 'supportedLDAPVersion' attribute from the root DSE (DSA- 203 Specific Entry) [Models]. 205 4.1. Common Elements 207 This section describes the LDAPMessage envelope Protocol Data Unit 208 (PDU) format, as well as data type definitions, which are used in the 209 protocol operations. 211 Lightweight Directory Access Protocol Version 3 213 4.1.1. Message Envelope 215 For the purposes of protocol exchanges, all protocol operations are 216 encapsulated in a common envelope, the LDAPMessage, which is defined 217 as follows: 219 LDAPMessage ::= SEQUENCE { 220 messageID MessageID, 221 protocolOp CHOICE { 222 bindRequest BindRequest, 223 bindResponse BindResponse, 224 unbindRequest UnbindRequest, 225 searchRequest SearchRequest, 226 searchResEntry SearchResultEntry, 227 searchResDone SearchResultDone, 228 searchResRef SearchResultReference, 229 modifyRequest ModifyRequest, 230 modifyResponse ModifyResponse, 231 addRequest AddRequest, 232 addResponse AddResponse, 233 delRequest DelRequest, 234 delResponse DelResponse, 235 modDNRequest ModifyDNRequest, 236 modDNResponse ModifyDNResponse, 237 compareRequest CompareRequest, 238 compareResponse CompareResponse, 239 abandonRequest AbandonRequest, 240 extendedReq ExtendedRequest, 241 extendedResp ExtendedResponse, 242 intermediateResponse IntermediateResponse 243 ... }, 244 controls [0] Controls OPTIONAL } 246 MessageID ::= INTEGER (0 .. maxInt) 248 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 250 The ASN.1 type Controls is defined in Section 4.1.11. 252 The function of the LDAPMessage is to provide an envelope containing 253 common fields required in all protocol exchanges. At this time the 254 only common fields are the message ID and the controls. 256 If the server receives a PDU from the client in which the LDAPMessage 257 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 258 the tag of the protocolOp is not recognized as a request, or the 259 encoding structures or lengths of data fields are found to be 260 incorrect, then the server SHOULD return the Notice of Disconnection 261 described in Section 4.4.1, with the resultCode set to protocolError, 262 and MUST immediately close the connection. 264 In other cases where the client or server cannot parse a PDU, it 265 SHOULD abruptly close the connection where further communication 266 (including providing notice) would be pernicious. Otherwise, server 267 Lightweight Directory Access Protocol Version 3 269 implementations MUST return an appropriate response to the request, 270 with the resultCode set to protocolError. 272 4.1.1.1. Message ID 274 All LDAPMessage envelopes encapsulating responses contain the 275 messageID value of the corresponding request LDAPMessage. 277 The message ID of a request MUST have a non-zero value different from 278 the values of any other requests outstanding in the LDAP association 279 of which this message is a part. The zero value is reserved for the 280 unsolicited notification message. 282 Typical clients increment a counter for each request. 284 A client MUST NOT send a request with the same message ID as an 285 earlier request on the same LDAP association unless it can be 286 determined that the server is no longer servicing the earlier request 287 (e.g. after the final response is received, or a subsequent bind 288 completes). Otherwise the behavior is undefined. For this purpose, 289 note that abandon and abandoned operations do not send responses. 291 4.1.2. String Types 293 The LDAPString is a notational convenience to indicate that, although 294 strings of LDAPString type encode as ASN.1 OCTET STRING types, the 295 [ISO10646] character set (a superset of [Unicode]) is used, encoded 296 following the [UTF-8] algorithm. Note that Unicode characters U+0000 297 through U+007F are the same as ASCII 0 through 127, respectively, and 298 have the same single octet UTF-8 encoding. Other Unicode characters 299 have a multiple octet UTF-8 encoding. 301 LDAPString ::= OCTET STRING -- UTF-8 encoded, 302 -- [ISO10646] characters 304 The LDAPOID is a notational convenience to indicate that the 305 permitted value of this string is a (UTF-8 encoded) dotted-decimal 306 representation of an OBJECT IDENTIFIER. Although an LDAPOID is 307 encoded as an OCTET STRING, values are limited to the definition of 308 given in Section 1.4 of [Models]. 310 LDAPOID ::= OCTET STRING -- Constrained to [Models] 312 For example, 314 1.3.6.1.4.1.1466.1.2.3 316 4.1.3. Distinguished Name and Relative Distinguished Name 318 An LDAPDN is defined to be the representation of a Distinguished Name 319 (DN) after encoding according to the specification in [LDAPDN]. 321 Lightweight Directory Access Protocol Version 3 323 LDAPDN ::= LDAPString 324 -- Constrained to [LDAPDN] 326 A RelativeLDAPDN is defined to be the representation of a Relative 327 Distinguished Name (RDN) after encoding according to the 328 specification in [LDAPDN]. 330 RelativeLDAPDN ::= LDAPString 331 -- Constrained to [LDAPDN] 333 4.1.4. Attribute Descriptions 335 The definition and encoding rules for attribute descriptions are 336 defined in Section 2.5 of [Models]. Briefly, an attribute description 337 is an attribute type and zero or more options. 339 AttributeDescription ::= LDAPString 340 -- Constrained to 341 -- [Models] 343 4.1.5. Attribute Value 345 A field of type AttributeValue is an OCTET STRING containing an 346 encoded attribute value. The attribute value is encoded according to 347 the LDAP-specific encoding definition of its corresponding syntax. 348 The LDAP-specific encoding definitions for different syntaxes and 349 attribute types may be found in other documents and in particular 350 [Syntaxes]. 352 AttributeValue ::= OCTET STRING 354 Note that there is no defined limit on the size of this encoding; 355 thus protocol values may include multi-megabyte attribute values 356 (e.g. photographs). 358 Attribute values may be defined which have arbitrary and non- 359 printable syntax. Implementations MUST NOT display nor attempt to 360 decode an attribute value if its syntax is not known. The 361 implementation may attempt to discover the subschema of the source 362 entry, and retrieve the descriptions of 'attributeTypes' from it 363 [Models]. 365 Clients MUST only send attribute values in a request that are valid 366 according to the syntax defined for the attributes. 368 4.1.6. Attribute Value Assertion 370 The AttributeValueAssertion (AVA) type definition is similar to the 371 one in the X.500 Directory standards. It contains an attribute 372 description and a matching rule ([Models Section 4.1.3) assertion 373 Lightweight Directory Access Protocol Version 3 375 value suitable for that type. Elements of this type are typically 376 used to assert that the value in assertionValue matches a value of an 377 attribute. 379 AttributeValueAssertion ::= SEQUENCE { 380 attributeDesc AttributeDescription, 381 assertionValue AssertionValue } 383 AssertionValue ::= OCTET STRING 385 The syntax of the AssertionValue depends on the context of the LDAP 386 operation being performed. For example, the syntax of the EQUALITY 387 matching rule for an attribute is used when performing a Compare 388 operation. Often this is the same syntax used for values of the 389 attribute type, but in some cases the assertion syntax differs from 390 the value syntax. See objectIdentiferFirstComponentMatch in 391 [Syntaxes] for an example. 393 4.1.7. Attribute and PartialAttribute 395 Attributes and partial attributes consist of an attribute description 396 and attribute values. A PartialAttribute allows zero values, while 397 Attribute requires at least one value. 399 PartialAttribute ::= SEQUENCE { 400 type AttributeDescription, 401 vals SET OF value AttributeValue } 403 Attribute ::= PartialAttribute(WITH COMPONENTS { 404 ..., 405 vals (SIZE(1..MAX))}) 407 No two attribute values are equivalent as described by Section 2.3 of 408 [Models]. The set of attribute values is unordered. Implementations 409 MUST NOT rely upon the ordering being repeatable. 411 4.1.8. Matching Rule Identifier 413 Matching rules are defined in Section 4.1.3 of [Models]. A matching 414 rule is identified in the protocol by the printable representation of 415 either its , or one of its short name descriptors 416 [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'. 418 MatchingRuleId ::= LDAPString 420 4.1.9. Result Message 422 The LDAPResult is the construct used in this protocol to return 423 success or failure indications from servers to clients. To various 424 requests, servers will return responses of LDAPResult or responses 425 Lightweight Directory Access Protocol Version 3 427 containing the components of LDAPResult to indicate the final status 428 of a protocol operation request. 430 LDAPResult ::= SEQUENCE { 431 resultCode ENUMERATED { 432 success (0), 433 operationsError (1), 434 protocolError (2), 435 timeLimitExceeded (3), 436 sizeLimitExceeded (4), 437 compareFalse (5), 438 compareTrue (6), 439 authMethodNotSupported (7), 440 strongAuthRequired (8), 441 -- 9 reserved -- 442 referral (10), 443 adminLimitExceeded (11), 444 unavailableCriticalExtension (12), 445 confidentialityRequired (13), 446 saslBindInProgress (14), 447 noSuchAttribute (16), 448 undefinedAttributeType (17), 449 inappropriateMatching (18), 450 constraintViolation (19), 451 attributeOrValueExists (20), 452 invalidAttributeSyntax (21), 453 -- 22-31 unused -- 454 noSuchObject (32), 455 aliasProblem (33), 456 invalidDNSyntax (34), 457 -- 35 reserved for undefined isLeaf -- 458 aliasDereferencingProblem (36), 459 -- 37-47 unused -- 460 inappropriateAuthentication (48), 461 invalidCredentials (49), 462 insufficientAccessRights (50), 463 busy (51), 464 unavailable (52), 465 unwillingToPerform (53), 466 loopDetect (54), 467 -- 55-63 unused -- 468 namingViolation (64), 469 objectClassViolation (65), 470 notAllowedOnNonLeaf (66), 471 notAllowedOnRDN (67), 472 entryAlreadyExists (68), 473 objectClassModsProhibited (69), 474 -- 70 reserved for CLDAP -- 475 affectsMultipleDSAs (71), 476 -- 72-79 unused -- 477 other (80), 478 ... }, 479 matchedDN LDAPDN, 480 diagnosticMessage LDAPString, 481 Lightweight Directory Access Protocol Version 3 483 referral [3] Referral OPTIONAL } 485 The resultCode enumeration is extensible as defined in Section 3.6 of 486 [LDAPIANA]. The meanings of the listed result codes are given in 487 Appendix A. If a server detects multiple errors for an operation, 488 only one result code is returned. The server should return the result 489 code that best indicates the nature of the error encountered. 491 The diagnosticMessage field of this construct may, at the server's 492 option, be used to return a string containing a textual, human- 493 readable (terminal control and page formatting characters should be 494 avoided) diagnostic message. As this diagnostic message is not 495 standardized, implementations MUST NOT rely on the values returned. 496 If the server chooses not to return a textual diagnostic, the 497 diagnosticMessage field MUST be empty. 499 For certain result codes (typically, but not restricted to 500 noSuchObject, aliasProblem, invalidDNSyntax and 501 aliasDereferencingProblem), the matchedDN field is set to the name of 502 the lowest entry (object or alias) in the Directory that was matched. 503 If no aliases were dereferenced while attempting to locate the entry, 504 this will be a truncated form of the name provided, or if aliases 505 were dereferenced, of the resulting name, as defined in Section 12.5 506 of [X.511]. Otherwise the matchedDN field is empty. 508 4.1.10. Referral 510 The referral result code indicates that the contacted server does not 511 hold the target entry of the request. The referral field is present 512 in an LDAPResult if the resultCode field value is referral, and 513 absent with all other result codes. It contains one or more 514 references to one or more servers or services that may be accessed 515 via LDAP or other protocols. Referrals can be returned in response to 516 any operation request (except unbind and abandon which do not have 517 responses). At least one URI MUST be present in the Referral. 519 During a search operation, after the baseObject is located, and 520 entries are being evaluated, the referral is not returned. Instead, 521 continuation references, described in Section 4.5.3, are returned 522 when other servers would need to be contacted to complete the 523 operation. 525 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 527 URI ::= LDAPString -- limited to characters permitted in 528 -- URIs 530 If the client wishes to progress the operation, it MUST follow the 531 referral by contacting one of the supported services. If multiple 532 URIs are present, the client assumes that any supported URI may be 533 used to progress the operation. 535 Lightweight Directory Access Protocol Version 3 537 Protocol peers that follow referrals MUST ensure that they do not 538 loop between servers. They MUST NOT repeatedly contact the same 539 server for the same request with the same target entry name, scope 540 and filter. Some implementations use a counter that is incremented 541 each time referral handling occurs for an operation, and these kinds 542 of implementations MUST be able to handle at least ten nested 543 referrals between the root and a leaf entry. 545 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 546 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 548 When an LDAP URL is used, the following instructions are followed: 550 - If an alias was dereferenced, the part of the URL MUST be 551 present, with the new target object name. UTF-8 encoded characters 552 appearing in the string representation of a DN or search filter 553 may not be legal for URLs (e.g. spaces) and MUST be escaped using 554 the % method in [URI]. 555 - It is RECOMMENDED that the part be present to avoid 556 ambiguity. 557 - If the part is present, the client MUST use this name in its 558 next request to progress the operation, and if it is not present 559 the client will use the same name as in the original request. 560 - Some servers (e.g. participating in distributed indexing) may 561 provide a different filter in a URL of a referral for a search 562 operation. 563 - If the part of the LDAP URL is present, the client MUST 564 use this filter in its next request to progress this search, and 565 if it is not present the client MUST use the same filter as it 566 used for that search. 567 - For search, it is RECOMMENDED that the part be present to 568 avoid ambiguity. 569 - If the part is missing, the scope of the original search 570 is used by the client to progress the operation. 571 - Other aspects of the new request may be the same as or different 572 from the request which generated the referral. 574 Other kinds of URIs may be returned. The syntax and semantics of such 575 URIs is left to future specifications. Clients may ignore URIs that 576 they do not support. 578 4.1.11. Controls 580 Controls provide a mechanism whereby the semantics and arguments of 581 existing LDAP operations may be extended. One or more controls may be 582 attached to a single LDAP message. A control only affects the 583 semantics of the message it is attached to. 585 Controls sent by clients are termed 'request controls' and those sent 586 by servers are termed 'response controls'. 587 When an extension calls for a particular response control to be sent 588 in response to a request control, the response and request controls 589 are termed to be "paired". 591 Lightweight Directory Access Protocol Version 3 593 Controls ::= SEQUENCE OF control Control 595 Control ::= SEQUENCE { 596 controlType LDAPOID, 597 criticality BOOLEAN DEFAULT FALSE, 598 controlValue OCTET STRING OPTIONAL } 600 The controlType field is the dotted-decimal representation of an 601 OBJECT IDENTIFIER which uniquely identifies the control, or the 602 request control and its paired response control. This provides 603 unambiguous naming of controls. 605 The criticality field only has meaning in controls attached to 606 request messages (except unbindRequest). For controls attached to 607 response messages and the unbindRequest, the criticality field SHOULD 608 be FALSE, and MUST be ignored by the receiving protocol peer. A value 609 of TRUE indicates that it is unacceptable to perform the operation 610 without applying the semantics of the control and FALSE otherwise. 611 Specifically, the criticality field is applied as follows: 613 - Regardless of the value of the criticality field, if the server 614 recognizes the control type and it is appropriate for the 615 operation, the server is to make use of the control when 616 performing the operation. 618 - If the server does not recognize the control type or it is not 619 appropriate for the operation, and the criticality field is TRUE, 620 the server MUST NOT perform the operation, and for operations that 621 have a response message, MUST return unavailableCriticalExtension 622 in the resultCode. 624 - If the server does not recognize the control type or it is not 625 appropriate for the operation, and the criticality field is FALSE, 626 the server MUST ignore the control. 628 The controlValue may contain information associated with the 629 controlType. Its format is defined by the specification of the 630 control. Implementations MUST be prepared to handle arbitrary 631 contents of the controlValue octet string, including zero bytes. It 632 is absent only if there is no value information which is associated 633 with a control of its type. When a controlValue is defined in terms 634 of ASN.1, and BER encoded according to Section 5.1, it also follows 635 the extensibility rules in Section 4. 637 Servers list the controlType of all request controls they recognize 638 in the supportedControl attribute in the root DSE (Section 5.1 of 639 [Models]). 641 Controls SHOULD NOT be combined unless the semantics of the 642 combination has been specified. The semantics of control 643 combinations, if specified, are generally found in the control 644 specification most recently published. In the absence of combination 645 semantics, the behavior of the operation is undefined. 647 Lightweight Directory Access Protocol Version 3 649 Additionally, unless order-dependent semantics are given in a 650 specification, the order of a combination of controls in the SEQUENCE 651 is ignored. 653 This document does not specify any controls. Controls may be 654 specified in other documents. Documents detailing control extensions 655 are to provide for each control: 657 - the OBJECT IDENTIFIER assigned to the control, 659 - direction as to what value the sender should provide for the 660 criticality field (note: the semantics of the criticality field 661 are defined above should not be altered by the control's 662 specification), 664 - whether information is to be present in the controlValue field, 665 and if so, the format of the controlValue contents, 667 - the semantics of the control, and 669 - optionally, semantics regarding the combination of the control 670 with other controls. 672 4.2. Bind Operation 674 The function of the Bind Operation is to allow authentication 675 information to be exchanged between the client and server. The Bind 676 operation should be thought of as the "authenticate" operation. 677 Authentication and security-related semantics of this operation are 678 given in [AuthMeth]. 680 The Bind Request is defined as follows: 682 BindRequest ::= [APPLICATION 0] SEQUENCE { 683 version INTEGER (1 .. 127), 684 name LDAPDN, 685 authentication AuthenticationChoice } 687 AuthenticationChoice ::= CHOICE { 688 simple [0] OCTET STRING, 689 -- 1 and 2 reserved 690 sasl [3] SaslCredentials, 691 ... } 693 SaslCredentials ::= SEQUENCE { 694 mechanism LDAPString, 695 credentials OCTET STRING OPTIONAL } 697 Fields of the Bind Request are: 699 - version: A version number indicating the version of the protocol 700 to be used in this LDAP association. This document describes 701 version 3 of the protocol. There is no version negotiation. The 702 Lightweight Directory Access Protocol Version 3 704 client sets this field to the version it desires. If the server 705 does not support the specified version, it MUST respond with 706 protocolError in the resultCode field of the BindResponse. 708 - name: The name of the Directory object that the client wishes to 709 bind as. This field may take on a null value (a zero length 710 string) for the purposes of anonymous binds ([AuthMeth] Section 711 5.1) or when using Simple Authentication and Security Layer [SASL] 712 authentication ([AuthMeth] Section 3.3.2). Server behavior is 713 undefined when the name is a null value, simple authentication is 714 used, and a non-null password is specified. Where the server 715 attempts to locate the named object, it SHALL NOT perform alias 716 dereferencing. 718 - authentication: information used in authentication. This type is 719 extensible as defined in Section 3.7 of [LDAPIANA]. Servers that 720 do not support a choice supplied by a client return 721 authMethodNotSupported in the resultCode field of the 722 BindResponse. 724 Textual passwords (consisting of a character sequence with a known 725 character set and encoding) transferred to the server using the 726 simple AuthenticationChoice SHALL be transferred as [UTF-8] 727 encoded [Unicode]. Prior to transfer, clients SHOULD prepare text 728 passwords by applying the [SASLprep] profile of the [Stringprep] 729 algorithm. Passwords consisting of other data (such as random 730 octets) MUST NOT be altered. The determination of whether a 731 password is textual is a local client matter. 733 Authorization is the use of this authentication information when 734 performing operations. Authorization MAY be affected by factors 735 outside of the LDAP Bind Request, such as those provided by lower 736 layer security services. 738 4.2.1. Processing of the Bind Request 740 Before processing a BindRequest, all outstanding operations MUST 741 either complete or be abandoned. The server may either wait for the 742 outstanding operations to complete, or abandon them. The server then 743 proceeds to authenticate the client in either a single-step, or 744 multi-step bind process. Each step requires the server to return a 745 BindResponse to indicate the status of authentication. 747 If the client did not bind before sending a request and receives an 748 operationsError to that request, it may then send a Bind Request. If 749 this also fails or the client chooses not to bind on the existing 750 connection, it may close the connection, reopen it and begin again by 751 first sending a PDU with a Bind Request. This will aid in 752 interoperating with servers implementing other versions of LDAP. 754 Clients may send multiple Bind Requests on a connection to change the 755 authentication and/or security associations or to complete a multi- 756 Lightweight Directory Access Protocol Version 3 758 stage bind process. Authentication from earlier binds is subsequently 759 ignored. 761 For some SASL authentication mechanisms, it may be necessary for the 762 client to invoke the BindRequest multiple times. This is indicated by 763 the server sending a BindResponse with the resultCode set to 764 saslBindInProgress. This indicates that the server requires the 765 client to send a new bind request, with the same sasl mechanism, to 766 continue the authentication process. Clients MUST NOT invoke 767 operations between two Bind Requests made as part of a multi-stage 768 bind. 770 A client may abort a SASL bind negotiation by sending a BindRequest 771 with a different value in the mechanism field of SaslCredentials, or 772 an AuthenticationChoice other than sasl. 774 If the client sends a BindRequest with the sasl mechanism field as an 775 empty string, the server MUST return a BindResponse with 776 authMethodNotSupported as the resultCode. This will allow clients to 777 abort a negotiation if it wishes to try again with the same SASL 778 mechanism. 780 A failed Bind Operation has the effect of placing the connection in 781 an anonymous state. 783 4.2.2. Bind Response 785 The Bind Response is defined as follows. 787 BindResponse ::= [APPLICATION 1] SEQUENCE { 788 COMPONENTS OF LDAPResult, 789 serverSaslCreds [7] OCTET STRING OPTIONAL } 791 BindResponse consists simply of an indication from the server of the 792 status of the client's request for authentication. 794 A successful bind operation is indicated by a BindResponse with a 795 resultCode set to success. Otherwise, an appropriate result code is 796 set in the BindResponse. For bind, the protocolError result code may 797 be used to indicate that the version number supplied by the client is 798 unsupported. 800 If the client receives a BindResponse where the resultCode field is 801 protocolError, it is to assume that the server does not support this 802 version of LDAP. While the client may be able proceed with another 803 version of this protocol (this may or may not require establishing a 804 new connection), how to proceed with another version of this protocol 805 is beyond the scope of this document. Clients which are unable or 806 unwilling to proceed SHOULD drop the underlying connection. 808 The serverSaslCreds field is used as part of a SASL-defined bind 809 mechanism to allow the client to authenticate the server to which it 810 is communicating, or to perform "challenge-response" authentication. 812 Lightweight Directory Access Protocol Version 3 814 If the client bound with the simple choice, or the SASL mechanism 815 does not require the server to return information to the client, then 816 this field SHALL NOT be included in the BindResponse. 818 4.3. Unbind Operation 820 The function of the Unbind Operation is to terminate an LDAP 821 association and connection. The Unbind operation is not the 822 antithesis of the Bind operation as the name implies. The naming of 823 these operations is historical. The Unbind operation should be 824 thought of as the "quit" operation. 826 The Unbind Operation is defined as follows: 828 UnbindRequest ::= [APPLICATION 2] NULL 830 The Unbind Operation has no response defined. Upon transmission of 831 the UnbindRequest, each protocol peer is to consider the LDAP 832 association terminated, MUST cease transmission of messages to the 833 other peer, and MUST close the connection. Outstanding operations are 834 handled as specified in Section 5.2. 836 4.4. Unsolicited Notification 838 An unsolicited notification is an LDAPMessage sent from the server to 839 the client which is not in response to any LDAPMessage received by 840 the server. It is used to signal an extraordinary condition in the 841 server or in the connection between the client and the server. The 842 notification is of an advisory nature, and the server will not expect 843 any response to be returned from the client. 845 The unsolicited notification is structured as an LDAPMessage in which 846 the messageID is zero and protocolOp is of the extendedResp form (See 847 Section 4.12). The responseName field of the ExtendedResponse always 848 contains an LDAPOID which is unique for this notification. 850 One unsolicited notification (Notice of Disconnection) is defined in 851 this document. The specification of an unsolicited notification 852 consists of: 854 - the OBJECT IDENTIFIER assigned to the notification (to be 855 specified in the responseName, 857 - the format of the contents (if any) of the responseValue, 859 - the circumstances which will cause the notification to be 860 returned, and 862 - the semantics of the operation. 864 4.4.1. Notice of Disconnection 865 Lightweight Directory Access Protocol Version 3 867 This notification may be used by the server to advise the client that 868 the server is about to close the connection due to an error 869 condition. This notification is intended to assist clients in 870 distinguishing between an error condition and a transient network 871 failure. Note that this notification is not a response to an unbind 872 requested by the client. Outstanding operations are handled as 873 specified in Section 5.2. 875 The responseName is 1.3.6.1.4.1.1466.20036, the response field is 876 absent, and the resultCode is used to indicate the reason for the 877 disconnection. 879 The following result codes have these meanings when used in this 880 notification: 882 - protocolError: The server has received data from the client in 883 which the LDAPMessage structure could not be parsed. 885 - strongAuthRequired: The server has detected that an established 886 security association between the client and server has 887 unexpectedly failed or been compromised, or that the server now 888 requires the client to authenticate using a strong(er) mechanism. 890 - unavailable: This server will stop accepting new connections and 891 operations on all existing connections, and be unavailable for an 892 extended period of time. The client may make use of an alternative 893 server. 895 Upon transmission of the Notice of Disconnection, the server is to 896 consider the LDAP association terminated, MUST cease transmission of 897 messages to the client, and MUST close the connection. 899 4.5. Search Operation 901 The Search Operation is used to request a server to return, subject 902 to access controls and other restrictions, a set of entries matching 903 a complex search criterion. This can be used to read attributes from 904 a single entry, from entries immediately subordinate to a particular 905 entry, or a whole subtree of entries. 907 4.5.1. Search Request 909 The Search Request is defined as follows: 911 SearchRequest ::= [APPLICATION 3] SEQUENCE { 912 baseObject LDAPDN, 913 scope ENUMERATED { 914 baseObject (0), 915 singleLevel (1), 916 wholeSubtree (2) }, 917 derefAliases ENUMERATED { 918 Lightweight Directory Access Protocol Version 3 920 neverDerefAliases (0), 921 derefInSearching (1), 922 derefFindingBaseObj (2), 923 derefAlways (3) }, 924 sizeLimit INTEGER (0 .. maxInt), 925 timeLimit INTEGER (0 .. maxInt), 926 typesOnly BOOLEAN, 927 filter Filter, 928 attributes AttributeSelection } 930 AttributeSelection ::= SEQUENCE OF selection LDAPString 931 -- constrained to below 933 Filter ::= CHOICE { 934 and [0] SET SIZE (1..MAX) OF filter Filter, 935 or [1] SET SIZE (1..MAX) OF filter Filter, 936 not [2] Filter, 937 equalityMatch [3] AttributeValueAssertion, 938 substrings [4] SubstringFilter, 939 greaterOrEqual [5] AttributeValueAssertion, 940 lessOrEqual [6] AttributeValueAssertion, 941 present [7] AttributeDescription, 942 approxMatch [8] AttributeValueAssertion, 943 extensibleMatch [9] MatchingRuleAssertion } 945 SubstringFilter ::= SEQUENCE { 946 type AttributeDescription, 947 -- initial and final can occur at most once 948 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 949 initial [0] AssertionValue, 950 any [1] AssertionValue, 951 final [2] AssertionValue } } 953 MatchingRuleAssertion ::= SEQUENCE { 954 matchingRule [1] MatchingRuleId OPTIONAL, 955 type [2] AttributeDescription OPTIONAL, 956 matchValue [3] AssertionValue, 957 dnAttributes [4] BOOLEAN DEFAULT FALSE } 959 Fields of the Search Request are: 961 - baseObject: The name of the base object entry relative to which 962 the search is to be performed. 964 - scope: Specifies the scope of the search to be performed. The 965 semantics (as described in [X.511]) of the possible values of this 966 field are: 968 baseObject: The scope is constrained to the entry named by 969 baseObject. 971 singleLevel: The scope is constrained to the immediate 972 subordinates of the entry named by baseObject. 974 Lightweight Directory Access Protocol Version 3 976 wholeSubtree: the scope is constrained to the entry named by 977 the baseObject, and all its subordinates. 979 - derefAliases: An indicator as to how alias entries (as defined in 980 [Models]) are to be handled in searching. The semantics of the 981 possible values of this field are: 983 neverDerefAliases: Do not dereference aliases in searching or 984 in locating the base object of the search. 986 derefInSearching: While searching, dereference any alias entry 987 subordinate to the base object which is also in the search 988 scope. The filter is applied to the dereferenced object(s). If 989 the search scope is wholeSubtree, the search continues in the 990 subtree of any dereferenced object. Aliases in that subtree are 991 also dereferenced. Servers SHOULD eliminate duplicate entries 992 that arise due to alias dereferencing while searching. 994 derefFindingBaseObj: Dereference aliases in locating the base 995 object of the search, but not when searching subordinates of 996 the base object. 998 derefAlways: Dereference aliases both in searching and in 999 locating the base object of the search. 1000 Servers MUST detect looping while dereferencing aliases in order 1001 to prevent denial of service attacks of this nature. 1003 - sizeLimit: A size limit that restricts the maximum number of 1004 entries to be returned as a result of the search. A value of zero 1005 in this field indicates that no client-requested size limit 1006 restrictions are in effect for the search. Servers may also 1007 enforce a maximum number of entries to return. 1009 - timeLimit: A time limit that restricts the maximum time (in 1010 seconds) allowed for a search. A value of zero in this field 1011 indicates that no client-requested time limit restrictions are in 1012 effect for the search. Servers may also enforce a maximum time 1013 limit for the search. 1015 - typesOnly: An indicator as to whether search results are to 1016 contain both attribute descriptions and values, or just attribute 1017 descriptions. Setting this field to TRUE causes only attribute 1018 descriptions (no values) to be returned. Setting this field to 1019 FALSE causes both attribute descriptions and values to be 1020 returned. 1022 - filter: A filter that defines the conditions that must be 1023 fulfilled in order for the search to match a given entry. 1025 The 'and', 'or' and 'not' choices can be used to form combinations 1026 of filters. At least one filter element MUST be present in an 1027 'and' or 'or' choice. The others match against individual 1028 attribute values of entries in the scope of the search. 1030 Lightweight Directory Access Protocol Version 3 1032 (Implementor's note: the 'not' filter is an example of a tagged 1033 choice in an implicitly-tagged module. In BER this is treated as 1034 if the tag was explicit.) 1036 A server MUST evaluate filters according to the three-valued logic 1037 of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated 1038 to either "TRUE", "FALSE" or "Undefined". If the filter evaluates 1039 to TRUE for a particular entry, then the attributes of that entry 1040 are returned as part of the search result (subject to any 1041 applicable access control restrictions). If the filter evaluates 1042 to FALSE or Undefined, then the entry is ignored for the search. 1044 A filter of the "and" choice is TRUE if all the filters in the SET 1045 OF evaluate to TRUE, FALSE if at least one filter is FALSE, and 1046 otherwise Undefined. A filter of the "or" choice is FALSE if all 1047 of the filters in the SET OF evaluate to FALSE, TRUE if at least 1048 one filter is TRUE, and Undefined otherwise. A filter of the 'not' 1049 choice is TRUE if the filter being negated is FALSE, FALSE if it 1050 is TRUE, and Undefined if it is Undefined. 1052 The present match evaluates to TRUE where there is an attribute or 1053 subtype of the specified attribute description present in an 1054 entry, and FALSE otherwise (including a presence test with an 1055 unrecognized attribute description.) 1057 The matching rule for equalityMatch filter items is defined by the 1058 EQUALITY matching rule for the attribute type. 1060 There SHALL be at most one 'initial', and at most one 'final' in 1061 the 'substrings' of a SubstringFilter. If 'initial' is present, it 1062 SHALL be the first element of 'substrings'. If 'final' is present, 1063 it SHALL be the last element of 'substrings'. 1064 The matching rule for AssertionValues in a substrings filter item 1065 is defined by the SUBSTR matching rule for the attribute type. 1066 Note that the AssertionValue in a substrings filter item conforms 1067 to the assertion syntax of the EQUALITY matching rule for the 1068 attribute type rather than the assertion syntax of the SUBSTR 1069 matching rule for the attribute type. Conceptually, the entire 1070 SubstringFilter is converted into an assertion value of the 1071 substrings matching rule prior to applying the rule. 1073 The matching rule for the greaterOrEqual filter item is defined by 1074 the ORDERING and EQUALITY matching rules for the attribute type. 1076 The matching rule for the lessOrEqual filter item is defined by 1077 the ORDERING matching rule for the attribute type. 1079 An approxMatch filter item evaluates to TRUE when there is a value 1080 of the attribute or subtype for which some locally-defined 1081 approximate matching algorithm (e.g. spelling variations, phonetic 1082 match, etc.) returns TRUE. If an item matches for equality, it 1083 also satisfies an approximate match. If approximate matching is 1084 not supported, this filter item should be treated as an 1085 equalityMatch. 1087 Lightweight Directory Access Protocol Version 3 1089 An extensibleMatch filter item is evaluated as follows: 1091 If the matchingRule field is absent, the type field MUST be 1092 present, and an equality match is performed for that type. 1094 If the type field is absent and the matchingRule is present, the 1095 matchValue is compared against all attributes in an entry which 1096 support that matchingRule. The matchingRule determines the 1097 syntax for the assertion value. The filter item evaluates to 1098 TRUE if it matches with at least one attribute in the entry, 1099 FALSE if it does not match any attribute in the entry, and 1100 Undefined if the matchingRule is not recognized or the 1101 assertionValue is invalid. 1103 If the type field is present and the matchingRule is present, 1104 the matchValue is compared against entry attributes of the 1105 specified type. In this case, the matchingRule MUST be one 1106 suitable for use with the specified type (see [Syntaxes]), 1107 otherwise the filter item is Undefined. 1109 If the dnAttributes field is set to TRUE, the match is 1110 additionally applied against all the AttributeValueAssertions in 1111 an entry's distinguished name, and evaluates to TRUE if there is 1112 at least one attribute in the distinguished name for which the 1113 filter item evaluates to TRUE. The dnAttributes field is present 1114 to alleviate the need for multiple versions of generic matching 1115 rules (such as word matching), where one applies to entries and 1116 another applies to entries and dn attributes as well. 1118 A filter item evaluates to Undefined when the server would not be 1119 able to determine whether the assertion value matches an entry. If 1120 an attribute description in an equalityMatch, substrings, 1121 greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter 1122 is not recognized by the server, a matching rule id in the 1123 extensibleMatch is not recognized by the server, the assertion 1124 value is invalid, or the type of filtering requested is not 1125 implemented, then the filter is Undefined. Thus for example if a 1126 server did not recognize the attribute type shoeSize, a filter of 1127 (shoeSize=*) would evaluate to FALSE, and the filters 1128 (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to 1129 Undefined. 1131 Servers MUST NOT return errors if attribute descriptions or 1132 matching rule ids are not recognized, assertion values are 1133 invalid, or the assertion syntax is not supported. More details of 1134 filter processing are given in Section 7.8 of [X.511]. 1136 - attributes: A list of the attributes to be returned from each 1137 entry which matches the search filter. LDAPString values of this 1138 field are constrained to the following Augmented Backus-Naur Form 1139 ([ABNF]): 1141 attributeSelection = attributedescription / selectionspecial 1142 Lightweight Directory Access Protocol Version 3 1144 selectionspecial = noattrs / alluserattrs 1146 noattrs = %x31.2E.31 ; "1.1" 1148 alluserattrs = %x2A ; asterisk ("*") 1150 The production is defined in Section 2.5 of 1151 [Models]. 1153 There are three special cases which may exist in the attribute 1154 selection: 1155 - an empty list with no attributes, 1156 - a list containing "*" (with zero or more attribute 1157 descriptions), and 1158 - a list containing only "1.1". 1160 An empty list requests the return of all user attributes. 1162 A list containing "*" requests all user attributes in addition to 1163 other listed (operational) attributes. 1165 A list containing only the OID "1.1" indicates that no values are 1166 to be returned. If "1.1" is provided with other values, the "1.1" 1167 value is ignored. This OID was chosen because it does not (and can 1168 not) correspond to any attribute in use. 1170 Client implementors should note that even if all user attributes 1171 are requested, some attributes and/or attribute values of the 1172 entry may not be included in search results due to access controls 1173 or other restrictions. Furthermore, servers will not return 1174 operational attributes, such as objectClasses or attributeTypes, 1175 unless they are listed by name. Operational attributes are 1176 described in [Models]. 1178 Attributes are returned at most once in an entry. If an attribute 1179 description is named more than once in the list, the subsequent 1180 names are ignored. If an attribute description in the list is not 1181 recognized, it is ignored by the server. 1183 Note that an X.500 "list"-like operation can be emulated by the 1184 client requesting a one-level LDAP search operation with a filter 1185 checking for the presence of the 'objectClass' attribute, and that an 1186 X.500 "read"-like operation can be emulated by a base object LDAP 1187 search operation with the same filter. A server which provides a 1188 gateway to X.500 is not required to use the Read or List operations, 1189 although it may choose to do so, and if it does, it must provide the 1190 same semantics as the X.500 search operation. 1192 4.5.2. Search Result 1193 Lightweight Directory Access Protocol Version 3 1195 The results of the search operation are returned as zero or more 1196 searchResultEntry messages, zero or more SearchResultReference 1197 messages, followed by a single searchResultDone message. 1199 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 1200 objectName LDAPDN, 1201 attributes PartialAttributeList } 1203 PartialAttributeList ::= SEQUENCE OF 1204 partialAttribute PartialAttribute 1205 -- Note that the PartialAttributeList may hold zero elements. 1206 -- This may happen when none of the attributes of an entry 1207 -- were requested, or could be returned. 1208 -- Note also that the partialAttribute vals set may hold zero 1209 -- elements. This may happen when typesOnly is requested, access 1210 -- controls prevent the return of values, or other reasons. 1212 SearchResultReference ::= [APPLICATION 19] SEQUENCE 1213 SIZE (1..MAX) OF uri URI 1215 SearchResultDone ::= [APPLICATION 5] LDAPResult 1217 Each SearchResultEntry represents an entry found during the search. 1218 Each SearchResultReference represents an area not yet explored during 1219 the search. The SearchResultEntry and SearchResultReference PDUs may 1220 come in any order. Following all the SearchResultReference and 1221 SearchResultEntry responses, the server returns a SearchResultDone 1222 response, which contains an indication of success, or detailing any 1223 errors that have occurred. 1225 Each entry returned in a SearchResultEntry will contain all 1226 appropriate attributes as specified in the attributes field of the 1227 Search Request. Return of attributes is subject to access control and 1228 other administrative policy. 1230 Some attributes may be constructed by the server and appear in a 1231 SearchResultEntry attribute list, although they are not stored 1232 attributes of an entry. Clients SHOULD NOT assume that all attributes 1233 can be modified, even if permitted by access control. 1235 If the server's schema defines short names [Models] for an attribute 1236 type then the server SHOULD use one of those names in attribute 1237 descriptions for that attribute type (in preference to using the 1238 [Models] format of the attribute type's object 1239 identifier). The server SHOULD NOT use the short name if that name is 1240 known by the server to be ambiguous, or otherwise likely to cause 1241 interoperability problems. 1243 4.5.3. Continuation References in the Search Result 1245 If the server was able to locate the entry referred to by the 1246 baseObject but was unable to search one or more non-local entries, 1247 the server may return one or more SearchResultReference entries, each 1248 Lightweight Directory Access Protocol Version 3 1250 containing a reference to another set of servers for continuing the 1251 operation. A server MUST NOT return any SearchResultReference if it 1252 has not located the baseObject and thus has not searched any entries; 1253 in this case it would return a SearchResultDone containing a referral 1254 result code. 1256 If a server holds a copy or partial copy of the subordinate naming 1257 context [Section 5 of Models], it may use the search filter to 1258 determine whether or not to return a SearchResultReference response. 1259 Otherwise SearchResultReference responses are always returned when in 1260 scope. 1262 The SearchResultReference is of the same data type as the Referral. 1264 A URI for a server implementing LDAP and accessible via [TCP]/[IP] 1265 (v4 or v6) is written as an LDAP URL according to [LDAPURL]. 1267 In order to complete the search, the client issues a new search 1268 operation for each SearchResultReference that is returned. Note that 1269 the abandon operation described in Section 4.11 applies only to a 1270 particular operation sent on an association between a client and 1271 server. The client must abandon subsequent search operations it 1272 wishes to individually. 1274 Clients that follow search continuation references MUST ensure that 1275 they do not loop between servers. They MUST NOT repeatedly contact 1276 the same server for the same request with the same target entry name, 1277 scope and filter. Some clients use a counter that is incremented each 1278 time search result reference handling occurs for an operation, and 1279 these kinds of clients MUST be able to handle at least ten nested 1280 search result references between the root and a leaf entry. 1282 When an LDAP URL is used, the following instructions are followed: 1284 - The part of the URL MUST be present, with the new target 1285 object name. The client MUST use this name when following the 1286 reference. UTF-8 encoded characters appearing in the string 1287 representation of a DN or search filter may not be legal for URLs 1288 (e.g. spaces) and MUST be escaped using the % method in [URI]. 1289 - Some servers (e.g. participating in distributed indexing) may 1290 provide a different filter in a URL of a SearchResultReference. 1291 - If the part of the URL is present, the client MUST use 1292 this filter in its next request to progress this search, and if it 1293 is not present the client MUST use the same filter as it used for 1294 that search. 1295 - If the originating search scope was singleLevel, the part 1296 of the URL will be "base". 1297 - it is RECOMMENDED that the part be present to avoid 1298 ambiguity. 1299 - Other aspects of the new search request may be the same as or 1300 different from the search request which generated the 1301 SearchResultReference. 1302 - The name of an unexplored subtree in a SearchResultReference need 1303 not be subordinate to the base object. 1305 Lightweight Directory Access Protocol Version 3 1307 Other kinds of URIs may be returned. The syntax and semantics of such 1308 URIs is left to future specifications. Clients may ignore URIs that 1309 they do not support. 1311 4.5.3.1. Examples 1313 For example, suppose the contacted server (hosta) holds the entry 1314 and the entry . It 1315 knows that either LDAP-capable servers (hostb) or (hostc) hold 1316 (one is the master and the other server 1317 a shadow), and that LDAP-capable server (hostd) holds the subtree 1318 . If a wholeSubtree search of 1319 is requested to the contacted server, it may 1320 return the following: 1322 SearchResultEntry for DC=Example,DC=NET 1323 SearchResultEntry for CN=Manager,DC=Example,DC=NET 1324 SearchResultReference { 1325 ldap://hostb/OU=People,DC=Example,DC=NET??sub 1326 ldap://hostc/OU=People,DC=Example,DC=NET??sub } 1327 SearchResultReference { 1328 ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } 1329 SearchResultDone (success) 1331 Client implementors should note that when following a 1332 SearchResultReference, additional SearchResultReference may be 1333 generated. Continuing the example, if the client contacted the server 1334 (hostb) and issued the search for the subtree 1335 , the server might respond as follows: 1337 SearchResultEntry for OU=People,DC=Example,DC=NET 1338 SearchResultReference { 1339 ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } 1340 SearchResultReference { 1341 ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } 1342 SearchResultDone (success) 1344 Similarly, if a singleLevel search of is 1345 requested to the contacted server, it may return the following: 1347 SearchResultEntry for CN=Manager,DC=Example,DC=NET 1348 SearchResultReference { 1349 ldap://hostb/OU=People,DC=Example,DC=NET??base 1350 ldap://hostc/OU=People,DC=Example,DC=NET??base } 1351 SearchResultReference { 1352 ldap://hostd/OU=Roles,DC=Example,DC=NET??base } 1353 SearchResultDone (success) 1355 If the contacted server does not hold the base object for the search, 1356 then it will return a referral to the client. For example, if the 1357 client requests a subtree search of to hosta, the 1358 server may return only a SearchResultDone containing a referral. 1360 Lightweight Directory Access Protocol Version 3 1362 SearchResultDone (referral) { 1363 ldap://hostg/DC=Example,DC=ORG??sub } 1365 4.6. Modify Operation 1367 The Modify Operation allows a client to request that a modification 1368 of an entry be performed on its behalf by a server. The Modify 1369 Request is defined as follows: 1371 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1372 object LDAPDN, 1373 changes SEQUENCE OF change SEQUENCE { 1374 operation ENUMERATED { 1375 add (0), 1376 delete (1), 1377 replace (2) }, 1378 modification PartialAttribute } } 1380 Fields of the Modify Request are: 1382 - object: The name of the object to be modified. The value of this 1383 field contains the DN of the entry to be modified. The server 1384 SHALL NOT perform any alias dereferencing in determining the 1385 object to be modified. 1387 - changes: A list of modifications to be performed on the entry. The 1388 entire list of modifications MUST be performed in the order they 1389 are listed as a single atomic operation. While individual 1390 modifications may violate certain aspects of the directory schema 1391 (such as the object class definition and DIT content rule), the 1392 resulting entry after the entire list of modifications is 1393 performed MUST conform to the requirements of the directory schema 1394 [Models]. 1396 - operation: Used to specify the type of modification being 1397 performed. Each operation type acts on the following 1398 modification. The values of this field have the following 1399 semantics respectively: 1401 add: add values listed to the modification attribute, 1402 creating the attribute if necessary; 1404 delete: delete values listed from the modification attribute, 1405 removing the entire attribute if no values are listed, or if 1406 all current values of the attribute are listed for deletion; 1408 replace: replace all existing values of the modification 1409 attribute with the new values listed, creating the attribute 1410 if it did not already exist. A replace with no value will 1411 delete the entire attribute if it exists, and is ignored if 1412 the attribute does not exist. 1414 Lightweight Directory Access Protocol Version 3 1416 - modification: A PartialAttribute (which may have an empty SET 1417 of vals) used to hold the attribute type or attribute type and 1418 values being modified. 1420 Upon receipt of a Modify Request, the server attempts to perform the 1421 necessary modifications to the DIT and returns the result in a Modify 1422 Response, defined as follows: 1424 ModifyResponse ::= [APPLICATION 7] LDAPResult 1426 The server will return to the client a single Modify Response 1427 indicating either the successful completion of the DIT modification, 1428 or the reason that the modification failed. Due to the requirement 1429 for atomicity in applying the list of modifications in the Modify 1430 Request, the client may expect that no modifications of the DIT have 1431 been performed if the Modify Response received indicates any sort of 1432 error, and that all requested modifications have been performed if 1433 the Modify Response indicates successful completion of the Modify 1434 Operation. If the association changes or the connection fails, 1435 whether the modification occurred or not is indeterminate. 1437 The Modify Operation cannot be used to remove from an entry any of 1438 its distinguished values, i.e. those values which form the entry's 1439 relative distinguished name. An attempt to do so will result in the 1440 server returning the notAllowedOnRDN result code. The Modify DN 1441 Operation described in Section 4.9 is used to rename an entry. 1443 Note that due to the simplifications made in LDAP, there is not a 1444 direct mapping of the changes in an LDAP ModifyRequest onto the 1445 changes of a DAP ModifyEntry operation, and different implementations 1446 of LDAP-DAP gateways may use different means of representing the 1447 change. If successful, the final effect of the operations on the 1448 entry MUST be identical. 1450 4.7. Add Operation 1452 The Add Operation allows a client to request the addition of an entry 1453 into the Directory. The Add Request is defined as follows: 1455 AddRequest ::= [APPLICATION 8] SEQUENCE { 1456 entry LDAPDN, 1457 attributes AttributeList } 1459 AttributeList ::= SEQUENCE OF attribute Attribute 1461 Fields of the Add Request are: 1463 - entry: the name of the entry to be added. The server SHALL NOT 1464 dereference any aliases in locating the entry to be added. 1466 - attributes: the list of attributes that, along with those from the 1467 RDN, make up the content of the entry being added. Clients MUST 1468 include the 'objectClass' attribute, and values of any mandatory 1469 Lightweight Directory Access Protocol Version 3 1471 attributes of the listed object classes. Clients MUST NOT supply 1472 NO-USER-MODIFICATION attributes such as the createTimestamp or 1473 creatorsName attributes, since the server maintains these 1474 automatically. 1476 The entry named in the entry field of the AddRequest MUST NOT exist 1477 for the AddRequest to succeed. The immediate superior (parent) of an 1478 object or alias entry to be added MUST exist. For example, if the 1479 client attempted to add , the 1480 entry did not exist, and the entry did 1481 exist, then the server would return the noSuchObject result code with 1482 the matchedDN field containing . 1484 If the entry to be added would not fall within a naming context 1485 [Section 5 of Models] held by the server, and the server has 1486 knowledge of where that entry is to be located, a referral to the 1487 server(s) holding the parent entry should be returned. 1489 Server implementations SHOULD NOT restrict where entries can be 1490 located in the Directory unless DIT structure rules are in place. 1491 Some servers allow the administrator to restrict the classes of 1492 entries which can be added to the Directory. 1494 Upon receipt of an Add Request, a server will attempt to add the 1495 requested entry. The result of the add attempt will be returned to 1496 the client in the Add Response, defined as follows: 1498 AddResponse ::= [APPLICATION 9] LDAPResult 1500 A response of success indicates that the new entry has been added to 1501 the Directory. 1503 4.8. Delete Operation 1505 The Delete Operation allows a client to request the removal of an 1506 entry from the Directory. The Delete Request is defined as follows: 1508 DelRequest ::= [APPLICATION 10] LDAPDN 1510 The Delete Request consists of the name of the entry to be deleted. 1511 The server SHALL NOT dereference aliases while resolving the name of 1512 the target entry to be removed. 1514 Only leaf entries (those with no subordinate entries) can be deleted 1515 with this operation. 1517 Upon receipt of a Delete Request, a server will attempt to perform 1518 the entry removal requested and return the result in the Delete 1519 Response defined as follows: 1521 DelResponse ::= [APPLICATION 11] LDAPResult 1522 Lightweight Directory Access Protocol Version 3 1524 4.9. Modify DN Operation 1526 The Modify DN Operation allows a client to change the Relative 1527 Distinguished Name (RDN) of an entry in the Directory, and/or to move 1528 a subtree of entries to a new location in the Directory. The Modify 1529 DN Request is defined as follows: 1531 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1532 entry LDAPDN, 1533 newrdn RelativeLDAPDN, 1534 deleteoldrdn BOOLEAN, 1535 newSuperior [0] LDAPDN OPTIONAL } 1537 Fields of the Modify DN Request are: 1539 - entry: the name of the entry to be changed. This entry may or may 1540 not have subordinate entries. 1542 - newrdn: the new RDN of the entry. If an attribute value in the 1543 newrdn does not already exist in the entry (either as part of the 1544 old RDN or as a non-distinguished value), it is added. If it 1545 cannot be added, an appropriate error is returned. 1547 - deleteoldrdn: a boolean field that controls whether the old RDN 1548 attribute values are to be retained as attributes of the entry, or 1549 deleted from the entry. 1551 - newSuperior: if present, this is the name of an existing object 1552 entry which becomes the immediate superior (parent) of the 1553 existing entry. 1555 The server SHALL NOT dereference any aliases in locating the objects 1556 named in entry or newSuperior. 1558 Upon receipt of a ModifyDNRequest, a server will attempt to perform 1559 the name change and return the result in the Modify DN Response, 1560 defined as follows: 1562 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 1564 For example, if the entry named in the entry field was , the newrdn field was , and the 1566 newSuperior field was absent, then this operation would attempt to 1567 rename the entry to be . If there was 1568 already an entry with that name, the operation would fail with the 1569 entryAlreadyExists result code. 1571 The object named in newSuperior MUST exist. For example, if the 1572 client attempted to add , the 1573 entry did not exist, and the entry did 1574 exist, then the server would return the noSuchObject result code with 1575 the matchedDN field containing . 1577 Lightweight Directory Access Protocol Version 3 1579 If the deleteoldrdn field is TRUE, the attribute values forming the 1580 old RDN but not the new RDN are deleted from the entry. If the 1581 deleteoldrdn field is FALSE, the attribute values forming the old RDN 1582 will be retained as non-distinguished attribute values of the entry. 1583 The server MUST fail the operation and return an error in the result 1584 code if the setting of the deleteoldrdn field would cause a schema 1585 inconsistency in the entry. 1587 Note that X.500 restricts the ModifyDN operation to only affect 1588 entries that are contained within a single server. If the LDAP server 1589 is mapped onto DAP, then this restriction will apply, and the 1590 affectsMultipleDSAs result code will be returned if this error 1591 occurred. In general, clients MUST NOT expect to be able to perform 1592 arbitrary movements of entries and subtrees between servers or 1593 between naming contexts. 1595 4.10. Compare Operation 1597 The Compare Operation allows a client to compare an assertion value 1598 with the values of a particular attribute in a particular entry in 1599 the Directory. The Compare Request is defined as follows: 1601 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1602 entry LDAPDN, 1603 ava AttributeValueAssertion } 1605 Fields of the Compare Request are: 1607 - entry: the name of the entry to be compared. The server SHALL NOT 1608 dereference any aliases in locating the entry to be compared. 1610 - ava: holds the attribute description and assertion value with 1611 which an attribute in the entry is to be compared. 1613 Upon receipt of a Compare Request, a server will attempt to perform 1614 the requested comparison and return the result in the Compare 1615 Response, defined as follows: 1617 CompareResponse ::= [APPLICATION 15] LDAPResult 1619 The resultCode field is set to compareTrue, compareFalse, or an 1620 appropriate error. compareTrue indicates that the assertion value in 1621 the ava field is equivalent to a value of the attribute or subtype 1622 (according to the attribute's EQUALITY matching rule). compareFalse 1623 indicates that the comparison of the assertion value in the ava field 1624 and the values of the attribute or subtype resulted in an Undefined 1625 (Section 4.5.1) or non-equivalent match. 1627 In the event that the attribute or subtype is not present in the 1628 entry, the resultCode field is set to noSuchAttribute. If the 1629 attribute is unknown, the resultCode is set to 1630 undefinedAttributeType. If the attribute or subtype has no equality 1631 matching rule, innapropriateMatching is returned in the resultCode. 1633 Lightweight Directory Access Protocol Version 3 1635 Note that some directory systems may establish access controls which 1636 permit the values of certain attributes (such as userPassword) to be 1637 compared but not interrogated by other means. 1639 4.11. Abandon Operation 1641 The function of the Abandon Operation is to allow a client to request 1642 that the server abandon an outstanding operation. The Abandon Request 1643 is defined as follows: 1645 AbandonRequest ::= [APPLICATION 16] MessageID 1647 The MessageID is that of an operation which was requested earlier in 1648 this LDAP association. The abandon request itself has its own message 1649 id. This is distinct from the id of the earlier operation being 1650 abandoned. 1652 There is no response defined in the Abandon operation. Upon receipt 1653 of an AbandonRequest, the server MAY abandon the operation identified 1654 by the MessageID. Operation responses are not sent for successfully 1655 abandoned operations, thus the application of the Abandon operation 1656 is limited to uses where the client does not require an indication of 1657 its outcome. 1659 Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. 1660 The ability to abandon other (particularly update) operations is at 1661 the discretion of the server. 1663 In the event that a server receives an Abandon Request on a Search 1664 Operation in the midst of transmitting responses to the search, that 1665 server MUST cease transmitting entry responses to the abandoned 1666 request immediately, and MUST NOT send the SearchResponseDone. Of 1667 course, the server MUST ensure that only properly encoded LDAPMessage 1668 PDUs are transmitted. 1670 Clients should not send abandon requests for the same operation 1671 multiple times, and MUST also be prepared to receive results from 1672 operations it has abandoned (since these may have been in transit 1673 when the abandon was requested, or are not able to be abandoned). 1675 Servers MUST discard abandon requests for message IDs they do not 1676 recognize, for operations which cannot be abandoned, and for 1677 operations which have already been abandoned. 1679 4.12. Extended Operation 1681 The extended operation allows additional operations to be defined for 1682 services not already available in the protocol. For example, to add 1683 operations to install transport layer security (see Section 4.14). 1685 Lightweight Directory Access Protocol Version 3 1687 The extended operation allows clients to make requests and receive 1688 responses with predefined syntaxes and semantics. These may be 1689 defined in RFCs or be private to particular implementations. 1691 Each extended operation consists of an extended request and an 1692 extended response. 1694 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1695 requestName [0] LDAPOID, 1696 requestValue [1] OCTET STRING OPTIONAL } 1698 The requestName is a dotted-decimal representation of the unique 1699 OBJECT IDENTIFIER corresponding to the request. The requestValue is 1700 information in a form defined by that request, encapsulated inside an 1701 OCTET STRING. 1703 The server will respond to this with an LDAPMessage containing an 1704 ExtendedResponse. 1706 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 1707 COMPONENTS OF LDAPResult, 1708 responseName [10] LDAPOID OPTIONAL, 1709 responseValue [11] OCTET STRING OPTIONAL } 1711 The responseName is typically not required to be present as the 1712 syntax and semantics of the response (including the format of the 1713 responseValue) is implicitly known and associated with the request by 1714 the messageID. 1716 If the requestName is not recognized by the server, the server MUST 1717 NOT provide a responseName nor a responseValue and MUST return a 1718 resultCode of protocolError. 1720 The requestValue and responseValue fields contain any information 1721 associated with the operation. The format of these fields is defined 1722 by the specification of the extended operation. Implementations MUST 1723 be prepared to handle arbitrary contents of these fields, including 1724 zero bytes. Values that are defined in terms of ASN.1 and BER encoded 1725 according to Section 5.1, also follow the extensibility rules in 1726 Section 4. 1728 It is RECOMMENDED that servers list the requestName of extended 1729 operations they support in the 'supportedExtension' attribute of the 1730 root DSE [Models]. 1732 Extended operations may be specified in other documents. The 1733 specification of an extended operation consists of: 1735 - the OBJECT IDENTIFIER assigned to the requestName (and possibly 1736 responseName), 1738 - the format of the contents of the requestValue and responseValue 1739 (if any), and 1740 Lightweight Directory Access Protocol Version 3 1742 - the semantics of the operation. 1744 4.13. IntermediateResponse Message 1746 While the Search operation provides a mechanism to return multiple 1747 response messages for a single search request, other operations, by 1748 nature, do not provide for multiple response messages. 1750 The IntermediateResponse message provides a general mechanism for 1751 defining single-request/multiple-response operations in LDAP. This 1752 message is intended to be used in conjunction with the extended 1753 operation to define new single-request/multiple-response operations 1754 or in conjunction with a control when extending existing LDAP 1755 operations in a way that requires them to return intermediate 1756 response information. 1758 It is intended that the definitions and descriptions of extended 1759 operations and controls that make use of the IntermediateResponse 1760 message will define the circumstances when an IntermediateResponse 1761 message can be sent by a server and the associated meaning of an 1762 IntermediateResponse message sent in a particular circumstance. 1763 Similarly, it is intended that clients will explicitly solicit 1764 IntermediateResponse messages by issuing operations that specifically 1765 call for their return. 1767 IntermediateResponse ::= [APPLICATION 25] SEQUENCE { 1768 responseName [0] LDAPOID OPTIONAL, 1769 responseValue [1] OCTET STRING OPTIONAL } 1771 IntermediateResponse messages SHALL NOT be returned to the client 1772 unless the client issues a request that specifically solicits their 1773 return. This document defines two forms of solicitation: extended 1774 operation and request control. 1776 Although the responseName and responseValue are optional in some 1777 circumstances, generally speaking IntermediateResponse messages have 1778 a predefined responseName and a responseValue. The value of the 1779 responseName (if present), the syntax of the responseValue (if 1780 present) and the semantics associated with a particular 1781 IntermediateResponse message MUST be specified in documents 1782 describing the extended operation or request control that uses them. 1783 Sections 4.13.1 and 4.13.2 describe additional requirements on the 1784 inclusion of responseName and responseValue in IntermediateResponse 1785 messages. 1787 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse 1789 A single-request/multiple-response operation may be defined using a 1790 single ExtendedRequest message to solicit zero or more 1791 IntermediateResponse messages of one or more kinds followed by an 1792 ExtendedResponse message. 1794 Lightweight Directory Access Protocol Version 3 1796 An extended operation that defines the return of multiple kinds of 1797 IntermediateResponse messages MUST provide and document a mechanism 1798 for the client to distinguish the kind of IntermediateResponse 1799 message being sent. This SHALL be accomplished by using different 1800 responseName values for each type of IntermediateResponse message 1801 associated with the extended operation or by including identifying 1802 information in the responseValue of each type of IntermediateResponse 1803 message associated with the extended operation. 1805 4.13.2. Usage with LDAP Request Controls 1807 Any LDAP operation may be extended by the addition of one or more 1808 controls ([RFC2251] Section 4.1.12). A control's semantics may 1809 include the return of zero or more IntermediateResponse messages 1810 prior to returning the final result code for the operation. One or 1811 more kinds of IntermediateResponse messages may be sent in response 1812 to a request control. 1814 All IntermediateResponse messages associated with request controls 1815 SHALL include a responseName. This requirement ensures that the 1816 client can correctly identify the source of IntermediateResponse 1817 messages when: 1819 - two or more controls using IntermediateResponse messages are 1820 included in a request for any LDAP operation or 1822 - one or more controls using IntermediateResponse messages are 1823 included in a request with an LDAP extended operation that uses 1824 IntermediateResponse messages. 1826 A request control that defines the return of multiple kinds of 1827 IntermediateResponse messages MUST provide and document a mechanism 1828 for the client to distinguish the kind of IntermediateResponse 1829 message being sent. This SHALL be accomplished by using different 1830 responseName values for each type of IntermediateResponse message 1831 associated with the request control or by including identifying 1832 information in the responseValue of each type of IntermediateResponse 1833 message associated with the request control. 1835 4.14. StartTLS Operation 1837 The Start Transport Layer Security (StartTLS) operation provides the 1838 ability to establish Transport Layer Security ([TLS]) on an LDAP 1839 connection. The StartTLS operation is defined using the extended 1840 operation mechanism described in Section 4.12. 1842 4.14.1. StartTLS Request 1844 A client requests TLS establishment by transmitting a StartTLS 1845 request PDU to the server. The StartTLS request is defined in terms 1846 Lightweight Directory Access Protocol Version 3 1848 of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", 1849 and the requestValue field is always absent. 1851 The client MUST NOT send any PDUs on this connection following this 1852 request until it receives a StartTLS extended response and completes 1853 TLS negotiations. 1855 4.14.2. StartTLS Response 1857 When a StartTLS request is made, servers supporting the operation 1858 MUST return a StartTLS response PDU to the requestor. The 1859 responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue 1860 field is absent. 1862 The server provides a resultCode field to either success or one of 1863 the other values outlined in Section 4.14.2.2. 1865 4.14.2.1. "Success" Response 1867 If the StartTLS Response contains a resultCode of success, this 1868 indicates that the server is willing and able to negotiate TLS. Refer 1869 to Section 4 of [AuthMeth] for details. 1871 4.14.2.2. Response other than "success" 1873 If the ExtendedResponse contains a result code other than success, 1874 this indicates that the server is unwilling or unable to negotiate 1875 TLS. The following result codes have these meanings for this 1876 operation: 1878 - operationsError: operations sequencing incorrect; e.g. TLS is 1879 already established. 1881 - protocolError: TLS is not supported or incorrect PDU structure. 1883 - unavailable: Some major problem with TLS, or the server is 1884 shutting down. 1886 The server MUST return operationsError if the client violates any of 1887 the StartTLS extended operation sequencing requirements described in 1888 Section 4 of [AuthMeth]. 1890 If the server does not support TLS (whether by design or by current 1891 configuration), it MUST return the protocolError resultCode. The 1892 client's current association is unaffected if the server does not 1893 support TLS. The client may proceed with any LDAP operation, or it 1894 may close the connection. 1896 The server MUST return unavailable if it supports TLS but cannot 1897 establish a TLS connection for some reason, e.g. the certificate 1898 Lightweight Directory Access Protocol Version 3 1900 server not responding, it cannot contact its TLS implementation, or 1901 if the server is in process of shutting down. The client may retry 1902 the StartTLS operation, or it may proceed with any other LDAP 1903 operation, or it may close the LDAP connection. 1905 4.14.3. Closing a TLS Connection 1907 Two forms of TLS connection closure -- graceful and abrupt -- are 1908 supported. These do not involve LDAP PDUs, but are preformed at the 1909 underlying layers. 1911 4.14.3.1. Graceful Closure 1913 Either the client or server MAY terminate the TLS connection and 1914 leave the LDAP connection intact by sending and receiving a TLS 1915 closure alert. 1917 The initiating protocol peer sends the TLS closure alert. If it 1918 wishes to leave the LDAP connection intact, it then MUST cease to 1919 send further PDUs and MUST ignore any received PDUs until it receives 1920 a TLS closure alert from the other peer. 1922 Once the initiating protocol peer receives a TLS closure alert from 1923 the other peer it MAY send and receive LDAP PDUs. 1925 When a protocol peer receives the initial TLS closure alert, it may 1926 choose to allow the underlying LDAP connection to remain intact. In 1927 this case, it MUST immediately transmit a TLS closure alert. 1928 Following this, it MAY send and receive LDAP PDUs. 1930 Protocol peers MAY drop the underlying LDAP connection after sending 1931 or receiving a TLS closure alert. 1933 After the TLS connection has been closed, the server MUST NOT send 1934 responses to any request message received before the TLS closure. 1935 Thus, clients wishing to receive responses to messages sent while the 1936 TLS connection is intact MUST wait for those message responses before 1937 sending the TLS closure alert. 1939 4.14.3.2. Abrupt Closure 1941 Either the client or server MAY abruptly close the TLS connection by 1942 dropping the underlying transfer protocol connection. In this 1943 circumstance, a server MAY send the client a Notice of Disconnection 1944 before dropping the underlying LDAP connection. Outstanding 1945 operations are handled as specified in Section 5.2. 1947 5. Protocol Element Encodings and Transfer 1948 Lightweight Directory Access Protocol Version 3 1950 One underlying service, LDAP over TCP, is defined here. This service 1951 is generally applicable to applications providing or consuming X.500- 1952 based directory services on the Internet. 1954 Implementations of LDAP over TCP MUST implement the mapping as 1955 described in Section 5.2.1 1957 5.1. Protocol Encoding 1959 The protocol elements of LDAP SHALL be encoded for exchange using the 1960 Basic Encoding Rules [BER] of [ASN.1] with the following 1961 restrictions: 1963 - Only the definite form of length encoding is used. 1965 - OCTET STRING values are encoded in the primitive form only. 1967 - If the value of a BOOLEAN type is true, the encoding of the value 1968 octet is set to hex "FF". 1970 - If a value of a type is its default value, it is absent. Only some 1971 BOOLEAN and INTEGER types have default values in this protocol 1972 definition. 1974 These restrictions are meant to ease the overhead of encoding and 1975 decoding certain elements in BER. 1977 These restrictions do not apply to ASN.1 types encapsulated inside of 1978 OCTET STRING values, such as attribute values, unless otherwise 1979 stated. 1981 5.2. Transfer Protocols 1983 This protocol is designed to run over connection-oriented, reliable 1984 transports, with all 8 bits in an octet being significant in the data 1985 stream. Protocol operations are tied to a connection, thus if the 1986 connection is closed or dropped, the operation is aborted. When this 1987 happens, any outstanding operations on the server are, when possible, 1988 abandoned, and when not possible, completed without transmission of 1989 the response. Also, if the connection is closed or dropped, the 1990 client MUST NOT assume that any outstanding requests which modified 1991 the Directory have succeeded or failed. 1993 5.2.1. Transmission Control Protocol (TCP) 1995 The encoded LDAPMessage PDUs are mapped directly onto the [TCP] 1996 bytestream using the BER-based encoding described in Section 5.1. It 1997 is recommended that server implementations running over the TCP 1998 provide a protocol listener on the Internet Assigned Numbers 1999 Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may 2000 Lightweight Directory Access Protocol Version 3 2002 instead provide a listener on a different port number. Clients MUST 2003 support contacting servers on any valid TCP port. 2005 6. Security Considerations 2007 This version of the protocol provides facilities for simple 2008 authentication using a cleartext password, as well as any [SASL] 2009 mechanism. SASL allows for integrity and privacy services to be 2010 negotiated. 2012 It is also permitted that the server can return its credentials to 2013 the client, if it chooses to do so. 2015 Use of cleartext password is strongly discouraged where the 2016 underlying transport service cannot guarantee confidentiality and may 2017 result in disclosure of the password to unauthorized parties. 2019 Servers are encouraged to prevent directory modifications by clients 2020 that have authenticated anonymously [AuthMeth]. 2022 Requirements of authentication methods, SASL mechanisms, and TLS are 2023 described in [AuthMeth]. 2025 It should be noted that SASL authentication exchanges do not provide 2026 data confidentiality nor integrity protection for the version or name 2027 fields of the bind request nor the resultCode, diagnosticMessage, or 2028 referral fields of the bind response nor of any information contained 2029 in controls attached to bind request or responses. Thus information 2030 contained in these fields SHOULD NOT be relied on unless otherwise 2031 protected (such as by establishing protections at the transport 2032 layer). 2034 Server implementors should plan for the possibility of an identity 2035 associated with an LDAP connection being deleted, renamed, or 2036 modified, and take appropriate actions to prevent insecure side 2037 effects. Likewise, server implementors should plan for the 2038 possibility of an associated identity's credentials becoming invalid, 2039 or an identity's privileges being changed. The ways in which these 2040 issues are addressed are application and/or implementation specific. 2042 Implementations which cache attributes and entries obtained via LDAP 2043 MUST ensure that access controls are maintained if that information 2044 is to be provided to multiple clients, since servers may have access 2045 control policies which prevent the return of entries or attributes in 2046 search results except to particular authenticated clients. For 2047 example, caches could serve result information only to the client 2048 whose request caused it to be in the cache. 2050 Servers may return referrals or search result references which 2051 redirect clients to peer servers. It is possible for a rogue 2052 application to inject such referrals into the data stream in an 2053 attempt to redirect a client to a rogue server. Clients are advised 2054 to be aware of this, and possibly reject referrals when 2055 Lightweight Directory Access Protocol Version 3 2057 confidentiality measures are not in place. Clients are advised to 2058 reject referrals from the StartTLS operation. 2060 The matchedDN and diagnosticMessage fields, as well as some 2061 resultCode values (e.g., attributeOrValueExists and 2062 entryAlreadyExists), could disclose the presence the specific data in 2063 the directory which is subject to access and other administrative 2064 controls. Server implementations should restrict access to protected 2065 information equally under both normal and error conditions. 2067 Protocol peers MUST be prepared to handle invalid and arbitrary 2068 length protocol encodings. A number of LDAP security advisories are 2069 available through [CERT]. 2071 7. Acknowledgements 2073 This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve 2074 Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, 2075 and Mark Wahl. It is also based on [LIMR] by Roger Harrison, and Kurt 2076 Zeilenga. Notable amounts of technical reviews and content were 2077 provided by Kurt Zeilenga, Steven Legg, and Hallvard Furuseth. Their 2078 work along with the input of individuals of the IETF ASID, LDAPEXT, 2079 LDUP, LDAPBIS, and other Working Groups is gratefully acknowledged. 2081 8. Normative References 2083 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2084 Specifications: ABNF", RFC 2234, November 1997. 2086 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 2087 "Information Technology - Abstract Syntax Notation One 2088 (ASN.1): Specification of basic notation" 2090 [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection 2091 Level Security Mechanisms", draft-ietf-ldapbis-authmeth- 2092 xx.txt, (a work in progress). 2094 [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, 2095 "Information technology - ASN.1 encoding rules: 2096 Specification of Basic Encoding Rules (BER), Canonical 2097 Encoding Rules (CER) and Distinguished Encoding Rules 2098 (DER)", 2002. 2100 [IP] Postel, J., "Internet Protocol", STD5 and RFC 791, 2101 September 1981 2103 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 2104 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 2105 : 1993. 2107 [Keyword] Bradner, S., "Key words for use in RFCs to Indicate 2108 Requirement Levels", RFC 2119, March 1997. 2110 Lightweight Directory Access Protocol Version 3 2112 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 2113 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a 2114 work in progress). 2116 [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf- 2117 ldapbis-bcp64-xx.txt, (a work in progress). 2119 [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf- 2120 ldapbis-url-xx.txt, (a work in progress). 2122 [LIMR] Harrison, R., and K. Zeilenga, "The Lightweight Directory 2123 Access Protocol (LDAP) Intermediate Response Message", 2124 draft-rharrison-ldap-intermediate-resp-xx.txt (a work in 2125 progress). 2127 [Models] Zeilenga, K., "LDAP: Directory Information Models", draft- 2128 ietf-ldapbis-models-xx.txt (a work in progress). 2130 [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", 2131 draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). 2133 [SASL] Melnikov, A., "Simple Authentication and Security Layer", 2134 draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). 2136 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and 2137 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in 2138 progress). 2140 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of 2141 Internationalized Strings ('stringprep')", draft-hoffman- 2142 rfc3454bis-xx.txt, a work in progress. 2144 [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching 2145 Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in 2146 progress). 2148 [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC 2149 793, September 1981 2151 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", 2152 draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. 2154 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 2155 3.2.0" is defined by "The Unicode Standard, Version 3.0" 2156 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 2157 as amended by the "Unicode Standard Annex #27: Unicode 2158 3.1" (http://www.unicode.org/reports/tr27/) and by the 2159 "Unicode Standard Annex #28: Unicode 3.2" 2160 (http://www.unicode.org/reports/tr28/). 2162 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2163 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2164 August 1998. 2166 Lightweight Directory Access Protocol Version 3 2168 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2169 10646", STD63 and RFC3629, November 2003. 2171 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 2172 Models and Service", 1993. 2174 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. 2176 [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service 2177 Definition", 1993. 2179 9. Informative References 2181 [CERT] The CERT(R) Center, http://www.cert.org 2183 [PortReg] IANA, "Port Numbers", 2184 http://www.iana.org/assignments/port-numbers 2186 10. IANA Considerations 2188 It is requested that the Internet Assigned Numbers Authority (IANA) 2189 update the LDAP result code registry to indicate that this document 2190 provides the definitive technical specification for result codes 0- 2191 36, 48-54, 64-70, 80-90. 2193 It is requested that the IANA update the LDAP Protocol Mechanism 2194 registry to indicate that this document and [AuthMeth] provides the 2195 definitive technical specification for the Start TLS 2196 (1.3.6.1.4.1.1466.20037) extended operation. 2198 It is requested that the IANA update the occurrence of "RFC XXXX" in 2199 Appendix B with this RFC number at publication. 2201 11. Editor's Address 2203 Jim Sermersheim 2204 Novell, Inc. 2205 1800 South Novell Place 2206 Provo, Utah 84606, USA 2207 jimse@novell.com 2208 +1 801 861-3088 2209 Lightweight Directory Access Protocol Version 3 2211 Appendix A - LDAP Result Codes 2213 This normative appendix details additional considerations regarding 2214 LDAP result codes and provides a brief, general description of each 2215 LDAP result code enumerated in Section 4.1.9. 2217 Additional result codes MAY be defined for use with extensions 2218 [LDAPIANA]. Client implementations SHALL treat any result code which 2219 they do not recognize as an unknown error condition. 2221 A.1 Non-Error Result Codes 2223 These result codes (called "non-error" result codes) do not indicate 2224 an error condition: 2225 success (0), 2226 compareTrue (6), 2227 compareFalse (7), 2228 referral (10), and 2229 saslBindInProgress (14). 2231 The success, compareTrue, and compareFalse result codes indicate 2232 successful completion (and, hence, are referred to as "successful" 2233 result codes). 2235 The referral and saslBindInProgress result codes indicate the client 2236 is required to take additional action to complete the operation. 2238 A.2 Result Codes 2240 Existing LDAP result codes are described as follows: 2242 success (0) 2243 Indicates the successful completion of an operation. Note: 2244 this code is not used with the compare operation. See 2245 compareTrue (5) and compareFalse (6). 2247 operationsError (1) 2248 Indicates that the operation is not properly sequenced with 2249 relation to other operations (of same or different type). 2251 For example, this code is returned if the client attempts to 2252 StartTLS [TLS] while there are other operations outstanding 2253 or if TLS was already established. 2255 protocolError (2) 2256 Indicates the server received data which has incorrect 2257 structure. 2259 For bind operation only, this code is also used to indicate 2260 that the server does not support the requested protocol 2261 version. 2263 Lightweight Directory Access Protocol Version 3 2265 timeLimitExceeded (3) 2266 Indicates that the time limit specified by the client was 2267 exceeded before the operation could be completed. 2269 sizeLimitExceeded (4) 2270 Indicates that the size limit specified by the client was 2271 exceeded before the operation could be completed. 2273 compareFalse (5) 2274 Indicates that the compare operation has successfully 2275 completed and the assertion has evaluated to FALSE. 2277 compareTrue (6) 2278 Indicates that the compare operation has successfully 2279 completed and the assertion has evaluated to TRUE. 2281 authMethodNotSupported (7) 2282 Indicates that the authentication method or mechanism is not 2283 supported. 2285 strongAuthRequired (8) 2286 Indicates that the server has detected that an established 2287 security association between the client and server has 2288 unexpectedly failed or been compromised, or that the server 2289 now requires the client to authenticate using a strong(er) 2290 mechanism. 2292 referral (10) 2293 Indicates that a referral needs to be chased to complete the 2294 operation (see Section 4.1.10). 2296 adminLimitExceeded (11) 2297 Indicates that an administrative limit has been exceeded. 2299 unavailableCriticalExtension (12) 2300 Indicates that the server is unable or unwilling to perform a 2301 critical control (see Section 4.1.11). 2303 confidentialityRequired (13) 2304 Indicates that data confidentiality protections are required. 2306 saslBindInProgress (14) 2307 Indicates the server requires the client to send a new bind 2308 request, with the same SASL mechanism, to continue the 2309 authentication process (see Section 4.2). 2311 noSuchAttribute (16) 2312 Indicates that the named entry does not contain the specified 2313 attribute or attribute value. 2315 undefinedAttributeType (17) 2316 Indicates that a request field contains an unrecognized 2317 attribute description. 2319 Lightweight Directory Access Protocol Version 3 2321 inappropriateMatching (18) 2322 Indicates that an attempt was made, e.g. in an assertion, to 2323 use a matching rule not defined for the attribute type 2324 concerned. 2326 constraintViolation (19) 2327 Indicates that the client supplied an attribute value which 2328 does not conform to the constraints placed upon it by the 2329 data model. 2331 For example, this code is returned when multiple values are 2332 supplied to an attribute which has a SINGLE-VALUE constraint. 2334 attributeOrValueExists (20) 2335 Indicates that the client supplied an attribute or value to 2336 be added to an entry, but the attribute or value already 2337 exists. 2339 invalidAttributeSyntax (21) 2340 Indicates that a purported attribute value does not conform 2341 to the syntax of the attribute. 2343 noSuchObject (32) 2344 Indicates that the object does not exist in the DIT. 2346 aliasProblem (33) 2347 Indicates that an alias problem has occurred. For example, 2348 the code may used to indicate an alias has been dereferenced 2349 which names no object. 2351 invalidDNSyntax (34) 2352 Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search 2353 base, target entry, ModifyDN newrdn, etc.) of a request does 2354 not conform to the required syntax or contains attribute 2355 values which do not conform to the syntax of the attribute's 2356 type. 2358 aliasDereferencingProblem (36) 2359 Indicates that a problem occurred while dereferencing an 2360 alias. Typically an alias was encountered in a situation 2361 where it was not allowed or where access was denied. 2363 inappropriateAuthentication (48) 2364 Indicates the server requires the client which had attempted 2365 to bind anonymously or without supplying credentials to 2366 provide some form of credentials. 2368 invalidCredentials (49) 2369 Indicates that the provided credentials (e.g. the user's name 2370 and password) are invalid. 2372 insufficientAccessRights (50) 2373 Indicates that the client does not have sufficient access 2374 rights to perform the operation. 2376 Lightweight Directory Access Protocol Version 3 2378 busy (51) 2379 Indicates that the server is too busy to service the 2380 operation. 2382 unavailable (52) 2383 Indicates that the server is shutting down or a subsystem 2384 necessary to complete the operation is offline. 2386 unwillingToPerform (53) 2387 Indicates that the server is unwilling to perform the 2388 operation. 2390 loopDetect (54) 2391 Indicates that the server has detected an internal loop (e.g. 2392 while dereferencing aliases or chaining an operation). 2394 namingViolation (64) 2395 Indicates that the entry's name violates naming restrictions. 2397 objectClassViolation (65) 2398 Indicates that the entry violates object class restrictions. 2400 notAllowedOnNonLeaf (66) 2401 Indicates that the operation is inappropriately acting upon a 2402 non-leaf entry. 2404 notAllowedOnRDN (67) 2405 Indicates that the operation is inappropriately attempting to 2406 remove a value which forms the entry's relative distinguished 2407 name. 2409 entryAlreadyExists (68) 2410 Indicates that the request cannot be fulfilled (added, moved, 2411 or renamed) as the target entry already exists. 2413 objectClassModsProhibited (69) 2414 Indicates that an attempt to modify the object class(es) of 2415 an entry's 'objectClass' attribute is prohibited. 2417 For example, this code is returned when a client attempts to 2418 modify the structural object class of an entry. 2420 affectsMultipleDSAs (71) 2421 Indicates that the operation cannot be completed as it 2422 affects multiple servers (DSAs). 2424 other (80) 2425 Indicates the server has encountered an internal error. 2427 Lightweight Directory Access Protocol Version 3 2429 Appendix B - Complete ASN.1 Definition 2431 This appendix is normative. 2433 Lightweight-Directory-Access-Protocol-V3 2434 -- Copyright (C) The Internet Society (2003). This version of 2435 -- this ASN.1 module is part of RFC XXXX; see the RFC itself 2436 -- for full legal notices. 2437 DEFINITIONS 2438 IMPLICIT TAGS 2439 EXTENSIBILITY IMPLIED ::= 2441 BEGIN 2443 LDAPMessage ::= SEQUENCE { 2444 messageID MessageID, 2445 protocolOp CHOICE { 2446 bindRequest BindRequest, 2447 bindResponse BindResponse, 2448 unbindRequest UnbindRequest, 2449 searchRequest SearchRequest, 2450 searchResEntry SearchResultEntry, 2451 searchResDone SearchResultDone, 2452 searchResRef SearchResultReference, 2453 modifyRequest ModifyRequest, 2454 modifyResponse ModifyResponse, 2455 addRequest AddRequest, 2456 addResponse AddResponse, 2457 delRequest DelRequest, 2458 delResponse DelResponse, 2459 modDNRequest ModifyDNRequest, 2460 modDNResponse ModifyDNResponse, 2461 compareRequest CompareRequest, 2462 compareResponse CompareResponse, 2463 abandonRequest AbandonRequest, 2464 extendedReq ExtendedRequest, 2465 extendedResp ExtendedResponse, 2466 intermediateResponse IntermediateResponse 2467 ... }, 2468 controls [0] Controls OPTIONAL } 2470 MessageID ::= INTEGER (0 .. maxInt) 2472 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 2474 LDAPString ::= OCTET STRING -- UTF-8 encoded, 2475 -- [ISO10646] characters 2477 LDAPOID ::= OCTET STRING -- Constrained to [Models] 2479 LDAPDN ::= LDAPString -- Constrained to 2480 -- [LDAPDN] 2482 RelativeLDAPDN ::= LDAPString -- Constrained to 2483 Lightweight Directory Access Protocol Version 3 2485 -- [LDAPDN] 2487 AttributeDescription ::= LDAPString 2488 -- Constrained to 2489 -- [Models] 2491 AttributeValue ::= OCTET STRING 2493 AttributeValueAssertion ::= SEQUENCE { 2494 attributeDesc AttributeDescription, 2495 assertionValue AssertionValue } 2497 AssertionValue ::= OCTET STRING 2499 PartialAttribute ::= SEQUENCE { 2500 type AttributeDescription, 2501 vals SET OF value AttributeValue } 2503 Attribute ::= PartialAttribute(WITH COMPONENTS { 2504 ..., 2505 vals (SIZE(1..MAX))}) 2507 MatchingRuleId ::= LDAPString 2509 LDAPResult ::= SEQUENCE { 2510 resultCode ENUMERATED { 2511 success (0), 2512 operationsError (1), 2513 protocolError (2), 2514 timeLimitExceeded (3), 2515 sizeLimitExceeded (4), 2516 compareFalse (5), 2517 compareTrue (6), 2518 authMethodNotSupported (7), 2519 strongAuthRequired (8), 2520 -- 9 reserved -- 2521 referral (10), 2522 adminLimitExceeded (11), 2523 unavailableCriticalExtension (12), 2524 confidentialityRequired (13), 2525 saslBindInProgress (14), 2526 noSuchAttribute (16), 2527 undefinedAttributeType (17), 2528 inappropriateMatching (18), 2529 constraintViolation (19), 2530 attributeOrValueExists (20), 2531 invalidAttributeSyntax (21), 2532 -- 22-31 unused -- 2533 noSuchObject (32), 2534 aliasProblem (33), 2535 invalidDNSyntax (34), 2536 -- 35 reserved for undefined isLeaf -- 2537 aliasDereferencingProblem (36), 2538 -- 37-47 unused -- 2539 Lightweight Directory Access Protocol Version 3 2541 inappropriateAuthentication (48), 2542 invalidCredentials (49), 2543 insufficientAccessRights (50), 2544 busy (51), 2545 unavailable (52), 2546 unwillingToPerform (53), 2547 loopDetect (54), 2548 -- 55-63 unused -- 2549 namingViolation (64), 2550 objectClassViolation (65), 2551 notAllowedOnNonLeaf (66), 2552 notAllowedOnRDN (67), 2553 entryAlreadyExists (68), 2554 objectClassModsProhibited (69), 2555 -- 70 reserved for CLDAP -- 2556 affectsMultipleDSAs (71), 2557 -- 72-79 unused -- 2558 other (80), 2559 ... }, 2560 matchedDN LDAPDN, 2561 diagnosticMessage LDAPString, 2562 referral [3] Referral OPTIONAL } 2564 Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI 2566 URI ::= LDAPString -- limited to characters permitted in 2567 -- URIs 2569 Controls ::= SEQUENCE OF control Control 2571 Control ::= SEQUENCE { 2572 controlType LDAPOID, 2573 criticality BOOLEAN DEFAULT FALSE, 2574 controlValue OCTET STRING OPTIONAL } 2576 BindRequest ::= [APPLICATION 0] SEQUENCE { 2577 version INTEGER (1 .. 127), 2578 name LDAPDN, 2579 authentication AuthenticationChoice } 2581 AuthenticationChoice ::= CHOICE { 2582 simple [0] OCTET STRING, 2583 -- 1 and 2 reserved 2584 sasl [3] SaslCredentials, 2585 ... } 2587 SaslCredentials ::= SEQUENCE { 2588 mechanism LDAPString, 2589 credentials OCTET STRING OPTIONAL } 2591 BindResponse ::= [APPLICATION 1] SEQUENCE { 2592 COMPONENTS OF LDAPResult, 2593 serverSaslCreds [7] OCTET STRING OPTIONAL } 2594 Lightweight Directory Access Protocol Version 3 2596 UnbindRequest ::= [APPLICATION 2] NULL 2598 SearchRequest ::= [APPLICATION 3] SEQUENCE { 2599 baseObject LDAPDN, 2600 scope ENUMERATED { 2601 baseObject (0), 2602 singleLevel (1), 2603 wholeSubtree (2) }, 2604 derefAliases ENUMERATED { 2605 neverDerefAliases (0), 2606 derefInSearching (1), 2607 derefFindingBaseObj (2), 2608 derefAlways (3) }, 2609 sizeLimit INTEGER (0 .. maxInt), 2610 timeLimit INTEGER (0 .. maxInt), 2611 typesOnly BOOLEAN, 2612 filter Filter, 2613 attributes AttributeSelection } 2615 AttributeSelection ::= SEQUENCE OF selection LDAPString 2616 -- constrained to 2617 -- in section 4.5.1. 2619 Filter ::= CHOICE { 2620 and [0] SET SIZE (1..MAX) OF filter Filter, 2621 or [1] SET SIZE (1..MAX) OF filter Filter, 2622 not [2] Filter, 2623 equalityMatch [3] AttributeValueAssertion, 2624 substrings [4] SubstringFilter, 2625 greaterOrEqual [5] AttributeValueAssertion, 2626 lessOrEqual [6] AttributeValueAssertion, 2627 present [7] AttributeDescription, 2628 approxMatch [8] AttributeValueAssertion, 2629 extensibleMatch [9] MatchingRuleAssertion } 2631 SubstringFilter ::= SEQUENCE { 2632 type AttributeDescription, 2633 -- at least one must be present, 2634 -- initial and final can occur at most once 2635 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 2636 initial [0] AssertionValue, 2637 any [1] AssertionValue, 2638 final [2] AssertionValue } } 2640 MatchingRuleAssertion ::= SEQUENCE { 2641 matchingRule [1] MatchingRuleId OPTIONAL, 2642 type [2] AttributeDescription OPTIONAL, 2643 matchValue [3] AssertionValue, 2644 dnAttributes [4] BOOLEAN DEFAULT FALSE } 2646 SearchResultEntry ::= [APPLICATION 4] SEQUENCE { 2647 objectName LDAPDN, 2648 attributes PartialAttributeList } 2649 Lightweight Directory Access Protocol Version 3 2651 PartialAttributeList ::= SEQUENCE OF 2652 partialAttribute PartialAttribute 2654 SearchResultReference ::= [APPLICATION 19] SEQUENCE 2655 SIZE (1..MAX) OF uri URI 2657 SearchResultDone ::= [APPLICATION 5] LDAPResult 2659 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 2660 object LDAPDN, 2661 changes SEQUENCE OF change SEQUENCE { 2662 operation ENUMERATED { 2663 add (0), 2664 delete (1), 2665 replace (2) }, 2666 modification PartialAttribute } } 2668 ModifyResponse ::= [APPLICATION 7] LDAPResult 2670 AddRequest ::= [APPLICATION 8] SEQUENCE { 2671 entry LDAPDN, 2672 attributes AttributeList } 2674 AttributeList ::= SEQUENCE OF attribute Attribute 2676 AddResponse ::= [APPLICATION 9] LDAPResult 2678 DelRequest ::= [APPLICATION 10] LDAPDN 2680 DelResponse ::= [APPLICATION 11] LDAPResult 2682 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 2683 entry LDAPDN, 2684 newrdn RelativeLDAPDN, 2685 deleteoldrdn BOOLEAN, 2686 newSuperior [0] LDAPDN OPTIONAL } 2688 ModifyDNResponse ::= [APPLICATION 13] LDAPResult 2690 CompareRequest ::= [APPLICATION 14] SEQUENCE { 2691 entry LDAPDN, 2692 ava AttributeValueAssertion } 2694 CompareResponse ::= [APPLICATION 15] LDAPResult 2696 AbandonRequest ::= [APPLICATION 16] MessageID 2698 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 2699 requestName [0] LDAPOID, 2700 requestValue [1] OCTET STRING OPTIONAL } 2702 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 2703 COMPONENTS OF LDAPResult, 2704 responseName [10] LDAPOID OPTIONAL, 2705 Lightweight Directory Access Protocol Version 3 2707 responseValue [11] OCTET STRING OPTIONAL } 2709 END 2710 Lightweight Directory Access Protocol Version 3 2712 Appendix C - Changes 2714 This appendix is non-normative. 2716 This appendix summarizes substantive changes made to RFC 2251 and RFC 2717 2830. 2719 C.1 Changes made to made to RFC 2251: 2721 This section summarizes the substantive changes made to Sections 1, 2722 2, 3.1, and 4 through the remainder of RFC 2251. Readers should 2723 consult [Models] and [AuthMeth] for summaries of changes to other 2724 sections. 2726 C.1.1 Section 1 2728 - Removed IESG note. Post publication of RFC 2251, mandatory LDAP 2729 authentication mechanisms have been standardized which are 2730 sufficient to remove this note. See [AuthMeth] for authentication 2731 mechanisms. 2733 C.1.2 Section 3.1 and others 2735 - Removed notes giving history between LDAP v1, v2 and v3. Instead, 2736 added sufficient language so that this document can stand on its 2737 own. 2739 C.1.3 Section 4 2741 - Clarified where the extensibility features of ASN.1 apply to the 2742 protocol. This change also affected various ASN.1 types. 2743 - Removed the requirement that servers which implement version 3 or 2744 later MUST provide the 'supportedLDAPVersion' attribute. This 2745 statement provided no interoperability advantages. 2747 C.1.4 Section 4.1.1 2749 - There was a mandatory requirement for the server to return a 2750 Notice of Disconnection and drop the connection when a PDU is 2751 malformed in a certain way. This has been clarified such that the 2752 server SHOULD return the Notice of Disconnection, and MUST drop 2753 the connection. 2755 C.1.5 Section 4.1.1.1 2757 - Clarified that the messageID of requests MUST be non-zero. 2759 Lightweight Directory Access Protocol Version 3 2761 - Clarified when it is and isn't appropriate to return an already 2762 used message id. RFC 2251 accidentally imposed synchronous server 2763 behavior in its wording of this. 2765 C.1.6 Section 4.1.2 2767 - Stated that LDAPOID is constrained to from [Models]. 2769 C.1.7 Section 4.1.5.1 2771 - Removed the Binary Option from the specification. There are 2772 numerous interoperability problems associated with this method of 2773 alternate attribute type encoding. Work to specify a suitable 2774 replacement is ongoing. 2776 C.1.8 Section 4.1.6 2778 - Removed references to the "binary" encoding as it has been removed 2779 from the specification. 2781 C.1.9 Section 4.1.7 2783 - Removed references to the "binary" encoding as it has been removed 2784 from the specification. 2786 C.1.10 Section 4.1.8 2788 - Combined the definitions of PartialAttribute and Attribute here, 2789 and defined Attribute in terms of PartialAttribute. 2791 C.1.11 Section 4.1.10 2793 - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to 2794 be sent for non-error results. 2795 - Moved some language into Appendix A, and refer the reader there. 2796 - Allowed matchedDN to be present for other result codes than those 2797 listed in RFC 2251. 2799 C.1.12 Section 4.1.11 2801 - Defined referrals in terms of URIs rather than URLs. 2802 - Removed the requirement that all referral URIs MUST be equally 2803 capable of progressing the operation. The statement was ambiguous 2804 and provided no instructions on how to carry it out. 2805 - Added the requirement that clients MUST NOT loop between servers. 2806 - Clarified the instructions for using LDAPURLs in referrals, and in 2807 doing so added a recommendation that the scope part be present. 2809 Lightweight Directory Access Protocol Version 3 2811 C.1.13 Section 4.1.12 2813 - Specified how control values defined in terms of ASN.1 are to be 2814 encoded. 2815 - Noted that the criticality field is only applied to request 2816 messages (except unbindRequest), and must be ignored when present 2817 on response messages and unbindRequest. 2818 - Added language regarding combinations of controls on a message. 2819 - Changed "The server MUST be prepared" to "Implementations MUST be 2820 prepared" in the eighth paragraph to reflect that both client and 2821 server implementations must be able to handle this (as both parse 2822 controls). 2824 C.1.14 Section 4.2 2826 - Mandated that servers return protocolError when the version is not 2827 supported. 2828 - Clarified behavior when the simple authentication is used, the 2829 name is empty and the password is non-empty. 2830 - Required servers to not dereference aliases for bind. This was 2831 added for consistency with other operations and to help ensure 2832 data consistency. 2833 - Required that textual passwords be transferred as UTF-8 encoded 2834 Unicode, and added recommendations on string preparation. This was 2835 to help ensure interoperability of passwords being sent from 2836 different clients. 2838 C.1.15 Section 4.2.1 2840 - This section was largely reorganized for readability and language 2841 was added to clarify the authentication state of failed and 2842 abandoned bind operations. 2843 - Removed: "If a SASL transfer encryption or integrity mechanism has 2844 been negotiated, that mechanism does not support the changing of 2845 credentials from one identity to another, then the client MUST 2846 instead establish a new connection." 2847 Each SASL negotiation is, generally, independent of other SASL 2848 negotiations. If there were dependencies between multiple 2849 negotiations of a particular mechanism, the mechanism technical 2850 specification should detail how applications are to deal with 2851 them. LDAP should not require any special handling. And if an LDAP 2852 client had used such a mechanism, it would have the option of 2853 using another mechanism. 2854 - Dropped MUST imperative in paragraph 3 to align with [Keywords]. 2856 C.1.16 Section 4.2.3 2857 Lightweight Directory Access Protocol Version 3 2859 - Moved most error-related text to Appendix A, and added text 2860 regarding certain errors used in conjunction with the bind 2861 operation. 2862 - Prohibited the server from specifying serverSaslCreds when not 2863 appropriate. 2865 C.1.17 Section 4.3 2867 - Required both peers to cease transmission and close the connection 2868 for the unbind operation. 2870 C.1.18 Section 4.4 2872 - Added instructions for future specifications of Unsolicited 2873 Notifications. 2875 C.1.19 Section 4.5.1 2877 - SearchRequest attributes is now defined as an AttributeSelection 2878 type rather than AttributeDescriptionList, and an ABNF is 2879 provided. 2880 - SearchRequest attributes may contain duplicate attribute 2881 descriptions. This was previously prohibited. Now servers are 2882 instructed to ignore subsequent names when they are duplicated. 2883 This was relaxed in order to allow different short names and also 2884 OIDs to be requested for an attribute. 2885 - The Filter choices 'and' and 'or', and the SubstringFilter 2886 substrings types are now defined with a lower bound of 1. 2887 - The SubstringFilter substrings 'initial, 'any', and 'final' types 2888 are now AssertionValue rather than LDAPString. Also, added 2889 imperatives stating that 'initial' (if present) must be listed 2890 first, and 'final' (if present) must be listed last. 2891 - Clarified the semantics of the derefAliases choices. 2892 - Added instructions for equalityMatch, substrings, greaterOrEqual, 2893 lessOrEqual, and approxMatch. 2895 C.1.20 Section 4.5.2 2897 - Recommended that servers not use attribute short names when it 2898 knows they are ambiguous or may cause interoperability problems. 2899 - Removed all mention of ExtendedResponse due to lack of 2900 implementation. 2902 C.1.21 Section 4.5.3 2904 - Made changes similar to those made to Section 4.1.11. 2906 C.1.22 Section 4.5.3.1 2907 Lightweight Directory Access Protocol Version 3 2909 - Fixed examples to adhere to changes made to Section 4.5.3. 2911 C.1.23 Section 4.6 2913 - Removed restriction that required an EQUALITY matching rule in 2914 order to perform value delete modifications. It is sufficiently 2915 documented that in absence of an equality matching rule, octet 2916 equality is used. 2917 - Replaced AttributeTypeAndValues with Attribute as they are 2918 equivalent. 2919 - Clarified what type of modification changes might temporarily 2920 violate schema. 2922 C.1.24 Section 4.7 2924 - Aligned Add operation with X.511 in that the attributes of the RDN 2925 are used in conjunction with the listed attributes to create the 2926 entry. Previously, Add required that the distinguished values be 2927 present in the listed attributes. 2929 C.1.25 Section 4.9 2931 - Required servers to not dereference aliases for modify DN. This 2932 was added for consistency with other operations and to help ensure 2933 data consistency. 2934 - Allow modify DN to fail when moving between naming contexts. 2935 - Specified what happens when the attributes of the newrdn are no 2936 present on the entry. 2938 C.1.26 Section 4.10 2940 - Clarified the semantics of Compare when the attribute is not 2941 present and when it is unknown. 2942 - Clarified that an Undefined compare results in a compareFalse 2943 resultCode. 2944 - Required servers to not dereference aliases for compare. This was 2945 added for consistency with other operations and to help ensure 2946 data consistency. 2948 C.1.27 Section 4.11 2950 - Explained that since abandon returns no response, clients should 2951 not use it if they need to know the outcome. 2952 - Specified that Abandon and Unbind cannot be abandoned. 2954 C.1.28 Section 4.12 2955 Lightweight Directory Access Protocol Version 3 2957 - Specified how values of extended operations defined in terms of 2958 ASN.1 are to be encoded. 2959 - Added instructions on what extended operation specifications 2960 consist of. 2961 - Added a recommendation that servers advertise supported extended 2962 operations. 2964 C.1.29 Section 5.2 2966 - Moved referral-specific instructions into referral-related 2967 sections. 2969 C.1.30 Section 7 2971 - Reworded notes regarding SASL not protecting certain aspects of 2972 the LDAP bind PDU. 2973 - Noted that Servers are encouraged to prevent directory 2974 modifications by clients that have authenticated anonymously 2975 [AuthMeth]. 2976 - Added a note regarding the scenario where an identity is changed 2977 (deleted, privileges or credentials modified, etc.). 2978 - Warned against following referrals that may have been injected in 2979 the data stream. 2980 - Noted that servers should protect information equally, whether in 2981 an error condition or not, and mentioned specifically; matchedDN, 2982 diagnosticMessage, and resultCodes. 2983 - Added a note regarding malformed and long encodings. 2985 C.1.31 Appendix A 2987 - Added "EXTESIBILITY IMPLIED" to ASN.1 definition. 2988 - Removed AttributeType. It is not used. 2990 C.2 Changes made to made to RFC 2830: 2992 This section summarizes the substantive changes made to Sections of 2993 RFC 2830. Readers should consult [AuthMeth] for summaries of changes 2994 to other sections. 2996 C.2.1 Section 2.3 2998 - Removed wording indicating that referrals can be returned from 2999 StartTLS 3000 - Removed requirement that only a narrow set of result codes can be 3001 returned. Some result codes are required in certain scenarios, but 3002 any other may be returned if appropriate. 3004 C.2.1 Section 4.13.3.1 3005 Lightweight Directory Access Protocol Version 3 3007 - Reworded most of this section and added the requirement that after 3008 the TLS connection has been closed, the server MUST NOT send 3009 responses to any request message received before the TLS closure. 3011 C.3 Changes made to made to [LIMR]: 3013 - In general, all technical language was transferred in whole. 3014 Supporting and background language seen as redundant due to its 3015 presence in this document was omitted. 3017 Lightweight Directory Access Protocol Version 3 3019 Intellectual Property Rights 3021 The IETF takes no position regarding the validity or scope of any 3022 intellectual property or other rights that might be claimed to 3023 pertain to the implementation or use of the technology described in 3024 this document or the extent to which any license under such rights 3025 might or might not be available; neither does it represent that it 3026 has made any effort to identify any such rights. Information on the 3027 IETF's procedures with respect to rights in standards-track and 3028 standards-related documentation can be found in BCP-11. Copies of 3029 claims of rights made available for publication and any assurances of 3030 licenses to be made available, or the result of an attempt made to 3031 obtain a general license or permission for the use of such 3032 proprietary rights by implementors or users of this specification can 3033 be obtained from the IETF Secretariat. 3035 The IETF invites any interested party to bring to its attention any 3036 copyrights, patents or patent applications, or other proprietary 3037 rights which may cover technology that may be required to practice 3038 this standard. Please address the information to the IETF Executive 3039 Director. 3041 Full Copyright Statement 3043 Copyright (C) The Internet Society (2003). All Rights Reserved. 3045 This document and translations of it may be copied and furnished to 3046 others, and derivative works that comment on or otherwise explain it 3047 or assist in its implementation may be prepared, copied, published 3048 and distributed, in whole or in part, without restriction of any 3049 kind, provided that the above copyright notice and this paragraph are 3050 included on all such copies and derivative works. However, this 3051 document itself may not be modified in any way, such as by removing 3052 the copyright notice or references to the Internet Society or other 3053 Internet organizations, except as needed for the purpose of 3054 developing Internet standards in which case the procedures for 3055 copyrights defined in the Internet Standards process must be 3056 followed, or as required to translate it into languages other than 3057 English. 3059 The limited permissions granted above are perpetual and will not be 3060 revoked by the Internet Society or its successors or assigns. 3062 This document and the information contained herein is provided on an 3063 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3064 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3065 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3066 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3067 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.