OwlCyberSecurity - MANAGER

Edit File: draft-haripriya-dynamicgroup-xx.txt

Network Working Group                                       S. Haripriya
Internet-Draft                                         Jaimon. Jose, Ed.
Updates: 02 (if approved)                               Jim. Sermersheim
Intended status: Standards Track                            Novell, Inc.
Expires: July 9, 2007                                    January 5, 2007

LDAP: Dynamic Groups for LDAPv3
                    draft-haripriya-dynamicgroup-02

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 July 9, 2007.

Haripriya, et al.         Expires July 9, 2007                  [Page 1]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Abstract

This document describes the requirements, semantics, schema elements,
   and operations needed for a dynamic group feature in LDAP.  A dynamic
   group is defined here as a group object with a membership list of
   distinguished names that is dynamically generated using LDAP search
   criteria.  The dynamic membership list may then be interrogated by
   LDAP search and compare operations, and may also be used to find the
   groups that an object is a member of.  This feature eliminates a huge
   amount of the administrative effort required today for maintaining
   group memberships and role-based operations in large enterprises.

Table of Contents

1.  Conventions used in this document  . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Requirements of a dynamic group feature  . . . . . . . . . . .  6
   4.  Schema and Semantic Definitions for Dynamic Groups . . . . . .  7
     4.1.  Object Classes . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  dynamicGroup . . . . . . . . . . . . . . . . . . . . .  7
       4.1.2.  dynamicGroupOfUniqueNames  . . . . . . . . . . . . . .  7
       4.1.3.  dynamicGroupAux  . . . . . . . . . . . . . . . . . . .  7
       4.1.4.  dynamicGroupOfUniqueNamesAux . . . . . . . . . . . . .  7
     4.2.  Attributes . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  memberQueryURL . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  excludedMember . . . . . . . . . . . . . . . . . . . . 11
     4.3.  member . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  uniqueMember . . . . . . . . . . . . . . . . . . . . . . . 11
     4.5.  dgIdentity . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.5.1.  dgIdentity - Security implications . . . . . . . . . . 12
   5.  Advertisement of support for dynamic groups  . . . . . . . . . 13
   6.  Dynamic Group Operations . . . . . . . . . . . . . . . . . . . 14
     6.1.  Existing Operations  . . . . . . . . . . . . . . . . . . . 14
       6.1.1.  Access to resources in the directory . . . . . . . . . 14
       6.1.2.  Reading a dynamic group object . . . . . . . . . . . . 14
       6.1.3.  'Is Member Of' functionality . . . . . . . . . . . . . 15
     6.2.  New Extensions . . . . . . . . . . . . . . . . . . . . . . 16
       6.2.1.  Managing the static members of a dynamic group . . . . 16
   7.  Performance Considerations . . . . . . . . . . . . . . . . . . 17
     7.1.  Caching of Dynamic Members . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Example Values for memberQueryURL . . . . . . . . . . 22
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

Haripriya, et al.         Expires July 9, 2007                  [Page 2]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Intellectual Property and Copyright Statements . . . . . . . . . . 25

Haripriya, et al.         Expires July 9, 2007                  [Page 3]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

1.  Conventions used in this document

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 [1].

Haripriya, et al.         Expires July 9, 2007                  [Page 4]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

2.  Introduction

The LDAP schema described in [4] defines two object classes:
   'groupOfNames', and 'groupOfUniqueNames', that hold a static list of
   distinguished names in their 'member' or 'uniqueMember' attributes
   respectively, and are typically used to describe a group of objects
   for various functions.  These grouping functions range from simple
   group membership applications such as email distribution lists to
   describing common authorization for a set of users The administration
   and updating of these membership lists must be done by specifically
   modifying the DN values in the member or uniqueMember attributes.
   Thus, each time a change in membership happens, a process must exist
   which adds or removes the particular entry's DN from the member
   attribute.  For example, consider an organization, where the access
   to its facilities is controlled by membership in a directory group.
   Assume that all employees in a department have been added to the
   group that provides access to the required department facility.  If
   an employee moves from one department to another, the administrator
   must remove the employee from one group and add him to another.
   Similarly consider an organization that wants to provide access to
   its facility, to both interns and employees on weekdays, but only to
   employees on weekends.  It would be effort-consuming to achieve this
   with static groups.

