Internet Draft                                                 P.Behera
draft-behera-ldap-password-policy-01.txt                         V. Chu
Intended Category: Proposed Standard                           Netscape
Expires: September 2000                                       L. Poitou
                                                       Sun Microsystems
                                                         J. Sermersheim
                                                                 Novell
                                                             March 2000


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

   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.

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

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


Behera, et. al.           Proposed Standard                    Page 1


                 Password Policy for LDAP Directories       March 2000


2. Abstract

   Password policy is a set of rules that controls how passwords are
   used 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.

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

4.1 Application of password policy

   The password policy defined in this document can be applied to any
   attribute holding usersÆ passwords which are used for authentication
   by the use of the bind operation.
   Typically, it is 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 HTTP-Digest [RFC-Digest].
   The password policy also defines some constraints to be checked
   during add or modify operations on these attributes.
   In this document, the term "user" represents any application which
   is an LDAP client using the directory to retrieve or store
   information.

   Directory administrators are not forced to comply with any of
   password policy. In other words, the password for a directory
   administrator never expires, the account is never locked, etc.

5. Articles of password policy


Behera, et. al.           Proposed Standard                    Page 2


                 Password Policy for LDAP Directories       March 2000


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

5.1. Password Usage Policy

   This section describes policy enforced while users are using
   passwords to authenticate. The general focus of this policy is to
   minimize the threat of intruders once a password is in use.

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

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

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

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

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


Behera, et. al.           Proposed Standard                    Page 3


                 Password Policy for LDAP Directories       March 2000


   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.

5.2.2. Password History

   When the Password Expiration policy is used, an additional mechanism
   may be employed in order to prevent users from simply re-using a
   previous password (as this would effectively circumvent the
   expiration policy).

   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.

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

5.2.4. Password Syntax and Minimum length

   In order to prevent users from creating or updating passwords that
   are easy to guess, a password syntax policy may be employed. This
   policy consists of two general mechanisms - ensuring that passwords
   conform to a defined syntax and ensuring that they are of a minimum
   length.

   Forcing a password to comply with a syntax 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.


Behera, et. al.           Proposed Standard                    Page 4


                 Password Policy for LDAP Directories       March 2000


   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 'syntax checking'
      means. This can lead to unexpected behavior in a heterogeneous
      environment.

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

   This implies that certain other policy, such as password expiration
   is not enforced.

5.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 set or
   reset the password to a well-known value.

5.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 before modifying it.

6. 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 which hold general password policy state
   information for each user.

6.1. The pwdPolicy Object Class

   This object class holds password policy in effect for a set of
   users. See section 11 for a discussion of how entries of this object
   class are associated with users.

Behera, et. al.           Proposed Standard                    Page 5


                 Password Policy for LDAP Directories       March 2000



   (  pwdSchema.6.1
      NAME 'pwdPolicy'
      AUXILIARY
      SUP top
      MUST ( pwdAttribute )
      MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckSyntax $
      pwdMinLength $ pwdDefaultStorageScheme $ pwdExpireWarning $
      pwdGraceLoginLimit $ pwdLockout $ pwdLockoutDuration $
      pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $
      pwdAllowUserChange $ pwdSafeModify ) )

