From c8520d2b7dcc6556153be1f1f9774e1f858a582e Mon Sep 17 00:00:00 2001 From: Howard Chu Date: Fri, 8 Jul 2005 10:17:03 +0000 Subject: [PATCH] import draft-08 since that's what we now implement. sss: ---------------------------------------------------------------------- --- .../draft-behera-ldap-password-policy-xx.txt | 3940 +++++++++-------- 1 file changed, 2053 insertions(+), 1887 deletions(-) diff --git a/doc/drafts/draft-behera-ldap-password-policy-xx.txt b/doc/drafts/draft-behera-ldap-password-policy-xx.txt index 8e68484a13..d9978abe04 100644 --- a/doc/drafts/draft-behera-ldap-password-policy-xx.txt +++ b/doc/drafts/draft-behera-ldap-password-policy-xx.txt @@ -1,1940 +1,2046 @@ +Network Working Group J. Sermersheim +Internet-Draft Novell, Inc +Expires: April 24, 2005 L. Poitou + Sun Microsystems + October 24, 2004 -Internet-Draft P. Behera -draft behera-ldap-password-policy-07.txt L. Poitou -Intended Category: Proposed Standard Sun Microsystems -Expires: August 2004 J. Sermersheim - Novell - - February 2004 - - - Password Policy for LDAP Directories - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. - - 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. - - Technical discussions of this draft are held on the LDAPEXT Working - Group mailing list at ietf-ldapext@netscape.com. Editorial comments - may be sent to the authors listed in Section 13. - - Copyright (C) The Internet Society (2004). All rights Reserved. - - Please see the Copyright Section near the end of this document for - more information. - - - -Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document - are to be interpreted as described in RFC 2119 [RFC-2119]. - - - -Behera, et. al. Expires August 15, 2004 Page 1 + + Password Policy for LDAP Directories + draft-behera-ldap-password-policy-08.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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. + + This Internet-Draft will expire on April 24, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + Password policy as described in this document is a set of rules that + controls how passwords are used and administered in Lightweight + Directory Access Protocol (LDAP) based 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 + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 1] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - -1. Abstract - - Password policy as described in this document is a set of rules that - controls how passwords are used and administered in LDAP - directories. In order to improve the security of LDAP directories - and make it difficult for password cracking programs to break into - directories, it is desirable to enforce a set of rules on password - usage. These rules are made to ensure that users change their - passwords periodically, passwords meet construction requirements, - the re-use of old password is restricted, and users are locked out - after a certain number of failed attempts. - - - -2. Overview - - LDAP-based directory services are currently accepted by many - organizations as the access protocol for directories. The ability to - ensure the secure read and update access to directory information - throughout the network is essential to the successful deployment. - Most LDAP implementations support many authentication schemes - the - most basic and widely used is the simple authentication i.e., user - DN and password. In this case, many LDAP servers have implemented - some kind of policy related to the password used to authenticate. - Among other things, this policy includes: - - - Whether and when passwords expire. - - Whether failed bind attempts cause the account to be locked. - - If and how users are able to change their passwords. - - In order to achieve greater security protection and ensure - interoperability in a heterogeneous environment, LDAP needs to - standardize on a common password policy model. This is critical to - the successful deployment of LDAP directories. - -2.1. Application of password policy - - The password policy defined in this document can be applied to any - attribute holding a user's password used for an authenticated LDAP - bind operation. In this document, the term "user" represents any - LDAP client application that has an identity in the directory. - - This policy is typically applied to the userPassword attribute in - the case of the LDAP simple authentication method [RFC-2251] or the - case of password based SASL [RFC-2222] authentication such as CRAM- - MD5 [RFC-2195] and DIGEST-MD5 [RFC-Digest]. - - - - -Behera, et. al. Expires August 15, 2004 Page 2 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + ensure that users change their passwords periodically, passwords meet + construction requirements, the re-use of old password is restricted, + and users are locked out after a certain number of failed attempts. + +Discussion Forum + + Technical discussion of this document will take place on the IETF + LDAP Extensions mailing list . Please send + editorial comments directly to the authors. + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Application of password policy . . . . . . . . . . . . . . . . 6 + 4. Articles of password policy . . . . . . . . . . . . . . . . . 7 + 4.1 Password Usage Policy . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Password Modification Policy . . . . . . . . . . . . . . . . . 7 + 4.3 Restriction of the Password Policy . . . . . . . . . . . . . . 10 + 5. Schema used for Password Policy . . . . . . . . . . . . . . . 11 + 5.1 The pwdPolicy Object Class . . . . . . . . . . . . . . . . . . 11 + 5.2 Attribute Types used in the pwdPolicy ObjectClass . . . . . . 11 + 5.3 Attribute Types for Password Policy State Information . . . . 16 + 6. Controls used for Password Policy . . . . . . . . . . . . . . 20 + 6.1 Request Control . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.2 Response Control . . . . . . . . . . . . . . . . . . . . . . . 20 + 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . . 22 + 7.1 Locked Account Check . . . . . . . . . . . . . . . . . . . . . 22 + 7.2 Password Must be Changed Now Check . . . . . . . . . . . . . . 22 + 7.3 Password Expiration Check . . . . . . . . . . . . . . . . . . 22 + 7.4 Remaining Grace AuthN Check . . . . . . . . . . . . . . . . . 22 + 7.5 Time Before Expiration Check . . . . . . . . . . . . . . . . . 23 + 7.6 Intruder Detection Check . . . . . . . . . . . . . . . . . . . 23 + 7.7 Password Too Young Check . . . . . . . . . . . . . . . . . . . 23 + 8. Server Policy Enforcement Points . . . . . . . . . . . . . . . 24 + 8.1 Password-based Authentication . . . . . . . . . . . . . . . . 24 + 8.2 Password Update Operations . . . . . . . . . . . . . . . . . . 26 + 8.3 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 29 + 9. Client Policy Enforcement Points . . . . . . . . . . . . . . . 30 + 9.1 Bind Operation . . . . . . . . . . . . . . . . . . . . . . . . 30 + 9.2 Modify Operations . . . . . . . . . . . . . . . . . . . . . . 30 + 9.3 Add Operation . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9.4 Compare Operation . . . . . . . . . . . . . . . . . . . . . . 32 + 9.5 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 32 + 10. Administration of the Password Policy . . . . . . . . . . . . 33 + 11. Password Policy and Replication . . . . . . . . . . . . . . . 34 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 36 + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 2] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - The policy described in this document assumes that the password - attribute holds a single value. No considerations are made for - directories or systems that allow a user to maintain multi-valued - password attributes. - - Server implementations MAY institute internal policy whereby certain - identities (such as directory administrators) are not forced to - comply with any of password policy. In this case, the password for a - directory administrator never expires; the account is never locked, - etc. - - The term "directory administrator" refers to a user that has - sufficient access control privileges to modify users' passwords, and - the pwdPolicy object defined in this document. The access control - that is used to determine whether an identity is a directory - administrator is beyond the scope of this document, but typically - implies that the administrator has 'write' privileges to the - password attribute. - -3. Articles of password policy - - The following sections explain in general terms each aspect of the - password policy defined in this document as well as the need for - each. These policies are subdivided into the general groups of - password usage and password modification. Implementation details are - presented in Sections 6 and 7. - -3.1. Password Usage Policy - - This section describes policy enforced when a password is used to - authenticate. The general focus of this policy is to minimize the - threat of intruders once a password is in use. - -3.1.1. Password Guessing limit - - In order to prevent intruders from guessing a user's password, a - mechanism exists to track the number of failed authentication - attempts, and take action when a limit is reached. - - This policy consists of five parts: - - - A configurable limit on failed authentication attempts. - - - A counter to track the number of failed authentication attempts. - - - A timeframe in which the limit of consecutive failed - authentication attempts must happen before action is taken. - - - - -Behera, et. al. Expires August 15, 2004 Page 3 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + 14. Normative References . . . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 + Intellectual Property and Copyright Statements . . . . . . . . 38 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 3] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - The action to be taken when the limit is reached. The action will - either be nothing, or the account will be locked. - - - An amount of time the account is locked (if it is to be locked). - This can be indefinite. - -3.2. Password Modification Policy - - This section describes policy enforced while users are modifying - passwords. The general focus of this policy is to ensure that when - users add or change their passwords, the security and effectiveness - of their passwords is maximized. In this document, the term "modify - password operation" refers to any operation that is used to add or - modify a password attribute. Often this is done by updating the - userPassword attribute during an add or modify operation, but MAY be - done by other means such as an extended operation. - - -3.2.1. Password Expiration, Expiration Warning, and Grace binds - - One of the key properties of a password is the fact that it is not - well known. If a password is frequently changed, the chances of that - user's account being broken into are minimized. - - Directory administrators may deploy a password policy that causes - passwords to expire after a given amount of time - thus forcing - users to change their passwords periodically. - - As a side effect, there needs to be a way in which users are made - aware of this need to change their password before actually being - locked out of their accounts. One or both of the following methods - handle this: - - - The user is sent a warning sometime before his password is due to - expire. If the user fails to heed this warning before the - expiration time, his account will be locked. - - - The user may bind to the directory a preset number of times after - her password has expired. If she fails to change her password - during one of her 'grace' binds, her account will be locked. - -3.2.2. Password History - - When the Password Expiration policy is used, an additional mechanism - may be employed to prevent users from simply re-using a previous - password (as this would effectively circumvent the expiration - policy). - - - - -Behera, et. al. Expires August 15, 2004 Page 4 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +1. Overview + + LDAP-based directory services are currently accepted by many + organizations as the access protocol for directories. The ability to + ensure the secure read and update access to directory information + throughout the network is essential to the successful deployment. + Most LDAP implementations support many authentication schemes - the + most basic and widely used is the simple authentication i.e., user DN + and password. In this case, many LDAP servers have implemented some + kind of policy related to the password used to authenticate. Among + other things, this policy includes: + + o Whether and when passwords expire. + o Whether failed bind attempts cause the account to be locked. + o If and how users are able to change their passwords. + + In order to achieve greater security protection and ensure + interoperability in a heterogeneous environment, LDAP needs to + standardize on a common password policy model. This is critical to + the successful deployment of LDAP directories. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 4] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - In order to do this; a history of used passwords is kept. The - directory administrator sets the number of passwords to be stored at - any given time. Passwords are stored in this history whenever the - password is changed. Users aren't allowed to specify any passwords - that are in the history list while changing passwords. - -3.2.3. Password Minimum Age - - Users may circumvent the Password History mechanism by quickly - performing a series of password changes. If they change their - password enough times, their 'favorite' password will be pushed out - of the history list. - - This process may be made less attractive to users by employing a - minimum age for passwords. If users are forced to wait 24 hours - between password changes, they may be less likely to cycle through a - history of 10 passwords. - -3.2.4. Password Quality and Minimum length - - In order to prevent users from creating or updating passwords that - are easy to guess, a password quality policy may be employed. This - policy consists of two general mechanisms - ensuring that passwords - conform to a defined quality criteria and ensuring that they are of - a minimum length. - - Forcing a password to comply with the quality policy may imply a - variety of things including: - - - Disallowing trivial or well-known words make up the password. - - - Forcing a certain number of digits be used. - - - Disallowing anagrams of the user's name. - - The implementation of this policy meets with the following problems: - - - If the password to be added or updated is encrypted by the client - before being sent, the server has no way of enforcing this - policy. Therefore, the onus of enforcing this policy falls upon - client implementations. - - - There are no specific definitions of what 'quality checking' - means. This can lead to unexpected behavior in a heterogeneous - environment. - -3.2.5. User Defined Passwords - - - - -Behera, et. al. Expires August 15, 2004 Page 5 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +2. Conventions + + Imperative keywords defined in [RFC2119] are used in this document, + and carry the meanings described there. + + All Basic Encoding Rules (BER) [X690] encodings follow the + conventions found in Section 5.1 of [RFC2251]. + + The term "password administrator" refers to a user that has + sufficient access control privileges to modify users' passwords. The + term "password policy administrator" refers to a user that has + sufficient access control privileges to modify the pwdPolicy object + defined in this document. The access control that is used to + determine whether an identity is a password administrator or password + policy administrator is beyond the scope of this document, but + typically implies that the password administrator has 'write' + privileges to the password attribute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 5] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - In some cases, it is desirable to disallow users from adding and - updating their own passwords. This policy makes this functionality - possible. - - This implies that certain other policy, such as password expiration - is not enforced. - -3.2.6. Password Change After Reset - - This policy forces the user to update her password after it has been - set for the first time, or has been reset by the directory - administrator. - - This is needed in scenarios where a directory administrator has set - or reset the password to a well-known value. - -3.2.7. Safe modification - - As directories become more commonly used, it will not be unusual for - clients to connect to a directory and leave the connection open for - an extended period. This opens up the possibility for an intruder to - make modifications to a user's password while that user's computer - is connected but unattended. - - This policy forces the user to prove his identity by specifying the - old password during a password modify operation. - -3.3. Restriction of the Password Policy - - The password policy defined in this document can apply to any - attribute containing a password. Password policy state information - is held in the user's entry, and applies to a password attribute, - not a particular password attribute value. Thus the server SHOULD - enforce that the password attribute subject to password policy, - contains one and only one password value. - - -4. Schema used for Password Policy - - The schema elements defined here fall into two general categories. A - password policy object class is defined which contains a set of - administrative password policy attributes, and a set of operational - attributes are defined that hold general password policy state - information for each user. - -4.1. The pwdPolicy Object Class - - This object class contains the attributes defining a password policy - in effect for a set of users. Section 8 describes the administration - - -Behera, et. al. Expires August 15, 2004 Page 6 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +3. Application of password policy + + The password policy defined in this document can be applied to any + attribute holding a user's password used for an authenticated LDAP + bind operation. In this document, the term "user" represents any + LDAP client application that has an identity in the directory. + + This policy is typically applied to the userPassword attribute in the + case of the LDAP simple authentication method [RFC2251] or the case + of password based SASL [RFC2222] authentication such as CRAM-MD5 + [RFC2195] and DIGEST-MD5 [RFC2831]. + + The policy described in this document assumes that the password + attribute holds a single value. No considerations are made for + directories or systems that allow a user to maintain multi-valued + password attributes. + + Server implementations MAY institute internal policy whereby certain + identities (such as directory administrators) are not forced to + comply with any of password policy. In this case, the password for a + directory administrator never expires; the account is never locked, + etc. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 6] + +Internet-Draft Password Policy for LDAP Directories October 2004 + + +4. Articles of password policy + + The following sections explain in general terms each aspect of the + password policy defined in this document as well as the need for + each. These policies are subdivided into the general groups of + password usage and password modification. Implementation details are + presented in Section 8 and Section 9. + +4.1 Password Usage Policy + + This section describes policy enforced when a password is used to + authenticate. The general focus of this policy is to minimize the + threat of intruders once a password is in use. + +4.1.1 Password Guessing Limit + + In order to prevent intruders from guessing a user's password, a + mechanism exists to track the number of failed authentication + attempts, and take action when a limit is reached. This policy + consists of five parts: + + o A configurable limit on failed authentication attempts. + o A counter to track the number of failed authentication attempts. + o A timeframe in which the limit of consecutive failed + authentication attempts must happen before action is taken. + o The action to be taken when the limit is reached. The action will + either be nothing, or the account will be locked. + o An amount of time the account is locked (if it is to be locked). + This can be indefinite. + +4.2 Password Modification Policy + + This section describes policy enforced while users are modifying + passwords. The general focus of this policy is to ensure that when + users add or change their passwords, the security and effectiveness + of their passwords is maximized. In this document, the term "modify + password operation" refers to any operation that is used to add or + modify a password attribute. Often this is done by updating the + password attribute during an add or modify operation, but MAY be done + by other means such as an extended operation. + +4.2.1 Password Expiration, Expiration Warning, and Grace + Authentications + + One of the key properties of a password is the fact that it is not + well known. If a password is frequently changed, the chances of that + user's account being broken into are minimized. + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 7] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - of this object, and the relationship between it and particular - objects. - - ( 1.3.6.1.4.1.42.2.27.8.2.1 - NAME 'pwdPolicy' - SUP top - AUXILIARY - MUST ( pwdAttribute ) - MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ - pwdMinLength $ pwdExpireWarning $ pwdGraceLoginLimit $ pwdLockout - $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ - pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) - -4.2. Attribute Types used in the pwdPolicy ObjectClass - - Following are the attribute types used by the pwdPolicy object - class. - -4.2.1. pwdAttribute - - This holds the name of the attribute to which the password policy is - applied. For example, the password policy may be applied to the - userPassword attribute. - - ( 1.3.6.1.4.1.42.2.27.8.1.1 - NAME 'pwdAttribute' - EQUALITY objectIdentifierMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) - -4.2.2. pwdMinAge - - This attribute holds the number of seconds that must elapse between - modifications to the password. If this attribute is not present, 0 - seconds is assumed. - - ( 1.3.6.1.4.1.42.2.27.8.1.2 - NAME 'pwdMinAge' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.3. pwdMaxAge - - This attribute holds the number of seconds after which a modified - password will expire. - - If this attribute is not present, or if the value is 0 the password - does not expire. If not 0, the value must be greater than or equal - to the value of the pwdMinAge. - - -Behera, et. al. Expires August 15, 2004 Page 7 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + Password policy administrators may deploy a password policy that + causes passwords to expire after a given amount of time - thus + forcing users to change their passwords periodically. + + As a side effect, there needs to be a way in which users are made + aware of this need to change their password before actually being + locked out of their accounts. One or both of the following methods + handle this: + + o A warning may be returned to the user sometime before his password + is due to expire. If the user fails to heed this warning before + the expiration time, his account will be locked. + o The user may bind to the directory a preset number of times after + her password has expired. If she fails to change her password + during one of her 'grace' authentications, her account will be + locked. + +4.2.2 Password History + + When the Password Expiration policy is used, an additional mechanism + may be employed to prevent users from simply re-using a previous + password (as this would effectively circumvent the expiration + policy). + + In order to do this; a history of used passwords is kept. The + password policy administrator sets the number of passwords to be + stored at any given time. Passwords are stored in this history + whenever the password is changed. Users aren't allowed to specify + any passwords that are in the history list while changing passwords. + +4.2.3 Password Minimum Age + + Users may circumvent the Password History mechanism by quickly + performing a series of password changes. If they change their + password enough times, their 'favorite' password will be pushed out + of the history list. + + This process may be made less attractive to users by employing a + minimum age for passwords. If users are forced to wait 24 hours + between password changes, they may be less likely to cycle through a + history of 10 passwords. + +4.2.4 Password Quality and Minimum length + + In order to prevent users from creating or updating passwords that + are easy to guess, a password quality policy may be employed. This + policy consists of two general mechanisms - ensuring that passwords + conform to a defined quality criterion and ensuring that they are of + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 8] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - ( 1.3.6.1.4.1.42.2.27.8.1.3 - NAME 'pwdMaxAge' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.4. pwdInHistory - - This attribute specifies the maximum number of used passwords stored - in the pwdHistory attribute. - - If this attribute is not present, or if the value is 0, used - passwords are not stored in the pwdHistory attribute and thus may be - reused. - - ( 1.3.6.1.4.1.42.2.27.8.1.4 - NAME 'pwdInHistory' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.5. pwdCheckQuality - - This attribute indicates how the password quality will be verified - while being modified or added. If this attribute is not present, or - if the value is '0', quality checking will not be enforced. A value - of '1' indicates that the server will check the quality, and if the - server is unable to check it (due to a hashed password or other - reasons) it will be accepted. A value of '2' indicates that the - server will check the quality, and if the server is unable to verify - it, it will return an error refusing the password. - - ( 1.3.6.1.4.1.42.2.27.8.1.5 - NAME 'pwdCheckQuality' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.6. pwdMinLength - - When quality checking is enabled, this attribute holds the minimum - number of characters that must be used in a password. If this - attribute is not present, no minimum password length will be - enforced. If the server is unable to check the length (due to a - hashed password or otherwise), the server will, depending on the - value of the pwdCheckQuality attribute, either accept the password - without checking it ('0' or '1') or refuse it ('2'). - - - -Behera, et. al. Expires August 15, 2004 Page 8 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + a minimum length. + + Forcing a password to comply with the quality policy may imply a + variety of things including: + + o Disallowing trivial or well-known words make up the password. + o Forcing a certain number of digits be used. + o Disallowing anagrams of the user's name. + + The implementation of this policy meets with the following problems: + + o If the password to be added or updated is encrypted by the client + before being sent, the server has no way of enforcing this policy. + Therefore, the onus of enforcing this policy falls upon client + implementations. + o There are no specific definitions of what 'quality checking' + means. This can lead to unexpected behavior in a heterogeneous + environment. + +4.2.5 User Defined Passwords + + In some cases, it is desirable to disallow users from adding and + updating their own passwords. This policy makes this functionality + possible. + + This implies that certain other policy, such as password expiration + is not enforced. + +4.2.6 Password Change after Reset + + This policy forces the user to update her password after it has been + set for the first time, or has been reset by a password + administrator. + + This is needed in scenarios where a password administrator has set or + reset the password to a well-known value. + +4.2.7 Safe Modification + + As directories become more commonly used, it will not be unusual for + clients to connect to a directory and leave the connection open for + an extended period. This opens up the possibility for an intruder to + make modifications to a user's password while that user's computer is + connected but unattended. + + This policy forces the user to prove his identity by specifying the + old password during a password modify operation. + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 9] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - ( 1.3.6.1.4.1.42.2.27.8.1.6 - NAME 'pwdMinLength' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.7. pwdExpireWarning - - This attribute specifies the maximum number of seconds before a - password is due to expire that expiration warning messages will be - returned to an authenticating user. If this attribute is not - present, or if the value is 0 no warnings will be sent. If not 0, - the value must be smaller than the value of the pwdMaxAge attribute. - - ( 1.3.6.1.4.1.42.2.27.8.1.7 - NAME 'pwdExpireWarning' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.8. pwdGraceLoginLimit - - This attribute specifies the number of times an expired password can - be used to authenticate. If this attribute is not present or if the - value is 0, authentication will fail. - - ( 1.3.6.1.4.1.42.2.27.8.1.8 - NAME 'pwdGraceLoginLimit' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.9. pwdLockout - - This attribute indicates, when its value is "TRUE", that the - password may not be used to authenticate after a specified number of - consecutive failed bind attempts. The maximum number of consecutive - failed bind attempts is specified in pwdMaxFailure. - - If this attribute is not present, or if the value is "FALSE", the - password may be used to authenticate when the number of failed bind - attempts has been reached. - - ( 1.3.6.1.4.1.42.2.27.8.1.9 - NAME 'pwdLockout' - EQUALITY booleanMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 - SINGLE-VALUE ) - - - -Behera, et. al. Expires August 15, 2004 Page 9 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + {TODO: This allows a dictionary attack unless we specify that this is + also subject to intruder detection} + +4.3 Restriction of the Password Policy + + The password policy defined in this document can apply to any + attribute containing a password. Password policy state information + is held in the user's entry, and applies to a password attribute, not + a particular password attribute value. Thus the server SHOULD + enforce that the password attribute subject to password policy, + contains one and only one password value. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 10] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - -4.2.10. pwdLockoutDuration - - This attribute holds the number of seconds that the password cannot - be used to authenticate due to too many failed bind attempts. If - this attribute is not present, or if the value is 0 the password - cannot be used to authenticate until reset by an administrator. - - ( 1.3.6.1.4.1.42.2.27.8.1.10 - NAME 'pwdLockoutDuration' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.11. pwdMaxFailure - - This attribute specifies the number of consecutive failed bind - attempts after which the password may not be used to authenticate. - If this attribute is not present, or if the value is 0, this policy - is not checked, and the value of pwdLockout will be ignored. - - ( 1.3.6.1.4.1.42.2.27.8.1.11 - NAME 'pwdMaxFailure' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.12. pwdFailureCountInterval - - This attribute holds the number of seconds after which the password - failures are purged from the failure counter, even though no - successful authentication occurred. - - If this attribute is not present, or if its value is 0, the failure - counter is only reset by a successful authentication. - - ( 1.3.6.1.4.1.42.2.27.8.1.12 - NAME 'pwdFailureCountInterval' - EQUALITY integerMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 - SINGLE-VALUE ) - -4.2.13. pwdMustChange - - This attribute specifies with a value of "TRUE" that users must - change their passwords when they first bind to the directory after a - password is set or reset by the administrator. If this attribute is - not present, or if the value is "FALSE", users are not required to - change their password upon binding after the administrator sets or - resets the password. - - -Behera, et. al. Expires August 15, 2004 Page 10 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +5. Schema used for Password Policy + + The schema elements defined here fall into two general categories. A + password policy object class is defined which contains a set of + administrative password policy attributes, and a set of operational + attributes are defined that hold general password policy state + information for each user. + +5.1 The pwdPolicy Object Class + + This object class contains the attributes defining a password policy + in effect for a set of users. Section 10 describes the + administration of this object, and the relationship between it and + particular objects. + + ( 1.3.6.1.4.1.42.2.27.8.2.1 + NAME 'pwdPolicy' + SUP top + AUXILIARY + MUST ( pwdAttribute ) + MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ + pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout + $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ + pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) + +5.2 Attribute Types used in the pwdPolicy ObjectClass + + Following are the attribute types used by the pwdPolicy object class. + +5.2.1 pwdAttribute + + This holds the name of the attribute to which the password policy is + applied. For example, the password policy may be applied to the + userPassword attribute. + + ( 1.3.6.1.4.1.42.2.27.8.1.1 + NAME 'pwdAttribute' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + +5.2.2 pwdMinAge + + This attribute holds the number of seconds that must elapse between + modifications to the password. If this attribute is not present, 0 + seconds is assumed. + + ( 1.3.6.1.4.1.42.2.27.8.1.2 + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 11] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - ( 1.3.6.1.4.1.42.2.27.8.1.13 - NAME 'pwdMustChange' - EQUALITY booleanMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 - SINGLE-VALUE ) - -4.2.14. pwdAllowUserChange - - This attribute indicates whether users can change their own - passwords, although the change operation is still subject to access - control. If this attribute is not present, a value of "TRUE" is - assumed. - - ( 1.3.6.1.4.1.42.2.27.8.1.14 - NAME 'pwdAllowUserChange' - EQUALITY booleanMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 - SINGLE-VALUE ) - -4.2.15. pwdSafeModify - - This attribute specifies whether or not the existing password must - be sent when changing a password. If this attribute is not present, - a "FALSE" value is assumed. - - ( 1.3.6.1.4.1.42.2.27.8.1.15 - NAME 'pwdSafeModify' - EQUALITY booleanMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 - SINGLE-VALUE ) - -4.3. Attribute Types for Password Policy State Information - - Password policy state information must be maintained for each user. - The information is located in each user entry as a set of - operational attributes. These operational attributes are: - pwdChangedTime, pwdAccountLockedTime, pwdExpirationWarned, - pwdFailureTime, pwdHistory, pwdGraceUseTime, pwdReset, - pwdPolicySubEntry. - -4.3.1. Password Policy State Attribute Option - - Since the password policy could apply to several attributes used to - store passwords, each of the above operational attributes must have - an option to specify which pwdAttribute is applies to. - The password policy option is defined as the following: - pwd- - - - -Behera, et. al. Expires August 15, 2004 Page 11 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + NAME 'pwdMinAge' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.3 pwdMaxAge + + This attribute holds the number of seconds after which a modified + password will expire. + + If this attribute is not present, or if the value is 0 the password + does not expire. If not 0, the value must be greater than or equal + to the value of the pwdMinAge. + + ( 1.3.6.1.4.1.42.2.27.8.1.3 + NAME 'pwdMaxAge' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.4 pwdInHistory + + This attribute specifies the maximum number of used passwords stored + in the pwdHistory attribute. + + If this attribute is not present, or if the value is 0, used + passwords are not stored in the pwdHistory attribute and thus may be + reused. + + ( 1.3.6.1.4.1.42.2.27.8.1.4 + NAME 'pwdInHistory' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.5 pwdCheckQuality + + {TODO: Consider changing the syntax to OID. Each OID will list a + quality rule (like min len, # of special characters, etc). These + rules can be specified outsid ethis document.} + + {TODO: Note that even though this is meant to be a check that happens + during password modification, it may also be allowed to happen during + authN. This is useful for situations where the password is encrypted + when modified, but decrypted when used to authN.} + + This attribute indicates how the password quality will be verified + while being modified or added. If this attribute is not present, or + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 12] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - where passwordAttribute a string following the OID syntax - (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor - (short name) MUST be used. - - For example, if the pwdPolicy object has for pwdAttribute - "userPassword" then the pwdChangedTime operational attribute, in a - user entry, will be: - pwdChangedTime;pwd-userPassword: 20000103121520Z - - This attribute option follows sub-typing semantics. If a client - requests a password policy state attribute to be returned in a - search operation, and does not specify an option, all subtypes of - that policy state attribute are returned. - - -4.3.2. pwdChangedTime - - This attribute specifies the last time the entry's password was - changed. This is used by the password expiration policy. If this - attribute does not exist, the password will never expire. - - ( 1.3.6.1.4.1.42.2.27.8.1.16 - NAME 'pwdChangedTime' - DESC 'The time the password was last changed' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SINGLE-VALUE - USAGE directoryOperation) - -4.3.3. pwdAccountLockedTime - - This attribute holds the time that the user's account was locked. A - locked account means that the password may no longer be used to - authenticate. A 0 value means that the account has been locked - permanently, and that only an administrator can unlock the account. - - ( 1.3.6.1.4.1.42.2.27.8.1.17 - NAME 'pwdAccountLockedTime' - DESC 'The time an user account was locked' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SINGLE-VALUE - USAGE directoryOperation) - -4.3.4. pwdExpirationWarned - - - - -Behera, et. al. Expires August 15, 2004 Page 12 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + if the value is '0', quality checking will not be enforced. A value + of '1' indicates that the server will check the quality, and if the + server is unable to check it (due to a hashed password or other + reasons) it will be accepted. A value of '2' indicates that the + server will check the quality, and if the server is unable to verify + it, it will return an error refusing the password. + + ( 1.3.6.1.4.1.42.2.27.8.1.5 + NAME 'pwdCheckQuality' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.6 pwdMinLength + + When quality checking is enabled, this attribute holds the minimum + number of characters that must be used in a password. If this + attribute is not present, no minimum password length will be + enforced. If the server is unable to check the length (due to a + hashed password or otherwise), the server will, depending on the + value of the pwdCheckQuality attribute, either accept the password + without checking it ('0' or '1') or refuse it ('2'). + + ( 1.3.6.1.4.1.42.2.27.8.1.6 + NAME 'pwdMinLength' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.7 pwdExpireWarning + + This attribute specifies the maximum number of seconds before a + password is due to expire that expiration warning messages will be + returned to an authenticating user. + + If this attribute is not present, or if the value is 0 no warnings + will be returned. If not 0, the value must be smaller than the value + of the pwdMaxAge attribute. + + ( 1.3.6.1.4.1.42.2.27.8.1.7 + NAME 'pwdExpireWarning' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.8 pwdGraceAuthNLimit + + This attribute specifies the number of times an expired password can + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 13] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - This attribute contains the time when the password expiration - warning was first sent to the client. The password will expire in - the pwdExpireWarning time. - - ( 1.3.6.1.4.1.42.2.27.8.1.18 - NAME 'pwdExpirationWarned' - DESC 'The time the user was first warned about the coming - expiration of the password' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - SINGLE-VALUE - USAGE directoryOperation ) - -4.3.5. pwdFailureTime - - This attribute holds the timestamps of the consecutive - authentication failures. - - ( 1.3.6.1.4.1.42.2.27.8.1.19 - NAME 'pwdFailureTime' - DESC 'The timestamps of the last consecutive authentication - failures' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch - USAGE directoryOperation ) - - -4.3.6. pwdHistory - - This attribute holds a history of previously used passwords. - - Values of this attribute are transmitted in string format as given - by the following ABNF: - - pwdHistory = time "#" syntaxOID "#" length "#" data - - time = - - syntaxOID = numericoid ; the string representation of the - ; dotted-decimal OID that defines the - ; syntax used to store the password. - ; numericoid is described in 4.1 of - ; [RFC2252]. - - length = numericstring ; the number of octets in data. - ; numericstring is described in 4.1 of - - -Behera, et. al. Expires August 15, 2004 Page 13 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + be used to authenticate. If this attribute is not present or if the + value is 0, authentication will fail. + + ( 1.3.6.1.4.1.42.2.27.8.1.8 + NAME 'pwdGraceAuthNLimit' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.9 pwdLockout + + This attribute indicates, when its value is "TRUE", that the password + may not be used to authenticate after a specified number of + consecutive failed bind attempts. The maximum number of consecutive + failed bind attempts is specified in pwdMaxFailure. + + If this attribute is not present, or if the value is "FALSE", the + password may be used to authenticate when the number of failed bind + attempts has been reached. + + ( 1.3.6.1.4.1.42.2.27.8.1.9 + NAME 'pwdLockout' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + +5.2.10 pwdLockoutDuration + + This attribute holds the number of seconds that the password cannot + be used to authenticate due to too many failed bind attempts. If + this attribute is not present, or if the value is 0 the password + cannot be used to authenticate until reset by a password + administrator. + + ( 1.3.6.1.4.1.42.2.27.8.1.10 + NAME 'pwdLockoutDuration' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.11 pwdMaxFailure + + This attribute specifies the number of consecutive failed bind + attempts after which the password may not be used to authenticate. + If this attribute is not present, or if the value is 0, this policy + is not checked, and the value of pwdLockout will be ignored. + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 14] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - ; [RFC2252]. - - data = . - - This format allows the server to store, and transmit a history of - passwords that have been used. In order for equality matching to - function properly, the time field needs to adhere to a consistent - format. For this purpose, the time field MUST be in GMT format. - - ( 1.3.6.1.4.1.42.2.27.8.1.20 - 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) - -4.3.7. pwdGraceUseTime - - This attribute holds the timestamps of grace login once a password - has expired. - - ( 1.3.6.1.4.1.42.2.27.8.1.21 - NAME 'pwdGraceUseTime' - DESC 'The timestamps of the grace login once the password has - expired' - SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 - EQUALITY generalizedTimeMatch - - USAGE directoryOperation) - -4.3.8. pwdReset - - This attribute holds a flag to indicate (when TRUE) that the - password has been reset and therefore must be changed by the user on - first authentication. - - ( 1.3.6.1.4.1.42.2.27.8.1.22 - NAME 'pwdReset' - DESC 'The indication that the password has been reset' - EQUALITY booleanMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 - SINGLE-VALUE - USAGE directoryOperation) - -4.3.9. pwdPolicySubentry - - This attribute points to the pwdPolicy subentry in effect for this - object. - - -Behera, et. al. Expires August 15, 2004 Page 14 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + ( 1.3.6.1.4.1.42.2.27.8.1.11 + NAME 'pwdMaxFailure' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.12 pwdFailureCountInterval + + This attribute holds the number of seconds after which the password + failures are purged from the failure counter, even though no + successful authentication occurred. + + If this attribute is not present, or if its value is 0, the failure + counter is only reset by a successful authentication. + + ( 1.3.6.1.4.1.42.2.27.8.1.12 + NAME 'pwdFailureCountInterval' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +5.2.13 pwdMustChange + + This attribute specifies with a value of "TRUE" that users must + change their passwords when they first bind to the directory after a + password is set or reset by a password administrator. If this + attribute is not present, or if the value is "FALSE", users are not + required to change their password upon binding after the password + administrator sets or resets the password. This attribute is not set + due to any actions specified by this document, it is typically set by + a password administrator after resetting a user's password. + + ( 1.3.6.1.4.1.42.2.27.8.1.13 + NAME 'pwdMustChange' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + +5.2.14 pwdAllowUserChange + + This attribute indicates whether users can change their own + passwords, although the change operation is still subject to access + control. If this attribute is not present, a value of "TRUE" is + assumed. This attribute is intended to be used in the absense of an + access control mechanism. + + ( 1.3.6.1.4.1.42.2.27.8.1.14 + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 15] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - ( 1.3.6.1.4.1.42.2.27.8.1.23 - NAME 'pwdPolicySubentry' - DESC 'The pwdPolicy subentry in effect for this object' - EQUALITY distinguishedNameMatch - SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 - SINGLE-VALUE - USAGE directoryOperation) - -5. Controls used for Password Policy - - This section details the controls used while enforcing password - policy. A request control is defined that is sent by a client with a - request operation in order to elicit a response control. The - response control contains various warnings and errors associated - with password policy. - -5.1. Request Control - - This control MAY be sent with any LDAP request message in order to - convey to the server that this client is aware of, and can process - the response control described in this document. When a server - receives this control, it will return the response control when - appropriate and with the proper data. - - The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality - MUST be FALSE. There is no controlValue. - - passwordPolicyRequest - - controlType: 1.3.6.1.4.1.42.2.27.8.5.1 - criticality: FALSE - controlValue: None - -5.2. Response Control - - If the client has sent a passwordPolicyRequest control, the server - sends this control with the following operation responses: - bindResponse, modifyResponse, addResponse, compareResponse and - possibly extendedResponse, to inform of various conditions, and MAY - be sent with other operations (in the case of the changeAfterReset - error). - - passwordPolicyResponse - - controlType: 1.3.6.1.4.1.42.2.27.8.5.1 - criticality: FALSE - controlValue: an OCTET STRING, whose value is the BER encoding of the - following type: - - -Behera, et. al. Expires August 15, 2004 Page 15 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + NAME 'pwdAllowUserChange' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + +5.2.15 pwdSafeModify + + This attribute specifies whether or not the existing password must be + sent along with the new password when being changed. If this + attribute is not present, a "FALSE" value is assumed. + + ( 1.3.6.1.4.1.42.2.27.8.1.15 + NAME 'pwdSafeModify' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + +5.3 Attribute Types for Password Policy State Information + + Password policy state information must be maintained for each user. + The information is located in each user entry as a set of operational + attributes. These operational attributes are: pwdChangedTime, + pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime, + pwdReset, pwdPolicySubEntry. + +5.3.1 Password Policy State Attribute Option + + Since the password policy could apply to several attributes used to + store passwords, each of the above operational attributes must have + an option to specify which pwdAttribute it applies to. The password + policy option is defined as the following: + + pwd- + + where passwordAttribute a string following the OID syntax + (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor + (short name) MUST be used. + + For example, if the pwdPolicy object has for pwdAttribute + "userPassword" then the pwdChangedTime operational attribute, in a + user entry, will be: + + pwdChangedTime;pwd-userPassword: 20000103121520Z + + This attribute option follows sub-typing semantics. If a client + requests a password policy state attribute to be returned in a search + operation, and does not specify an option, all subtypes of that + policy state attribute are returned. + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 16] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - PasswordPolicyResponseValue ::= SEQUENCE { - warning [0] CHOICE { - timeBeforeExpiration [0] INTEGER (0 .. maxInt), - graceLoginsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL - error [1] ENUMERATED { - passwordExpired (0), - accountLocked (1), - changeAfterReset (2), - passwordModNotAllowed (3), - mustSupplyOldPassword (4), - insufficientPasswordQuality (5), - passwordTooShort (6), - passwordTooYoung (7), - passwordInHistory (8) } OPTIONAL } - - The timeBeforeExpiration warning specifies the number of seconds - before a password will expire. The graceLoginsRemaining warning - specifies the remaining number of times a user will be allowed to - authenticate with an expired password. The passwordExpired error - signifies that the password has expired and must be reset. The - changeAfterReset error signifies that the password must be changed - before the user will be allowed to perform any operation other than - bind and modify. The passwordModNotAllowed error is set when a user - is restricted from changing her password. The - insufficientPasswordQuality error is set when a password doesn't - pass quality checking. The passwordTooYoung error is set if the age - of the password to be modified is not yet old enough. - - Typically, only either a warning or an error will be encoded though - there may be exceptions. For example, if the user is required to - change a password after the administrator set it, and the password - will expire in a short amount of time, the control may include the - timeBeforeExpiration warning and the changeAfterReset error. - - -6. Server Implementation by LDAP operation - - The following sections contain detailed instructions that refer to - attributes of the pwdPolicy object class. When doing so, the - attribute of the pwdPolicy object that governs the entry being - discussed is implied. - - The server SHOULD enforce that the password attribute subject to a - password policy as defined in this document, contains one and only - one password value. - - The scenarios in the following operations assume that the client has - attached a passwordPolicyRequest control to the request message of - - -Behera, et. al. Expires August 15, 2004 Page 16 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +5.3.2 pwdChangedTime + + This attribute specifies the last time the entry's password was + changed. This is used by the password expiration policy. If this + attribute does not exist, the password will never expire. + + ( 1.3.6.1.4.1.42.2.27.8.1.16 + NAME 'pwdChangedTime' + DESC 'The time the password was last changed' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE + USAGE directoryOperation ) + +5.3.3 pwdAccountLockedTime + + This attribute holds the time that the user's account was locked. A + locked account means that the password may no longer be used to + authenticate. A 000001010000Z value means that the account has been + locked permanently, and that only a password administrator can unlock + the account. + + ( 1.3.6.1.4.1.42.2.27.8.1.17 + NAME 'pwdAccountLockedTime' + DESC 'The time an user account was locked' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE + USAGE directoryOperation ) + +5.3.4 pwdFailureTime + + This attribute holds the timestamps of the consecutive authentication + failures. + + ( 1.3.6.1.4.1.42.2.27.8.1.19 + NAME 'pwdFailureTime' + DESC 'The timestamps of the last consecutive authentication + failures' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + USAGE directoryOperation ) + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 17] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - the operation. In the event that the passwordPolicyRequest control - was not sent, no passwordPolicyRequest control is returned. All - other instructions remain the same. - - -6.1. Bind Operation - - When processing a bind request, the server MUST perform the - following steps: - - 1. Check for a locked account: - - If the value of the pwdAccountLockedTime attribute is 0, or if - the current time is less than the value of the - pwdAccountLockedTime attribute added to the value of the - pwdLockoutDuration, the account is locked. - - If the account is locked, the server MUST send a bindResponse to - the client with the resultCode: unwillingToPerform (53), and MUST - include the passwordPolicyResponse in the controls field of the - bindResponse message with the error: accountLocked (1). - - If the account is not locked, the server MUST proceed with the - bind operation. - - 2. Check the result of the bind operation: - - If the bind operation succeeds with authentication, the server - MUST do the following: - - A. Delete the pwdFailureTime attribute. - - B. Check whether the password must be changed now. - - If the pwdMustChange attribute is set to TRUE, and if the - pwdReset attribute is set to TRUE, the password must be - changed now. - - If the password must be changed now, the server MUST send a - bindResponse to the client with the resultCode: success (0), - and MUST include the passwordPolicyResponse in the controls - field of the bindResponse message with the warning: - changeAfterReset specified. - The server MUST then disallow all operations issued by this - user except modify password, bind, unbind, abandon and - StartTLS extended operation. - - If the password does not need to be changed now, the operation - proceeds. - - -Behera, et. al. Expires August 15, 2004 Page 17 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +5.3.5 pwdHistory + + This attribute holds a history of previously used passwords. Values + of this attribute are transmitted in string format as given by the + following ABNF: + + pwdHistory = time "#" syntaxOID "#" length "#" data + + time = + + syntaxOID = numericoid ; the string representation of the + ; dotted-decimal OID that defines the + ; syntax used to store the password. + ; numericoid is described in 4.1 + ; of [RFC2252]. + + length = numericstring ; the number of octets in data. + ; numericstring is described in 4.1 + ; of [RFC2252]. + + data = . + + This format allows the server to store, and transmit a history of + passwords that have been used. In order for equality matching to + function properly, the time field needs to adhere to a consistent + format. For this purpose, the time field MUST be in GMT format. + + ( 1.3.6.1.4.1.42.2.27.8.1.20 + NAME 'pwdHistory' + DESC 'The history of user s passwords' + EQUALITY octetStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + USAGE directoryOperation ) + +5.3.6 pwdGraceUseTime + + This attribute holds the timestamps of grace authentications after a + password has expired. + + ( 1.3.6.1.4.1.42.2.27.8.1.21 + NAME 'pwdGraceUseTime' + DESC 'The timestamps of the grace authentication after the + password has expired' + EQUALITY generalizedTimeMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 18] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - C. Check for password expiration - - The password has expired when either of the following - conditions is met: - - - If the value of the pwdExpireWarning attribute is 0, the - server subtracts the current time from the time stored in - pwdChangedTime to arrive at the password's age. If the age - is greater than the value in the pwdMaxAge attribute, the - password has expired. - - - If the value of the pwdExpireWarning attribute is non- - zero, and the pwdExpirationWarned attribute is present and - has a time value, the server subtracts the current time - from the time stored in the pwdExpirationWarned to arrive - at the first warning age. If the age is greater than the - value in the pwdExpireWarning attribute, the password has - expired. - - If the password has expired, the server MUST check for - remaining grace logins. - - If the pwdGraceUseTime attribute is present, the server - MUST count the number of values in that attribute and - subtract it from the pwdGraceLoginLimit. A positive result - specifies the number of remaining grace logins. - - If there are remaining grace logins, the server MUST add a - new value with the current time in pwdGraceUseTime. Then - it MUST send a bindResponse with the resultCode: success - (0), and MUST include the passwordPolicyResponse in the - controls field of the bindResponse message with the - warning: graceLoginsRemaining choice set to the number of - grace logins left. - - If there are no remaining grace logins, the server MUST - send a bindResponse with the resultCode: - invalidCredentials (49), and MUST include the - passwordPolicyResponse in the controls field of the - bindResponse message with the error: passwordExpired (0) - set. - - If the password has not expired, execution continues. - - D. Calculates whether the time before expiration warning should - be sent. - - - - -Behera, et. al. Expires August 15, 2004 Page 18 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + USAGE directoryOperation ) + +5.3.7 pwdReset + + This attribute holds a flag to indicate (when TRUE) that the password + has been updated by the password administrator and must be changed by + the user on first authentication. + + ( 1.3.6.1.4.1.42.2.27.8.1.22 + NAME 'pwdReset' + DESC 'The indication that the password has been reset' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE + USAGE directoryOperation ) + +5.3.8 pwdPolicySubentry + + This attribute points to the pwdPolicy subentry in effect for this + object. + + ( 1.3.6.1.4.1.42.2.27.8.1.23 + NAME 'pwdPolicySubentry' + DESC 'The pwdPolicy subentry in effect for this object' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + USAGE directoryOperation ) + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 19] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - If the pwdExpireWarning attribute is present and contains a - value, the server MUST perform the following steps. - - If the pwdExpirationWarned attribute is present and has a - time value, the warning time is the value of the - pwdExpirationWarned attribute plus the value of the - pwdExpireWarning attribute minus the current time. - - If the pwdExpirationWarned attribute is not present, the - server MUST subtract the current time from the time stored - in pwdChangedTime to arrive at the password's age. If the - age is greater than the value of the pwdMaxAge attribute - minus the value of the pwdExpireWarning attribute, the - server MUST set the current time as the value of the - pwdExpirationWarned attribute, and the warning time is the - value of pwdMaxAge minus the password's age. - - If the warning time is a positive number, the server MUST - send a bindResponse with the resultCode: success (0), and - MUST include the passwordPolicyResponse in the controls - field of the bindResponse message with the warning: - timeBeforeExiration set to the value as described above. - - If the warning time is zero, or wasn't calculated, the - server MUST send a bindResponse with the resultCode: - success (0), and MUST include the passwordPolicyResponse - with nothing in the SEQUENCE. - - If the pwdExpireWarning attribute is not present, the server - MUST send a bindResponse with the resultCode: success (0), - and MUST include the passwordPolicyResponse with nothing in - the SEQUENCE. - - If the bind operation fails authentication due to invalid - credentials, the server MUST do the following: - - A. Add the current time as a value of the pwdFailureTime - attribute. - - B. If the pwdLockout attribute is TRUE, the server MUST also do - the following: - - Count the number of values in the pwdFailureTime attribute - that are younger than pwdFailureCountInterval. - - If the number of these failures is greater or equal to the - pwdMaxFailure attribute, the server MUST lock the account - by setting the value of the pwdAccountLockedTime attribute - to the current time. After locking the account, the server - - -Behera, et. al. Expires August 15, 2004 Page 19 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +6. Controls used for Password Policy + + This section details the controls used while enforcing password + policy. A request control is defined that is sent by a client with a + request operation in order to elicit a response control. The + response control contains various warnings and errors associated with + password policy. + +6.1 Request Control + + This control MAY be sent with any LDAP request message in order to + convey to the server that this client is aware of, and can process + the response control described in this document. When a server + receives this control, it will return the response control when + appropriate and with the proper data. + + The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may + be TRUE or FALSE. There is no controlValue. + +6.2 Response Control + + If the client has sent a passwordPolicyRequest control, the server + (when solicited by the inclusion of the request control) sends this + control with the following operation responses: bindResponse, + modifyResponse, addResponse, compareResponse and possibly + extendedResponse, to inform of various conditions, and MAY be sent + with other operations (in the case of the changeAfterReset error). + The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is + the BER encoding of the following type: + + PasswordPolicyResponseValue ::= SEQUENCE { + warning [0] CHOICE { + timeBeforeExpiration [0] INTEGER (0 .. maxInt), + graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, + error [1] ENUMERATED { + passwordExpired (0), + accountLocked (1), + changeAfterReset (2), + passwordModNotAllowed (3), + mustSupplyOldPassword (4), + insufficientPasswordQuality (5), + passwordTooShort (6), + passwordTooYoung (7), + passwordInHistory (8) } OPTIONAL } + + The timeBeforeExpiration warning specifies the number of seconds + before a password will expire. The graceAuthNsRemaining warning + specifies the remaining number of times a user will be allowed to + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 20] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - MUST send a bindResponse to the client with the - resultCode: unwillingToPerform (53), and MUST include the - passwordPolicyResponse in the controls field of the - bindResponse message with the error: accountLocked (1). - - If the number of failures is less than the pwdMaxFailure - attribute, operation proceeds. - - C. Failure times that are old by more than - pwdFailureCountInterval are purged from the pwdFailureTime - attribute. - - - -6.2. Modify Password Operation - - Because the password is stored in an attribute, the modify operation - may be used to create or update a password. But some alternate - mechanisms have been defined or may be defined, such as the LDAP - Password Modify Extended Operation [RFC-3062]. - - - - - While processing a password modification, the server MUST perform - the following steps: - - 1. Check the pwdSafeModify attribute. If set to TRUE, the server - MUST ensure that the modify password operation included the - user's existing password. When the LDAP modify operation is used - to modify a password, this is done by specifying both a delete - action and an add or replace action, where the delete action is - first, and specifies the existing password, and the add or - replace action specifies the new password. Other password modify - operations SHOULD employ a similar mechanism. Otherwise this - policy will fail. - - If the existing password is not specified, the server MUST NOT - process the operation and MUST send the appropriate response - message to the client with the resultCode: unwillingToPerform - (53), and MUST include the passwordPolicyResponse in the controls - field of the response message with the error: - mustSupplyOldPassword (4). - - - 2. Check the value of the pwdMustChange attribute. If TRUE, the - server MUST check the pwdReset attribute in the user's entry, to - see if a directory administrator has reset the password. If so, - it MUST ensure that the modify password operation contains no - - -Behera, et. al. Expires August 15, 2004 Page 20 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + authenticate with an expired password. The passwordExpired error + signifies that the password has expired and must be reset. The + changeAfterReset error signifies that the password must be changed + before the user will be allowed to perform any operation other than + bind and modify. The passwordModNotAllowed error is set when a user + is restricted from changing her password. The + insufficientPasswordQuality error is set when a password doesn't pass + quality checking. The passwordTooYoung error is set if the age of + the password to be modified is not yet old enough. + + Typically, only either a warning or an error will be encoded though + there may be exceptions. For example, if the user is required to + change a password after the password administrator set it, and the + password will expire in a short amount of time, the control may + include the timeBeforeExpiration warning and the changeAfterReset + error. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 21] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - modifications other than the modification of the password - attribute. If other modifications exist, the server MUST send a - response message to the client with the resultCode: - unwillingToPerform (53), and MUST include the - passwordPolicyResponse in the controls field of the response - message with the error: changeAfterReset (2). - - 3. Check to see whether the bound identity has sufficient rights to - modify the password. If the bound identity is a user changing its - own password, this MAY be done by checking the pwdAllowUserChange - attribute or using an access control mechanism. The determination - of this is implementation specific. If the user is not allowed to - change her password, the server MUST send a response message to - the client with the resultCode: unwillingToPerform (53), and MUST - include the passwordPolicyResponse in the controls field of the - response message with the error: passwordModNotAllowed (3). - - 4. Check the value of the pwdMinAge attribute. If it is set to a - non-zero value, the server MUST subtract the current time from - the value of the pwdChangedTime attribute to arrive at the - password's age. If the password's age is less than the value of - the pwdMinAge attribute, the password is too young to modify. In - this case, the server MUST send a response message to the client - with the resultCode: constraintViolation (19), and MUST include - the passwordPolicyResponse in the controls field of the response - message with the error: passwordTooYoung (7). - - 5. Check the value of the pwdCheckQuality attribute. - - If the value is non-zero, The server: - - A. MUST ensure that the password meets the quality criteria - enforced by the server. This enforcement is implementation - specific. - - If the server is unable to check the quality (due to a hashed - password or otherwise), the value of pwdCheckQuality is - evaluated. If the value is 1, operation MUST continue. If the - value is 2, the server MUST send a response message to the - client with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the response message with the error: - insufficientPasswordQuality (5). - - If the server is able to check the password quality, and the - check fails, the server MUST send a response message to the - client with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - - - -Behera, et. al. Expires August 15, 2004 Page 21 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +7. Policy Decision Points + + Following are a number of procedures used to make policy decisions. + These procedures are typically performed by the server while + processing an operation. + + The following sections contain detailed instructions that refer to + attributes of the pwdPolicy object class. When doing so, the + attribute of the pwdPolicy object that governs the entry being + discussed is implied. + +7.1 Locked Account Check + + A status of true is returned to indicate that the account is locked + if any of these conditions are met: + + o The value of the pwdAccountLockedTime attribute is 000001010000Z. + o The current time is less than the value of the + pwdAccountLockedTime attribute added to the value of the + pwdLockoutDuration. + + Otherwise a status of false is returned. + +7.2 Password Must be Changed Now Check + + A status of true is returned to indicate that the account is locked + if all of these conditions are met: + + The pwdMustChange attribute is set to TRUE. + The pwdReset attribute is set to TRUE. + + Otherwise a status of false is returned. + +7.3 Password Expiration Check + + A status of true is returned indicating that the password has expired + if the value of the pwdExpireWarning attribute is 0, and the current + time minus the value of pwdChangedTime is greater than the value of + the pwdMaxAge. + + Otherwise, a status of false is returned. + +7.4 Remaining Grace AuthN Check + + If the pwdGraceUseTime attribute is present, the number of values in + that attribute subtracted from the value of pwdGraceAuthNLimit is + returned. Otherwise zero is returned. A positive result specifies + the number of remaining grace authentications. + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 22] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - the response message with the error: - insufficientPasswordQuality (5). - - B. MUST check the value of the pwdMinLength attribute. If the - value is non-zero, it MUST ensure that the new password is of - at least the minimum length. - - If the server is unable to check the length (due to a hashed - password or otherwise), the value of pwdCheckQuality is - evaluated. If the value is 1, operation MUST continue. If the - value is 2, the server MUST send a response message to the - client with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the response message with the error: passwordTooShort (6). - - If the server is able to check the password length, and the - check fails, the server MUST send a response message to the - client with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the response message with the error: passwordTooShort (6). - - 6. Check the value of the pwdInHistory attribute. If the value is - non-zero, the server MUST check whether this password exists in - the entry's pwdHistory attribute or in the current password - attribute. If the password does exist in the pwdHistory attribute - or in the current password attribute, the server MUST send a - response message to the client with the resultCode: - constraintViolation (19), and MUST include the - passwordPolicyResponse in the controls field of the response - message with the error: passwordInHistory (8). - - If the steps have completed without causing an error condition, the - server MUST follow the following steps in order to update the - necessary password policy state attributes: - - 7. Check the value of the pwdMaxAge attribute. If the value is non- - zero, or if the value of the pwdMinAge attribute is non-zero, the - server MUST update the pwdChangedTime attribute on the entry to - the current time. - - 8. If the value of the pwdInHistory attribute is non-zero, the - server MUST add the previous password to the pwdHistory - attribute. If the number of attributes held in the pwdHistory - attribute exceeds the value of pwdInHistory, the server MUST - remove the oldest excess passwords. - - 9. Remove the pwdFailureTime, pwdReset, pwdGraceUseTime and - pwdExpirationWarned attributes from the user's entry if they - - - -Behera, et. al. Expires August 15, 2004 Page 22 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +7.5 Time Before Expiration Check + + If the pwdExpireWarning attribute is not present a zero status is + returned. Otherwise the following steps are followed: + + Subtract the time stored in pwdChangedTime from the current time to + arrive at the password's age. If the password's age is greater than + than the value of the pwdMaxAge attribute, a zero status is returned. + Subtract the value of the pwdExpireWarning attribute from the value + of the pwdMaxAge attribute to arrive at the warning age. If the + password's age is equal to or greater than the warning age, the value + of pwdMaxAge minus the password's age is returned. + +7.6 Intruder Detection Check + + A status of true indicating that an intruder has been detected is + returned if the following conditions are met: + + The pwdLockout attribute is TRUE. + The number of values in the pwdFailureTime attribute that are + younger than pwdFailureCountInterval is greater or equal to the + pwdMaxFailure attribute. + + Otherwise a status of false is returned. + + While performing this check, values of pwdFailureTime that are old by + more than pwdFailureCountInterval are purged and not counted. + +7.7 Password Too Young Check + + A status of true indicating that not enough time has passed since the + password was last updated is returned if: + + The value of pwdMinAge is non-zero and pwdChangedTime is present. + The value of pwdMinAge is greater than the current time minus the + value of pwdChangedTime. + + Otherwise a false status is returned. + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 23] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - exist. - - The server MUST then apply the modify password operation. - -6.3. Add Operation - - The password MAY be set during an Add operation. If it is, the - server MUST perform the following steps while processing the add - operation. Note that these are essentially duplicates of steps 3, 5 - and 7 from Section 6.2 with the exception that pwdAllowUserChange is - not checked. - - 1. Check to see whether the bound identity has sufficient rights to - modify the password. This MAY be done by the use of an access - control mechanism. If the user is not allowed to add this - password, the server MUST send an addResponse to the client with - the resultCode: unwillingToPerform (53), and MUST include the - passwordPolicyResponse in the controls field of the addResponse - message with the error: passwordModNotAllowed (3). - - 2. Check the value of the pwdCheckQuality attribute. - - If the value is non-zero, The server: - - A. MUST ensure that the password meets the quality criteria - enforced by the server. This enforcement is implementation - specific. - - If the server is unable to check the quality (due to a hashed - password or otherwise), the value of pwdCheckQuality MUST be - evaluated. If the value is 1, operation MUST continue. If the - value is 2, the server MUST send an addResponse to the client - with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the addResponse message with the error: - insufficientPasswordQuality (5). - - If the server is able to check the password quality, and the - check fails, the server MUST send an addResponse to the client - with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the addResponse message with the error: - insufficientPasswordQuality (5). - - B. MUST check the value of the pwdMinLength attribute. If the - value is non-zero, it MUST ensure that the new password is of - at least the minimum length. - - - - -Behera, et. al. Expires August 15, 2004 Page 23 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +8. Server Policy Enforcement Points + + The server SHOULD enforce that the password attribute subject to a + password policy as defined in this document, contains one and only + one password value. + + The scenarios in the following operations assume that the client has + attached a passwordPolicyRequest control to the request message of + the operation. In the event that the passwordPolicyRequest control + was not sent, no passwordPolicyResponse control is returned. All + other instructions remain the same. + + For successfuly completed operations, unless otherwise stated, no + passwordPolicyResponse control is returned. + +8.1 Password-based Authentication + + This section contains the policy enforcement rules and policy data + updates used while validating a password. Operations that validate + passwords include, but are not limited to, the Bind operation where + the simple choice specifies a password, and the compare operation + where the attribute being compared holds a password. + +8.1.1 Fail if the account is locked + + If the account is locked as specified in Section 7.1, the server + fails the operation with an appropriate resultCode (i.e. + invalidCredentials (49) in the case of a bind operation, compareFalse + (5) in the case of a compare operation, etc.). The server MAY set + the error: accountLocked (1) in the passwordPolicyResponse in the + controls field of the message. + +8.1.2 AuthN Passed Procedures + + If the authentication process indicates that the password validated, + these procedures are followed in order: + +8.1.2.1 Policy state updates + + Delete the pwdFailureTime and pwdAccountLockedTime attributes. + +8.1.2.2 Password must be changed now + + If the decision in Section 7.2 returns true, the server sends to the + client a response with an appropriate successful resultCode (i.e. + success (0), compareTrue (6), etc.), and includes the + passwordPolicyResponse in the controls field of the bindResponse + message with the warning: changeAfterReset specified. + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 24] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - If the server is unable to check the length (due to a hashed - password or otherwise), the value of pwdCheckQuality MUST be - evaluated. If the value is 1, operation MUST continue. If the - value is 2, the server MUST send an addResponse to the client - with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the addResponse message with the error: passwordTooShort (6). - - If the server is able to check the password length, and the - check fails, the server MUST send an addResponse to the client - with the resultCode: constraintViolation (19), and MUST - include the passwordPolicyResponse in the controls field of - the addResponse message with the error: passwordTooShort (6). - - If the steps above have completed without causing an error - condition, the server MUST follow the steps below in order to update - the necessary password policy state attributes. - - 3. Check the value of the pwdMaxAge attribute. If the value is non- - zero, or if the value of the pwdMinAge attribute is non-zero, the - server MUST update the pwdChangedTime attribute on the entry to - the current time. - -6.4. Compare Operation - - The compare operation MAY be used to compare a password. This might - be performed when a client wishes to verify that user's supplied - password is correct. An example of this is an LDAP HTTP - authentication redirector. It may be desirable to use this rather - than performing a bind operation in order to reduce possible - overhead involved in performing a bind. Access Controls SHOULD be - used to restrict this comparison from being made. - - If a server supports this behavior, it MUST comply with the - following. Otherwise the password policy described in this document - may be circumvented. - - While comparing password attributes, the server MUST perform the - following steps: - - 1. Check for a locked account: - - If the value of the pwdAccountLockedTime attribute is 0, or if - the current time is less than the value of the - pwdAccountLockedTime attribute added to the value of the - pwdLockoutDuration, the account is locked. - - If the account is locked, the server MUST send a compareResponse - to the client with the resultCode: compareFalse (5), and MUST - - -Behera, et. al. Expires August 15, 2004 Page 24 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + For bind, the server MUST then disallow all operations issued by this + user except modify password, bind, unbind, abandon and StartTLS + extended operation. + +8.1.2.3 Expired password + + If the password has expired as per Section 7.3, the server either + returns a success or failure based on the state of grace + authentications. + +8.1.2.3.1 Remaining Grace Authentications + + If there are remaining grace authentications as per Section 7.4, the + server adds a new value with the current time in pwdGraceUseTime. + Then it sends to the client a response with an appropriate successful + resultCode (i.e. success (0), compareTrue (6), etc.), and includes + the passwordPolicyResponse in the controls field of the response + message with the warning: graceAuthNsRemaining choice set to the + number of grace authentications left. + + Implementor's note: The system time of the host machine may be more + granular than is needed to ensure unique values of this attribute. + It is recommended that a mechanism is used to ensure unique + generalized time values. The fractional seconds field may be used + for this purpose. + +8.1.2.3.2 No Remaining Grace Authentications + + If there are no remaining grace authentications, the server fails the + operation with an appropriate resultCode (invalidCredentials (49), + compareFalse (5), etc.), and includes the passwordPolicyResponse in + the controls field of the bindResponse message with the error: + passwordExpired (0) set. + +8.1.2.4 Expiration Warning + + If the result of Section 7.5 is a positive number, the server sends + to the client a response with an appropriate successful resultCode + (i.e. success (0), compareTrue (6), etc.), and includes the + passwordPolicyResponse in the controls field of the bindResponse + message with the warning: timeBeforeExiration set to the value as + described above. Otherwise, the server sends a successful response, + and omits the passwordPolicyResponse. + +8.1.2.5 AuthN Failed Procedures + + If the authentication process indicates that the password failed + validation due to invalid credentials, these procedures are followed: + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 25] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - include the passwordPolicyResponse in the controls field of the - compareResponse message with the error: accountLocked (1). - - If the account is not locked, the server MUST proceed with the - compare operation. - - 2. If Access Controls permit, the server MUST proceed with compare - operation and MUST check the result. - - If the result of the compare operation is true, the server MUST - do the following: - - A. Delete the pwdFailureTime attribute. - - B. Check for password expiration - - The password has expired when either of the following - conditions is met: - - - If the value of the pwdExpireWarning attribute is 0, the - server MUST subtract the current time from the time stored - in pwdChangedTime to arrive at the password's age. If the - age is greater than the value in the pwdMaxAge attribute, - the password has expired. - - - If the value of the pwdExpireWarning attribute is non- - zero, and the pwdExpirationWarned attribute is present and - has a time value, the server MUST subtract the current - time from the time stored in the pwdExpirationWarned to - arrive at the first warning age. If the age is greater - than the value in the pwdExpireWarning attribute, the - password has expired. - - If the password has expired, the server MUST check for - remaining grace logins. - - If the pwdGraceUseTime attribute is present, the server - MUST count the number of values in that attribute and MUST - subtract it from the pwdGraceLoginLimit. A positive result - specifies the number of remaining grace logins. - - If there are remaining grace logins, the server MUST add a - new value with the current time in pwdGraceUseTime. Then - it MUST send a compareResponse with the resultCode: - compareTrue (6), and MUST include the - passwordPolicyResponse in the controls field of the - compareResponse message with the warning: - graceLoginsRemaining choice set to the number of grace - logins left. - - -Behera, et. al. Expires August 15, 2004 Page 25 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +8.1.2.5.1 Policy state update + + Add the current time as a value of the pwdFailureTime attribute. + + Implementor's note: The system time of the host machine may be more + granular than is needed to ensure unique values of this attribute. + It is recommended that a mechanism is used to ensure unique + generalized time values. The fractional seconds field may be used + for this purpose. + +8.1.2.5.2 Lock on intruder detection + + If the check in Section 7.6 returns a true state, the server locks + the account by setting the value of the pwdAccountLockedTime + attribute to the current time. After locking the account, the server + fails the operation with an appropriate resultCode + (invalidCredentials (49), compareFalse (5), etc.), and includes the + passwordPolicyResponse in the controls field of the message with the + error: accountLocked (1). + +8.2 Password Update Operations + + Because the password is stored in an attribute, various operations + (like add and modify) may be used to create or update a password. + But some alternate mechanisms have been defined or may be defined, + such as the LDAP Password Modify Extended Operation [RFC3062]. + + While processing a password update, the server performs the following + steps: + +8.2.1 Safe Modification + + If pwdSafeModify is set to TRUE and if there is an existing password + value, the server ensures that the password update operation includes + the user's existing password. + + When the LDAP modify operation is used to modify a password, this is + done by specifying both a delete action and an add or replace action, + where the delete action is first, and specifies the existing + password, and the add or replace action specifies the new password. + Other password update operations SHOULD employ a similar mechanism. + Otherwise this policy will fail. + + If the existing password is not specified, the server does not + process the operation and sends the appropriate response message to + the client with the resultCode: insufficientAccessRights (50), and + includes the passwordPolicyResponse in the controls field of the + response message with the error: mustSupplyOldPassword (4). + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 26] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - If there are no remaining grace logins, the server MUST - send a compareResponse with the resultCode: compareFalse - (5), and MUST include the passwordPolicyResponse in the - controls field of the compareResponse message with the - error: passwordExpired (0) set. - - If the password has not expired, execution MUST continue. - - C. Calculate whether the time before expiration warning should be - sent. - - If the pwdExpireWarning attribute is present and contains a - value, the server MUST perform the following steps. - - If the pwdExpirationWarned attribute is present and has a - time value, the warning time is the value of the - pwdExpirationWarned attribute plus the value of the - pwdExpireWarning attribute minus the current time. - - If the pwdExpirationWarned attribute is not present, the - server MUST subtract the current time from the time stored - in pwdChangedTime to arrive at the password's age. If the - age is greater than the value of the pwdMaxAge attribute - minus the value of the pwdExpireWarning attribute, the - server MUST set the current time as the value of the - pwdExpirationWarned attribute, and the warning time is the - value of pwdMaxAge minus the password's age. - - If the warning time is a positive number, the server MUST - send a compareResponse with the resultCode: compareTrue - (6), and MUST include the passwordPolicyResponse in the - controls field of the compareResponse message with the - warning: timeBeforeExiration set to the value as described - above. - - If the warning time is zero, or wasn't calculated, the - server MUST send a compareResponse with the resultCode: - compareTrue (6), and MUST include the - passwordPolicyResponse with nothing in the SEQUENCE. - - If the pwdExpireWarning attribute is not present, the server - MUST send a compareResponse with the resultCode: compareTrue - (6), and MUST include the passwordPolicyResponse with nothing - in the SEQUENCE. - - If the result of the compare operation is false, the server MUST - do the following: - - - -Behera, et. al. Expires August 15, 2004 Page 26 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +8.2.2 Change After Reset + + If the decision in Section 7.2 returns true, the server ensures that + the password update operation contains no modifications other than + the modification of the password attribute. If other modifications + exist, the server sends a response message to the client with the + resultCode: insufficientAccessRights (50), and includes the + passwordPolicyResponse in the controls field of the response message + with the error: changeAfterReset (2). + +8.2.3 Rights Check + + Check to see whether the bound identity has sufficient rights to + update the password. If the bound identity is a user changing its + own password, this MAY be done by checking the pwdAllowUserChange + attribute or using an access control mechanism. The determination of + this is implementation specific. If the user is not allowed to + update her password, the server sends a response message to the + client with the resultCode: insufficientAccessRights (50), and + includes the passwordPolicyResponse in the controls field of the + response message with the error: passwordModNotAllowed (3). + +8.2.4 Too Early to Update + + If the check in Section 7.7 results in a true status The server sends + a response message to the client with the resultCode: + constraintViolation (19), and includes the passwordPolicyResponse in + the controls field of the response message with the error: + passwordTooYoung (7). + +8.2.5 Password Quality + + Check the value of the pwdCheckQuality attribute. If the value is + non-zero, the server: + + o Ensure that the password meets the quality criteria enforced by + the server. This enforcement is implementation specific. + If the server is unable to check the quality (due to a hashed + password or otherwise), the value of pwdCheckQuality is evaluated. + If the value is 1, operation continues. If the value is 2, the + server sends a response message to the client with the resultCode: + constraintViolation (19), and includes the passwordPolicyResponse + in the controls field of the response message with the error: + insufficientPasswordQuality (5). + If the server is able to check the password quality, and the check + fails, the server sends a response message to the client with the + resultCode: constraintViolation (19), and includes the + passwordPolicyResponse in the controls field of the response + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 27] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - A. Add the current time as a value of the pwdFailureTime - attribute. - - B. If the pwdLockout attribute is TRUE, the server MUST do - the following: - - Count the number of values in the pwdFailureTime - attribute that are younger than - pwdFailureCountInterval. - - If the number of these failures is greater or equal to - the pwdMaxFailure attribute, the server MUST lock the - account by setting the value of the - pwdAccountLockedTime attribute to the current time. - After locking the account, the server MUST send a - compareResponse to the client with the resultCode: - compareFalse (5), and MUST include the - passwordPolicyResponse in the controls field of the - compareResponse message with the error: accountLocked - (1). - - If the number of failures is less than the - pwdMaxFailure attribute, operation MUST proceed. - - If the pwdLockout attribute is FALSE, operation MUST - continue. - - C. Failure times that are old by more than - pwdFailureCountInterval, MUST be purged from the - pwdFailureTime attribute. - - D. If no errors were returned, the server MUST send a - compareResponse with the resultCode: compareTrue (6), and - MUST include the passwordPolicyResponse with nothing in - the SEQUENCE. - -7. Client Implementation by LDAP operation - - These sections illustrate possible scenarios for each LDAP operation - and define the types of responses that identify those scenarios. - - The scenarios in the following operations assume that the client - attached a passwordPolicyRequest control to the request message of - the operation, and thus MAY receive a passwordPolicyResponse control - in the response message. In the event that the passwordPolicyRequest - control was not sent, no passwordPolicyRequest control is returned. - All other instructions remain the same. - -7.1. Bind Operation - - -Behera, et. al. Expires August 15, 2004 Page 27 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + message with the error: insufficientPasswordQuality (5). + o checks the value of the pwdMinLength attribute. If the value is + non-zero, it ensures that the new password is of at least the + minimum length. + If the server is unable to check the length (due to a hashed + password or otherwise), the value of pwdCheckQuality is evaluated. + If the value is 1, operation continues. If the value is 2, the + server sends a response message to the client with the resultCode: + constraintViolation (19), and includes the passwordPolicyResponse + in the controls field of the response message with the error: + passwordTooShort (6). + If the server is able to check the password length, and the check + fails, the server sends a response message to the client with the + resultCode: constraintViolation (19), and includes the + passwordPolicyResponse in the controls field of the response + message with the error: passwordTooShort (6). + +8.2.6 Invalid Reuse + + If pwdInHistory is present and its value is non-zero, the server + checks whether this password exists in the entry's pwdHistory + attribute or in the current password attribute. If the password does + exist in the pwdHistory attribute or in the current password + attribute, the server sends a response message to the client with the + resultCode: constraintViolation (19), and includes the + passwordPolicyResponse in the controls field of the response message + with the error: passwordInHistory (8). + +8.2.7 Policy State Updates + + If the steps have completed without causing an error condition, the + server performs the following steps in order to update the necessary + password policy state attributes: + + If the value of either pwdMaxAge or pwdMinAge is non-zero, the server + updates the pwdChangedTime attribute on the entry to the current + time. + + If the value of pwdInHistory is non-zero, the server adds the + previous password (if one existed) to the pwdHistory attribute. If + the number of attributes held in the pwdHistory attribute exceeds the + value of pwdInHistory, the server removes the oldest excess + passwords. + + If the value the pwdMustChange is TRUE and the modification is + performed by a password administrator, then the pwdReset attribute is + set to TRUE. Otherwise, the pwdReset is removed from the user's + entry if it exists. + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 28] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - For every bind response received, the client MUST check the - resultCode of the bindResponse and MUST check for a - passwordPolicyResponse to determine if any of the following - conditions are true and MAY prompt the user accordingly. - - 1. The password failure limit has been reached and the account is - locked. The user needs to retry later or contact the directory - administrator to reset the password. - - resultCode: unwillingToPerform (53) - passwordPolicyResponse: error: accountLocked (1) - - 2. The user is binding for the first time after the directory - administrator set the password. In this scenario, the client - SHOULD prompt the user to change his password immediately. - - resultCode: success (0) - passwordPolicyResponse: error: changeAfterReset (2) - - 3. The password has expired but there are remaining grace logins. - The user needs to change it. - - resultCode: success (0) - passwordPolicyResponse: warning: graceLoginsRemaining - - 4. The password has expired and there are no more grace logins. The - user MUST contact the directory administrator in order to have - its password reset. - - resultCode: invalidCredentials (49) - passwordPolicyResponse: error: passwordExpired (0) - - 5. The user's password will expire in n number of seconds. - - resultCode: success (0) - passwordPolicyResponse: warning: timeBeforeExpiration - -7.2. Modify Operations - -7.2.1. Modify Request - - If the application or client encrypts the password prior to sending - it in a password modification operation (whether done through - modifyRequest or another password modification mechanism), it SHOULD - check the values of the pwdMinLength, and pwdCheckQuality attributes - and SHOULD enforce these policies. - -7.2.2. Modify Response - - -Behera, et. al. Expires August 15, 2004 Page 28 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + The pwdFailureTime, pwdGraceUseTime and pwdExpirationWarned + attributes is removed from the user's entry if they exist. + +8.3 Other Operations + + For operations other than bind, password update, unbind, abandon or + StartTLS, if the decision in Section 7.2 returns true, the server + sends a response message to the client with the resultCode: + insufficientAccessRights (50), and includes the + passwordPolicyResponse in the controls field of the response message + with the error: changeAfterReset (2). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 29] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - If the modifyRequest operation was used to change the password, or - if another mechanism is used --such as an extendedRequest-- the - modifyResponse or other appropriate response MAY contain information - pertinent to password policy. The client MUST check the resultCode - of the response and MUST check for a passwordPolicyResponse to - determine if any of the following conditions are true and optionally - notify the user of the condition. - - 1. The user attempted to change her password without specifying the - old password but the password policy requires this. - - resultCode: unwillingToPerform (53) - passwordPolicyResponse: error: mustSupplyOldPassword (4) - - 2. The user MUST change her password before submitting any other - LDAP requests. - - resultCode: unwillingToPerform (53) - passwordPolicyResponse: error: changeAfterReset (2) - - 3. The user doesn't have sufficient rights to change his password. - - resultCode: unwillingToPerform (53) - passwordPolicyResponse: error: passwordModNotAllowed (3) - - 4. It is too soon after the last password modification to change the - password. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: passwordTooYoung (7) - - 5. The password failed quality checking. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: - insufficientPasswordQuality (5) - - 6. The length of the password is too short. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: passwordTooShort (6) - - 7. The password has already been used; the user MUST choose a - different one. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: passwordInHistory (8) - - - -Behera, et. al. Expires August 15, 2004 Page 29 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +9. Client Policy Enforcement Points + + These sections illustrate possible scenarios for each LDAP operation + and define the types of responses that identify those scenarios. + + The scenarios in the following operations assume that the client + attached a passwordPolicyRequest control to the request message of + the operation, and thus may receive a passwordPolicyResponse control + in the response message. In the event that the passwordPolicyRequest + control was not sent, no passwordPolicyResponse control is returned. + All other instructions remain the same. + +9.1 Bind Operation + + For every bind response received, the client checks the resultCode of + the bindResponse and checks for a passwordPolicyResponse control to + determine if any of the following conditions are true and MAY prompt + the user accordingly. + + o bindResponse.resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = accountLocked (1): The password + failure limit has been reached and the account is locked. The + user needs to retry later or contact the password administrator to + reset the password. + o bindResponse.resultCode = success (0), + passwordPolicyResponse.error = changeAfterReset (2): The user is + binding for the first time after the password administrator set + the password. In this scenario, the client SHOULD prompt the user + to change his password immediately. + o bindResponse.resultCode = success (0), + passwordPolicyResponse.warning = graceAuthNsRemaining: The + password has expired but there are remaining grace + authentications. The user needs to change it. + o bindResponse.resultCode = invalidCredentials (49), + passwordPolicyResponse.error = passwordExpired (0): The password + has expired and there are no more grace authentications. The user + contacts the password administrator in order to have its password + reset. + o bindResponse.resultCode = success (0), + passwordPolicyResponse.warning = timeBeforeExpiration: The user's + password will expire in n number of seconds. + +9.2 Modify Operations + +9.2.1 Modify Request + + If the application or client encrypts the password prior to sending + it in a password modification operation (whether done through + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 30] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - -7.3. Add Operation - - If a password is specified in an addRequest, the client MUST check - the resultCode of the addResponse and MUST check for a - passwordPolicyResponse to determine if any of the following - conditions are true and may prompt the user accordingly. - - 1. The user doesn't have sufficient rights to add this password. - - resultCode: unwillingToPerform (53) - passwordPolicyResponse: error: passwordModNotAllowed (3) - - 2. The password failed quality checking. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: - insufficientPasswordQuality (5) - - 3. The length of the password is too short. - - resultCode: constraintViolation (19) - passwordPolicyResponse: error: passwordTooShort (6) - - -7.4. Compare Operation - - When a compare operation is used to compare a password, the client - MUST check the resultCode of the compareResponse and MUST check for - a passwordPolicyResponse to determine if any of the following - conditions are true and MAY prompt the user accordingly. These - conditions assume that the result of the comparison was true. - - 1. The password failure limit has been reached and the account is - locked. The user needs to retry later or contact the directory - administrator to reset the password. - - resultCode: compareFalse (5) - passwordPolicyResponse: error: accountLocked (1) - - 2. The password has expired but there are remaining grace logins. - The user needs to change it. - - resultCode: compareTrue (6) - passwordPolicyResponse: warning: graceLoginsRemaining - - 3. The password has expired and there are no more grace logins. The - user MUST contact the directory administrator to reset the - password. - - -Behera, et. al. Expires August 15, 2004 Page 30 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + modifyRequest or another password modification mechanism), it SHOULD + check the values of the pwdMinLength, and pwdCheckQuality attributes + and SHOULD enforce these policies. + +9.2.2 Modify Response + + If the modifyRequest operation was used to change the password, or if + another mechanism is used --such as an extendedRequest-- the + modifyResponse or other appropriate response MAY contain information + pertinent to password policy. The client checks the resultCode of + the response and checks for a passwordPolicyResponse control to + determine if any of the following conditions are true and optionally + notify the user of the condition. + + o .resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = mustSupplyOldPassword (4): The user + attempted to change her password without specifying the old + password but the password policy requires this. + o .resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = changeAfterReset (2): The user must + change her password before submitting any other LDAP requests. + o .resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = passwordModNotAllowed (3): The user + doesn't have sufficient rights to change his password. + o .resultCode = constraintViolation (19), + passwordPolicyResponse.error = passwordTooYoung (7): It is too + soon after the last password modification to change the password. + o .resultCode = constraintViolation (19), + passwordPolicyResponse.error = insufficientPasswordQuality (5): + The password failed quality checking. + o .resultCode = constraintViolation (19), + passwordPolicyResponse.error = passwordTooShort (6): The length of + the password is too short. + o .resultCode = constraintViolation (19), + passwordPolicyResponse.error = passwordInHistory (8): The password + has already been used; the user must choose a different one. + +9.3 Add Operation + + If a password is specified in an addRequest, the client checks the + resultCode of the addResponse and checks for a passwordPolicyResponse + control to determine if any of the following conditions are true and + may prompt the user accordingly. + + o addResponse.resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = passwordModNotAllowed (3): The user + doesn't have sufficient rights to add this password. + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 31] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - - resultCode: compareFalse (5) - passwordPolicyResponse: error: passwordExpired (0) - - 4. The user's password will expire in n number of seconds. - - resultCode: compareTrue (6) - passwordPolicyResponse: warning: timeBeforeExpiration - - -7.5. Other Operations - - For operations other than bind, unbind, abandon, search or StartTLS, - the client MUST 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: unwillingToPerform (53) - passwordPolicyResponse: error: changeAfterReset (2) - -8. Administration of a Password Policy - - - A password policy MUST be defined for a particular subtree of the - DIT by adding to an LDAP subentry whose immediate superior is the - root of the subtree, the pwdPolicy auxiliary object class. - The scope of the password policy is defined by the - SubtreeSpecification attribute of the LDAP subentry as specified in - RFC 3672 [RFC-3672]. - - It is possible to define password policies for different password - attributes within the same pwdPolicy entry, by specifying multiple - values of the pwdAttribute. But password policies could also be in - separate sub entries as long as they are contained under the same - LDAP subentry. - - Modifying the password policy MUST not result in any change in - users' entries to which the policy applies. - - It SHOULD be possible to overwrite the password policy for one user - by defining a new policy in a subentry of the user entry. - - Each object that is controlled by password policy SHALL advertise - the subentry that is being used to control its policy in its - pwdPolicySubentry attribute. Clients wishing to examine or manage - password policy for an object, MUST interrogate the - - - -Behera, et. al. Expires August 15, 2004 Page 31 +Internet-Draft Password Policy for LDAP Directories October 2004 + + + o addResponse.resultCode = constraintViolation (19), + passwordPolicyResponse.error = insufficientPasswordQuality (5): + The password failed quality checking. + o addResponse.resultCode = constraintViolation (19), + passwordPolicyResponse.error = passwordTooShort (6): The length of + the password is too short. + +9.4 Compare Operation + + When a compare operation is used to compare a password, the client + checks the resultCode of the compareResponse and checks for a + passwordPolicyResponse to determine if any of the following + conditions are true and MAY prompt the user accordingly. These + conditions assume that the result of the comparison was true. + + o compareResponse.resultCode = compareFalse (5), + passwordPolicyResponse.error = accountLocked (1): The password + failure limit has been reached and the account is locked. The + user needs to retry later or contact the password administrator to + reset the password. + o compareResponse.resultCode = compareTrue (6), + passwordPolicyResponse.warning = graceAuthNsRemaining: The + password has expired but there are remaining grace + authentications. The user needs to change it. + o compareResponse.resultCode = compareFalse (5), + passwordPolicyResponse.error = passwordExpired (0): The password + has expired and there are no more grace authentications. The user + must contact the password administrator to reset the password. + o compareResponse.resultCode = compareTrue (6), + passwordPolicyResponse.warning = timeBeforeExpiration: The user's + password will expire in n number of seconds. + +9.5 Other Operations + + For operations other than bind, unbind, abandon or StartTLS, the + client checks the following result code and control to determine if + the user needs to change the password immediately. + + o .resultCode = insufficientAccessRights (50), + passwordPolicyResponse.error = : changeAfterReset (2) + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 32] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - pwdPolicySubentry for that object in order to arrive at the proper - pwdPolicy subentry. - -9. Password Policy and Replication - - The pwdPolicy object defines the password policy for a portion of - the DIT and MUST be replicated on all the replicas of this subtree, - as any subentry would be, in order to have a consistent policy among - all replicated servers. - - The elements of the password policy that are related to the users - are stored in the entry themselves as operational attributes. - As these attributes are subject to modifications even on a read-only - replica, replicating them must be carefully considered. - - The pwdChangedTime attribute MUST be replicated on all replicas, to - allow expiration of the password. - - The pwdReset attribute MUST be replicated on all replicas, to deny - access to operations other than bind and modify password. - - The pwdHistory attribute MUST be replicated to writable replicas. It - doesn't have to be replicated to a read-only replica, since the - password will never be directly modified on this server. - - The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and - pwdGraceUseTime attributes MUST be replicated to writable replicas, - making the password policy global for all servers. - When the user entry is replicated to a read-only replica, these - attributes SHOULD NOT be replicated. This means that the number of - failures, of grace logins and the locking will take place on each - replicated server. For example, the effective number of failed - attempts on a user password will be N x M (where N is the number of - servers and M the value of pwdMaxFailure attribute). - Replicating these attributes to a read-only replica MAY reduce the - number of tries globally but MAY also introduce some inconstancies - in the way the password policy is applied. - - -10. Security Considerations - - This document defines a set of rules to implement in an LDAP server, - in order to mitigate some of the security risks associated with the - use of passwords and to make it difficult for password cracking - programs to break into directories. - - Authentication with a password MUST follow the recommendations made - in RFC 2829 [RFC-2829]. - - - -Behera, et. al. Expires August 15, 2004 Page 32 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +10. Administration of the Password Policy + + {TODO: Need to define an administrativeRole (need OID). Need to + describe whether pwdPolicy admin areas can overlap} + + A password policy is defined for a particular subtree of the DIT by + adding to an LDAP subentry whose immediate superior is the root of + the subtree, the pwdPolicy auxiliary object class. The scope of the + password policy is defined by the SubtreeSpecification attribute of + the LDAP subentry as specified in [RFC3672]. + + It is possible to define password policies for different password + attributes within the same pwdPolicy entry, by specifying multiple + values of the pwdAttribute. But password policies could also be in + separate sub entries as long as they are contained under the same + LDAP subentry. + + Modifying the password policy MUST NOT result in any change in users' + entries to which the policy applies. + + It SHOULD be possible to overwrite the password policy for one user + by defining a new policy in a subentry of the user entry. + + Each object that is controlled by password policy advertises the + subentry that is being used to control its policy in its + pwdPolicySubentry attribute. Clients wishing to examine or manage + password policy for an object may interrogate the pwdPolicySubentry + for that object in order to arrive at the proper pwdPolicy subentry. + + + + + + + + + + + + + + + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 33] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - Modifications of passwords SHOULD only occur when the connection is - protected with confidentiality and secure authentication. - - Access controls SHOULD be used to restrict access to the password - policy attributes. Especially all the attributes defined to maintain - the Password Policy state information SHOULD not be modifiable by - anyone but the Administrator of the directory server. - - As it is possible to define a password policy for one specific user - by adding a subentry immediately under the user's entry, Access - Controls SHOULD be used to restrict the use of the pwdPolicy object - class or the LDAP subentry object class. - - When a password policy is put in place, the LDAP directory is - subject to a denial of service attack. A malicious user could - deliberately lock out one specific user's account (or all of them) - by sending bind requests with wrong passwords. There is no way to - protect against this kind of attack. The LDAP directory server - SHOULD log as much information as it can (such as client IP address) - whenever an account is locked, in order to be able to identify the - origin of the attack. Denying anonymous access to the LDAP directory - is also a way to restrict this kind of attacks. - - -11. Acknowledgement - - This document is based in part on prior work done by Valerie Chu - from Netscape Communications Corp, published as draft-vchu-ldap-pwd- - policy-00.txt (December 1998). - - -12. Normative References - - [RFC-2119] S. Bradner, "Key Words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC-2195] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize - Extension for Simple Challenge/Response", RFC 2195, September 1997. - - [RFC-2222] J. Myers, "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. - - [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. - - - -Behera, et. al. Expires August 15, 2004 Page 33 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +11. Password Policy and Replication + + The pwdPolicy object defines the password policy for a portion of the + DIT and MUST be replicated on all the replicas of this subtree, as + any subentry would be, in order to have a consistent policy among all + replicated servers. + + The elements of the password policy that are related to the users are + stored in the entry themselves as operational attributes. As these + attributes are subject to modifications even on a read-only replica, + replicating them must be carefully considered. + + The pwdChangedTime attribute MUST be replicated on all replicas, to + allow expiration of the password. + + The pwdReset attribute MUST be replicated on all replicas, to deny + access to operations other than bind and modify password. + + The pwdHistory attribute MUST be replicated to writable replicas. It + doesn't have to be replicated to a read-only replica, since the + password will never be directly modified on this server. + + The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime and + pwdGraceUseTime attributes MUST be replicated to writable replicas, + making the password policy global for all servers. When the user + entry is replicated to a read-only replica, these attributes SHOULD + NOT be replicated. This means that the number of failures, of grace + authentications and the locking will take place on each replicated + server. For example, the effective number of failed attempts on a + user password will be N x M (where N is the number of servers and M + the value of pwdMaxFailure attribute). Replicating these attributes + to a read-only replica MAY reduce the number of tries globally but + MAY also introduce some inconstancies in the way the password policy + is applied. + + Servers participating in a loosely consistent multi-master + replication agreement SHOULD employ a mechanism which ensures + uniqueness of values when populating the attributes pwdFailureTime + and pwdGraceUseTime. The method of achieving this is a local matter + and may consist of using a single authoritative source for the + generation of unique time values, or may consist of the use of the + fractional seconds part to hold a replica identifier. + + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 34] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - [RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest - Authentication as a SASL Mechanism", RFC 2831, May 2000. - - [RFC-3062] K. Zeilenga, "LDAP Password Modify Extended Operation", - RFC 3062, February 2001. - - [RFC-3672] K. Zeilenga, S. Legg, "Subentries in the Lightweight - Directory Access Protocol (LDAP)", RFC 3672, December. - - -13. Authors' Addresses - - Prasanta Behera - 18366 Chelmsford Dr. - Cupertino, CA 95014 - USA - prasantabehera@yahoo.com - - Ludovic Poitou - Sun Microsystems Inc. - 180, Avenue de l'Europe - Zirst de Montbonnot - 38334 Saint Ismier cedex - France - +33 476 188 212 - ludovic.poitou@sun.com - - Jim Sermersheim - Novell, Inc. - 1800 South Novell Place - Provo, Utah 84606, USA - +1 801 861-3088 - jimse@novell.com - -14. Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights - Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - - -Behera, et. al. Expires August 15, 2004 Page 34 +Internet-Draft Password Policy for LDAP Directories October 2004 + + +12. Security Considerations + + This document defines a set of rules to implement in an LDAP server, + in order to mitigate some of the security risks associated with the + use of passwords and to make it difficult for password cracking + programs to break into directories. + + Authentication with a password MUST follow the recommendations made + in [RFC2829]. + + Modifications of passwords SHOULD only occur when the connection is + protected with confidentiality and secure authentication. + + Access controls SHOULD be used to restrict access to the password + policy attributes. The attributes defined to maintain the password + policy state information SHOULD only be modifiable by the password + administrator or higher authority. The pwdHistory attribute MUST be + subject to the same level of access control as the attrbute holding + the password. + + As it is possible to define a password policy for one specific user + by adding a subentry immediately under the user's entry, Access + Controls SHOULD be used to restrict the use of the pwdPolicy object + class or the LDAP subentry object class. + + When the intruder detection password policy is enforced, the LDAP + directory is subject to a denial of service attack. A malicious user + could deliberately lock out one specific user's account (or all of + them) by sending bind requests with wrong passwords. There is no way + to protect against this kind of attack. The LDAP directory server + SHOULD log as much information as it can (such as client IP address) + whenever an account is locked, in order to be able to identify the + origin of the attack. Denying anonymous access to the LDAP directory + is also a way to restrict this kind of attack. + + Returning certain status codes (such as passwordPolicyResponse.error + = accountLocked) allows a denial of service attacker to know that it + has successfully denied service to an account. Servers SHOULD + implement additional checks which return the same status when it is + sensed that some number of failed authentication requests has occured + on a single connection, or from a client address. Server + implementors are encouraged to invent other checks similar to this in + order to thwart this type of DoS attack. + + + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 35] -INTERNET DRAFT LDAP Password Policy 15 February 2004 - - - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - +Internet-Draft Password Policy for LDAP Directories October 2004 + + +13. Acknowledgement + + This document is based in part on prior work done by Valerie Chu from + Netscape Communications Corp, published as + draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera + participated in early revisions of this document. + +14 Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + [RFC2222] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a + SASL Mechanism", RFC 2831, May 2000. + [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", + RFC 3062, February 2001. + [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 3383, September 2002. + [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory + Access Protocol (LDAP)", RFC 3672, December 2003. + [X680] International Telecommunications Union, "Abstract Syntax + Notation One (ASN.1): Specification of basic notation", + ITU-T Recommendation X.680, July 2002. + [X690] International Telecommunications Union, "Information + Technology - ASN.1 encoding rules: Specification of Basic +Sermersheim & Poitou Expires April 24, 2005 [Page 36] + +Internet-Draft Password Policy for LDAP Directories October 2004 + + + Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690, July 2002. + + +Authors' Addresses + + Jim Sermersheim + Novell, Inc + 1800 South Novell Place + Provo, Utah 84606 + USA + + Phone: +1 801 861-3088 + EMail: jimse@novell.com + + Ludovic Poitou + Sun Microsystems + 180, Avenue de l'Europe + Zirst de Montbonnot, 38334 Saint Ismier cedex + France + Phone: +33 476 188 212 + EMail: ludovic.poitou@sun.com @@ -1955,7 +2061,67 @@ INTERNET DRAFT LDAP Password Policy 15 February 2004 - -Behera, et. al. Expires August 15, 2004 Page 35 + + + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 37] +Internet-Draft Password Policy for LDAP Directories October 2004 + + +Intellectual Property Statement + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Sermersheim & Poitou Expires April 24, 2005 [Page 38] + -- 2.39.2