idnits 2.17.1 draft-ietf-asid-ldapv2-protocol-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope ENUMERATED {' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 189 has weird spacing: '...inition is si...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1035 looks like a reference -- Missing reference section? '2' on line 1036 looks like a reference -- Missing reference section? '3' on line 965 looks like a reference -- Missing reference section? '4' on line 966 looks like a reference -- Missing reference section? '5' on line 967 looks like a reference -- Missing reference section? '6' on line 968 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 835 looks like a reference -- Missing reference section? '0' on line 1034 looks like a reference -- Missing reference section? '7' on line 969 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 856 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 858 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 861 looks like a reference -- Missing reference section? '8' on line 970 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 887 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 895 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 901 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 917 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 920 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 928 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 930 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 932 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 935 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 940 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 943 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 950 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 952 looks like a reference -- Missing reference section? '12' on line 765 looks like a reference -- Missing reference section? '11' on line 762 looks like a reference -- Missing reference section? '10' on line 759 looks like a reference -- Missing reference section? '13' on line 768 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Wengyik Yeong 3 INTERNET-DRAFT Performance Systems International 4 Tim Howes 5 University of Michigan 6 Steve Kille 7 ISODE Consortium 9 Lightweight Directory Access Protocol 10 12 1. Status of this Memo 14 This draft document will be submitted to the RFC Editor as a standards 15 document. Distribution of this memo is unlimited. Please send comments 16 to the authors, or the discussion group . 18 This document is an Internet-Draft. Internet-Drafts are working docu- 19 ments of the Internet Engineering Task Force (IETF), its areas, and its 20 working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 2. Abstract 35 The protocol described in this document is designed to provide access to 36 the X.500 Directory while not incurring the resource requirements of the 37 Directory Access Protocol (DAP). This protocol is specifically targeted 38 at simple management applications and browser applications that provide 39 simple read/write interactive access to the X.500 Directory, and is 40 intended to be a complement to the DAP itself. 42 Key aspects of LDAP are 44 - Protocol elements are carried directly over TCP or other transport, 45 bypassing much of the session/presentation overhead. 47 - Many protocol data elements are encoding as ordinary strings (e.g., 48 LDAP May 1996 50 Distinguished Names). 52 - A lightweight BER encoding is used to encode all protocol elements. 54 3. History 56 The tremendous interest in X.500 [1,2] technology in the Internet has 57 lead to efforts to reduce the high ``cost of entry'' associated with use 58 of the technology, such as the Directory Assistance Service [3] and 59 DIXIE [4]. While efforts such as these have met with success, they have 60 been solutions based on particular implementations and as such have lim- 61 ited applicability. This document continues the efforts to define 62 Directory protocol alternatives but departs from previous efforts in 63 that it consciously avoids dependence on particular implementations. 65 4. Protocol Model 67 The general model adopted by this protocol is one of clients performing 68 protocol operations against servers. In this model, this is accomplished 69 by a client transmitting a protocol request describing the operation to 70 be performed to a server, which is then responsible for performing the 71 necessary operations on the Directory. Upon completion of the necessary 72 operations, the server returns a response containing any results or 73 errors to the requesting client. In keeping with the goal of easing the 74 costs associated with use of the Directory, it is an objective of this 75 protocol to minimize the complexity of clients so as to facilitate 76 widespread deployment of applications capable of utilizing the Direc- 77 tory. 79 Note that, although servers are required to return responses whenever 80 such responses are defined in the protocol, there is no requirement for 81 synchronous behavior on the part of either client or server implementa- 82 tions: requests and responses for multiple operations may be exchanged 83 by client and servers in any order, as long as clients eventually 84 receive a response for every request that requires one. 86 Consistent with the model of servers performing protocol operations on 87 behalf of clients, it is also to be noted that protocol servers are 88 expected to handle referrals without resorting to the return of such 89 referrals to the client. This protocol makes no provisions for the 90 return of referrals to clients, as the model is one of servers ensuring 91 the performance of all necessary operations in the Directory, with only 92 final results or errors being returned by servers to clients. 94 Note that this protocol can be mapped to a strict subset of the direc- 95 tory abstract service, so it can be cleanly provided by the DAP. 97 LDAP May 1996 99 5. Mapping Onto Transport Services 101 This protocol is designed to run over connection-oriented, reliable 102 transports, with all 8 bits in an octet being significant in the data 103 stream. Specifications for two underlying services are defined here, 104 though others are also possible. 106 5.1. Transmission Control Protocol (TCP) 108 The LDAPMessage PDUs are mapped directly onto the TCP bytestream. 109 Server implementations running over the TCP should provide a protocol 110 listener on port 389. 112 5.2. Connection Oriented Transport Service (COTS) 114 The connection is established. No special use of T-Connect is made. 115 Each LDAPMessage PDU is mapped directly onto T-Data. 117 6. Elements of Protocol 119 For the purposes of protocol exchanges, all protocol operations are 120 encapsulated in a common envelope, the LDAPMessage, which is defined as 121 follows: 123 LDAPMessage ::= 124 SEQUENCE { 125 messageID MessageID, 126 protocolOp CHOICE { 127 bindRequest BindRequest, 128 bindResponse BindResponse, 129 unbindRequest UnbindRequest, 130 searchRequest SearchRequest, 131 searchResponse SearchResponse, 132 modifyRequest ModifyRequest, 133 modifyResponse ModifyResponse, 134 addRequest AddRequest, 135 addResponse AddResponse, 136 delRequest DelRequest, 137 delResponse DelResponse, 138 modifyRDNRequest ModifyRDNRequest, 139 modifyRDNResponse ModifyRDNResponse, 140 compareRequest CompareRequest, 141 compareResponse CompareResponse, 142 abandonRequest AbandonRequest 143 } 144 } 146 MessageID ::= INTEGER (0 .. maxInt) 148 LDAP May 1996 150 The function of the LDAPMessage is to provide an envelope containing 151 common fields required in all protocol exchanges. At this time the only 152 common field is a message ID, which is required to have a value dif- 153 ferent from the values of any other requests outstanding in the LDAP 154 session of which this message is a part. 156 The message ID value must be echoed in all LDAPMessage envelopes encap- 157 sulting responses corresponding to the request contained in the LDAPMes- 158 sage in which the message ID value was originally used. 160 In addition to the LDAPMessage defined above, the following definitions 161 are also used in defining protocol operations: 163 LDAPString ::= OCTET STRING 165 The LDAPString is a notational convenience to indicate that, although 166 strings of LDAPString type encode as OCTET STRING types, the legal char- 167 acter set in such strings is limited to the IA5 character set. 169 LDAPDN ::= LDAPString 171 RelativeLDAPDN ::= LDAPString 173 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 174 representation of a Distinguished Name and a Relative Distinguished Name 175 after encoding according to the specification in [5], such that 177 ::= 179 ::= 181 where and are as defined in [5]. 183 AttributeValueAssertion ::= 184 SEQUENCE { 185 attributeType AttributeType, 186 attributeValue AttributeValue 187 } 189 The AttributeValueAssertion type definition is similar to the one in 190 the X.500 Directory standards. 192 AttributeType ::= LDAPString 194 AttributeValue ::= OCTET STRING 196 LDAP May 1996 198 An AttributeType value takes on as its value the textual string associ- 199 ated with that AttributeType in Section 4 of [6]. For example, the 200 AttributeType commonName with object identifier 2.5.4.3 is represented 201 as an AttributeType in this protocol by the string "cn". In the event 202 that a protocol implementation encounters an Attribute Type with which 203 it cannot associate a textual string, an ASCII string encoding of the 204 object identifier associated with the Attribute Type may be subsiti- 205 tuted. For example, the commonName AttributeType may be represented by 206 the ASCII string "2.5.4.3" if a protocol implementation is unable to 207 associate the string "cn" with it. 209 The list of textual attribute names defined in Section 4 of [6] are the 210 only names supported, though sites may exchange other names through 211 bilateral agreement. A future version of this protocol may provide a 212 general mechanism by which supported attribute names may be extended. 214 A field of type AttributeValue takes on as its value an octet string 215 encoding of a Directory AttributeValue type. The definition of these 216 string encodings for different Directory AttributeValue syntaxes may be 217 found in [6]. These are the only syntaxes allowed in the protocol, 218 though others may be supported by bilateral agreement. A future version 219 of this protocol may provide a general mechanism by which supported 220 attribute syntaxes may be extended. 222 LDAPResult ::= 223 SEQUENCE { 224 resultCode ENUMERATED { 225 success (0), 226 operationsError (1), 227 protocolError (2), 228 timeLimitExceeded (3), 229 sizeLimitExceeded (4), 230 compareFalse (5), 231 compareTrue (6), 232 authMethodNotSupported (7), 233 strongAuthRequired (8), 234 noSuchAttributeOrValue (16), 235 undefinedAttributeType (17), 236 inappropriateMatching (18), 237 constraintViolation (19), 238 attributeOrValueExists (20), 239 invalidAttributeSyntax (21), 240 noSuchObject (32), 241 aliasProblem (33), 242 invalidDNSyntax (34), 243 isLeaf (35), 244 aliasDereferencingProblem (36), 245 inappropriateAuthentication (48), 247 LDAP May 1996 249 invalidCredentials (49), 250 insufficientAccessRights (50), 251 busy (51), 252 unavailable (52), 253 unwillingToPerform (53), 254 loopDetected (54), 255 namingViolation (64), 256 objectClassViolation (65), 257 notAllowedOnNonLeaf (66), 258 notAllowedOnRDN (67), 259 entryAlreadyExists (68), 260 objectClassModsProhibited (69), 261 other (80) }, 262 matchedDN LDAPDN, errorMessage LDAPString } 264 The LDAPResult is the construct used in this protocol to return success 265 or failure indications from servers to clients. In response to various 266 requests, servers will return responses containing fields of type 267 LDAPResult to indicate the final status of a protocol operation request. 268 The errorMessage field of this construct may, at the servers option, be 269 used to return an ASCII string containing a textual, human-readable 270 error diagnostic. As this error diagnostic is not standardized, imple- 271 mentations should not rely on the values returned. If the server 272 chooses not to return a textual diagnostic, the errorMessage field of 273 the LDAPResult type should contain a zero length string. 275 For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax, isLeaf, 276 and aliasDereferencingProblem, the matchedDN field is set to the name of 277 the lowest entry (object or alias) in the DIT that was matched and is a 278 truncated form of the name provided or, if an alias has been derefer- 279 enced, of the resulting name. The matchedDN field should be set to NULL 280 DN (a zero length string) in all other cases. 282 Note that the resultCodes are not sequential in value. X.500 defines 283 different categories of errors (e.g., NameError, AttributeError, etc.). 284 The resultCodes are constructed so that a simple and efficient bit 285 operation can be performed to determine the error category. 287 6.1. Bind Operation 289 The function of the Bind Operation is to initiate a protocol session 290 between a client and a server, and to allow the authentication of the 291 client to the server. The Bind Operation must be the first operation 292 request received by a server from a client in a protocol session. The 293 Bind Request is defined as follows: 295 BindRequest ::= 296 [APPLICATION 0] SEQUENCE { 298 LDAP May 1996 300 version INTEGER (1 .. 127), 301 name LDAPDN, 302 authentication CHOICE { 303 simple [0] OCTET STRING 304 -- more choices possible in a future version 305 -- tag [1] reserved 306 -- tag [2] reserved 307 } 308 } 310 Parameters of the Bind Request are: 312 - version: A version number indicating the version of the protocol to 313 be used in this protocol session. This document describes version 314 2 of the LDAP protocol. Note that there is no version negotiation, 315 and the client should just set this parameter to the version it 316 desires. 318 - name: The name of the Directory object that the client wishes to 319 bind as. This field may take on a null value (a zero length 320 string) for the purposes of anonymous binds. 322 - authentication: information used to authenticate the name, if any, 323 provided in the Bind Request. The ``simple'' authentication option 324 provides minimal authentication facilities, with the contents of 325 the authentication field consisting only of a cleartext password. 326 This option should also be used when unauthenticated or anonymous 327 binds are to be performed, with the field containing a zero length 328 string in such cases. Sites may use other choices in the authenti- 329 cation field by bilateral agreement. Authentication choices with 330 tags [1] and [2] are reserved for compatibility with existing 331 clients that use those tags for non-standard authentication using 332 Kerberos version 4 [7]. 334 The Bind Operation requires a response, the Bind Response, which is 335 defined as: 337 BindResponse ::= [APPLICATION 1] LDAPResult 339 A Bind Response consists simply of an indication from the server of the 340 status of the client's request for the initiation of a protocol session. 342 Upon receipt of a Bind Request, a protocol server will authenticate the 343 requesting client if necessary, and attempt to set up a protocol session 344 with that client. The server will then return a Bind Response to the 345 client indicating the status of the session setup request. 347 LDAP May 1996 349 6.2. Unbind Operation 351 The function of the Unbind Operation is to terminate a protocol session. 352 The Unbind Operation is defined as follows: 354 UnbindRequest ::= [APPLICATION 2] NULL 356 The Unbind Operation has no response defined. Upon transmission of an 357 UnbindRequest, a protocol client may assume that the protocol session is 358 terminated. Upon receipt of an UnbindRequest, a protocol server may 359 assume that the requesting client has terminated the session and that 360 all outstanding requests may be discarded. 362 6.3. Search Operation 364 The Search Operation allows a client to request that a search be per- 365 formed on its behalf by a server. The Search Request is defined as fol- 366 lows: 368 SearchRequest ::= 369 [APPLICATION 3] SEQUENCE { 370 baseObject LDAPDN, 371 scope ENUMERATED { 372 baseObject (0), 373 singleLevel (1), 374 wholeSubtree (2) 375 }, 376 derefAliases ENUMERATED { 377 neverDerefAliases (0), 378 derefInSearching (1), 379 derefFindingBaseObj (2), 380 derefAlways (3) 381 }, 382 sizeLimit INTEGER (0 .. maxInt), 383 timeLimit INTEGER (0 .. maxInt), 384 attrsOnly BOOLEAN, 385 filter Filter, 386 attributes SEQUENCE OF AttributeType 387 } 389 Filter ::= 390 CHOICE { 391 and [0] SET OF Filter, 392 or [1] SET OF Filter, 393 not [2] Filter, 394 equalityMatch [3] AttributeValueAssertion, 395 substrings [4] SubstringFilter, 396 greaterOrEqual [5] AttributeValueAssertion, 398 LDAP May 1996 400 lessOrEqual [6] AttributeValueAssertion, 401 present [7] AttributeType, 402 approxMatch [8] AttributeValueAssertion 403 } 405 SubstringFilter 406 SEQUENCE { 407 type AttributeType, 408 SEQUENCE OF CHOICE { 409 initial [0] LDAPString, 410 any [1] LDAPString, 411 final [2] LDAPString 412 } 413 } 415 Parameters of the Search Request are: 417 - baseObject: An LDAPDN that is the base object entry relative to 418 which the search is to be performed. 420 - scope: An indicator of the scope of the search to be performed. The 421 semantics of the possible values of this field are identical to the 422 semantics of the scope field in the Directory Search Operation. 424 - derefAliases: An indicator as to how alias objects should be han- 425 dled in searching. The semantics of the possible values of this 426 field are, in order of increasing value: 428 neverDerefAliases: do not dereference aliases in search- 429 ing or in locating the base object of the search; 431 derefInSearching: dereference aliases in subordinates of 432 the base object in searching, but not in locating the 433 base object of the search; 435 derefFindingBaseObject: dereference aliases in locating 436 the base object of the search, but not when searching 437 subordinates of the base object; 439 derefAlways: dereference aliases both in searching and in 440 locating the base object of the search. 442 - sizelimit: A sizelimit that restricts the maximum number of entries 443 to be returned as a result of the search. A value of 0 in this 444 field indicates that no sizelimit restrictions are in effect for 445 the search. 447 - timelimit: A timelimit that restricts the maximum time (in seconds) 448 LDAP May 1996 450 allowed for a search. A value of 0 in this field indicates that no 451 timelimit restrictions are in effect for the search. 453 - attrsOnly: An indicator as to whether search results should contain 454 both attribute types and values, or just attribute types. Setting 455 this field to TRUE causes only attribute types (no values) to be 456 returned. Setting this field to FALSE causes both attribute types 457 and values to be returned. 459 - filter: A filter that defines the conditions that must be fulfilled 460 in order for the search to match a given entry. 462 - attributes: A list of the attributes from each entry found as a 463 result of the search to be returned. An empty list signifies that 464 all attributes from each entry found in the search are to be 465 returned. 467 The results of the search attempted by the server upon receipt of a 468 Search Request are returned in Search Responses, defined as follows: 470 Search Response ::= 471 CHOICE { 472 entry [APPLICATION 4] SEQUENCE { 473 objectName LDAPDN, 474 attributes SEQUENCE OF SEQUENCE { 475 AttributeType, 476 SET OF AttributeValue 477 } 478 }, 479 resultCode [APPLICATION 5] LDAPResult 480 } 482 Upon receipt of a Search Request, a server will perform the necessary 483 search of the DIT. 485 The server will return to the client a sequence of responses comprised 486 of: 488 - Zero or more Search Responses each consisting of an entry found 489 during the search; with the response sequence terminated by 491 - A single Search Response containing an indication of success, or 492 detailing any errors that have occurred. 494 Each entry returned will contain all attributes, complete with associ- 495 ated values if necessary, as specified in the 'attributes' field of the 496 Search Request. 498 LDAP May 1996 500 Note that an X.500 ``list'' operation can be emulated by a one-level 501 LDAP search operation with a filter checking for the existence of the 502 objectClass attribute, and that an X.500 ``read'' operation can be emu- 503 lated by a base object LDAP search operation with the same filter. 505 6.4. Modify Operation 507 The Modify Operation allows a client to request that a modification of 508 the DIB be performed on its behalf by a server. The Modify Request is 509 defined as follows: 511 ModifyRequest ::= 512 [APPLICATION 6] SEQUENCE { 513 object LDAPDN, 514 modification SEQUENCE OF SEQUENCE { 515 operation ENUMERATED { 516 add (0), 517 delete (1), 518 replace (2) 519 }, 520 modification SEQUENCE { 521 type AttributeType, 522 values SET OF 523 AttributeValue 524 } 525 } 526 } 528 Parameters of the Modify Request are: 530 - object: The object to be modified. The value of this field should 531 name the object to be modified after all aliases have been derefer- 532 enced. The server will not perform any alias dereferencing in 533 determining the object to be modified. 535 - A list of modifications to be performed on the entry to be modi- 536 fied. The entire list of entry modifications should be performed 537 in the order they are listed, as a single atomic operation. While 538 individual modifications may violate the Directory schema, the 539 resulting entry after the entire list of modifications is performed 540 must conform to the requirements of the Directory schema. The 541 values that may be taken on by the 'operation' field in each modif- 542 ication construct have the following semantics respectively:- 544 add: add values listed to the given attribute, creating 545 the attribute if necessary; 547 delete: delete values listed from the given attribute, 549 LDAP May 1996 551 removing the entire attribute if no values are listed, or 552 if all current values of the attribute are listed for 553 deletion; 555 replace: replace existing values of the given attribute 556 with the new values listed, creating the attribute if 557 necessary. 559 The result of the modify attempted by the server upon receipt of a 560 Modify Request is returned in a Modify Response, defined as follows: 562 ModifyResponse ::= [APPLICATION 7] LDAPResult 564 Upon receipt of a Modify Request, a server will perform the necessary 565 modifications to the DIB. 567 The server will return to the client a single Modify Response indicating 568 either the successful completion of the DIB modification, or the reason 569 that the modification failed. Note that due to the requirement for atom- 570 icity in applying the list of modifications in the Modify Request, the 571 client may expect that no modifications of the DIB have been performed 572 if the Modify Response received indicates any sort of error, and that 573 all requested modifications have been performed if the Modify Response 574 indicates successful completion of the Modify Operation. 576 6.5. Add Operation 578 The Add Operation allows a client to request the addition of an entry 579 into the Directory. The Add Request is defined as follows: 581 AddRequest ::= 582 [APPLICATION 8] SEQUENCE { 583 entry LDAPDN, 584 attrs SEQUENCE OF SEQUENCE { 585 type AttributeType, 586 values SET OF AttributeValue 587 } 588 } 590 Parameters of the Add Request are: 592 - entry: the Distinguished Name of the entry to be added. Note that 593 all components of the name except for the last RDN component must 594 exist for the add to succeed. 596 - attrs: the list of attributes that make up the content of the entry 597 being added. 599 LDAP May 1996 601 The result of the add attempted by the server upon receipt of a Add 602 Request is returned in the Add Response, defined as follows: 604 AddResponse ::= [APPLICATION 9] LDAPResult 606 Upon receipt of an Add Request, a server will attempt to perform the add 607 requested. The result of the add attempt will be returned to the client 608 in the Add Response. 610 6.6. Delete Operation 612 The Delete Operation allows a client to request the removal of an entry 613 from the Directory. The Delete Request is defined as follows: 615 DelRequest ::= [APPLICATION 10] LDAPDN 617 The Delete Request consists only of the Distinguished Name of the entry 618 to be deleted. The result of the delete attempted by the server upon 619 receipt of a Delete Request is returned in the Delete Response, defined 620 as follows: 622 DelResponse ::= [APPLICATION 11] LDAPResult 624 Upon receipt of a Delete Request, a server will attempt to perform the 625 entry removal requested. The result of the delete attempt will be 626 returned to the client in the Delete Response. Note that only leaf 627 objects may be deleted with this operation. 629 6.7. Modify RDN Operation 631 The Modify RDN Operation allows a client to change the last component of 632 the name of an entry in the Directory. The Modify RDN Request is defined 633 as follows: 635 ModifyRDNRequest ::= 636 [APPLICATION 12] SEQUENCE { 637 entry LDAPDN, 638 newrdn RelativeLDAPDN, 639 deleteoldrdn BOOLEAN 640 } 642 Parameters of the Modify RDN Request are: 644 - entry: the name of the entry to be changed. 646 - newrdn: the RDN that will form the last component of the new name. 648 - deleteoldrdn: a boolean parameter that controls whether the old RDN 649 LDAP May 1996 651 attribute values should be retained as attributes of the entry or 652 deleted from the entry. 654 The result of the name change attempted by the server upon receipt of a 655 Modify RDN Request is returned in the Modify RDN Response, defined as 656 follows: 658 ModifyRDNResponse ::= [APPLICATION 13] LDAPResult 660 Upon receipt of a Modify RDN Request, a server will attempt to perform 661 the name change. The result of the name change attempt will be returned 662 to the client in the Modify RDN Response. The attributes that make up 663 the old RDN are deleted from the entry, or kept, depending on the set- 664 ting of the deleteoldrdn parameter. 666 6.8. Compare Operation 668 The Compare Operation allows a client to compare an assertion provided 669 with an entry in the Directory. The Compare Request is defined as fol- 670 lows: 672 CompareRequest ::= 673 [APPLICATION 14] SEQUENCE { 674 entry LDAPDN, 675 ava AttributeValueAssertion 676 } 678 Parameters of the Compare Request are: 680 - entry: the name of the entry to be compared with. 682 - ava: the assertion with which the entry is to be compared. 684 The result of the compare attempted by the server upon receipt of a Com- 685 pare Request is returned in the Compare Response, defined as follows: 687 CompareResponse ::= [APPLICATION 15] LDAPResult 689 Upon receipt of a Compare Request, a server will attempt to perform the 690 requested comparison. The result of the comparison will be returned to 691 the client in the Compare Response. Note that errors and the result of 692 comparison are all returned in the same construct. 694 6.9. Abandon Operation 696 The function of the Abandon Operation is to allow a client to request 697 that the server abandon an outstanding operation. The Abandon Request 698 is defined as follows: 700 LDAP May 1996 702 AbandonRequest ::= [APPLICATION 16] MessageID 704 There is no response defined in the Abandon Operation. Upon transmission 705 of an Abandon Operation, a client may expect that the operation identi- 706 fied by the Message ID in the Abandon Request has been abandoned. In the 707 event that a server receives an Abandon Request on a Search Operation in 708 the midst of transmitting responses to that search, that server should 709 cease transmitting responses to the abandoned search immediately. 711 7. Protocol Element Encodings 713 The protocol elements of LDAP are encoded for exchange using the Basic 714 Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the high over- 715 head involved in using certain elements of the BER, the following addi- 716 tional restrictions are placed on BER-encodings of LDAP protocol ele- 717 ments: 719 (1) Only the definite form of length encoding will be used. 721 (2) Bitstrings and octet strings and all character string types will be 722 encoded in the primitive form only. 724 8. Security Considerations 726 This version of the protocol provides facilities only for simple authen- 727 tication using a cleartext password. Future versions of LDAP will 728 likely include support for other authentication methods. 730 9. Bibliography 732 [1] The Directory: Overview of Concepts, Models and Service. CCITT 733 Recommendation X.500, 1988 735 [2] Information Processing Systems -- Open Systems Interconnection -- 736 The Directory: Overview of Concepts, Models and Service. ISO/IEC 737 JTC 1/SC21; International Standard 9594-1, 1988 739 [3] Directory Assistance Service. M.T. Rose; RFC 1202, February 1991. 741 [4] DIXIE protocol specification. T. Howes, M. Smith, B. Beecher; RFC 742 1249, August 1991. 744 [5] A String Representation of Distinguished Names. Steve Kille; RFC 745 1779 747 [6] The String Representation of Standard Attribute Syntaxes. T. 748 Howes, S. Kille, W. Yeong, C.J. Robbins, M. Wahl; RFC XXXX 750 LDAP May 1996 752 [7] Kerberos Authentication and Authorization System. S.P. Miller, 753 B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena Docu- 754 mentation Section E.2.1, December 1987 756 [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC 757 1/SC21; International Standard 9594-2, 1988 759 [10] The Directory: Abstract Service Definition. CCITT Recommendation 760 X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988 762 [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT 763 Recommendation X.208, 1988. 765 [12] Specification of Basic Encoding Rules for Abstract Syntax Notation 766 One (ASN.1). CCITT Recommendation X.209, 1988. 768 [13] Information Processing Systems - Open Systems Interconnection, 769 "Transport Service Definition", International Organization for 770 Standardization, International Standard 8072, June 1986. 772 10. Author's Addresses 774 Wengyik Yeong 775 PSI Inc. 776 510 Huntmar Park Drive 777 Herndon, VA 22070 778 USA 779 +1 703-450-8001 780 yeongw@psilink.com 782 Tim Howes 783 University of Michigan 784 ITD Research Systems 785 535 W William St. 786 Ann Arbor, MI 48103-4943 787 USA 788 +1 313 747-4454 789 tim@umich.edu 791 Steve Kille 792 ISODE Consortium 793 The Dome, The Square 794 Richmond 795 TW9 1DT 796 UK 797 +44-181-332-9091 798 S.Kille@isode.com 800 LDAP May 1996 802 Appendix A 803 Complete ASN.1 Definition 805 Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::= 807 BEGIN 809 LDAPMessage ::= 810 SEQUENCE { 811 messageID MessageID, 812 -- unique id in request, 813 -- to be echoed in response(s) 814 protocolOp CHOICE { 815 searchRequest SearchRequest, 816 searchResponse SearchResponse, 817 modifyRequest ModifyRequest, 818 modifyResponse ModifyResponse, 819 addRequest AddRequest, 820 addResponse AddResponse, 821 delRequest DelRequest, 822 delResponse DelResponse, 823 modifyDNRequest ModifyDNRequest, 824 modifyDNResponse ModifyDNResponse, 825 compareRequest CompareRequest, 826 compareResponse CompareResponse, 827 bindRequest BindRequest, 828 bindResponse BindResponse, 829 abandonRequest AbandonRequest, 830 unbindRequest UnbindRequest 831 } 832 } 834 BindRequest ::= 835 [APPLICATION 0] SEQUENCE { 836 version INTEGER (1 .. 127), 837 -- current version is 2 838 name LDAPDN, 839 -- null name implies an anonymous bind 840 authentication CHOICE { 841 simple [0] OCTET STRING, 842 -- a zero length octet string 843 -- implies an unauthenticated 844 -- bind. 845 krbv42LDAP [1] OCTET STRING, 846 krbv42DSA [2] OCTET STRING 847 -- values as returned by krb_mk_req() 849 LDAP May 1996 851 -- Other values in later versions 852 -- of this protocol. 853 } 854 } 856 BindResponse ::= [APPLICATION 1] LDAPResult 858 UnbindRequest ::= [APPLICATION 2] NULL 860 SearchRequest ::= 861 [APPLICATION 3] SEQUENCE { 862 baseObject LDAPDN, 863 scope ENUMERATED { 864 baseObject (0), 865 singleLevel (1), 866 wholeSubtree (2) 867 }, 868 derefAliases ENUMERATED { 869 neverDerefAliases (0), 870 derefInSearching (1), 871 derefFindingBaseObj (2), 872 alwaysDerefAliases (3) 873 }, 874 sizeLimit INTEGER (0 .. maxInt), 875 -- value of 0 implies no sizelimit 876 timeLimit INTEGER (0 .. maxInt), 877 -- value of 0 implies no timelimit 878 attrsOnly BOOLEAN, 879 -- TRUE, if only attributes (without values) 880 -- to be returned. 881 filter Filter, 882 attributes SEQUENCE OF AttributeType 883 } 885 SearchResponse ::= 886 CHOICE { 887 entry [APPLICATION 4] SEQUENCE { 888 objectName LDAPDN, 889 attributes SEQUENCE OF SEQUENCE { 890 AttributeType, 891 SET OF 892 AttributeValue 893 } 894 }, 895 resultCode [APPLICATION 5] LDAPResult 896 } 898 ModifyRequest ::= 899 LDAP May 1996 901 [APPLICATION 6] SEQUENCE { 902 object LDAPDN, 903 modifications SEQUENCE OF SEQUENCE { 904 operation ENUMERATED { 905 add (0), 906 delete (1), 907 replace (2) 908 }, 909 modification SEQUENCE { 910 type AttributeType, 911 values SET OF 912 AttributeValue 913 } 914 } 915 } 917 ModifyResponse ::= [APPLICATION 7] LDAPResult 919 AddRequest ::= 920 [APPLICATION 8] SEQUENCE { 921 entry LDAPDN, 922 attrs SEQUENCE OF SEQUENCE { 923 type AttributeType, 924 values SET OF AttributeValue 925 } 926 } 928 AddResponse ::= [APPLICATION 9] LDAPResult 930 DelRequest ::= [APPLICATION 10] LDAPDN 932 DelResponse ::= [APPLICATION 11] LDAPResult 934 ModifyRDNRequest ::= 935 [APPLICATION 12] SEQUENCE { 936 entry LDAPDN, 937 newrdn RelativeLDAPDN -- old RDN always deleted 938 } 940 ModifyRDNResponse ::= [APPLICATION 13] LDAPResult 942 CompareRequest ::= 943 [APPLICATION 14] SEQUENCE { 944 entry LDAPDN, 945 ava AttributeValueAssertion 946 } 948 LDAP May 1996 950 CompareResponse ::= [APPLICATION 15] LDAPResult 952 AbandonRequest ::= [APPLICATION 16] MessageID 954 MessageID ::= INTEGER (0 .. maxInt) 956 LDAPDN ::= LDAPString 958 RelativeLDAPDN ::= LDAPString 960 Filter ::= 961 CHOICE { 962 and [0] SET OF Filter, 963 or [1] SET OF Filter, 964 not [2] Filter, 965 equalityMatch [3] AttributeValueAssertion, 966 substrings [4] SubstringFilter, 967 greaterOrEqual [5] AttributeValueAssertion, 968 lessOrEqual [6] AttributeValueAssertion, 969 present [7] AttributeType, 970 approxMatch [8] AttributeValueAssertion 971 } 973 LDAPResult ::= 974 SEQUENCE { 975 resultCode ENUMERATED { 976 success (0), 977 operationsError (1), 978 protocolError (2), 979 timeLimitExceeded (3), 980 sizeLimitExceeded (4), 981 compareFalse (5), 982 compareTrue (6), 983 authMethodNotSupported (7), 984 strongAuthRequired (8), 985 noSuchAttribute (16), 986 undefinedAttributeType (17), 987 inappropriateMatching (18), 988 constraintViolation (19), 989 attributeOrValueExists (20), 990 invalidAttributeSyntax (21), 991 noSuchObject (32), 992 aliasProblem (33), 993 invalidDNSyntax (34), 994 isLeaf (35), 995 aliasDereferencingProblem (36), 996 inappropriateAuthentication (48), 997 invalidCredentials (49), 999 LDAP May 1996 1001 insufficientAccessRights (50), 1002 busy (51), 1003 unavailable (52), 1004 unwillingToPerform (53), 1005 loopDetect (54), 1006 namingViolation (64), 1007 objectClassViolation (65), 1008 notAllowedOnNonLeaf (66), 1009 notAllowedOnRDN (67), 1010 entryAlreadyExists (68), 1011 objectClassModsProhibited (69), 1012 other (80) 1013 }, 1014 matchedDN LDAPDN, 1015 errorMessage LDAPString 1016 } 1018 AttributeType ::= LDAPString 1019 -- text name of the attribute, or dotted 1020 -- OID representation 1022 AttributeValue ::= OCTET STRING 1024 AttributeValueAssertion ::= 1025 SEQUENCE { 1026 attributeType AttributeType, 1027 attributeValue AttributeValue 1028 } 1030 SubstringFilter ::= 1031 SEQUENCE { 1032 type AttributeType, 1033 SEQUENCE OF CHOICE { 1034 initial [0] LDAPString, 1035 any [1] LDAPString, 1036 final [2] LDAPString 1037 } 1038 } 1040 LDAPString ::= OCTET STRING 1042 maxInt INTEGER ::= 65535 1043 END