Subject: please publish ldap password policy draft

From: [email-masked] (Prasanta Behera)
Date: Tue, 19 Oct 1999 14:16:26 -0700

Editor,
Please publish this new internet draft.

LDAPEXT chairs: Tim & Mark

We are asking for  10-15 min in the next meeting
to talk about the "password policy" model before the group.

Thanks,
/prasanta

                                                               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
      [email-masked]

      Valerie Chu
      Netscape Communications Corp.
      501 E. Middlefield Rd.
      Mountain View, CA 94043
      USA
      +1 650 937-3443
      [email-masked]

      Ludovic Poitou
      Sun Microsystems Inc.
      32 Chemin du vieux chêne
      38240 Meylan
      France
      +33 476 414 212
      [email-masked]

      Jim Sermersheim
      Novell, Inc.
      122 East 1700 South
      Provo, Utah 84606, USA
      +1 801 861-3088
      [email-masked]

   Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 18]

---

From: Helmut Volpers <[email-masked]>
Date: Thu, 21 Oct 1999 11:40:39 +0200

Hi,

Some comments and questions.

Prasanta Behera schrieb:
>   ------------------------------------------------------------------------
> 
>                                                                P.Behera
>    Internet Draft                                                V. Chu

Why is it needed in the password policy ? It's an item of AccessControl.

>         USAGE directoryOperation )

Again I think this is Access Control.
>       a set of user accounts.
 
How is the set of user-accounts specified ? over a Subtree specification
or
a filter ? Is it not a case where subentries (operational objects) make
sense?
Subentries because you don't want to see this entries when you browse
through the DIT.

During the server initial startup,

>      order to reduce possible overhead involved in performing a bind.

what's the overhead here ? before you compare you will also bind
authenticated ?

>      ACLs may be used to restrict this comparison from being made.

In the normal case the compare to a UserPassword is not allowed by ACLs.
>    12.5.1 During a compare operation on the userPassword attribute

will the returncodes and errormessages change for the compare operation
?
>      of the following conditions are true and prompt the user

what happens if existing V2 or V3 clients get that bind responses back ?
>       association. This work is still under investigation.

I think there should be different password policies for "users",
"administrators",
"services", "CAs", etc.
>       users of the directory and must be replicated on all the

I think that is easy if we define a subentry for the password policy.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 21 Oct 1999 14:47:24 +0200

Helmut Volpers wrote:

> <ZAP>

This is an element of definition of a Password Policy. It can be implemented as
an AccessControl or by other means...

> <...>

Same as above... It's a definition of an element of the policy.
Yes, it could be implemented as an ACI.

> <...>

> Subentries because you don't want to see this entries when you browse

This need to be worked. We need to specify a way to associate a user with a
password policy.
This could be subtree based via the use of subentries. But you may want to
define your policies with Groups or other means.
The question is still open to discussion. See section 14.

> <...>

This is for 3-tier application that uses LDAP to authenticate users. The
application opens an LDAP connection to the Directory Server, authenticate
itself and then uses compare operations to authenticate its own clients.

> In the normal case the compare to a UserPassword is not allowed by ACLs.

It may be allowed for specific users such as Administrators or Applicative
Users.

> will the returncodes and errormessages change for the compare operation

The return code should always be CompareTrue or CompareFalse. Error messages
may change. Controls should be added in case of failures due to a violation of
the password policy or in case of success and expiring password. The document
will be update in that sense.

> what happens if existing V2 or V3 clients get that bind responses back ?

Good question... We need to think about LDAP v2 clients who don't support
controls.

> <...>
> >       information in a user?s entry. We need an association between the

This is a division of "Users" into roles, groups or categories. By user, I
guess we meant any entry that can be authenticated (contains a UserPassword
attribute).
This is why there's a need to associate an entry to a password policy.
This is still under investigation and subentries is one way.

> I think that is easy if we define a subentry for the password policy.

This is the easy part.

> >       policy in the user?s entry. Some of the attributes have to be
> >       If they?re not replicated, it means that the limits apply on each
> <...>

Ludovic.

--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Netscape Alliance - Directory Group - Grenoble - France

---

From: [email-masked] (Rob Weltman)
Date: Thu, 21 Oct 1999 07:38:59 -0700

