idnits 2.17.1 draft-ietf-asid-ldapv3-protocol-02.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-24) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 42 longer pages, the longest (page 2) being 61 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 324 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 286: '... cldapUserName LDAPDN OPTIONAL,...' RFC 2119 keyword, line 578: '... referral [3] Referral OPTIONAL }...' RFC 2119 keyword, line 739: '... supportedVersion [5] INTEGER (1..127) OPTIONAL,...' RFC 2119 keyword, line 740: '... serverURL [6] LDAPURL OPTIONAL,...' RFC 2119 keyword, line 741: '... serverCreds [7] AuthenticationChoice OPTIONAL }...' (35 more instances...) == 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 RFC1798, but the abstract doesn't seem to directly say this. It does mention RFC1798 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC1777, but the abstract doesn't seem to directly say this. It does mention RFC1777 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 28 has weird spacing: '...listing conta...' == Line 155 has weird spacing: '...bute to preve...' == Line 1236 has weird spacing: '...eturned actu...' -- 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 (30 August 1996) is 10099 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) -- Missing reference section? '1' on line 2285 looks like a reference -- Missing reference section? '2' on line 2261 looks like a reference -- Missing reference section? '5' on line 2109 looks like a reference -- Missing reference section? '6' on line 2110 looks like a reference -- Missing reference section? '3' on line 2262 looks like a reference -- Missing reference section? '15' on line 1878 looks like a reference -- Missing reference section? '16' on line 1881 looks like a reference -- Missing reference section? '4' on line 2263 looks like a reference -- Missing reference section? '17' on line 1883 looks like a reference -- Missing reference section? '11' on line 2215 looks like a reference -- Missing reference section? '14' on line 1875 looks like a reference -- Missing reference section? '9' on line 2205 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 2046 looks like a reference -- Missing reference section? '0' on line 2284 looks like a reference -- Missing reference section? '18' on line 1886 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 2060 looks like a reference -- Missing reference section? '7' on line 2111 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2066 looks like a reference -- Missing reference section? 'APPLICATION 17' on line 2068 looks like a reference -- Missing reference section? 'APPLICATION 18' on line 2070 looks like a reference -- Missing reference section? '12' on line 2287 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 2079 looks like a reference -- Missing reference section? '8' on line 2148 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 2129 looks like a reference -- Missing reference section? 'APPLICATION 19' on line 2143 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 2146 looks like a reference -- Missing reference section? 'APPLICATION 20' on line 2155 looks like a reference -- Missing reference section? 'APPLICATION 21' on line 2160 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 2162 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 2175 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 2177 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 2185 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2187 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2189 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2191 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2197 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 2199 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 2203 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 2207 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 2208 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 2212 looks like a reference -- Missing reference section? '10' on line 2214 looks like a reference -- Missing reference section? '19' on line 1889 looks like a reference -- Missing reference section? '13' on line 2288 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 48 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Critical Angle Inc. 3 Obsoletes: RFC 1777, RFC 1798 T. Howes 4 Netscape Communications Corp. 5 S. Kille 6 ISODE Consortium 7 Expires in six months from 30 August 1996 8 Intended Category: Standards Track 10 Lightweight Directory Access Protocol (v3) 11 13 Table of Contents - see end of document. 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 2. Abstract 34 The protocol described in this document is designed to provide access 35 to directories supporting the X.500 models, while not incurring the 36 resource requirements of the X.500 Directory Access Protocol (DAP). This 37 protocol is specifically targeted at management applications and browser 38 applications that provide read/write interactive access to directories. 39 When used with a directory supporting the X.500 protocols, it is 40 intended to be a complement to the X.500 DAP. 42 Key aspects of this version of LDAP are: 44 - All protocol elements of LDAP (RFC 1777) and CLDAP (RFC 1798) are 45 supported. 47 - Protocol elements are carried directly over TCP or other transport, 48 bypassing much of the session/presentation overhead. Connectionless 49 transport (UDP) is also supported for efficient lookup operations. 51 - Most protocol data elements can be encoded as ordinary strings 52 (e.g., Distinguished Names). 54 - New features have been added to enable more powerful clients, such as 55 the abilities to retrieve attribute values in binary or search results 56 in pages. 58 - Important features of X.500(1993) and X.500(1997) are included. 60 - Referrals to other servers may be returned. 62 - The protocol may be extended to support bilaterally-defined 63 operations. 65 - Several session controls may be requested by the client. 67 3. Models 69 Interest in X.500 [1] directory technologies in the Internet has lead to 70 efforts to reduce the high "cost of entry" associated with use of these 71 technologies. This document continues the efforts to define directory 72 protocol alternatives: it updates the LDAP [2] protocol specification, 73 adding support for new features, including some support for connecting 74 to X.500 services that implement the 1993 or 1997 edition protocols. 76 3.1. Protocol Model 78 The general model adopted by this protocol is one of clients 79 performing protocol operations against servers. In this model, a 80 client transmits a protocol request describing the operation to be 81 performed to a server, which is then responsible for performing 82 the necessary operation(s) in the directory. Upon completion of 83 the operation(s), the server returns a response containing any results or 84 errors to the requesting client. 86 In keeping with the goal of easing the costs associated with use of 87 the directory, it is an objective of this protocol to minimize the 88 complexity of clients so as to facilitate widespread deployment of 89 applications capable of utilizing the directory. 91 Note that, although servers are required to return responses whenever 92 such responses are defined in the protocol, there is no requirement 93 for synchronous behavior on the part of either clients or servers. 94 Requests and responses for multiple operations may be exchanged 95 between a client and server in any order, provided the client 96 eventually receives a response for every request that requires one. 98 In LDAP versions 1 and 2, no provision was made for protocol servers 99 returning referrals to clients. However, for improved performance and 100 distribution this version of the protocol permits servers to return to 101 clients referrals to other servers if requested. This allows servers, 102 if requested by clients, to offload the work of contacting other servers 103 to progress operations. 105 Clients may also request that no referrals be returned, in which case 106 the server must ensure that the operation is performed against the 107 directory, or else return an error. This is the default. 109 Note that this protocol can be mapped to a strict subset of the 110 X.500(1997) directory abstract service, so it can be cleanly provided 111 by the DAP. However there is not a one-to-one mapping between LDAP 112 protocol operations and DAP operations: server implementations 113 acting as a gateway to X.500 directories may need to make multiple DAP 114 requests to perform extended operations. 116 3.2. Data Model 118 This section provides a brief introduction to the X.500 data model, as 119 used by LDAP. 121 The LDAP protocol assumes there are one or more servers which jointly 122 provide access to a Directory Information Tree. The tree is made up of 123 entries. Entries have names: one or more values from the entry itself 124 form its relative distinguished name, which must be unique among all 125 its siblings. The concatenation of the relative distinguished names 126 of the line of entries from a particular entry to an immediate 127 subordinate of the root of the tree forms that entry's Distinguished 128 Name, which is unique in the tree. An example of a Distinguished Name is 130 CN=Steve Kille, O=ISODE Consortium, C=GB 132 Entries consist of a set of attributes. An attribute is a type with 133 one or more associated values. The attribute type, identified by a 134 short descriptive name and an OID (object identifier), governs the 135 maximum number of values permissible for an attribute of that type 136 in an entry, the syntax to which the values must conform, the types 137 of matching which can be performed on values of that attribute, and 138 other functions. 140 An example of an attribute is "mail". There may be one or more values 141 of this attribute, they must be IA5 strings, and they are case 142 insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). 144 Some servers may hold cache or shadow copies of entries, which can be 145 used to answer search and comparison queries, but will return referrals 146 or contact other servers if modification operations are requested. 148 3.2.1 Attributes of Entries 150 Each entry must have an objectClass attribute. The objectClass 151 attribute specifies the object classes of an entry, which along with 152 the system and user schema determine the permitted attributes of an entry. 153 Values of this attribute may be modified by clients, but the objectClass 154 attribute cannot be removed. Servers may restrict the modifications of 155 this attribute to prevent the basic structural class of the entry from 156 being changed (e.g. one cannot change a person into a country). 158 Servers should not permit clients to add attributes to an entry unless 159 those attributes are permitted by the object class definitions, the user 160 schema controlling that entry (specified in the subschema subentry), or 161 are operational attributes known to that server and used for 162 administrative purposes. Note that there is a particular objectClass 163 'extensibleObject' defined in [5] which permits all user attributes. 165 Entries may contain, among others, the following operational attributes, 166 defined in [5], which if present should not be modifiable by clients: 168 - creatorsName: the Distinguished Name of the user who added this entry 169 to the directory. 170 - createTimestamp: the time this entry was added to the directory. 171 - modifiersName: the Distinguished Name of the user who last modified 172 this entry. 173 - modifyTimestamp: the time this entry was last modified. 175 - subschemaSubentry: the Distinguished Name of the subschema subentry 176 which controls the schema for this entry. 177 - entryName: the Distinguished Name of the entry. 179 Servers may implement other operational attributes. Servers which 180 also make use of X.500(1993) protocols should provide support 181 for the attributes defined in X.501, including administrativeRole and 182 dseType. Some servers may permit the retrieval of subschema attributes 183 directly from user entries. 185 3.2.2 Subschema Subentry 187 A server may provide access to one or more subschema subentries to 188 permit clients to interrogate the schema which is in force for entries 189 in the directory. 191 A server which masters entries and permits clients to modify these 192 entries must implement and provide access to these subschema subentries, 193 so that its clients may discover the attributes and object classes which 194 are permitted to be present. It is strongly recommended that all other 195 servers implement subschema subentries as well. 197 The following four attributes, defined in [6] with string representations 198 in [5], must be present in all subschema subentries: 200 - CN: this attribute should be used to form the RDN of the subschema 201 subentry. 202 - objectClass: the attribute should have at least the values "top" and 203 "subschema". 204 - objectClasses: each value of this attribute specifies an object class 205 known to the server. 206 - attributeTypes: each value of this attribute specifies an attribute 207 type known to the server. 209 Other operational attributes may be present in subschema subentries, 210 in particular dseType, subtreeSpecification, ditStructureRules, nameForms, 211 ditContentRules, matchingRules, matchingRuleUse, createTimestamp, 212 creatorsName, modifyTimestamp, modifiersName, entryName, as described in 213 [6]. 215 Clients must only retrieve these attributes from a subentry by requesting 216 them by name in a baseObject search of the subentry. 218 3.3. Relationship to X.500 220 This document defines LDAP in terms of X.500 as an X.500 access 221 mechanism. An LDAP server should act in accordance with the 222 X.500(1993) series of ITU Recommendations when providing the service. 223 However, it is not required that an LDAP server make use of any X.500 224 protocols in providing this service, e.g. LDAP can be mapped onto any 225 other directory system so long as the X.500 data and service model as 226 used in LDAP is not violated in the LDAP interface. 228 3.4. Server-specific Data Requirements 230 An LDAP server must provide information about itself and other 231 information that is specific to each server. This is represented as a 232 number of attributes located in the root DSE (DSA-Specific Entry), 233 which is named with the zero-length LDAPDN. These attributes 234 should be retrievable if a client performs a base object search of the 235 root, however they are subject to access control restrictions. 236 They should not be included if the client performs a subtree search 237 starting from the root. The server may, but need not, allow the client to 238 modify these attributes. 240 The following attributes of the root DSE are defined in section 5.1.3 of 241 [5]. Additional attributes may be defined in later documents. 243 - administratorAddress: a URL containing address of administrator. 244 - currentTime: the current time. 245 - serverName: the Distinguished Name of the server. 246 - certificationPath: the server's certificate path. 247 - namingContexts: naming contexts held in the server. 248 - subschemaSubentry: subschema subentries known by this server. 249 - altServer: alternative servers in case this one is later unavailable. 250 - supportedExtension: list of supported extensions. 252 If the server does not master or shadow entries and does not know the 253 locations of schema information, the subschemaSubentry attribute should 254 not be present in the root DSE. If the server holds master or shadow 255 copies of directory entries under one or more schema rules, there may be 256 any number of values of the subschemaSubentry attribute in the root DSE. 258 4. Elements of Protocol 260 The LDAP protocol is described using Abstract Syntax Notation 1 [3]. It 261 is typically transferred using a subset of the Basic Encoding Rules. 262 In order to support future extensions to this protocol, clients and 263 servers should ignore elements of SEQUENCEs whose tags they do not 264 recognize. 266 Note that unlike X.500, each change to the LDAP protocol other than through 267 the extension mechanisms will have a different version number. A client 268 may indicate the version it supports as part of the bind request, 269 described in section 4.1.2. If a client has not sent a bind, the server 270 should assume that version 3 is supported in the client (since version 2 271 required that the client bind first). 273 4.1. Common Elements 275 This section describes the LDAPMessage envelope PDU format, as well as 276 data type definitions which are used in the protocol operations. 278 4.1.1. Message Envelope 280 For the purposes of protocol exchanges, all protocol operations are 281 encapsulated in a common envelope, the LDAPMessage, which is defined 282 as follows: 284 LDAPMessage ::= SEQUENCE { 285 messageID MessageID, 286 cldapUserName LDAPDN OPTIONAL, 287 protocolOp CHOICE { 288 bindRequest BindRequest, 289 bindResponse BindResponse, 290 unbindRequest UnbindRequest, 291 searchRequest SearchRequest, 292 searchResEntry SearchResultEntry, 293 searchResDone SearchResultDone, 294 searchResRef SearchResultReference, 295 searchResFull SearchResultFull, 296 modifyRequest ModifyRequest, 297 modifyResponse ModifyResponse, 298 addRequest AddRequest, 299 addResponse AddResponse, 300 delRequest DelRequest, 301 delResponse DelResponse, 302 modDNRequest ModifyDNRequest, 303 modDNResponse ModifyDNResponse, 304 compareRequest CompareRequest, 305 compareResponse CompareResponse, 306 abandonRequest AbandonRequest, 307 sessionRequest SessionRequest, 308 sessionResponse SessionResponse, 309 resumeRequest ResumeRequest, 310 resumeError ResumeError, 311 extendedReq ExtendedRequest, 312 extendedResp ExtendedResponse } } 314 MessageID ::= INTEGER (0 .. maxInt) 316 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 318 The function of the LDAPMessage is to provide an envelope containing 319 common fields required in all protocol exchanges. At this time the 320 only common fields are the message ID and cldapUserName. 322 The message ID value must be echoed in all LDAPMessage envelopes 323 encapsulating responses corresponding to the request contained in 324 the LDAPMessage in which the message ID value was originally used. 326 The message ID is required to have a value different from the values of 327 any other requests outstanding in the LDAP session of which this 328 message is a part. A client must not send a second request with the same 329 message ID as another request if the first request is outstanding. 330 If it does so, the behavior is undefined. Typically a client will 331 increment a counter for each request. 333 For all requests except for a search with a pageSizeLimit, the message ID 334 is outstanding until the client receives the final response for that 335 operation. 337 For searchRequest with a pageSize limit, if the client did not receive a 338 SearchResultDone for that search indicating all results were received, 339 the message ID is outstanding until after the operation is abandoned. 341 A client must not reuse the message id of an abandonRequest or the 342 abandoned operation until it has received a response from the server for 343 another request invoked subsequent to the abandonRequest, as the 344 abandonRequest itself does not have a response. 346 The cldapUserName identifies the requesting user for this message. It 347 is only present for backwards compatability with RFC 1798, if this 348 LDAPMessage is carried in a connectionless transport protocol, such as UDP. 349 Its significance is equivalent to a bind with a zero-length password. 350 When the LDAP session is carried in a connection-oriented transport 351 protocol this field must be absent. LDAPv3 client implementors should not 352 use this field in connectionless requests, but instead concatenate a bind 353 request with the other operations in the request. Concatenation and 354 connectionless transport are described in section 5.1.3. 356 4.1.2. String Types 358 The LDAPString is a notational convenience to indicate that, although 359 strings of LDAPString type encode as OCTET STRING types, the Unicode 360 [15] character set is used, encoded following the UTF-8 algorithm [16]. 361 Note that in the UTF-8 algorithm, characters which are the same as 362 ASCII (0000 through 007F) are represented as that same ASCII character 363 in a single byte. The other byte values are used to form a variable- 364 length encoding of an arbitrary Unicode character. 366 LDAPString ::= OCTET STRING 368 The LDAPOID is a notational convenience to indicate that the permitted 369 value of this string is a dotted-decimal representation of an OBJECT 370 IDENTIFIER. 372 LDAPOID ::= OCTET STRING 374 For example, 375 1.3.6.1.4.1.1466.1.2.3 377 4.1.3. Distinguished Name and Relative Distinguished Name 379 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 380 representation of a Distinguished Name and a Relative Distinguished 381 Name after encoding according to the specification in [4], such that 383 ::= 385 ::= 387 where and are as defined in [4]. 389 LDAPDN ::= LDAPString 391 RelativeLDAPDN ::= LDAPString 393 4.1.4. Attribute Type and Description 395 An AttributeType takes on as its value the textual string associated 396 with that AttributeType in its specification. This string must begin 397 with a letter, and only contain ASCII letters and digit characters. 398 If this string is not known, the AttributeType should take the ASCII 399 representation of its OBJECT IDENTIFIER, as decimal digits with 400 components separated by periods, e.g., "2.5.4.10". The attribute type 401 strings which are used in this version of LDAP are described in [5]. 403 AttributeType ::= LDAPString 405 An AttributeDescription is a superset of the definition of the 406 AttributeType. It has the same ASN.1 definition, but allows additional 407 options to be specified. 409 AttributeDescription ::= LDAPString 411 A value of AttributeDescription is based on the following BNF: 413 ::= [ ";" ] 415 ::=