idnits 2.17.1 draft-greenblatt-dn-type-00.txt: ** The Abstract section seems to be numbered -(89): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(96): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? ** 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. == There are 3 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 4) being 83 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. ** The abstract seems to contain references ([3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 131 has weird spacing: '...message as p...' == Line 132 has weird spacing: '... of the con...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8374 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: '0' is mentioned on line 71, but not defined == Unused Reference: '2' is defined on line 355, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 360, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (ref. '2') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2256 (ref. '3') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAPEXT Working Group B. Greenblatt 3 Internet Draft Directory Tools and 4 Application 5 Services, Inc. 6 Document: May 2001 7 Category: Standards Track 9 Control for requesting DN object class in LDAP 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 There are many circumstances in LDAP [1] when the result of a Search 32 operation returns attribute values that have the distinguished name 33 (DN) syntax. This document defines controls that allow the client 34 to request that the server tag each DN with its object classes. 35 This is a useful feature because object classes such as groups [3] 36 may hold many DNs, each of which is a potentially different object 37 class. When using this control in a search, the LDAP client request 38 that the server return the object classes of each DN that is an 39 attribute value of the search result. This control also defines a 40 way to limit the kinds of DNs that should be returned in a Search 41 result. 43 2. Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 47 this document are to be interpreted as described in RFC-2119 [5]. 49 3. Control for Requesting Object Class information 51 Greenblatt Standards Track � Expires November 2001 1 52 This control is included in the SearchRequest message as part of the 53 controls field of the LDAPMessage, as defined in Section 4.1.12 of 54 [1]. The controlType is set to "1.3.6.1.4.1.5515.5.1". The 55 criticality SHOULD be set to FALSE. If this control is included in a 56 SearchRequest message, and the server understands the control, then 57 a corresponding control that contains object class information is 58 included in the SearchResultDone message as part of the controls 59 field of the LDAPMessage. The controlValue is an OCTET STRING whose 60 value is the BER-encoding of the following SEQUENCE: 62 DNObjectClassRequest ::= SEQUENCE { 63 listObjectClasses ENUMERATED { 64 all (0), 65 mostSubordinateOnly (1), 66 omitAuxiliary (2), 67 mostSubordinateStructural (3), 68 none (4) 69 } OPTIONAL, 70 CHOICE { 71 dnSelection [0] SEQUENCE OF LDAPString, 72 dnOmission [1] SEQUENCE OF LDAPString 73 } OPTIONAL 74 } 75 Upon receiving this control, a server that supports it MUST process 76 this as a standard LDAPv3 search with the following changes: 78 a) If listObjectClasses is "all" the DNObjectClassResponse request 79 includes all object classes for each DN value in the 80 SearchResult. If listObjectClasses is "mostSubordinateOnly", 81 the DNObjectClassResponse contains only the most specific 82 object class in the entries object class inheritance. For 83 example, if a DN referred to an entry that was the object class 84 of "Person", then the DNObjectClassResponse would only contain 85 the information that the DN was a "person", instead of 86 including the "top" object class information as well. If 87 listObjectClasses is "omitAuxiliary", only the object classes 88 that are included in the DNObjectClassResponse are those in the 89 "structural" object class� inheritance. For example, if a DN 90 referred to an entry that was the object class of "Person" and 91 "StrongAuthenticationUser", then the DNObjectClassResponse 92 would only contain the information that the DN was a "person" 93 and "top". If listObjectClasses is "mostSubordinateStructural", 94 only the object classes that are included in the 95 DNObjectClassResponse is the most specific object class in the 96 "structural" object class� inheritance. For example, if a DN 97 referred to an entry that was the object class of "Person" and 98 "StrongAuthenticationUser", then the DNObjectClassResponse 99 would only contain the information that the DN was a "person". 100 If listObjectClasses is "none" the DNObjectClassResponse does 101 MUST NOT include any information about the object classes of 102 the returned DN values. 103 b) If dnSelection is present it lists the dn values, the object 104 classes of which should be included in the Search Result. The 106 Greenblatt Standards Track 2 107 LDAP Server should process the Search Request normally, but 108 only include those DN values in the returned results which 109 match one of the values in the list of object classes specified 110 in the control. Object class values in the dnSelection that 111 are unknown or invalid are ignored in the processing, but are 112 listed in the ignoredDNValues of the DNObjectClassResponse. 113 c) If dnOmission is present it lists the dn values, the object 114 classes of which should be omitted the Search Result. The LDAP 115 Server should process the Search Request normally, but exclude 116 all of those DN values in the returned results which match one 117 of the values in the list of object classes specified in the 118 control. Object class values in the dnOmission that are 119 unknown or invalid are ignored in the processing, but are 120 listed in the ignoredDNValues of the DNObjectClassResponse. 122 Servers that claim support for this control MUST support the 123 listObjectClasses processing defined above. Support for processing 124 dnSelection and dnOmission is OPTIONAL. Note that the processing of 125 the DNObjectClassRequest never restricts the entries which are 126 returned as a result of the processing of the submitted 127 SearchRequest. 129 4. Control for Responding to Requests for Object Class information 131 This control is included in the SearchRequestDone message as part 132 of the controls field of the LDAPMessage, as defined in 133 Section 4.1.12 of [1]. The controlType is set to 134 "1.3.6.1.4.1.5515.5.2". The controlValue is an OCTET STRING whose 135 value is the BER-encoding of the following SEQUENCE: 137 DNObjectClassResponse ::= SEQUENCE { 138 SEQUENCE OF { 139 entry LDAPDN, 140 objectClassList SEQUENCE of LDAPString 141 }, 142 ignoredDNValues LDAPString, 143 dNObjectClassResult ENUMERATED { 144 success (0), 145 operationsError (1), 146 timeLimitExceeded (3), 147 busy (51), 148 unwillingToPerform (53), 149 dnSelectionOrOmissionIgnored (60) 150 } 152 The dNObjectClassResult codes that are common to the LDAP 153 searchResponse (success, operationsError, timeLimitExceeded, busy, 154 unwillingToPerform) have the same meanings as defined in [1], but 155 they pertain specifically to the DN Object Class Request operation. 156 For example, the server could exceed a time limit processing a 157 SearchRequest with a DNObjectClassRequest control. However, the same 158 time limit would not be exceeded should the client submit the same 160 Greenblatt Standards Track 3 161 SearchRequest without the DNObjectClassRequest control. In this 162 case, the client can determine that a time limit has been exceeded 163 in servicing the DNObjectClassRequest, and can choose to resubmit 164 the SearchRequest without the DNObjectClassRequest control. 166 If the DNObjectClassRequest control includes dnSelection or 167 dnOmission information and the Server only supports the 168 listObjectClasses processing, then the Server MUST return the result 169 code dnSelectionOrOmissionIgnored in the DNObjectClassResponse. 171 5. Examples 173 Assume a Directory Information Tree (DIT) with the following 174 entries: 176 DN Most Subordinate Object Classes 178 O=dtasi.com Organization 180 Ou=sales, o=dtasi.com OrganizationalUnit 182 Ou=eng, o=dtasi.com OrganizationalUnit 184 Uid=bruceg, ou=sales, o=dtasi.com InetOrgPerson 186 Uid=joe, ou=sales, o=dtasi.com InetOrgPerson, 187 StrongAuthenticationUser 189 Uid=mary, ou=sales, o=dtasi.com InetOrgPerson 191 Cn=se, ou=sales, o=dtasi.com GroupOfNames 193 Cn=cs, ou=sales, o=dtasi.com GroupOfNames 195 Uid=tom, ou=eng, o=dtasi.com InetOrgPerson, 196 StrongAuthenticationUser 198 Uid=alice, ou=eng, o=dtasi.com InetOrgPerson, 199 StrongAuthenticationUser 201 Uid=fred, ou=eng, o=dtasi.com InetOrgPerson 203 Uid=elmer, ou=eng, o=dtasi.com InetOrgPerson 205 Cn=support, ou=eng, o=dtasi.com GroupOfNames 207 Cn=qa, ou=eng, o=dtasi.com GroupOfNames 209 Cn=dev, ou=eng, o=dtasi.com GroupOfNames 211 Table 1 - Sample DIT 213 Assume that the Groups in the DIT have the following member 214 attribute values: 216 Group DN Members 218 Cn=se, ou=sales, o=dtasi.com Uid=joe, ou=sales, o=dtasi.com 219 Cn=qa, ou=eng, o=dtasi.com 221 Cn=cs, ou=sales, o=dtasi.com Uid=mary, ou=sales, o=dtasi.com 222 Cn=support, ou=eng, o=dtasi.com 223 Uid=alice, ou=eng, o=dtasi.com 225 Cn=support, ou=eng, o=dtasi.com Uid=alice, ou=eng, o=dtasi.com 226 Uid=bruceg, ou=sales, o=dtasi.com 228 Cn=qa, ou=eng, o=dtasi.com Uid=fred, ou=eng, o=dtasi.com 229 Uid=tom, ou=eng, o=dtasi.com 231 Cn=dev, ou=eng, o=dtasi.com Cn=qa, ou=eng, o=dtasi.com 232 Uid=elmer, ou=eng, o=dtasi.com 234 Table 2 - Group membership information for the Sample DIT 236 Greenblatt Standards Track 4 237 Consider the following Searches: 239 a) Search Base: ou=sales, o=dtasi.com, scope: subtree, filter: 240 "objectClass=groupOfNames", attributes: member. Assume that 241 dnSelection and dnOmission are not present. This search 242 matches all 5 groups in Table 2. Assuming that there are no 243 problems in processing, the contents of the 244 DNObjectClassResponse are: 245 i. If listObjectClasses = "all": Uid=joe, ou=sales, 246 o=dtasi.com: inetOrgPerson, organizationalPerson, Person, 247 top, strongAuthenticationPerson; Cn=qa, ou=eng, 248 o=dtasi.com: groupOfNames, top; Uid=mary, ou=sales, 249 o=dtasi.com: inetOrgPerson, organizationalPerson, Person, 250 top; Cn=support, ou=eng, o=dtasi.com: groupOfNames, top; 251 Uid=alice, ou=eng, o=dtasi.com: inetOrgPerson, 252 organizationalPerson, Person, top, 253 strongAuthenticationUser; 254 ii. If listObjectClasses = "mostSubordinateOnly": Uid=joe, 255 ou=sales, o=dtasi.com: inetOrgPerson, 256 strongAuthenticationPerson; Cn=qa, ou=eng, o=dtasi.com: 257 groupOfNames; Uid=mary, ou=sales, o=dtasi.com: 258 inetOrgPerson; Cn=support, ou=eng, o=dtasi.com: 259 groupOfNames; Uid=alice, ou=eng, o=dtasi.com: 260 inetOrgPerson, strongAuthenticationUser; 261 iii. If listObjectClasses = "omitAuxiliary": Uid=joe, 262 ou=sales, o=dtasi.com: inetOrgPerson, 263 organizationalPerson, Person, top; Cn=qa, ou=eng, 264 o=dtasi.com: groupOfNames, top; Uid=mary, ou=sales, 265 o=dtasi.com: inetOrgPerson, organizationalPerson, Person, 266 top; Cn=support, ou=eng, o=dtasi.com: groupOfNames, top; 267 Uid=alice, ou=eng, o=dtasi.com: inetOrgPerson, 268 organizationalPerson, Person, top; 269 iv. If listObjectClasses = "mostSubordinateStructural": 270 Uid=joe, ou=sales, o=dtasi.com: inetOrgPerson; Cn=qa, 271 ou=eng, o=dtasi.com: groupOfNames; Uid=mary, ou=sales, 272 o=dtasi.com: inetOrgPerson; Cn=support, ou=eng, 273 o=dtasi.com: groupOfNames; Uid=alice, ou=eng, o=dtasi.com: 274 inetOrgPerson; 275 v. If listObjectClases = "none", the DNObjectClassResponse 276 does not contain any object class information 277 b) Search Base: o=dtasi.com, scope: subtree, filter: "member= 278 Uid=alice, ou=eng, o=dtasi.com", attributes: member. Assume 279 that dnSelection is "person", and dnOmission is not present. 280 This search only the 2 groups in Table 2 in which alice is 281 named as a member. The presence of the dnSelection indicates 282 that the SearchResultEntry message only includes those DN 283 attribute values in which the DN refers to an entry that 284 specifies a person object. So, all of the group values of the 285 member attribute that would have been returned if the 286 DNObjectClassRequest had not been specified are omitted from 287 the SearchResultEntry messages. This way, the client is able 288 to ignore the nested groups in the specified group entries. 290 Greenblatt Standards Track 5 291 Assuming that there are no problems in processing, the contents 292 of the DNObjectClassResponse are: 293 i. If listObjectClasses = "all": Uid=mary, ou=sales, 294 o=dtasi.com: inetOrgPerson, organizationalPerson, Person, 295 top; Uid=alice, ou=eng, o=dtasi.com: inetOrgPerson, 296 organizationalPerson, person, top, 297 strongAuthenticationUser; Uid=bruceg, ou=sales, 298 o=dtasi.com: inetOrgPerson, organizationalPerson, person, 299 top; 300 ii. If listObjectClasses = "mostSubordinateOnly": Uid=mary, 301 ou=sales, o=dtasi.com: inetOrgPerson; Uid=alice, ou=eng, 302 o=dtasi.com: inetOrgPerson, strongAuthenticationUser; 303 Uid=bruceg, ou=sales, o=dtasi.com: inetOrgPerson; 304 iii. If listObjectClasses = "omitAuxiliary": Uid=mary, 305 ou=sales, o=dtasi.com: inetOrgPerson, 306 organizationalPerson, Person, top; Uid=alice, ou=eng, 307 o=dtasi.com: inetOrgPerson, organizationalPerson, person, 308 top; Uid=bruceg, ou=sales, o=dtasi.com: inetOrgPerson, 309 organizationalPerson, person, top; 310 iv. If listObjectClasses = "mostSubordinateStructural": 311 Uid=mary, ou=sales, o=dtasi.com: inetOrgPerson; Uid=alice, 312 ou=eng, o=dtasi.com: inetOrgPerson; Uid=bruceg, ou=sales, 313 o=dtasi.com: inetOrgPerson; 314 v. If listObjectClases = "none", the DNObjectClassResponse 315 does not contain any object class information 316 c) Search Base: o=dtasi.com, scope: subtree, filter: "member= 317 Uid=alice, ou=eng, o=dtasi.com", attributes: member. Assume 318 that dnOmission is "person", and dnSelection is not present. 319 This search only the 2 groups in Table 2 in which alice is 320 named as a member. The presence of the dnOmission indicates 321 that the SearchResultEntry message only includes those DN 322 attribute values in which the DN refers to an entry that 323 specifies something other than a person object. So, all of the 324 person values of the member attribute that would have been 325 returned if the DNObjectClassRequest had not been specified are 326 omitted from the SearchResultEntry messages. This way, the 327 client is able to retrieve the nested groups from the specified 328 group entries. Assuming that there are no problems in 329 processing, the contents of the DNObjectClassResponse are: 330 i. If listObjectClasses = "all": Cn=qa, ou=eng, o=dtasi.com: 331 groupOfNames, top; 332 ii. If listObjectClasses = "mostSubordinateOnly": Cn=qa, 333 ou=eng, o=dtasi.com: groupOfNames; 334 iii. If listObjectClasses = "omitAuxiliary": Cn=qa, ou=eng, 335 o=dtasi.com: groupOfNames, top; 336 iv. If listObjectClasses = "mostSubordinateStructural": 337 Cn=qa, ou=eng, o=dtasi.com: groupOfNames; 338 v. If listObjectClases = "none", the DNObjectClassResponse 339 does not contain any object class information 341 6. Security Considerations 343 Greenblatt Standards Track 6 344 This memo describes mechanism to enhance the retrieval of DN 345 values when using LDAP search filters. This mechanism itself has no 346 known security implications. However, LDAP search filters do have 347 security implications, as defined in [1]. LDAP servers should take 348 care to protect the data they maintain from unauthorized access. 350 7. References 352 [1] Wahl, M., Kille, S. and Howes, T., "Lightweight Directory 353 Access Protocol (v3)", Internet Standard, December, 1997. 354 RFC2251. 355 [2] Wahl, M., Coulbeck, A., Howes, T. and Kille, S., "Lightweight 356 Directory Access Protocol (v3), Attribute Syntax Definitions", 357 Internet Standard, December, 1997. RFC2252. 358 [3] Wahl, M., "A Summary of the X.500(96) User Schema for use with 359 LDAPv3", Internet Standard, December, 1997. RFC2256. 360 [4] Crocker, D., and P. Overell, "Augmented BNF for Syntax 361 Specifications: ABNF", RFC 2234, November 191 Bradner, S., "The 362 Internet Standards Process -- Revision 3", BCP 9, RFC 2026, 363 October 1996. 364 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 365 Levels", BCP 14, RFC 2119, March 1997 367 8. Author's Address 369 Bruce Greenblatt 370 Directory Tools and Application Services, Inc. 371 6841 Heaton Moor Drive 372 San Jose, CA 95119 373 Email: bgreenblatt@directory-applications.com 375 Full Copyright Statement 377 "Copyright (C) The Internet Society (date). All Rights Reserved. 378 This document and translations of it may be copied and furnished to 379 others, and derivative works that comment on or otherwise explain it 380 or assist in its implmentation may be prepared, copied, published 381 and distributed, in whole or in part, without restriction of any 382 kind, provided that the above copyright notice and this paragraph 383 are included on all such copies and derivative works. However, this 384 document itself may not be modified in any way, such as by removing 385 the copyright notice or references to the Internet Society or other 386 Internet organizations, except as needed for the purpose of 387 developing Internet standards in which case the procedures for 388 copyrights defined in the Internet Standards process must be 389 followed, or as required to translate it into languages other than 390 English. The limited permissions granted above are perpetual and 391 will not be revoked by the Internet Society or its successors or 392 assigns. 394 This document and the information contained herein is provided on an 395 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 397 Greenblatt Standards Track 7 398 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 399 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 400 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 401 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 403 Greenblatt Standards Track 8