4 Network Working Group P. Masarati
5 Internet-Draft Politecnico di Milano
6 Intended status: Standards Track H. Chu
7 Expires: May 23, 2009 Symas Corp.
11 LDAP Dereference Control
12 draft-masarati-ldap-deref-00.txt
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.
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-
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."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on May 23, 2009.
55 Masarati & Chu Expires May 23, 2009 [Page 1]
57 Internet-Draft LDAP Deref November 2008
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.
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
111 Masarati & Chu Expires May 23, 2009 [Page 2]
113 Internet-Draft LDAP Deref November 2008
116 1. Background and Intended Use
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
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].
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
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].
167 Masarati & Chu Expires May 23, 2009 [Page 3]
169 Internet-Draft LDAP Deref November 2008
172 2. The LDAP Dereference Control
174 2.1. Control Semantics
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.
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.
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.
196 This control is only appropriate for the search operation [RFC4511].
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.
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.
213 This control is totally unrelated to alias dereferencing [RFC4511].
223 Masarati & Chu Expires May 23, 2009 [Page 4]
225 Internet-Draft LDAP Deref November 2008
230 The control type is deref-oid (IANA assigned; see Section 6). The
231 specification of the Dereference Control request is:
233 controlValue ::= SEQUENCE OF derefSpec DerefSpec
235 DerefSpec ::= SEQUENCE {
236 derefAttr attributeDescription, ; with DN syntax
237 attributes AttributeList }
239 AttributeList ::= SEQUENCE OF attr AttributeDescription
241 Each derefSpec.derefAttr MUST be unique within controlValue.
243 2.3. Control Response
245 The control type is deref-oid (IANA assigned; see Section 6). The
246 specification of the Dereference Control response is:
248 controlValue ::= SEQUENCE OF derefRes DerefRes
250 DerefRes ::= SEQUENCE {
251 derefAttr AttributeDescription,
253 attrVals [0] PartialAttributeList OPTIONAL }
255 PartialAttributeList ::= SEQUENCE OF
256 partialAttribute PartialAttribute
258 PartialAttribute is defined in [RFC4511]; the definition is reported
261 PartialAttribute ::= SEQUENCE {
262 type AttributeDescription,
263 vals SET OF value AttributeValue }
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.
279 Masarati & Chu Expires May 23, 2009 [Page 5]
281 Internet-Draft LDAP Deref November 2008
288 dn: cn=Howard Chu,ou=people,dc=example,dc=org
289 objectClass: inetOrgPerson
294 dn: cn=Pierangelo Masarati,ou=people,dc=example,dc=org
295 objectClass: inetOrgPerson
296 cn: Pierangelo Masarati
300 dn: cn=Test Group,ou=groups,dc=example,dc=org
301 objectClass: groupOfNames
303 member: cn=Howard Chu,ou=people,dc=example,dc=org
304 member: cn=Pierangelo Masarati,ou=people,dc=example,dc=org
306 A search could be performed with a Dereference request control value
311 and the "cn=Test Group" entry would be returned with the response
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] } } } }
335 Masarati & Chu Expires May 23, 2009 [Page 6]
337 Internet-Draft LDAP Deref November 2008
340 4. Implementation Notes
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.
391 Masarati & Chu Expires May 23, 2009 [Page 7]
393 Internet-Draft LDAP Deref November 2008
396 5. Security Considerations
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
408 Security considerations described in documents listed in [RFC4510]
447 Masarati & Chu Expires May 23, 2009 [Page 8]
449 Internet-Draft LDAP Deref November 2008
452 6. IANA Considerations
454 6.1. Object Identifier Registration
456 It is requested that IANA register upon Standards Action an LDAP
457 Object Identifier for use in this technical specification.
459 Subject: Request for LDAP OID Registration
460 Person & email address to contact for further information:
461 Pierangelo Masarati <ando@OpenLDAP.org>
463 Author/Change Controller: IESG
465 Identifies the LDAP Dereference Control request
503 Masarati & Chu Expires May 23, 2009 [Page 9]
505 Internet-Draft LDAP Deref November 2008
559 Masarati & Chu Expires May 23, 2009 [Page 10]
561 Internet-Draft LDAP Deref November 2008
564 8. Normative References
566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
567 Requirement Levels", BCP 14, RFC 2119, March 1997.
569 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
570 (LDAP): Technical Specification Road Map", RFC 4510,
573 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
574 (LDAP): The Protocol", RFC 4511, June 2006.
576 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
577 (LDAP): Directory Information Models", RFC 4512,
580 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
581 Syntaxes and Matching Rules", RFC 4517, June 2006.
615 Masarati & Chu Expires May 23, 2009 [Page 11]
617 Internet-Draft LDAP Deref November 2008
623 Politecnico di Milano
624 Dipartimento di Ingegneria Aerospaziale
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/
637 18740 Oxnard St., Suite 313A
638 Tarzana, California 91356
641 Phone: +1 818 757-7087
643 URI: http://www.symas.com/
671 Masarati & Chu Expires May 23, 2009 [Page 12]
673 Internet-Draft LDAP Deref November 2008
676 Full Copyright Statement
678 Copyright (C) The IETF Trust (2008).
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.
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.
693 Intellectual Property
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.
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.
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
727 Masarati & Chu Expires May 23, 2009 [Page 13]