Internet-Draft Ryan Moats draft-moats-ldap-dereference-match-00.txt Jerry Maziarski Expires in six months AT&T John Strassner cisco Systems June 1999 Extensible Match Rule to Dereference Pointers Filename: draft-moats-ldap-dereference-match-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document defines a LDAPv3 extensible matching rule that allows a server to dereference pointers stored in an object's attribute and apply a LDAP search filter to the resulting objects. This rule is needed for schema definitions that attempt to capture richer association models than that typically seen in white pages related schema. 1. Introduction When mapping rich information models, it sometimes becomes necessary to use DN pointers to show relationships between objects in the schema. An example is the information model and resulting core schema that is currently being proposed by the policy working group (see [1]). Expires 12/31/99 [Page 1]
INTERNET DRAFTExtensible Match Rule to Dereference Pointers June 1999 To maintain client efficiency, it is desirable to define an extensible match rule that allows a LDAP search filter not to an object, but to the objects that are pointed to by DN pointers contained in a particular attribute of the base object of the search. 2. derefencingMatch A server will advertise support for this matching rule by having the following rule definition present in its root subschema subentry. ( <oid-m1> NAME "derefencingMatch" DESC "Extended match that dereferences before searching" SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) This extensibleMatch filter is used by a client presenting <oid-m1> as the matchingRule, any attribute with DN syntax as the type and a string representation of a LDAP search filter as the value. The server first collects the objects that the attribute points to and the client has permission to read and then applies the specified LDAP filter to them, returning the objects that were matched. For example, a client that presented the following filter: (targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)(trafficType=2))) The server would apply the filter specified to all objects referenced to by the values of the targetDN attribute of the current object. It would then return the requested attributes of the objects that matched the specified filter. If the LDAP filter itself contains a dereferencingMatch rule, it is possible to do double dereferencing. The following filter causes the server to first apply the embedded filter (trafficType=2) to objects pointed to by the dmtfActiveConnectionRefs attribute of the base object. Requested attributes of all objects pointed to by the destinationDmtfProtocolEndpointsRef attribute of objects that passed the first filter are then returned to the client. (destinationDmtfProtocolEndpointsRef:<oid-m1>:= (dmtfActiveConnectionRefs:<oid-m1>:=(trafficType=2))) In cases where a client does not have permission to access an object pointed to by a reference, that object is not placed on the list. 3. Interaction with sizelimit If the number of objects that result from the application of the search filter exceed the size limit, the server MUST respond with a size limit exceeded error. Expires 12/31/99 [Page 2]
INTERNET DRAFTExtensible Match Rule to Dereference Pointers June 1999 4. Search scoping considerations Because of the possibility of size limit overload and the loss of relationship between the returned objects and the source object during one-level or subtree searches, it is strongly recommended that this match rule only be used with base level searches. 5. Security considerations An improperly formed query can create a denial of service attack by using up excessive resources. Therefore, queries of this type should also specify a specific time limit to ensure that other clients can continue to make use of the directory. In addition, by allowing a client to request that the server collect objects before applying the search filter, a client may be able to determine information about what objects they have rights to search on. This is no different from what is possible using a subtree search. 6. References Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites. [1] J. Strassner, E. Ellesson, B. Moore, "Policy Frame- work Core Information Model," Internet Draft (work in progress), May 1999. 5. Author's Addresses Ryan Moats Jerry Maziarski John Strassner 15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1 Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive USA Middletown, NJ 07748 San Jose, CA 95134 E-mail: jayhawk@att.com USA E-mail: johns@cisco.com E-mail: gfm@qsun.att.com Expires 12/31/99 [Page 3]