"Dynamic groups" are like normal groups, but they let one specify
   criteria to be used for evaluating membership to a group; the
   membership of the group is determined dynamically by the directory
   servers involved.  This lets the group administrator define the
   membership in terms of attributes, and let the DSAs worry about who
   are the actual members.  This solution is more scalable and reduces
   administrative costs.  This can also supplement static groups in LDAP
   to provide flexibility to the user.

Haripriya, et al.         Expires July 9, 2007                  [Page 5]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

3.  Requirements of a dynamic group feature

The following requirements SHOULD be met by a proposal for the
   dynamic groups feature:

1.  Creation and administration of dynamic groups should be done
       using normal LDAP operations.

2.  Applications must be able to use dynamic groups in the same way
       that they are able to use static groups for listing members and
       for membership evaluation.

3.  Interrogation of a dynamic group's membership should be done
       using normal LDAP operations, and should be consistent.  This
       means that all authorization identities with the same permission
       to the membership attribute of a dynamic group (such as 'read')
       should be presented with the same membership list.

Haripriya, et al.         Expires July 9, 2007                  [Page 6]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

4.  Schema and Semantic Definitions for Dynamic Groups

The dynamic group classes are defined by the following schema

4.1.  Object Classes

The following object classes MUST be supported, and their semantics
   understood by the server, for it to support the dynamic groups
   feature.

4.1.1.  dynamicGroup

( <OID.TBD> NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY
   (memberQueryURL $ excludedMember $ dgIdentity ))

This structural object class is used to create a dynamic group
   object.  It is derived from groupOfNames, which is defined in [4].

4.1.2.  dynamicGroupOfUniqueNames

( <OID.TBD> NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames
   STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity ))

This structural object class is used to create a dynamic group object
   whose membership list is held in a uniqueMember attribute.  It is
   derived from groupOfUniqueNames, which is defined in [4].

4.1.3.  dynamicGroupAux

( <OID.TBD> NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY
   (memberQueryURL $ excludedMember $ dgIdentity ))

This auxiliary object class is used to convert an existing object to
   a dynamic group or to create an object of another object class but
   with dynamic group capabilities.  This is derived from groupOfNames
   which is defined in [4].

4.1.4.  dynamicGroupOfUniqueNamesAux

( <OID.TBD> NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames
  AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity ))

This auxiliary object class is used to convert an existing object to
   a dynamic group of unique names or to create an object of another
   object class but with dynamic group capabilities.  This is derived
   from groupOfUniqueNames which is defined in [4].

Haripriya, et al.         Expires July 9, 2007                  [Page 7]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

4.2.  Attributes

The following attribute names MUST be supported by the server.

4.2.1.  memberQueryURL

This attribute describes the membership of the list using an LDAPURL
   [3].

(<OID.TBD> NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

The value of memberQueryURL is encoded as an LDAPURL [3]

Haripriya, et al.         Expires July 9, 2007                  [Page 8]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

The BNF from [3] is listed here for reference.
ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn
                     [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION
                     extensions]]]]]
                                ; <host> and <port> are defined
                                ;   in Sections 3.2.2 and 3.2.3
                                ;   of [RFC3986].
                                ; <filter> is from Section 3 of
                                ;   [RFC4515], subject to the
                                ;   provisions of the
                                ;   "Percent-Encoding" section
                                ;   below.
scheme      = "ldap"
dn          = distinguishedName ; From Section 3 of [RFC4514],
                                ; subject to the provisions of
                                ; the "Percent-Encoding"
                                ; section below.
attributes  = attrdesc *(COMMA attrdesc)
attrdesc    = selector *(COMMA selector)
selector    = attributeSelector ; From Section 4.5.1 of
                                ; [RFC4511], subject to the
                                ; provisions of the
                                ; "Percent-Encoding" section
                                ; below.
scope       = "base" / "one" / "sub"
extensions  = extension *(COMMA extension)
extension   = [EXCLAMATION] extype [EQUALS exvalue]
extype      = oid               ; From section 1.4 of [RFC4512].
exvalue     = LDAPString        ; From section 4.1.2 of
                                ; [RFC4511], subject to the
                                ; provisions of the
                                ; "Percent-Encoding" section
                                ; below.
