[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

                                                               P.Behera
   Internet Draft                                                V. Chu
   Expires in Six months                                       Netscape
   Intended Category: Proposed Standard                       L. Poitou
   Expires: 20 April 2000                              Sun Microsystems
                                                         J. Sermersheim
                                                                 Novell
                                                        20 October 1999
   
                   Password Policy for LDAP Directories
                <draft-behera-ldap-password-policy-00.txt>
   
   1. Status of this Memo
   
      This document is an Internet-Draft and is in full conformance
      with all provisions of Section 10 of RFC2026. 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.
   
   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
      attempts.
   
   3. Overview
   
      LDAP-based directory services currently are 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
   
   Behera, Chu, Poitou, Sermersheim     Expires 20 April 2000  [Page 1]


   Internet-Draft             Password Policy           20 October 1999
   
      authentication schemes - the most basic and widely used is the
      simple authentication i.e., user DN and password. In order to
      achieve greater security protection and ensure interoperability
      in a heterogeneous environment, LDAP needs to standardize on a
      password policy model, and it is critical to the successful
      deployment of LDAP directories.
   
      Specifically, the password policy defines:
   
      1.  The maximum length of time that a given password is valid.
      2.  The minimum length of time required between password changes.
      3.  The amount of time before a user's password is due to expire
          that the user will be sent a warning message.
      4.  Whether users can reuse passwords.
      5.  The minimum number of characters a password must contain.
      6.  Whether the password syntax is checked before a new password
          is saved.
      7.  Whether users are allowed to change their own passwords.
      8.  Whether passwords must be changed after the administrator
          resets them.
      9.  Whether users will be locked out of the directory after a
          given number of failed bind attempts.
      10. How long users will be locked out of the directory after a
          given number of failed bind attempts.
      11. The length of time before the password failure counter, which
          keeps track of the number of failed password attempts, is
          reset.
      12. The number of times users are allowed to bind with an expired
          password in order to reset their password.
      13. Whether users can change their password without specifying
          the old password
   
      The password policy defined in this document is applied to the
      userPassword attribute values only in case of the LDAP simple
      authentication method [RFC-2251], the password based SASL
      mechanisms such as CRAM-MD5 [RFC-2195] and HTTP-Digest [RFC-
      2222], add, modify, and compare operations. 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.
   
   4. New Attribute Types and Object Classes
   4.1 The pwdPolicy Object Class
   
      ( <pwdSchema>
        NAME 'pwdPolicy'
        AUXILIARY
        SUP top
        DESC 'Password Policy object class to hold password policy
             information'
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 2]


   Internet-Draft             Password Policy           20 October 1999
   
        MAY (pwdMaxAge $ pwdMinLength $ pwdInHistory $
             pwdAllowUserChange $ pwdCheckSyntax $ pwdExpireWarning $
             pwdLockout $ pwdMaxFailure $ pwdLockoutDuration $
             pwdMustChange $ pwdDefaultStorageScheme $ pwdMinAge $
             pwdFailureCountResetTime $ pwdGraceLoginLimit $
             pwdSafeModify ) )
   
   4.2 Attribute types used by the pwdPolicy Object Class
   
      ( pwdSchema.1.0
        NAME 'pwdMaxAge'
        DESC'the number of seconds after which user passwords will
            expire. A value of 0 means the password never expires.'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.1
        NAME 'pwdMinLength'
        DESC'the minimum number of characters that must be used in a
            passwordÆ
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.2
        NAME 'pwdInHistory'
        DESC'the number of passwords the directory server stores in
            history. A value of 0 means passwords can be reused'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.3
        NAME 'pwdAllowUserChange'
        DESC'a flag which indicates whether users can change their
            passwords'
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.4
        NAME 'pwdCheckSyntax'
        DESC'a flag which indicates whether the password syntax will be
            checked before the password is saved'
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 3]


   Internet-Draft             Password Policy           20 October 1999
   
        USAGE directoryOperation )
   
      ( pwdSchema.1.5
        NAME 'pwdExpireWarning'
        DESC'the maximum number of seconds before a password is due to
            expire that a warning message is to the user. A value of 0
            means no warning will be sentÆ
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.6
        NAME 'pwdLockout'
        DESC'a flag which indicates whether users will be locked out of
            the directory after a given number of consecutive failed
            bind attempts'
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdSchema.1.7
        NAME 'pwdMaxFailure'
        DESC'the number of consecutive failed bind attempts after which
            a user will be locked out of the directory'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.8
        NAME 'pwdLockoutDuration'
        DESC'the number of seconds that users will be locked out of the
            directory after an account lockout. A value of 0 means the
            account will be locked until reset'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.9
        NAME 'pwdMustChange'
        DESC'a flag which indicates whether users must change their
            passwords when they first bind to the directory server'
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.10
        NAME 'pwdDefaultStorageScheme'
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 4]


   Internet-Draft             Password Policy           20 October 1999
   
        DESC'the type of hash algorithm used to store directory server
            passwords'
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
        USAGE directoryOperation )
   
      The description of password storage scheme can be found in [RFC-
      2307]. One additional storage scheme not mentioned there is
      "CLEARTEXT".
   
      ( pwdSchema.1.11
        NAME 'pwdMinAge'
        DESC'the number of seconds that must elapse before a user can
            change their password again'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.12
        NAME 'pwdFailureCountResetTime'
        DESC'the number of seconds after which the password failure
            counter will be reset.'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.13
        NAME 'pwdGraceLoginLimit'
        DESC'the number of times an expired password can be used to
            access an account'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation )
   
      ( pwdSchema.1.14
        NAME 'pwdSafeModify'
        DESC'whether the existing password must be sent when changing a
            password'
        EQUALITY booleanMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE
        USAGE directoryOperation )
   
   4.3 The pwdInfObject Object Class
   
      The pwdInfObject object class holds the password policy state
      information for each user. For example, how many consecutive bad
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 5]


   Internet-Draft             Password Policy           20 October 1999
   
      password attempts a user made.  The information is located in
      each user entry. The description of pwdInfObject object class:
   
      ( <pwdInfoObj OID>
        NAME 'pwdInfObject'
        AUXILIARY
        SUP  top
        DESC'Password object class to hold password policy information
            in each entryÆ
        MAY ( pwdExpirationTime $ pwdExpWarned $ pwdRetryCount $
              pwdRetryCountResetTime $ pwdAccountUnlockTime $
              pwdHistory $ pwdAllowChangeTime $ pwdGraceLeft ) )
   
   4.4 Attribute types used by the pwdInfObject Object Class
   
      ( pwdInfObject.1.1
        NAME 'pwdExpirationTime'
        DESC'the time the entry's password expires. A 0 means that the
            password has expired. If this attribute does not exist, the
            password will never expire'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        EQUALITY generalizedTimeMatch
        ORDERING generalizedTimeOrderingMatch
        SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdInfObject.1.2
        NAME 'pwdExpWarned'
        DESC'a flag which indicates whether a password expiration
            warning has already been sent to the client. This prevents
            the server from sending multiple warning messages'
        EQUALITY caseIgnoreMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdInfObject.1.3
        NAME 'pwdRetryCount'
        DESC 'the count of consecutive failed login attempts'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdInfObject.1.4
        NAME 'pwdRetryCountResetTime'
        DESC 'the time to reset the pwdRetryCount'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        EQUALITY generalizedTimeMatch
        ORDERING generalizedTimeOrderingMatch SINGLE-VALUE
        USAGE directoryOperation)
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 6]


   Internet-Draft             Password Policy           20 October 1999
   
      ( pwdInfObject.1.5
        NAME 'pwdAccountUnlockTime'
        DESC'the time that the user can bind again after an account
            lockout. A 0 value means that an administrator must unlock
            the account. The absence of this attribute means that the
            account has not been locked'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        EQUALITY generalizedTimeMatch
        ORDERING generalizedTimeOrderingMatch SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdInfObject.1.6
        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)
   
      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.
   
      ( pwdInfObject.1.7
        NAME 'pwdAllowChangeTime'
        DESC'the time after which the user is allowed change the
            password. This prevents a user from quickly recycling
            passwords.'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
        EQUALITY generalizedTimeMatch
        ORDERING generalizedTimeOrderingMatch SINGLE-VALUE
        USAGE directoryOperation)
   
      ( pwdInfObject.1.8
        NAME 'pwdGraceLeft'
        DESC 'the remaining number of grace logins left'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
        SINGLE-VALUE
        USAGE directoryOperation)
   
   5. Password Expiration and Expiration Warning
   
      The attributes pwdMaxAge and pwdExpireWarning are defined to
      specify when the password expires and when a warning message will
      be sent to the client respectively. The actual expiration time
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 7]


   Internet-Draft             Password Policy           20 October 1999
   
      for a password will be stored in the pwdExpirationTime attribute
      of the user entry.
   
      After a bind operation succeeds with authentication and before
      any response is sent to the client, the server should check for a
      non-0 value in the pwdExpireWarning attribute. If warnings are to
      be issued, the server should check for password expiration time.
      If the account's password has expired, and there are no more
      remaining grace logins, the server should send a bindResponse
      with the resultCode LDAP_INVALID_CREDENTIALS along with an error
      message to inform the client that the password has expired. If
      the password is going to expire sooner than the password warning
      duration, the server should send a bindResponse with the
      resultCode: LDAP_SUCCESS, and should include the password
      expiring control in the controls field of the bindResponse
      message:
   
      controlType:  <pwdControlType.1>,
      controlValue: A BER encoding of the following ASN.1:
                           pwdExpirationTimeInSecs ::= Integer
      criticality:  false
   
      If the account's password is expired, and there are remaining
      grace logins, the server should send bindResponse with the
      resultCode: LDAP_SUCCESS, and should include the remaining grace
      logins control in the controls field of the bindResponse message:
   
      controlType:  <pwdControlType.2>,
      controlValue: A BER encoding of the following ASN.1:
                           graceLoginsLeft ::= Integer
      criticality:  false
   
   6. Password Minimum Age
   
      This policy defines the number of seconds that must pass before a
      user can change the password again.  This policy can be used in
      conjunction with the password history policy to prevent users
      from quickly cycling through passwords in history so that they
      can reuse the old password.  A value of zero indicates that the
      user can change the password immediately.
   
      During modify password operation, the server should check if the
      user is allowed to change password at this time. If not, the
      server should send the LDAP_CONSTRAINT_VIOLATION result code back
      to the client and an error message to indicate that the password
      cannot be changed before the password minimum age.
   
   7. Password History
   
      The pwdInHistory attributes control how many passwords the
      directory server stores in history. A value of zero indicates no
      history of password is maintained and in that case a user can
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 8]


   Internet-Draft             Password Policy           20 October 1999
   
      reuse the same password. During modify password operation, the
      server should check for password history.  If the new password
      matches one of the old passwords in history, the server should
      send modifyResponse back to the client with resultCode:
      LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the
      new password is in history and choose another password.
   
   8. Password Syntax and Minimum length
   
      The pwdCheckSyntax attribute indicates whether the password
      syntax will be checked before a new password is saved.  If this
      policy is on, the directory server should check that the new
      password meets the password minimum length requirement and that
      the string does not contain any trivial words such as the user's
      name, user id and so on. The mechanisms used to determine syntax
      are implementation dependent and not described in this document.
      The pwdMinLength attribute defines the minimum number of
      characters that must be used in a password. During modify or add
      password operation, the server should check for password syntax.
      If password check syntax is on and the new password fails the
      syntax check, the server should send modifyResponse or
      addResponse back to the client with resultCode:
      LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the
      new password failed the syntax check and the user should choose
      another password.
   
      If the client is sending an encrypted password as the new
      password then it becomes the client responsibility to make sure
      that the password meets the minimum length and other constraints.
   
   9. User Defined Passwords
   
      This policy defines whether the users can change their own
      passwords.
      During modify password operation, the server should check if the
      user is allowed to change password. If not, the server should
      send to the client the LDAP_UNWILLING_TO_PERFORM result code and
      an error message to indicate that the user is not allowed to
      change the password. Note that the userPassword attribute may be
      protected via ACLs also and the user must have necessary
      privilege to modify the userPassword attribute values.
   
   10. Password Change After Reset
   
      This policy forces the user to select a new password on first
      bind or after password reset. After a bind operation succeeds
      with authentication, the server should check if the password
      change after reset policy is on. If so, and this is the first
      login, the server should send bindResponse with the resultCode:
      LDAP_SUCCESS, and should include the password expired control in
      the controls field of the bindResponse message:
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000     [Page 9]


   Internet-Draft             Password Policy           20 October 1999
   
      controlType: <pwdControlType.3>,
      criticality: false
   
      After that, for any operation issued by the user other than
      modify password, bind, unbind, or abandon the server should send
      the response message with the resultCode:
      LDAP_UNWILLING_TO_PERFORM, and should include the password
      expired control in the controls field of the response message:
   
      controlType:  <pwdControlType.3>,
      criticality: false
   
   11. Password Guessing limit
   
      This policy enforces the limit of number of tries the client has
      to get the password right.  The user will be locked out of the
      directory after a given number of consecutive failed bind
      attempts to the directory.  This policy protects the directory
      from automated guessing attacks.
      The server keeps a failure counter in the pwdRetryCount attribute
      in each entry.  The server should increment the failure counter
      when a bind operation fails with the LDAP_INVALID_CREDENTIALS
      error code.  The server should clear the failure counter when a
      bind operation succeeds with authentication, the account password
      is reset by administrator, or when the failure counter reset time
      is reached.
      During the bind operation, the server should check for password
      guessing limit.  If password guessing limit policy is on and the
      password guessing limit is reached, the server should send
      bindResponse back to the client with resultCode:
      LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the
      password failure limit is reached.
   
   12. Server Implementation
   12.1 Password policy initialization
   
      The pwdPolicy object class holds the password policy settings for
      a set of user accounts. During the server initial startup,
      password policy should be assigned a set of initial values. Only
      the directory administrators should modify the settings. The
      server should preserve the settings over server restart. An
      example of a password policy is shown below.
   
      - User may change password
      - Do not need to change password first time logon
      - Use SHA as the password hash algorithm
      - No password syntax check
      - Password minimum length: 6
      - Password expires in 100 days
      - No password minimum age
      - Send warning one day before password expires
      - Six passwords in history
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 10]


   Internet-Draft             Password Policy           20 October 1999
   
      - No account lockout
      - Lock account for 60 minutes
      - Reset retry count after 10 minutes
      - Allow 1 grace login
      - Force users to pass old password when modifying password
   
      In ldif format:
         pwdChange: TRUE
         pwdMustChange: FALSE
         pwdStorageScheme: SHA
         pwdCheckSyntax: FALSE
         pwdMinLength: 6
         pwdMaxAge: 8640000
         pwdMinAge: 0
         pwdWarning: 86400
         pwdInHistory: 6
         pwdLockout: FALSE
         pwdMaxFailure: 3
         pwdLockoutDuration: 3600
         pwdResetFailureCount: 600
         pwdGraceLoginLimit: 1
         pwdSafeModify: TRUE
   
   12.2 Bind Operations
   12.2.1 During bind operations
   
      The server should check if the user account is locked or, if the
      password guessing limit policy is on and the guessing limit is
      reached. If so, the server should send bindResponse back to the
      client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error
      message to indicate the password failure limit is reached.
      Otherwise the server should continue the bind operation.
   
   12.2.2 After Bind Operation succeeds with authentication
   
      The server should
   
      1. Clear the password failure counter.
   
      2. Check if the password change after reset policy is on and this
         is the first login. If so, the server should disallow all
         operations issued by this user except modify password, bind,
         unbind, and abandon. The server should send a bindResponse
         with the resultCode: LDAP_SUCCESS, and should include the
         password expired control in the controls field of the
         bindResponse message.
   
        controlType: <pwdControlType.3>,
        criticality: false
   
      3. Check for password expiration.  If the account's password has
         expired, the server should check the remaining grace logins.
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 11]


   Internet-Draft             Password Policy           20 October 1999
   
      3.1. If there are remaining grace logins, the server should
           decrement the number of grace logins and send a bindResponse
           with the resultCode: LDAP_SUCCESS, and should include the
           remaining grace logins control in the controls field of the
           bindResponse message:
   
        controlType:  <pwdControlType.2>,
        controlValue: A BER encoding of the following ASN.1
                           graceLoginsLeft ::= Integer
        criticality:  false
   
      3.2. If there are no remaining grace logins, the server should
           send bindResponse with the resultCode
           LDAP_INVALID_CREDENTIALS long with an error message to
           inform the client that the password has expired.
   
      4. Check if the password is going to expire sooner than the
         password warning duration, the server should send bindResponse
         with the resultCode: LDAP_SUCCESS, and should include the
         password  expiring control in the controls field of the
         bindResponse message:
   
        controlType:  <pwdControlType.1>,
        controlValue: A BER encoding of the following ASN.1
                           pwdExpirationTimeInSecs ::= Integer
        criticality:  false
   
   12.2.3 After bind operations fails with LDAP_INVALID_CREDENTIALS
   
     The server should
   
      1. Check if it is time to reset the password failure counter. If
         so, set the failure counter to 1 and re-calculate the next
         failure counter reset time. Otherwise, increment the failure
         counter.
   
      2. Check if failure counter exceeds the allowed maximum value. If
         so, the server should lock the user account.
   
   12.3. Add Password Operation
   
     A password is added using the ldapModify request, either while
     creating a new entry or while modifying an existing entry that has
     no password.
   
   12.3.1. During the add password operation
   
     The server should
   
      1. Check for password syntax.  If password check syntax is on and
         the new password fails the syntax check, the server should
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 12]


   Internet-Draft             Password Policy           20 October 1999
   
         send addResponse back to the client with resultCode:
         LDAP_CONSTRAINT_VIOLATION, and an error message to indicate
         the new password failed the syntax check, the user should
         choose another password.
   
      2. Evaluate the hash of the password value. If the password is
         cleartext, check the pwdStorageScheme attribute. If the
         passwordStorageScheme is other than "CLEARTEXT", hash the
         password with the appropriate mechanism prior to storing.
   
      3. Calculate and add pwdExpirationTime and pwdAllowChangeTime
         attribute to the entry if password expiration policy
         (pwdMaxAge) and password minimum age (pwdMinAge) policies are
         on respectively.
   
   12.4.  Modify Password Operations
   
     Passwords are changed using the ldapModify operation to modify the
     value of the userPassword attribute. If the pwdSafeModify password
     policy attribute is set, the server must require that the
     ldapModify request consists of both a delete action which
     specifies the existing password, as well as an add action which
     specifies the new password.
   
   12.4.1.  During the modify password operation
   
     The server should
   
      1. Check if the user is allowed to change password. If not, the
         server should send to the client the LDAP_UNWILLING_TO_PERFORM
         result code and an error message to indicate that the user is
         not allowed to change the password.
   
      2. Check the pwdSafeModify attribute. If set, make sure that the
         modify operation contains a delete action and that the delete
         action specifies the existing password.
   
      3. Check for password minimum age, password minimum length,
         password history, and password syntax.  If the checking fails,
         the server should send modifyResponse back to the client with
         resultCode: LDAP_CONSTRAINT_VIOLATION, and an appropriate
         error message.
   
      4. Evaluate the hash of the password value. If the password is
         cleartext, check the pwdStorageScheme attribute. If the
         pwdStorageScheme is other than "CLEARTEXT", hash the password
         with the appropriate mechanism prior to storing.
   
      5. If this is the first login and if there are any modification
         being made other than userPassword, the server should send the
         response message with the resultCode:
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 13]


   Internet-Draft             Password Policy           20 October 1999
   
         LDAP_UNWILLING_TO_PERFORM, and should include the password
         expired control in the controls field of the response message
   
        controlType:  <pwdControlType.3>,
        criticality:  false
   
   12.4.2.  After the password modify operation succeeds
   
     The server should
   
      1. Update password history in the user's entry, if the
         pwdInHistory is a positive value.
   
      2. Update pwdExpirationTime in the user's entry, if the pwdMaxAge
         is a positive value.
   
      3. Update pwdAllowChangeTime in the user's entry, if the
         pwdMinAge is on.
   
      4. Reset the pwdGraceLeft attribute to the value held by the
         pwdGraceLoginLimit attribute in the pwdPolicy object in effect
         for this entry.
   
      5. Remove the pwdRetryCount and pwdRetryCountResetTime attributes
         from the user's entry if they exist.
   
   12.5 Compare Operation
   
     The compare operation may be used to compare a userPassword. This
     might be performed when a client wishes to verify that user's
     supplied password is correct. An example of this is an LDAP PAM
     redirector or an LDAP HTTP authentication redirector. It is
     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.
   
   12.5.1 During a compare operation on the userPassword attribute
   
     The server should
   
      1. Check the pwdAccountUnlockTime attribute. If it exists, return
         LDAP_UNWILLING_TO_PERFORM to indicate that the account is
         locked.
   
      2. If ACLs permit, compare the password.
   
      3. If the password compares true, the server should clear the
         failure counter. If it compares false, it should check to see
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 14]


   Internet-Draft             Password Policy           20 October 1999
   
         if it's time to reset the failure counter, if so, set the
         failure counter to 1, otherwise increment the failure counter.
         If the failure counter exceeds the allowed maximum value, the
         server MUST lock the user account.
   
   13.  Client Implementation
   13.1. Bind Response
   
     For every bind response received, the client needs to parse the
     bind result code, error message, and controls to determine if any
     of the following conditions are true and prompt the user
     accordingly.
   
      1. The user needs to change password first time logon. The user
         should be prompted to change the password immediately.
   
        resultCode:   LDAP_SUCCESS, with the control
        controlType:  <pwdControlType.3>,
        criticality:  false
   
      2. This is a warning message that the server sends to a user to
         indicate the time in seconds before the user's password
         expires.
   
        resultCode:   LDAP_SUCCESS, with the control
        controlType:  <pwdControlTYpe.1>,
        controlValue: A BER encoding of the following ASN.1
                           pwdExpirationTimeInSecs ::= Integer
        criticality:  false
   
      3. The password failure limit has been reached.  The user needs
         to retry later or contact the directory administrator to reset
         the password.
   
        resultCode:   LDAP_CONSTRAINT_VIOLATION, with an appropriate
                      error message.
        For example:  errorMessage: "exceed password retry limit"
   
      4. The password has expired but there are remaining grace logins.
         The user needs to change it.
   
        resultCode:   LDAP_SUCCESS, with the control
        controlType:  <pwdControlType.2>
        controlValue: A BER encoding of the following ASN.1
                           graceLoginsLeft ::= Integer
        criticality:  false
   
      5. The password has expired and there are no more grace logins.
         The user needs to contact the directory administrator to reset
         the password.
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 15]


   Internet-Draft             Password Policy           20 October 1999
   
        resultCode:   LDAP_INVALID_CREDENTIALS, with an appropriate
                      error message.
        For example:  errorMessage: "password expired"
   
   13.2 Modify Responses
   
      For the modify response received for the change password request,
      the client needs to check the result code and error message to
      determine if it failed the password checking, and either let the
      user retry or quit.
   
      1. The user defined password policy is disabled. Either the user
         is not allowed to change passwords, or the user must specify
         the old password when changing passwords.
   
        resultCode:   LDAP_UNWILLING_TO_PERFORM, with an appropriate
                      error message.
        For example:  errorMessage: "user not allowed to change
                      password"
   
      2. The new password failed the password syntax checking, or the
         current password has not reached the minimum password age, or
         the new password is in history.
   
        resultCode:   LDAP_CONSTRAINT_VIOLATION, with an appropriate
                      error message.
        For example:  errorMessage: "invalid password syntax"
        errorMessage: "password in history"
        errorMessage: "trivial password"
        errorMessage: "within minimum password age"
   
      3. User must supply the old password if the pwdSafeModify is on.
         The user must specify the old password when changing
         passwords.
   
        resultCode:   LDAP_UNWILLING_TO_PERFORM, with an appropriate
                      error message.
        For example:  errorMessage: "must specify old password"
   
   13.3 Add Responses
   
      For the add response received for the add entry request, the
      client needs to check the result code and error message to
      determine if it failed the password checking, and either let the
      user retry or quit.
   
      1. The new password failed the password syntax checking.
   
        resultCode:   LDAP CONSTRAINT_VIOLATION, with an appropriate
                      error message.
        For example:  errorMessage: "invalid password syntax"
        errorMessage: "trivial password"
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 16]


   Internet-Draft             Password Policy           20 October 1999
   
   13.4 Other Responses
   
      For operations other than bind, unbind, abandon, or search, the
      client needs to check the following result code and control to
      determine if the user needs to change the password immediately.
   
      1. The user needs to change password. The user should be prompted
         to change the password immediately.
   
        resultCode:   LDAP_UNWILLING_TO_PERFORM, with the control
        controlType:  <pwdControlType.3>
        criticality:  false
   
   14. Association between Users and Password Policy
   
      We have so far described two new objectclasses; one contains the
      password policy and the other contains password-related
      information in a userÆs entry. We need an association between the
      password policy and users. Association via DIT or groups or any
      other method can be used. To make this policy work in a
      heterogeneous environment we need to describe a mechanism for the
      association. This work is still under investigation.
   
   15. Password Policy and Replication
   
      The pwdPolicyObject defines the password policy for a set of
      users of the directory and must be replicated on all the
      replicas.
   
      The pwdInfObject class holds information related to password
      policy in the userÆs entry. Some of the attributes have to be
      replicated on all servers, for the consistency of passwords and
      the policy. This is the case for pwdHistory, pwdExpirationTime,
      pwdAllowChangeTime which changes along with the userPassword.
      The other attributes may change each time the user binds to a
      server. It is up to the administrator to decide to replicate them
      or not.
      If they are replicated, it means that the retry counter, the
      grace login counter and the account locking are applied on the
      whole set of servers, but that the replication updates will be
      very important and may lead to conflicts in a multi-master
      environment.
      If theyÆre not replicated, it means that the limits apply on each
      server and therefore, a user can try to bind N times on each
      server.
      As long as the number of retries and the number of server are
      low, this can be an acceptable policy.
   
   16. Security Considerations
   
   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 17]


   Internet-Draft             Password Policy           20 October 1999
   
      The password policy defined in this document is applied to the
      LDAP simple authentication method [RFC-2251] and the password
      based SASL mechanisms such as CRAM-MD5 [RFC-2195] and HTTP-Digest
      [RFC-2222].
   
   17. 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.
   
   18. Authors' Addresses
   
      Prasanta Behera
      Netscape Communications Corp.
      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, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 18]
   

Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/