[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: please publish ldap password policy draft
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
> prasanta@netscape.com
>
> Valerie Chu
> Netscape Communications Corp.
> 501 E. Middlefield Rd.
> Mountain View, CA 94043
> USA
> +1 650 937-3443
> vchu@netscape.com
>
> Ludovic Poitou
> Sun Microsystems Inc.
> 32 Chemin du vieux chêne
> 38240 Meylan
> France
> +33 476 414 212
> ludovic.poitou@france.sun.com
>
> Jim Sermersheim
> Novell, Inc.
> 122 East 1700 South
> Provo, Utah 84606, USA
> +1 801 861-3088
> jimse@novell.com
>
>
> Behera, Chu, Poitou, Sermersheim Expires 20 April 2000 [Page 18]
>