!!! Overview
[{$pagename}] is an [Internet Draft]

We put this here as a reference as the [Internet Draft] is expired even though there is still growing [LDAP Server Implementations] that support for the implementation.[1]

There have been some slight formatting  has been added for the Wiki and to provide more understanding, but this is nearly the same as the last [{$pagename}].

%%information
Several [LDAP Server Implementations] provide at least partial support but no known comprehensive list of compliance has been determined. Use with caution.
%%


|Network Working Group|J. Sermersheim Novell, Inc
|Internet-Draft|L. Poitou, Sun Microsystems
|Intended status: Standards Track 
|Expires: February 10, 2010|H. Chu, Ed.  Symas Corp.
|August 9, 2009| 


!!! [Password Policy] for LDAP Directories
draft-behera-ldap-password-policy-10.txt

!! Status of this Memo

This [Internet Draft] is submitted to [IETF] in full conformance with the provisions of BCP 78 and BCP 79.

[Internet Drafts] are working documents of the [Internet Engineering Task Force] ([IETF]), its areas, and its working groups. Note that their groups may also distribute working documents as [Internet Drafts].

[Internet Draft] 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 Draft] can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of [Internet Draft] Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This [Internet Draft] will expire on February 10, [2010|Year 2010].

!!! Copyright Notice
Copyright (c) 2009 [IETF] Trust and the persons identified as the document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date ofpublication of this document [http://trustee.ietf.org/license-info|http://trustee.ietf.org/license-info |target='_blank'].

Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

!!! Abstract
Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based 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 to deter password guessing attacks.

!!! 1.  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|LDAP Server Implementations] support many [authentication schemes|Authentication Method] - 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.  Conventions
Imperative keywords defined in [RFC 2119] are used in this document, and carry the meanings described there.

All ASN.1 [X.680|Wikipedia:X.680] [Basic Encoding Rules] ([BER]) [X.690|Wikipedia:X.690] encodings follow the conventions found in Section 5.1 of [RFC 4511]

The term "[Password Administrator]" refers to a user that has sufficient access control privileges to modify users' passwords.  The term "[Password Policy Administrator]" refers to a user that has sufficient access control privileges to modify the pwdPolicy object defined in this document.  The [Access Control] that is used to determine whether an identity is a password administrator or password policy administrator is beyond the scope of this document, but typically implies that the password administrator has 'write' privileges to the password attribute.

!!! 3.  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|Bind Request].  In this document, the term "user" represents any [LDAP client application|DUA] that has an [identity|LDAP Entry] in the directory.

This policy is typically applied to the [userPassword] attribute in the case of the [LDAP] simple authentication method [RFC 4511] or the case of password based [SASL] [RFC 4422] authentication such as [CRAM-MD5] [RFC 2195] and [DIGEST-MD5] [RFC 2831].

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.

!!! 4.  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 Section 8 and Section 9.

!! 4.1.  [Password Usage Policy]
This section describes [policy] enforced when a [password] is used for [Authentication].  The general focus of this policy is to minimize the threat of [intruders|Intruder Detection] once a [password] is in use.

! 4.1.1.  Password Validity Policy 
These mechanisms allow account usage to be controlled independent of any [Password Expiration|Password Expired] policies.  The [policy] defines the absolute period of time for which an account may be used.  This allows an administrator to define an absolute starting time after which a password becomes valid, and an absolute ending time after which the password is disabled.

A mechanism is also provided to define the period of time for which an account may remain unused before being disabled.
! 4.1.2.  [Password Guessing Limit|Intruder Detection]
In order to [prevent intruders|Intruder Detection] from guessing a user's password, a mechanism exists to track the number of consecutive failed authentication attempts, and take action when a limit is reached.

This policy consists of several parts:
*  A counter to track the number of failed authentication attempts.
*  The amount of time to delay on the first authentication failure.
*  The maximum amount of time to delay on subsequent failures.
*  A timeframe in which the limit of consecutive failed authentication attempts must happen before action is taken.
*  A configurable limit on failed authentication attempts.
*  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.

