Subject: RE: please publish ldap password policy draft

From: "Bob Joslin" <[email-masked]>
Date: Wed, 20 Oct 1999 17:19:24 -0700

See comments under 12.5...

Thanks,

Bob Joslin

> -----Original Message-----
> From: Bob Joslin [mailto:bobj]
> Sent: Wednesday, October 20, 1999 2:21 PM
> To: bobj
> Subject:
>
>
>
>
>                                                                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
>

I assume you propose this as a new extended operation.  Do you propose
adding a new API?

Also, I assume you must have bound to the directory to perform this
operation.  Correct?

>      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

When you say PAM, are you referring to a Posix compliant system that
supports the Open Group defined PAM subsystem?  If so, how does the compare
operation help?  I am having trouble coming up with feasable implemtation
where the pam_authenticate back-end procedure does not need to open a new
connection to the LDAP server each time it is called.  Thus I don't see how
that example shows how you can eliminate the overhead of the bind operation.

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

How are the ACLs evaluated?  Are ACLs applied for the user who is calling
the compare operation or as the one being tested?  I assume the former but
would like clairification.

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

Am I correct in understanding that you don't examine all password policy
rules for a compare operation?  For example, suppose that the entry has a
login time of day restriction (defind outside the scope of this schema.)
Suppose a rule exists that says the DN may not bind from the hours of 6:00pm
to 6:00am?  If a compare operation is performed at 7:00pm, should it return
true (assuming no other failure conditions?)

Should the compare operation return the extented controls that indicate if a
password is about to expire, etc...?

How should zero length password strings be treated?  In a bind operation the
null string is a special syntax that means bind anonymously.  What does it
mean for a compare?

>
>    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: Ludovic Poitou <[email-masked]>
Date: Thu, 21 Oct 1999 11:21:48 +0200

Bob Joslin wrote:

> <...>

No the Compare operation is an LDAPv2 and v3 operation.

> Also, I assume you must have bound to the directory to perform this

You may or may not have bound. This is an administrator choice.

> that example shows how you can eliminate the overhead of the bind operation.

Several 3-tier applications are using LDAP to perform password based
authentication. This can be the case of an web-ldap gateway, an Mail server, an
FTP server...or the LDAP Pluggable Authentication Module (PAM).
It's true that opening a connection for each authentication doesn't really
scale.
Many of these applications open one connection, authenticate themselves and
just check the user password using a compare operation using the User DN and
the user password. The compare operation is much faster because you don't have
to perform extra checking and computing that the bind operation has to do.

> would like clairification.

ACL are applied for the user who is calling the compare operation.

> login time of day restriction (defind outside the scope of this schema.)

This is out of the scope of this draft. We're thinking about such services but
they are not dealing with passwords. So they should appear in a separate
document.

> true (assuming no other failure conditions?)

This would have to be specified for a "Constrained Login Service".

> password is about to expire, etc...?

I think it should. This will be clarified in the next version of the document.

> null string is a special syntax that means bind anonymously.  What does it

It doesn't mean anything. You cannot compare with zero length password. The
client should not call the compare operation if it
doesn't want to perform authentication.

Ludovic.

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

---

From: Helmut Volpers <[email-masked]>
Date: Thu, 21 Oct 1999 12:56:34 +0200

Hi,

> You may or may not have bound. This is an administrator choice.

But in a normal environment an administrator will not allow a compare
to the Password for anonymous bind ?
> to perform extra checking and computing that the bind operation has to do.

Does it mean if you have a password policy it have not been checked by
the Server if you do a compare ?

> doesn't want to perform authentication.

Does it mean the compare should only be used for authentication ?

Helmut

---

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

> to the Password for anonymous bind ?

Right...

> the Server if you do a compare ?

No. The goal of this section is to describe what to do with the Password Policy in
the case of the Compare Operation.
It may be implementation details, but  Novell, Sun and Netscape experimented
separately that Bind operations were slower than compare operations on
userpassword..

> Does it mean the compare should only be used for authentication ?

zero length password strings will be compared FALSE. It is up to the 3-tier
application to decide whether it means Anonymous for it or failure. This decision
could have been made before sending the compare request, by checking the length of
the password.

What this document is describing here, is that a compare operation on the
userPassword attribute should be considered as an authentication request with
regards to a Password Policy enforcement. It doesn't implies Authentication to the
LDAP server (identity used for ACLs).

