--- /dev/null
+
+
+
+Network Working Group P. Masarati
+Internet-Draft Politecnico di Milano
+Intended status: Standards Track H. Chu
+Expires: April 30, 2009 Symas Corp.
+ October 27, 2008
+
+
+ LDAP Dereference Control
+ draft-masarati-ldap-deref.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on April 30, 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 1]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+Abstract
+
+ This document describes the Dereference Control for LDAP. This
+ control is intended to provide a concise means to collect extra
+ information related to cross-links present in entries returned as
+ part of search responses.
+
+
+Table of Contents
+
+ 1. Background and Intended Use . . . . . . . . . . . . . . . . . 3
+ 2. The LDAP Dereference Control . . . . . . . . . . . . . . . . . 4
+ 2.1. Control Semantics . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Control Request . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Control Response . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Object Identifier Registration . . . . . . . . . . . . . . 9
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+ Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 2]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+1. Background and Intended Use
+
+ Cross-links between entries are often used to describe relationships
+ between entries. To exploit the uniqueness of entries naming, these
+ links are usually represented by the distinguished name (DN) of the
+ linked entries.
+
+ In many cases, DUAs need to collect information about linked entries.
+ This requires to explicitly dereference each linked entry in order to
+ collect the desired attributes, resulting in the need to perform a
+ specific sequence of search operations, using the links as search
+ base, with a SearchRequest.scope of baseObject [RFC4511].
+
+ This document describes a LDAP Control [RFC4511] that allows a DUA to
+ request the DSA to return specific attributes of linked entries along
+ with the link, under the assumption that this operation can be
+ performed by the DSA in a more efficient manner than the DUA would
+ itself by performing the complete sequence of required search
+ operations.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 3]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+2. The LDAP Dereference Control
+
+2.1. Control Semantics
+
+ This control allows specifying a dereference attribute and a set of
+ attributes to be dereferenced, as illustrated in Section 2.2. The
+ dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12
+ (DN) [RFC4517]. Each value of the dereference attribute in a
+ SearchResultEntry SHOULD result in dereferencing the corresponding
+ entry, collecting the values of the attributes to be dereferenced,
+ and returning them as part of the control value in the
+ SearchResultEntry response, in the format detailed in Section 2.3.
+
+ The control value may contain dereference attribute values without
+ any dereferenced attribute values, as detailed in Section 2.3. The
+ control semantics does not specify whether this is a consequence of a
+ dangling link or of the application of access restrictions on the
+ values of the attributes to be dereferenced.
+
+ Attribute description hierarchy [RFC4512] SHALL NOT be exploited when
+ collecting the values of the attributes to be dereferenced. On the
+ contrary, all of the attribute descriptions in an attribute hierarchy
+ SHOULD be treated as distinct and unrelated descriptions.
+
+ This control is only appropriate for the search operation [RFC4511].
+ This control MUST be ignored if the Search was requested with
+ SearchRequest.typesOnly specified as TRUE. The dereference attribute
+ MUST be part of the search result set.
+
+ The semantics of the criticality field are specified in [RFC4511].
+ In detail, the criticality of the control determines whether the
+ control will or will not be used, and if it will not be used, whether
+ the operation will continue without the control, or fail returning
+ unavailableCriticalExtension. If the control is appropriate for an
+ operation and, for any reason, it cannot be applied in its entirety
+ to a single SearchResultEntry response, it MUST NOT be applied to
+ that specific SearchResultEntry response, without affecting its
+ application to any subsequent SearchResultEntry response.
+
+ This control is totally unrelated to alias dereferencing [RFC4511].
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 4]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+2.2. Control Request
+
+ The specification of the Dereference Control request is:
+
+ controlValue ::= SEQUENCE OF derefSpec DerefSpec
+
+ DerefSpec ::= SEQUENCE {
+ derefAttr attributeDescription, ; with DN syntax
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attr AttributeDescription
+
+ Each derefSpec.derefAttr MUST be unique within controlValue.
+
+2.3. Control Response
+
+ The specification of the Dereference Control response is:
+
+ controlValue ::= SEQUENCE OF derefRes DerefRes
+
+ DerefRes ::= SEQUENCE {
+ derefAttr AttributeDescription,
+ derefVal LDAPDN,
+ attrVals [0] PartialAttributeList OPTIONAL }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ PartialAttribute is defined in [RFC4511]; the definition is reported
+ here for clarity:
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ If partialAttribute.vals is empty, the corresponding partialAttribute
+ is omitted. If all partialAttribute.vals in attrVals are empty, that
+ derefRes.attrVals is omitted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 5]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+3. Examples
+
+ Given these entries:
+
+ dn: cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org
+ objectClass: inetOrgPerson
+ cn: Howard Chu
+ sn: Chu
+ uid: hyc
+
+ dn: Pierangelo Masarati,ou=people,dc=OpenLDAP,dc=org
+ objectClass: inetOrgPerson
+ cn: Pierangelo Masarati
+ sn: Masarati
+ uid: ando
+
+ dn: cn=Test Group,ou=groups,dc=OpenLDAP,dc=org
+ objectClass: groupOfNames
+ cn: test Group
+ member: cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org
+ member: cn=Pierangelo,Masarati,ou=people,dc=OpenLDAP,dc=org
+
+ A search could be performed with a Dereference request control value
+ specified as
+
+ { member, uid }
+
+ and the "cn=Test Group" entry would be returned with the response
+ control value
+
+ { { member, cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org,
+ { { uid, [hyc] } } },
+ { member, cn=Pierangelo Masarati,ou=people,dc=OpenLDAP,dc=org,
+ { { uid, [ando] } } } }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 6]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+4. Implementation Notes
+
+ This LDAP extension is currently implemented in OpenLDAP software.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 7]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+5. Security Considerations
+
+ The control result MUST NOT disclose information the client's
+ identity could not have accessed by performing the related search
+ operations. The presence of a derefRes.derefVal in the response
+ control, with no derefRes.attrVals, does not imply neither the
+ existence of nor any access privilege to the corresponding entry. It
+ is merely a consequence of the read access the client's identity has
+ on the corresponding value of the derefRes.derefAttr that would be
+ returned as part of the attributes of a SearchResultEntry [RFC4511].
+
+ Security considerations described in documents listed in [RFC4510]
+ apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 8]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+6. IANA Considerations
+
+6.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier for use in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Pierangelo Masarati <ando@OpenLDAP.org>
+ Specification: (I-D)
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Dereference Control request
+ and response
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 9]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+7. Acknowledgments
+
+ TBD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 10]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510,
+ June 2006.
+
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512,
+ June 2006.
+
+ [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 11]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+Authors' Addresses
+
+ Pierangelo Masarati
+ Politecnico di Milano
+ Dipartimento di Ingegneria Aerospaziale
+ via La Masa 34
+ Milano 20156
+ IT
+
+ Phone: +39 02 2399 8309
+ Fax: +39 02 2399 8334
+ Email: ando@OpenLDAP.org
+ URI: http://www.aero.polimi.it/masarati/
+
+
+ Howard Y. Chu
+ Symas Corporation
+ 18740 Oxnard St., Suite 313A
+ Tarzana, California 91356
+ USA
+
+ Phone: +1 818 757-7087
+ Email: hyc@symas.com
+ URI: http://www.symas.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 12]
+\f
+Internet-Draft LDAP Deref October 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Masarati & Chu Expires April 30, 2009 [Page 13]
+\f
--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+ <!ENTITY rfc2119 PUBLIC ''
+ 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
+ <!ENTITY rfc4510 PUBLIC ''
+ 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4510.xml'>
+ <!ENTITY rfc4511 PUBLIC ''
+ 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
+ <!ENTITY rfc4512 PUBLIC ''
+ 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4512.xml'>
+ <!ENTITY rfc4517 PUBLIC ''
+ 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
+]>
+
+<!-- $OpenLDAP$ -->
+
+<rfc category="std" ipr="full3978" docName="draft-masarati-ldap-deref.txt">
+
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+
+<?rfc toc="yes" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes"?>
+<?rfc iprnotified="no" ?>
+<?rfc strict="yes" ?>
+
+ <front>
+ <title abbrev='LDAP Deref'>LDAP Dereference Control</title>
+ <author initials='P.' surname="Masarati" fullname='Pierangelo Masarati'>
+ <organization abbrev='Politecnico di Milano'>
+ Politecnico di Milano
+ </organization>
+ <address>
+ <postal>
+ <street>Dipartimento di Ingegneria Aerospaziale</street>
+ <street>via La Masa 34</street>
+ <city>Milano</city>
+ <code>20156</code>
+ <country>IT</country>
+ </postal>
+ <phone>+39 02 2399 8309</phone>
+ <facsimile>+39 02 2399 8334</facsimile>
+ <email>ando@OpenLDAP.org</email>
+ <uri>http://www.aero.polimi.it/masarati/</uri>
+ </address>
+ </author>
+ <author initials="H.Y." surname="Chu" fullname="Howard Y. Chu">
+ <organization abbrev="Symas Corp.">
+ Symas Corporation
+ </organization>
+ <address>
+ <postal>
+ <street>18740 Oxnard St., Suite 313A</street>
+ <city>Tarzana</city>
+ <region>California</region>
+ <code>91356</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1 818 757-7087</phone>
+ <email>hyc@symas.com</email>
+ <uri>http://www.symas.com/</uri>
+ </address>
+ </author>
+ <!--date/-->
+ <date month='October' year='2008' />
+ <abstract>
+ <t>
+This document describes the Dereference Control for LDAP.
+This control is intended to provide a concise means to collect
+extra information related to cross-links present in entries
+returned as part of search responses.
+ </t>
+ </abstract>
+ </front>
+
+ <middle>
+ <section title="Background and Intended Use">
+ <t>
+Cross-links between entries are often used to describe relationships
+between entries.
+To exploit the uniqueness of entries naming, these links are usually
+represented by the distinguished name (DN) of the linked entries.
+ </t>
+
+ <t>
+In many cases, DUAs need to collect information about linked entries.
+This requires to explicitly dereference each linked entry in order to
+collect the desired attributes, resulting in the need to perform a
+specific sequence of search operations, using the links as search base,
+with a SearchRequest.scope of baseObject <xref target="RFC4511" />.
+ </t>
+
+ <t>
+This document describes a LDAP Control <xref target="RFC4511" />
+that allows a DUA to request the DSA to return specific attributes
+of linked entries along with the link, under the assumption that
+this operation can be performed by the DSA in a more efficient manner
+than the DUA would itself by performing the complete sequence
+of required search operations.
+ </t>
+
+ <t>
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+and "OPTIONAL" in this document are to be interpreted as
+described in <xref target="RFC2119" />.
+ </t>
+ </section>
+
+ <section title="The LDAP Dereference Control">
+ <section title="Control Semantics">
+ <t>
+This control allows specifying a dereference attribute and a set
+of attributes to be dereferenced, as illustrated
+in <xref target="control_request" />.
+The dereference attribute's syntax MUST be 1.3.6.1.4.1.1466.115.121.1.12
+(DN) <xref target="RFC4517" />.
+Each value of the dereference attribute in a SearchResultEntry SHOULD
+result in dereferencing the corresponding entry, collecting the values
+of the attributes to be dereferenced, and returning them as part
+of the control value in the SearchResultEntry response, in the format
+detailed in <xref target="control_response" />.
+ </t>
+
+ <t>
+The control value may contain dereference attribute values without any
+dereferenced attribute values, as detailed in
+<xref target="control_response" />.
+The control semantics does not specify whether this is a consequence
+of a dangling link or of the application of access restrictions
+on the values of the attributes to be dereferenced.
+ </t>
+
+ <t>
+Attribute description hierarchy <xref target="RFC4512" /> SHALL NOT
+be exploited when collecting the values of the attributes
+to be dereferenced.
+On the contrary, all of the attribute descriptions in an attribute
+hierarchy SHOULD be treated as distinct and unrelated descriptions.
+ </t>
+
+ <t>
+This control is only appropriate for the search operation
+<xref target="RFC4511" />. This control MUST be ignored if the
+Search was requested with SearchRequest.typesOnly specified as TRUE.
+The dereference attribute MUST be part of the search result set.
+ </t>
+
+ <t>
+The semantics of the criticality field are specified in
+<xref target="RFC4511" />.
+In detail, the criticality of the control determines whether the control
+will or will not be used, and if it will not be used, whether the operation
+will continue without the control, or fail returning
+unavailableCriticalExtension.
+If the control is appropriate for an operation and, for any reason,
+it cannot be applied in its entirety to a single SearchResultEntry response,
+it MUST NOT be applied to that specific SearchResultEntry response,
+without affecting its application to any subsequent SearchResultEntry
+response.
+ </t>
+
+ <t>
+This control is totally unrelated to alias dereferencing
+<xref target="RFC4511" />.
+ </t>
+ </section>
+
+ <section anchor="control_request" title="Control Request">
+ <figure>
+ <preamble>
+The specification of the Dereference Control request is:
+ </preamble>
+ <artwork>
+ controlValue ::= SEQUENCE OF derefSpec DerefSpec
+
+ DerefSpec ::= SEQUENCE {
+ derefAttr attributeDescription, ; with DN syntax
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attr AttributeDescription
+ </artwork>
+ <postamble>
+Each derefSpec.derefAttr MUST be unique within controlValue.
+ </postamble>
+ </figure>
+ </section>
+
+ <section anchor="control_response" title="Control Response">
+ <figure>
+ <preamble>
+The specification of the Dereference Control response is:
+ </preamble>
+ <artwork>
+ controlValue ::= SEQUENCE OF derefRes DerefRes
+
+ DerefRes ::= SEQUENCE {
+ derefAttr AttributeDescription,
+ derefVal LDAPDN,
+ attrVals [0] PartialAttributeList OPTIONAL }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+ </artwork>
+ </figure>
+ <figure>
+ <preamble>
+PartialAttribute is defined in <xref target="RFC4511" />;
+the definition is reported here for clarity:
+ </preamble>
+ <artwork>
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+ </artwork>
+ <postamble>
+If partialAttribute.vals is empty, the corresponding partialAttribute
+is omitted.
+If all partialAttribute.vals in attrVals are empty, that derefRes.attrVals
+is omitted.
+ </postamble>
+ </figure>
+ </section>
+ </section>
+
+ <section title="Examples">
+ <figure>
+ <preamble>
+Given these entries:
+ </preamble>
+ <artwork>
+ dn: cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org
+ objectClass: inetOrgPerson
+ cn: Howard Chu
+ sn: Chu
+ uid: hyc
+
+ dn: Pierangelo Masarati,ou=people,dc=OpenLDAP,dc=org
+ objectClass: inetOrgPerson
+ cn: Pierangelo Masarati
+ sn: Masarati
+ uid: ando
+
+ dn: cn=Test Group,ou=groups,dc=OpenLDAP,dc=org
+ objectClass: groupOfNames
+ cn: test Group
+ member: cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org
+ member: cn=Pierangelo,Masarati,ou=people,dc=OpenLDAP,dc=org
+ </artwork>
+ </figure>
+ <figure>
+ <preamble>
+A search could be performed with a Dereference request control value
+specified as
+ </preamble>
+ <artwork>
+ { member, uid }
+ </artwork>
+ </figure>
+ <figure>
+ <preamble>
+and the "cn=Test Group" entry would be returned with the response control
+value
+ </preamble>
+ <artwork>
+ { { member, cn=Howard Chu,ou=people,dc=OpenLDAP,dc=org,
+ { { uid, [hyc] } } },
+ { member, cn=Pierangelo Masarati,ou=people,dc=OpenLDAP,dc=org,
+ { { uid, [ando] } } } }
+ </artwork>
+ </figure>
+ </section>
+
+ <section title="Implementation Notes">
+ <t>
+This LDAP extension is currently implemented in OpenLDAP software.
+ </t>
+ </section>
+
+ <section title="Security Considerations">
+ <t>
+The control result MUST NOT disclose information the client's identity
+could not have accessed by performing the related search operations.
+The presence of a derefRes.derefVal in the response control, with
+no derefRes.attrVals, does not imply neither the existence of nor any
+access privilege to the corresponding entry.
+It is merely a consequence of the read access the client's identity has
+on the corresponding value of the derefRes.derefAttr that would be returned
+as part of the attributes of a SearchResultEntry <xref target="RFC4511" />.
+ </t>
+ <t>
+Security considerations described in documents listed in
+<xref target="RFC4510" /> apply.
+ </t>
+ </section>
+
+ <section title="IANA Considerations">
+ <section title="Object Identifier Registration">
+ <figure>
+ <preamble>
+It is requested that IANA register upon Standards Action an LDAP
+Object Identifier for use in this technical specification.
+ </preamble>
+ <artwork>
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Pierangelo Masarati <ando@OpenLDAP.org>
+ Specification: (I-D)
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Dereference Control request
+ and response
+ </artwork>
+ </figure>
+ </section>
+ </section>
+
+ <section title="Acknowledgments">
+ <t>
+TBD
+ </t>
+ </section>
+ </middle>
+
+ <back>
+ <references title='Normative References'>
+ &rfc2119;
+ &rfc4510;
+ &rfc4511;
+ &rfc4512;
+ &rfc4517;
+ </references>
+
+ </back>
+
+</rfc>
projects / openldap / commitdiff