1 2 3 4Network Working Group P. Masarati 5Internet-Draft Politecnico di Milano 6Intended status: Standards Track November 19, 2008 7Expires: May 23, 2009 8 9 10 LDAP "What Failed?" Control 11 draft-masarati-ldap-whatfailed-00.txt 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on May 23, 2009. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Masarati Expires May 23, 2009 [Page 1] 56 57Internet-Draft LDAP WHATFAILED November 2008 58 59 60Abstract 61 62 This document describes the LDAP "What Failed?" control. This 63 control allows DUAs to request, in response to a failed operation 64 request, the object identifier of those extensions that caused the 65 operation to fail. 66 67 68Table of Contents 69 70 1. Background and Intended Use . . . . . . . . . . . . . . . . . 3 71 2. LDAP "What Failed?" Control . . . . . . . . . . . . . . . . . 4 72 2.1. Control Semantics . . . . . . . . . . . . . . . . . . . . 4 73 2.2. Control Request . . . . . . . . . . . . . . . . . . . . . 4 74 2.3. Control Response . . . . . . . . . . . . . . . . . . . . . 5 75 3. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. Object Identifier Registration . . . . . . . . . . . . . . 8 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 Expires May 23, 2009 [Page 2] 112 113Internet-Draft LDAP WHATFAILED November 2008 114 115 1161. Background and Intended Use 117 118 The LDAP Protocol [RFC4510] is extensible. Extensions include 119 controls, extended requests and extensions related to other aspects 120 of the protocol, for example those described in [RFC4526], [RFC4529] 121 and more. 122 123 Operations may fail for different reasons. The resultCode may help 124 in determining the reason of a failure. The (optional) 125 diagnosticsMessage fields of a LDAPResponse could also be of help. 126 However, according to [RFC4511], implementations MUST NOT rely on the 127 returned values, which are simply intended to be presented as are to 128 human users. 129 130 In case of failure related to the inability to process a control 131 marked as critical in a request, the specific resultCode 132 unavailableCriticalExtension is returned. In case of failure related 133 to an unrecognized extendedReq, the generic resultCode protocolError 134 is returned. Failures related to handling other extensions may 135 result in other generic resultCode values. 136 137 As a consequence, DUAs may be unable to exactly determine what 138 extension, if any, caused a failure. The "What Failed?" control 139 represents a means for the DSA to inform DUAs about what specific 140 extensions, if any, caused an error notified by the DSA. 141 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Masarati Expires May 23, 2009 [Page 3] 168 169Internet-Draft LDAP WHATFAILED November 2008 170 171 1722. LDAP "What Failed?" Control 173 1742.1. Control Semantics 175 176 The presence of the "What Failed?" LDAP control in a LDAP request 177 indicates that the DUA, in case of error, wishes to receive detailed 178 information about what extension, if any, caused the error. 179 180 The criticality of the control in the request SHOULD be FALSE. 181 According to the semantics of the criticality field as indicated in 182 [RFC4511], this ensures that in case the control is not recognized by 183 the DSA, it does not cause itself an error. 184 185 The presence of this control in a request does not guarantee that the 186 DSA will return detailed information about what extensions caused an 187 error. Considering the requirement on the criticality of the 188 control, the DSA MAY simply choose to ignore the control. The DSA 189 MAY hide information about failure in handling an extension to 190 prevent disclosure of other information. The DSA MAY choose to 191 notify an error as soon as it is detected, instead of proceed 192 checking its ability to handle any other extension present in a 193 request. 194 195 Implementations may choose to check the validity of extensions, 196 including controls, as soon as they are parsed. As a consequence, a 197 critical control might result in an error before thw "What Failed?" 198 control request is parsed. Implementations SHOULD check anyway the 199 presence of this control, unless they detect that the remaining part 200 of the request is malformed. Clients SHOULD NOT rely on any specific 201 ordering of controls handling when requesting the "What Failed?" 202 control. 203 204 Servers implementing this technical specification SHOULD publish the 205 object identifier whatFailed-oid (IANA assigned; see Section 5) as a 206 value of the 'supportedControl' attribute [RFC4512] in their root 207 DSE. 208 2092.2. Control Request 210 211 The controlType is whatFailed-oid (IANA assigned; see Section 5); the 212 controlValue MUST be absent; the criticality SHOULD be FALSE. 213 214 215 216 217 218 219 220 221 222 223Masarati Expires May 23, 2009 [Page 4] 224 225Internet-Draft LDAP WHATFAILED November 2008 226 227 2282.3. Control Response 229 230 The controlType is whatFailed-oid (IANA assigned; see Section 5); the 231 controlValue is: 232 233 controlValue ::= SET OF oid LDAPOID 234 235 If the set of extension OID is empty, the control is omitted from the 236 response. The criticality MUST be FALSE. 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Masarati Expires May 23, 2009 [Page 5] 280 281Internet-Draft LDAP WHATFAILED November 2008 282 283 2843. Implementation Notes 285 286 The "What Failed?" LDAP Control is implemented in OpenLDAP software 287 using the temporary OID 1.3.6.1.4.1.4203.666.5.17 under OpenLDAP's 288 experimental OID arc. 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Masarati Expires May 23, 2009 [Page 6] 336 337Internet-Draft LDAP WHATFAILED November 2008 338 339 3404. Security Considerations 341 342 Implementations MUST take measures to prevent the disclosure of 343 sensible information whenever this may result from disclosing what 344 extension caused an error. This can consist in excluding the OID of 345 specific extensions from the controlValue in the response, or in 346 entirely omitting the control in the response. 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 Expires May 23, 2009 [Page 7] 392 393Internet-Draft LDAP WHATFAILED November 2008 394 395 3965. IANA Considerations 397 3985.1. Object Identifier Registration 399 400 It is requested that IANA register upon Standards Action an LDAP 401 Object Identifier for use in this technical specification. 402 403 Subject: Request for LDAP OID Registration 404 Person & email address to contact for further information: 405 Pierangelo Masarati <ando@OpenLDAP.org> 406 Specification: (I-D) 407 Author/Change Controller: IESG 408 Comments: 409 Identifies the LDAP "What Failed?" Control request 410 and response 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 Expires May 23, 2009 [Page 8] 448 449Internet-Draft LDAP WHATFAILED November 2008 450 451 4526. Acknowledgments 453 454 455 456 457 458 459 460 461 462 463 464 465 466 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 Expires May 23, 2009 [Page 9] 504 505Internet-Draft LDAP WHATFAILED November 2008 506 507 5087. References 509 5107.1. Normative References 511 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 515 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 516 (LDAP): Technical Specification Road Map", RFC 4510, 517 June 2006. 518 519 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 520 (LDAP): The Protocol", RFC 4511, June 2006. 521 522 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 523 (LDAP): Directory Information Models", RFC 4512, 524 June 2006. 525 5267.2. Informative References 527 528 [RFC4526] Zeilenga, K., "Lightweight Directory Access Protocol 529 (LDAP) Absolute True and False Filters", RFC 4526, 530 June 2006. 531 532 [RFC4529] Zeilenga, K., "Requesting Attributes by Object Class in 533 the Lightweight Directory Access Protocol", RFC 4529, 534 June 2006. 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 Expires May 23, 2009 [Page 10] 560 561Internet-Draft LDAP WHATFAILED November 2008 562 563 564Author's Address 565 566 Pierangelo Masarati 567 Politecnico di Milano 568 Dipartimento di Ingegneria Aerospaziale 569 via La Masa 34 570 Milano 20156 571 IT 572 573 Phone: +39 02 2399 8309 574 Fax: +39 02 2399 8334 575 Email: ando@OpenLDAP.org 576 URI: http://www.aero.polimi.it/masarati/ 577 578 579 580 581 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 Expires May 23, 2009 [Page 11] 616 617Internet-Draft LDAP WHATFAILED November 2008 618 619 620Full Copyright Statement 621 622 Copyright (C) The IETF Trust (2008). 623 624 This document is subject to the rights, licenses and restrictions 625 contained in BCP 78, and except as set forth therein, the authors 626 retain all their rights. 627 628 This document and the information contained herein are provided on an 629 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 630 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 631 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 632 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 635 636 637Intellectual Property 638 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 647 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 654 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org. 660 661 662 663 664 665 666 667 668 669 670 671Masarati Expires May 23, 2009 [Page 12] 672 673