--- /dev/null
+
+
+Internet-Draft P. Behera
+draft behera-ldap-password-policy-07.txt L. Poitou
+Intended Category: Proposed Standard Sun Microsystems
+Expires: August 2004 J. Sermersheim
+ Novell
+
+ February 2004
+
+
+ Password Policy for LDAP Directories
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC 2026.
+
+ 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.
+
+ Technical discussions of this draft are held on the LDAPEXT Working
+ Group mailing list at ietf-ldapext@netscape.com. Editorial comments
+ may be sent to the authors listed in Section 13.
+
+ Copyright (C) The Internet Society (2004). All rights Reserved.
+
+ Please see the Copyright Section near the end of this document for
+ more information.
+
+
+
+Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
+ are to be interpreted as described in RFC 2119 [RFC-2119].
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 1
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+1. Abstract
+
+ Password policy as described in this document is a set of rules that
+ controls how passwords are used and administered in LDAP
+ directories. In order to improve the security of LDAP directories
+ and make it difficult for password cracking programs to break into
+ directories, it is desirable to enforce a set of rules on password
+ usage. These rules are made to ensure that users change their
+ passwords periodically, passwords meet construction requirements,
+ the re-use of old password is restricted, and users are locked out
+ after a certain number of failed attempts.
+
+
+
+2. Overview
+
+ LDAP-based directory services are currently accepted by many
+ organizations as the access protocol for directories. The ability to
+ ensure the secure read and update access to directory information
+ throughout the network is essential to the successful deployment.
+ Most LDAP implementations support many authentication schemes - the
+ most basic and widely used is the simple authentication i.e., user
+ DN and password. In this case, many LDAP servers have implemented
+ some kind of policy related to the password used to authenticate.
+ Among other things, this policy includes:
+
+ - Whether and when passwords expire.
+ - Whether failed bind attempts cause the account to be locked.
+ - If and how users are able to change their passwords.
+
+ In order to achieve greater security protection and ensure
+ interoperability in a heterogeneous environment, LDAP needs to
+ standardize on a common password policy model. This is critical to
+ the successful deployment of LDAP directories.
+
+2.1. Application of password policy
+
+ The password policy defined in this document can be applied to any
+ attribute holding a user's password used for an authenticated LDAP
+ bind operation. In this document, the term "user" represents any
+ LDAP client application that has an identity in the directory.
+
+ This policy is typically applied to the userPassword attribute in
+ the case of the LDAP simple authentication method [RFC-2251] or the
+ case of password based SASL [RFC-2222] authentication such as CRAM-
+ MD5 [RFC-2195] and DIGEST-MD5 [RFC-Digest].
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 2
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ The policy described in this document assumes that the password
+ attribute holds a single value. No considerations are made for
+ directories or systems that allow a user to maintain multi-valued
+ password attributes.
+
+ Server implementations MAY institute internal policy whereby certain
+ identities (such as directory administrators) are not forced to
+ comply with any of password policy. In this case, the password for a
+ directory administrator never expires; the account is never locked,
+ etc.
+
+ The term "directory administrator" refers to a user that has
+ sufficient access control privileges to modify users' passwords, and
+ the pwdPolicy object defined in this document. The access control
+ that is used to determine whether an identity is a directory
+ administrator is beyond the scope of this document, but typically
+ implies that the administrator has 'write' privileges to the
+ password attribute.
+
+3. Articles of password policy
+
+ The following sections explain in general terms each aspect of the
+ password policy defined in this document as well as the need for
+ each. These policies are subdivided into the general groups of
+ password usage and password modification. Implementation details are
+ presented in Sections 6 and 7.
+
+3.1. Password Usage Policy
+
+ This section describes policy enforced when a password is used to
+ authenticate. The general focus of this policy is to minimize the
+ threat of intruders once a password is in use.
+
+3.1.1. Password Guessing limit
+
+ In order to prevent intruders from guessing a user's password, a
+ mechanism exists to track the number of failed authentication
+ attempts, and take action when a limit is reached.
+
+ This policy consists of five parts:
+
+ - A configurable limit on failed authentication attempts.
+
+ - A counter to track the number of failed authentication attempts.
+
+ - A timeframe in which the limit of consecutive failed
+ authentication attempts must happen before action is taken.
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 3
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ - The action to be taken when the limit is reached. The action will
+ either be nothing, or the account will be locked.
+
+ - An amount of time the account is locked (if it is to be locked).
+ This can be indefinite.
+
+3.2. Password Modification Policy
+
+ This section describes policy enforced while users are modifying
+ passwords. The general focus of this policy is to ensure that when
+ users add or change their passwords, the security and effectiveness
+ of their passwords is maximized. In this document, the term "modify
+ password operation" refers to any operation that is used to add or
+ modify a password attribute. Often this is done by updating the
+ userPassword attribute during an add or modify operation, but MAY be
+ done by other means such as an extended operation.
+
+
+3.2.1. Password Expiration, Expiration Warning, and Grace binds
+
+ One of the key properties of a password is the fact that it is not
+ well known. If a password is frequently changed, the chances of that
+ user's account being broken into are minimized.
+
+ Directory administrators may deploy a password policy that causes
+ passwords to expire after a given amount of time - thus forcing
+ users to change their passwords periodically.
+
+ As a side effect, there needs to be a way in which users are made
+ aware of this need to change their password before actually being
+ locked out of their accounts. One or both of the following methods
+ handle this:
+
+ - The user is sent a warning sometime before his password is due to
+ expire. If the user fails to heed this warning before the
+ expiration time, his account will be locked.
+
+ - The user may bind to the directory a preset number of times after
+ her password has expired. If she fails to change her password
+ during one of her 'grace' binds, her account will be locked.
+
+3.2.2. Password History
+
+ When the Password Expiration policy is used, an additional mechanism
+ may be employed to prevent users from simply re-using a previous
+ password (as this would effectively circumvent the expiration
+ policy).
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 4
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ In order to do this; a history of used passwords is kept. The
+ directory administrator sets the number of passwords to be stored at
+ any given time. Passwords are stored in this history whenever the
+ password is changed. Users aren't allowed to specify any passwords
+ that are in the history list while changing passwords.
+
+3.2.3. Password Minimum Age
+
+ Users may circumvent the Password History mechanism by quickly
+ performing a series of password changes. If they change their
+ password enough times, their 'favorite' password will be pushed out
+ of the history list.
+
+ This process may be made less attractive to users by employing a
+ minimum age for passwords. If users are forced to wait 24 hours
+ between password changes, they may be less likely to cycle through a
+ history of 10 passwords.
+
+3.2.4. Password Quality and Minimum length
+
+ In order to prevent users from creating or updating passwords that
+ are easy to guess, a password quality policy may be employed. This
+ policy consists of two general mechanisms - ensuring that passwords
+ conform to a defined quality criteria and ensuring that they are of
+ a minimum length.
+
+ Forcing a password to comply with the quality policy may imply a
+ variety of things including:
+
+ - Disallowing trivial or well-known words make up the password.
+
+ - Forcing a certain number of digits be used.
+
+ - Disallowing anagrams of the user's name.
+
+ The implementation of this policy meets with the following problems:
+
+ - If the password to be added or updated is encrypted by the client
+ before being sent, the server has no way of enforcing this
+ policy. Therefore, the onus of enforcing this policy falls upon
+ client implementations.
+
+ - There are no specific definitions of what 'quality checking'
+ means. This can lead to unexpected behavior in a heterogeneous
+ environment.
+
+3.2.5. User Defined Passwords
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 5
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ In some cases, it is desirable to disallow users from adding and
+ updating their own passwords. This policy makes this functionality
+ possible.
+
+ This implies that certain other policy, such as password expiration
+ is not enforced.
+
+3.2.6. Password Change After Reset
+
+ This policy forces the user to update her password after it has been
+ set for the first time, or has been reset by the directory
+ administrator.
+
+ This is needed in scenarios where a directory administrator has set
+ or reset the password to a well-known value.
+
+3.2.7. Safe modification
+
+ As directories become more commonly used, it will not be unusual for
+ clients to connect to a directory and leave the connection open for
+ an extended period. This opens up the possibility for an intruder to
+ make modifications to a user's password while that user's computer
+ is connected but unattended.
+
+ This policy forces the user to prove his identity by specifying the
+ old password during a password modify operation.
+
+3.3. Restriction of the Password Policy
+
+ The password policy defined in this document can apply to any
+ attribute containing a password. Password policy state information
+ is held in the user's entry, and applies to a password attribute,
+ not a particular password attribute value. Thus the server SHOULD
+ enforce that the password attribute subject to password policy,
+ contains one and only one password value.
+
+
+4. Schema used for Password Policy
+
+ The schema elements defined here fall into two general categories. A
+ password policy object class is defined which contains a set of
+ administrative password policy attributes, and a set of operational
+ attributes are defined that hold general password policy state
+ information for each user.
+
+4.1. The pwdPolicy Object Class
+
+ This object class contains the attributes defining a password policy
+ in effect for a set of users. Section 8 describes the administration
+
+
+Behera, et. al. Expires August 15, 2004 Page 6
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ of this object, and the relationship between it and particular
+ objects.
+
+ ( 1.3.6.1.4.1.42.2.27.8.2.1
+ NAME 'pwdPolicy'
+ SUP top
+ AUXILIARY
+ MUST ( pwdAttribute )
+ MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
+ pwdMinLength $ pwdExpireWarning $ pwdGraceLoginLimit $ pwdLockout
+ $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
+ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
+
+4.2. Attribute Types used in the pwdPolicy ObjectClass
+
+ Following are the attribute types used by the pwdPolicy object
+ class.
+
+4.2.1. pwdAttribute
+
+ This holds the name of the attribute to which the password policy is
+ applied. For example, the password policy may be applied to the
+ userPassword attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.1
+ NAME 'pwdAttribute'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+4.2.2. pwdMinAge
+
+ This attribute holds the number of seconds that must elapse between
+ modifications to the password. If this attribute is not present, 0
+ seconds is assumed.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.2
+ NAME 'pwdMinAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.3. pwdMaxAge
+
+ This attribute holds the number of seconds after which a modified
+ password will expire.
+
+ If this attribute is not present, or if the value is 0 the password
+ does not expire. If not 0, the value must be greater than or equal
+ to the value of the pwdMinAge.
+
+
+Behera, et. al. Expires August 15, 2004 Page 7
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.3
+ NAME 'pwdMaxAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.4. pwdInHistory
+
+ This attribute specifies the maximum number of used passwords stored
+ in the pwdHistory attribute.
+
+ If this attribute is not present, or if the value is 0, used
+ passwords are not stored in the pwdHistory attribute and thus may be
+ reused.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.4
+ NAME 'pwdInHistory'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.5. pwdCheckQuality
+
+ This attribute indicates how the password quality will be verified
+ while being modified or added. If this attribute is not present, or
+ if the value is '0', quality checking will not be enforced. A value
+ of '1' indicates that the server will check the quality, and if the
+ server is unable to check it (due to a hashed password or other
+ reasons) it will be accepted. A value of '2' indicates that the
+ server will check the quality, and if the server is unable to verify
+ it, it will return an error refusing the password.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.5
+ NAME 'pwdCheckQuality'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.6. pwdMinLength
+
+ When quality checking is enabled, this attribute holds the minimum
+ number of characters that must be used in a password. If this
+ attribute is not present, no minimum password length will be
+ enforced. If the server is unable to check the length (due to a
+ hashed password or otherwise), the server will, depending on the
+ value of the pwdCheckQuality attribute, either accept the password
+ without checking it ('0' or '1') or refuse it ('2').
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 8
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.6
+ NAME 'pwdMinLength'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.7. pwdExpireWarning
+
+ This attribute specifies the maximum number of seconds before a
+ password is due to expire that expiration warning messages will be
+ returned to an authenticating user. If this attribute is not
+ present, or if the value is 0 no warnings will be sent. If not 0,
+ the value must be smaller than the value of the pwdMaxAge attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.7
+ NAME 'pwdExpireWarning'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.8. pwdGraceLoginLimit
+
+ This attribute specifies the number of times an expired password can
+ be used to authenticate. If this attribute is not present or if the
+ value is 0, authentication will fail.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.8
+ NAME 'pwdGraceLoginLimit'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.9. pwdLockout
+
+ This attribute indicates, when its value is "TRUE", that the
+ password may not be used to authenticate after a specified number of
+ consecutive failed bind attempts. The maximum number of consecutive
+ failed bind attempts is specified in pwdMaxFailure.
+
+ If this attribute is not present, or if the value is "FALSE", the
+ password may be used to authenticate when the number of failed bind
+ attempts has been reached.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.9
+ NAME 'pwdLockout'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 9
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+4.2.10. pwdLockoutDuration
+
+ This attribute holds the number of seconds that the password cannot
+ be used to authenticate due to too many failed bind attempts. If
+ this attribute is not present, or if the value is 0 the password
+ cannot be used to authenticate until reset by an administrator.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.10
+ NAME 'pwdLockoutDuration'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.11. pwdMaxFailure
+
+ This attribute specifies the number of consecutive failed bind
+ attempts after which the password may not be used to authenticate.
+ If this attribute is not present, or if the value is 0, this policy
+ is not checked, and the value of pwdLockout will be ignored.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.11
+ NAME 'pwdMaxFailure'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.12. pwdFailureCountInterval
+
+ This attribute holds the number of seconds after which the password
+ failures are purged from the failure counter, even though no
+ successful authentication occurred.
+
+ If this attribute is not present, or if its value is 0, the failure
+ counter is only reset by a successful authentication.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.12
+ NAME 'pwdFailureCountInterval'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+4.2.13. pwdMustChange
+
+ This attribute specifies with a value of "TRUE" that users must
+ change their passwords when they first bind to the directory after a
+ password is set or reset by the administrator. If this attribute is
+ not present, or if the value is "FALSE", users are not required to
+ change their password upon binding after the administrator sets or
+ resets the password.
+
+
+Behera, et. al. Expires August 15, 2004 Page 10
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.13
+ NAME 'pwdMustChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+4.2.14. pwdAllowUserChange
+
+ This attribute indicates whether users can change their own
+ passwords, although the change operation is still subject to access
+ control. If this attribute is not present, a value of "TRUE" is
+ assumed.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.14
+ NAME 'pwdAllowUserChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+4.2.15. pwdSafeModify
+
+ This attribute specifies whether or not the existing password must
+ be sent when changing a password. If this attribute is not present,
+ a "FALSE" value is assumed.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.15
+ NAME 'pwdSafeModify'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+4.3. Attribute Types for Password Policy State Information
+
+ Password policy state information must be maintained for each user.
+ The information is located in each user entry as a set of
+ operational attributes. These operational attributes are:
+ pwdChangedTime, pwdAccountLockedTime, pwdExpirationWarned,
+ pwdFailureTime, pwdHistory, pwdGraceUseTime, pwdReset,
+ pwdPolicySubEntry.
+
+4.3.1. Password Policy State Attribute Option
+
+ Since the password policy could apply to several attributes used to
+ store passwords, each of the above operational attributes must have
+ an option to specify which pwdAttribute is applies to.
+ The password policy option is defined as the following:
+ pwd-<passwordAttribute>
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 11
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ where passwordAttribute a string following the OID syntax
+ (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
+ (short name) MUST be used.
+
+ For example, if the pwdPolicy object has for pwdAttribute
+ "userPassword" then the pwdChangedTime operational attribute, in a
+ user entry, will be:
+ pwdChangedTime;pwd-userPassword: 20000103121520Z
+
+ This attribute option follows sub-typing semantics. If a client
+ requests a password policy state attribute to be returned in a
+ search operation, and does not specify an option, all subtypes of
+ that policy state attribute are returned.
+
+
+4.3.2. pwdChangedTime
+
+ This attribute specifies the last time the entry's password was
+ changed. This is used by the password expiration policy. If this
+ attribute does not exist, the password will never expire.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.16
+ NAME 'pwdChangedTime'
+ DESC 'The time the password was last changed'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SINGLE-VALUE
+ USAGE directoryOperation)
+
+4.3.3. pwdAccountLockedTime
+
+ This attribute holds the time that the user's account was locked. A
+ locked account means that the password may no longer be used to
+ authenticate. A 0 value means that the account has been locked
+ permanently, and that only an administrator can unlock the account.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.17
+ NAME 'pwdAccountLockedTime'
+ DESC 'The time an user account was locked'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SINGLE-VALUE
+ USAGE directoryOperation)
+
+4.3.4. pwdExpirationWarned
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 12
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ This attribute contains the time when the password expiration
+ warning was first sent to the client. The password will expire in
+ the pwdExpireWarning time.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.18
+ NAME 'pwdExpirationWarned'
+ DESC 'The time the user was first warned about the coming
+ expiration of the password'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SINGLE-VALUE
+ USAGE directoryOperation )
+
+4.3.5. pwdFailureTime
+
+ This attribute holds the timestamps of the consecutive
+ authentication failures.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.19
+ NAME 'pwdFailureTime'
+ DESC 'The timestamps of the last consecutive authentication
+ failures'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ USAGE directoryOperation )
+
+
+4.3.6. pwdHistory
+
+ This attribute holds a history of previously used passwords.
+
+ Values of this attribute are transmitted in string format as given
+ by the following ABNF:
+
+ pwdHistory = time "#" syntaxOID "#" length "#" data
+
+ time = <generalizedTimeString as specified in 6.14 of
+ [RFC2252]>
+
+ syntaxOID = numericoid ; the string representation of the
+ ; dotted-decimal OID that defines the
+ ; syntax used to store the password.
+ ; numericoid is described in 4.1 of
+ ; [RFC2252].
+
+ length = numericstring ; the number of octets in data.
+ ; numericstring is described in 4.1 of
+
+
+Behera, et. al. Expires August 15, 2004 Page 13
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ ; [RFC2252].
+
+ data = <octets representing the password in the format
+ specified by syntaxOID>.
+
+ This format allows the server to store, and transmit a history of
+ passwords that have been used. In order for equality matching to
+ function properly, the time field needs to adhere to a consistent
+ format. For this purpose, the time field MUST be in GMT format.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.20
+ NAME 'pwdHistory'
+ DESC 'The history of user s passwords'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ EQUALITY octetStringMatch
+ USAGE directoryOperation)
+
+4.3.7. pwdGraceUseTime
+
+ This attribute holds the timestamps of grace login once a password
+ has expired.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.21
+ NAME 'pwdGraceUseTime'
+ DESC 'The timestamps of the grace login once the password has
+ expired'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ EQUALITY generalizedTimeMatch
+
+ USAGE directoryOperation)
+
+4.3.8. pwdReset
+
+ This attribute holds a flag to indicate (when TRUE) that the
+ password has been reset and therefore must be changed by the user on
+ first authentication.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.22
+ NAME 'pwdReset'
+ DESC 'The indication that the password has been reset'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ USAGE directoryOperation)
+
+4.3.9. pwdPolicySubentry
+
+ This attribute points to the pwdPolicy subentry in effect for this
+ object.
+
+
+Behera, et. al. Expires August 15, 2004 Page 14
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.23
+ NAME 'pwdPolicySubentry'
+ DESC 'The pwdPolicy subentry in effect for this object'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ USAGE directoryOperation)
+
+5. Controls used for Password Policy
+
+ This section details the controls used while enforcing password
+ policy. A request control is defined that is sent by a client with a
+ request operation in order to elicit a response control. The
+ response control contains various warnings and errors associated
+ with password policy.
+
+5.1. Request Control
+
+ This control MAY be sent with any LDAP request message in order to
+ convey to the server that this client is aware of, and can process
+ the response control described in this document. When a server
+ receives this control, it will return the response control when
+ appropriate and with the proper data.
+
+ The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality
+ MUST be FALSE. There is no controlValue.
+
+ passwordPolicyRequest
+
+ controlType: 1.3.6.1.4.1.42.2.27.8.5.1
+ criticality: FALSE
+ controlValue: None
+
+5.2. Response Control
+
+ If the client has sent a passwordPolicyRequest control, the server
+ sends this control with the following operation responses:
+ bindResponse, modifyResponse, addResponse, compareResponse and
+ possibly extendedResponse, to inform of various conditions, and MAY
+ be sent with other operations (in the case of the changeAfterReset
+ error).
+
+ passwordPolicyResponse
+
+ controlType: 1.3.6.1.4.1.42.2.27.8.5.1
+ criticality: FALSE
+ controlValue: an OCTET STRING, whose value is the BER encoding of the
+ following type:
+
+
+Behera, et. al. Expires August 15, 2004 Page 15
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ PasswordPolicyResponseValue ::= SEQUENCE {
+ warning [0] CHOICE {
+ timeBeforeExpiration [0] INTEGER (0 .. maxInt),
+ graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL
+ error [1] ENUMERATED {
+ passwordExpired (0),
+ accountLocked (1),
+ changeAfterReset (2),
+ passwordModNotAllowed (3),
+ mustSupplyOldPassword (4),
+ insufficientPasswordQuality (5),
+ passwordTooShort (6),
+ passwordTooYoung (7),
+ passwordInHistory (8) } OPTIONAL }
+
+ The timeBeforeExpiration warning specifies the number of seconds
+ before a password will expire. The graceLoginsRemaining warning
+ specifies the remaining number of times a user will be allowed to
+ authenticate with an expired password. The passwordExpired error
+ signifies that the password has expired and must be reset. The
+ changeAfterReset error signifies that the password must be changed
+ before the user will be allowed to perform any operation other than
+ bind and modify. The passwordModNotAllowed error is set when a user
+ is restricted from changing her password. The
+ insufficientPasswordQuality error is set when a password doesn't
+ pass quality checking. The passwordTooYoung error is set if the age
+ of the password to be modified is not yet old enough.
+
+ Typically, only either a warning or an error will be encoded though
+ there may be exceptions. For example, if the user is required to
+ change a password after the administrator set it, and the password
+ will expire in a short amount of time, the control may include the
+ timeBeforeExpiration warning and the changeAfterReset error.
+
+
+6. Server Implementation by LDAP operation
+
+ The following sections contain detailed instructions that refer to
+ attributes of the pwdPolicy object class. When doing so, the
+ attribute of the pwdPolicy object that governs the entry being
+ discussed is implied.
+
+ The server SHOULD enforce that the password attribute subject to a
+ password policy as defined in this document, contains one and only
+ one password value.
+
+ The scenarios in the following operations assume that the client has
+ attached a passwordPolicyRequest control to the request message of
+
+
+Behera, et. al. Expires August 15, 2004 Page 16
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ the operation. In the event that the passwordPolicyRequest control
+ was not sent, no passwordPolicyRequest control is returned. All
+ other instructions remain the same.
+
+
+6.1. Bind Operation
+
+ When processing a bind request, the server MUST perform the
+ following steps:
+
+ 1. Check for a locked account:
+
+ If the value of the pwdAccountLockedTime attribute is 0, or if
+ the current time is less than the value of the
+ pwdAccountLockedTime attribute added to the value of the
+ pwdLockoutDuration, the account is locked.
+
+ If the account is locked, the server MUST send a bindResponse to
+ the client with the resultCode: unwillingToPerform (53), and MUST
+ include the passwordPolicyResponse in the controls field of the
+ bindResponse message with the error: accountLocked (1).
+
+ If the account is not locked, the server MUST proceed with the
+ bind operation.
+
+ 2. Check the result of the bind operation:
+
+ If the bind operation succeeds with authentication, the server
+ MUST do the following:
+
+ A. Delete the pwdFailureTime attribute.
+
+ B. Check whether the password must be changed now.
+
+ If the pwdMustChange attribute is set to TRUE, and if the
+ pwdReset attribute is set to TRUE, the password must be
+ changed now.
+
+ If the password must be changed now, the server MUST send a
+ bindResponse to the client with the resultCode: success (0),
+ and MUST include the passwordPolicyResponse in the controls
+ field of the bindResponse message with the warning:
+ changeAfterReset specified.
+ The server MUST then disallow all operations issued by this
+ user except modify password, bind, unbind, abandon and
+ StartTLS extended operation.
+
+ If the password does not need to be changed now, the operation
+ proceeds.
+
+
+Behera, et. al. Expires August 15, 2004 Page 17
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ C. Check for password expiration
+
+ The password has expired when either of the following
+ conditions is met:
+
+ - If the value of the pwdExpireWarning attribute is 0, the
+ server subtracts the current time from the time stored in
+ pwdChangedTime to arrive at the password's age. If the age
+ is greater than the value in the pwdMaxAge attribute, the
+ password has expired.
+
+ - If the value of the pwdExpireWarning attribute is non-
+ zero, and the pwdExpirationWarned attribute is present and
+ has a time value, the server subtracts the current time
+ from the time stored in the pwdExpirationWarned to arrive
+ at the first warning age. If the age is greater than the
+ value in the pwdExpireWarning attribute, the password has
+ expired.
+
+ If the password has expired, the server MUST check for
+ remaining grace logins.
+
+ If the pwdGraceUseTime attribute is present, the server
+ MUST count the number of values in that attribute and
+ subtract it from the pwdGraceLoginLimit. A positive result
+ specifies the number of remaining grace logins.
+
+ If there are remaining grace logins, the server MUST add a
+ new value with the current time in pwdGraceUseTime. Then
+ it MUST send a bindResponse with the resultCode: success
+ (0), and MUST include the passwordPolicyResponse in the
+ controls field of the bindResponse message with the
+ warning: graceLoginsRemaining choice set to the number of
+ grace logins left.
+
+ If there are no remaining grace logins, the server MUST
+ send a bindResponse with the resultCode:
+ invalidCredentials (49), and MUST include the
+ passwordPolicyResponse in the controls field of the
+ bindResponse message with the error: passwordExpired (0)
+ set.
+
+ If the password has not expired, execution continues.
+
+ D. Calculates whether the time before expiration warning should
+ be sent.
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 18
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ If the pwdExpireWarning attribute is present and contains a
+ value, the server MUST perform the following steps.
+
+ If the pwdExpirationWarned attribute is present and has a
+ time value, the warning time is the value of the
+ pwdExpirationWarned attribute plus the value of the
+ pwdExpireWarning attribute minus the current time.
+
+ If the pwdExpirationWarned attribute is not present, the
+ server MUST subtract the current time from the time stored
+ in pwdChangedTime to arrive at the password's age. If the
+ age is greater than the value of the pwdMaxAge attribute
+ minus the value of the pwdExpireWarning attribute, the
+ server MUST set the current time as the value of the
+ pwdExpirationWarned attribute, and the warning time is the
+ value of pwdMaxAge minus the password's age.
+
+ If the warning time is a positive number, the server MUST
+ send a bindResponse with the resultCode: success (0), and
+ MUST include the passwordPolicyResponse in the controls
+ field of the bindResponse message with the warning:
+ timeBeforeExiration set to the value as described above.
+
+ If the warning time is zero, or wasn't calculated, the
+ server MUST send a bindResponse with the resultCode:
+ success (0), and MUST include the passwordPolicyResponse
+ with nothing in the SEQUENCE.
+
+ If the pwdExpireWarning attribute is not present, the server
+ MUST send a bindResponse with the resultCode: success (0),
+ and MUST include the passwordPolicyResponse with nothing in
+ the SEQUENCE.
+
+ If the bind operation fails authentication due to invalid
+ credentials, the server MUST do the following:
+
+ A. Add the current time as a value of the pwdFailureTime
+ attribute.
+
+ B. If the pwdLockout attribute is TRUE, the server MUST also do
+ the following:
+
+ Count the number of values in the pwdFailureTime attribute
+ that are younger than pwdFailureCountInterval.
+
+ If the number of these failures is greater or equal to the
+ pwdMaxFailure attribute, the server MUST lock the account
+ by setting the value of the pwdAccountLockedTime attribute
+ to the current time. After locking the account, the server
+
+
+Behera, et. al. Expires August 15, 2004 Page 19
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ MUST send a bindResponse to the client with the
+ resultCode: unwillingToPerform (53), and MUST include the
+ passwordPolicyResponse in the controls field of the
+ bindResponse message with the error: accountLocked (1).
+
+ If the number of failures is less than the pwdMaxFailure
+ attribute, operation proceeds.
+
+ C. Failure times that are old by more than
+ pwdFailureCountInterval are purged from the pwdFailureTime
+ attribute.
+
+
+
+6.2. Modify Password Operation
+
+ Because the password is stored in an attribute, the modify operation
+ may be used to create or update a password. But some alternate
+ mechanisms have been defined or may be defined, such as the LDAP
+ Password Modify Extended Operation [RFC-3062].
+
+
+
+
+ While processing a password modification, the server MUST perform
+ the following steps:
+
+ 1. Check the pwdSafeModify attribute. If set to TRUE, the server
+ MUST ensure that the modify password operation included the
+ user's existing password. When the LDAP modify operation is used
+ to modify a password, this is done by specifying both a delete
+ action and an add or replace action, where the delete action is
+ first, and specifies the existing password, and the add or
+ replace action specifies the new password. Other password modify
+ operations SHOULD employ a similar mechanism. Otherwise this
+ policy will fail.
+
+ If the existing password is not specified, the server MUST NOT
+ process the operation and MUST send the appropriate response
+ message to the client with the resultCode: unwillingToPerform
+ (53), and MUST include the passwordPolicyResponse in the controls
+ field of the response message with the error:
+ mustSupplyOldPassword (4).
+
+
+ 2. Check the value of the pwdMustChange attribute. If TRUE, the
+ server MUST check the pwdReset attribute in the user's entry, to
+ see if a directory administrator has reset the password. If so,
+ it MUST ensure that the modify password operation contains no
+
+
+Behera, et. al. Expires August 15, 2004 Page 20
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ modifications other than the modification of the password
+ attribute. If other modifications exist, the server MUST send a
+ response message to the client with the resultCode:
+ unwillingToPerform (53), and MUST include the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: changeAfterReset (2).
+
+ 3. Check to see whether the bound identity has sufficient rights to
+ modify the password. If the bound identity is a user changing its
+ own password, this MAY be done by checking the pwdAllowUserChange
+ attribute or using an access control mechanism. The determination
+ of this is implementation specific. If the user is not allowed to
+ change her password, the server MUST send a response message to
+ the client with the resultCode: unwillingToPerform (53), and MUST
+ include the passwordPolicyResponse in the controls field of the
+ response message with the error: passwordModNotAllowed (3).
+
+ 4. Check the value of the pwdMinAge attribute. If it is set to a
+ non-zero value, the server MUST subtract the current time from
+ the value of the pwdChangedTime attribute to arrive at the
+ password's age. If the password's age is less than the value of
+ the pwdMinAge attribute, the password is too young to modify. In
+ this case, the server MUST send a response message to the client
+ with the resultCode: constraintViolation (19), and MUST include
+ the passwordPolicyResponse in the controls field of the response
+ message with the error: passwordTooYoung (7).
+
+ 5. Check the value of the pwdCheckQuality attribute.
+
+ If the value is non-zero, The server:
+
+ A. MUST ensure that the password meets the quality criteria
+ enforced by the server. This enforcement is implementation
+ specific.
+
+ If the server is unable to check the quality (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is
+ evaluated. If the value is 1, operation MUST continue. If the
+ value is 2, the server MUST send a response message to the
+ client with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the response message with the error:
+ insufficientPasswordQuality (5).
+
+ If the server is able to check the password quality, and the
+ check fails, the server MUST send a response message to the
+ client with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 21
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ the response message with the error:
+ insufficientPasswordQuality (5).
+
+ B. MUST check the value of the pwdMinLength attribute. If the
+ value is non-zero, it MUST ensure that the new password is of
+ at least the minimum length.
+
+ If the server is unable to check the length (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is
+ evaluated. If the value is 1, operation MUST continue. If the
+ value is 2, the server MUST send a response message to the
+ client with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the response message with the error: passwordTooShort (6).
+
+ If the server is able to check the password length, and the
+ check fails, the server MUST send a response message to the
+ client with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the response message with the error: passwordTooShort (6).
+
+ 6. Check the value of the pwdInHistory attribute. If the value is
+ non-zero, the server MUST check whether this password exists in
+ the entry's pwdHistory attribute or in the current password
+ attribute. If the password does exist in the pwdHistory attribute
+ or in the current password attribute, the server MUST send a
+ response message to the client with the resultCode:
+ constraintViolation (19), and MUST include the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: passwordInHistory (8).
+
+ If the steps have completed without causing an error condition, the
+ server MUST follow the following steps in order to update the
+ necessary password policy state attributes:
+
+ 7. Check the value of the pwdMaxAge attribute. If the value is non-
+ zero, or if the value of the pwdMinAge attribute is non-zero, the
+ server MUST update the pwdChangedTime attribute on the entry to
+ the current time.
+
+ 8. If the value of the pwdInHistory attribute is non-zero, the
+ server MUST add the previous password to the pwdHistory
+ attribute. If the number of attributes held in the pwdHistory
+ attribute exceeds the value of pwdInHistory, the server MUST
+ remove the oldest excess passwords.
+
+ 9. Remove the pwdFailureTime, pwdReset, pwdGraceUseTime and
+ pwdExpirationWarned attributes from the user's entry if they
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 22
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ exist.
+
+ The server MUST then apply the modify password operation.
+
+6.3. Add Operation
+
+ The password MAY be set during an Add operation. If it is, the
+ server MUST perform the following steps while processing the add
+ operation. Note that these are essentially duplicates of steps 3, 5
+ and 7 from Section 6.2 with the exception that pwdAllowUserChange is
+ not checked.
+
+ 1. Check to see whether the bound identity has sufficient rights to
+ modify the password. This MAY be done by the use of an access
+ control mechanism. If the user is not allowed to add this
+ password, the server MUST send an addResponse to the client with
+ the resultCode: unwillingToPerform (53), and MUST include the
+ passwordPolicyResponse in the controls field of the addResponse
+ message with the error: passwordModNotAllowed (3).
+
+ 2. Check the value of the pwdCheckQuality attribute.
+
+ If the value is non-zero, The server:
+
+ A. MUST ensure that the password meets the quality criteria
+ enforced by the server. This enforcement is implementation
+ specific.
+
+ If the server is unable to check the quality (due to a hashed
+ password or otherwise), the value of pwdCheckQuality MUST be
+ evaluated. If the value is 1, operation MUST continue. If the
+ value is 2, the server MUST send an addResponse to the client
+ with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the addResponse message with the error:
+ insufficientPasswordQuality (5).
+
+ If the server is able to check the password quality, and the
+ check fails, the server MUST send an addResponse to the client
+ with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the addResponse message with the error:
+ insufficientPasswordQuality (5).
+
+ B. MUST check the value of the pwdMinLength attribute. If the
+ value is non-zero, it MUST ensure that the new password is of
+ at least the minimum length.
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 23
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ If the server is unable to check the length (due to a hashed
+ password or otherwise), the value of pwdCheckQuality MUST be
+ evaluated. If the value is 1, operation MUST continue. If the
+ value is 2, the server MUST send an addResponse to the client
+ with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the addResponse message with the error: passwordTooShort (6).
+
+ If the server is able to check the password length, and the
+ check fails, the server MUST send an addResponse to the client
+ with the resultCode: constraintViolation (19), and MUST
+ include the passwordPolicyResponse in the controls field of
+ the addResponse message with the error: passwordTooShort (6).
+
+ If the steps above have completed without causing an error
+ condition, the server MUST follow the steps below in order to update
+ the necessary password policy state attributes.
+
+ 3. Check the value of the pwdMaxAge attribute. If the value is non-
+ zero, or if the value of the pwdMinAge attribute is non-zero, the
+ server MUST update the pwdChangedTime attribute on the entry to
+ the current time.
+
+6.4. Compare Operation
+
+ The compare operation MAY be used to compare a password. This might
+ be performed when a client wishes to verify that user's supplied
+ password is correct. An example of this is an LDAP HTTP
+ authentication redirector. It may be desirable to use this rather
+ than performing a bind operation in order to reduce possible
+ overhead involved in performing a bind. Access Controls SHOULD be
+ used to restrict this comparison from being made.
+
+ If a server supports this behavior, it MUST comply with the
+ following. Otherwise the password policy described in this document
+ may be circumvented.
+
+ While comparing password attributes, the server MUST perform the
+ following steps:
+
+ 1. Check for a locked account:
+
+ If the value of the pwdAccountLockedTime attribute is 0, or if
+ the current time is less than the value of the
+ pwdAccountLockedTime attribute added to the value of the
+ pwdLockoutDuration, the account is locked.
+
+ If the account is locked, the server MUST send a compareResponse
+ to the client with the resultCode: compareFalse (5), and MUST
+
+
+Behera, et. al. Expires August 15, 2004 Page 24
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ include the passwordPolicyResponse in the controls field of the
+ compareResponse message with the error: accountLocked (1).
+
+ If the account is not locked, the server MUST proceed with the
+ compare operation.
+
+ 2. If Access Controls permit, the server MUST proceed with compare
+ operation and MUST check the result.
+
+ If the result of the compare operation is true, the server MUST
+ do the following:
+
+ A. Delete the pwdFailureTime attribute.
+
+ B. Check for password expiration
+
+ The password has expired when either of the following
+ conditions is met:
+
+ - If the value of the pwdExpireWarning attribute is 0, the
+ server MUST subtract the current time from the time stored
+ in pwdChangedTime to arrive at the password's age. If the
+ age is greater than the value in the pwdMaxAge attribute,
+ the password has expired.
+
+ - If the value of the pwdExpireWarning attribute is non-
+ zero, and the pwdExpirationWarned attribute is present and
+ has a time value, the server MUST subtract the current
+ time from the time stored in the pwdExpirationWarned to
+ arrive at the first warning age. If the age is greater
+ than the value in the pwdExpireWarning attribute, the
+ password has expired.
+
+ If the password has expired, the server MUST check for
+ remaining grace logins.
+
+ If the pwdGraceUseTime attribute is present, the server
+ MUST count the number of values in that attribute and MUST
+ subtract it from the pwdGraceLoginLimit. A positive result
+ specifies the number of remaining grace logins.
+
+ If there are remaining grace logins, the server MUST add a
+ new value with the current time in pwdGraceUseTime. Then
+ it MUST send a compareResponse with the resultCode:
+ compareTrue (6), and MUST include the
+ passwordPolicyResponse in the controls field of the
+ compareResponse message with the warning:
+ graceLoginsRemaining choice set to the number of grace
+ logins left.
+
+
+Behera, et. al. Expires August 15, 2004 Page 25
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ If there are no remaining grace logins, the server MUST
+ send a compareResponse with the resultCode: compareFalse
+ (5), and MUST include the passwordPolicyResponse in the
+ controls field of the compareResponse message with the
+ error: passwordExpired (0) set.
+
+ If the password has not expired, execution MUST continue.
+
+ C. Calculate whether the time before expiration warning should be
+ sent.
+
+ If the pwdExpireWarning attribute is present and contains a
+ value, the server MUST perform the following steps.
+
+ If the pwdExpirationWarned attribute is present and has a
+ time value, the warning time is the value of the
+ pwdExpirationWarned attribute plus the value of the
+ pwdExpireWarning attribute minus the current time.
+
+ If the pwdExpirationWarned attribute is not present, the
+ server MUST subtract the current time from the time stored
+ in pwdChangedTime to arrive at the password's age. If the
+ age is greater than the value of the pwdMaxAge attribute
+ minus the value of the pwdExpireWarning attribute, the
+ server MUST set the current time as the value of the
+ pwdExpirationWarned attribute, and the warning time is the
+ value of pwdMaxAge minus the password's age.
+
+ If the warning time is a positive number, the server MUST
+ send a compareResponse with the resultCode: compareTrue
+ (6), and MUST include the passwordPolicyResponse in the
+ controls field of the compareResponse message with the
+ warning: timeBeforeExiration set to the value as described
+ above.
+
+ If the warning time is zero, or wasn't calculated, the
+ server MUST send a compareResponse with the resultCode:
+ compareTrue (6), and MUST include the
+ passwordPolicyResponse with nothing in the SEQUENCE.
+
+ If the pwdExpireWarning attribute is not present, the server
+ MUST send a compareResponse with the resultCode: compareTrue
+ (6), and MUST include the passwordPolicyResponse with nothing
+ in the SEQUENCE.
+
+ If the result of the compare operation is false, the server MUST
+ do the following:
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 26
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ A. Add the current time as a value of the pwdFailureTime
+ attribute.
+
+ B. If the pwdLockout attribute is TRUE, the server MUST do
+ the following:
+
+ Count the number of values in the pwdFailureTime
+ attribute that are younger than
+ pwdFailureCountInterval.
+
+ If the number of these failures is greater or equal to
+ the pwdMaxFailure attribute, the server MUST lock the
+ account by setting the value of the
+ pwdAccountLockedTime attribute to the current time.
+ After locking the account, the server MUST send a
+ compareResponse to the client with the resultCode:
+ compareFalse (5), and MUST include the
+ passwordPolicyResponse in the controls field of the
+ compareResponse message with the error: accountLocked
+ (1).
+
+ If the number of failures is less than the
+ pwdMaxFailure attribute, operation MUST proceed.
+
+ If the pwdLockout attribute is FALSE, operation MUST
+ continue.
+
+ C. Failure times that are old by more than
+ pwdFailureCountInterval, MUST be purged from the
+ pwdFailureTime attribute.
+
+ D. If no errors were returned, the server MUST send a
+ compareResponse with the resultCode: compareTrue (6), and
+ MUST include the passwordPolicyResponse with nothing in
+ the SEQUENCE.
+
+7. Client Implementation by LDAP operation
+
+ These sections illustrate possible scenarios for each LDAP operation
+ and define the types of responses that identify those scenarios.
+
+ The scenarios in the following operations assume that the client
+ attached a passwordPolicyRequest control to the request message of
+ the operation, and thus MAY receive a passwordPolicyResponse control
+ in the response message. In the event that the passwordPolicyRequest
+ control was not sent, no passwordPolicyRequest control is returned.
+ All other instructions remain the same.
+
+7.1. Bind Operation
+
+
+Behera, et. al. Expires August 15, 2004 Page 27
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ For every bind response received, the client MUST check the
+ resultCode of the bindResponse and MUST check for a
+ passwordPolicyResponse to determine if any of the following
+ conditions are true and MAY prompt the user accordingly.
+
+ 1. The password failure limit has been reached and the account is
+ locked. The user needs to retry later or contact the directory
+ administrator to reset the password.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: accountLocked (1)
+
+ 2. The user is binding for the first time after the directory
+ administrator set the password. In this scenario, the client
+ SHOULD prompt the user to change his password immediately.
+
+ resultCode: success (0)
+ passwordPolicyResponse: error: changeAfterReset (2)
+
+ 3. The password has expired but there are remaining grace logins.
+ The user needs to change it.
+
+ resultCode: success (0)
+ passwordPolicyResponse: warning: graceLoginsRemaining
+
+ 4. The password has expired and there are no more grace logins. The
+ user MUST contact the directory administrator in order to have
+ its password reset.
+
+ resultCode: invalidCredentials (49)
+ passwordPolicyResponse: error: passwordExpired (0)
+
+ 5. The user's password will expire in n number of seconds.
+
+ resultCode: success (0)
+ passwordPolicyResponse: warning: timeBeforeExpiration
+
+7.2. Modify Operations
+
+7.2.1. Modify Request
+
+ If the application or client encrypts the password prior to sending
+ it in a password modification operation (whether done through
+ modifyRequest or another password modification mechanism), it SHOULD
+ check the values of the pwdMinLength, and pwdCheckQuality attributes
+ and SHOULD enforce these policies.
+
+7.2.2. Modify Response
+
+
+Behera, et. al. Expires August 15, 2004 Page 28
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ If the modifyRequest operation was used to change the password, or
+ if another mechanism is used --such as an extendedRequest-- the
+ modifyResponse or other appropriate response MAY contain information
+ pertinent to password policy. The client MUST check the resultCode
+ of the response and MUST check for a passwordPolicyResponse to
+ determine if any of the following conditions are true and optionally
+ notify the user of the condition.
+
+ 1. The user attempted to change her password without specifying the
+ old password but the password policy requires this.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: mustSupplyOldPassword (4)
+
+ 2. The user MUST change her password before submitting any other
+ LDAP requests.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: changeAfterReset (2)
+
+ 3. The user doesn't have sufficient rights to change his password.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: passwordModNotAllowed (3)
+
+ 4. It is too soon after the last password modification to change the
+ password.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error: passwordTooYoung (7)
+
+ 5. The password failed quality checking.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error:
+ insufficientPasswordQuality (5)
+
+ 6. The length of the password is too short.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error: passwordTooShort (6)
+
+ 7. The password has already been used; the user MUST choose a
+ different one.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error: passwordInHistory (8)
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 29
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+7.3. Add Operation
+
+ If a password is specified in an addRequest, the client MUST check
+ the resultCode of the addResponse and MUST check for a
+ passwordPolicyResponse to determine if any of the following
+ conditions are true and may prompt the user accordingly.
+
+ 1. The user doesn't have sufficient rights to add this password.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: passwordModNotAllowed (3)
+
+ 2. The password failed quality checking.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error:
+ insufficientPasswordQuality (5)
+
+ 3. The length of the password is too short.
+
+ resultCode: constraintViolation (19)
+ passwordPolicyResponse: error: passwordTooShort (6)
+
+
+7.4. Compare Operation
+
+ When a compare operation is used to compare a password, the client
+ MUST check the resultCode of the compareResponse and MUST check for
+ a passwordPolicyResponse to determine if any of the following
+ conditions are true and MAY prompt the user accordingly. These
+ conditions assume that the result of the comparison was true.
+
+ 1. The password failure limit has been reached and the account is
+ locked. The user needs to retry later or contact the directory
+ administrator to reset the password.
+
+ resultCode: compareFalse (5)
+ passwordPolicyResponse: error: accountLocked (1)
+
+ 2. The password has expired but there are remaining grace logins.
+ The user needs to change it.
+
+ resultCode: compareTrue (6)
+ passwordPolicyResponse: warning: graceLoginsRemaining
+
+ 3. The password has expired and there are no more grace logins. The
+ user MUST contact the directory administrator to reset the
+ password.
+
+
+Behera, et. al. Expires August 15, 2004 Page 30
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+
+ resultCode: compareFalse (5)
+ passwordPolicyResponse: error: passwordExpired (0)
+
+ 4. The user's password will expire in n number of seconds.
+
+ resultCode: compareTrue (6)
+ passwordPolicyResponse: warning: timeBeforeExpiration
+
+
+7.5. Other Operations
+
+ For operations other than bind, unbind, abandon, search or StartTLS,
+ the client MUST check the following result code and control to
+ determine if the user needs to change the password immediately.
+
+ 1. The user needs to change password. The user SHOULD be prompted to
+ change the password immediately.
+
+ resultCode: unwillingToPerform (53)
+ passwordPolicyResponse: error: changeAfterReset (2)
+
+8. Administration of a Password Policy
+
+
+ A password policy MUST be defined for a particular subtree of the
+ DIT by adding to an LDAP subentry whose immediate superior is the
+ root of the subtree, the pwdPolicy auxiliary object class.
+ The scope of the password policy is defined by the
+ SubtreeSpecification attribute of the LDAP subentry as specified in
+ RFC 3672 [RFC-3672].
+
+ It is possible to define password policies for different password
+ attributes within the same pwdPolicy entry, by specifying multiple
+ values of the pwdAttribute. But password policies could also be in
+ separate sub entries as long as they are contained under the same
+ LDAP subentry.
+
+ Modifying the password policy MUST not result in any change in
+ users' entries to which the policy applies.
+
+ It SHOULD be possible to overwrite the password policy for one user
+ by defining a new policy in a subentry of the user entry.
+
+ Each object that is controlled by password policy SHALL advertise
+ the subentry that is being used to control its policy in its
+ pwdPolicySubentry attribute. Clients wishing to examine or manage
+ password policy for an object, MUST interrogate the
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 31
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ pwdPolicySubentry for that object in order to arrive at the proper
+ pwdPolicy subentry.
+
+9. Password Policy and Replication
+
+ The pwdPolicy object defines the password policy for a portion of
+ the DIT and MUST be replicated on all the replicas of this subtree,
+ as any subentry would be, in order to have a consistent policy among
+ all replicated servers.
+
+ The elements of the password policy that are related to the users
+ are stored in the entry themselves as operational attributes.
+ As these attributes are subject to modifications even on a read-only
+ replica, replicating them must be carefully considered.
+
+ The pwdChangedTime attribute MUST be replicated on all replicas, to
+ allow expiration of the password.
+
+ The pwdReset attribute MUST be replicated on all replicas, to deny
+ access to operations other than bind and modify password.
+
+ The pwdHistory attribute MUST be replicated to writable replicas. It
+ doesn't have to be replicated to a read-only replica, since the
+ password will never be directly modified on this server.
+
+ The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and
+ pwdGraceUseTime attributes MUST be replicated to writable replicas,
+ making the password policy global for all servers.
+ When the user entry is replicated to a read-only replica, these
+ attributes SHOULD NOT be replicated. This means that the number of
+ failures, of grace logins and the locking will take place on each
+ replicated server. For example, the effective number of failed
+ attempts on a user password will be N x M (where N is the number of
+ servers and M the value of pwdMaxFailure attribute).
+ Replicating these attributes to a read-only replica MAY reduce the
+ number of tries globally but MAY also introduce some inconstancies
+ in the way the password policy is applied.
+
+
+10. Security Considerations
+
+ This document defines a set of rules to implement in an LDAP server,
+ in order to mitigate some of the security risks associated with the
+ use of passwords and to make it difficult for password cracking
+ programs to break into directories.
+
+ Authentication with a password MUST follow the recommendations made
+ in RFC 2829 [RFC-2829].
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 32
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ Modifications of passwords SHOULD only occur when the connection is
+ protected with confidentiality and secure authentication.
+
+ Access controls SHOULD be used to restrict access to the password
+ policy attributes. Especially all the attributes defined to maintain
+ the Password Policy state information SHOULD not be modifiable by
+ anyone but the Administrator of the directory server.
+
+ As it is possible to define a password policy for one specific user
+ by adding a subentry immediately under the user's entry, Access
+ Controls SHOULD be used to restrict the use of the pwdPolicy object
+ class or the LDAP subentry object class.
+
+ When a password policy is put in place, the LDAP directory is
+ subject to a denial of service attack. A malicious user could
+ deliberately lock out one specific user's account (or all of them)
+ by sending bind requests with wrong passwords. There is no way to
+ protect against this kind of attack. The LDAP directory server
+ SHOULD log as much information as it can (such as client IP address)
+ whenever an account is locked, in order to be able to identify the
+ origin of the attack. Denying anonymous access to the LDAP directory
+ is also a way to restrict this kind of attacks.
+
+
+11. Acknowledgement
+
+ This document is based in part on prior work done by Valerie Chu
+ from Netscape Communications Corp, published as draft-vchu-ldap-pwd-
+ policy-00.txt (December 1998).
+
+
+12. Normative References
+
+ [RFC-2119] S. Bradner, "Key Words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC-2195] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize
+ Extension for Simple Challenge/Response", RFC 2195, September 1997.
+
+ [RFC-2222] J. Myers, "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [RFC-2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, August 1997.
+
+ [RFC-2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S.,
+ "Lightweight Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 33
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ [RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest
+ Authentication as a SASL Mechanism", RFC 2831, May 2000.
+
+ [RFC-3062] K. Zeilenga, "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC-3672] K. Zeilenga, S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December.
+
+
+13. Authors' Addresses
+
+ Prasanta Behera
+ 18366 Chelmsford Dr.
+ Cupertino, CA 95014
+ USA
+ prasantabehera@yahoo.com
+
+ Ludovic Poitou
+ Sun Microsystems Inc.
+ 180, Avenue de l'Europe
+ Zirst de Montbonnot
+ 38334 Saint Ismier cedex
+ France
+ +33 476 188 212
+ ludovic.poitou@sun.com
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ +1 801 861-3088
+ jimse@novell.com
+
+14. Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights
+ Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+
+
+Behera, et. al. Expires August 15, 2004 Page 34
+\f
+INTERNET DRAFT LDAP Password Policy 15 February 2004
+
+
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Behera, et. al. Expires August 15, 2004 Page 35
+\f
+
--- /dev/null
+
+
+
+Application Working Group M. Ansari
+INTERNET-DRAFT Sun Microsystems, Inc.
+Expires Febuary 2003 L. Howard
+ PADL Software Pty. Ltd.
+ B. Joslin [ed.]
+ Hewlett-Packard Company
+
+ September 15th, 2003
+Intended Category: Informational
+
+
+ A Configuration Schema for LDAP Based
+ Directory User Agents
+ <draft-joslin-config-schema-07.txt>
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This
+ memo does not specify an Internet standard of any kind. Distribu-
+ tion of this memo is unlimited.
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or made obsolete
+ by other documents at any time. It is not appropriate to use
+ Internet-Drafts as reference material or to cite them other than as
+ a "working draft" or "work in progress".
+
+ To learn the current status of any Internet-Draft, please check the
+ 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+ Directories on ds.internic.net (US East Coast), nic.nordu.net
+ (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+ Rim).
+
+ Distribution of this document is unlimited.
+
+Abstract
+
+ This document describes a mechanism for global configuration of
+ similar directory user agents. This document defines a schema for
+
+
+
+Joslin [Page 1]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ configuration of these DUAs that may be discovered using the Light-
+ weight Directory Access Protocol in RFC 2251[17]. A set of attri-
+ bute types and an objectclass are proposed, along with specific
+ guidelines for interpreting them. A significant feature of the
+ global configuration policy for DUAs is a mechanism that allows
+ DUAs to re-configure their schema to that of the end user's
+ environment. This configuration is achieved through attribute and
+ objectclass mapping. This document is intended to be a skeleton
+ for future documents that describe configuration of specific DUA
+ services.
+
+
+1. Background & Motivation
+
+ The LDAP protocol has brought about a new and nearly ubiquitous
+ acceptance of the directory server. Many new client applications
+ (DUAs) are being created that use LDAP directories for many dif-
+ ferent services. And although the LDAP protocol has eased the
+ development of these applications, some challenges still exist for
+ both developers and directory administrators.
+
+ The authors of this document are implementers of DUAs described by
+ RFC 2307 [14]. In developing these agents, we felt there are
+ several issues that still need to be addressed to ease the deploy-
+ ment and configuration of a large network of these DUAs.
+
+ One of these challenges stems from the lack of a utopian schema. A
+ utopian schema would be one that every application developer could
+ agree upon and that would support every application. Unfortunately
+ today, many DUAs define their own schema (like RFC 2307 vs.
+ Microsoft's Services for Unix [13]) containing similar attributes,
+ but with different attribute names. This can lead to data redun-
+ dancy within directory entries and give directory administrators
+ unwanted challenges, updating schemas and synchronizing data.
+
+ So, one goal of this document is to eliminate data redundancy by
+ having DUAs configure themselves to the schema of the deployed
+ directory, instead of forcing it's own schema on the directory.
+
+ Another goal of this document is to provide the DUA with enough
+ configuration information so that it can discover how to retrieve
+ its data in the directory, such as what locations to search in the
+ directory tree.
+
+ Finally, this document intends to describe a configuration method
+ for DUAs that can be shared among many DUAs, on various platforms,
+ providing as such, a configuration profile, the purpose is to cen-
+ tralize and simplify management of DUAs.
+
+
+
+Joslin [Page 2]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ This document is intended to provide the skeleton framework for
+ future drafts, which will describe the individual implementation
+ details for the particular services provided by that DUA. The
+ authors of this document plan to develop such a document for the
+ Network Information Service DUA, described by RFC 2307 or its suc-
+ cessor.
+
+ We expect that as DUAs take advantage of this configuration scheme,
+ each DUA will require additional configuration parameters, not
+ specified by this document. Thus, we would expect that new auxili-
+ ary object classes, containing new configuration attributes will be
+ created, and then joined with the structural class defined by this
+ document to create a configuration profile for a particular DUA
+ service. And that by joining various auxiliary objectclasses for
+ different DUA services, that configuration of various DUA services
+ can be controlled by a single configuration profile entry.
+
+
+2. General Issues
+
+ The schema defined by this document is defined under the "DUA Con-
+ figuration Schema." This schema is derived from the OID: iso (1)
+ org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett-
+ Packard Company (11) directory (1) LDAP-UX Integration Project (3)
+ DUA Configuration Schema (1). This OID is represented in this
+ document by the keystring "DUAConfSchemaOID"
+ (1.3.6.1.4.1.11.1.3.1).
+
+2.1 Terminology
+
+ 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 RFC 2119 [15].
+
+2.2 Attributes
+
+ The attributes and classes defined in this document are summarized
+ below.
+
+ The following attributes are defined in this document:
+
+ preferredServerList
+ defaultServerList
+ defaultSearchBase
+ defaultSearchScope
+ authenticationMethod
+ credentialLevel
+ serviceSearchDescriptor
+
+
+
+Joslin [Page 3]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ serviceCredentialLevel
+ serviceAuthenticationMethod
+ attributeMap
+ objectclassMap
+ searchTimeLimit
+ bindTimeLimit
+ followReferrals
+ dereferenceAliases
+ profileTTL
+
+2.3 Object Classes
+
+ The following object class is defined in this document:
+
+ DUAConfigProfile
+
+2.4 Syntax Definitions
+
+ The following syntax definitions are used throughout this document.
+ This document does not define new syntaxes that must be supported
+ by the directory server. The string encoding used by the attri-
+ butes defined in this document can be found section 5.
+
+ keystring as defined by RFC 2252 [2]
+ descr as defined by RFC 2252 section 4.1
+ a as defined by RFC 2252 section 4.1
+ d as defined by RFC 2252 section 4.1
+ space as defined by RFC 2252 section 4.1
+ whsp as defined by RFC 2252 section 4.1
+ base as defined by RFC 2253 [3]
+ DistinguishedName as defined by RFC 2253 section 2
+ RelativeDistinguishedName as defined by RFC 2253 section 2
+ scope as defined by RFC 2255 [5]
+ IPv4address as defined by RFC 2396 [9]
+ hostport as defined by RFC 2396 section 3.2.2
+ port as defined by RFC 2396 section 3.2.2
+ ipv6reference as defined by RFC 2732 [10]
+ host as defined by RFC 2732 section 3
+ serviceID = keystring
+
+
+3. Attribute Definitions
+
+ This section contains attribute definitions to be used by DUAs when
+ discovering their configuration.
+
+ ( DUAConfSchemaOID.1.0 NAME 'defaultServerList'
+ DESC 'Default LDAP server host address used by a DUA'
+
+
+
+Joslin [Page 4]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase'
+ DESC 'Default LDAP base DN used by a DUA'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
+ DESC 'Preferred LDAP server host addresses to be used by a
+ DUA'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit'
+ DESC 'Maximum time in seconds a DUA should allow for a
+ search to complete'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit'
+ DESC 'Maximum time in seconds a DUA should allow for the
+ bind operation to complete'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.5 NAME 'followReferrals'
+ DESC 'Tells DUA if it should follow referrals
+ returned by a DSA search result'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
+ DESC 'Tells DUA if it should dereference aliases'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
+ DESC 'A keystring which identifies the type of
+ authentication method used to contact the DSA'
+ EQUALITY caseIgnoreMatch
+
+
+
+Joslin [Page 5]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.7 NAME 'profileTTL'
+ DESC 'Time to live, in seconds, before a client DUA
+ should re-read this configuration profile'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
+ DESC 'LDAP search descriptor list used by a DUA'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( DUAConfSchemaOID.1.9 NAME 'attributeMap'
+ DESC 'Attribute mappings used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
+ DESC 'Identifies type of credentials a DUA should
+ use when binding to the LDAP server'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
+ DESC 'Objectclass mappings used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope'
+ DESC 'Default search scope used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
+ DESC 'Identifies type of credentials a DUA
+ should use when binding to the LDAP server for a
+ specific service'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
+ DESC 'Authentication method used by a service of the DUA'
+ EQUALITY caseIgnoreMatch
+
+
+
+Joslin [Page 6]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+4. Class Definition
+
+ The objectclass below is constructed from the attributes defined in
+ 3, with the exception of the cn attribute, which is defined in RFC
+ 2256 [8]. cn is used to represent the name of the DUA configura-
+ tion profile.
+
+ ( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile'
+ SUP top STRUCTURAL
+ DESC 'Abstraction of a base configuration for a DUA'
+ MUST ( cn )
+ MAY ( defaultServerList $ preferredServerList $
+ defaultSearchBase $ defaultSearchScope $
+ searchTimeLimit $ bindTimeLimit $
+ credentialLevel $ authenticationMethod $
+ followReferrals $ dereferenceAliases $
+ serviceSearchDescriptor $ serviceCredentialLevel $
+ serviceAuthenticationMethod $ objectclassMap $
+ attributeMap $ profileTTL ) )
+
+
+5. Implementation Details
+
+5.1.1 Interpreting the preferredServerList attribute
+
+ Interpretation:
+
+ As described by the syntax, the preferredServerList parameter
+ is a white-space separated list of server addresses and asso-
+ ciated port numbers. When the DUA needs to contact a DSA, the
+ DUA MUST first attempt to contact one of the servers listed in
+ the preferredServerList attribute. The DUA MUST contact the
+ DSA specified by the first server address in the list. If
+ that DSA is unavailable, the remaining DSAs MUST be queried in
+ the order provided until a connection is established with a
+ DSA. Once a connection with a DSA is established, the DUA
+ SHOULD NOT attempt to establish a connection with the remain-
+ ing DSAs.
+
+ If the DUA is unable to contact any of the DSAs specified by
+ the preferredServerList, the defaultServerList attribute MUST
+ be examined, as described in 5.1.2. The servers identified by
+ the preferredServerList MUST be contacted before attempting to
+ contact any of the servers specified by the defaultServerList.
+
+
+
+
+Joslin [Page 7]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Syntax:
+
+ serverList = host *(space [host])
+
+ Default Value:
+
+ The preferredServerList attribute does not have a default
+ value. Instead a DUA MUST examine the defaultServerList
+ attribute.
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the defaultServer-
+ List attribute. Please see section 5.1.2 for additional
+ implementation notes. Determining how the DUA should query
+ the DSAs also depends on the additional configuration attri-
+ butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ serviceAuthenticationMethod and authenticationMethod. Please
+ review section 5.2 for details on how a Posix DUA should prop-
+ erly bind to a DSA.
+
+ Example:
+
+ preferredServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
+ [1080::8:800:200C:417A]:1389
+
+5.1.2 Interpreting the defaultServerList attribute
+
+ Interpretation:
+
+ The defaultServerList attribute MUST only be examined if the
+ preferredServerList attribute is not provided, or the DUA is
+ unable to establish a connection with one of the DSAs speci-
+ fied by the preferredServerList.
+
+ If more than one address is provided, the DUA may choose to
+ either accept the order provided, or choose to create its own
+ order, based on what the DUA determines is the "best" order of
+ servers to query. For example, the DUA may choose to examine
+ the server list and choose to query the DSAs in order based on
+ the "closest" server or the server with the least amount of
+ "load." Interpretation of the "best" server order is entirely
+ up to the DUA, and not part of this document.
+
+ Once the order of server addresses is determined, the DUA con-
+ tacts the DSA specified by the first server address in the
+ list. If that DSA is unavailable, the remaining DSAs SHOULD
+ be queried until an available DSA is found or no more DSAs are
+
+
+
+Joslin [Page 8]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ available. If a server address or port is invalid, the DUA
+ SHOULD proceed to the next server address as described just
+ above.
+
+ Syntax:
+
+ serverList = host *(space [host])
+
+ Default Value:
+
+ If a defaultServerList attribute is not provided, the DUA
+ should xxx attempt to contact the same DSA that provided the
+ configuration profile entry itself. The default DSA is con-
+ tacted only if the preferredServerList attribute is also not
+ provided.
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the preferredSer-
+ verList attribute. Please see section 5.1.1 for additional
+ implementation notes. Determining how the DUA should query
+ the DSAs also depends on the additional configuration attri-
+ butes, credentialLevel, serviceCredentialLevel, bindTimeLimit,
+ serviceAuthenticationMethod and authenticationMethod. Please
+ review section 5.2 for details on how a DUA should properly
+ contact a DSA.
+
+ Example:
+
+ defaultServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389
+ [1080::8:800:200C:417A]:1389
+
+5.1.3 Interpreting the defaultSearchBase attribute
+
+ Interpretation:
+
+ When a DUA needs to search the DSA for information, this
+ attribute provides the "base" for the search. This parameter
+ can be overridden or appended by the serviceSearchDescriptor
+ attribute. See section 5.1.6.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.12
+
+ Default Value:
+
+ There is no default value for the defaultSearchBase. A DUA
+
+
+
+Joslin [Page 9]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ MAY define its own method for determining the search base, if
+ the defaultSearchBase is not provided.
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the serviceSear-
+ chDescriptor attribute. See section 5.1.6.
+
+ Example:
+
+ defaultSearchBase: dc=mycompany,dc=com
+
+5.1.4 Interpreting the authenticationMethod attribute
+
+ Interpretation:
+
+ The authenticationMethod attribute defines an ordered list of
+ LDAP bind methods to be used when attempting to contact a
+ DSA[1]. The serviceAuthenticationMethod overrides this value
+ for a particular service (see 5.1.15.) Each method MUST be
+ attempted in the order provided by the attribute, until a suc-
+ cessful LDAP bind is performed ("none" is assumed to always be
+ successful.) However the DUA MAY skip over one or more
+ methods. See section 5.2 for more information.
+
+ none - The DUA does not perform an LDAP bind.
+ simple - The DUA performs an LDAP simple bind.
+ sasl - The DUA performs an LDAP SASL bind using the
+ specified SASL mechanism and options.
+ tls - The DUA performs an LDAP StartTLS operation
+ followed by the specified bind method (for more
+ information refer to section 5.1 of RFC 2830 [12]).
+
+ Syntax:
+
+ authMethod = method *(";" method)
+ method = none | simple | sasl | tls
+ none = "none"
+ simple = "simple"
+ sasl = "sasl/" saslmech [ ":" sasloption ]
+ sasloption = "auth-conf" | "auth-int"
+ tls = "tls:" (none | simple | sasl)
+ saslmech = SASL mechanism name as defined in
+ RFC 2222[7], section 3
+
+ Note: Although multiple authentication methods may be speci-
+ fied in the syntax, at most one of each type is allowed.
+
+
+
+
+Joslin [Page 10]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Default Value:
+
+ If the authenticationMethod or serviceAuthenticationMethod
+ (for that particular service) attributes are not provided, the
+ DUA MAY choose to bind to the DSA using any method defined by
+ the DUA. However, if either authenticationMethod or servi-
+ ceAuthenticationMethod are provided, the DUA MUST only use the
+ methods specified.
+
+ Other attribute notes:
+
+ When using TLS, the string "tls:sasl/EXTERNAL" implies that
+ two way authentication is to be performed. Any other TLS
+ authentication method implies one way (DSA side credential)
+ authentication.
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, credentialLevel,
+ serviceCredentialLevel, serviceAuthenticationMethod and
+ bindTimeLimit. Please review section 5.2 for details on how
+ to properly bind to a DSA.
+
+ Example:
+
+ authenticationMethod: tls:simple;sasl/DIGEST-MD5
+ (see [11])
+
+5.1.5 Interpreting the credentialLevel attribute
+
+ Interpretation:
+
+ The credentialLevel attribute defines what type(s) of
+ credential(s) the DUA SHOULD use when contacting the DSA. The
+ serviceCredentialLevel overrides this value for a particular
+ service (5.1.16.) The credentialLevel can contain more than
+ one credential type, separated by white space.
+
+ anonymous - The DUA SHOULD NOT use a credential when binding
+ to the DSA.
+
+ proxy - The DUA SHOULD use a known proxy identity when binding
+ to the DSA. A proxy identity is a specific credential that
+ was created to represent the DUA. This document does not
+ define how the proxy user should be created, or how the DUA
+ should determine what the proxy user's credential is. This
+ functionality is up to each implementation.
+
+ self - When the DUA is acting on behalf of a "real user" the
+
+
+
+Joslin [Page 11]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ DUA SHOULD attempt to bind to the DSA as that user. The DUA
+ SHOULD map the user's identity to a credential used in the
+ directory.
+
+ If the credentialLevel contains more than one credential type,
+ the DUA MUST use the credential types in the order specified.
+ However, the DUA MAY skip over one or more credential types.
+ As soon as the DUA is able to successfully bind to the DSA,
+ the DUA SHOULD NOT attempt to bind using the remaining creden-
+ tial types.
+
+ Syntax:
+
+ credentialLevel = level *(space level)
+ level = self | proxy | anonymous
+ self = "self"
+ proxy = "proxy"
+ anonymous = "anonymous"
+
+ Note: Although multiple credential levels may be specified in
+ the syntax, at most one of each type is allowed. Refer to
+ implementation notes in section 5.2 for additional syntax
+ requirements for the credentialLevel attribute.
+
+ Default Value:
+
+ If the credentialLevel attribute is not defined, the DUA
+ SHOULD NOT use a credential when binding to the DSA (also
+ known as anonymous.)
+
+ Other attribute notes:
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, authentication-
+ Method, serviceAuthenticationMethod, serviceCredentialLevel
+ and bindTimeLimit. Please review section 5.2 for details on
+ how to properly bind to a DSA.
+
+ Example:
+
+ credentialLevel: proxy anonymous
+
+5.1.6 Interpreting the serviceSearchDescriptor attribute
+
+ Interpretation:
+
+ The serviceSearchDescriptor attribute defines how and where a
+ DUA SHOULD search for information for a particular service.
+
+
+
+Joslin [Page 12]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ The serviceSearchDescriptor contains a serviceID, followed by
+ one or more base-scope-filter triples. These base-scope-
+ filter triples are used to define searches only for the
+ specific service. Multiple base-scope-filters allow the DUA
+ to search for data in multiple locations of the DIT. Although
+ this syntax is very similar to the LDAP URL[6], this draft
+ requires the ability to supply multiple hosts as part of the
+ configuration of the DSA. In addition, an ordered list of
+ search descritors is required, which can not be specified by
+ the LDAP URL.
+
+ In addition to the triples, serviceSearchDescriptor might also
+ contain the DN of an entry that will contain an alternate pro-
+ file. The DSA SHOULD re-evaluate the alternate profile and
+ perform searches as specified by that profile.
+
+ If the base, as defined in the serviceSearchDescriptor, is
+ followed by the "," (ASCII 0x2C) character, this base is known
+ as a relative base. This relative base may be constructed of
+ one or more RDN components. The DUA MUST define the search
+ base by appending the relative base with the defaultSear-
+ chBase.
+
+ Syntax:
+
+ serviceSearchList = serviceID ":" serviceSearchDesc
+ *(";" serviceSearchDesc)
+ serviceSearchDesc = confReferral | searchDescriptor
+ searchDescriptor = [base] ["?" [scope] ["?" [filter]]]
+ confReferral = "ref:" DistinguishedName
+ base = DistinguishedName |
+ RelativeBaseName
+ RelativeBaseName = 1*(RelativeDistinguishedName ",")
+ filter = UTF-8 encoded string
+
+ If the base or filter contains the ";" (ASCII 0x3B) "?" (ASCII
+ 0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those
+ characters MUST be escaped (preceded with the "\" character.)
+ Alternately the DN may be surrounded by quotes (ASCII 0x22.)
+ Refer to RFC 2253, section 4. If the base or filter are sur-
+ rounded by quotes, only the """ character needs to be escaped.
+ Any character that is preceded by the "\" character, which
+ does not need to be escaped results in both "\" character and
+ the character itself.
+
+ The usage and syntax of the filter string MUST be defined by
+ the DUA service. A suggested syntax would be that as defined
+ by RFC 2254.
+
+
+
+Joslin [Page 13]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ If a DUA is performing a search for a particular service,
+ which has a serviceSearchDescriptor defined, the DUA MUST set
+ the base, scope and filter as defined. Each base-scope-filter
+ triple represents a single LDAP search operation. If multiple
+ base-scope-filter triples are provided in the serviceSear-
+ chDescriptor, the DUA SHOULD perform multiple search requests
+ and in that case it MUST be in the order specified by the ser-
+ viceSearchDescriptor.
+
+ FYI: Service search descriptors do not exactly follow the LDAP
+ URL syntax [5]. The reasoning for this difference is to
+ separate the host name(s) from the filter. This allows the
+ DUA to have a more flexible solution in choosing its provider.
+
+ Default Values:
+
+ If a serviceSearchDescriptor, or an element their-of, is not
+ defined for a particular service, the DUA SHOULD create the
+ base, scope and filter as follows:
+
+ base - Same as the defaultSearchBase or as
+ defined by the DUA service.
+ scope - Same as the defaultSearchScope or as
+ defined by the DUA service.
+ filter - Use defaults as defined by DUAs service.
+
+ If the defaultSearchBase or defaultSearchScope are not
+ defined, then the DUA service may use its own default.
+
+
+ Other attribute notes:
+
+ If a serviceSearchDescriptor exists for a given service, the
+ service MUST use at least one base-scope-filter triple in per-
+ forming searches. It SHOULD perform multiple searches per
+ service if multiple base-scope-filter triples are defined for
+ that service.
+
+ The details of how the "filter" is interpreted by each DUA's
+ service is defined by that service. This means the filter is
+ NOT REQUIRED to be a legal LDAP filter [4]. Furthermore,
+ determining how attribute and objectclass mapping affects that
+ search filter MUST be defined by the service. I.E. The DUA
+ SHOULD specify if the filter has been assumed to already have
+ been mapped, or if it is expected that mapping would be
+ applied to the filter. In general practice, implementation
+ and usability suggests that attribute and objectclass mapping
+ (sections 5.1.7 and 5.1.13) SHOULD NOT be applied to the
+
+
+
+Joslin [Page 14]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ filter defined in the serviceSearchDescriptor.
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of any DUA that might use the given profile.
+
+ Example:
+
+ defaultSearchBase: dc=mycompany,dc=com
+
+ serviceSearchDescriptor: email:ou=people,ou=org1,?
+ one;ou=contractor,?one;
+ ref:cn=profile,dc=mycompany,dc=com
+
+ In this example, the DUA MUST search in
+ "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then
+ SHOULD search in "ou=contractor,dc=mycompany,dc=com", and
+ finally it SHOULD search other locations as specified in the
+ profile described at "cn=profile,dc=mycompany,dc=com". For
+ more examples, see section 9.
+
+
+5.1.7 Interpreting the attributeMap attribute
+
+ Interpretation:
+
+ A DUA SHOULD perform attribute mapping for all LDAP operations
+ performed for a service that has an attributeMap entry.
+ Because attribute mapping is specific to each service within
+ the DUA, a "serviceID" is required as part of the attributeMap
+ syntax. I.E. not all DUA services should necessarily perform
+ the same attribute mapping.
+
+ Attribute mapping in general is expected be used to map attri-
+ butes of similar syntaxes as specified by the service sup-
+ ported by the DUA. However, a DUA is NOT REQUIRED to verify
+ syntaxes of mapped attributes. If the DUA does discover that
+ the syntax of the mapped attribute does not match that of the
+ original attribute, the DUA MAY perform translation between
+ the original syntax and the new syntax. When DUAs do support
+ attribute value translation, the list of capabable transla-
+ tions SHOULD be documented in a description of the DUA ser-
+ vice.
+
+ Syntax:
+
+ attributeMap = serviceID ":" origAttribute "="
+ attributes
+ origAttribute = attribute
+
+
+
+Joslin [Page 15]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ attributes = wattribute *( space wattribute )
+ wattribute = whsp newAttribute whsp
+ newAttribute = descr | "*NULL*"
+ attribute = descr
+
+ Values of the origAttribute are defined by and SHOULD be docu-
+ mented for the DUA service, as a list of known supported
+ attributes.
+
+ Default Value:
+
+ By default, attributes that are used by a DUA service are not
+ mapped unless mapped by the attributeMap attributes. The DUA
+ MUST NOT map an attribute unless it is explicitly defined by
+ an attributeMap attribute.
+
+ Other attribute notes:
+
+ When an attribute is mapped to the special keystring "*NULL*",
+ the DUA SHOULD NOT request that attribute from the DSA, when
+ performing a search or compare request. If the DUA is also
+ capable of performing modification on the DSA, the DUA SHOULD
+ NOT attempt to modify any attribute which has been mapped to
+ "*NULL*".
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of the DSA.
+
+ A DUA SHOULD support attribute mapping. If it does, the fol-
+ lowing additional rules apply:
+
+ 1) The list of attributes that are allowed to be mapped SHOULD
+ defined by and documented for the service.
+
+ 2) Any supported translation of mapping from attributes of
+ dissimilar syntax SHOULD also be defined and documented.
+
+ 3) If an attribute may be mapped to multiple attributes the
+ DSA SHOULD define a syntax or usage statement for how the new
+ attribute value will be evaluated. Furthermore, the resulting
+ translated syntax of the combined attributes MUST be the same
+ as the attribute being mapped.
+
+ 4) A DUA MUST support mapping of attributes using the attri-
+ bute OID. It SHOULD support attribute mapping based on the
+ attribute name.
+
+ 5) It is recommended that attribute mapping not be applied to
+
+
+
+Joslin [Page 16]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ parents of the target entries.
+
+ 6) Attribute mapping is not recursive. In other words, if an
+ attribute has been mapped to a target attribute, that new tar-
+ get attribute MUST NOT be mapped to a third attribute.
+
+ 7) A given attribute MUST only be mapped once for a given ser-
+ vice.
+
+
+ Example:
+
+ Suppose a DUA is acting on behalf of an email service. By
+ default the "email" service uses the "mail", "cn" and "sn"
+ attributes to discover mail addresses. However, the email
+ service has been deployed in an environment that uses "employ-
+ eeName" instead of "cn." And also instead of using the "mail"
+ attribute for email addresses, the "email" attribute is used
+ for that purpose. In this case, the attribute "cn" can be
+ mapped to "employeeName," allowing the DUA to perform searches
+ using the "employeeName" attribute as part of the search
+ filter, instead of "cn". And "mail" can be mapped to "email"
+ when attempting to retrieve the email address. This mapping
+ is performed by adding the attributeMap attributes to the con-
+ figuration profile entry as follows (represented in LDIF[18]):
+
+ attributeMap: email:cn=employeeName
+ attributeMap: email:mail=email
+
+ As described above, the DUA MAY also map a single attribute to
+ multiple attributes. When mapping a single attribute to more
+ than one attribute, the new syntax or usage of the mapped
+ attribute must be intrinsically defined by the DUAs service.
+
+ attributeMap: email:cn=firstName lastName
+
+ In the above example, the DUA creates the new value by gen-
+ erating space separated string using the values of the mapped
+ attributes. In this case, a special mapping must be defined
+ so that a proper search filter can be created. For further
+ information on this example, please refer to section 9.
+
+ Another possibility for multiple attribute mapping might come
+ in when constructing returned attributes. For example,
+ perhaps all email addresses are of a guaranteed syntax of
+ "uid@domain". And in this example, the uid and domain are
+ separate attributes in the directory. The email service may
+ define that if the "mail" attribute is mapped to two different
+
+
+
+Joslin [Page 17]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ attributes, it will construct the email address as a concate-
+ nation of the uid and domain attributes, placing the "@" char-
+ acter between them.
+
+ attributeMap: email:mail=uid domain
+
+
+5.1.8 Interpreting the searchTimeLimit attribute
+
+ Interpretation:
+
+ The searchTimeLimit attribute defines the maximum time, in
+ seconds, that a DUA SHOULD allow to perform a search request.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+
+ Default Value:
+
+ If the searchTimeLimit attribute is not defined or is zero,
+ the search time limit is not enforced by the DUA.
+
+ Other attribute notes:
+
+ This time limit only includes the amount of time required to
+ perform the LDAP search operation. If other operations are
+ required, those operations do not need to be considered part
+ of the search time. See bindTimeLimit for the LDAP bind
+ operation.
+
+5.1.9 Interpreting the bindTimeLimit attribute
+
+ Interpretation:
+
+ The bindTimeLimit attribute defines the maximum time, in
+ seconds, that a DUA SHOULD allow to perform an LDAP bind
+ request against each server on the preferredServerList or
+ defaultServerList.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+
+ Default Value:
+
+ If the bindTimeLimit attribute is not defined or is zero, the
+ bind time limit is not enforced by the DUA.
+
+
+
+Joslin [Page 18]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Other attribute notes:
+
+ This time limit only includes the amount of time required to
+ perform the LDAP bind operation. If other operations are
+ required, those operations do not need to be considered part
+ of the bind time. See searchTimeLimit for the LDAP search
+ operation.
+
+5.1.10 Interpreting the followReferrals attribute
+
+ Interpretation:
+
+ If set to TRUE, the DUA SHOULD follow any referrals if
+ discovered.
+
+ If set to FALSE, the DUA MUST NOT follow referrals.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
+
+ Default Value:
+
+ If the followReferrals attribute is not set or set to an
+ invalid value the default value is TRUE.
+
+5.1.11 Interpreting the dereferenceAliases attribute
+
+ Interpretation:
+
+ If set to TRUE, the DUA SHOULD enable alias dereferening.
+
+ If set to FALSE, the DUA MUST NOT enable alias dereferencing.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
+
+ Default Value:
+
+ If the dereferenceAliases attribute is not set or set to an
+ invalid value the default value is TRUE.
+
+5.1.12 Interpreting the profileTTL attribute
+
+ Interpretation:
+
+ The profileTTL attribute defines how often the DUA SHOULD re-
+
+
+
+Joslin [Page 19]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ load and reconfigure itself using the corresponding configura-
+ tion profile entry. The value is represented in seconds.
+ Once a DUA reloads the profile entry, it SHOULD re-configure
+ itself with the new values.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+
+ Default Value:
+
+ If not specified the DUA MAY use its own reconfiguration pol-
+ icy.
+
+ Other attribute notes:
+
+ If the profileTTL value is zero, the DUA SHOULD NOT automati-
+ cally re-load the configuration profile.
+
+5.1.13 Interpreting the objectclassMap attribute
+
+ Interpretation:
+
+ A DUA MAY perform objectclass mapping for all LDAP operations
+ performed for a service that has an objectclassMap entry.
+ Because objectclass mapping is specific for each service
+ within the DUA, a "serviceID" is required as part of the
+ objectclassMap syntax. I.E. Not all DUA services should
+ necessarily perform the same objectclass mapping.
+
+ Objectclass mapping SHOULD be used in conjunction with attri-
+ bute mapping to map the required schema by the service to an
+ equivalent schema that is available in the directory.
+
+ Objectclass mapping may or may not be required by a DUA. In
+ general, the objectclass attribute is used primarily in search
+ filters. If a service search descriptor is provided, it is
+ expected that the search filter contains a "correct" search
+ filter (though this is not a requirement,) which does not need
+ to be re-mapped. However, when the service search descriptor
+ is not provided, and the default search filter for that ser-
+ vice contains the objectclass attribute, that search filter
+ SHOULD be re-defined by objectclass mapping. If a default
+ search filter is not used, it SHOULD be re-defined through the
+ serviceSearchDescriptor. If a serviceSearchDescriptor is
+ defined for a particular service, it SHOULD NOT be re-mapped
+ by either the objectclassMap or attributeMap values.
+
+
+
+
+Joslin [Page 20]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ One condition where the objectclassMap SHOULD be used is when
+ the DUA is providing gateway functionality. In this case, the
+ DUA is acting on behalf of another service, which may pass in
+ a search filter itself. In this type of DUA, the DUA may
+ alter the search filter according to the appropriate attribu-
+ teMap and objectclassMap values. And in this case, it is also
+ assumed that a serviceSearchDescriptor is not defined.
+
+ Syntax:
+
+ objectclassMap = serviceID ":" origObjectclass "="
+ objectclass
+ origObjectclass = objectclass
+ objectclass = keystring
+
+ Values of the origObjectclass depend on the type of DUA Ser-
+ vice using the objectclass mapping feature.
+
+ Default Value:
+
+ The DUA MUST NOT remap an objectclass unless it is explicitly
+ defined by an objectclassMap attribute.
+
+ Other attribute notes:
+
+ A DUA SHOULD support objectclass mapping. If it does, the DUA
+ MUST support mapping of objectclasses using the objectclass
+ OID. It SHOULD support objectclass mapping based on the
+ objectclass name.
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of the DSA.
+
+ Example:
+
+ Suppose a DUA is acting on behalf of an email service. By
+ default the "email" service uses the "mail", "cn" and "sn"
+ attributes to discover mail addresses in entries created using
+ inetOrgPerson objectclass [16]. However, the email service
+ has been deployed in an environment that uses entries created
+ using "employee" objectclass. In this case, the attribute
+ "cn" can be mapped to "employeeName", and "inetOrgPerson" can
+ be mapped to "employee", allowing the DUA to perform LDAP
+ operations using the entries that exist in the directory.
+ This mapping is performed by adding attributeMap and
+ objectclassMap attributes to the configuration profile entry
+ as follows (represented in LDIF[18]):
+
+
+
+
+Joslin [Page 21]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ attributeMap: email:cn=employeeName
+ objectclassMap: email:inetOrgPerson=employee
+
+
+5.1.14 Interpreting the defaultSearchScope attribute
+
+ Interpretation:
+
+ When a DUA needs to search the DSA for information, this
+ attribute provides the "scope" for the search. This parameter
+ can be overridden by the serviceSearchDescriptor attribute.
+ See section 5.1.6.
+
+ Syntax:
+
+ scopeSyntax = "base" | "one" | "sub"
+
+ Default Value:
+
+ The default value for the defaultSearchScope SHOULD be defined
+ by the DUA service. If the default search scope for a service
+ is not defined then the scope SHOULD be for the DUA to perform
+ a subtree search.
+
+
+5.1.15 Interpreting the serviceAuthenticationMethod attribute
+
+ Interpretation:
+
+ The serviceAuthenticationMethod attribute defines an ordered
+ list of LDAP bind methods to be used when attempting to con-
+ tact a DSA for a particular service. Interpretation and use
+ of this attribute is the same as 5.1.4, but specific for each
+ service.
+
+ Syntax:
+
+ svAuthMethod = service ":" method *(";" method)
+
+ Note: Although multiple authentication methods may be speci-
+ fied in the syntax, at most one of each type is allowed.
+
+ Default Value:
+
+ If the serviceAuthenticationMethod attribute is not provided,
+ the authenticationMethod SHOULD be followed, or its default.
+
+ Other attribute notes:
+
+
+
+Joslin [Page 22]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, credentialLevel,
+ serviceCredentialLevel and bindTimeLimit. Please review sec-
+ tion 5.2 for details on how to properly bind to a DSA.
+
+ Example:
+
+ serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
+
+
+5.1.16 Interpreting the serviceCredentialLevel attribute
+
+ Interpretation:
+
+ The serviceCredentialLevel attribute defines what type(s) of
+ credential(s) the DUA SHOULD use when contacting the DSA for a
+ particular service. Interpretation and used of this attribute
+ are the same as 5.1.5.
+
+ Syntax:
+
+ svCredentialLevel = service ":" level *(space level)
+
+ Refer to implementation notes in section 5.2 for additional
+ syntax requirements for the credentialLevel attribute.
+
+ Note: Although multiple credential levels may be specified in
+ the syntax, at most one of each type is allowed.
+
+ Default Value:
+
+ If the serviceCredentialLevel attribute is not defined, the
+ DUA MUST examine the credentialLevel attribute, or follow its
+ default if not provided.
+
+ Other attribute notes:
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, serviceAuthentica-
+ tionMethod, authenticationMethod and bindTimeLimit. Please
+ review section 5.2 for details on how to properly bind to a
+ DSA.
+
+ Example:
+
+ serviceCredentialLevel: email:proxy anonymous
+
+
+
+
+
+Joslin [Page 23]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+5.2 Binding to the Directory Server
+
+ The DUA SHOULD use the following algorithm when binding to the
+ server:
+
+ for (clevel in credLevel) [see note 1]
+ if (clevel is "anonymous")
+ for (host in hostnames) [see note 2]
+ if (server is responding)
+ return success
+ return failure
+ else
+ for (amethod in authMethod) [see note 3]
+ if (amethod is none)
+ for (host in hostnames)
+ if (server is responding)
+ return success
+ return failure
+ else
+ for (host in hostnames)
+ authenticate using amethod and clevel
+ if (authentication passed)
+ return success
+ return failure
+
+ Note 1: The credLevel is a list of credential levels as defined
+ in serviceCredentialLevel (section 5.1.16) for a given
+ service. If the serviceCredentialLevel is not defined,
+ the DUA MUST examine the credentialLevel attribute.
+
+ Note 2: hostnames is the list of servers to contact as defined
+ in 5.1.1 & 5.1.2.
+
+ Note 3: The authMethod a list of authentication methods as defined
+ in serviceAuthenticationMethod (section 5.1.15) for a
+ given service. If the serviceAuthenticationMethod is not
+ defined, the DUA MUST examine the authenticationMethod
+ attribute.
+
+
+
+6. Security Considerations
+
+ The profile entries MUST be protected against unauthorized modifi-
+ cation. Since the profile is most useful if its content is avail-
+ able broadly, it is recommended that the profile entries will be
+ readable anonymously. However, ultimately each service needs to
+ consider implications of providing its service configuration as
+
+
+
+Joslin [Page 24]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ part of this profile and limit access to the profile entries
+ accordingly. Additionally, the management of the authentication
+ credentials for the DUA is outside the scope of this document and
+ needs to be handled by the DUA.
+
+ The algorithm described by section 5.2 also has security considera-
+ tions. Altering that design will alter the security aspectes of
+ the configuration profile.
+
+
+7. Acknowledgments
+
+ There were several additional authors of this document. However we
+ chose to represent only one author per company in the heading.
+ From Sun we also would like to acknowledge Roberto Tam for his
+ design work on Sun's first LDAP name service product and his input
+ for this document. From Hewlett-Packard we'd like to acknowledge
+ Dave Binder for his work architecting Hewlett-Packard's LDAP name
+ service product as well as his design guidance on this document.
+ We'd also like to acknowledge Grace Lu from HP, for her input and
+ implementation of HP's configuration profile manager code.
+
+
+8. References
+
+[1]
+ M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
+ Methods for LDAP", RFC 2828, May 2000
+
+[2]
+ M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
+ Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,
+ December 1997.
+
+[3]
+ M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+ (v3): UTF-8 String Representation of Distinguished Names", RFC
+ 2253, December 1997.
+
+[4]
+ T. Howes, "The String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
+
+[5]
+ T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
+
+[6]
+ T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
+
+
+
+Joslin [Page 25]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Locators (URL)", RFC 1738, December 1994.
+
+[7]
+ J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
+ 2222, October 1997
+
+[8]
+ M. Wahl, "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+[9]
+ T. Berners-Lee, R. Fielding, R. Fielding, "Uniform Resource Iden-
+ tifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+[10]
+ R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6
+ Addresses in URL's, RFC 2732, December 1999.
+
+[11]
+ P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechan-
+ ism", RFC 2831, May 2000
+
+[12]
+ J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto-
+ col [v3]: Extension for Transport Layer Security", RFC 2830, May
+ 2000
+
+[13]
+ Microsoft Corporation, "Services for Unix 2.0",
+ http://www.microsoft.com/WINDOWS2000/sfu/default.asp
+
+[14]
+ L. Howard, "An Approach for Using LDAP as a Network Information
+ Service", RFC 2307, March 1998.
+
+[15]
+ S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
+ els", RFC 2119, March 1997.
+
+[16]
+ M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
+ 2789, April 2000
+
+[17]
+ M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
+ (v3)", RFC 2251, December 1997.
+
+[18]
+
+
+
+Joslin [Page 26]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
+ Specification", RFC 2849, June 2000.
+
+
+9. Examples
+
+ In this section we will describe a fictional DUA which provides one
+ service, called the "email" service. This service would be similar
+ to an email client that uses an LDAP directory to discover email
+ addresses based on a textual representation of the recipient's col-
+ loquial name.
+
+ This email service is defined by default to expect that users with
+ email addresses will be of the "inetOrgPerson" objectclass type
+ [16]. And by default, the "email" service expects the colloquial
+ name to be stored in the "cn" attribute, while it expects the email
+ address to be stored in the "mail" attribute (as one would expect
+ as defined by the inetOrgPerson objectclass.)
+
+ As a special feature, the "email" service will perform a special
+ type of attribute mapping, when performing searches. If the "cn"
+ attribute has been mapped to two or more attributes, the "email"
+ service will parse the requested search string and map each white-
+ space separated token into the mapped attributes, respectively.
+
+ The default search filter for the "email" service is
+ "(objectclass=inetOrgPerson)". The email service also defines that
+ when it performs a name to address discovery, it will wrap the
+ search filter inside a complex search filter as follows:
+
+ (&(<filter>)(cn~=<name string>)
+
+ or if "cn" has been mapped to multiple attributes, that wrapping
+ would appear as follows:
+
+ (&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
+
+ The below examples show how the "email" service builds it search
+ requests, based on the defined profile. In all cases, the
+ defaultSearchBase is "o=airius.com" and the defaultSearchScope is
+ undefined.
+
+ In addition, for all examples, we assume that the "email" service
+ has been requested to discover the email address for "Jane Hernan-
+ dez."
+
+
+ Example 1:
+
+
+
+Joslin [Page 27]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ serviceSearchDescriptor: email:"ou=marketing,"
+
+ base: ou=marketing,o=airius.com
+ scope: sub
+ filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
+
+ Example 2:
+
+ serviceSearchDescriptor: email:"ou=marketing,"?one?
+ (&(objectclass=inetOrgPerson)(c=us))
+ attributeMap: email:cn=2.5.4.42 sn
+
+ Note: 2.5.4.42 is the OID that represents the "givenName"
+ attribute.
+
+ In this example, the email service performs <name string> parsing
+ as described above to generate a complex search filter. The above
+ example results in one search.
+
+ base: ou=marketing,o=airius.com
+ scope: one
+ filter: (&(&(objectclass=inetOrgPerson)(c=us))
+ (2.5.4.42~=Jane)(sn~=Hernandez))
+
+ Example 3:
+
+ serviceSearchDescriptor: email:ou=marketing,"?base
+ attributeMap: email:cn=name
+
+ This example is invalid, because either the quote should have been
+ escaped, or there should have been a leading quote.
+
+ Example 4:
+
+ serviceSearchDescriptor: email:ou=\mar\\keting,\"?base
+ attributeMap: email:cn=name
+
+ base: ou=\mar\keting,"
+ scope: base
+ filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
+
+ Example 5:
+
+ serviceSearchDescriptor: email:ou="marketing",o=supercom
+
+ This example is invalid, since the quote was not a leading quote,
+ and thus should have been escaped.
+
+
+
+
+Joslin [Page 28]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+ Example 6:
+
+ serviceSearchDescriptor: email:??(&(objectclass=person)
+ (ou=Org1 \\(temporary\\)))
+
+ base: o=airius.com
+ scope: sub
+ filter: (&((&(objectclass=person)(ou=Org1 \(Temporary\)))
+ (cn~=Jane Henderson)))
+
+ Example 7:
+
+ serviceSearchDescriptor: email:"ou=funny?org,"
+
+ base: ou=funny?org,o=airius.com
+ scope: sub
+ filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
+
+
+10. Author's Addresses
+
+ Luke Howard
+ PADL Software Pty. Ltd.
+ PO Box 59
+ Central Park Vic 3145
+ Australia
+
+ EMail: lukeh@padl.com
+
+
+ Bob Joslin
+ Hewlett-Packard Company
+ 19420 Homestead RD MS43-LF
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1 408 447-3044
+ EMail: bob_joslin@hp.com
+
+
+ Morteza Ansari
+ Sun Microsystems, Inc.
+ 901 San Antonio RD MS MPK17-203
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 650 786-6178
+ EMail: morteza.ansari@sun.com
+
+
+
+Joslin [Page 29]
+\f
+Internet-Draft DUA Configuration Schema October 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joslin [Page 30]
+\f
--- /dev/null
+
+Internet Draft J. Sermersheim
+Personal Submission R. Harrison
+Intended Category: Standard Track Novell, Inc
+Document: draft-sermersheim-ldap-chaining-02.txt Feb 2004
+
+
+
+ LDAP Control to Specify Chaining Behavior
+
+
+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.
+
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions Working Group
+ mailing list <ldapext@ietf.org>. Editorial comments may be sent to
+ the author <jimse@novell.com>.
+
+
+Abstract
+
+ This document describes a Lightweight Directory Access Protocol
+ (LDAP) request control that allows specification of chaining behavior
+ for LDAP operations. By using the control with various LDAP
+ operations, a directory client (DUA), or directory server (DSA)
+ specifies whether or not a DSA or secondary DSA chains operations to
+ other DSAs or returns referrals and/or search result references to
+ the client.
+
+
+1. Introduction
+
+ Many directory servers have the ability through the use of various
+ mechanisms to participate in a distributed directory model. A
+ distributed directory is one where the DIT is distributed over
+ multiple DSAs. One operation completion mechanism used by DSAs in a
+ distributed directory is chaining. Chaining is defined in [X.518],
+ and is the act of one DSA communicating a directory operation that
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 1 \f
+ LDAP Control to Specify Chaining Behavior
+
+ originated from a DUA to another DSA in a distributed directory.
+ Contrast this with the act of passing referrals (4.1.11 of [RFC2251])
+ and SearchResultReferences (4.5.2 of [RFC2251]) back to the client.
+ Chaining may happen during the name resolution part of an operation
+ or during other parts of operations like search which apply to a
+ number of entries in a subtree.
+
+ This document does not attempt to define the distributed directory
+ model, nor does it attempt to define the manner in which DSAs chain
+ requests. This document defines a request control that the client can
+ use to specify whether parts of an operation should or should not be
+ chained.
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document carry the meanings described in [RFC2119].
+
+ The term chaining may apply to uni-chaining as well as multi-chaining
+ (see [X.518]) depending on the capabilities and configuration of the
+ DSAs.
+
+
+3. The Control
+
+ Support for the control is advertised by the presence of its
+ controlType in the supportedControl attribute of a server's root DSE.
+
+ This control MAY be included in any LDAP request operation except
+ abandon, unbind, and StartTLS as part of the controls field of the
+ LDAPMessage, as defined in Section 4.1.12 of [RFC2251]:
+
+ The controlType is set to <IANA-ASSIGNED-OID.1>. The criticality MAY
+ be set to either TRUE or FALSE. The controlValue is an OCTET STRING,
+ whose value is the following ChainingBehavior type, BER encoded
+ following the rules in Section 5.1 of [RFC2251]:
+
+ ChainingBehavior ::= SEQUENCE {
+ resolveBehavior Behavior OPTIONAL,
+ continuationBehavior Behavior OPTIONAL }
+
+ Behavior :: = ENUMERATED {
+ chainingPreferred (0),
+ chainingRequired (1),
+ referralsPreferred (2),
+ referralsRequired (3) }
+
+ resolveBehavior instructs the DSA what to do when a referral is
+ encountered during the local name resolution part of an operation. If
+ this field is not specified, other policy dictates the DSA's
+ behavior.
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 2 \f
+ LDAP Control to Specify Chaining Behavior
+
+ continuationBehavior instructs the DSA what to do when a referral is
+ encountered after the name resolution part of an operation has
+ completed. This scenario occurs during search operations, and may
+ occur during yet to be defined future operations. If this field is
+ not specified, other policy dictates the DSA's behavior.
+
+ Behavior specifies whether the DSA should chain the operation or
+ return referrals when a target object is held by a remote service.
+
+ chainingPreferred indicates that the preference is that
+ chaining, rather than referrals, be used to provide the service.
+ When this value is set, the server attempts to chain the request
+ but if it can't it returns referrals.
+
+ chainingRequired indicates that chaining is to be used rather
+ than referrals to service the request. When this value is set,
+ the server MUST NOT return referrals. It either chains the
+ request or fails.
+
+ referralsPreferred indicates that the client wishes to receive
+ referrals rather than allow the server to chain the operation.
+ When this value is set, the server return referrals and search
+ references when possible, but may chain the operation otherwise.
+
+ referralsRequired indicates that chaining is prohibited. When
+ this value is set, the server MUST NOT chain the request to
+ other DSAs. Instead it returns referrals as necessary, or fails.
+
+ The following list assigns meanings to some of the result codes that
+ may occur due to this control being present:
+
+ - chainingRequired (IANA-ASSIGNED-1) Unable to process without
+ chaining.
+ - cannotChain (IANA-ASSIGNED-2) Unable to chain the request.
+
+
+4. Notes to Implementors
+
+ <todo: add some>
+
+
+4.1 Unbind and Abandon
+
+ Clients MUST NOT include the ChainingBehavior control with an Abandon
+ operation or an Unbind operation. Servers MUST ignore any chaining
+ control on the abandon and unbind requests. Servers that chain
+ operation are responsible to keep track of where an operation was
+ chained to for the purposes of unbind and abandon.
+
+
+4.2 StartTLS
+
+ This operation cannot be chained because the TLS handshake protocol
+ does not allow man-in-the-middle attacks.
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 3 \f
+ LDAP Control to Specify Chaining Behavior
+
+
+
+5. Relationship with other Extensions
+
+ This control MAY be used with other controls or with extended
+ operations. When it is used with other controls or with extended
+ operations not listed here, server behavior is undefined unless
+ otherwise specified.
+
+
+5.1 Relationship with ManageDsaIT
+
+ When this control is used along with the ManageDsaIT control, the
+ resolveBehavior value is evaluated. If resolveBehavior is such that
+ chaining is allowed, the DSA is allowed to chain the operation as
+ necessary until the last RDN is found.
+
+ For example: DSA1 holds the naming context <dc=net> and a subordinate
+ reference to <dc=example,dc=net>, DSA2 holds the naming context
+ <dc=example,dc=net> and a subordinate reference to
+ <dc=hostc,dc=example,dc=net>.
+
+ A modify operation accompanied by the ManageDsaIT control alone is
+ sent to DSA1. The base object of the modify operation is set to
+ <dc=hostc,dc=example,dc=net>. Since DSA1 does not hold the
+ <dc=hostc,dc=example,dc=net> IT DSE, a referral is returned for
+ <dc=example,dc=net>.
+
+ Next, the same modify operation is accompanied by both the
+ ManageDsaIT and the ChainingBehavior control where the
+ ChainingBehavior.resolveBehavior is set to chainingPreferred. In this
+ case, DSA1 chains to DSA2 when it encounters <dc=example,dc=net> and
+ DSA2 continues the operation. Since DSA2 holds the IT DSE
+ <dc=hostc,dc=example,dc=net>, the resolve portion completes, and the
+ rest of the operation proceeds.
+
+
+6. Security Considerations
+
+ Because this control directs a DSA to chain requests to other DSAs,
+ it may be used in a denial of service attack. Implementers should be
+ cognizant of this possibility.
+
+ This control may be used to allow access to hosts and portions of the
+ DIT not normally available to clients. Servers supporting this
+ control should provide sufficient policy to prevent unwanted
+ occurrences of this.
+
+
+7. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 4 \f
+ LDAP Control to Specify Chaining Behavior
+
+7.1. Object Identifiers
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ suggested:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ One delegation will be made under the assigned OID:
+
+ IANA-ASSIGNED-OID.1 Chaining Behavior Request Control
+
+
+7.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration template is suggested:
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: Chaining Behavior Request Control
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Usage: Control
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+7.3. LDAP Result Codes
+
+ It is requested that IANA register upon Standards Action the LDAP
+ result codes:
+
+ chainingRequired (IANA-ASSIGNED-1)
+ cannotChain (IANA-ASSIGNED-2)
+
+ The following registration template is suggested:
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse@novell.com
+ Result Code Name: chainingRequired
+ Result Code Name: cannotChain
+ Specification: RFCXXXX
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 5 \f
+ LDAP Control to Specify Chaining Behavior
+
+ Author/Change Controller: IESG
+ Comments: request consecutive result codes be assigned
+
+
+8. Normative References
+
+ [X.518]
+ ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
+
+ [RFC2119]
+ Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
+ Levels", Internet Draft, March 1997.
+ Available as RFC2119.
+
+ [RFC2251]
+ Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
+ Protocol (v3)", Internet Standard, December, 1997.
+ Available as RFC2251.
+
+
+9. Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse@novell.com
+ +1 801 861-3088
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ rharrison@novell.com
+ +1 801 861-2642
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 6 \f
+ LDAP Control to Specify Chaining Behavior
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification
+ can be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain
+ it or assist in its implementation may be prepared, copied,
+ published and distributed, in whole or in part, without restriction
+ of any kind, provided that the above copyright notice and this
+ paragraph are included on all such copies and derivative works.
+ However, this document itself may not be modified in any way, such
+ as by removing the copyright notice or references to the Internet
+ Society or other Internet organizations, except as needed for the
+ purpose of developing Internet standards in which case the
+ procedures for copyrights defined in the Internet Standards process
+ must be followed, or as required to translate it into languages
+ other than English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on
+ an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 7 \f
+
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 26 October 2003
+
+
+ LDAP Read Entry Controls
+ <draft-zeilenga-ldap-readentry-01.txt>
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext@ietf.org>. Please send editorial comments directly to the
+ author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This specification describes controls which can be attached to a
+ Lightweight Directory Access Protocol (LDAP) update request to obtain
+ copies of the target entry before and/or after the requested update is
+ applied.
+
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+1. Background and Intent of Use
+
+ This specification describes controls [RFC2251] which can be attached
+ to Lightweight Directory Access Protocol (LDAP) [RFC3377] update
+ requests to request and return copies of the target entry. One
+ request control, called the Pre-Read request control, indicates that a
+ copy of the entry before application of update is to be returned.
+ Another control, called the Post-Read request control, indicates that
+ a copy of the entry after application of the update is to be returned.
+ Each request control has a corresponding response control used to
+ return the entry.
+
+ The functionality offered by these controls is based upon similar
+ functionality in the X.500 Directory Access Protocol (DAP) [X.511].
+
+ The Pre-Read controls may be used to obtain replaced or deleted values
+ of modified attributes or a copy of the entry being deleted.
+
+ The Post-Read controls may be used to obtain values of operational
+ attributes, such as the 'entryUUID' [EntryUUID] and 'modifytimestamp'
+ [RFC2252] attributes, updated by the server as part of the update
+ operation.
+
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.1 of [RFC2251].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent (i.e., a directory server).
+ DSE stands for DSA-specific Entry.
+
+ 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 BCP 14 [RFC2119].
+
+
+3. Read Entry Controls
+
+3.1. The Pre-Read Controls
+
+ The Pre-Read request and response controls are identified by the
+ IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
+ controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
+ 'supportedControl' [RFC2252] in their root DSE.
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ The Pre-Read request control is an LDAP Control [RFC2251] whose
+ controlType is IANA-ASSIGNED-OID.1 and controlValue is a BER-encoded
+ AttributeDescriptionList [RFC2251]. The criticality may be TRUE or
+ FALSE. This control is appropriate for the modifyRequest, delRequest,
+ and modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose controlType
+ is IANA-ASSIGNED-OID.1 and the controlValue, an OCTET STRING, contains
+ a BER-encoded SearchResultEntry. The criticality may be TRUE or
+ FALSE. This control is appropriate for the modifyResponse,
+ delResponse, and modDNResponse LDAP messages with a resultCode of
+ success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of target entry
+ prior to the application of the update. The AttributeDescriptionList
+ indicates which attributes are requested to appear in the copy. There
+ are two special AttributeDescriptions which may be included in the
+ list, "*" and "+". "*" requests all user attributes. "+" requests
+ all operational attributes. If the list is empty, all user attributes
+ are requested. If the list contains an unrecognized attribute type,
+ that type is simply ignored. If all attribute types are unrecognized,
+ no attributes are to be returned. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails, no response control is provided.
+
+
+3.2. The Post-Read Controls
+
+ The Post-Read request and response controls are identified by the
+ IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
+ controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
+ 'supportedControl' [RFC2252] in their root DSE.
+
+ The Post-Read request control is an LDAP Control [RFC2251] whose
+ controlType is IANA-ASSIGNED-OID.2 and controlValue, an OCTET STRING,
+ contains a BER-encoded AttributeDescriptionList [RFC2251]. The
+ criticality may be TRUE or FALSE. This control is appropriate for the
+ addRequest, modifyRequest, and modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose controlType
+ is IANA-ASSIGNED-OID.2 and controlValue is a BER-encoded
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ SearchResultEntry. The criticality may be TRUE or FALSE. This
+ control is appropriate for the addResponse, modifyResponse, and
+ modDNResponse LDAP messages with a resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of target entry
+ after the application of the update. The AttributeDescriptionList
+ indicates which attributes are requested to appear in the copy. There
+ are two special AttributeDescriptions which may be included in the
+ list, "*" and "+". "*" requests all user attributes. "+" requests
+ all operational attributes. If the list is empty, all user attributes
+ are requested. If the list contains an unrecognized attribute type,
+ that type is simply ignored. If all attribute types are unrecognized,
+ no attributes are to be returned. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails, no response control is provided.
+
+
+4. Interaction with other controls
+
+ The Pre- and Post-Read controls may be combined with each other and/or
+ with a variety of other controls. When combined with the assertion
+ control [ASSERT], the manageDsaIT control [RFC3296], and/or the proxy
+ authorization control [PROXYAUTH], the semantics of each control
+ included in the combination apply. The Pre- and Post-Read controls
+ may be combined with other controls as detailed in other technical
+ specifications.
+
+
+5. Security Considerations
+
+ The controls defined in this document extend update operations to
+ support read capabilities. Servers MUST ensure that the client is
+ authorized both for reading of the information provided in this
+ control in addition to ensuring the client is authorized to perform
+ the requested directory update.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP security considerations [RFC3377].
+
+
+6. IANA Considerations
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ Registration of the following protocol values [RFC3383] is requested.
+
+
+6.1. Object Identifier
+
+ It is requested that IANA register an LDAP Object Identifier to
+ identify LDAP protocol elements defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Read Entry Controls
+
+
+6.2. LDAP Protocol Mechanisms
+
+ It is requested that IANA register the LDAP Protocol Mechanism
+ described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: LDAP Pre-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Description: LDAP Post-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
+
+
+7. Acknowledgment
+
+ The LDAP Pre- and Post-Read controls are modeled after similar
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ capabilities offered in the DAP [X.511].
+
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+
+ [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", draft-
+ weltman-ldapv3-proxy-xx.txt, a work in progress.
+
+ [ASSERT] Zeilenga, K., "LDAP Assertion Control",
+ draft-zeilenga-ldap-assert-xx.txt, a work in progress.
+
+
+9. Informative References
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993).
+
+ [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
+ Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
+ progress.
+
+
+10. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 8]
+\f
--- /dev/null
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 8 February 2004
+
+
+
+ LDAP Turn Operation
+ <draft-zeilenga-ldap-turn-00.txt>
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor for publication as an
+ Experimental document. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext@ietf.org>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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>.
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to reverse (or "turn") the roles of client
+ and server for subsequent protocol exchanges in the session.
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+
+
+1. Background and Intent of Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] is a client
+ / server protocol which typically operates over reliable octet stream
+ transports such as the Transport Control Protocol (TCP). Generally,
+ the client initiates the stream by connecting to the server's listener
+ at some well-known address.
+
+ There are cases where it is desirable for the server to initiate the
+ stream. While it certainly is possible to write a technical
+ specification detailing how to implement server-initiated LDAP
+ sessions, this would requiring designing new authentication and other
+ security features to support server-initiated LDAP sessions.
+
+ This document instead introduces an operation, the Turn operation,
+ which may be used to reverse the client / server roles of the
+ protocol peers. This allows the initiating protocol peer to be server
+ (after reversal).
+
+ As an additional feature, the Turn operation may be used to allow both
+ peers to act in both roles. This is useful where both peers are
+ directory servers which desire to issue, as LDAP clients, operations
+ against the other. This may be useful in replicated environments.
+
+ This operation is intended to used between protocol peers which have
+ established a mutual agreement, by means outside of the protocol,
+ which requires reversal of client / server roles or both peers to act
+ both as client and server.
+
+
+1.1 Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.1 of [RFC2251].
+
+ 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 BCP 14 [RFC2119].
+
+
+2. Turn Operation
+
+ The Turn operation is defined as a LDAP Extended Operation [RFC2251,
+ Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
+ the Turn Operation is to request that the client / server roles be
+ reversed, or, optionally to request that both protocol peers to be
+
+
+
+Zeilenga LDAP Turn Op [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+
+
+ able to act both as client and server.
+
+
+2.1. Turn Request
+
+ The Turn request is an ExtendedRequest with the requestName field
+ containing the IANA-ASSIGNED-OID and a requestValue field is a
+ BER-encoded turnValue:
+
+ turnValue ::= SEQUENCE {
+ mutual BOOLEAN DEFAULT FALSE,
+ identifier LDAPString,
+ }
+
+ A TRUE value of the mutual field indicates a request to allow both
+ peers to act both as client and server while a FALSE value indicates a
+ request to reserve the client and server roles.
+
+ The value of the identifier field is a locally-defined policy
+ identifier (typicallly associated with a mutual agreement for which
+ this turn is be executed as part of). This policy identifier is
+ called the turn indicator.
+
+
+2.2. Turn Response
+
+ A Turn response is an ExtendedResponse where the responseName and
+ response fields are absent. A resultCode of success is returned if
+ and only if the responder is willing and able to turn the session as
+ requested. Otherwise, a different resultCode is returned.
+
+
+3. Security Considerations
+
+ It is generally recommended that before issuing the Turn operation the
+ protocol peers:
+
+ - establish each other identities through appropriate authentication
+ mechanism,
+ - establish appropriate data integrity, data confidentiality, and
+ other protections,
+ - establish an LDAP association between the initiating peer and the
+ responding peer.
+
+ And upon successful completion of turn:
+ - establish an LDAP association in reverse.
+
+ That is, for peer A connecting to peer B listening and where TLS and
+
+
+
+Zeilenga LDAP Turn Op [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+
+
+ SASL/EXTERNAL were to be used, the sequence of operations would be:
+
+ A->B: StartTLS
+ A->B: Bind(SASL,EXTERNAL)
+ A->B: Turn
+ B->A: Bind(SASL,EXTERNAL)
+
+
+4. IANA Considerations
+
+ Registration of the following values [RFC3383] is requested.
+
+
+4.1. Object Identifier
+
+ It is requested that IANA assign an LDAP Object Identifier to identify
+ the LDAP Turn Operation as defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Turn Operation
+
+
+4.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register the LDAP Protocol Mechanism
+ described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Turn Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC XXXX
+ Author/Change Controller: Author
+ Comments: none
+
+
+5. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+
+
+
+Zeilenga LDAP Turn Op [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+
+
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+
+
+6. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt@OpenLDAP.org
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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
+
+
+
+Zeilenga LDAP Turn Op [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+
+
+ rights by implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 6]
+\f
+\r
.B include <filename>
Read additional configuration information from the given file before
continuing with the next line of the current file.
-.TP
-.B limits <who> <limit> [<limit> [...]]
-Specify time and size limits based on who initiated an operation.
-The argument
-.B who
-can be any of
-.RS
-.RS
-.TP
-anonymous | users | [dn[.<style>]=]<pattern> | group[/oc[/at]]=<pattern>
-
-.RE
-with
-.RS
-.TP
-<style> ::= exact | base | onelevel | subtree | children | regex | anonymous
-
-.RE
-The term
-.B anonymous
-matches all unauthenticated clients.
-The term
-.B users
-matches all authenticated clients;
-otherwise an
-.B exact
-dn pattern is assumed unless otherwise specified by qualifying
-the (optional) key string
-.B dn
-with
-.B exact
-or
-.B base
-(which are synonyms), to require an exact match; with
-.BR onelevel ,
-to require exactly one level of depth match; with
-.BR subtree ,
-to allow any level of depth match, including the exact match; with
-.BR children ,
-to allow any level of depth match, not including the exact match;
-.BR regex
-explicitly requires the (default) match based on regular expression
-pattern, as detailed in
-.BR regex (7).
-Finally,
-.B anonymous
-matches unbound operations; the
-.B pattern
-field is ignored.
-The same behavior is obtained by using the
-.B anonymous
-form of the
-.B who
-clause.
-The term
-.BR group ,
-with the optional objectClass
-.B oc
-and attributeType
-.B at
-fields, followed by
-.BR pattern ,
-sets the limits for any DN listed in the values of the
-.B at
-attribute (default
-.BR member )
-of the
-.B oc
-group objectClass (default
-.BR groupOfNames )
-whose DN exactly matches
-.BR pattern .
-
-The currently supported limits are
-.B size
-and
-.BR time .
-
-The syntax for time limits is
-.BR time[.{soft|hard}]=<integer> ,
-where
-.BR integer
-is the number of seconds slapd will spend answering a search request.
-If no time limit is explicitly requested by the client, the
-.BR soft
-limit is used; if the requested time limit exceeds the
-.BR hard
-limit, an
-.I \"Administrative limit exceeded\"
-is returned.
-If the
-.BR hard
-limit is set to 0 or to the keyword
-.IR soft ,
-the soft limit is used in either case; if it is set to
-.I -1
-or to the keyword
-.IR none ,
-no hard limit is enforced.
-Explicit requests for time limits smaller or equal to the
-.BR hard
-limit are honored.
-If no flag is set, the value is assigned to the
-.BR soft
-limit, and the
-.BR hard
-limit is set to zero, to preserve the original behavior.
-
-The syntax for size limits is
-.BR size[.{soft|hard|unchecked}]=<integer> ,
-where
-.BR integer
-is the maximum number of entries slapd will return answering a search
-request.
-If no size limit is explicitly requested by the client, the
-.BR soft
-limit is used; if the requested size limit exceeds the
-.BR hard
-limit, an
-.I \"Administrative limit exceeded\"
-is returned.
-If the
-.BR hard
-limit is set to 0 or to the keyword
-.IR soft ,
-the soft limit is used in either case; if it is set to
-.I -1
-or to the keyword
-.IR none ,
-no hard limit is enforced.
-Explicit requests for size limits smaller or equal to the
-.BR hard
-limit are honored.
-The
-.BR unchecked
-flag sets a limit on the number of candidates a search request is allowed
-to examine.
-If the selected candidates exceed the
-.BR unchecked
-limit, the search will abort with
-.IR \"Unwilling to perform\" .
-If it is set to
-.I -1
-or to the keyword
-.IR none ,
-no limit is applied (the default).
-If it is set to
-.IR disable ,
-the search is not even performed; this can be used to disallow searches
-for a specific set of users.
-If no flag is set, the value is assigned to the
-.BR soft
-limit, and the
-.BR hard
-limit is set to zero, to preserve the original behavior.
-
-In case of no match, the global limits are used.
-The default values are the same of
-.B sizelimit
-and
-.BR timelimit ;
-no limit is set on
-.BR unchecked .
-
-If
-.B pagedResults
-control is defined, additional size limits may be enforced; the syntax is
-.BR size.pr={<integer>|noEstimate|disabled|none} ,
-where
-.B integer
-is the max page size if no explicit limit is set; the keyword
-.I noEstimate
-inhibits the server to return an estimate of the total number
-of entries that will be returned; the keyword
-.I disabled
-disables the control; the keyword
-.I none
-indicates that no limit is applied to the pagedResults control page size.
-The syntax
-.B size.prtotal={<integer>|none}
-allows to set a limit on the total number of entries that a pagedResults
-control allows to return.
-By default it is unlimited, which is indicated by the keyword
-.IR none .
-When set,
-.B integer
-is the max number of entries that the whole search with pagedResults control
-can return.
-.RE
.\"-- NEW_LOGGING option --
.\".TP
.\".B logfile <filename>
modifiersName, modifyTimestamp, creatorsName, and
createTimestamp attributes for entries. By default, lastmod is on.
.TP
+.B limits <who> <limit> [<limit> [...]]
+Specify time and size limits based on who initiated an operation.
+The argument
+.B who
+can be any of
+.RS
+.RS
+.TP
+anonymous | users | [dn[.<style>]=]<pattern> | group[/oc[/at]]=<pattern>
+
+.RE
+with
+.RS
+.TP
+<style> ::= exact | base | onelevel | subtree | children | regex | anonymous
+
+.RE
+The term
+.B anonymous
+matches all unauthenticated clients.
+The term
+.B users
+matches all authenticated clients;
+otherwise an
+.B exact
+dn pattern is assumed unless otherwise specified by qualifying
+the (optional) key string
+.B dn
+with
+.B exact
+or
+.B base
+(which are synonyms), to require an exact match; with
+.BR onelevel ,
+to require exactly one level of depth match; with
+.BR subtree ,
+to allow any level of depth match, including the exact match; with
+.BR children ,
+to allow any level of depth match, not including the exact match;
+.BR regex
+explicitly requires the (default) match based on regular expression
+pattern, as detailed in
+.BR regex (7).
+Finally,
+.B anonymous
+matches unbound operations; the
+.B pattern
+field is ignored.
+The same behavior is obtained by using the
+.B anonymous
+form of the
+.B who
+clause.
+The term
+.BR group ,
+with the optional objectClass
+.B oc
+and attributeType
+.B at
+fields, followed by
+.BR pattern ,
+sets the limits for any DN listed in the values of the
+.B at
+attribute (default
+.BR member )
+of the
+.B oc
+group objectClass (default
+.BR groupOfNames )
+whose DN exactly matches
+.BR pattern .
+
+The currently supported limits are
+.B size
+and
+.BR time .
+
+The syntax for time limits is
+.BR time[.{soft|hard}]=<integer> ,
+where
+.BR integer
+is the number of seconds slapd will spend answering a search request.
+If no time limit is explicitly requested by the client, the
+.BR soft
+limit is used; if the requested time limit exceeds the
+.BR hard
+limit, an
+.I \"Administrative limit exceeded\"
+error is returned.
+If the
+.BR hard
+limit is set to 0 or to the keyword
+.IR soft ,
+the soft limit is used in either case; if it is set to
+.I -1
+or to the keyword
+.IR none ,
+no hard limit is enforced.
+Explicit requests for time limits smaller or equal to the
+.BR hard
+limit are honored.
+If no flag is set, the value is assigned to the
+.BR soft
+limit, and the
+.BR hard
+limit is set to zero, to preserve the original behavior.
+
+The syntax for size limits is
+.BR size[.{soft|hard|unchecked}]=<integer> ,
+where
+.BR integer
+is the maximum number of entries slapd will return answering a search
+request.
+If no size limit is explicitly requested by the client, the
+.BR soft
+limit is used; if the requested size limit exceeds the
+.BR hard
+limit, an
+.I \"Administrative limit exceeded\"
+error is returned.
+If the
+.BR hard
+limit is set to 0 or to the keyword
+.IR soft ,
+the soft limit is used in either case; if it is set to
+.I -1
+or to the keyword
+.IR none ,
+no hard limit is enforced.
+Explicit requests for size limits smaller or equal to the
+.BR hard
+limit are honored.
+The
+.BR unchecked
+flag sets a limit on the number of candidates a search request is allowed
+to examine.
+If the selected candidates exceed the
+.BR unchecked
+limit, the search will abort with
+.IR \"Unwilling to perform\" .
+If it is set to
+.I -1
+or to the keyword
+.IR none ,
+no limit is applied (the default).
+If it is set to
+.IR disable ,
+the search is not even performed; this can be used to disallow searches
+for a specific set of users.
+If no flag is set, the value is assigned to the
+.BR soft
+limit, and the
+.BR hard
+limit is set to zero, to preserve the original behavior.
+
+In case of no match, the global limits are used.
+The default values are the same of
+.B sizelimit
+and
+.BR timelimit ;
+no limit is set on
+.BR unchecked .
+
+If
+.B pagedResults
+control is requested, the
+.B hard
+size limit is used by default, because the request of a specific page size
+is considered as an explicit request for a limitation on the number
+of entries to be returned.
+However, the size limit applies to the total count of entries returned within
+the search, and not to a single page.
+Additional size limits may be enforced; the syntax is
+.BR size.pr={<integer>|noEstimate|disabled|none} ,
+where
+.B integer
+is the max page size if no explicit limit is set; the keyword
+.I noEstimate
+inhibits the server to return an estimate of the total number
+of entries that will be returned; the keyword
+.I disabled
+disables the control, i.e. no paged results can be returned; the keyword
+.I none
+indicates that no limit is applied to the pagedResults control page size.
+The syntax
+.B size.prtotal={<integer>|none}
+allows to set a limit on the total number of entries that a pagedResults
+control allows to return.
+By default it is set to the
+.B hard
+limit.
+When set,
+.B integer
+is the max number of entries that the whole search with pagedResults control
+can return.
+Use
+.B none
+to allow unlimited number of entries to be returned, i.e. to use
+pagedResults as a means to allow clients to circumvent size limitations
+on regular searches.
+Note that the total number of entries returned when the pagedResults control
+is requested cannot exceed the
+.B hard
+size limit of regular searches unless extended by the
+.B prtotal
+switch.
+.RE
+.TP
.B maxderefdepth <depth>
Specifies the maximum number of aliases to dereference when trying to
resolve an entry, used to avoid infinite alias loops. The default is 1.
rfc3674.txt Feature Discovery in LDAP (PS)
rfc3687.txt LDAP Component Matching Rules (PS)
rfc3698.txt LDAP: Additional Matching Rules (PS)
+rfc3703.txt LDAP: Schema for Policy Core (PS)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
--- /dev/null
+
+
+
+
+
+
+Network Working Group J. Strassner
+Request for Comments: 3703 Intelliden Corporation
+Category: Standards Track B. Moore
+ IBM Corporation
+ R. Moats
+ Lemur Networks, Inc.
+ E. Ellesson
+ February 2004
+
+
+ Policy Core Lightweight Directory Access Protocol (LDAP) Schema
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document defines a mapping of the Policy Core Information Model
+ to a form that can be implemented in a directory that uses
+ Lightweight Directory Access Protocol (LDAP) as its access protocol.
+ This model defines two hierarchies of object classes: structural
+ classes representing information for representing and controlling
+ policy data as specified in RFC 3060, and relationship classes that
+ indicate how instances of the structural classes are related to each
+ other. Classes are also added to the LDAP schema to improve the
+ performance of a client's interactions with an LDAP server when the
+ client is retrieving large amounts of policy-related information.
+ These classes exist only to optimize LDAP retrievals: there are no
+ classes in the information model that correspond to them.
+
+Table of Contents
+
+ 1. Introduction ................................................. 2
+ 2. The Policy Core Information Model ............................ 4
+ 3. Inheritance Hierarchy for the PCLS ........................... 5
+ 4. General Discussion of Mapping the Information Model to LDAP .. 6
+ 4.1. Summary of Class and Association Mappings .............. 7
+ 4.2. Usage of DIT Content and Structure Rules and Name Forms. 9
+ 4.3. Naming Attributes in the PCLS .......................... 10
+
+
+
+Strassner, et al. Standards Track [Page 1]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ 4.4. Rule-Specific and Reusable Conditions and Actions ...... 11
+ 4.5. Location and Retrieval of Policy Objects in the
+ Directory .............................................. 16
+ 4.5.1. Aliases and Other DIT-Optimization Techniques .. 19
+ 5. Class Definitions ............................................ 19
+ 5.1. The Abstract Class "pcimPolicy" ........................ 21
+ 5.2. The Three Policy Group Classes ......................... 22
+ 5.3. The Three Policy Rule Classes .......................... 23
+ 5.4. The Class pcimRuleConditionAssociation ................. 30
+ 5.5. The Class pcimRuleValidityAssociation .................. 32
+ 5.6. The Class pcimRuleActionAssociation .................... 34
+ 5.7. The Auxiliary Class pcimConditionAuxClass .............. 36
+ 5.8. The Auxiliary Class pcimTPCAuxClass .................... 36
+ 5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40
+ 5.10. The Auxiliary Class pcimActionAuxClass ................. 41
+ 5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
+ 5.12. The Class pcimPolicyInstance ........................... 43
+ 5.13. The Auxiliary Class pcimElementAuxClass ................ 44
+ 5.14. The Three Policy Repository Classes .................... 45
+ 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
+ 5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
+ 5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
+ 6. Extending the Classes Defined in This Document ............... 50
+ 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
+ 6.2. Using the Vendor Policy Attributes ..................... 50
+ 6.3. Using Time Validity Periods ............................ 51
+ 7. Security Considerations ...................................... 51
+ 8. IANA Considerations .......................................... 53
+ 8.1. Object Identifiers ..................................... 53
+ 8.2. Object Identifier Descriptors .......................... 53
+ 9. Acknowledgments .............................................. 56
+ 10. Appendix: Constructing the Value of orderedCIMKeys .......... 57
+ 11. References ................................................... 58
+ 11.1. Normative References ................................... 58
+ 11.2. Informative References ................................. 59
+ 12. Authors' Addresses ........................................... 60
+ 13. Full Copyright Statement ..................................... 61
+
+1. Introduction
+
+ This document takes as its starting point the object-oriented
+ information model for representing information for representing and
+ controlling policy data as specified in [1]. Lightweight Directory
+ Access Protocol (LDAP) [2] implementers, please note that the use of
+ the term "policy" in this document does not refer to the use of the
+ term "policy" as defined in X.501 [4]. Rather, the use of the term
+ "policy" throughout this document is defined as follows:
+
+
+
+
+Strassner, et al. Standards Track [Page 2]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Policy is defined as a set of rules to administer, manage, and
+ control access to network resources.
+
+ This work is currently under joint development in the IETF's Policy
+ Framework working group and in the Policy working group of the
+ Distributed Management Task Force (DMTF). This model defines two
+ hierarchies of object classes: structural classes representing policy
+ information and control of policies, and relationship classes that
+ indicate how instances of the structural classes are related to each
+ other. In general, both of these class hierarchies will need to be
+ mapped to a particular data store.
+
+ This document defines the mapping of these information model classes
+ to a directory that uses LDAP as its access protocol. Two types of
+ mappings are involved:
+
+ - For the structural classes in the information model, the
+ mapping is basically one-for-one: information model classes map
+ to LDAP classes, information model properties map to LDAP
+ attributes.
+
+ - For the relationship classes in the information model,
+ different mappings are possible. In this document, the Policy
+ Core Information Model's (PCIM's) relationship classes and
+ their properties are mapped in three ways: to LDAP auxiliary
+ classes, to attributes representing distinguished name (DN)
+ references, and to superior-subordinate relationships in the
+ Directory Information Tree (DIT).
+
+ Implementations that use an LDAP directory as their policy repository
+ and want to implement policy information according to RFC 3060 [1]
+ SHALL use the LDAP schema defined in this document, or a schema that
+ subclasses from the schema defined in this document. The use of the
+ information model defined in reference [1] as the starting point
+ enables the inheritance and the relationship class hierarchies to be
+ extensible, such that other types of policy repositories, such as
+ relational databases, can also use this information.
+
+ This document fits into the overall framework for representing,
+ deploying, and managing policies being developed by the Policy
+ Framework Working Group.
+
+ The LDAP schema described in this document uses the prefix "pcim" to
+ identify its classes and attributes. It consists of ten very general
+ classes: pcimPolicy (an abstract class), three policy group classes
+ (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy
+ rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and
+ three special auxiliary classes (pcimConditionAuxClass,
+
+
+
+Strassner, et al. Standards Track [Page 3]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ pcimTPCAuxClass, and pcimActionAuxClass). (Note that the
+ PolicyTimePeriodCondition auxiliary class defined in [1] would
+ normally have been named pcimTimePeriodConditionAuxClass, but this
+ name is too long for some directories. Therefore, we have
+ abbreviated this name to be pcimTPCAuxClass).
+
+ The mapping for the PCIM classes pcimGroup and pcimRule is designed
+ to be as flexible as possible. Three classes are defined for these
+ two PCIM classes. First, an abstract superclass is defined that
+ contains all required properties of each PCIM class. Then, both an
+ auxiliary class as well as a structural class are derived from the
+ abstract superclass. This provides maximum flexibility for the
+ developer.
+
+ The schema also contains two less general classes:
+ pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve
+ the mapping of the information model's relationships, the schema also
+ contains two auxiliary classes: pcimGroupContainmentAuxClass and
+ pcimRuleContainmentAuxClass. Capturing the distinction between
+ rule-specific and reusable policy conditions and policy actions
+ introduces seven other classes: pcimRuleConditionAssociation,
+ pcimRuleValidityAssociation, pcimRuleActionAssociation,
+ pcimPolicyInstance, and three policy repository classes
+ (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance).
+ Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and
+ pcimElementAuxClass) for optimizing LDAP retrievals. In all, the
+ schema contains 23 classes.
+
+ Within the context of this document, the term "PCLS" (Policy Core
+ LDAP Schema) is used to refer to the LDAP class definitions that this
+ document contains. The term "PCIM" refers to classes defined in [1].
+
+ 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 RFC 2119 [10].
+
+2. The Policy Core Information Model
+
+ This document contains an LDAP schema representing the classes
+ defined in the companion document "Policy Core Information
+ Model -- Version 1 Specification" [1]. Other documents may
+ subsequently be produced, with mappings of this same PCIM to other
+ storage technologies. Since the detailed semantics of the PCIM
+ classes appear only in [1], that document is a prerequisite for
+ reading and understanding this document.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 4]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+3. Inheritance Hierarchy for the PCLS
+
+ The following diagram illustrates the class hierarchy for the LDAP
+ Classes defined in this document:
+
+ top
+ |
+ +--dlm1ManagedElement (abstract)
+ | |
+ | +--pcimPolicy (abstract)
+ | | |
+ | | +--pcimGroup (abstract)
+ | | | |
+ | | | +--pcimGroupAuxClass (auxiliary)
+ | | | |
+ | | | +--pcimGroupInstance (structural)
+ | | |
+ | | +--pcimRule (abstract)
+ | | | |
+ | | | +--pcimRuleAuxClass (auxiliary)
+ | | | |
+ | | | +--pcimRuleInstance (structural)
+ | | |
+ | | +--pcimRuleConditionAssociation (structural)
+ | | |
+ | | +--pcimRuleValidityAssociation (structural)
+ | | |
+ | | +--pcimRuleActionAssociation (structural)
+ | | |
+ | | +--pcimPolicyInstance (structural)
+ | | |
+ | | +--pcimElementAuxClass (auxiliary)
+ | |
+ | +--dlm1ManagedSystemElement (abstract)
+ | |
+ | +--dlm1LogicalElement (abstract)
+ | |
+ | +--dlm1System (abstract)
+ | |
+ | +--dlm1AdminDomain (abstract)
+ | |
+ | +--pcimRepository (abstract)
+ | |
+ | +--pcimRepositoryAuxClass (auxiliary)
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 5]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ top
+ | |
+ | +--pcimRepositoryInstance
+ | (structural)
+ |
+ +--pcimConditionAuxClass (auxiliary)
+ | |
+ | +---pcimTPCAuxClass (auxiliary)
+ | |
+ | +---pcimConditionVendorAuxClass (auxiliary)
+ |
+ +--pcimActionAuxClass (auxiliary)
+ | |
+ | +---pcimActionVendorAuxClass (auxiliary)
+ |
+ +--pcimSubtreesPtrAuxClass (auxiliary)
+ |
+ +--pcimGroupContainmentAuxClass (auxiliary)
+ |
+ +--pcimRuleContainmentAuxClass (auxiliary)
+
+ Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
+
+4. General Discussion of Mapping the Information Model to LDAP
+
+ The classes described in Section 5 below contain certain
+ optimizations for a directory that uses LDAP as its access protocol.
+ One example of this is the use of auxiliary classes to represent some
+ of the associations defined in the information model. Other data
+ stores might need to implement these associations differently. A
+ second example is the introduction of classes specifically designed
+ to optimize retrieval of large amounts of policy-related data from a
+ directory. This section discusses some general topics related to the
+ mapping from the information model to LDAP.
+
+ The remainder of this section will discuss the following topics.
+ Section 4.1 will discuss the strategy used in mapping the classes and
+ associations defined in [1] to a form that can be represented in a
+ directory that uses LDAP as its access protocol. Section 4.2
+ discusses DIT content and structure rules, as well as name forms.
+ Section 4.3 describes the strategy used in defining naming attributes
+ for the schema described in Section 5 of this document. Section 4.4
+ defines the strategy recommended for locating and retrieving
+ PCIM-derived objects in the directory.
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 6]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.1. Summary of Class and Association Mappings
+
+ Fifteen of the classes in the PCLS come directly from the nine
+ corresponding classes in the information model. Note that names of
+ classes begin with an upper case character in the information model
+ (although for CIM in particular, case is not significant in class and
+ property names), but with a lower case character in LDAP. This is
+ because although LDAP doesn't care, X.500 doesn't allow class names
+ to begin with an uppercase character. Note also that the prefix
+ "pcim" is used to identify these LDAP classes.
+
+ +---------------------------+-------------------------------+
+ | Information Model | LDAP Class(es) |
+ +---------------------------+-------------------------------+
+ +---------------------------+-------------------------------+
+ | Policy | pcimPolicy |
+ +---------------------------+-------------------------------+
+ | PolicyGroup | pcimGroup |
+ | | pcimGroupAuxClass |
+ | | pcimGroupInstance |
+ +---------------------------+-------------------------------+
+ | PolicyRule | pcimRule |
+ | | pcimRuleAuxClass |
+ | | pcimRuleInstance |
+ +---------------------------+-------------------------------+
+ | PolicyCondition | pcimConditionAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyAction | pcimActionAuxClass |
+ +---------------------------+-------------------------------+
+ | VendorPolicyCondition | pcimConditionVendorAuxClass |
+ +---------------------------+-------------------------------+
+ | VendorPolicyAction | pcimActionVendorAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyTimePeriodCondition | pcimTPCAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyRepository | pcimRepository |
+ | | pcimRepositoryAuxClass |
+ | | pcimRepositoryInstance |
+ +---------------------------+-------------------------------+
+
+ Figure 2. Mapping of Information Model Classes to LDAP
+
+ The associations in the information model map to attributes that
+ reference DNs (Distinguished Names) or to Directory Information Tree
+ (DIT) containment (i.e., superior-subordinate relationships) in LDAP.
+ Two of the attributes that reference DNs appear in auxiliary classes,
+ which allow each of them to represent several relationships from the
+ information model.
+
+
+
+Strassner, et al. Standards Track [Page 7]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
++----------------------------------+----------------------------------+
+| Information Model Association | LDAP Attribute / Class |
++-----------------------------------+---------------------------------+
++-----------------------------------+---------------------------------+
+| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in |
+| | pcimGroupContainmentAuxClass |
++-----------------------------------+---------------------------------+
+| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in |
+| | pcimRuleContainmentAuxClass |
++-----------------------------------+---------------------------------+
+| PolicyConditionInPolicyRule | DIT containment or |
+| | pcimRuleConditionList in |
+| | pcimRule or |
+| | pcimConditionDN in |
+| | pcimRuleConditionAssociation |
++-----------------------------------+---------------------------------+
+| PolicyActionInPolicyRule | DIT containment or |
+| | pcimRuleActionList in |
+| | pcimRule or |
+| | pcimActionDN in |
+| | pcimRuleActionAssociation |
++-----------------------------------+---------------------------------+
+| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList |
+| | in pcimRule or (if reusable) |
+| | referenced through the |
+| | pcimTimePeriodConditionDN in |
+| | pcimRuleValidityAssociation |
++-----------------------------------+---------------------------------+
+| PolicyConditionInPolicyRepository | DIT containment |
++-----------------------------------+---------------------------------+
+| PolicyActionInPolicyRepository | DIT containment |
++-----------------------------------+---------------------------------+
+| PolicyRepositoryInPolicyRepository| DIT containment |
++-----------------------------------+---------------------------------+
+
+ Figure 3. Mapping of Information Model Associations to LDAP
+
+ Of the remaining classes in the PCLS, two (pcimElementAuxClass and
+ pcimSubtreesPtrAuxClass) are included to make navigation through the
+ DIT and retrieval of the entries found there more efficient. This
+ topic is discussed below in Section 4.5.
+
+ The remaining four classes in the PCLS, pcimRuleConditionAssociation,
+ pcimRuleValidityAssociation, pcimRuleActionAssociation, and
+ pcimPolicyInstance, are all involved with the representation of
+ policy conditions and policy actions in an LDAP directory. This
+ topic is discussed below in Section 4.4.
+
+
+
+
+Strassner, et al. Standards Track [Page 8]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.2. Usage of DIT Content and Structure Rules and Name Forms
+
+ There are three powerful tools that can be used to help define
+ schemata. The first, DIT content rules, is a way of defining the
+ content of an entry for a structural object class. It can be used to
+ specify the following characteristics of the entry:
+
+ - additional mandatory attributes that the entries are required
+ to contain
+ - additional optional attributes the entries are allowed to
+ contain
+ - the set of additional auxiliary object classes that these
+ entries are allowed to be members of
+ - any optional attributes from the structural and auxiliary
+ object class definitions that the entries are required to
+ preclude
+
+ DIT content rules are NOT mandatory for any structural object class.
+
+ A DIT structure rule, together with a name form, controls the
+ placement and naming of an entry within the scope of a subschema.
+ Name forms define which attribute type(s) are required and are
+ allowed to be used in forming the Relative Distinguished Names (RDNs)
+ of entries. DIT structure rules specify which entries are allowed to
+ be superior to other entries, and hence control the way that RDNs are
+ added together to make DNs.
+
+ A name form specifies the following:
+
+ - the structural object class of the entries named by this name
+ form
+ - attributes that are required to be used in forming the RDNs of
+ these entries
+ - attributes that are allowed to be used in forming the RDNs of
+ these entries
+ - an object identifier to uniquely identify this name form
+
+ Note that name forms can only be specified for structural object
+ classes. However, every entry in the DIT must have a name form
+ controlling it.
+
+ Unfortunately, current LDAP servers vary quite a lot in their support
+ of these features. There are also three crucial implementation
+ points that must be followed. First, X.500 use of structure rules
+ requires that a structural object class with no superior structure
+ rule be a subschema administrative point. This is exactly NOT what
+ we want for policy information. Second, when an auxiliary class is
+ subclassed, if a content rule exists for the structural class that
+
+
+
+Strassner, et al. Standards Track [Page 9]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ the auxiliary class refers to, then that content rule needs to be
+ augmented. Finally, most LDAP servers unfortunately do not support
+ inheritance of structure and content rules.
+
+ Given these concerns, DIT structure and content rules have been
+ removed from the PCLS. This is because, if included, they would be
+ normative references and would require OIDs. However, we don't want
+ to lose the insight gained in building the structure and content
+ rules of the previous version of the schema. Therefore, we describe
+ where such rules could be used in this schema, what they would
+ control, and what their effect would be.
+
+4.3. Naming Attributes in the PCLS
+
+ Instances in a directory are identified by distinguished names (DNs),
+ which provide the same type of hierarchical organization that a file
+ system provides in a computer system. A distinguished name is a
+ sequence of RDNs. An RDN provides a unique identifier for an
+ instance within the context of its immediate superior, in the same
+ way that a filename provides a unique identifier for a file within
+ the context of the folder in which it resides.
+
+ To preserve maximum naming flexibility for policy administrators,
+ three optional (i.e., "MAY") naming attributes have been defined.
+ They are:
+
+ - Each of the structural classes defined in this schema has its
+ own unique ("MAY") naming attribute. Since the naming
+ attributes are different, a policy administrator can, by using
+ these attributes, guarantee that there will be no name
+ collisions between instances of different classes, even if the
+ same value is assigned to the instances' respective naming
+ attributes.
+
+ - The LDAP attribute cn (corresponding to X.500's commonName) is
+ included as a MAY attribute in the abstract class pcimPolicy,
+ and thus by inheritance in all of its subclasses. In X.500,
+ commonName typically functions as an RDN attribute, for naming
+ instances of many classes (e.g., X.500's person class).
+
+ - A special attribute is provided for implementations that expect
+ to map between native CIM and LDAP representations of policy
+ information. This attribute, called orderedCimKeys, is defined
+ in the class dlm1ManagedElement [6]. The value of this
+ attribute is derived algorithmically from values that are
+ already present in a CIM policy instance. The normative
+ reference for this algorithm is contained in [6]. See the
+ appendix of this document for a description of the algorithm.
+
+
+
+Strassner, et al. Standards Track [Page 10]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Since any of these naming attributes MAY be used for naming an
+ instance of a PCLS class, implementations MUST be able to accommodate
+ instances named in any of these ways.
+
+ Note that it is recommended that two or more of these attributes
+ SHOULD NOT be used together to form a multi-part RDN, since support
+ for multi-part RDNs is limited among existing directory
+ implementations.
+
+4.4. Rule-Specific and Reusable Conditions and Actions
+
+ The PCIM [1] distinguishes between two types of policy conditions and
+ policy actions: those associated with a single policy rule, and
+ those that are reusable, in the sense that they may be associated
+ with more than one policy rule. While there is no inherent
+ functional difference between a rule-specific condition or action and
+ a reusable one, there is both a usage, as well as, an implementation
+ difference between them.
+
+ Defining a condition or action as reusable vs. rule-specific reflects
+ a conscious decision on the part of the administrator in defining how
+ they are used. In addition, there are variations that reflect
+ implementing rule-specific vs. reusable policy conditions and actions
+ and how they are treated in a policy repository. The major
+ implementation differences between a rule-specific and a reusable
+ condition or action are delineated below:
+
+ 1. It is natural for a rule-specific condition or action to be
+ removed from the policy repository at the same time the rule is.
+ It is just the opposite for reusable conditions and actions.
+ This is because the condition or action is conceptually attached
+ to the rule in the rule-specific case, whereas it is referenced
+ (e.g., pointed at) in the reusable case. The persistence of a
+ pcimRepository instance is independent of the persistence of a
+ pcimRule instance.
+ 2. Access permissions for a rule-specific condition or action are
+ usually identical to those for the rule itself. On the other
+ hand, access permissions of reusable conditions and actions must
+ be expressible without reference to a policy rule.
+ 3. Rule-specific conditions and actions require fewer accesses,
+ because the conditions and actions are "attached" to the rule.
+ In contrast, reusable conditions and actions require more
+ accesses, because each condition or action that is reusable
+ requires a separate access.
+ 4. Rule-specific conditions and actions are designed for use by a
+ single rule. As the number of rules that use the same
+ rule-specific condition increase, subtle problems are created
+ (the most obvious being how to keep the rule-specific conditions
+
+
+
+Strassner, et al. Standards Track [Page 11]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ and actions updated to reflect the same value). Reusable
+ conditions and actions lend themselves for use by multiple
+ independent rules.
+ 5. Reusable conditions and actions offer an optimization when
+ multiple rules are using the same condition or action. This is
+ because the reusable condition or action only needs be updated
+ once, and by virtue of DN reference, the policy rules will be
+ automatically updated.
+
+ The preceding paragraph does not contain an exhaustive list of the
+ ways in which reusable and rule-specific conditions should be treated
+ differently. Its purpose is merely to justify making a semantic
+ distinction between rule-specific and reusable, and then reflecting
+ this distinction in the policy repository itself.
+
+ When the policy repository is realized in an LDAP-accessible
+ directory, the distinction between rule-specific and reusable
+ conditions and actions is realized via placement of auxiliary classes
+ and via DIT containment. Figure 4 illustrates a policy rule Rule1
+ with one rule-specific condition CA and one rule-specific action AB.
+
+ +-----+
+ |Rule1|
+ | |
+ +-----|- -|-----+
+ | +-----+ |
+ | * * |
+ | * * |
+ | **** **** |
+ | * * |
+ v * * v
+ +--------+ +--------+
+ | CA+ca | | AB+ab |
+ +--------+ +--------+
+
+
+ +------------------------------+
+ |LEGEND: |
+ | ***** DIT containment |
+ | + auxiliary attachment |
+ | ----> DN reference |
+ +------------------------------+
+
+ Figure 4 Rule-Specific Policy Conditions and Actions
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 12]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Because the condition and action are specific to Rule1, the auxiliary
+ classes ca and ab that represent them are attached, respectively, to
+ the structural classes CA and AB. These structural classes represent
+ not the condition ca and action ab themselves, but rather the
+ associations between Rule1 and ca, and between Rule1 and ab.
+
+ As Figure 4 illustrates, Rule1 contains DN references to the
+ structural classes CA and AB that appear below it in the DIT. At
+ first glance it might appear that these DN references are
+ unnecessary, since a subtree search below Rule1 would find all of the
+ structural classes representing the associations between Rule1 and
+ its conditions and actions. Relying only on a subtree search,
+ though, runs the risk of missing conditions or actions that should
+ have appeared in the subtree, but for some reason did not, or of
+ finding conditions or actions that were inadvertently placed in the
+ subtree, or that should have been removed from the subtree, but for
+ some reason were not. Implementation experience has suggested that
+ many (but not all) of these risks are eliminated.
+
+ However, it must be noted that this comes at a price. The use of DN
+ references, as shown in Figure 4 above, thwarts inheritance of access
+ control information as well as existence dependency information. It
+ also is subject to referential integrity considerations. Therefore,
+ it is being included as an option for the designer.
+
+ Figure 5 illustrates a second way of representing rule-specific
+ conditions and actions in an LDAP-accessible directory: attachment of
+ the auxiliary classes directly to the instance representing the
+ policy rule. When all of the conditions and actions are attached to
+ a policy rule in this way, the rule is termed a "simple" policy rule.
+ When conditions and actions are not attached directly to a policy
+ rule, the rule is termed a "complex" policy rule.
+
+ +-----------+
+ |Rule1+ca+ab|
+ | |
+ +-----------+
+
+ +------------------------------+
+ |LEGEND: |
+ | + auxiliary attachment |
+ +------------------------------+
+
+ Figure 5. A Simple Policy Rule
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 13]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The simple/complex distinction for a policy rule is not all or
+ nothing. A policy rule may have its conditions attached to itself
+ and its actions attached to other entries, or it may have its actions
+ attached to itself and its conditions attached to other entries.
+ However, it SHALL NOT have either its conditions or its actions
+ attached both to itself and to other entries, with one exception: a
+ policy rule may reference its validity periods with the
+ pcimRuleValidityPeriodList attribute, but have its other conditions
+ attached to itself.
+
+ The tradeoffs between simple and complex policy rules are between the
+ efficiency of simple rules and the flexibility and greater potential
+ for reuse of complex rules. With a simple policy rule, the semantic
+ options are limited:
+
+ - All conditions are ANDed together. This combination can be
+ represented in two ways in the Disjunctive Normal Form (DNF)/
+ Conjunctive Normal Form (CNF) (please see [1] for definitions of
+ these terms) expressions characteristic of policy conditions: as
+ a DNF expression with a single AND group, or as a CNF expression
+ with multiple single-condition OR groups. The first of these is
+ arbitrarily chosen as the representation for the ANDed conditions
+ in a simple policy rule.
+
+ - If multiple actions are included, no order can be specified for
+ them.
+
+ If a policy administrator needs to combine conditions in some other
+ way, or if there is a set of actions that must be ordered, then the
+ only option is to use a complex policy rule.
+
+ Finally, Figure 6 illustrates the same policy rule Rule1, but this
+ time its condition and action are reusable. The association classes
+ CA and AB are still present, and they are still DIT contained under
+ Rule1. But rather than having the auxiliary classes ca and ab
+ attached directly to the association classes CA and AB, each now
+ contains DN references to other entries to which these auxiliary
+ classes are attached. These other entries, CIA and AIB, are DIT
+ contained under RepositoryX, which is an instance of the class
+ pcimRepository. Because they are named under an instance of
+ pcimRepository, ca and ab are clearly identified as reusable.
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 14]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ +-----+ +-------------+
+ |Rule1| | RepositoryX |
+ +-|- -|--+ | |
+ | +-----+ | +-------------+
+ | * * | * *
+ | * * | * *
+ | *** **** | * *
+ | * * v * *
+ | * +---+ * *
+ | * |AB | +------+ *
+ v * | -|-------->|AIB+ab| *
+ +---+ +---+ +------+ *
+ |CA | +------+
+ | -|------------------------>|CIA+ca|
+ +---+ +------+
+
+ +------------------------------+
+ |LEGEND: |
+ | ***** DIT containment |
+ | + auxiliary attachment |
+ | ----> DN reference |
+ +------------------------------+
+
+ Figure 6. Reusable Policy Conditions and Actions
+
+ The classes pcimConditionAuxClass and pcimActionAuxClass do not
+ themselves represent actual conditions and actions: these are
+ introduced in their subclasses. What pcimConditionAuxClass and
+ pcimActionAuxClass do introduce are the semantics of being a policy
+ condition or a policy action. These are the semantics that all the
+ subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit.
+ Among these semantics are those of representing either a
+ rule-specific or a reusable policy condition or policy action.
+
+ In order to preserve the ability to represent a rule-specific or a
+ reusable condition or action, as well as a simple policy rule, all
+ the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST
+ also be auxiliary classes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 15]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.5. Location and Retrieval of Policy Objects in the Directory
+
+ When a Policy Decision Point (PDP) goes to an LDAP directory to
+ retrieve the policy object instances relevant to the Policy
+ Enforcement Points (PEPs) it serves, it is faced with two related
+ problems:
+
+ - How does it locate and retrieve the directory entries that apply
+ to its PEPs? These entries may include instances of the PCLS
+ classes, instances of domain-specific subclasses of these
+ classes, and instances of other classes modeling such resources
+ as user groups, interfaces, and address ranges.
+
+ - How does it retrieve the directory entries it needs in an
+ efficient manner, so that retrieval of policy information from
+ the directory does not become a roadblock to scalability? There
+ are two facets to this efficiency: retrieving only the relevant
+ directory entries, and retrieving these entries using as few LDAP
+ calls as possible.
+
+ The placement of objects in the Directory Information Tree (DIT)
+ involves considerations other than how the policy-related objects
+ will be retrieved by a PDP. Consequently, all that the PCLS can do
+ is to provide a "toolkit" of classes to assist the policy
+ administrator as the DIT is being designed and built. A PDP SHOULD
+ be able to take advantage of any tools that the policy administrator
+ is able to build into the DIT, but it MUST be able to use a less
+ efficient means of retrieval if that is all it has available to it.
+
+ The basic idea behind the LDAP optimization classes is a simple one:
+ make it possible for a PDP to retrieve all the policy-related objects
+ it needs, and only those objects, using as few LDAP calls as
+ possible. An important assumption underlying this approach is that
+ the policy administrator has sufficient control over the underlying
+ DIT structure to define subtrees for storing policy information. If
+ the policy administrator does not have this level of control over DIT
+ structure, a PDP can still retrieve the policy-related objects it
+ needs individually. But it will require more LDAP access operations
+ to do the retrieval in this way. Figure 7 illustrates how LDAP
+ optimization is accomplished.
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 16]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ +-----+
+ ---------------->| A |
+ DN reference to | | DN references to subtrees +---+
+ starting object +-----+ +-------------------------->| C |
+ | o--+----+ +---+ +---+
+ | o--+------------->| B | / \
+ +-----+ +---+ / \
+ / \ / \ / ... \
+ / \ / \
+ / \ / ... \
+
+ Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies
+
+ The PDP is configured initially with a DN reference to some entry in
+ the DIT. The structural class of this entry is not important; the
+ PDP is interested only in the pcimSubtreesPtrAuxClass attached to it.
+ This auxiliary class contains a multi-valued attribute with DN
+ references to objects that anchor subtrees containing policy-related
+ objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an
+ auxiliary class, it can be attached to an entry that the PDP would
+ need to access anyway - perhaps an entry containing initial
+ configuration settings for the PDP, or for a PEP that uses the PDP.
+
+ Once it has retrieved the DN references, the PDP will direct to each
+ of the objects identified by them an LDAP request that all entries in
+ its subtree be evaluated against the selection criteria specified in
+ the request. The LDAP-enabled directory then returns all entries in
+ that subtree that satisfy the specified criteria.
+
+ The selection criteria always specify that object class="pcimPolicy".
+ Since all classes representing policy rules, policy conditions, and
+ policy actions, both in the PCLS and in any domain-specific schema
+ derived from it, are subclasses of the abstract class policy, this
+ criterion evaluates to TRUE for all instances of these classes. To
+ accommodate special cases where a PDP needs to retrieve objects that
+ are not inherently policy-related (for example, an IP address range
+ object referenced by a subclass of pcimActionAuxClass representing
+ the DHCP action "assign from this address range"), the auxiliary
+ class pcimElementAuxClass can be used to "tag" an entry, so that it
+ will be found by the selection criterion "object class=pcimPolicy".
+
+ The approach described in the preceding paragraph will not work for
+ certain directory implementations, because these implementations do
+ not support matching of auxiliary classes in the objectClass
+ attribute. For environments where these implementations are expected
+ to be present, the "tagging" of entries as relevant to policy can be
+
+
+
+
+
+Strassner, et al. Standards Track [Page 17]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ accomplished by inserting the special value "POLICY" into the list of
+ values contained in the pcimKeywords attribute (provided by the
+ pcimPolicy class).
+
+ If a PDP needs only a subset of the policy-related objects in the
+ indicated subtrees, then it can be configured with additional
+ selection criteria based on the pcimKeywords attribute defined in the
+ pcimPolicy class. This attribute supports both standardized and
+ administrator- defined values. For example, a PDP could be
+ configured to request only those policy-related objects containing
+ the keywords "DHCP" and "Eastern US".
+
+ To optimize what is expected to be a typical case, the initial
+ request from the client includes not only the object to which its
+ "seed" DN references, but also the subtree contained under this
+ object. The filter for searching this subtree is whatever the client
+ is going to use later to search the other subtrees: object
+ class="pcimPolicy" or the presence of the keyword "POLICY", and/or
+ presence of a more specific value of pcimKeywords (e.g., "QoS Edge
+ Policy").
+
+ Returning to the example in Figure 7, we see that in the best case, a
+ PDP can get all the policy-related objects it needs, and only those
+ objects, with exactly three LDAP requests: one to its starting
+ object A to get the references to B and C, as well as the
+ policy-related objects it needs from the subtree under A, and then
+ one each to B and C to get all the policy-related objects that pass
+ the selection criteria with which it was configured. Once it has
+ retrieved all of these objects, the PDP can then traverse their
+ various DN references locally to understand the semantic
+ relationships among them. The PDP should also be prepared to find a
+ reference to another subtree attached to any of the objects it
+ retrieves, and to follow this reference first, before it follows any
+ of the semantically significant references it has received. This
+ recursion permits a structured approach to identifying related
+ policies. In Figure 7, for example, if the subtree under B includes
+ departmental policies and the one under C includes divisional
+ policies, then there might be a reference from the subtree under C to
+ an object D that roots the subtree of corporate-level policies.
+
+ A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be
+ capable of retrieving and processing the entries in the subtrees it
+ references, and SHOULD be capable of doing all of this recursively.
+ The same requirements apply to any other entity needing to retrieve
+ policy information from the directory. Thus, a Policy Management
+ Tool that retrieves policy entries from the directory in order to
+ perform validation and conflict detection SHOULD also understand and
+ be capable of using the pcimSubtreesPtrAuxClass. All of these
+
+
+
+Strassner, et al. Standards Track [Page 18]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ requirements are "SHOULD"s rather than "MUST"s because an LDAP client
+ that doesn't implement them can still access and retrieve the
+ directory entries it needs. The process of doing so will just be
+ less efficient than it would have been if the client had implemented
+ these optimizations.
+
+ When it is serving as a tool for creating policy entries in the
+ directory, a Policy Management Tool SHOULD support creation of
+ pcimSubtreesPtrAuxClass entries and their references to object
+ instances.
+
+4.5.1. Aliases and Other DIT-Optimization Techniques
+
+ Additional flexibility in DIT structure is available to the policy
+ administrator via LDAP aliasing and other techniques. Previous
+ versions of this document have used aliases. However, because
+ aliases are experimental, the use of aliases has been removed from
+ this version of this document. This is because the IETF has yet to
+ produce a specification on how aliases are represented in the
+ directory or how server implementations are to process aliases.
+
+5. Class Definitions
+
+ The semantics for the policy information classes that are to be
+ mapped directly from the information model to an LDAP representation
+ are detailed in [1]. Consequently, all that this document presents
+ for these classes is the specification for how to do the mapping from
+ the information model (which is independent of repository type and
+ access protocol) to a form that can be accessed using LDAP. Remember
+ that some new classes needed to be created (that were not part of
+ [1]) to implement the LDAP mapping. These new LDAP-only classes are
+ fully documented in this document.
+
+ The formal language for specifying the classes, attributes, and DIT
+ structure and content rules is that defined in reference [3]. If
+ your implementation does not support auxiliary class inheritance, you
+ will have to list auxiliary classes in content rules explicitly or
+ define them in another (implementation-specific) way.
+
+ The following notes apply to this section in its entirety.
+
+ Note 1: in the following definitions, the class and attribute
+ definitions follow RFC 2252 [3] but they are line-wrapped to enhance
+ human readability.
+
+ Note 2: where applicable, the possibilities for specifying DIT
+ structure and content rules are noted. However, care must be taken
+ in specifying DIT structure rules. This is because X.501 [4] states
+
+
+
+Strassner, et al. Standards Track [Page 19]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ that an entry may only exist in the DIT as a subordinate to another
+ superior entry (the superior) if a DIT structure rule exists in the
+ governing subschema which:
+
+ 1) indicates a name form for the structural object class of the
+ subordinate entry, and
+ 2) either includes the entry's superior structure rule as a possible
+ superior structure rule, or
+ 3) does not specify a superior structure rule.
+
+ If this last case (3) applies, then the entry is defined to be a
+ subschema administrative point. This is not what is desired.
+ Therefore, care must be taken in defining structure rules, and in
+ particular, they must be locally augmented.
+
+ Note 3: Wherever possible, both an equality and a substring matching
+ rule are defined for a particular attribute (as well as an ordering
+ match rule to enable sorting of matching results). This provides two
+ different choices for the developer for maximum flexibility.
+
+ For example, consider the pcimRoles attribute (section 5.3). Suppose
+ that a PEP has reported that it is interested in pcimRules for three
+ roles R1, R2, and R3. If the goal is to minimize queries, then the
+ PDP can supply three substring filters containing the three role
+ names.
+
+ These queries will return all of the pcimRules that apply to the PEP,
+ but they may also get some that do not apply (e.g., ones that contain
+ one of the roles R1, R2, or R3 and one or more other roles present in
+ a role-combination [1]).
+
+ Another strategy would be for the PDP to use only equality filters.
+ This approach eliminates the extraneous replies, but it requires the
+ PDP to explicitly build the desired role-combinations itself. It
+ also requires extra queries. Note that this approach is practical
+ only because the role names in a role combination are required to
+ appear in alphabetical order.
+
+ Note 4: in the following definitions, note that all LDAP matching
+ rules are defined in [3] and in [9]. The corresponding X.500
+ matching rules are defined in [8].
+
+ Note 5: some of the following attribute definitions specify
+ additional constraints on various data types (e.g., this integer has
+ values that are valid from 1..10). Text has been added to instruct
+ servers and applications what to do if a value outside of this range
+
+
+
+
+
+Strassner, et al. Standards Track [Page 20]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ is encountered. In all cases, if a constraint is violated, then the
+ policy rule SHOULD be treated as being disabled, meaning that
+ execution of the policy rule SHOULD be stopped.
+
+5.1. The Abstract Class pcimPolicy
+
+ The abstract class pcimPolicy is a direct mapping of the abstract
+ class Policy from the PCIM. The class value "pcimPolicy" is also
+ used as the mechanism for identifying policy-related instances in the
+ Directory Information Tree. An instance of any class may be "tagged"
+ with this class value by attaching to it the auxiliary class
+ pcimElementAuxClass. Since pcimPolicy is derived from the class
+ dlm1ManagedElement defined in reference [6], this specification has a
+ normative dependency on that element of reference [6].
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy'
+ DESC 'An abstract class that is the base class for all classes
+ that describe policy-related instances.'
+ SUP dlm1ManagedElement
+ ABSTRACT
+ MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
+ pcimKeywords )
+ )
+
+ The attribute cn is defined in RFC 2256 [7]. The dlmCaption,
+ dlmDescription, and orderedCimKeys attributes are defined in [6].
+
+ The pcimKeywords attribute is a multi-valued attribute that contains
+ a set of keywords to assist directory clients in locating the policy
+ objects identified by these keywords. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords'
+ DESC 'A set of keywords to assist directory clients in
+ locating the policy objects applicable to them.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 21]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+5.2. The Three Policy Group Classes
+
+ PCIM [1] defines the PolicyGroup class to serve as a generalized
+ aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be
+ aggregated together. PCLS maps this class into three LDAP classes,
+ called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is
+ done in order to provide maximum flexibility for the DIT designer.
+
+ The class definitions for the three policy group classes are listed
+ below. These class definitions do not include attributes to realize
+ the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations
+ from the PCIM. This is because a pcimGroup object refers to
+ instances of pcimGroup and pcimRule via, respectively, the attribute
+ pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object
+ class and the attribute pcimRulesAuxContainedSet in the
+ pcimRuleContainmentAuxClass object class.
+
+ To maximize flexibility, the pcimGroup class is defined as abstract.
+ The subclass pcimGroupAuxClass provides for auxiliary attachment to
+ another entry, while the structural subclass pcimGroupInstance is
+ available to represent a policy group as a standalone entry.
+
+ The class definitions are as follows. First, the definition of the
+ abstract class pcimGroup:
+
+ ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup'
+ DESC 'A container for a set of related pcimRules and/or
+ a set of related pcimGroups.'
+ SUP pcimPolicy
+ ABSTRACT
+ MAY ( pcimGroupName )
+ )
+
+ The one attribute of pcimGroup is pcimGroupName. This attribute is
+ used to define a user-friendly name of this policy group, and may be
+ used as a naming attribute if desired. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
+ DESC 'The user-friendly name of this policy group.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 22]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The two subclasses of pcimGroup are defined as follows. The class
+ pcimGroupAuxClass is an auxiliary class that can be used to collect a
+ set of related pcimRule and/or pcimGroup classes. It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass'
+ DESC 'An auxiliary class that collects a set of related
+ pcimRule and/or pcimGroup entries.'
+ SUP pcimGroup
+ AUXILIARY
+ )
+
+ The class pcimGroupInstance is a structural class that can be used to
+ collect a set of related pcimRule and/or pcimGroup classes. It is
+ defined as follows:
+
+ ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance'
+ DESC 'A structural class that collects a set of related
+ pcimRule and/or pcimGroup entries.'
+ SUP pcimGroup
+ STRUCTURAL
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimGroupInstance to have attached to it either references to one or
+ more policy groups (using pcimGroupContainmentAuxClass) or references
+ to one or more policy rules (using pcimRuleContainmentAuxClass).
+ This would be used to formalize the semantics of the PolicyGroup
+ class [1]. Since these semantics do not include specifying any
+ properties of the PolicyGroup class, the content rule would not need
+ to specify any attributes.
+
+ Similarly, three separate DIT structure rules could be written, each
+ of which would refer to a specific name form that identified one of
+ the three possible naming attributes (i.e., pcimGroupName, cn, and
+ orderedCIMKeys) for the pcimGroup object class. This structure rule
+ SHOULD include a superiorStructureRule (see Note 2 at the beginning
+ of section 5). The three name forms referenced by the three
+ structure rules would each define one of the three naming attributes.
+
+5.3. The Three Policy Rule Classes
+
+ The information model defines a PolicyRule class to represent the "If
+ Condition then Action" semantics associated with processing policy
+ information. For maximum flexibility, the PCLS maps this class into
+ three LDAP classes.
+
+
+
+
+
+Strassner, et al. Standards Track [Page 23]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ To maximize flexibility, the pcimRule class is defined as abstract.
+ The subclass pcimRuleAuxClass provides for auxiliary attachment to
+ another entry, while the structural subclass pcimRuleInstance is
+ available to represent a policy rule as a standalone entry.
+
+ The conditions and actions associated with a policy rule are modeled,
+ respectively, with auxiliary subclasses of the auxiliary classes
+ pcimConditionAuxClass and pcimActionAuxClass. Each of these
+ auxiliary subclasses is attached to an instance of one of three
+ structural classes. A subclass of pcimConditionAuxClass is attached
+ to an instance of pcimRuleInstance, to an instance of
+ pcimRuleConditionAssociation, or to an instance of
+ pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is
+ attached to an instance of pcimRuleInstance, to an instance of
+ pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.
+
+ The pcimRuleValidityPeriodList attribute (defined below) realizes the
+ PolicyRuleValidityPeriod association defined in the PCIM. Since this
+ association has no additional properties besides those that tie the
+ association to its associated objects, this association can be
+ realized by simply using an attribute. Thus, the
+ pcimRuleValidityPeriodList attribute is simply a multi-valued
+ attribute that provides an unordered set of DN references to one or
+ more instances of the pcimTPCAuxClass, indicating when the policy
+ rule is scheduled to be active and when it is scheduled to be
+ inactive. A policy rule is scheduled to be active if it is active
+ according to AT LEAST ONE of the pcimTPCAuxClass instances referenced
+ by this attribute.
+
+ The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
+ associations, however, do have additional attributes. The
+ association PolicyActionInPolicyRule defines an integer attribute to
+ sequence the actions, and the association PolicyConditionInPolicyRule
+ has both an integer attribute to group the condition terms as well as
+ a Boolean property to specify whether a condition is to be negated.
+
+ In the PCLS, these additional association attributes are represented
+ as attributes of two classes introduced specifically to model these
+ associations. These classes are the pcimRuleConditionAssociation
+ class and the pcimRuleActionAssociation class, which are defined in
+ Sections 5.4 and 5.5, respectively. Thus, they do not appear as
+ attributes of the class pcimRule. Instead, the pcimRuleConditionList
+ and pcimRuleActionList attributes can be used to reference these
+ classes.
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 24]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definitions for the three pcimRule classes are as follows.
+
+ The abstract class pcimRule is a base class for representing the "If
+ Condition then Action" semantics associated with a policy rule. It
+ is defined as follows:
+
+ ( 1.3.6.1.1.6.1.5 NAME 'pcimRule'
+ DESC 'The base class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+ SUP pcimPolicy
+ ABSTRACT
+ MAY ( pcimRuleName $ pcimRuleEnabled $
+ pcimRuleConditionListType $ pcimRuleConditionList $
+ pcimRuleActionList $ pcimRuleValidityPeriodList $
+ pcimRuleUsage $ pcimRulePriority $
+ pcimRuleMandatory $ pcimRuleSequencedActions $
+ pcimRoles )
+ )
+
+ The PCIM [1] defines seven properties for the PolicyRule class. The
+ PCLS defines eleven attributes for the pcimRule class, which is the
+ LDAP equivalent of the PolicyRule class. Of these eleven attributes,
+ seven are mapped directly from corresponding properties in PCIM's
+ PolicyRule class. The remaining four attributes are a class-specific
+ optional naming attribute, and three attributes used to realize the
+ three associations that the pcimRule class participates in.
+
+ The pcimRuleName attribute is used as a user-friendly name of this
+ policy rule, and can also serve as the class-specific optional naming
+ attribute. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName'
+ DESC 'The user-friendly name of this policy rule.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimRuleEnabled attribute is an integer enumeration indicating
+ whether a policy rule is administratively enabled (value=1),
+ administratively disabled (value=2), or enabled for debug (value=3).
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
+ DESC 'An integer indicating whether a policy rule is
+ administratively enabled (value=1), disabled
+
+
+
+Strassner, et al. Standards Track [Page 25]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ (value=2), or enabled for debug (value=3).'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: All other values for the pcimRuleEnabled attribute are
+ considered errors, and the administrator SHOULD treat this rule as
+ being disabled if an invalid value is found.
+
+ The pcimRuleConditionListType attribute is used to indicate whether
+ the list of policy conditions associated with this policy rule is in
+ disjunctive normal form (DNF, value=1) or conjunctive normal form
+ (CNF, value=2). It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType'
+ DESC 'A value of 1 means that this policy rule is in
+ disjunctive normal form; a value of 2 means that this
+ policy rule is in conjunctive normal form.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: any value other than 1 or 2 for the pcimRuleConditionListType
+ attribute is considered an error. Administrators SHOULD treat this
+ rule as being disabled if an invalid value is found, since it is
+ unclear how to structure the condition list.
+
+ The pcimRuleConditionList attribute is a multi-valued attribute that
+ is used to realize the policyRuleInPolicyCondition association
+ defined in [1]. It contains a set of DNs of
+ pcimRuleConditionAssociation entries representing associations
+ between this policy rule and its conditions. No order is implied.
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList'
+ DESC 'Unordered set of DNs of pcimRuleConditionAssociation
+ entries representing associations between this policy
+ rule and its conditions.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 26]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimRuleActionList attribute is a multi-valued attribute that is
+ used to realize the policyRuleInPolicyAction association defined in
+ [1]. It contains a set of DNs of pcimRuleActionAssociation entries
+ representing associations between this policy rule and its actions.
+ No order is implied. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList'
+ DESC 'Unordered set of DNs of pcimRuleActionAssociation
+ entries representing associations between this policy
+ rule and its actions.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The pcimRuleValidityPeriodList attribute is a multi-valued attribute
+ that is used to realize the pcimRuleValidityPeriod association that
+ is defined in [1]. It contains a set of DNs of
+ pcimRuleValidityAssociation entries that determine when the pcimRule
+ is scheduled to be active or inactive. No order is implied. It is
+ defined as follows:
+
+ ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList'
+ DESC 'Unordered set of DNs of pcimRuleValidityAssociation
+ entries that determine when the pcimRule is scheduled
+ to be active or inactive.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The pcimRuleUsage attribute is a free-form string providing
+ guidelines on how this policy should be used. It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage'
+ DESC 'This attribute is a free-form sting providing
+ guidelines on how this policy should be used.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 27]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimRulePriority attribute is a non-negative integer that is used
+ to prioritize this pcimRule relative to other pcimRules. A larger
+ value indicates a higher priority. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority'
+ DESC 'A non-negative integer for prioritizing this
+ pcimRule relative to other pcimRules. A larger
+ value indicates a higher priority.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimRulePriority field is 0, then it SHOULD
+ be treated as "don't care". On the other hand, if the value is
+ negative, then it SHOULD be treated as an error and Administrators
+ SHOULD treat this rule as being disabled.
+
+ The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE,
+ indicates that for this policy rule, the evaluation of its conditions
+ and execution of its actions (if the condition is satisfied) is
+ required. If it is FALSE, then the evaluation of its conditions and
+ execution of its actions (if the condition is satisfied) is not
+ required. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory'
+ DESC 'If TRUE, indicates that for this policy rule, the
+ evaluation of its conditions and execution of its
+ actions (if the condition is satisfied) is required.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ The pcimRuleSequencedActions attribute is an integer enumeration that
+ is used to indicate that the ordering of actions defined by the
+ pcimActionOrder attribute is either mandatory(value=1),
+ recommended(value=2), or dontCare(value=3). It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions'
+ DESC 'An integer enumeration indicating that the ordering of
+ actions defined by the pcimActionOrder attribute is
+ mandatory(1), recommended(2), or dontCare(3).'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+
+
+
+
+Strassner, et al. Standards Track [Page 28]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of pcimRulesSequencedActions field is not one of
+ these three values, then Administrators SHOULD treat this rule as
+ being disabled.
+
+ The pcimRoles attribute represents the policyRoles property of [1].
+ Each value of this attribute represents a role-combination, which is
+ a string of the form:
+ <RoleName>[&&<RoleName>]* where the individual role names appear
+ in alphabetical order according to the collating sequence for UCS-2.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles'
+ DESC 'Each value of this attribute represents a role-
+ combination.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ Note: if the value of the pcimRoles attribute does not conform to the
+ format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then
+ this attribute is malformed and its policy rule SHOULD be treated as
+ being disabled.
+
+ The two subclasses of the pcimRule class are defined as follows.
+ First, the pcimRuleAuxClass is an auxiliary class for representing
+ the "If Condition then Action" semantics associated with a policy
+ rule. Its class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass'
+ DESC 'An auxiliary class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+ SUP pcimRule
+ AUXILIARY
+ )
+
+ The pcimRuleInstance is a structural class for representing the "If
+ Condition then Action" semantics associated with a policy rule. Its
+ class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance'
+ DESC 'A structural class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+
+
+
+Strassner, et al. Standards Track [Page 29]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimRule
+ STRUCTURAL
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleInstance to have attached to it either references to one or
+ more policy conditions (using pcimConditionAuxClass) or references to
+ one or more policy actions (using pcimActionAuxClass). This would be
+ used to formalize the semantics of the PolicyRule class [1]. Since
+ these semantics do not include specifying any properties of the
+ PolicyRule class, the content rule would not need to specify any
+ attributes.
+
+ Similarly, three separate DIT structure rules could be written, each
+ of which would refer to a specific name form that identified one of
+ its three possible naming attributes (i.e., pcimRuleName, cn, and
+ orderedCIMKeys). This structure rule SHOULD include a
+ superiorStructureRule (see Note 2 at the beginning of section 5).
+ The three name forms referenced by the three structure rules would
+ each define one of the three naming attributes.
+
+5.4. The Class pcimRuleConditionAssociation
+
+ This class contains attributes to represent the properties of the
+ PCIM's PolicyConditionInPolicyRule association. Instances of this
+ class are related to an instance of pcimRule via DIT containment.
+ The policy conditions themselves are represented by auxiliary
+ subclasses of the auxiliary class pcimConditionAuxClass. These
+ auxiliary classes are attached directly to instances of
+ pcimRuleConditionAssociation for rule-specific policy conditions.
+ For a reusable policy condition, the policyCondition auxiliary
+ subclass is attached to an instance of the class pcimPolicyInstance
+ (which is presumably associated with a pcimRepository by DIT
+ containment), and the policyConditionDN attribute (of this class) is
+ used to reference the reusable policyCondition instance.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation'
+ DESC 'This class contains attributes characterizing the
+ relationship between a policy rule and one of its
+ policy conditions.'
+ SUP pcimPolicy
+ MUST ( pcimConditionGroupNumber $ pcimConditionNegated )
+ MAY ( pcimConditionName $ pcimConditionDN )
+ )
+
+
+
+
+
+Strassner, et al. Standards Track [Page 30]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attributes of this class are defined as follows.
+
+ The pcimConditionGroupNumber attribute is a non-negative integer. It
+ is used to identify the group to which the condition referenced by
+ this association is assigned. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.16
+ NAME 'pcimConditionGroupNumber'
+ DESC 'The number of the group to which a policy condition
+ belongs. This is used to form the DNF or CNF
+ expression associated with a policy rule.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note that this number is non-negative. A negative value for this
+ attribute is invalid, and any policy rule that refers to an invalid
+ entry SHOULD be treated as being disabled.
+
+ The pcimConditionNegated attribute is a Boolean attribute that
+ indicates whether this policy condition is to be negated or not. If
+ it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT)
+ negated in the DNF or CNF expression associated with a policy rule.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.17
+ NAME 'pcimConditionNegated'
+ DESC 'If TRUE (FALSE), it indicates that a policy condition
+ IS (IS NOT) negated in the DNF or CNF expression
+ associated with a policy rule.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ The pcimConditionName is a user-friendly name for identifying this
+ policy condition, and may be used as a naming attribute if desired.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.18
+ NAME 'pcimConditionName'
+ DESC 'A user-friendly name for a policy condition.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+
+
+
+
+Strassner, et al. Standards Track [Page 31]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimConditionDN attribute is a DN that references an instance of
+ a reusable policy condition. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.19
+ NAME 'pcimConditionDN'
+ DESC 'A DN that references an instance of a reusable policy
+ condition.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleConditionAssociation to have attached to it an instance of
+ the auxiliary class pcimConditionAuxClass, or one of its subclasses.
+ This would be used to formalize the semantics of the
+ PolicyConditionInPolicyRule association. Specifically, this would be
+ used to represent a rule-specific policy condition [1].
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimConditionName, cn, and orderedCIMKeys) for the
+ pcimRuleConditionAssociation object class. Second, each name form
+ would require that an instance of the pcimRuleConditionAssociation
+ class have as its superior an instance of the pcimRule class. This
+ structure rule SHOULD also include a superiorStructureRule (see Note
+ 2 at the beginning of section 5).
+
+5.5. The Class pcimRuleValidityAssociation
+
+ The policyRuleValidityPeriod aggregation is mapped to the PCLS
+ pcimRuleValidityAssociation class. This class represents the
+ scheduled activation and deactivation of a policy rule by binding the
+ definition of times that the policy is active to the policy rule
+ itself. The "scheduled" times are either identified through an
+ attached auxiliary class pcimTPCAuxClass, or are referenced through
+ its pcimTimePeriodConditionDN attribute.
+
+ This class is defined as follows:
+
+ ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation'
+ DESC 'This defines the scheduled activation or deactivation
+ of a policy rule.'
+
+
+
+Strassner, et al. Standards Track [Page 32]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimPolicy
+ STRUCTURAL
+ MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
+ )
+
+ The attributes of this class are defined as follows:
+
+ The pcimValidityConditionName attribute is used to define a
+ user-friendly name of this condition, and may be used as a naming
+ attribute if desired. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.20
+ NAME 'pcimValidityConditionName'
+ DESC 'A user-friendly name for identifying an instance of
+ a pcimRuleValidityAssociation entry.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimTimePeriodConditionDN attribute is a DN that references a
+ reusable time period condition. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.21
+ NAME 'pcimTimePeriodConditionDN'
+ DESC 'A reference to a reusable policy time period
+ condition.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleValidityAssociation to have attached to it an instance of the
+ auxiliary class pcimTPCAuxClass, or one of its subclasses. This
+ would be used to formalize the semantics of the
+ PolicyRuleValidityPeriod aggregation [1].
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimValidityConditionName, cn, and orderedCIMKeys) for the
+ pcimRuleValidityAssociation object class. Second, each name form
+ would require that an instance of the pcimRuleValidityAssociation
+ class have as its superior an instance of the pcimRule class. This
+
+
+
+Strassner, et al. Standards Track [Page 33]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ structure rule SHOULD also include a superiorStructureRule (see Note
+ 2 at the beginning of section 5).
+
+5.6. The Class pcimRuleActionAssociation
+
+ This class contains an attribute to represent the one property of the
+ PCIM PolicyActionInPolicyRule association, ActionOrder. This
+ property is used to specify an order for executing the actions
+ associated with a policy rule. Instances of this class are related
+ to an instance of pcimRule via DIT containment. The actions
+ themselves are represented by auxiliary subclasses of the auxiliary
+ class pcimActionAuxClass.
+
+ These auxiliary classes are attached directly to instances of
+ pcimRuleActionAssociation for rule-specific policy actions. For a
+ reusable policy action, the pcimAction auxiliary subclass is attached
+ to an instance of the class pcimPolicyInstance (which is presumably
+ associated with a pcimRepository by DIT containment), and the
+ pcimActionDN attribute (of this class) is used to reference the
+ reusable pcimCondition instance.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation'
+ DESC 'This class contains attributes characterizing the
+ relationship between a policy rule and one of its
+ policy actions.'
+ SUP pcimPolicy
+ MUST ( pcimActionOrder )
+ MAY ( pcimActionName $ pcimActionDN )
+ )
+
+ The pcimActionName attribute is used to define a user-friendly name
+ of this action, and may be used as a naming attribute if desired.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.22
+ NAME 'pcimActionName'
+ DESC 'A user-friendly name for a policy action.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 34]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimActionOrder attribute is an unsigned integer that is used to
+ indicate the relative position of an action in a sequence of actions
+ that are associated with a given policy rule. When this number is
+ positive, it indicates a place in the sequence of actions to be
+ performed, with smaller values indicating earlier positions in the
+ sequence. If the value is zero, then this indicates that the order
+ is irrelevant. Note that if two or more actions have the same
+ non-zero value, they may be performed in any order as long as they
+ are each performed in the correct place in the overall sequence of
+ actions. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.23
+ NAME 'pcimActionOrder'
+ DESC 'An integer indicating the relative order of an action
+ in the context of a policy rule.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimActionOrder field is negative, then it
+ SHOULD be treated as an error and any policy rule that refers to such
+ an entry SHOULD be treated as being disabled.
+
+ The pcimActionDN attribute is a DN that references a reusable policy
+ action. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.24
+ NAME 'pcimActionDN'
+ DESC 'A DN that references a reusable policy action.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleActionAssociation to have attached to it an instance of the
+ auxiliary class pcimActionAuxClass, or one of its subclasses. This
+ would be used to formalize the semantics of the
+ PolicyActionInPolicyRule association. Specifically, this would be
+ used to represent a rule-specific policy action [1].
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimActionName, cn, and orderedCIMKeys) for the
+
+
+
+Strassner, et al. Standards Track [Page 35]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ pcimRuleActionAssociation object class. Second, each name form would
+ require that an instance of the pcimRuleActionAssociation class have
+ as its superior an instance of the pcimRule class. This structure
+ rule should also include a superiorStructureRule (see Note 2 at the
+ beginning of section 5).
+
+5.7. The Auxiliary Class pcimConditionAuxClass
+
+ The purpose of a policy condition is to determine whether or not the
+ set of actions (contained in the pcimRule that the condition applies
+ to) should be executed or not. This class defines the basic
+ organizational semantics of a policy condition, as specified in [1].
+ Subclasses of this auxiliary class can be attached to instances of
+ three other classes in the PCLS. When a subclass of this class is
+ attached to an instance of pcimRuleConditionAssociation, or to an
+ instance of pcimRule, it represents a rule-specific policy condition.
+ When a subclass of this class is attached to an instance of
+ pcimPolicyInstance, it represents a reusable policy condition.
+
+ Since all of the classes to which subclasses of this auxiliary class
+ may be attached are derived from the pcimPolicy class, the attributes
+ of pcimPolicy will already be defined for the entries to which these
+ subclasses attach. Thus, this class is derived directly from "top".
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass'
+ DESC 'A class representing a condition to be evaluated in
+ conjunction with a policy rule.'
+ SUP top
+ AUXILIARY
+ )
+
+5.8. The Auxiliary Class pcimTPCAuxClass
+
+ The PCIM defines a time period class, PolicyTimePeriodCondition, to
+ provide a means of representing the time periods during which a
+ policy rule is valid, i.e., active. It also defines an aggregation,
+ PolicyRuleValidityPeriod, so that time periods can be associated with
+ a PolicyRule. The LDAP mapping also provides two classes, one for
+ the time condition itself, and one for the aggregation.
+
+ In the PCIM, the time period class is named
+ PolicyTimePeriodCondition. However, the resulting name of the
+ auxiliary class in this mapping (pcimTimePeriodConditionAuxClass)
+ exceeds the length of a name that some directories can store.
+ Therefore, the name has been shortened to pcimTPCAuxClass.
+
+
+
+
+Strassner, et al. Standards Track [Page 36]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass'
+ DESC 'This provides the capability of enabling or disabling
+ a policy rule according to a predetermined schedule.'
+ SUP pcimConditionAuxClass
+ AUXILIARY
+ MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $
+ pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $
+ pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime )
+ )
+
+ The attributes of the pcimTPCAuxClass are defined as follows.
+
+ The pcimTPCTime attribute represents the time period that a policy
+ rule is enabled for. This attribute is defined as a string in [1]
+ with a special format which defines a time period with a starting
+ date and an ending date separated by a forward slash ("/"), as
+ follows:
+
+ yyyymmddThhmmss/yyyymmddThhmmss
+
+ where the first date and time may be replaced with the string
+ "THISANDPRIOR" or the second date and time may be replaced with the
+ string "THISANDFUTURE". This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.25
+ NAME 'pcimTPCTime'
+ DESC 'The start and end times on which a policy rule is
+ valid.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second
+ date strings may be replaced with the strings "THISANDPRIOR" and
+ "THISANDFUTURE"). If the value of this attribute does not conform to
+ this syntax, then this SHOULD be considered an error and the policy
+ rule SHOULD be treated as being disabled.
+
+ The next four attributes (pcimTPCMonthOfYearMask,
+ pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and
+ pcimTPCTimeOfDayMask) are all defined as octet strings in [1].
+ However, the semantics of each of these attributes are contained in
+
+
+
+Strassner, et al. Standards Track [Page 37]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ bit strings of various fixed lengths. Therefore, the PCLS uses a
+ syntax of Bit String to represent each of them. The definition of
+ these four attributes are as follows.
+
+ The pcimTPCMonthOfYearMask attribute defines a 12-bit mask
+ identifying the months of the year in which a policy rule is valid.
+ The format is a bit string of length 12, representing the months of
+ the year from January through December. The definition of this
+ attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.26
+ NAME 'pcimTPCMonthOfYearMask'
+ DESC 'This identifies the valid months of the year for a
+ policy rule using a 12-bit string that represents the
+ months of the year from January through December.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCMonthOfDayMask attribute defines a mask identifying the
+ days of the month on which a policy rule is valid. The format is a
+ bit string of length 62. The first 31 positions represent the days
+ of the month in ascending order, from day 1 to day 31. The next 31
+ positions represent the days of the month in descending order, from
+ the last day to the day 31 days from the end. The definition of this
+ attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.27
+ NAME 'pcimTPCDayOfMonthMask'
+ DESC 'This identifies the valid days of the month for a
+ policy rule using a 62-bit string. The first 31
+ positions represent the days of the month in ascending
+ order, and the next 31 positions represent the days of
+ the month in descending order.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 38]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCDayOfWeekMask attribute defines a mask identifying the
+ days of the week on which a policy rule is valid. The format is a
+ bit string of length 7, representing the days of the week from Sunday
+ through Saturday. The definition of this attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.28
+ NAME 'pcimTPCDayOfWeekMask'
+ DESC 'This identifies the valid days of the week for a
+ policy rule using a 7-bit string. This represents
+ the days of the week from Sunday through Saturday.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCTimeOfDayMask attribute defines the range of times at
+ which a policy rule is valid. If the second time is earlier than the
+ first, then the interval spans midnight. The format of the string is
+ Thhmmss/Thhmmss. The definition of this attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.29
+ NAME 'pcimTPCTimeOfDayMask'
+ DESC 'This identifies the valid range of times for a policy
+ using the format Thhmmss/Thhmmss.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 39]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Finally, the pcimTPCLocalOrUtcTime attribute is used to choose
+ between local or UTC time representation. This is mapped as a simple
+ integer syntax, with the value of 1 representing local time and the
+ value of 2 representing UTC time. The definition of this attribute
+ is as follows:
+
+ ( 1.3.6.1.1.6.2.30
+ NAME 'pcimTPCLocalOrUtcTime'
+ DESC 'This defines whether the times in this instance
+ represent local (value=1) times or UTC (value=2)
+ times.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then
+ this SHOULD be considered an error and the policy rule SHOULD be
+ disabled. If the attribute is not present at all, then all times are
+ interpreted as if it were present with the value 2, that is, UTC
+ time.
+
+5.9. The Auxiliary Class pcimConditionVendorAuxClass
+
+ This class provides a general extension mechanism for representing
+ policy conditions that have not been modeled with specific
+ properties. Instead, its two properties are used to define the
+ content and format of the condition, as explained below. This class
+ is intended for vendor-specific extensions that are not amenable to
+ using pcimCondition; standardized extensions SHOULD NOT use this
+ class.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass'
+ DESC 'A class that defines a registered means to describe a
+ policy condition.'
+ SUP pcimConditionAuxClass
+ AUXILIARY
+ MAY ( pcimVendorConstraintData $
+ pcimVendorConstraintEncoding )
+ )
+
+ The pcimVendorConstraintData attribute is a multi-valued attribute.
+ It provides a general mechanism for representing policy conditions
+ that have not been modeled as specific attributes. This information
+ is encoded in a set of octet strings. The format of the octet
+
+
+
+Strassner, et al. Standards Track [Page 40]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ strings is identified by the OID stored in the
+ pcimVendorConstraintEncoding attribute. This attribute is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.31
+ NAME 'pcimVendorConstraintData'
+ DESC 'Mechanism for representing constraints that have not
+ been modeled as specific attributes. Their format is
+ identified by the OID stored in the attribute
+ pcimVendorConstraintEncoding.'
+ EQUALITY octetStringMatch
+ ORDERING octetStringOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ )
+
+ The pcimVendorConstraintEncoding attribute is used to identify the
+ format and semantics for the pcimVendorConstraintData attribute.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.32
+ NAME 'pcimVendorConstraintEncoding'
+ DESC 'An OID identifying the format and semantics for the
+ pcimVendorConstraintData for this instance.'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE
+ )
+
+5.10. The Auxiliary Class pcimActionAuxClass
+
+ The purpose of a policy action is to execute one or more operations
+ that will affect network traffic and/or systems, devices, etc. in
+ order to achieve a desired policy state. This class is used to
+ represent an action to be performed as a result of a policy rule
+ whose condition clause was satisfied.
+
+ Subclasses of this auxiliary class can be attached to instances of
+ three other classes in the PCLS. When a subclass of this class is
+ attached to an instance of pcimRuleActionAssociation, or to an
+ instance of pcimRule, it represents a rule-specific policy action.
+ When a subclass of this class is attached to an instance of
+ pcimPolicyInstance, it represents a reusable policy action.
+
+ Since all of the classes to which subclasses of this auxiliary class
+ may be attached are derived from the pcimPolicy class, the attributes
+ of the pcimPolicy class will already be defined for the entries to
+ which these subclasses attach. Thus, this class is derived directly
+ from "top".
+
+
+
+Strassner, et al. Standards Track [Page 41]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass'
+ DESC 'A class representing an action to be performed as a
+ result of a policy rule.'
+ SUP top
+ AUXILIARY
+ )
+
+5.11. The Auxiliary Class pcimActionVendorAuxClass
+
+ The purpose of this class is to provide a general extension mechanism
+ for representing policy actions that have not been modeled with
+ specific properties. Instead, its two properties are used to define
+ the content and format of the action, as explained below.
+
+ As its name suggests, this class is intended for vendor-specific
+ extensions that are not amenable to using the standard pcimAction
+ class. Standardized extensions SHOULD NOT use this class.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass'
+ DESC 'A class that defines a registered means to describe a
+ policy action.'
+ SUP pcimActionAuxClass
+ AUXILIARY
+ MAY ( pcimVendorActionData $ pcimVendorActionEncoding )
+ )
+
+ The pcimVendorActionData attribute is a multi-valued attribute. It
+ provides a general mechanism for representing policy actions that
+ have not been modeled as specific attributes. This information is
+ encoded in a set of octet strings. The format of the octet strings
+ is identified by the OID stored in the pcimVendorActionEncoding
+ attribute. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.33
+ NAME 'pcimVendorActionData'
+ DESC ' Mechanism for representing policy actions that have
+ not been modeled as specific attributes. Their
+ format is identified by the OID stored in the
+ attribute pcimVendorActionEncoding.'
+ EQUALITY octetStringMatch
+ ORDERING octetStringOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ )
+
+
+
+
+Strassner, et al. Standards Track [Page 42]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimVendorActionEncoding attribute is used to identify the format
+ and semantics for the pcimVendorActionData attribute. This attribute
+ is defined as follows:
+
+ ( 1.3.6.1.1.6.2.34
+ NAME 'pcimVendorActionEncoding'
+ DESC 'An OID identifying the format and semantics for the
+ pcimVendorActionData attribute of this instance.'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE
+ )
+
+5.12. The Class pcimPolicyInstance
+
+ This class is not defined in the PCIM. Its role is to serve as a
+ structural class to which auxiliary classes representing policy
+ information are attached when the information is reusable. For
+ auxiliary classes representing policy conditions and policy actions,
+ there are alternative structural classes that may be used. See
+ Section 4.4 for a complete discussion of reusable policy conditions
+ and actions, and of the role that this class plays in how they are
+ represented.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance'
+ DESC 'A structural class to which aux classes containing
+ reusable policy information can be attached.'
+ SUP pcimPolicy
+ MAY ( pcimPolicyInstanceName )
+ )
+
+ The pcimPolicyInstanceName attribute is used to define a
+ user-friendly name of this class, and may be used as a naming
+ attribute if desired. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName'
+ DESC 'The user-friendly name of this policy instance.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 43]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ A DIT content rule could be written to enable an instance of
+ pcimPolicyInstance to have attached to it either instances of one or
+ more of the auxiliary object classes pcimConditionAuxClass and
+ pcimActionAuxClass. Since these semantics do not include specifying
+ any properties, the content rule would not need to specify any
+ attributes. Note that other content rules could be defined to enable
+ other policy-related auxiliary classes to be attached to
+ pcimPolicyInstance.
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object
+ class. Second, each name form would require that an instance of the
+ pcimPolicyInstance class have as its superior an instance of the
+ pcimRepository class. This structure rule SHOULD also include a
+ superiorStructureRule (see Note 2 at the beginning of section 5).
+
+5.13. The Auxiliary Class pcimElementAuxClass
+
+ This class introduces no additional attributes, beyond those defined
+ in the class pcimPolicy from which it is derived. Its role is to
+ "tag" an instance of a class defined outside the realm of policy
+ information as represented by PCIM as being nevertheless relevant to
+ a policy specification. This tagging can potentially take place at
+ two levels:
+
+ - Every instance to which pcimElementAuxClass is attached becomes
+ an instance of the class pcimPolicy, since pcimElementAuxClass is
+ a subclass of pcimPolicy. Searching for object
+ class="pcimPolicy" will return the instance. (As noted earlier,
+ this approach does NOT work for some directory implementations.
+ To accommodate these implementations, policy-related entries
+ SHOULD be tagged with the pcimKeyword "POLICY".)
+
+ - With the pcimKeywords attribute that it inherits from pcimPolicy,
+ an instance to which pcimElementAuxClass is attached can be
+ tagged as being relevant to a particular type or category of
+ policy information, using standard keywords,
+ administrator-defined keywords, or both.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass'
+ DESC 'An auxiliary class used to tag instances of classes
+ defined outside the realm of policy as relevant to a
+ particular policy specification.'
+
+
+
+Strassner, et al. Standards Track [Page 44]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimPolicy
+ AUXILIARY
+ )
+
+5.14. The Three Policy Repository Classes
+
+ These classes provide a container for reusable policy information,
+ such as reusable policy conditions and/or reusable policy actions.
+ This document is concerned with mapping just the properties that
+ appear in these classes. Conceptually, this may be thought of as a
+ special location in the DIT where policy information may reside.
+ Since pcimRepository is derived from the class dlm1AdminDomain
+ defined in reference [6], this specification has a normative
+ dependency on that element of reference [6] (as well as on its entire
+ derivation hierarchy, which also appears in reference [6]). To
+ maximize flexibility, the pcimRepository class is defined as
+ abstract. A subclass pcimRepositoryAuxClass provides for auxiliary
+ attachment to another entry, while a structural subclass
+ pcimRepositoryInstance is available to represent a policy repository
+ as a standalone entry.
+
+ The definition for the pcimRepository class is as follows:
+
+ ( 1.3.6.1.1.6.1.18 NAME 'pcimRepository'
+ DESC 'A container for reusable policy information.'
+ SUP dlm1AdminDomain
+ ABSTRACT
+ MAY ( pcimRepositoryName )
+ )
+
+ The pcimRepositoryName attribute is used to define a user-friendly
+ name of this class, and may be used as a naming attribute if desired.
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName'
+ DESC 'The user-friendly name of this policy repository.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 45]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The two subclasses of pcimRepository are defined as follows. First,
+ the pcimRepositoryAuxClass is an auxiliary class that can be used to
+ aggregate reusable policy information. It is defined as follows:
+
+ ( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass'
+ DESC 'An auxiliary class that can be used to aggregate
+ reusable policy information.'
+ SUP pcimRepository
+ AUXILIARY
+ )
+
+ In cases where structural classes are needed instead of an auxiliary
+ class, the pcimRepositoryInstance class is a structural class that
+ can be used to aggregate reusable policy information. It is defined
+ as follows:
+
+ ( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance'
+ DESC 'A structural class that can be used to aggregate
+ reusable policy information.'
+ SUP pcimRepository
+ STRUCTURAL
+ )
+
+ Three separate DIT structure rules could be written for this class.
+ Each of these DIT structure rules would refer to a specific name form
+ that enabled an instance of the pcimRepository class to be named
+ under any superior using one of the three possible naming attributes
+ (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure
+ rule SHOULD also include a superiorStructureRule (see Note 2 at the
+ beginning of section 5).
+
+5.15. The Auxiliary Class pcimSubtreesPtrAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of objects that are at the root of DIT subtrees
+ containing policy-related information. By attaching this attribute
+ to instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the policy information
+ relevant to it.
+
+ It is intended that these entries are placed in the DIT such that
+ well-known DNs can be used to reference a well-known structural entry
+ that has the pcimSubtreesPtrAuxClass attached to it. In effect, this
+ defines a set of entry points. Each of these entry points can
+ contain and/or reference all related policy entries for
+
+
+
+
+
+Strassner, et al. Standards Track [Page 46]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ any well-known policy domains. The pcimSubtreesPtrAuxClass functions
+ as a tag to identify portions of the DIT that contain policy
+ information.
+
+ This object does not provide the semantic linkages between individual
+ policy objects, such as those between a policy group and the policy
+ rules that belong to it. Its only role is to enable efficient bulk
+ retrieval of policy-related objects, as described in Section 4.5.
+
+ Once the objects have been retrieved, a directory client can
+ determine the semantic linkages by following references contained in
+ multi-valued attributes, such as pcimRulesAuxContainedSet.
+
+ Since policy-related objects will often be included in the DIT
+ subtree beneath an object to which this auxiliary class is attached,
+ a client SHOULD request the policy-related objects from the subtree
+ under the object with these references at the same time that it
+ requests the references themselves.
+
+ Since clients are expected to behave in this way, the policy
+ administrator SHOULD make sure that this subtree does not contain so
+ many objects unrelated to policy that an initial search done in this
+ way results in a performance problem. The pcimSubtreesPtrAuxClass
+ SHOULD NOT be attached to the partition root for a large directory
+ partition containing a relatively few number of policy-related
+ objects along with a large number of objects unrelated to policy
+ (again, "policy" here refers to the PCIM, not the X.501, definition
+ and use of "policy"). A better approach would be to introduce a
+ container object immediately below the partition root, attach
+ pcimSubtreesPtrAuxClass to this container object, and then place all
+ of the policy-related objects in that subtree.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass'
+ DESC 'An auxiliary class providing DN references to roots of
+ DIT subtrees containing policy-related objects.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimSubtreesAuxContainedSet )
+ )
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 47]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimSubtreesAuxContainedSet provides an unordered set
+ of DN references to instances of one or more objects under which
+ policy-related information is present. The objects referenced may or
+ may not themselves contain policy-related information. The attribute
+ definition is as follows:
+
+ ( 1.3.6.1.1.6.2.37
+ NAME 'pcimSubtreesAuxContainedSet'
+ DESC 'DNs of objects that serve as roots for DIT subtrees
+ containing policy-related objects.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ Note that the cn attribute does NOT need to be defined for this
+ class. This is because an auxiliary class is used as a means to
+ collect common attributes and treat them as properties of an object.
+ A good analogy is a #include file, except that since an auxiliary
+ class is a class, all the benefits of a class (e.g., inheritance) can
+ be applied to an auxiliary class.
+
+5.16. The Auxiliary Class pcimGroupContainmentAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of pcimGroups. By attaching this attribute to
+ instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the pcimGroups relevant to it.
+
+ As is the case with pcimRules, a policy administrator might have
+ several different references to a pcimGroup in the overall directory
+ structure. The pcimGroupContainmentAuxClass is the mechanism that
+ makes it possible for the policy administrator to define all these
+ different references.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass'
+ DESC 'An auxiliary class used to bind pcimGroups to an
+ appropriate container object.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimGroupsAuxContainedSet )
+ )
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 48]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimGroupsAuxContainedSet provides an unordered set of
+ references to instances of one or more pcimGroups associated with the
+ instance of a structural class to which this attribute has been
+ appended.
+
+ The attribute definition is as follows:
+
+ ( 1.3.6.1.1.6.2.38
+ NAME 'pcimGroupsAuxContainedSet'
+ DESC 'DNs of pcimGroups associated in some way with the
+ instance to which this attribute has been appended.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ Note that the cn attribute does NOT have to be defined for this class
+ for the same reasons as those given for the pcimSubtreesPtrAuxClass
+ in section 5.15.
+
+5.17. The Auxiliary Class pcimRuleContainmentAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of pcimRules. By attaching this attribute to
+ instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the pcimRules relevant to it.
+
+ A policy administrator might have several different references to a
+ pcimRule in the overall directory structure. For example, there
+ might be references to all pcimRules for traffic originating in a
+ particular subnet from a directory entry that represents that subnet.
+ At the same time, there might be references to all pcimRules related
+ to a particular DiffServ setting from an instance of a pcimGroup
+ explicitly introduced as a container for DiffServ-related pcimRules.
+ The pcimRuleContainmentAuxClass is the mechanism that makes it
+ possible for the policy administrator to define all these separate
+ references.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass'
+ DESC 'An auxiliary class used to bind pcimRules to an
+ appropriate container object.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimRulesAuxContainedSet )
+ )
+
+
+
+
+Strassner, et al. Standards Track [Page 49]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimRulesAuxContainedSet provides an unordered set of
+ references to one or more instances of pcimRules associated with the
+ instance of a structural class to which this attribute has been
+ appended. The attribute definition is as follows:
+
+ ( 1.3.6.1.1.6.2.39
+ NAME 'pcimRulesAuxContainedSet'
+ DESC 'DNs of pcimRules associated in some way with the
+ instance to which this attribute has been appended.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The cn attribute does NOT have to be defined for this class for the
+ same reasons as those given for the pcimSubtreesPtrAuxClass in
+ section 5.15.
+
+6. Extending the Classes Defined in This Document
+
+ The following subsections provide general guidance on how to create a
+ domain-specific schema derived from this document, discuss how the
+ vendor classes in the PCLS should be used, and explain how
+ policyTimePeriodConditions are related to other policy conditions.
+
+6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass
+
+ In Section 4.4, there is a discussion of how, by representing policy
+ conditions and policy actions as auxiliary classes in a schema, the
+ flexibility is retained to instantiate a particular condition or
+ action as either rule-specific or reusable. This flexibility is lost
+ if a condition or action class is defined as structural rather than
+ auxiliary. For standardized schemata, this document specifies that
+ domain-specific information MUST be expressed in auxiliary subclasses
+ of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED
+ that non-standardized schemata follow this practice as well.
+
+6.2. Using the Vendor Policy Attributes
+
+ As discussed Section 5.9, the attributes pcimVendorConstraintData and
+ pcimVendorConstraintEncoding are included in the
+ pcimConditionVendorAuxClass to provide a mechanism for representing
+ vendor-specific policy conditions that are not amenable to being
+ represented with the pcimCondition class (or its subclasses). The
+ attributes pcimVendorActionData and pcimVendorActionEncoding in the
+ pcimActionVendorAuxClass class play the same role with respect to
+ actions. This enables interoperability between different vendors who
+ could not otherwise interoperate.
+
+
+
+
+Strassner, et al. Standards Track [Page 50]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ For example, imagine a network composed of access devices from vendor
+ A, edge and core devices from vendor B, and a policy server from
+ vendor C. It is desirable for this policy server to be able to
+ configure and manage all of the devices from vendors A and B.
+ Unfortunately, these devices will in general have little in common
+ (e.g., different mechanisms, different ways for controlling those
+ mechanisms, different operating systems, different commands, and so
+ forth). The extension conditions provide a way for vendor-specific
+ commands to be encoded as octet strings, so that a single policy
+ server can commonly manage devices from different vendors.
+
+6.3. Using Time Validity Periods
+
+ Time validity periods are defined as an auxiliary subclass of
+ pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow
+ their inclusion in the AND/OR condition definitions for a pcimRule.
+ Care should be taken not to subclass pcimTPCAuxClass to add
+ domain-specific condition properties.
+
+ For example, it would be incorrect to add IPsec- or QoS-specific
+ condition properties to the pcimTPCAuxClass class, just because IPsec
+ or QoS includes time in its condition definition. The correct
+ subclassing would be to create IPsec or QoS-specific subclasses of
+ pcimConditionAuxClass and then combine instances of these
+ domain-specific condition classes with the appropriate validity
+ period criteria. This is accomplished using the AND/OR association
+ capabilities for policy conditions in pcimRules.
+
+7. Security Considerations
+
+ The PCLS, presented in this document, provides a mapping of the
+ object-oriented model for describing policy information (PCIM) into a
+ data model that forms the basic framework for describing the
+ structure of policy data, in the case where the policy repository
+ takes the form of an LDAP-accessible directory.
+
+ PCLS is not intended to represent any particular system design or
+ implementation. PCLS is not directly useable in a real world system,
+ without the discipline-specific mappings that are works in progress
+ in the Policy Framework Working Group of the IETF.
+
+ These other derivative documents, which use PCIM and its
+ discipline-specific extensions as a base, will need to convey more
+ specific security considerations (refer to RFC 3060 for more
+ information.)
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 51]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The reason that PCLS, as defined here, is not representative of any
+ real-world system, is that its object classes were designed to be
+ independent of any specific discipline, or policy domain. For
+ example, DiffServ and IPsec represent two different policy domains.
+ Each document that extends PCIM to one of these domains will derive
+ subclasses from the classes and relationships defined in PCIM, in
+ order to represent extensions of a generic model to cover specific
+ technical domains.
+
+ PCIM-derived documents will thus subclass the PCIM classes into
+ classes specific to each technical policy domain (QOS, IPsec, etc.),
+ which will, in turn, be mapped, to directory-specific schemata
+ consistent with the PCLS documented here.
+
+ Even though discipline-specific security requirements are not
+ appropriate for PCLS, specific security requirements MUST be defined
+ for each operational real-world application of PCIM. Just as there
+ will be a wide range of operational, real-world systems using PCIM,
+ there will also be a wide range of security requirements for these
+ systems. Some operational, real-world systems that are deployed
+ using PCLS may have extensive security requirements that impact
+ nearly all object classes utilized by such a system, while other
+ systems' security requirements might have very little impact.
+
+ The derivative documents, discussed above, will create the context
+ for applying operational, real-world, system-level security
+ requirements against the various models that derive from PCIM,
+ consistent with PCLS.
+
+ In some real-world scenarios, the values associated with certain
+ properties, within certain instantiated object classes, may represent
+ information associated with scarce, and/or costly (and therefore
+ valuable) resources. It may be the case that these values must not
+ be disclosed to, or manipulated by, unauthorized parties.
+
+ Since this document forms the basis for the representation of a
+ policy data model in a specific format (an LDAP-accessible
+ directory), it is herein appropriate to reference the data
+ model-specific tools and mechanisms that are available for achieving
+ the authentication and authorization implicit in a requirement that
+ restricts read and/or read- write access to these values stored in a
+ directory.
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 52]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ General LDAP security considerations apply, as documented in RFC 3377
+ [2]. LDAP-specific authentication and authorization tools and
+ mechanisms are found in the following standards track documents,
+ which are appropriate for application to the management of security
+ applied to policy data models stored in an LDAP-accessible directory:
+
+ - RFC 2829 (Authentication Methods for LDAP)
+ - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
+ for Transport Layer Security)
+
+ Any identified security requirements that are not dealt with in the
+ appropriate discipline-specific information model documents, or in
+ this document, MUST be dealt with in the derivative data model
+ documents which are specific to each discipline.
+
+8. IANA Considerations
+
+ Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol (LDAP)"
+ [16].
+
+8.1. Object Identifiers
+
+ The IANA has registered an LDAP Object Identifier for use in this
+ technical specification according to the following template:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Bob Moore (remoore@us.ibm.com)
+ Specification: RFC 3703
+ Author/Change Controller: IESG
+ Comments:
+ The assigned OID will be used as a base for identifying
+ a number of schema elements defined in this document.
+
+ IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema
+ to this registration as recorded in the following registry:
+
+ http://www.iana.org/assignments/smi-numbers
+
+8.2. Object Identifier Descriptors
+
+ The IANA has registered the LDAP Descriptors used in this technical
+ specification as detailed in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+
+
+
+Strassner, et al. Standards Track [Page 53]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Person & email address to contact for further information:
+ Bob Moore (remoore@us.ibm.com)
+ Usage: see comment
+ Specification: RFC 3703
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ -------------- ---- ------------
+ pcimPolicy O 1.3.6.1.1.6.1.1
+ pcimGroup O 1.3.6.1.1.6.1.2
+ pcimGroupAuxClass O 1.3.6.1.1.6.1.3
+ pcimGroupInstance O 1.3.6.1.1.6.1.4
+ pcimRule O 1.3.6.1.1.6.1.5
+ pcimRuleAuxClass O 1.3.6.1.1.6.1.6
+ pcimRuleInstance O 1.3.6.1.1.6.1.7
+ pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
+ pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
+ pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
+ pcimConditionAuxClass O 1.3.6.1.1.6.1.11
+ pcimTPCAuxClass O 1.3.6.1.1.6.1.12
+ pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
+ pcimActionAuxClass O 1.3.6.1.1.6.1.14
+ pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
+ pcimPolicyInstance O 1.3.6.1.1.6.1.16
+ pcimElementAuxClass O 1.3.6.1.1.6.1.17
+ pcimRepository O 1.3.6.1.1.6.1.18
+ pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
+ pcimRepositoryInstance O 1.3.6.1.1.6.1.20
+ pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
+ pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
+ pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
+ pcimKeywords A 1.3.6.1.1.6.2.3
+ pcimGroupName A 1.3.6.1.1.6.2.4
+ pcimRuleName A 1.3.6.1.1.6.2.5
+ pcimRuleEnabled A 1.3.6.1.1.6.2.6
+ pcimRuleConditionListType A 1.3.6.1.1.6.2.7
+ pcimRuleConditionList A 1.3.6.1.1.6.2.8
+ pcimRuleActionList A 1.3.6.1.1.6.2.9
+ pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
+ pcimRuleUsage A 1.3.6.1.1.6.2.11
+ pcimRulePriority A 1.3.6.1.1.6.2.12
+ pcimRuleMandatory A 1.3.6.1.1.6.2.13
+ pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
+ pcimRoles A 1.3.6.1.1.6.2.15
+ pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
+
+
+
+Strassner, et al. Standards Track [Page 54]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ pcimConditionNegated A 1.3.6.1.1.6.2.17
+ pcimConditionName A 1.3.6.1.1.6.2.18
+ pcimConditionDN A 1.3.6.1.1.6.2.19
+ pcimValidityConditionName A 1.3.6.1.1.6.2.20
+ pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
+ pcimActionName A 1.3.6.1.1.6.2.22
+ pcimActionOrder A 1.3.6.1.1.6.2.23
+ pcimActionDN A 1.3.6.1.1.6.2.24
+ pcimTPCTime A 1.3.6.1.1.6.2.25
+ pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
+ pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
+ pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
+ pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
+ pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
+ pcimVendorConstraintData A 1.3.6.1.1.6.2.31
+ pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
+ pcimVendorActionData A 1.3.6.1.1.6.2.33
+ pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
+ pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
+ pcimRepositoryName A 1.3.6.1.1.6.2.36
+ pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
+ pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
+ pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39
+
+ where Type A is Attribute, Type O is ObjectClass
+
+ These assignments are recorded in the following registry:
+
+ http://www.iana.org/assignments/ldap-parameters
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 55]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+9. Acknowledgments
+
+ We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg
+ for doing a review of this document and making many helpful
+ suggestions and corrections.
+
+ Several of the policy classes in this model first appeared in early
+ IETF drafts on IPsec policy and QoS policy. The authors of these
+ drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy
+ Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael
+ See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar.
+
+ This document is closely aligned with the work being done in the
+ Distributed Management Task Force (DMTF) Policy and Networks working
+ groups. We would especially like to thank Lee Rafalow, Glenn Waters,
+ David Black, Michael Richardson, Mark Stevens, David Jones, Hugh
+ Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 56]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+10. Appendix: Constructing the Value of orderedCIMKeys
+
+ This appendix is non-normative, and is included in this document as a
+ guide to implementers that wish to exchange information between CIM
+ schemata and LDAP schemata.
+
+ Within a CIM name space, the naming is basically flat; all instances
+ are identified by the values of their key properties, and each
+ combination of key values must be unique. A limited form of
+ hierarchical naming is available in CIM, however, by using weak
+ associations: since a weak association involves propagation of key
+ properties and their values from the superior object to the
+ subordinate one, the subordinate object can be thought of as being
+ named "under" the superior object. Once they have been propagated,
+ however, propagated key properties and their values function in
+ exactly the same way that native key properties and their values do
+ in identifying a CIM instance.
+
+ The CIM mapping document [6] introduces a special attribute,
+ orderedCIMKeys, to help map from the CIM_ManagedElement class to the
+ LDAP class dlm1ManagedElement. This attribute SHOULD only be used in
+ an environment where it is necessary to map between an
+ LDAP-accessible directory and a CIM repository. For an LDAP
+ environment, other LDAP naming attributes are defined (i.e., cn and a
+ class-specific naming attribute) that SHOULD be used instead.
+
+ The role of orderedCIMKeys is to represent the information necessary
+ to correlate an entry in an LDAP-accessible directory with an
+ instance in a CIM name space. Depending on how naming of CIM-related
+ entries is handled in an LDAP directory, the value of orderedCIMKeys
+ represents one of two things:
+
+ - If the DIT hierarchy does not mirror the "weakness hierarchy" of
+ the CIM name space, then orderedCIMKeys represents all the
+ keys of the CIM instance, both native and propagated.
+ - If the DIT hierarchy does mirror the "weakness hierarchy" of the
+ CIM name space, then orderedCIMKeys may represent either all the
+ keys of the instance, or only the native keys.
+
+ Regardless of which of these alternatives is taken, the syntax of
+ orderedCIMKeys is the same - a DirectoryString of the form
+
+ <className>.<key>=<value>[,<key>=<value>]*
+
+ where the <key>=<value> elements are ordered by the names of the key
+ properties, according to the collating sequence for US ASCII. The
+ only spaces allowed in the DirectoryString are those that fall within
+ a <value> element. As with alphabetizing the key properties, the
+
+
+
+Strassner, et al. Standards Track [Page 57]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ goal of suppressing the spaces is once again to make the results of
+ string operations predictable.
+
+ The values of the <value> elements are derived from the various CIM
+ syntaxes according to a grammar specified in [5].
+
+11. References
+
+11.1. Normative References
+
+ [1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy
+ Core Information Model -- Version 1 Specification", RFC 3060,
+ February 2001.
+
+ [2] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [4] The Directory: Models. ITU-T Recommendation X.501, 2001.
+
+ [5] Distributed Management Task Force, Inc., "Common Information
+ Model (CIM) Specification", Version 2.2, June 14, 1999. This
+ document is available on the following DMTF web page:
+ http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
+
+ [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for
+ the CIM v2.5 Core Information Model", April 15, 2002. This
+ document is available on the following DMTF web page:
+ http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
+
+ [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [8] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 2001.
+
+ [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February 2004.
+
+ [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 58]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+11.2. Informative References
+
+ [11] Hovey, R. and S. Bradner, "The Organizations Involved in the
+ IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+ [12] Strassner, J., policy architecture BOF presentation, 42nd IETF
+ Meeting, Chicago, Illinois, October 1998. Minutes of this BOF
+ are available at the following location:
+ http://www.ietf.org/proceedings/98aug/index.html.
+
+ [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for
+ Policy-based Admission Control", RFC 2753, January 2000.
+
+ [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000
+
+ [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer Security",
+ RFC 2830, May 2000.
+
+ [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 59]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+12. Authors' Addresses
+
+ John Strassner
+ Intelliden Corporation
+ 90 South Cascade Avenue
+ Colorado Springs, CO 80903
+
+ Phone: +1.719.785.0648
+ Fax: +1.719.785.0644
+ EMail: john.strassner@intelliden.com
+
+
+ Bob Moore
+ IBM Corporation
+ P. O. Box 12195, BRQA/B501/G206
+ 3039 Cornwallis Rd.
+ Research Triangle Park, NC 27709-2195
+
+ Phone: +1 919-254-4436
+ Fax: +1 919-254-6243
+ EMail: remoore@us.ibm.com
+
+
+ Ryan Moats
+ Lemur Networks, Inc.
+ 15621 Drexel Circle
+ Omaha, NE 68135
+
+ Phone: +1-402-894-9456
+ EMail: rmoats@lemurnetworks.net
+
+
+ Ed Ellesson
+ 3026 Carriage Trail
+ Hillsborough, NC 27278
+
+ Phone: +1 919-644-3977
+ EMail: ellesson@mindspring.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 60]
+\f
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 61]
+\f
projects / openldap / commitdiff