> Good question... We need to think about LDAP v2 clients who don't support

  We've had them for almost two years now in Netscape Directory Server, and it works fine. Controls are never returned to an LDAPv2 client. LDAPv3 clients which are not aware of password policy ignore the controls.

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Oct 1999 07:56:45 -0700

Initial comments...

This draft proposes changes the behavior of userPassword attribute
which are incompatible with the RFC2256 defined schema rules:

  5.36. userPassword   
    ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch  
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
   Passwords are stored using an Octet String syntax and are not
   encrypted.

a) compare must use octetStringMatch
b) servers cannot encrypt (or hash) the password and store
   it in userPassword.

The draft relies on LDAPv3 mechanisms (controls).  The
draft, however, does not state that any protocol restrictions
exist.  If LDAPv2 is to be supported, the document should state
how a server should respond with the client attempts to bind
or is bound using LDAPv2.

The draft uses results not allowed by RFC2251.  In particular,
constraintViolation is not allowed in a bindResponse.

Editing issues:
  The draft should not be written in terms of the LDAP C API draft.
  Please use names defined by RFC2251 instead of LDAP C API defines.
	ie: use constraintViolation not LDAP_CONSTRAINT_VIOLATION

At 02:16 PM 10/19/99 -0700, Prasanta Behera wrote:
>      authentication method [RFC-2251],

>	the password based SASL
>Attachment Converted: "c:\home\kurt\data files\eudora\attach\smime1.p7s"
>

----
Kurt D. Zeilenga <[email-masked]>
OpenLDAP Project <http://www.OpenLDAP.org/>

---

From: [email-masked] (Prasanta Behera)
Date: Thu, 21 Oct 1999 10:12:21 -0700

> Why is it needed in the password policy ? It's an item of AccessControl.

You can control password change via ACLs too. This provide a easier
mechanism to switch on/off "the ability to change password". Once we
support multiple policies  ( i.e. association between set of users and a policy)
this
makes life easier ( don't have to create lots of ACLs).

> Subentries because you don't want to see this entries when you browse

Section 14 touched on this issue. We left it open to get feedback from the
community.  We  have considered  the approaches you have suggested but
didn't   have time to think it thru to make it to the draft.  This is one of the

area which we will be working on for the next round.

> what's the overhead here ? before you compare you will also bind

correct.

> In the normal case the compare to a UserPassword is not allowed by ACLs.

It's a admin decision.

> I think there should be different password policies for "users",

Right.

> I think that is easy if we define a subentry for the password policy.

I think so.

/prasanta

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Oct 1999 09:50:22 -0700

At 02:16 PM 10/19/99 -0700, Prasanta Behera wrote:
>      authentication method [RFC-2251]

RFC2251 doesn't meantion userPassword in the context of
authentication, neither should this document.  (See other thread)

>	In this document, the

This terminology might be confusing when discussiong 3rd party
authenication applications.  I suggest using user to refer to
the entity being authenticated and client to refer LDAP
application which is submitting LDAP requests on behalf of this
entity.

>            checked before the password is saved'

'Syntax' implies that this is enabling a schema check.  It's
actually enables various checks for password restrictions.
I would suggest renaming this attribute or, at least,
changing this attribute's description.

>            means no warning will be sent’

Sounds like the user is going to be sent an unsolicited notification
message of some sort.

>        DESC'the type of hash algorithm used to store directory server

used 'by default'.   That is, that scheme which is currently used
for generation of hashed password values for storage purposes.
Also, I would like to see an attribute which enumerates
which hash algorithms are currently supported for checking passwords.
Many servers can support checking against multiple hash algorithms
([S]MD5, [S]SHA, crypt, etc.).  That is, you can change the policy
for generation of passwords for storage purposes while to support
checking against both new and old hash algorithms.

>      2307].

It should be noted two storage schemes can be found in RFC-2307.
Also note that RFC-2307 is has a few holes, such as it doesn't
describe how the encryptedpassword should encoded to string.  I
suggest that such details be left to implementations (and
future drafts) and remove from this draft all dependency upon
RFC-2307.

>            password will never expire'

If an administrator changes expiration policy, each pwdExpirationTime
in that policy would need to be adjusted.  If an administrator
didn't previously have an expiration policy, it not possible to
establish an pwdExpirationTime specific to this entry and as
until the administrator does add some pwdExpirationTime value,
the current password will never expirse.  If a password expiration
policy is in affect, no pwdExpirationTime should imply 'has expired'.