Ludovic.

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Thu, 21 Oct 1999 09:44:24 -0700 (PDT)

| >
| >
| > >      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
| >
| > When you say PAM, are you referring to a Posix compliant system that
| > supports the Open Group defined PAM subsystem?  If so, how does the compare
| > operation help?  I am having trouble coming up with feasable implemtation
| > where the pam_authenticate back-end procedure does not need to open a new
| > connection to the LDAP server each time it is called.  Thus I don't see how
| > that example shows how you can eliminate the overhead of the bind
| operation. >
| 
| Several 3-tier applications are using LDAP to perform password based
| authentication. This can be the case of an web-ldap gateway, an Mail server,
| an FTP server...or the LDAP Pluggable Authentication Module (PAM).
| It's true that opening a connection for each authentication doesn't really
| scale.
| Many of these applications open one connection, authenticate themselves and
| just check the user password using a compare operation using the User DN and
| the user password. The compare operation is much faster because you don't
| have to perform extra checking and computing that the bind operation has to
| do.
| 

Does the DS apply the pwdDefaultStorageScheme hash to the password BEFORE the
compare is done?  All LDAP directory servers don't apply the storage hash
before the compare.  This is done only on a bind.  Hence using a compare for
user authentication is not gauranteed to work.

Anil Srivastava
iPlanet Messaging Server

| 
| >
| > >      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.
| >
| > How are the ACLs evaluated?  Are ACLs applied for the user who is calling
| > the compare operation or as the one being tested?  I assume the former but
| > would like clairification.
| >
| 
| ACL are applied for the user who is calling the compare operation.
| 
| 
| >
| > >
| > >       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.
| >
| > Am I correct in understanding that you don't examine all password policy
| > rules for a compare operation?  For example, suppose that the entry has a
| > login time of day restriction (defind outside the scope of this schema.)
| 
| This is out of the scope of this draft. We're thinking about such services
| but they are not dealing with passwords. So they should appear in a separate
| document.
| 
| 
| >
| > Suppose a rule exists that says the DN may not bind from the hours of
| 6:00pm > to 6:00am?  If a compare operation is performed at 7:00pm, should
| it return > true (assuming no other failure conditions?)
| 
| This would have to be specified for a "Constrained Login Service".
| 
| 
| >
| >
| > Should the compare operation return the extented controls that indicate if
| a > password is about to expire, etc...?
| >
| 
| I think it should. This will be clarified in the next version of the
| document.
| 
| 
| >
| > How should zero length password strings be treated?  In a bind operation
| the > null string is a special syntax that means bind anonymously.  What
| does it > mean for a compare?
| 
| It doesn't mean anything. You cannot compare with zero length password. The
| client should not call the compare operation if it
| doesn't want to perform authentication.
| 
| Ludovic.
| 
| --
| Ludovic Poitou
| Sun Microsystems Inc.
| Sun-Netscape Alliance - Directory Group - Grenoble - France
| 
| 
|

---

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

Anil SRIVASTAVA wrote:

> compare is done?

It has to. That's the only way to verify if it is the same password.

> All LDAP directory servers don't apply the storage hash
> before the compare.

If some servers keep a cleartxt version of the password then  there
is no need to hash it otherwise I don't see how that is possible.

> This is done only on a bind.  Hence using a compare for

/prasanta

---

From: "Bob Joslin" <[email-masked]>
Date: Thu, 21 Oct 1999 11:14:11 -0700

> to perform extra checking and computing that the bind operation has to do.

Thanks for the reply.  I do understand that this architecture will greatly
improve performance of applications that maintain a connection to the LDAP
server, such as an what you mentioned above.  My point is that I don't think
LDAP PAM is a good example of this.  Most examples you provied above are
servers (which can easily maintian the connection to the LDAP server.)  I've
never seen an implementation of PAM that works like a server (though it's
certianly possible.)

> they are not dealing with passwords. So they should appear in a separate

Since 12.5 starts out by saying this feature is useful for authentication
redirectors, I'm a bit concerned that the redirector may authenticate a user
because a compare succeeded when other policy rules would have caused a
failure.  I guess I'm concerned about promoting this type of architecture
for those reasons.  But this is a subjective view.

> doesn't want to perform authentication.

As one example, RFC 2256 defines userPassword to be an Octet String.  And if
I am not mistaken, that means that the userPassword attribute can have zero
length.  Thus a compare operation of a zero length string against a zero
length userPassword attribute should succeed, no?