1 2 3 4Network Working Group P. Masarati 5Internet-Draft Politecnico di Milano 6Intended status: Standards Track H. Chu 7Expires: May 23, 2009 Symas Corp. 8 November 19, 2008 9 10 11 LDAP Dereference Control 12 draft-masarati-ldap-deref-00.txt 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on May 23, 2009. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Masarati & Chu Expires May 23, 2009 [Page 1] 56 57Internet-Draft LDAP Deref November 2008 58 59 60Abstract 61 62 This document describes the Dereference Control for LDAP. This 63 control is intended to provide a concise means to collect extra 64 information related to cross-links present in entries returned as 65 part of search responses. 66 67 68Table of Contents 69 70 1. Background and Intended Use . . . . . . . . . . . . . . . . . 3 71 2. The LDAP Dereference Control . . . . . . . . . . . . . . . . . 4 72 2.1. Control Semantics . . . . . . . . . . . . . . . . . . . . 4 73 2.2. Control Request . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Control Response . . . . . . . . . . . . . . . . . . . . . 5 75 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 7 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6.1. Object Identifier Registration . . . . . . . . . . . . . . 9 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . . . 13 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Masarati & Chu Expires May 23, 2009 [Page 2] 112 113Internet-Draft LDAP Deref November 2008 114 115 1161. Background and Intended Use 117 118 Cross-links between entries are often used to describe relationships 119 between entries. To exploit the uniqueness of entries naming, these 120 links are usually represented by the distinguished name (DN) of the 121 linked entries. 122 123 In many cases, DUAs need to collect information about linked entries. 124 This requires to explicitly dereference each linked entry in order to 125 collect the desired attributes, resulting in the need to perform a 126 specific sequence of search operations, using the links as search 127 base, with a SearchRequest.scope of baseObject [RFC4511]. 128 129 This document describes a LDAP Control [RFC4511] that allows a DUA to 130 request the DSA to return specific attributes of linked entries along 131 with the link, under the assumption that this operation can be 132 performed by the DSA in a more efficient manner than the DUA would 133 itself by performing the complete sequence of required search 134 operations. 135 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Masarati & Chu Expires May 23, 2009 [Page 3] 168 169Internet-Draft LDAP Deref November 2008 170 171 1722. The LDAP Dereference Control 173 1742.1. Control Semantics 175 176 This control allows specifying a dereference attribute and a set of 177 attributes to be dereferenced, as illustrated in Section 2.2. The 178 dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12 179 (DN) [RFC4517]. Each value of the dereference attribute in a 180 SearchResultEntry SHOULD result in dereferencing the corresponding 181 entry, collecting the values of the attributes to be dereferenced, 182 and returning them as part of the control value in the 183 SearchResultEntry response, in the format detailed in Section 2.3. 184 185 The control value may contain dereference attribute values without 186 any dereferenced attribute values, as detailed in Section 2.3. The 187 control semantics does not specify whether this is a consequence of a 188 dangling link or of the application of access restrictions on the 189 values of the attributes to be dereferenced. 190 191 Attribute description hierarchy [RFC4512] SHALL NOT be exploited when 192 collecting the values of the attributes to be dereferenced. On the 193 contrary, all of the attribute descriptions in an attribute hierarchy 194 SHOULD be treated as distinct and unrelated descriptions. 195 196 This control is only appropriate for the search operation [RFC4511]. 197 198 The semantics of the criticality field are specified in [RFC4511]. 199 In detail, the criticality of the control determines whether the 200 control will or will not be used, and if it will not be used, whether 201 the operation will continue without returning the control in the 202 response, or fail, returning unavailableCriticalExtension. If the 203 control is appropriate for an operation and, for any reason, it 204 cannot be applied in its entirety to a single SearchResultEntry 205 response, it MUST NOT be applied to that specific SearchResultEntry 206 response, without affecting its application to any subsequent 207 SearchResultEntry response. 208 209 Servers implementing this technical specification SHOULD publish the 210 object identifier deref-oid (IANA assigned; see Section 6) as a value 211 of the 'supportedControl' attribute [RFC4512] in their root DSE. 212 213 This control is totally unrelated to alias dereferencing [RFC4511]. 214 215 216 217 218 219 220 221 222 223Masarati & Chu Expires May 23, 2009 [Page 4] 224 225Internet-Draft LDAP Deref November 2008 226 227 2282.2. Control Request 229 230 The control type is deref-oid (IANA assigned; see Section 6). The 231 specification of the Dereference Control request is: 232 233 controlValue ::= SEQUENCE OF derefSpec DerefSpec 234 235 DerefSpec ::= SEQUENCE { 236 derefAttr attributeDescription, ; with DN syntax 237 attributes AttributeList } 238 239 AttributeList ::= SEQUENCE OF attr AttributeDescription 240 241 Each derefSpec.derefAttr MUST be unique within controlValue. 242 2432.3. Control Response 244 245 The control type is deref-oid (IANA assigned; see Section 6). The 246 specification of the Dereference Control response is: 247 248 controlValue ::= SEQUENCE OF derefRes DerefRes 249 250 DerefRes ::= SEQUENCE { 251 derefAttr AttributeDescription, 252 derefVal LDAPDN, 253 attrVals [0] PartialAttributeList OPTIONAL } 254 255 PartialAttributeList ::= SEQUENCE OF 256 partialAttribute PartialAttribute 257 258 PartialAttribute is defined in [RFC4511]; the definition is reported 259 here for clarity: 260 261 PartialAttribute ::= SEQUENCE { 262 type AttributeDescription, 263 vals SET OF value AttributeValue } 264 265 If partialAttribute.vals is empty, the corresponding partialAttribute 266 is omitted. If all partialAttribute.vals in attrVals are empty, that 267 derefRes.attrVals is omitted. 268 269 270 271 272 273 274 275 276 277 278 279Masarati & Chu Expires May 23, 2009 [Page 5] 280 281Internet-Draft LDAP Deref November 2008 282 283 2843. Examples 285 286 Given these entries: 287 288 dn: cn=Howard Chu,ou=people,dc=example,dc=org 289 objectClass: inetOrgPerson 290 cn: Howard Chu 291 sn: Chu 292 uid: hyc 293 294 dn: cn=Pierangelo Masarati,ou=people,dc=example,dc=org 295 objectClass: inetOrgPerson 296 cn: Pierangelo Masarati 297 sn: Masarati 298 uid: ando 299 300 dn: cn=Test Group,ou=groups,dc=example,dc=org 301 objectClass: groupOfNames 302 cn: Test Group 303 member: cn=Howard Chu,ou=people,dc=example,dc=org 304 member: cn=Pierangelo Masarati,ou=people,dc=example,dc=org 305 306 A search could be performed with a Dereference request control value 307 specified as 308 309 { member, uid } 310 311 and the "cn=Test Group" entry would be returned with the response 312 control value 313 314 { { member, cn=Howard Chu,ou=people,dc=example,dc=org, 315 { { uid, [hyc] } } }, 316 { member, cn=Pierangelo Masarati,ou=people,dc=example,dc=org, 317 { { uid, [ando] } } } } 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Masarati & Chu Expires May 23, 2009 [Page 6] 336 337Internet-Draft LDAP Deref November 2008 338 339 3404. Implementation Notes 341 342 This LDAP extension is currently implemented in OpenLDAP software 343 using the temporary OID 1.3.6.1.4.1.4203.666.5.16 under OpenLDAP's 344 experimental OID arc. 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Masarati & Chu Expires May 23, 2009 [Page 7] 392 393Internet-Draft LDAP Deref November 2008 394 395 3965. Security Considerations 397 398 The control result MUST NOT disclose information the client's 399 identity could not have accessed by performing the related search 400 operations. The presence of a derefRes.derefVal in the response 401 control, with no derefRes.attrVals, does not imply neither the 402 existence of nor any access privilege to the corresponding entry. It 403 is merely a consequence of the read access the client's identity has 404 on the corresponding value of the derefRes.derefAttr that would be 405 returned as part of the attributes of a SearchResultEntry response 406 [RFC4511]. 407 408 Security considerations described in documents listed in [RFC4510] 409 apply. 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Masarati & Chu Expires May 23, 2009 [Page 8] 448 449Internet-Draft LDAP Deref November 2008 450 451 4526. IANA Considerations 453 4546.1. Object Identifier Registration 455 456 It is requested that IANA register upon Standards Action an LDAP 457 Object Identifier for use in this technical specification. 458 459 Subject: Request for LDAP OID Registration 460 Person & email address to contact for further information: 461 Pierangelo Masarati <ando@OpenLDAP.org> 462 Specification: (I-D) 463 Author/Change Controller: IESG 464 Comments: 465 Identifies the LDAP Dereference Control request 466 and response 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Masarati & Chu Expires May 23, 2009 [Page 9] 504 505Internet-Draft LDAP Deref November 2008 506 507 5087. Acknowledgments 509 510 TBD 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Masarati & Chu Expires May 23, 2009 [Page 10] 560 561Internet-Draft LDAP Deref November 2008 562 563 5648. Normative References 565 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 569 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 570 (LDAP): Technical Specification Road Map", RFC 4510, 571 June 2006. 572 573 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 574 (LDAP): The Protocol", RFC 4511, June 2006. 575 576 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 577 (LDAP): Directory Information Models", RFC 4512, 578 June 2006. 579 580 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 581 Syntaxes and Matching Rules", RFC 4517, June 2006. 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Masarati & Chu Expires May 23, 2009 [Page 11] 616 617Internet-Draft LDAP Deref November 2008 618 619 620Authors' Addresses 621 622 Pierangelo Masarati 623 Politecnico di Milano 624 Dipartimento di Ingegneria Aerospaziale 625 via La Masa 34 626 Milano 20156 627 IT 628 629 Phone: +39 02 2399 8309 630 Fax: +39 02 2399 8334 631 Email: ando@OpenLDAP.org 632 URI: http://www.aero.polimi.it/masarati/ 633 634 635 Howard Y. Chu 636 Symas Corporation 637 18740 Oxnard St., Suite 313A 638 Tarzana, California 91356 639 USA 640 641 Phone: +1 818 757-7087 642 Email: hyc@symas.com 643 URI: http://www.symas.com/ 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Masarati & Chu Expires May 23, 2009 [Page 12] 672 673Internet-Draft LDAP Deref November 2008 674 675 676Full Copyright Statement 677 678 Copyright (C) The IETF Trust (2008). 679 680 This document is subject to the rights, licenses and restrictions 681 contained in BCP 78, and except as set forth therein, the authors 682 retain all their rights. 683 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 691 692 693Intellectual Property 694 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 703 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 710 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 716 717 718 719 720 721 722 723 724 725 726 727Masarati & Chu Expires May 23, 2009 [Page 13] 728 729