EXCLAMATION = %x21              ; exclamation mark ("!")
SLASH       = %x2F              ; forward slash ("/")
COLON       = %x3A              ; colon (":")
QUESTION    = %x3F              ; question mark ("?")

For the purpose of evaluating dynamic members, the directory server
   uses only the dn, scope, filter and extensions fields.  All remaining
   fields are ignored if specified.  If other fields are specified, the
   server SHALL ignore them and MAY omit them when presenting the value
   to a client.  The dn is used to specify the base dn from which to
   start the search for dynamic members.  The scope specifies the scope
   with respect to the dn in which to search for dynamic members.  The
   filter specifies the criteria with which to select objects for
   dynamic membership.

Haripriya, et al.         Expires July 9, 2007                  [Page 9]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

4.2.1.1.  The x-chain extension

A new extension is defined for use of the memberQueryURL in dynamic
   groups, named 'x-chain'. x-chain does not take a value.  When x-chain
   is present, the server must follow any search continuation references
   to other servers while searching for dynamic members.  When x-chain
   is absent, the dynamic members computed will be only those that are
   present on the server from which the search is made.  A directory
   server supporting the memberQueryURL MAY support the x-chain
   extension, thus the x-chain extension could be critical or non-
   critical as specified by the '!' prefix to the extension type.

4.2.1.2.  Semantics of multiple values for memberQueryURL

The memberQueryURL MAY have multiple values, and in that case, the
   members of the dynamic group will be the union of the members
   computed using each individual URL value.  This is useful in
   specifying a group membership that is made up from subtrees rooted at
   different base DNs, and possibly using different filters.

4.2.1.3.  Condition of membership

An object O is a member of a dynamic group G if and only if

(( O is a value of the 'member' or 'uniqueMember' attribute of G)

(( O is selected by the membership criteria specified in the
   'memberQueryURL' attribute values of G)

AND

( O is not listed in the 'excludedMember' attribute of G) ))

If a member M of a dynamic group G happens to be a dynamic or a
   static group, the static or dynamic members of M SHALL NOT be
   considered as members of G. M is a member of G though.

The last condition is imposed because

o  Recursively evaluating members of members may degrade the
      performance of the server drastically.

o  Looping may occur particularly in situations where the search
      chains across multiple-servers.

Haripriya, et al.         Expires July 9, 2007                 [Page 10]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

o  Dynamic membership assertions (compare operation) cannot be
      optimized if recursive memberships are allowed.  Without
      recursion, comparisons can be made light-weight.

4.2.2.  excludedMember

( <OID.TBD> NAME 'excludedMember' SUP distinguishedName )

This attribute is used to exclude entries from being a dynamic member
   of a dynamic group.  Thus an entry is a dynamic member of a dynamic
   group if and only if it is selected by the member criteria specified
   by the 'memberQueryURL' attribute or explicitly added to the member
   or uniqueMember attribute, and it is not listed in the
   'excludedMember' attribute.

4.3.  member

( 2.5.4.31 NAME 'member' SUP distinguishedName )

Defined in [4], this attribute is overloaded when used in the context
   of a dynamic group.  It is used to explicitly specify static members
   of a dynamic group.  If the same entry is listed in both the 'member'
   and 'excludedMember' attributes, the 'member' overrides the
   'excludedMember', and the entry is considered to be a member of the
   group.  This attribute is also used to interrogate both the static
   and dynamic member values of a dynamic group object.  Subclasses of
   this attribute are NOT considered in this manner.

4.4.  uniqueMember

( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName )

Defined in [4], this attribute is overloaded when used in the context
   of a dynamic group.  It is used to specify the static members of a
   dynamic group.  If the same entry is listed in both the
   'uniqueMember' and 'excludedMember' attributes, the 'uniqueMember'
   overrides the 'excludedMember', and the entry is considered to be a
   member of the group.  This attribute is also used to interrogate both
   the static and dynamic member values of a dynamic group object.
   Subclasses of this attribute are NOT considered in this manner.

4.5.  dgIdentity

( <OID.TBD> NAME 'identity' SUP distinguishedName SINGLE-VALUE )

In order to provide consistent results when processing the search
   criteria, the server must use a single authorization identity.  If
   the authorization of the bound identity is used, the membership list