I would suggest that this attribute be replaced with an attribute
which would serve as timestamp for each password modification.
This would allow for a expiration policy change to made with
requiring change to each entry under that policy.  The password
of an entry without a such timestamp would be considerred expired
if an expiration policy was in effect.

>      be sent to the client respectively.

Again, sounds like the server should send an unsolicited notification
of some sort...

>	The actual expiration time

As noted above, this requires each entry under the policy to be
updated whenever the expiration policy changes.

>      syntax will be checked before a new password is saved.

I suggest s/syntax/restrictions/.

>      LDAP_CONSTRAINT_VIOLATION

I am not sure constraintViolation is the most appropriate
resultCode to use.  I'll have to chew on this before making
any suggestions.

>      that the password meets the minimum length and other constraints.

There should be a requirement that servers publish password
policy to any client which can modify an attribute under the
policy. (Much like the requirement to publish schema for any
attribute that a client can modify).

>      privilege to modify the userPassword attribute values.

Which checks, access policy or password policy, are applied first.
That is, if a modify operation violates both policies, which error
will be returned.  I would assume access controls would be applied
first.

>      expired control in the controls field of the response message:

All this special unwillingToPerform behavior gives me the willies.

>      In ldif format:

Nit: No DN, not valid LDIF (no DN).  And 'LDIF format' is redundant.
And a reference, please.

>         pwdStorageScheme: SHA

Should be pwdDefaultStorageScheme.

More later...

----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Oct 1999 12:09:51 -0700

As I've was rereading this draft, a few things struck me as
being overly complex.  Most of this complexity is caused
by enforcing policy when modify used to set credentials.

An alternative approach would be use a control sent with a
BindRequest to specify new credentials.  Here is a little
food for thought.

Basically, a simple bind request would only return success if:
	1) access controls permitted the operation,
	2) proper credentials were provided, and
	3) password policy was satisfied.

If, for example, the credentials have expired, the bindResponse
contain an invalidCredentials result, an appropriate text
message, and, if LDAPv3, a control indicating the reason
why the credentials are considered invalid.

To set credentials, the client would send an LDAPv3 simple
bindRequest with the current credentials and a control
containing the new credentials.  If all is well and
a rebind was not required by policy, a success would be
returned.  Otherwise the response would contain an appropriate
result code and, if appropriate, a control providing additional
information (such as rebind required).

A new attribute type could be provided to store encrypted
credentials.  This attribute could have a syntax that supported
equality match of the appropriate hash of client provided
value with the stored hash value.  An attribute type option
(;binary?) to indicate that client value should be matched
directly against the stored value.

Additionally, a control (enforcePasswordPolicy) could be
defined, and specified with operations that modify the stored
credentials, that would enable password policy processing.
A well behaving 3rd party authentication application would
provide an enforcePasswordPolicy critical control.

I believe such an approach would eliminates much of the
complexity associated with implementing password policy codes
with both clients and servers.

If there are others interested in this alternative approach,
I'd be willing to work with them on an I-D.
 
	Kurt

----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 22 Oct 1999 23:07:38 -0700

>      password failure limit is reached.

As I noted previously, constraintViolation is not an appropriate
resultCode to be provided in a bindResponse.  I suggest returning
invalidCredentials.  Rational: reaching the password guessing
limit can be viewed as temporarily invalidating the credentials.

>      message to indicate the password failure limit is reached.

I suggest returning invalidCredentials.  Rational: reaching the
password failure limit can be viewed as temporarily invalidating
the credentials.

>         not allowed to change the password.

Seems like insufficientAccessRights would be more appropriate.
The policy is stating that this user does not have sufficient
rights to change password.

As noted by others, this capability may be better provided
by the access control features of the server.  I concur.

>     order to reduce possible overhead involved in performing a bind.

That overhead you are avoiding is implementation other policies.
By using compare, you disallow the server from applying such
policies.

>     document may be circumvention.

Redirectors can easily circumvented the policy.  And they will...
to improve performance.  A common approach is for the redirector
to cache information to avoid further directory operations.

I see no reason why the server MUST comply.  SHOULD should be sufficient.

>      server and therefore, a user can try to bind N times on each

If they are replicated (single-master), the master will reset
counters on the slaves upon each replication.  An attacker
could use abuse this to obtain more than N attempts on each
server.

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>