idnits 2.17.1 draft-zeilenga-ldapbis-vd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 450 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (1 April 2001) is 8425 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2596' is mentioned on line 178, but not defined ** Obsolete undefined reference: RFC 2596 (Obsoleted by RFC 3866) == Missing Reference: 'RFC2849' is mentioned on line 341, but not defined == Unused Reference: 'RFC1960' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC2255' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC2256' is defined on line 426, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1778 (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1960 (Obsoleted by RFC 2254) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) ** Obsolete normative reference: RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) Summary: 20 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Informational OpenLDAP Foundation 4 Expires: 1 October 2001 1 April 2001 6 Lightweight Directory Access Protocol: Version Differences 7 draft-zeilenga-ldapbis-vd-02 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as an Informational document. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF LDAP Revision Working Group 16 (LDAPbis) mailing list . Please send 17 editorial comments directly to the author . 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working 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 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 29 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 31 Copyright 2001, The Internet Society. All Rights Reserved. 33 Please see the Copyright section near the end of this document for 34 more information. 36 1. Overview 38 This document details differences between Lightweight Directory Access 39 Protocol versions 2 [RFC1777] (LDAPv2) and 3 [RFC2251] (LDAPv3). 41 There has been significant interest within the community to develop 42 applications which implement both LDAPv2 and LDAPv3. These are 43 referred to as "dual" implementations in this document. This document 44 discusses issues specific to dual implementations. 46 2. X.500 Issues 48 LDAPv2 is defined in terms of X.500(1988) series of ITU 49 Recommendations whereas LDAPv3 is defined in terms of the X.500(1993) 50 series. There are significant differences between X.500(1988) and 51 X.500(1993). 53 2.1. Directory Strings 55 The X.520(1988) directoryString is defined as: 57 DirectoryString { INTEGER : maxSize } ::= CHOICE { 58 teletexString TeletexString (SIZE (1..maxSize)), 59 printableString PrintableString (SIZE (1..maxSize)) } 61 LDAPv2 requires that the encoding of values of the directoryString 62 syntax is the string value itself [RFC1778]. As each choice was a 63 subset of the T.61, the transferred value is restricted to T.61. 65 A choice of universalString was added in the X.500(1993). LDAPv2 66 implementations which support this choice should transliterate values 67 to TeletexString (T.61). 69 LDAPv3 requires that values of directoryString syntax be encoded as 70 ISO 10646-1 UTF-8 strings [RFC2252]. DirectoryString values of 71 teletexString choice should be transliterated to UTF-8. 73 A dual implementation must be able to transliterate strings between 74 ISO 10646-1 and T.61 or restrict strings to common subset of both 75 (e.g. IA5). 77 2.2. Attribute type 79 X.500(1988) makes no distinction between user, operational, and 80 collective attributes whereas X.500(1993) does. Hence, LDAPv2 makes 81 no distinction whereas LDAPv3 does. 83 For example, a LDAPv2 search request with an empty attribute list 84 returns all attributes whereas LDAPv3 only returns all user 85 attributes. LDAPv3 only returns operational attributes unless 86 specifically requested, whereas LDAPv2 has no such restriction. 88 X.500(1993) also states that a search "request for a particular 89 attribute is always treated as a request for the attribute and all 90 subtypes of that attribute (except for requests processed by 91 1988-edition systems)". LDAPv2 does not support subtyping whereas 92 LDAPv3 does (though it is optional). 94 2.3. Object Classes 96 X.500(1988) makes no distinction between structural, auxiliary, and 97 abstract object classes whereas X.500(1993) does. Hence, LDAPv2 makes 98 no distinction whereas LDAPv3 does. 100 2.3. ExtensibleMatch 102 X.500(1993) introduces extensible matching. LDAPv2 does not support 103 extensible matching, LDAPv3 does. 105 3. Protocol elements 107 LDAPv3 supports all protocol elements of LDAPv2. LDAPv3, besides 108 defining additional protocol elements, alters the syntax and semantics 109 of existing protocol elements. 111 3.1. LDAPString 113 The LDAPString is a notational convenience to indicate that, although 114 strings of LDAPString type encode as OCTET STRING types, the legal 115 character set in such strings is restricted. LDAPv2 restricts 116 LDAPString to IA5 (ASCII) characters. LDAPv3 restricts LDAPString to 117 UTF-8 encoded ISO 10646-1 characters. The change to UTF-8 allows 118 internationalized strings. 120 For example, an LDAPv3 server can provide localized errorMessage 121 textual error diagnostic using ISO 10646-1 characters. LDAPv2 122 errorMessages are restricted to IA5. 124 A number of protocol fields are restricted by LDAPString. In most 125 cases, this is not problematic for dual implementations as LDAPv3 126 often restricts these fields to IA5 subset of UTF-8 by other means. 127 For instance, attributeType which is an LDAPString is specifically 128 restricted to a subset of IA5. 130 3.2. Distinguished Names 132 DNs are restricted to IA5 when transferred by LDAPv2 and are 133 restricted to UTF-8 when transferred by LDAPv3 as DNs. 135 LDAPv2 DN [RFC1779] syntax does not support escaping of arbitrary 136 characters within values. The BER encoding mechanism must be used for 137 all attribute values contain any non-IA5 characters. LDAPv3 DN 138 [RFC2253] syntax supports escaping of arbitrary characters. 140 LDAPv2 and LDAPv3 special character escaping requirements are 141 different. 143 LDAPv2 set of valid "keywords" is different from the set defined for 144 LDAPv3. LDAPv2 keywords can contain spaces, LDAPv3 keywords cannot. 146 LDAPv2 and LDAPv3 DNs use incompatible mechanisms for specifying 147 attribute types by OIDs. 149 RFC 2253, Section 4 details additional requirements for LDAPv2 150 implementations. However, these requirements are too restrictive as 151 they disallow encoding of a DN in a number of cases (such as when OIDs 152 must be used). The requirements also do not account for the fact that 153 encodings produced per RFC 2253, Section 2 may not be transferable in 154 an LDAPv2 LDAPString or may contain elements (such as hex pair 155 escaping) not allowed by RFC 1779 grammar. 157 A dual implementation should: 158 - parse and generate LDAPv2 DNs per RFC 1779, 159 - parse and generate LDAPv3 DNs per RFC 2253, 160 - convert between LDAPv2 and LDAPv3 DN representations though 161 intermediate conversion to the DN's BER encoding. 163 3.4. AttributeDescription 165 LDAPv3 supports AttributeDescription options, LDAPv2 does not. An 166 LDAPv2 implementation has no mechanism to transfer attribute types 167 with options including the binary transfer and language tag options. 169 LDAPv3 requires certain attributes to be transferred using ";binary". 170 LDAPv2 requires these attributes to be transferred using their string 171 encoding. A dual server should be prepared to convert between a 172 syntax's string and binary encodings. It should be noted that certain 173 syntaxes, such as certificate, have protocol specific requirements 174 which restrict possible conversions. 176 LDAPv2 has no mechanism to support attribute descriptions containing 177 language tags. Applications requiring use of language tags should use 178 LDAPv3 and [RFC2596]. 180 3.5. AttributeDescriptionList 181 LDAPv2 has no special "*" to indicate transfer of all user attributes 182 (see section 2). An LDAPv2 client requesting "*" should expect a 183 protocolError to be returned. 185 3.6. ExtensibleMatch 187 LDAPv3 Filter supports a choice of extensibleMatch. An LDAPv2 does 188 not. A LDAPv2 implementation would likely treat an unknown filter 189 choice as a protocol error. 191 3.7. Empty 'or' and 'and' filters sets 193 LDAPv3 requires 'and' and 'or' filter sets to be non-empty. LDAPv2 194 does not explicitly require filter sets to be non-empty and support 195 for non-empty sets is implied by the statement that an X.500 "read" 196 operation can be emulated by a base object LDAP search operation with 197 the same filter. As X.500(1988) supports 'and' and 'or' empty filters 198 sets, it is reasonable to expect some LDAPv2 servers may also support 199 filters with empty 'and' and 'or' sets. However, as defined filter 200 string representation cannot represent an empty filter set, support 201 for empty filter sets cannot be presumed to be present. Dual 202 implementations should avoid empty 'or' and 'and' filter sets. 204 3.8. LDAPResult 206 LDAPv3 extends LDAPResult to allow additional resultCode values and 207 the inclusion of an optional referral field. LDAPv3 also requires 208 that unknown result codes be treated as unknown error condition 209 LDAPv2 does not have any such requirement. 211 3.9. Unrecognized Tags 213 LDAPv3 implementations must ignore elements of SEQUENCE encodings 214 whose tags they do not recognize. LDAPv2 does not have any such 215 requirement. A LDAPv2 implementation will likely treat an 216 unrecognized as protocol error. 218 3.10. Controls 220 LDAPv3 introduces Controls which may alter the behavior of operations. 221 LDAPv2 does not support Controls. A LDAPv2 implementation will likely 222 treat a control as a protocol error. 224 3.11. New LDAP Message Types 226 LDAPv3 introduces three new LDAP PDU choices: extended requests, 227 extended responses, and search reference responses. LDAPv2 does not 228 support these new PDUs and likely will treat such as a protocol error. 230 4. Protocol Semantics 232 This section details semantical differences in the protocols. 234 4.1. Bind Operation 236 Per RFC 1777, the LDAPv2 Bind operation is used to initiate a session. 237 It must be the first operation and cannot be used subsequently. 238 However, many LDAPv2 implementations do not require use of the Bind 239 operation to initiate a session. A dual implementation MUST treat a 240 session without an initial Bind operation as LDAPv3. This may result 241 in interoperability problems with clients which do not strictly adhere 242 to the LDAPv2 specifications. 244 4.2. Search Operation 246 LDAPv3 search operation can return in addition to entries, references 247 and extended responses. LDAPv2 search operation can only entries. A 248 dual server implementation should be prepared to chain requests to 249 other servers as LDAPv2 has no mechanism to return search references. 251 4.3. Modify Operation 253 LDAPv3 alters the semantics of the Modify/replace. In LDAPv2, a 254 replace with no values commonly results in a protocolError. In 255 LDAPv3, a replace with no values is treated as a delete with no values 256 excepting no error is generated if the attribute does not exist. 258 4.4. Unsolicited Notifications 260 LDAPv2 implementations do not support Unsolicited Notifications. A 261 dual implementation should avoid returning an Unsolicited Notification 262 until it has obtained a request has been received and this request is 263 not a LDAPv2 bind request. 265 5. Protocol Encoding 266 LDAPv3 places additional restrictions on the BER encoding of protocol 267 elements. 269 6. Schema 271 LDAPv2 and LDAPv3 schema is dramatically different. 273 6.1 Syntaxes 275 6.1.1. Common Syntax Encodings 277 An number of BNF definitions differ between LDAPv2 and LDAPv3. 279 LDAPv3 allows ";" in the production k whereas LDAPv2 does not. 280 Production k is used by production anhstring. 282 LDAPv3 allows """ in the production p whereas LDAPv2 does not. LDAPv2 283 allows "'" in the production p whereas LDAPv3 does not. Production p 284 is used by production printablestring. 286 The differences in these productions affects the specification of many 287 common syntaxes. A dual implementation must ensure produces values 288 which are consistent with the syntax restrictions of the protocol in 289 use. 291 6.1.2. Object Identifier Syntax 293 LDAPv2 and LDAPv3 use different string representations for object 294 identifier (OIDs) syntax. LDAPv2 defines an OID to be: 296 oid = / '.' / 298 whereas LDAPv3 defines an OID to be: 300 oid = descr / numericoid 302 LDAPv3 eliminates the mixed descr-numeric form. 304 In LDAPv2, when encoding the object identifier representing an 305 organizationName, the descriptor "organizationName" is preferable to 306 "ds.4.10", which is in turn preferable to the string "2.5.4.10". 308 In LDAPv3, when encoding the object identifier representing an 309 organization name (o), the descriptor "o" is preferred to the string 310 "2.5.4.20. 312 A dual implementation must ensure it does not produce the eliminated 313 form when using LDAPv3. Also note that LDAPv2 and LDAPv3 often use 314 different descriptors for some schema elements. 316 6.1.3. Distinguished Name Syntax 318 The issues discussed in Section 3.2 generally apply to values of 319 Distinguished Name syntax. 321 6.1.4. Certificate and related syntaxes 323 LDAPv2 defines a string representation for X.509 certificates, 324 revocation lists, and other related syntaxes. LDAPv3 does not use 325 these string representation and instead requires ";binary" transfer of 326 such values. LDAPv2 does not support ";binary" transfer. 328 Dual implementations must be prepared to recognize and generate the 329 encoding required by the protocol. 331 6.2. Attribute Types 333 LDAPv2, in general, uses X.500 names such as commonName and 334 organizationalName. LDAPv3 uses short names such as cn and o. Dual 335 implementations should use attribute names appropriate for the 336 protocol session. 338 7. Other Version Differences 340 Many LDAP applications use LDIF as an intermediate format. LDIFv1 341 [RFC2849] is designed specifically for LDAPv3. LDIFv0 [SLAPD] was 342 designed for LDAPv2, but often used with LDAPv3. Neither format 343 provides any information regarding which the protocol version 344 associated with the presented data. 346 8. Liberties Taken 348 Dual implementations of LDAPv2 and LDAPv3 have taken significant 349 liberties to support both protocols. The most common liberties taken 350 are to apply the restrictions of one protocol to the other. For 351 example, it is common for dual implementations to ignore the LDAPv2 352 LDAPString IA5 restriction and/or the LDAPv2 directoryString T.61 353 restriction. These taking of such liberties have lead to 354 interoperability problems. Implementors should be strict in what the 355 produce. 357 9. Security Considerations 359 LDAPv3 supports SASL [RFC2829] and TLS [RFC2830]. LDAPv2 does not 360 offer integrity or confidentiality services. LDAPv2 Kerberos bind 361 choices are not widely nor consistently implemented. Use of LDAPv3 362 with appropriate confidentiality protections should be used when 363 updating the directory. 365 10. Summary 367 There are numerous differences between LDAPv2 and LDAPv3 which make it 368 very difficult for an application to properly support both protocols. 370 11. Author's Address 372 Kurt D. Zeilenga 373 OpenLDAP Foundation 375 Email: Kurt@OpenLDAP.org 377 12. References 379 [X.500] "The Directory -- Overview of Concepts, Models and 380 Services," ITU-T Rec. X.500(1993). 382 [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993). 384 [X.511] "The Directory: Abstract Service Definition", ITU-T Rec. 385 X.511(1993). 387 [RFC1777] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory 388 Access Protocol", RFC 1777, March 1995. 390 [RFC1778] T. Howes, S. Kille, W. Yeong, C. Robbins, "The String 391 Representation of Standard Attribute Syntaxes", RFC 1778, 392 March 1995. 394 [RFC1779] S. Kille, "A String Representation of Distinguished Names", 395 RFC 1779, March 1995. 397 [RFC1960] T. Howes, "A String Representation of LDAP Search Filters", 398 RFC 1960, June 1996. 400 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 401 Requirement Levels", RFC 2119. 403 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 404 Specifications: ABNF", RFC 2234, November 1997. 406 [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", 407 RFC 2279, January 1998. 409 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 410 Protocol (v3)", RFC 2251, December 1997. 412 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 413 Directory Access Protocol (v3): Attribute Syntax 414 Definitions", RFC 2252, December 1997. 416 [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 417 Protocol (v3): UTF-8 String Representation of Distinguished 418 Names", RFC 2253, December 1997. 420 [RFC2254] T. Howes, "A String Representation of LDAP Search Filters", 421 RFC 2254, December 1997. 423 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, 424 December, 1997. 426 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use 427 with LDAPv3", RFC 2256, December 1997. 429 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, 430 "Authentication Methods for LDAP", RFC 2829, June 2000. 432 [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory 433 Access Protocol (v3): Extension for Transport Layer 434 Security", RFC 2830, May 2000. 436 [SLAPD] The SLAPD and SLURPD Administrators Guide. University of 437 Michigan, April 1996. 440 Copyright 2001, The Internet Society. All Rights Reserved. 442 This document and translations of it may be copied and furnished to 443 others, and derivative works that comment on or otherwise explain it 444 or assist in its implementation may be prepared, copied, published and 445 distributed, in whole or in part, without restriction of any kind, 446 provided that the above copyright notice and this paragraph are 447 included on all such copies and derivative works. However, this 448 document itself may not be modified in any way, such as by removing 449 the copyright notice or references to the Internet Society or other 450 Internet organizations, except as needed for the purpose of 451 developing Internet standards in which case the procedures for 452 copyrights defined in the Internet Standards process must be followed, 453 or as required to translate it into languages other than English. 455 The limited permissions granted above are perpetual and will not be 456 revoked by the Internet Society or its successors or assigns. 458 This document and the information contained herein is provided on an 459 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 460 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 461 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 462 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.