Haripriya, et al.         Expires July 9, 2007                 [Page 11]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

will vary, from identity to identity due to differing access
   controls.  This may either be done by the server authenticating as
   the dgIdentity prior to performing a search or compare operation, or
   may be done by simply assuming the authorization of the dgIdentity
   when performing those operations.  As server implementations vary, so
   may the mechanisms to achieve consistent results through the use of
   the dgIdentity.  In the case that the server authenticates as the
   dgIdentity, it may be required by the server that this identity have
   proper authentication credentials, and it may be required that this
   identity reside in the DIB of the local server.

In the absence of an identity value, or in case the identity value
   cannot be used, the server will process the memberQueryURL as the
   anonymous identity.  This attribute MAY be supported, and represents
   the identity the server will use for processing the memberQueryURL.

4.5.1.  dgIdentity - Security implications

Because this attribute indirectly but effectively grants anyone with
   read or compare access to the member or uniqueMember attribute
   sufficient permission to gain a DN result set from the
   memberQueryURL, server implementations SHOULD NOT allow this
   attribute to be populated with the DN of any object that is not
   administered by the identity making the change to this attribute.
   For purposes of this document, to "administer an object" indicates
   that the administrative identity has the ability to fully update the
   access control mechanism in place the object in question.  As of this
   writing, there is no way to describe further what it means to be
   fully able to administer the access control mechanism for an object,
   so this definition is left as implementation-specific.

This requirement will allow an entity that has privileges to
   administer a particular subtree (meaning that entity can add, delete,
   and update objects in that subtree), to place in the dgIdentity DNs
   of only those objects it administers.

Haripriya, et al.         Expires July 9, 2007                 [Page 12]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

5.  Advertisement of support for dynamic groups

If the dynamic groups schema is not present on an LDAP server, it
   MUST be assumed that the dynamic groups feature is not supported.

Haripriya, et al.         Expires July 9, 2007                 [Page 13]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

6.  Dynamic Group Operations

6.1.  Existing Operations

The following operations SHOULD expose the dynamic groups
   functionality.  These operations do not require any change in the
   LDAP protocol to be exchanged between the client and server.

6.1.1.  Access to resources in the directory

If access control items are set on a target resource object in the
   directory, with the subject being a dynamic group object, then all
   the members of the group object, including the dynamic members, will
   get the same permissions on the target entry.  This would be the most
   useful application of dynamic groups as seen by an administrator
   because it lets the server control access to resources based on
   dynamic membership to a trustee (subject of ACI) of the resource.
   The way to specify a dynamic ACL is currently implementation
   specific, as there is no common ACL definition for LDAP, and hence
   will be dealt with in a separate document or later (TO BE DONE).

6.1.2.  Reading a dynamic group object

When the member attributes of a dynamic group object is listed by the
   client using an LDAP search operation, the member values returned
   SHOULD contain both the static and dynamic members of the group
   object.  This functionality will not require a change to the
   protocol, and the clients need not be aware of dynamic groups to
   exploit this functionality.  This feature is useful for clients that
   determine access privileges to a resource by themselves, by reading
   the members of a group object.  It will also be useful to
   administrators who want to see the result of the query URL that they
   set on the dynamic group entry.  Note that this overloads the
   semantics of the 'member' and 'uniqueMember' attributes.  This could
   lead to some surprises for the client .

for example: Clients that read the member attribute of a dynamic
   group object and then attempt to remove values (which were dynamic)
   could get an error specifying such a value was not there.

Example:

Let cn=dg1,o=myorg be a dynamic group object with the following
   attributes stored in the directory.

Haripriya, et al.         Expires July 9, 2007                 [Page 14]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

member: cn=admin,o=myorg

excludedMember: cn=guest,ou=finance,o=myorg

excludedMember: cn=robin,ou=finance,o=myorg

memberQueryURL:
      ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson)

If there are 5 organizationalPerson objects under ou=finance,o=myorg
   with common names bob, alice, john, robin, and guest, then the output
   of a base-scope LDAP search at cn=dg1,o=myorg, with the attribute
   list containing 'member' will be as follows:

dn: cn=dg1,o=myorg

member: cn=admin,o=myorg

member: cn=bob,ou=finance,o=myorg

member: cn=alice,ou=finance,o=myorg