Note that using the account lock feature provides an easy avenue for Denial-of-Service (DoS) attacks on user accounts.  While some sites' policies require accounts to be locked, this feature is discouraged in favor of delaying each failed login attempt.

The delay time will be doubled on each subsequent failure, until it reaches the maximum time configured.

TBD: we could also provide a syntax for configuring a backoff algorithm.  E.g. "+<int>" for linearly incrementing delay, "x<int>" for constant multiplier, "^<int> for geometric.  But it's probably overkill to add a calculator language to the server.

!! 4.2.  [Password Modification Policy|Password-composition Policy|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|Password Change], 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 password attribute during an add or modify operation, but MAY be done by other means such as an extended operation.

! 4.2.1.  [Password Expiration], [Expiration Warning|Password Expiration Warning], and [Grace Authentication|Password Grace Authentication]s 
Often 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.

[Password Policy 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|Password Policy] before actually being locked out of their accounts.  

One or both of the following methods handle this:
*  A warning may be returned to the user 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' authentications, her account will be locked.

! 4.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 [Password Expiration] policy).

In order to do this; a [history|Password History] of used passwords is kept.  The [Password Policy Administrator] sets the number of passwords to be stored at any given time.  [Passwords] are stored in this [Password History] whenever the password is changed.  Users aren't allowed to specify any passwords that are in the [history|Password History] list while changing passwords.

! 4.2.3.  [Password Minimum Age]
Users may circumvent the [Password History] mechanism by quickly performing a series of [password Change].  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.

! 4.2.4.  [Password Quality] and [Minimum length|Password Minimum Length]
In order to prevent users from creating or updating passwords that are easy to guess, a [password quality policy|Password Quality] may be employed.  This policy consists of two general mechanisms - ensuring that passwords conform to a defined quality criterion and ensuring that they are of a [minimum length|Password Minimum Length].

Forcing a password to comply with the [quality policy|Password Quality] may imply a variety of things including:
*  Disallowing trivial or [well-known words|Password Dictionary] make up the password.
*  Forcing a certain number of digits be used. ([Password Minimum Length])
*  Disallowing anagrams of the user's name.

The implementation of this [policy|Password Quality] meets with the following problems:
*  If the [password] to be added or updated is [encrypted] by the [client|DUA] before being sent, the server has no way of enforcing this [policy|Password Quality]. Therefore, the onus of enforcing this policy falls upon [client|DUA] implementations.
*  There are no specific definitions of what 'quality checking' means.  This can lead to unexpected behavior in a heterogeneous environment.

! 4.2.5.  User Defined Passwords
In some cases, it is desirable to disallow users from adding and updating their own passwords.  This policy makes this functionality possible.

! 4.2.6.  [Password Change after Reset|Password MUST Change]
This policy forces the user to update her password after it has been set for the first time, or has been reset by a password administrator.

This is needed in scenarios where a password administrator has set or reset the password to a well-known value.

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

{TODO: This allows a dictionary attack unless we specify that this is also subject to intruder detection.  One solution is to require users to authN prior to changing password.  Another solution is to perform intruder detection checks when the password for a non-authenticated identity is being updated}

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

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

!! 5.1.  The [pwdPolicy] Object Class
This object class contains the attributes defining a password policy in effect for a set of users.  Section 10 describes the administration of this object, and the relationship between it and particular objects.
!! 5.2.  Attribute Types used in the pwdPolicy ObjectClass
Following are the attribute types used by the pwdPolicy object class.

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

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


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

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