6.2. Attribute Types used in the pwdPolicy ObjectClass

   Following are the attribute types used by the pwdPolicy object
   class.

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

   (  pwdSchema.4.1.1
      NAME 'pwdAttribute'
      EQUALITY caseIgnoreMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

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

   (  pwdSchema.4.1.2
      NAME 'pwdMinAge'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

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

   (  pwdSchema.4.1.3
      NAME 'pwdMaxAge'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

Behera, et. al.           Proposed Standard                    Page 6


                 Password Policy for LDAP Directories       March 2000



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

   (  pwdSchema.4.1.4
      NAME 'pwdInHistory'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.5 pwdCheckSyntax

   This attribute indicates how the password syntax will be checked
   while being modified. If this attribute is not present, or if the
   value is '0', syntax checking will not be enforced. A value of '1'
   indicates that the syntax will be checked if the password is not
   hashed, otherwise it must be accepted. A value of '2' indicates that
   the syntax will be checked if the password is not hashed, otherwise
   the server must returned an error refusing the password.

   (  pwdSchema.4.1.5
      NAME 'pwdCheckSyntax'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.6 pwdMinLength

   This attribute holds the minimum number of characters that must be
   used in a password, if syntax checking is enabled. If this attribute
   is not present, no minimum password length will be enforced. If the
   password is hashed, the server will, depending on the value of the
   pwdCheckSyntax attribute, either accept the password without
   checking it ('0' or '1') or refuse it ('2').

   (  pwdSchema.4.1.6
      NAME 'pwdMinLength'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.7 pwdDefaultStorageScheme

   This attribute specifies the type of hash algorithm used to store
   directory server passwords. This is used when a password
   modification is made and the supplied password has not been


Behera, et. al.           Proposed Standard                    Page 7


                 Password Policy for LDAP Directories       March 2000


   encrypted. If this attribute is not present, or if the value is
   "CLEARTEXT", the password will not be changed before it is stored.

   The description of password storage scheme can be found in [RFC-
   2307]. One additional storage scheme not mentioned there is
   "CLEARTEXT".

   (  pwdSchema.4.1.7
      NAME 'pwdDefaultStorageScheme'
      EQUALITY caseIgnoreMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
      SINGLE-VALUE )

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

   (  pwdSchema.4.1.8
      NAME 'pwdExpireWarning'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.9 pwdGraceLoginLimit

   This attribute specifies the number of times an expired password can
   be used to access an account. If this attribute is not present or if
   the value is 0, the account cannot be accessed once the password has
   expired.

   (  pwdSchema.4.1.9
      NAME 'pwdGraceLoginLimit'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.10 pwdLockout

   This attribute indicates, when its value is "TRUE", that users will
   be locked out of the directory 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
   account will not be locked when the number of failed bind attempts
   has been reached.

   (  pwdSchema.4.1.10
      NAME 'pwdLockout'
      EQUALITY booleanMatch

Behera, et. al.           Proposed Standard                    Page 8


                 Password Policy for LDAP Directories       March 2000


      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

6.2.11 pwdLockoutDuration

   This attribute holds the number of seconds that an account will
   remain locked due to too many failed bind attempts. If this
   attribute is not present, or if the value is 0 the account will be
   locked until reset by an administrator.

   (  pwdSchema.4.1.11
      NAME 'pwdLockoutDuration'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.12 pwdMaxFailure

   This attribute specifies the number of consecutive failed bind
   attempts after which a users account will be locked. If this
   attribute is not present, or if the value is 0, the account will not
   be locked due to failed bind attempts and the value of pwdLockout
   will be ignored.

   (  pwdSchema.4.1.12
      NAME 'pwdMaxFailure'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.13 pwdFailureCountInterval

   This attribute holds the number of seconds after which the password
   failures are purged from the failure counter.

   If this attribute is not present, or if its value is 0, the failure
   counter will never be purged.

   (  pwdSchema.4.1.13
      NAME 'pwdFailureCountInterval'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

6.2.14 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.           Proposed Standard                    Page 9


                 Password Policy for LDAP Directories       March 2000


   (  pwdSchema.4.1.14
      NAME 'pwdMustChange'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

6.2.15 pwdAllowUserChange

   This attribute indicates whether users can change their own
   passwords. If this attribute is not present, a value of "TRUE" is
   assumed.

   (  pwdSchema.4.1.15
      NAME 'pwdAllowUserChange'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

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

   (  pwdSchema.4.1.16
      NAME 'pwdSafeModify'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

6.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, pwdGraceLeft, pwdReset.

   Since the password policy could apply to several attributes used to
   store passwords, each of the above operational attributes must have
   an option to tell which attribute is applies to.
   The password policy option is defined as the following:
        pwd-<passwordAttribute>

   For example, if the pwdPolicy object has for pwdAttribute
   ôuserPasswordö then the pwdChangedTime operational attribute, in a
   user entry, will be like this:
   pwdChangedTime;pwd-userPassword: 20000103121520Z

6.3.1 pwdChangedTime




Behera, et. al.           Proposed Standard                   Page 10


                 Password Policy for LDAP Directories       March 2000


   This attribute specifies the time the entry's password was last
   changed. This is used by the password expiration policy. If this
   attribute does not exist, the password will never expire.

   (  pwdSchema.4.2.1
      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)

6.3.2 pwdAccountLockedTime

   This attribute holds the time that the userÆs account was locked. A
   0 value means that the account has been locked permanently, and that
   only an administrator can unlock the account.

   (  pwdSchema.2.2
      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)

6.3.3 pwdExpirationWarned

   This attribute contains the time when the password expiration
   warning was first sent to the client. The password must expire in
   the pwdExpireWarning time.

   (  pwdSchema.2.3
      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 )

6.3.4 pwdFailureTime

   This attribute holds the time stamps of the consecutive
   authentication failures.

   (  pwdSchema.2.4
      NAME 'pwdFailureTime'
      DESC 'The timestamps of the last consecutive authentication
              failures'

Behera, et. al.           Proposed Standard                   Page 11


                 Password Policy for LDAP Directories       March 2000


      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
      EQUALITY generalizedTimeMatch
      ORDERING generalizedTimeOrderingMatch
      USAGE directoryOperation )


6.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 BNF:

   pwdHistory = time "{" hashMethod "}" data

   time = <generalizedTimeString as specified in 6.14 of [RFC2252]>
   hashMethod = <encryptionMethodString as described by the
                 pwdDefaultStorageScheme attribute in this document>
   data = <String of characters representing the password in the
           format specified in hashMethod.

   (  Schema.2.5
      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)

6.3.6 pwdGraceLeft

   This attribute holds the current number of grace logins remaining.

   (  pwdSchema.2.6
      NAME 'pwdGraceLeft'
      DESC 'The current number of grace logins remaining once
              password has expire'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE
      USAGE directoryOperation)

6.3.7 pwdReset

   This attribute holds a flag to indicate if the password has been
   reset and therefore must be changed by the user on first
   authentication.

   (  pwdSchema.2.7
      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

Behera, et. al.           Proposed Standard                   Page 12


                 Password Policy for LDAP Directories       March 2000


      USAGE directoryOperation)

7. Control used for Password Policy

   This section details the control used while enforcing password
   policy. This control contains various warnings and errors associated
   with password policy

   The server typically sends this control with the following
   operations: 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).

   passwordPolicyControl

   controlType: <pwdControlType>
   criticality: FALSE
   controlValue:an OCTET STRING, whose value is the BER encoding of the
                following type:

   PasswordPolicyControlValue ::= SEQUENCE {
      warning   [0] CHOICE OPTIONAL {
          timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
          graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
      error     [1] ENUMERATED OPTIONAL {
          passwordExpired       (0),
          accountLocked         (1),
          changeAfterReset      (2),
          passwordModNotAllowed (3),
          mustSupplyOldPassword (4),
          invalidPasswordSyntax (5),
          passwordTooShort      (6),
          passwordTooYoung      (7),
          passwordInHistory     (8) }

   The timeBeforeExpiration warning specifies the number of seconds
   before a password will expire. The graceLoginsRemaining warning
   specifies the remaining number of time 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 is set when a user is
   restricted from changing her password. The invalidPasswordSyntax
   error is set when a password doesn't pass syntax checking. The
   passwordTooYoung 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


Behera, et. al.           Proposed Standard                   Page 13


                 Password Policy for LDAP Directories       March 2000


   will expire in a short amount of time, the control may include the
   timeBeforeExpiration warning and the changeAfterReset error.


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


8.1 Bind Operation

   When processing a bind request, the server performs the following
   steps:

   1. Checks 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 sends a bindResponse to the client with the
      resultCode: unwillingToPerform (53), and includes the
      passwordPolicyControl in the controls field of the bindResponse
      message with the error: accountLocked (1).

   2. If the account is not locked, the server proceeds with the bind
      operation and checks the result:

      If the bind operation succeeds with authentication, The server
      does the following:

      A. Deletes the pwdFailureTime attribute.

      B. Checks 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 server sends a
          bindResponse to the client with the resultCode: success (0),
          and includes the passwordPolicyControl in the controls field
          of the bindResponse message with the warning:
          changeAfterReset specified.
          The server then disallows all operations issued by this user
          except modify password, bind, unbind, and abandon.

      C. Checks for password expiration
          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

Behera, et. al.           Proposed Standard                   Page 14


                 Password Policy for LDAP Directories       March 2000


          greater than the value in the pwdMaxAge attribute, the
          password has expired.

          If the value of the pwdExpireWarning attribute is non-0, and
          the pwdExpirationWarned attribute is present and has a
          positive 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.
          In the case of an expired password, the server checks for
          remaining grace logins

          -  The server checks the pwdGraceLeft attribute. A non-0
             value means there are that many remaining grace logins.

          -  If there are remaining grace logins, the server decrements
             the value in pwdGraceLeft by 1 and sends a bindResponse
             with the resultCode: success (0), and includes the
             passwordPolicyControl 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 sends a
             bindResponse with the resultCode: invalidCredentials (49),
             and includes the passwordPolicyControl in the controls
             field of the bindResponse message with the error:
             passwordExpired (0) set.

      D. Calculates whether the time before expiration warning should
         be sent. If the pwdExpirationWarned attribute is present and
         has a positive value, the warning is sent with a
         timeBeforeExpiration set to the value of the
         pwdExpirationWarned attribute plus the value of the
         pwdExpireWarning attribute minus the current time.
         Otherwise, 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 of the pwdMaxAge attribute
         minus the value of the pwdExpireWarning attribute, the server
         sets the current time as the value of the pwdExpirationWarned
         attribute, and the warning is sent with a timeBeforeExpiration
         set to the value of pwdMaxAge minus the passwordÆs age.

         The server sends a bindResponse with the resultCode: success
         (0), and includes the passwordPolicyControl in the controls
         field of the bindResponse message with the warning:
         timeBeforeExiration set to the value as described above.


      If the bind operation fails authentication due to invalid
      credentials and the pwdLockout attribute is TRUE, the server does
      the following:


Behera, et. al.           Proposed Standard                   Page 15


                 Password Policy for LDAP Directories       March 2000


      A. Adds the current time as a value of the pwdFailureTime
         attribute.

      B. Counts 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 locks the account by setting the value
         of the pwdAccountLockedTime attribute to the current time.
         After locking the account, the server sends a bindResponse to
         the client with the resultCode: unwillingToPerform (53), and
         includes the passwordPolicyControl in the controls field of
         the bindResponse message with the error: accountLocked (1).

      C. Failures times that are old by more than
         pwdFailureCountInterval, are purged from the pwdFailureTime
         attribute.


8.2. Modify Operation

   Because the password is stored in an attribute, the modify operation
   may be used to create or update a password. Other specifications MAY
   define alternate mechanisms used to modify the password.
   The following instructions are to be followed when processing any
   request which includes changes to the password attribute.

   While processing a password modification, the server performs the
   following steps:

   1. Checks the pwdSafeModify attribute. If set, the server ensures
      that the modify operation contains a delete action before the add
      or replace action, and that the delete action specifies the
      existing password. If the delete action is not specified, the
      server aborts the modification and then sends a modifyResponse to
      the client with the resultCode: unwillingToPerform (53), and
      includes the passwordPolicyControl in the controls field of the
      modifyResponse message with the error: mustSupplyOldPassword (4).

   2. Checks the value of the pwdMustChange attribute. If TRUE, the
      server checks the pwdReset attribute in the userÆs entry, to see
      if the password has been reset by a Directory Administrator. If
      so, it ensures that the modify operation contains no
      modifications other than the modification of the password
      attribute. If other modifications exist, the server sends a
      modifyResponse to the client with the resultCode:
      unwillingToPerform (53), and includes the passwordPolicyControl
      in the controls field of the modifyResponse message with the
      error: changeAfterReset (2).

   3. Checks to see whether the bound identity has sufficient rights to
      modify the password. If the bound identity is a user changing her
      own password, this may be done by either the use of an access
      control mechanism, or by checking the pwdAllowUserChange

Behera, et. al.           Proposed Standard                   Page 16


                 Password Policy for LDAP Directories       March 2000


      attribute. Otherwise an access control mechanism must be used.
      The determination of this is implementation specific. If the user
      is not allowed to change her password, the server sends a
      modifyResponse to the client with the resultCode:
      unwillingToPerform (53), and includes the passwordPolicyControl
      in the controls field of the modifyResponse message with the
      error: passwordModNotAllowed (3).

   4. Checks the value of the pwdMinAge attribute. If it is set to a
      non-0 value, the server subtracts 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 sends a modifyResponse to the client with the resultCode:
      constraintViolation (19), and includes the passwordPolicyControl
      in the controls field of the modifyResponse message with the
      error: passwordTooYoung (7).

   5. Checks the value of the pwdCheckSyntax attribute.

      If the value is non-0, The server:

      A. ensures that the password meets the syntax restrictions
          enforced by the server. This enforcement is implementation
          specific. If the password fails this check or the password is
          hashed and the value of the pwdCheckSyntax attribute is 2,
          the server sends a modifyResponse to the client with the
          resultCode: constraintViolation (19), and includes the
          passwordPolicyControl in the controls field of the
          modifyResponse message with the error: invalidPasswordSyntax
          (5).

      B. Checks the value of the pwdMinLength attribute. If the value
          is non-0, ensures that the new password is of at least the
          minimum length. If not or if the password is hashed and the
          value of the pwdCheckSyntax attribute is 2, the server sends
          a modifyResponse to the client with the resultCode:
          constraintViolation (19), and includes the
          passwordPolicyControl in the controls field of the
          modifyResponse message with the error: passwordTooShort (6).

   6. Checks the value of the pwdStorageScheme attribute. If the
      pwdStorageScheme is other than "CLEARTEXT", the server hashes the
      password with the appropriate mechanism prior to storing.

   7. Checks the value of the pwdInHistory attribute. If the value is
      non-0, 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
      modifyResponse to the client with the resultCode:
      constraintViolation (19), and includes the passwordPolicyControl


Behera, et. al.           Proposed Standard                   Page 17


                 Password Policy for LDAP Directories       March 2000


      in the controls field of the modifyResponse message with the
      error: passwordInHistory (8).

   If these steps have completed without causing an error condition,
   the server follows these steps in order to update the necessary
   password policy state attributes:

   8. Checks the value of the pwdMaxAge attribute. If the value is non-
      0, or if the value of the pwdMinAge attribute is non-0, the
      server updates the pwdChangedTime attribute on the entry to the
      current time.

   9. If the value of the pwdInHistory attribute is non-0, the server
      adds the previous password 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.

   10.Checks the value of the pwdGraceLoginLimit attribute. If the
      value is non-0, resets the pwdGraceLeft attribute to the value
      held by the pwdGraceLoginLimit attribute in the pwdPolicy object
      in effect for this entry.

   11.Removes the pwdFailureTime, pwdReset and pwdExpirationWarned
      attributes from the user's entry if they exist.

   The server then applies the modify operation.

8.3 Add Operation

   The password MAY be set during an Add operation. If it is, the
   server performs the following steps while processing the add
   operation: Note that these are essentially duplicates of steps 3, 5
   and 6 from section 8.2.

   1. Checks 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 sends an addResponse to the client with the
      resultCode: unwillingToPerform (53), and includes the
      passwordPolicyControl in the controls field of the addResponse
      message with the error: passwordModNotAllowed (3).

   2. Checks the value of the pwdCheckSyntax attribute.

      If the value is non-0:

      A. ensures that the password meets the syntax restrictions
         enforced by the server. This enforcement is implementation
         specific. If the password fails this check or the password is
         hashed and the value of the pwdCheckSyntax attribute is 2, the
         server sends a modifyResponse to the client with the
         resultCode: constraintViolation (19), and includes the

Behera, et. al.           Proposed Standard                   Page 18


                 Password Policy for LDAP Directories       March 2000


         passwordPolicyControl in the controls field of the
         modifyResponse message with the error: invalidPasswordSyntax
         (5).

      B. Checks the value of the pwdMinLength attribute. If the value
         is non-0, ensures that the new password is of at least the
         minimum length. If not or if the password is hashed and the
         value of the pwdCheckSyntax attribute is 2, the server sends a
         modifyResponse to the client with the resultCode:
         constraintViolation (19), and includes the
         passwordPolicyControl in the controls field of the
         modifyResponse message with the error: passwordTooShort (6).

   3. Checks the value of the pwdStorageScheme attribute. If the
      pwdStorageScheme is other than "CLEARTEXT", the server hashes the
      password with the appropriate mechanism prior to storing.

   If these steps have completed without causing an error condition,
   the server follows these steps in order to update the necessary
   password policy state attributes: Note that these are essentially
   duplicates of steps 8 and 10, from section 8.2.

   4. Checks the value of the pwdMaxAge attribute. If the value is non-
      0, or if the value of the pwdMinAge attribute is non-0, the
      server updates the pwdChangedTime attribute on the entry to the
      current time.

   5. Checks the value of the pwdGraceLoginLimit attribute. If the
      value is non-0, sets the pwdGraceLeft attribute to the value held
      by the pwdGraceLoginLimit attribute in the pwdPolicy object in
      effect for this entry.

8.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. ACLs may 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 performs the
   following steps:

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

Behera, et. al.           Proposed Standard                   Page 19


                 Password Policy for LDAP Directories       March 2000


      pwdLockoutDuration, the account is locked. If the account is
      locked, the server sends a compareResponse to the client with the
      resultCode: unwillingToPerform (53), and includes the
      passwordPolicyControl in the controls field of the
      compareResponse message with the error: accountLocked (1).

   2. If ACLs permit, the server proceeds with compare operation and
      checks the result.

      If the result of the compare operation is compareTrue, the server
      does the following:

      A. Deletes the pwdFailureTime attribute.

      B. Checks for password expiration
         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-0, and
         the pwdExpirationWarned attribute is present and has a
         positive 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.
         In the case of an expired password, the server checks for
         remaining grace logins

          -  The server checks the pwdGraceLeft attribute. A non-0
             value means there are that many remaining grace logins.

          -  If there are remaining grace logins, the server decrements
             the value in pwdGraceLeft by 1 and sends a bindResponse
             with the resultCode: success (0), and includes the
             passwordPolicyControl 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 sends a
             bindResponse with the resultCode: invalidCredentials (49),
             and includes the passwordPolicyControl in the controls
             field of the bindResponse message with the error:
             passwordExpired (0) set.

      C. Calculates whether the time before expiration warning should
         be sent. If the pwdExpirationWarned attribute is present and
         has a positive value, the warning is sent with a
         timeBeforeExpiration set to the value of the
         pwdExpirationWarned attribute plus the value of the
         pwdExpireWarning attribute minus the current time.

Behera, et. al.           Proposed Standard                   Page 20


                 Password Policy for LDAP Directories       March 2000


         Otherwise, 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 of the pwdMaxAge attribute
         minus the value of the pwdExpireWarning attribute, the server
         sets the current time as the value of the pwdExpirationWarned
         attribute, and the warning is sent with a timeBeforeExpiration
         set to the value of pwdMaxAge minus the passwordÆs age.

         The server sends a bindResponse with the resultCode: success
         (0), and includes the passwordPolicyControl in the controls
         field of the bindResponse message with the warning:
         timeBeforeExiration set to the value as described above.

      If the result of the compare operation is compareFalse, the
      server does the following:

      A. Adds the current time as a value of the pwdFailureTime
         attribute.

      B. Counts 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 locks the account by setting the value
         of the pwdAccountLockedTime attribute to the current time.
         After locking the account, the server sends a bindResponse to
         the client with the resultCode: unwillingToPerform (53), and
         includes the passwordPolicyControl in the controls field of
         the bindResponse message with the error: accountLocked (1).

      C. Failures times that are old by more than
         pwdFailureCountInterval, are purged from the pwdFailureTime
         attribute.


9. Client Implementation by LDAP operation

   These sections illustrate possible scenarios for each LDAP operation
   and define the types of responses that identify those scenarios.

9.1. Bind Operation

   For every bind response received, the client checks the resultCode
   of the bindResponse and checks for a passwordPolicyControl to
   determine if any of the following conditions are true and may prompt
   the user accordingly.

   1. The user is binding for the first time after the directory
      administrator set the password. In this scenario, the client may
      prompt the user to change his password immediately.

      resultCode:            success (0)
      passwordPolicyControl: error: changeAfterReset (2)


Behera, et. al.           Proposed Standard                   Page 21


                 Password Policy for LDAP Directories       March 2000


   2. The user's password will expire in n number of seconds.

      resultCode:            success (0)
      passwordPolicyControl: warning: timeBeforeExpiration [0] INTEGER

   3. 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)
      passwordPolicyControl: error: accountLocked (1)

   4. The password has expired but there are remaining grace logins.
      The user needs to change it.

      resultCode:            success (0)
      passwordPolicyControl: warning: graceLoginsRemaining [1] INTEGER

   5. The password has expired and there are no more grace logins.  The
      user needs to contact the directory administrator to reset the
      password.

      resultCode:            invalidCredentials (49)
      passwordPolicyControl: error: passwordExpired (0)

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, pwdCheckSyntax, and
   pwdDefaultStorageScheme attributes and 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 passwordPolicyControl 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)
      passwordPolicyControl: error: mustSupplyOldPassword (4)

   2. The user must change her password before submitting any other
      LDAP requests.

Behera, et. al.           Proposed Standard                   Page 22


                 Password Policy for LDAP Directories       March 2000



      resultCode:            unwillingToPerform (53)
      passwordPolicyControl: error: changeAfterReset (2)

   3. The user doesn't have sufficient rights to change his password.

      resultCode:            unwillingToPerform (53)
      passwordPolicyControl: error: passwordModNotAllowed (3)

   4. It is too soon after the last password modification to change the
      password.

      resultCode:            constraintViolation (19)
      passwordPolicyControl: error: passwordTooYoung (7)

   5. The length of the password is too short.

     resultCode:              constraintViolation (19)
     passwordPolicyControl:   error: passwordTooShort (6)

   6. The password failed syntax checking.

      resultCode:            constraintViolation (19)
      passwordPolicyControl: error: invalidPasswordSyntax (5)

   7. The password has already been used; the user must choose a
      different one.

      resultCode:            constraintViolation (19)
      passwordPolicyControl: error: passwordInHistory (8)


9.3 Add Operation

   If a password is specified in an addRequest, the client checks the
   resultCode of the addResponse and checks for a passwordPolicyControl
   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)
      passwordPolicyControl: error: passwordModNotAllowed (3)

   2. The length of the password is too short.

      resultCode:            constraintViolation (19)
      passwordPolicyControl: error: passwordTooShort (6)

   3. The password failed syntax checking.

      resultCode:            constraintViolation (19)
      passwordPolicyControl: error: invalidPasswordSyntax (5)

Behera, et. al.           Proposed Standard                   Page 23


                 Password Policy for LDAP Directories       March 2000



9.4 Other Operations

   For operations other than bind, unbind, abandon, or search, the
   client checks 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)
      passwordPolicyControl: error: changeAfterReset (2)

10. Association between Users and Password Policy

   A password policy should be defined as a subentry [SubEntry] of the
   portion of the DIT to which it applies.
   When the server need to find the password policy that applies to a
   specific user and password attribute, it will try to locate the
   nearest subentry of objectclass pwdPolicy whose pwdAttribute matches
   the desired password attribute.
   If several policies are defined in the same portion of the DIT, it
   is up to the administrators to ensure that thereÆs no conflict,
   otherwise results could be undetermined.

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

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

Behera, et. al.           Proposed Standard                   Page 24


                 Password Policy for LDAP Directories       March 2000


   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.


12. Security Considerations

   This document defines a set of rules to implement in an LDAP server,
   in order to improve the security of LDAP directories and make it
   difficult for password cracking programs to break into directories.

   Because the state information in the userÆs entry is on a per
   attribute basis and not per password attribute value, 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.


13. Bibliography

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

   [RFC-2307] L. Howard, "An Approach for Using LDAP as a Network
   Information Service", RFC 2307, March 1998.

   [RFC-2119] S. Bradner, "Key Words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [RFC-2222] J. Myers, "Simple Authentication and Security Layer
   (SASL)", RFC 2222, October 1997.

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

   [RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest
   Authentication as a SASL Mechanism", draft-leach-digest-sasl-05.txt,
   October 1999.

   [SubEntry] Ed Reed, "LDAP Subentry schema", draft-ietf-ldup-
   subentry-01.txt, August 1999.


14. Authors' Addresses

   Prasanta Behera
   Netscape Communications Corp.

Behera, et. al.           Proposed Standard                   Page 25


                 Password Policy for LDAP Directories       March 2000


   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   +1 650 937-4948
   prasanta@netscape.com

   Valerie Chu
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA
   +1 650 937-3443
   vchu@netscape.com

   Ludovic Poitou
   Sun Microsystems Inc.
   32 Chemin du vieux chŠne
   38240 Meylan
   France
   +33 476 414 212
   ludovic.poitou@france.sun.com

   Jim Sermersheim
   Novell, Inc.
   122 East 1700 South
   Provo, Utah 84606, USA
   +1 801 861-3088
   jimse@novell.com


























Behera, et. al.           Proposed Standard                   Page 26