member: cn=john,ou=finance,o=myorg

6.1.3.  'Is Member Of' functionality

The LDAP compare operation allows one to discover whether a given DN
   is in the membership list of a dynamic group.  Again, the server
   SHOULD produce consistent results among different authorization
   identities when processing this request, as long as those identities
   have the same access to the member or uniqueMember attribute.  Using
   the data from the example in Section 6.1.2, a compare on
   cn=dg1,o=myorg, for the AVA member=cn=bob,ou=finance,o=myorg would
   result in a response of compareTrue (assuming the bound identity was
   authorized to compare the member attribute of cn=dg1,o=myorg).

Likewise, a search operation that contains an equalityMatch or
   presence filter, naming the member or uniqueMember attribute as the
   attribute (such as (member= cn=bob,ou=finance,o=myorg), or
   (member=*)), will cause the server to evaluate this filter against
   the rules given in Section 4.2.1.3 in the event that the search is
   performed on a dynamic group object.  As of this writing, no other
   matching rules exist for the distinguished name syntax, thus no
   requirements beyond equalityMatch are given here.

Haripriya, et al.         Expires July 9, 2007                 [Page 15]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

6.2.  New Extensions

The following new extensions are added for dynamic group support.

6.2.1.  Managing the static members of a dynamic group

Because a dynamic group overloads the semantics of the member and
   uniqueMember attributes, a mechanism is needed to retrieve the static
   values found in these attributes for management purposes.  To serve
   this need, a new attribute option is defined here called 'x-static'.
   Attribute options are discussed in Section 2.5 of [2].  This option
   SHALL only be specified with the 'member' or 'uniqueMember'
   attribute.  When the LDAP server does not understand the semantics of
   this option on a given attribute, the option SHOULD be ignored.  This
   attribute option is only used to affect the transmitted values, and
   does not impose sub-typing semantics on the attribute.

This option MAY be specified by a client during a search request in
   the list of attributes to be returned, i.e. member;x-static.  In this
   case, the server SHALL only return those members of the dynamic group
   that are statically listed as values of the member or uniqueMember
   attribute.  The evaluation process listed in Section 9 SHALL NOT be
   used to populate the values to be returned.

This option MAY be specified is either an equalityMatch or presence
   search filter.  In this case, the server evaluates only the values
   statically listed in the member or uniqueMember attribute, and does
   not apply the evaluation process listed in Section 9.

This option MAY be specified in update operations such as add and
   modify, but SHOULD be ignored, as its presence is semantically the
   same as its non-presence.

Note to user: Performing a search to read a dynamic group, with a
   filter item such as (member=*), and specifying member;x-static, may
   result in a search result entry that has no member attribute.  This
   may seem counter-intuitive.

Haripriya, et al.         Expires July 9, 2007                 [Page 16]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

7.  Performance Considerations

When the x-chain extension is present on the memberQueryURL, the
   server MUST follow any search continuation references to other
   servers while searching for dynamic members.  This may be expensive
   and slow in a true distributed environment.  The dynamicGroup
   implementation can consider a distributed caching feature to improve
   the performance.  An outline of such a distributed caching is given
   below.

7.1.  Caching of Dynamic Members

Since the dynamic members of a group are computed every time the
   group is accessed, the performance could be affected.  An
   implementation of dynamic groups can get around this problem by
   caching the computed members of a dynamic group locally and using the
   cached data subsequently.  One way to do this is to create pseudo-
   objects for each dynamic group on every server that holds an object
   that is a dynamic member of the group.  With this, the computation of
   the dynamic members of a group reduces to the task of reading the
   pseudo-objects from each server.  These pseudo-objects need to be
   linked from the original dynamic group to speed up the member
   computation.  Also, since these are cached objects, appropriate
   timeouts need to be associated with the cache after which the cache
   should be invalidated or refreshed

Haripriya, et al.         Expires July 9, 2007                 [Page 17]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

8.  Security Considerations

This document discusses the use of one object as the identity
   (Section 4.5) with which to read information for another object.  If
   the creation of the dgIdentity attribute is uncontrolled, an intruder
   could potentially create a dynamic group with the identity of, say,
   the administrator, to be able to read the directory as the
   administrator, and see information which would be otherwise
   unavailable to him.  Thus, a person adding an object as identity of a
   dynamic group should have appropriate permissions on the object being
   added as identity.