! 5.2.5.  [pwdCheckQuality]
TODO: Consider changing the syntax to OID.  Each OID will list a quality rule (like min len, # of special characters, etc).  These rules can be specified outside this document.

TODO: Note that even though this is meant to be a check that happens during password modification, it may also be allowed to happen during authN.  This is useful for situations where the password is encrypted when modified, but decrypted when used to authN.

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.

! 5.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').

! 5.2.7.  [pwdMaxLength]
When quality checking is enabled, this attribute holds the maximum number of characters that may be used in a password.  If this attribute is not present, no maximum 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').

! 5.2.8.  [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 returned.  If not 0, the value must be smaller than the value of the pwdMaxAge attribute.

! 5.2.9.  [pwdGraceAuthNLimit]
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.

! 5.2.10.  [pwdGraceExpiry]
This attribute specifies the number of seconds the grace authentications are valid.  If this attribute is not present or if the value is 0, there is no time limit on the grace authentications.

! 5.2.11.  [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.

! 5.2.12.  [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 a password administrator.

! 5.2.13.  [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.

! 5.2.14.  [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.

! 5.2.15.  [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 a password 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 password
administrator sets or resets the password.  This attribute is not set due to any actions specified by this document, it is typically set by a password administrator after resetting a user's password.

! 5.2.16.  [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.  This attribute is intended to be used in the absence of an access control mechanism.

! 5.2.17.  [pwdSafeModify]
This attribute specifies whether or not the existing password must be sent along with the new password when being changed.  If this attribute is not present, a "FALSE" value is assumed.

! 5.2.18.  [pwdMinDelay]
This attribute specifies the number of seconds to delay responding to the first failed authentication attempt.  If this attribute is not set or is 0, no delays will be used. pwdMaxDelay must also be specified if pwdMinDelay is set.

! 5.2.19.  [pwdMaxDelay]
This attribute specifies the maximum number of seconds to delay when responding to a failed authentication attempt.  The time specified in pwdMinDelay is used as the starting time and is then doubled on each failure until the delay time is greater than or equal to pwdMaxDelay (or a successful authentication occurs, which resets the failure counter). pwdMinDelay must be specified if pwdMaxDelay is set.

! 5.2.20.  [pwdMaxIdle]
This attribute specifies the number of seconds an account may remain unused before it becomes locked.  If this attribute is not set or is 0, no check is performed.

!! 5.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]
* [pwdFailureTime]
* [pwdHistory]
* [pwdGraceUseTime]
* [pwdReset]
* [pwdPolicySubEntry]
* [pwdStartTime]
* [pwdEndTime]
* [pwdLastSuccess]

! 5.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 it applies to.  The [Password Policy State Attribute] allows this option.

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

! 5.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 000001010000Z value means that the account has been [locked permanently|Administratively Disabled], and that only a password administrator can unlock the account.

! 5.3.4.  [pwdFailureTime]
This attribute holds the timestamps of the consecutive authentication failures.

! 5.3.5.  [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:

! 5.3.6.  [pwdGraceUseTime]
This attribute holds the timestamps of grace authentications after a password has expired.

! 5.3.7.  [pwdReset]
This attribute holds a flag to indicate (when TRUE) that the password has been updated by the password administrator and must be changed by the user.

! 5.3.8.  [PwdPolicySubEntry]
This attribute points to the pwdPolicy subentry in effect for this object.

!5.3.9.  [pwdStartTime]
This attribute specifies the time the entry's password becomes valid for authentication.  Authentication attempts made before this time will fail.  If this attribute does not exist, then no restriction applies.

! 5.3.10.  [pwdEndTime]
This attribute specifies the time the entry's password becomes invalid for authentication.  Authentication attempts made after this time will fail, regardless of expiration or grace settings.  If this attribute does not exist, then this restriction does not apply.

__Note:__ that [pwdStartTime] may be set to a time greater than or equal to [pwdEndTime]; this simply disables the password. 

! 5.3.11.  [pwdLastSuccess]
This attribute holds the timestamp of the last successful authentication.

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

{TODO: add a note about advertisement and [discovery Mechanism]}

!! 6.1.  [Password Policy Request] Control
[Password Policy Request] 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.

!! 6.2.  [Password Policy Response] Control
If the client has sent a [passwordPolicyRequest] [SupportedControl], the server (when solicited by the inclusion of the request control) sends the [Password Policy Response] Control.
!!! 7.  [Policy Decision Points]
Following are a number of procedures used to make policy decisions. These procedures are typically performed by the server while processing an 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.

! 7.1.  [Locked Account Check]
How the [Locked Account Check] is processed.

!! 7.2.  [Password Must be Changed|Password MUST Change] Now Check
A status of true is returned to indicate that the [password must be changed|Password MUST Change] if all of these conditions are met:
* The [pwdMustChange] attribute is set to TRUE.
* The [pwdReset] attribute is set to TRUE.
* otherwise a status of false is returned.

!! 7.3.  Password Expiration Check
A status of true is returned indicating that the [password has expired|Password Expired] if the current time minus the value of [pwdChangedTime] is greater than the value of the [pwdMaxAge].

Otherwise, a status of false is returned.

!! 7.4.  Remaining Grace AuthN Check
If the [pwdGraceUseTime] attribute is present, the number of values in that attribute subtracted from the value of pwdGraceAuthNLimit is returned.  Otherwise zero is returned.  

A positive result specifies the number of remaining [grace authentications|Password Grace Authentication].

!! 7.5.  Time Before Expiration Check
If the [pwdExpireWarning] attribute is not present a zero status is returned.  Otherwise the following steps are followed:

Subtract the time stored in [pwdChangedTime] from the current time to arrive at the password's age.  If the password's age is greater than than the value of the [pwdMaxAge] attribute, a zero status is returned.

Subtract the value of the pwdExpireWarning attribute from the value of the pwdMaxAge attribute to arrive at the warning age.  If the
password's age is equal to or greater than the warning age, the value of pwdMaxAge minus the password's age is returned.

! 7.6.  [Intruder Lockout Check]
A status of true indicating that an [intruder|Intruder Detection] has been detected is returned if the following conditions are met:
* The [pwdLockout] attribute is TRUE.
* The number of values in the [pwdFailureTime] attribute that are younger than [pwdFailureCountInterval] is greater or equal to the [pwdMaxFailure] attribute.
* otherwise a status of false is returned.

While performing this check, values of pwdFailureTime that are old by more than [pwdFailureCountInterval] are purged and not counted.

!! 7.7.  Intruder Delay Check
If the [pwdMinDelay] attribute is 0 or not set, zero is returned.

Otherwise, a delay time is computed based on the number of values in the [pwdFailureTime] attribute.  If the computed value is greater than the [pwdMaxDelay] attribute, the [pwdMaxDelay] value is returned.

While performing this check, values of [pwdFailureTime] that are old by more than [pwdFailureCountInterval] are purged and not counted.

!! 7.8.  Password Too Young Check
If the Section 7.2 check returned true then this check will return false, to allow the password to be changed.

A status of true indicating that not enough time has passed since the password was last updated is returned if:
* The value of [pwdMinAge] is non-zero and [pwdChangedTime] is present.
* The value of [pwdMinAge] is greater than the current time minus the value of [pwdChangedTime].
* Otherwise a false status is returned.

!!! 8.  Server [Policy Enforcement Points]
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.

Note: The case where a single [password] value is stored in multiple formats simultaneously is still considered to be only one password value.

The scenarios in the following operations assume that the client has attached a [passwordPolicyRequest] control to the request message of the operation.  In the event that the [passwordPolicyRequest] control was not sent, no [passwordPolicyResponse] control is returned.  All other instructions remain the same.

For successfully completed operations, unless otherwise stated, no [passwordPolicyResponse] control is returned.

!! 8.1.  Password-based [Authentication]
This section contains the policy enforcement rules and policy data updates used while validating a password.  Operations that validate passwords include, but are not limited to, the [Bind|Bind Request] operation where the simple choice specifies a password, and the [Compare operation|Compare Request] where the attribute being compared holds a [password].  

Note that while the Compare operation does not authenticate a user to the LDAP server, it may be used by an external application for purposes of authentication.

! 8.1.1.  Fail if the account is locked
If the account is locked as specified in Section 7.1, the server fails the operation with an appropriate [resultCode|LDAP Result Codes] (i.e. [invalidCredentials] (49) in the case of a bind operation, [compareFalse|LDAP_COMPARE_FALSE] (5) in the case of a compare operation, etc.).  The server MAY set the error: [accountLocked] (1) in the [passwordPolicyResponse] in the controls field of the message.

! 8.1.2.  Validated Password Procedures
If the validation operation indicates that the password validated, these procedures are followed in order:

__8.1.2.1.  Policy state updates__
Delete the [pwdFailureTime] and [pwdAccountLockedTime] attributes.

Set the value of the [pwdLastSuccess] attribute to the current time.

Note: setting [pwdLastSuccess] is optional, but it is required if the policy has [pwdMaxIdle] defined.

__8.1.2.2.  Password must be changed now__
If the decision in Section 7.2 returns true, the server sends to the client a response with an appropriate successful resultCode (i.e. success (0), [compareTrue|LDAP_COMPARE_TRUE] (6), etc.), and includes the [passwordPolicyResponse] in the controls field of the [bindResponse|Bind Response] message with the warning: changeAfterReset specified.

For bind, the server MUST then disallow all operations issued by this user except modify password, bind, unbind, abandon and StartTLS extended operation.

__8.1.2.3.  Expired password__
If the password has expired as per Section 7.3, the server either returns a success or failure based on the state of grace authentications.

__8.1.2.3.1.  Remaining Grace Authentications__
If there are remaining grace authentications as per Section 7.4, the server adds a new value with the current time in [pwdGraceUseTime]. 

Then it sends to the client a response with an appropriate successful resultCode (i.e. success (0), compareTrue (6), etc.), and includes the [passwordPolicyResponse] in the controls field of the response message with the warning: [graceAuthNsRemaining] choice set to the number of grace authentications left.

Implementor's note: The system time of the host machine may be more granular than is needed to ensure unique values of this attribute.

It is recommended that a mechanism is used to ensure unique generalized time values.  The fractional seconds field may be used for this purpose.

__8.1.2.3.2.  No Remaining Grace Authentications__
If there are no remaining grace authentications, the server fails the operation with an appropriate resultCode (invalidCredentials (49), compareFalse (5), etc.), and includes the passwordPolicyResponse in the controls field of the bindResponse message with the error:
passwordExpired (0) set.

__8.1.2.4.  Expiration Warning__
If the result of Section 7.5 is a positive number, the server sends to the client a response with an appropriate successful resultCode (i.e. success (0), compareTrue (6), etc.), and includes the passwordPolicyResponse in the controls field of the bindResponse message with the warning: timeBeforeExiration set to the value as described above.  Otherwise, the server sends a successful response, and omits the passwordPolicyResponse.

! 8.1.3.  AuthN Failed Procedures
If the authentication process indicates that the password failed validation due to invalid credentials, these procedures are followed:

__8.1.3.1.  Policy state update__\\
Add the current time as a value of the [pwdFailureTime] attribute.

Implementation's note: The system time of the host machine may be more granular than is needed to ensure unique values of this attribute. It is recommended that a mechanism is used to ensure unique generalized time values.  The fractional seconds field may be used for this purpose.

__8.1.3.2.  Handle [Intruder Detection]__\\
If the check in Section 7.6 returns a true state, the server locks the account by setting the value of the [pwdAccountLockedTime] attribute to the current time.  
After locking the account, the server fails the operation with an appropriate [LDAP Result Code]([LDAP_INVALID_CREDENTIALS] (49), [LDAP_COMPARE_FALSE] (5), etc.), and includes the [passwordPolicyResponse] in the controls field of the message with the error: accountLocked (1).

If the check in Section 7.7 returns a non-zero value, the server waits that number of seconds before sending the authentication response back to the client.

!! 8.2.  Password Update Operations
Because the password is stored in an attribute, various operations (like add and modify) 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 update, the server performs the following steps:

! 8.2.1.  Safe Modification
If [pwdSafeModify] is set to TRUE and if there is an existing password value, the server ensures that the password update operation includes 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 specifies the existing password, and the add or replace action specifies the new password.  Other password update operations SHOULD employ a similar mechanism.  Otherwise this policy
will fail.

If the existing password is not specified, the server does not process the operation and sends the appropriate response message to the client with the resultCode: [LDAP_INSUFFICIENT_ACCESS] (50), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: [mustSupplyOldPassword] (4).

! 8.2.2.  Change After Reset
If the decision in Section 7.2 returns true, the server ensures that the password update operation contains no modifications other than the modification of the password attribute.  

If other modifications exist, the server sends a response message to the client with the resultCode: [LDAP_INSUFFICIENT_ACCESS](50), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: changeAfterReset (2).

! 8.2.3.  Rights Check
Check to see whether the bound identity has sufficient rights to update 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 update her password, the server sends a response message to the client with the resultCode: insufficientAccessRights (50), and includes the passwordPolicyResponse in the controls field of the
response message with the error: passwordModNotAllowed (3).

! 8.2.4.  Too Early to Update
If the check in Section 7.8 results in a true status The server sends a response message to the client with the resultCode: constraintViolation (19), and includes the passwordPolicyResponse in the controls field of the response message with the error: passwordTooYoung (7).

! 8.2.5.  Password Quality
Check the value of the pwdCheckQuality attribute.  If the value is non-zero, the server:

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

If the value is 2, the server sends a response message to the client with the resultCode: [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), and includes 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 sends a response message to the client with the resultCode:
constraintViolation (19), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: [insufficientPasswordQuality] (5).

Checks the value of the [pwdMinLength] attribute.  If the value is non-zero, it ensures 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 continues.  

If the value is 2, the server sends a response message to the client with the resultCode: constraintViolation (19), and includes 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 sends a response message to the client with the resultCode:
[constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: [passwordTooShort] (6).

! 8.2.6.  Invalid Reuse
If [pwdInHistory] is present and its value is non-zero, the server checks 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 sends a response message to the client with the resultCode: [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: [passwordInHistory] (8).

! 8.2.7.  Policy State Updates
If the steps have completed without causing an error condition, the server performs the following steps in order to update the necessary password policy state attributes:
* If the value of either [pwdMaxAge] or [pwdMinAge] is non-zero, the server updates the [pwdChangedTime] attribute on the entry to the current time.
* If the value of [pwdInHistory] is non-zero, the server adds the previous password (if one existed) to the [pwdHistory] attribute.  
* If the number of attributes held in the [pwdHistory] attribute exceeds the value of [pwdInHistory], the server removes the oldest excess passwords.
* If the value the [pwdMustChange] is TRUE and the modification is performed by a password administrator, then the [pwdReset] attribute is set to TRUE.  Otherwise, the [pwdReset] is removed from the user's entry if it exists.

The [pwdFailureTime] and [pwdGraceUseTime] attributes is removed from the user's entry if they exist.

!! 8.3.  Other Operations
For operations other than bind, password update, unbind, abandon or StartTLS, if the decision in Section 7.2 returns true, the server sends a response message to the client with the resultCode:
[insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), and includes the [passwordPolicyResponse] in the controls field of the response message with the error: [changeAfterReset] (2).


!!! 9.  Client [Policy Enforcement Points]
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 passwordPolicyResponse control is returned. All other instructions remain the same.

!! 9.1.  [Bind Operation|Bind Response]
For every [Bind Response] received, the client checks the resultCode of the [Bind Response]  and checks for a [passwordPolicyResponse] control to determine if any of the following conditions are true and MAY prompt the user accordingly.
* [bindResponse|Bind Response].resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), [passwordPolicyResponse].error = [accountLocked] (1): The password failure limit has been reached and the account is locked.  The user needs to retry later or contact the password administrator to reset the password.
* [bindResponse|Bind Response].resultCode = [success|LDAP_SUCCESS] (0), [passwordPolicyResponse].error = [changeAfterReset] (2): The user is binding for the first time after the password administrator set the password.  In this scenario, the client SHOULD prompt the user to change his password immediately.
* [bindResponse|Bind Response].resultCode = [success|LDAP_SUCCESS] (0), [passwordPolicyResponse].warning = [graceAuthNsRemaining]: The password has expired but there are remaining grace authentications.  The user needs to change it.
*  [bindResponse|Bind Response].resultCode = [invalidCredentials|LDAP_INVALID_CREDENTIALS] (49), passwordPolicyResponse.error = [passwordExpired] (0): The password has expired and there are no more grace authentications.  The user contacts the password administrator in order to have its password reset.
* [bindResponse|Bind Response].resultCode = [success|LDAP_SUCCESS] (0), [passwordPolicyResponse].warning = [timeBeforeExpiration]: The user's password will expire in n number of seconds.


!! 9.2.  Modify Operations

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

! 9.2.2.  Modify Response
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 checks the resultCode of the response and checks for a passwordPolicyResponse control to determine if any of the following conditions are true and optionally notify the user of the condition.

* pwdModResponse.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = mustSupplyOldPassword (4): The user attempted to change her password without specifying the old password but the password policy requires this.
* pwdModResponse.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = [changeAfterReset] (2): The user must change her password before submitting any other LDAP requests.
* pwdModResponse.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = [passwordModNotAllowed] (3): The user doesn't have sufficient rights to change his password.
* pwdModResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [passwordTooYoung] (7): It is too soon after the last password modification to change the password.
* pwdModResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [insufficientPasswordQuality] (5): The password failed quality checking.
* pwdModResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [passwordTooShort] (6): The length of the password is too short.
* pwdModResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [passwordInHistory] (8): The password has already been used; the user must choose a different one.

! 9.3.  Add Operation
If a password is specified in an addRequest, the client checks the resultCode of the addResponse and checks for a passwordPolicyResponse control to determine if any of the following conditions are true and may prompt the user accordingly.

* addResponse.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = [passwordModNotAllowed] (3): The user doesn't have sufficient rights to add this password.
* addResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [insufficientPasswordQuality] (5): The password failed quality checking.
* addResponse.resultCode = [constraintViolation|LDAP_CONSTRAINT_VIOLATION] (19), passwordPolicyResponse.error = [passwordTooShort] (6): The length of the password is too short.

! 9.4.  Compare Operation
When a compare operation is used to compare a password, the client checks the resultCode of the [compare Response] and checks 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.

* compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = [accountLocked] (1): The password failure limit has been reached and the account is locked.  The user needs to retry later or contact the password administrator to reset the password.
* compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = [graceAuthNsRemaining]: The password has expired but there are remaining grace authentications.  The user needs to change it.
* compareResponse.resultCode = compareFalse (5), passwordPolicyResponse.error = [passwordExpired] (0): The password has expired and there are no more grace authentications.  The user must contact the password administrator to reset the password.
* compareResponse.resultCode = compareTrue (6), passwordPolicyResponse.warning = [timeBeforeExpiration]: The user's password will expire in n number of seconds.

!9.5.  Other Operations
For operations other than bind, unbind, abandon or StartTLS, the client checks the result code and control to determine if any other actions are needed.

* <Response>.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = [accountLocked] (1) : The password failure limit has been reached and the account is locked. The user needs to retry later or contact the password administrator to reset the password.
* <Response>.resultCode = [insufficientAccessRights|LDAP_INSUFFICIENT_ACCESS] (50), passwordPolicyResponse.error = [changeAfterReset] (2) : The user needs to change the password immediately.

!!! 10.  Administration of the Password Policy
{TODO: Need to define an administrativeRole (need [OID]).  Need to describe whether [pwdPolicy] admin areas can overlap}

A password policy is 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].

It is possible to define [password policies|Password Policy] for different password attributes within the same [pwdPolicy] entry, by specifying multiple values of the [pwdAttribute].  But [password policies|Password Policy] could also be in separate sub entries as long as they are contained under the same LDAP subentry.

Only one [policy|Password Policy] may be in effect for a given password attribute in any [entry|LDAP Entry].  If multiple [policies|Password Policy] exist which overlap in the range of entries affected, the resulting behavior is undefined.

Modifying the password policy __MUST NOT__ result in any change in users' entries to which the [policy|Password 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|LDAP Entry].

Each object that is controlled by [Password Policy] advertises 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 may interrogate the [pwdPolicySubEntry] for that object in order to arrive at the proper [pwdPolicySubEntry].

!!! 11.  Password Policy and Replication
TODO: This section needs to be changed to highlight the pitfalls of replication, suggest some implementation choices to overcome those pitfalls, but remove prescriptive language relating to the update of state information

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], [pwdFailureTime] and [pwdGraceUseTime] attributes __SHOULD__ 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 authentications 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.

Note: there are some situations where global replication of these state attributes may not be desired.  For example, if two clusters of replicas are geographically remote and joined by a slow network link, and their users only login from one of the two locations, it may be unnecessary to propagate all of the state changes from one cluster to the other.  Servers SHOULD allow administrators to control which attributes are replicated on a case-by-case basis.

Servers participating in a loosely consistent multi-master replication agreement SHOULD employ a mechanism which ensures uniqueness of values when populating the attributes pwdFailureTime and pwdGraceUseTime.  The method of achieving this is a local matter and may consist of using a single authoritative source for the generation of unique time values, or may consist of the use of the fractional seconds part to hold a replica identifier.

!!! 12.  [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 4513].

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.  The attributes defined to maintain the [Password Policy] state information [SHOULD] only be modifiable by the [Password Administrator] or higher authority.  The [pwdHistory] attribute [MUST] be subject to the same level of [Access Control] as the attribute holding the [password].

As it is possible to define a [Password Policy] for one specific user by adding a [LDAP 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] subentry object class.

When the [Intruder Detection] password policy is enforced, the [LDAP directory|DSA] 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|Attacker].  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|DSA] is also a way to restrict this kind of attack.  Using the [login delay|Server-Side Login throttling schemes] instead of the lockout mechanism will also help avoid this [Denial-of-Service].

Returning certain status codes (such as [passwordPolicyResponse].error = accountLocked) allows a denial of service attacker to know that it has successfully denied service to an account.  [Servers|DSA] [SHOULD] implement additional checks which return the same status when it is sensed that some number of failed [authentication] requests has occurred on a single connection, or from a client address.  Server implementors are encouraged to invent other checks similar to this in order to thwart this type of [DoS] attack.

!!! 14.  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).  Prasanta Behera
participated in early revisions of this document.


15.  Normative References
{{{
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2195]  Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
  AUTHorize Extension for Simple Challenge/Response",
  RFC 2195, September 1997.

[RFC2831]  Leach, P. and C. Newman, "Using Digest Authentication as a
  SASL Mechanism", RFC 2831, May 2000.

[RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
  RFC 3062, February 2001.

[RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
  Considerations for the Lightweight Directory Access
  Protocol (LDAP)", RFC 3383, September 2002.

[RFC3672]  Zeilenga, K., "Subentries in the Lightweight Directory
  Access Protocol (LDAP)", RFC 3672, December 2003.

[RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
  Security Layer (SASL)", RFC 4422, June 2006.

[RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
  (LDAP): The Protocol", RFC 4511, June 2006.

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

[RFC4513]  Harrison, R., "Lightweight Directory Access Protocol
  (LDAP): Authentication Methods and Security Mechanisms",
  RFC 4513, June 2006.

[RFC4517]  Legg, S., "Lightweight Directory Access Protocol (LDAP):
  Syntaxes and Matching Rules", RFC 4517, June 2006.

[X.680] International Telecommunications Union, "Abstract Syntax
  Notation One (ASN.1): Specification of basic notation",
  ITU-T Recommendation X.680, July 2002.

[X.690] International Telecommunications Union, "Information
  Technology - ASN.1 encoding rules: Specification of Basic
  Encoding Rules (BER),  Canonical Encoding Rules (CER) and
  Distinguished Encoding Rules (DER)", ITU-T
  Recommendation X.690, July 2002.
}}}

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [http://tools.ietf.org/id/draft-behera-ldap-password-policy-10.txt|http://tools.ietf.org/id/draft-behera-ldap-password-policy-10.txt|target='_blank'] - based on 2013-04-10