--- /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
+
+
+
+
+
+
+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
projects / openldap / commitdiff