This document also discusses using dynamic memberships to provide
   access for resources in a directory.  As the dynamic members are not
   created by the administrator, there could be surprises for the
   administrator in the form of certain objects getting access to
   certain resources through dynamic membership, which the administrator
   never intended.  So the administrator should be wary of such
   problems.  The administrator could view the memberships and make sure
   that anybody who is not supposed to be a member of a group is added
   to the excludedMember list.

Denial of service attacks can be launched on an LDAP server, by
   repeatedly searching for a dynamic group with a large membership list
   and listing the member attribute.  A more effective form of denial of
   service attack could be launched by making searches of the form
   (member="somedn") at the top of tree and closing the client
   connection as soon as the search starts.  Some administrative limits
   be imposed to avoid such situations.

The dynamic groups feature could be potentially misused by a user to
   circumvent any administrative size-limit restriction placed on the
   server.  In order to search an LDAP server and obtain the names of
   all the objects on the server irrespective of admin size-limit
   restriction on the server, the LDAP user could create a dynamic group
   with a memberQueryURL which matches all objects in the tree, and list
   just that one object.

Haripriya, et al.         Expires July 9, 2007                 [Page 18]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

9.  IANA Considerations

There are no IANA considerations.

Haripriya, et al.         Expires July 9, 2007                 [Page 19]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

10.  Conclusions

This document discusses the syntax, semantics and usage of dynamic
   groups in LDAPv3.

Haripriya, et al.         Expires July 9, 2007                 [Page 20]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

11.  Normative References

[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2]  Zeilenga, K., "Lightweight Directory Access Protocol (LDAP):
        Directory Information Models", RFC 4512, June 2006.

[3]  Smith, M. and T. Howes, "Lightweight Directory Access Protocol
        (LDAP): Uniform Resource Locator", RFC 4516, June 2006.

[4]  Sciberras, A., "Lightweight Directory Access Protocol (LDAP):
        Schema for User Applications", RFC 4519, June 2006.

Haripriya, et al.         Expires July 9, 2007                 [Page 21]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Appendix A.  Example Values for memberQueryURL

1.  This memberQueryURL value specifies the membership criteria for a
       dynamic group entry as "all inetorgperson entries that also have
       their title attribute set to 'manager', and are in the DIT-wide
       subtree under ou=hr,o=myorg ".

memberQueryURL: ldap:///
          ou=hr,o=myorg??sub?(&
          (objectclass=inetorgperson)(title=manager))? x-chain

2.  This value lets the user specify the membership criteria for a
       dynamic group entry as "all entries on the local server, that
       either have unix accounts or belong to the unix department, and
       are under the engineering container ".

memberQueryURL: ldap:///ou=eng,o=myorg??sub?
          (|(objectclass=posixaccount)(department=unix))

3.  These values let the user specify the membership criteria as "all
       inetorgperson entries on the local server, in either the
       ou=eng,o=myorg or ou=support,o=myorg" subtrees.

memberQueryURL:
          ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson)

memberQueryURL:
          ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson)

Haripriya, et al.         Expires July 9, 2007                 [Page 22]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Appendix B.  Acknowledgments

Funding for the RFC Editor function is currently provided by the
   Internet Society.

Haripriya, et al.         Expires July 9, 2007                 [Page 23]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Authors' Addresses

Haripriya S
   Novell, Inc.
   49/1 & 49/3 Garvebhavi Palya,
   7th Mile, Hosur Road
   Bangalore, Karnataka  560068
   India

Email: sharipriya@novell.com

Jaimon Jose (editor)
   Novell, Inc.
   49/1 & 49/3 Garvebhavi Palya,
   7th Mile, Hosur Road
   Bangalore, Karnataka  560068
   India

Email: jjaimon@novell.com

Jim Sermersheim
   Novell, Inc.
   1800 South Novell Place
   Provo, Utah  84606
   US

Email: jimse@novell.com

Haripriya, et al.         Expires July 9, 2007                 [Page 24]

Internet-Draft       LDAP: Dynamic Groups for LDAPv3        January 2007

Full Copyright Statement

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 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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Haripriya, et al.         Expires July 9, 2007                 [Page 25]