idnits 2.17.1 draft-behera-ldap-password-policy-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 2009) is 5373 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 928 -- Looks like a reference, but probably isn't: '1' on line 930 == Unused Reference: 'RFC3383' is defined on line 1667, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Sermersheim 3 Internet-Draft Novell, Inc 4 Intended status: Standards Track L. Poitou 5 Expires: February 10, 2010 Sun Microsystems 6 H. Chu, Ed. 7 Symas Corp. 8 August 9, 2009 10 Password Policy for LDAP Directories 11 draft-behera-ldap-password-policy-10.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 10, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Password policy as described in this document is a set of rules that 50 controls how passwords are used and administered in Lightweight 51 Directory Access Protocol (LDAP) based directories. In order to 52 improve the security of LDAP directories and make it difficult for 53 password cracking programs to break into directories, it is desirable 54 to enforce a set of rules on password usage. These rules are made to 55 ensure that users change their passwords periodically, passwords meet 56 construction requirements, the re-use of old password is restricted, 57 and to deter password guessing attacks. 59 Table of Contents 61 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Application of Password Policy . . . . . . . . . . . . . . . 6 64 4. Articles of Password Policy . . . . . . . . . . . . . . . . 7 65 4.1. Password Usage Policy . . . . . . . . . . . . . . . . . . . 7 66 4.2. Password Modification Policy . . . . . . . . . . . . . . . . 8 67 4.3. Restriction of the Password Policy . . . . . . . . . . . . . 10 68 5. Schema used for Password Policy . . . . . . . . . . . . . . 12 69 5.1. The pwdPolicy Object Class . . . . . . . . . . . . . . . . . 12 70 5.2. Attribute Types used in the pwdPolicy ObjectClass . . . . . 12 71 5.3. Attribute Types for Password Policy State Information . . . 18 72 6. Controls used for Password Policy . . . . . . . . . . . . . 24 73 6.1. Request Control . . . . . . . . . . . . . . . . . . . . . . 24 74 6.2. Response Control . . . . . . . . . . . . . . . . . . . . . . 24 75 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . 26 76 7.1. Locked Account Check . . . . . . . . . . . . . . . . . . . . 26 77 7.2. Password Must be Changed Now Check . . . . . . . . . . . . . 26 78 7.3. Password Expiration Check . . . . . . . . . . . . . . . . . 27 79 7.4. Remaining Grace AuthN Check . . . . . . . . . . . . . . . . 27 80 7.5. Time Before Expiration Check . . . . . . . . . . . . . . . . 27 81 7.6. Intruder Lockout Check . . . . . . . . . . . . . . . . . . . 27 82 7.7. Intruder Delay Check . . . . . . . . . . . . . . . . . . . . 27 83 7.8. Password Too Young Check . . . . . . . . . . . . . . . . . . 28 84 8. Server Policy Enforcement Points . . . . . . . . . . . . . . 29 85 8.1. Password-based Authentication . . . . . . . . . . . . . . . 29 86 8.2. Password Update Operations . . . . . . . . . . . . . . . . . 31 87 8.3. Other Operations . . . . . . . . . . . . . . . . . . . . . . 34 88 9. Client Policy Enforcement Points . . . . . . . . . . . . . . 35 89 9.1. Bind Operation . . . . . . . . . . . . . . . . . . . . . . . 35 90 9.2. Modify Operations . . . . . . . . . . . . . . . . . . . . . 36 91 9.3. Add Operation . . . . . . . . . . . . . . . . . . . . . . . 37 92 9.4. Compare Operation . . . . . . . . . . . . . . . . . . . . . 37 93 9.5. Other Operations . . . . . . . . . . . . . . . . . . . . . . 38 94 10. Administration of the Password Policy . . . . . . . . . . . 39 95 11. Password Policy and Replication . . . . . . . . . . . . . . 40 96 12. Security Considerations . . . . . . . . . . . . . . . . . . 42 97 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 98 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 44 99 15. Normative References . . . . . . . . . . . . . . . . . . . . 45 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 102 1. Overview 104 LDAP-based directory services are currently accepted by many 105 organizations as the access protocol for directories. The ability to 106 ensure the secure read and update access to directory information 107 throughout the network is essential to the successful deployment. 108 Most LDAP implementations support many authentication schemes - the 109 most basic and widely used is the simple authentication i.e., user DN 110 and password. In this case, many LDAP servers have implemented some 111 kind of policy related to the password used to authenticate. Among 112 other things, this policy includes: 114 o Whether and when passwords expire. 116 o Whether failed bind attempts cause the account to be locked. 118 o If and how users are able to change their passwords. 120 In order to achieve greater security protection and ensure 121 interoperability in a heterogeneous environment, LDAP needs to 122 standardize on a common password policy model. This is critical to 123 the successful deployment of LDAP directories. 125 2. Conventions 127 Imperative keywords defined in [RFC2119] are used in this document, 128 and carry the meanings described there. 130 All ASN.1 [X.680] Basic Encoding Rules (BER) [X.690] encodings follow 131 the conventions found in Section 5.1 of [RFC4511]. 133 The term "password administrator" refers to a user that has 134 sufficient access control privileges to modify users' passwords. The 135 term "password policy administrator" refers to a user that has 136 sufficient access control privileges to modify the pwdPolicy object 137 defined in this document. The access control that is used to 138 determine whether an identity is a password administrator or password 139 policy administrator is beyond the scope of this document, but 140 typically implies that the password administrator has 'write' 141 privileges to the password attribute. 143 3. Application of Password Policy 145 The password policy defined in this document can be applied to any 146 attribute holding a user's password used for an authenticated LDAP 147 bind operation. In this document, the term "user" represents any 148 LDAP client application that has an identity in the directory. 150 This policy is typically applied to the userPassword attribute in the 151 case of the LDAP simple authentication method [RFC4511] or the case 152 of password based SASL [RFC4422] authentication such as CRAM-MD5 153 [RFC2195] and DIGEST-MD5 [RFC2831]. 155 The policy described in this document assumes that the password 156 attribute holds a single value. No considerations are made for 157 directories or systems that allow a user to maintain multi-valued 158 password attributes. 160 Server implementations MAY institute internal policy whereby certain 161 identities (such as directory administrators) are not forced to 162 comply with any of password policy. In this case, the password for a 163 directory administrator never expires; the account is never locked, 164 etc. 166 4. Articles of Password Policy 168 The following sections explain in general terms each aspect of the 169 password policy defined in this document as well as the need for 170 each. These policies are subdivided into the general groups of 171 password usage and password modification. Implementation details are 172 presented in Section 8 and Section 9. 174 4.1. Password Usage Policy 176 This section describes policy enforced when a password is used to 177 authenticate. The general focus of this policy is to minimize the 178 threat of intruders once a password is in use. 180 4.1.1. Password Validity Policy 182 These mechanisms allow account usage to be controlled independent of 183 any password expiration policies. The policy defines the absolute 184 period of time for which an account may be used. This allows an 185 administrator to define an absolute starting time after which a 186 password becomes valid, and an absolute ending time after which the 187 password is disabled. 189 A mechanism is also provided to define the period of time for which 190 an account may remain unused before being disabled. 192 4.1.2. Password Guessing Limit 194 In order to prevent intruders from guessing a user's password, a 195 mechanism exists to track the number of consecutive failed 196 authentication attempts, and take action when a limit is reached. 197 This policy consists of several parts: 199 o A counter to track the number of failed authentication attempts. 201 o The amount of time to delay on the first authentication failure. 203 o The maximum amount of time to delay on subsequent failures. 205 o A timeframe in which the limit of consecutive failed 206 authentication attempts must happen before action is taken. 208 o A configurable limit on failed authentication attempts. 210 o The action to be taken when the limit is reached. The action will 211 either be nothing, or the account will be locked. 213 o An amount of time the account is locked (if it is to be locked). 214 This can be indefinite. 216 Note that using the account lock feature provides an easy avenue for 217 Denial-of-Service (DoS) attacks on user accounts. While some sites' 218 policies require accounts to be locked, this feature is discouraged 219 in favor of delaying each failed login attempt. 221 The delay time will be doubled on each subsequent failure, until it 222 reaches the maximum time configured. 224 [TBD: we could also provide a syntax for configuring a backoff 225 algorithm. E.g. "+" for linearly incrementing delay, "x" 226 for constant multiplier, "^ for geometric. But it's probably 227 overkill to add a calculator language to the server.] 229 4.2. Password Modification Policy 231 This section describes policy enforced while users are modifying 232 passwords. The general focus of this policy is to ensure that when 233 users add or change their passwords, the security and effectiveness 234 of their passwords is maximized. In this document, the term "modify 235 password operation" refers to any operation that is used to add or 236 modify a password attribute. Often this is done by updating the 237 password attribute during an add or modify operation, but MAY be done 238 by other means such as an extended operation. 240 4.2.1. Password Expiration, Expiration Warning, and Grace 241 Authentications 243 One of the key properties of a password is the fact that it is not 244 well known. If a password is frequently changed, the chances of that 245 user's account being broken into are minimized. 247 Password policy administrators may deploy a password policy that 248 causes passwords to expire after a given amount of time - thus 249 forcing users to change their passwords periodically. 251 As a side effect, there needs to be a way in which users are made 252 aware of this need to change their password before actually being 253 locked out of their accounts. One or both of the following methods 254 handle this: 256 o A warning may be returned to the user sometime before his password 257 is due to expire. If the user fails to heed this warning before 258 the expiration time, his account will be locked. 260 o The user may bind to the directory a preset number of times after 261 her password has expired. If she fails to change her password 262 during one of her 'grace' authentications, her account will be 263 locked. 265 4.2.2. Password History 267 When the Password Expiration policy is used, an additional mechanism 268 may be employed to prevent users from simply re-using a previous 269 password (as this would effectively circumvent the expiration 270 policy). 272 In order to do this; a history of used passwords is kept. The 273 password policy administrator sets the number of passwords to be 274 stored at any given time. Passwords are stored in this history 275 whenever the password is changed. Users aren't allowed to specify 276 any passwords that are in the history list while changing passwords. 278 4.2.3. Password Minimum Age 280 Users may circumvent the Password History mechanism by quickly 281 performing a series of password changes. If they change their 282 password enough times, their 'favorite' password will be pushed out 283 of the history list. 285 This process may be made less attractive to users by employing a 286 minimum age for passwords. If users are forced to wait 24 hours 287 between password changes, they may be less likely to cycle through a 288 history of 10 passwords. 290 4.2.4. Password Quality and Minimum length 292 In order to prevent users from creating or updating passwords that 293 are easy to guess, a password quality policy may be employed. This 294 policy consists of two general mechanisms - ensuring that passwords 295 conform to a defined quality criterion and ensuring that they are of 296 a minimum length. 298 Forcing a password to comply with the quality policy may imply a 299 variety of things including: 301 o Disallowing trivial or well-known words make up the password. 303 o Forcing a certain number of digits be used. 305 o Disallowing anagrams of the user's name. 307 The implementation of this policy meets with the following problems: 309 o If the password to be added or updated is encrypted by the client 310 before being sent, the server has no way of enforcing this policy. 311 Therefore, the onus of enforcing this policy falls upon client 312 implementations. 314 o There are no specific definitions of what 'quality checking' 315 means. This can lead to unexpected behavior in a heterogeneous 316 environment. 318 4.2.5. User Defined Passwords 320 In some cases, it is desirable to disallow users from adding and 321 updating their own passwords. This policy makes this functionality 322 possible. 324 4.2.6. Password Change after Reset 326 This policy forces the user to update her password after it has been 327 set for the first time, or has been reset by a password 328 administrator. 330 This is needed in scenarios where a password administrator has set or 331 reset the password to a well-known value. 333 4.2.7. Safe Modification 335 As directories become more commonly used, it will not be unusual for 336 clients to connect to a directory and leave the connection open for 337 an extended period. This opens up the possibility for an intruder to 338 make modifications to a user's password while that user's computer is 339 connected but unattended. 341 This policy forces the user to prove his identity by specifying the 342 old password during a password modify operation. 344 {TODO: This allows a dictionary attack unless we specify that this is 345 also subject to intruder detection. One solution is to require users 346 to authN prior to changing password. Another solution is to perform 347 intruder detection checks when the password for a non-authenticated 348 identity is being updated} 350 4.3. Restriction of the Password Policy 352 The password policy defined in this document can apply to any 353 attribute containing a password. Password policy state information 354 is held in the user's entry, and applies to a password attribute, not 355 a particular password attribute value. Thus the server SHOULD 356 enforce that the password attribute subject to password policy, 357 contains one and only one password value. 359 5. Schema used for Password Policy 361 The schema elements defined here fall into two general categories. A 362 password policy object class is defined which contains a set of 363 administrative password policy attributes, and a set of operational 364 attributes are defined that hold general password policy state 365 information for each user. 367 5.1. The pwdPolicy Object Class 369 This object class contains the attributes defining a password policy 370 in effect for a set of users. Section 10 describes the 371 administration of this object, and the relationship between it and 372 particular objects. 374 ( 1.3.6.1.4.1.42.2.27.8.2.1 375 NAME 'pwdPolicy' 376 SUP top 377 AUXILIARY 378 MUST ( pwdAttribute ) 379 MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ 380 pwdMinLength $ pwdMaxLength $ pwdExpireWarning $ 381 pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $ 382 pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ 383 pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $ 384 pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) ) 386 5.2. Attribute Types used in the pwdPolicy ObjectClass 388 Following are the attribute types used by the pwdPolicy object class. 390 5.2.1. pwdAttribute 392 This holds the name of the attribute to which the password policy is 393 applied. For example, the password policy may be applied to the 394 userPassword attribute. 396 ( 1.3.6.1.4.1.42.2.27.8.1.1 397 NAME 'pwdAttribute' 398 EQUALITY objectIdentifierMatch 399 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 401 5.2.2. pwdMinAge 403 This attribute holds the number of seconds that must elapse between 404 modifications to the password. If this attribute is not present, 0 405 seconds is assumed. 407 ( 1.3.6.1.4.1.42.2.27.8.1.2 408 NAME 'pwdMinAge' 409 EQUALITY integerMatch 410 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 411 SINGLE-VALUE ) 413 5.2.3. pwdMaxAge 415 This attribute holds the number of seconds after which a modified 416 password will expire. 418 If this attribute is not present, or if the value is 0 the password 419 does not expire. If not 0, the value must be greater than or equal 420 to the value of the pwdMinAge. 422 ( 1.3.6.1.4.1.42.2.27.8.1.3 423 NAME 'pwdMaxAge' 424 EQUALITY integerMatch 425 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 426 SINGLE-VALUE ) 428 5.2.4. pwdInHistory 430 This attribute specifies the maximum number of used passwords stored 431 in the pwdHistory attribute. 433 If this attribute is not present, or if the value is 0, used 434 passwords are not stored in the pwdHistory attribute and thus may be 435 reused. 437 ( 1.3.6.1.4.1.42.2.27.8.1.4 438 NAME 'pwdInHistory' 439 EQUALITY integerMatch 440 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 441 SINGLE-VALUE ) 443 5.2.5. pwdCheckQuality 445 {TODO: Consider changing the syntax to OID. Each OID will list a 446 quality rule (like min len, # of special characters, etc). These 447 rules can be specified outside this document.} 449 {TODO: Note that even though this is meant to be a check that happens 450 during password modification, it may also be allowed to happen during 451 authN. This is useful for situations where the password is encrypted 452 when modified, but decrypted when used to authN.} 454 This attribute indicates how the password quality will be verified 455 while being modified or added. If this attribute is not present, or 456 if the value is '0', quality checking will not be enforced. A value 457 of '1' indicates that the server will check the quality, and if the 458 server is unable to check it (due to a hashed password or other 459 reasons) it will be accepted. A value of '2' indicates that the 460 server will check the quality, and if the server is unable to verify 461 it, it will return an error refusing the password. 463 ( 1.3.6.1.4.1.42.2.27.8.1.5 464 NAME 'pwdCheckQuality' 465 EQUALITY integerMatch 466 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 467 SINGLE-VALUE ) 469 5.2.6. pwdMinLength 471 When quality checking is enabled, this attribute holds the minimum 472 number of characters that must be used in a password. If this 473 attribute is not present, no minimum password length will be 474 enforced. If the server is unable to check the length (due to a 475 hashed password or otherwise), the server will, depending on the 476 value of the pwdCheckQuality attribute, either accept the password 477 without checking it ('0' or '1') or refuse it ('2'). 479 ( 1.3.6.1.4.1.42.2.27.8.1.6 480 NAME 'pwdMinLength' 481 EQUALITY integerMatch 482 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 483 SINGLE-VALUE ) 485 5.2.7. pwdMaxLength 487 When quality checking is enabled, this attribute holds the maximum 488 number of characters that may be used in a password. If this 489 attribute is not present, no maximum password length will be 490 enforced. If the server is unable to check the length (due to a 491 hashed password or otherwise), the server will, depending on the 492 value of the pwdCheckQuality attribute, either accept the password 493 without checking it ('0' or '1') or refuse it ('2'). 495 ( 1.3.6.1.4.1.42.2.27.8.1.31 496 NAME 'pwdMaxLength' 497 EQUALITY integerMatch 498 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 499 SINGLE-VALUE ) 501 5.2.8. pwdExpireWarning 503 This attribute specifies the maximum number of seconds before a 504 password is due to expire that expiration warning messages will be 505 returned to an authenticating user. 507 If this attribute is not present, or if the value is 0 no warnings 508 will be returned. If not 0, the value must be smaller than the value 509 of the pwdMaxAge attribute. 511 ( 1.3.6.1.4.1.42.2.27.8.1.7 512 NAME 'pwdExpireWarning' 513 EQUALITY integerMatch 514 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 515 SINGLE-VALUE ) 517 5.2.9. pwdGraceAuthNLimit 519 This attribute specifies the number of times an expired password can 520 be used to authenticate. If this attribute is not present or if the 521 value is 0, authentication will fail. 523 ( 1.3.6.1.4.1.42.2.27.8.1.8 524 NAME 'pwdGraceAuthNLimit' 525 EQUALITY integerMatch 526 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 527 SINGLE-VALUE ) 529 5.2.10. pwdGraceExpiry 531 This attribute specifies the number of seconds the grace 532 authentications are valid. If this attribute is not present or if 533 the value is 0, there is no time limit on the grace authentications. 535 ( 1.3.6.1.4.1.42.2.27.8.1.30 536 NAME 'pwdGraceExpire' 537 EQUALITY integerMatch 538 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 539 SINGLE-VALUE ) 541 5.2.11. pwdLockout 543 This attribute indicates, when its value is "TRUE", that the password 544 may not be used to authenticate after a specified number of 545 consecutive failed bind attempts. The maximum number of consecutive 546 failed bind attempts is specified in pwdMaxFailure. 548 If this attribute is not present, or if the value is "FALSE", the 549 password may be used to authenticate when the number of failed bind 550 attempts has been reached. 552 ( 1.3.6.1.4.1.42.2.27.8.1.9 553 NAME 'pwdLockout' 554 EQUALITY booleanMatch 555 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 556 SINGLE-VALUE ) 558 5.2.12. pwdLockoutDuration 560 This attribute holds the number of seconds that the password cannot 561 be used to authenticate due to too many failed bind attempts. If 562 this attribute is not present, or if the value is 0 the password 563 cannot be used to authenticate until reset by a password 564 administrator. 566 ( 1.3.6.1.4.1.42.2.27.8.1.10 567 NAME 'pwdLockoutDuration' 568 EQUALITY integerMatch 569 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 570 SINGLE-VALUE ) 572 5.2.13. pwdMaxFailure 574 This attribute specifies the number of consecutive failed bind 575 attempts after which the password may not be used to authenticate. 576 If this attribute is not present, or if the value is 0, this policy 577 is not checked, and the value of pwdLockout will be ignored. 579 ( 1.3.6.1.4.1.42.2.27.8.1.11 580 NAME 'pwdMaxFailure' 581 EQUALITY integerMatch 582 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 583 SINGLE-VALUE ) 585 5.2.14. pwdFailureCountInterval 587 This attribute holds the number of seconds after which the password 588 failures are purged from the failure counter, even though no 589 successful authentication occurred. 591 If this attribute is not present, or if its value is 0, the failure 592 counter is only reset by a successful authentication. 594 ( 1.3.6.1.4.1.42.2.27.8.1.12 595 NAME 'pwdFailureCountInterval' 596 EQUALITY integerMatch 597 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 598 SINGLE-VALUE ) 600 5.2.15. pwdMustChange 602 This attribute specifies with a value of "TRUE" that users must 603 change their passwords when they first bind to the directory after a 604 password is set or reset by a password administrator. If this 605 attribute is not present, or if the value is "FALSE", users are not 606 required to change their password upon binding after the password 607 administrator sets or resets the password. This attribute is not set 608 due to any actions specified by this document, it is typically set by 609 a password administrator after resetting a user's password. 611 ( 1.3.6.1.4.1.42.2.27.8.1.13 612 NAME 'pwdMustChange' 613 EQUALITY booleanMatch 614 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 615 SINGLE-VALUE ) 617 5.2.16. pwdAllowUserChange 619 This attribute indicates whether users can change their own 620 passwords, although the change operation is still subject to access 621 control. If this attribute is not present, a value of "TRUE" is 622 assumed. This attribute is intended to be used in the absence of an 623 access control mechanism. 625 ( 1.3.6.1.4.1.42.2.27.8.1.14 626 NAME 'pwdAllowUserChange' 627 EQUALITY booleanMatch 628 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 629 SINGLE-VALUE ) 631 5.2.17. pwdSafeModify 633 This attribute specifies whether or not the existing password must be 634 sent along with the new password when being changed. If this 635 attribute is not present, a "FALSE" value is assumed. 637 ( 1.3.6.1.4.1.42.2.27.8.1.15 638 NAME 'pwdSafeModify' 639 EQUALITY booleanMatch 640 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 641 SINGLE-VALUE ) 643 5.2.18. pwdMinDelay 645 This attribute specifies the number of seconds to delay responding to 646 the first failed authentication attempt. If this attribute is not 647 set or is 0, no delays will be used. pwdMaxDelay must also be 648 specified if pwdMinDelay is set. 650 ( 1.3.6.1.4.1.42.2.27.8.1.24 651 NAME 'pwdMinDelay' 652 EQUALITY integerMatch 653 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 654 SINGLE-VALUE ) 656 5.2.19. pwdMaxDelay 658 This attribute specifies the maximum number of seconds to delay when 659 responding to a failed authentication attempt. The time specified in 660 pwdMinDelay is used as the starting time and is then doubled on each 661 failure until the delay time is greater than or equal to pwdMaxDelay 662 (or a successful authentication occurs, which resets the failure 663 counter). pwdMinDelay must be specified if pwdMaxDelay is set. 665 ( 1.3.6.1.4.1.42.2.27.8.1.25 666 NAME 'pwdMaxDelay' 667 EQUALITY integerMatch 668 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 669 SINGLE-VALUE ) 671 5.2.20. pwdMaxIdle 673 This attribute specifies the number of seconds an account may remain 674 unused before it becomes locked. If this attribute is not set or is 675 0, no check is performed. 677 ( 1.3.6.1.4.1.42.2.27.8.1.26 678 NAME 'pwdMaxIdle' 679 EQUALITY integerMatch 680 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 681 SINGLE-VALUE ) 683 5.3. Attribute Types for Password Policy State Information 685 Password policy state information must be maintained for each user. 686 The information is located in each user entry as a set of operational 687 attributes. These operational attributes are: pwdChangedTime, 688 pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime, 689 pwdReset, pwdPolicySubEntry, pwdStartTime, pwdEndTime, 690 pwdLastSuccess. 692 5.3.1. Password Policy State Attribute Option 694 Since the password policy could apply to several attributes used to 695 store passwords, each of the above operational attributes must have 696 an option to specify which pwdAttribute it applies to. The password 697 policy option is defined as the following: 699 pwd- 701 where passwordAttribute a string following the OID syntax 702 (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor 703 (short name) MUST be used. 705 For example, if the pwdPolicy object has for pwdAttribute 706 "userPassword" then the pwdChangedTime operational attribute, in a 707 user entry, will be: 709 pwdChangedTime;pwd-userPassword: 20000103121520Z 711 This attribute option follows sub-typing semantics. If a client 712 requests a password policy state attribute to be returned in a search 713 operation, and does not specify an option, all subtypes of that 714 policy state attribute are returned. 716 5.3.2. pwdChangedTime 718 This attribute specifies the last time the entry's password was 719 changed. This is used by the password expiration policy. If this 720 attribute does not exist, the password will never expire. 722 ( 1.3.6.1.4.1.42.2.27.8.1.16 723 NAME 'pwdChangedTime' 724 DESC 'The time the password was last changed' 725 EQUALITY generalizedTimeMatch 726 ORDERING generalizedTimeOrderingMatch 727 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 728 SINGLE-VALUE 729 NO-USER-MODIFICATION 730 USAGE directoryOperation ) 732 5.3.3. pwdAccountLockedTime 734 This attribute holds the time that the user's account was locked. A 735 locked account means that the password may no longer be used to 736 authenticate. A 000001010000Z value means that the account has been 737 locked permanently, and that only a password administrator can unlock 738 the account. 740 ( 1.3.6.1.4.1.42.2.27.8.1.17 741 NAME 'pwdAccountLockedTime' 742 DESC 'The time an user account was locked' 743 EQUALITY generalizedTimeMatch 744 ORDERING generalizedTimeOrderingMatch 745 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 746 SINGLE-VALUE 747 NO-USER-MODIFICATION 748 USAGE directoryOperation ) 750 5.3.4. pwdFailureTime 752 This attribute holds the timestamps of the consecutive authentication 753 failures. 755 ( 1.3.6.1.4.1.42.2.27.8.1.19 756 NAME 'pwdFailureTime' 757 DESC 'The timestamps of the last consecutive authentication 758 failures' 759 EQUALITY generalizedTimeMatch 760 ORDERING generalizedTimeOrderingMatch 761 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 762 NO-USER-MODIFICATION 763 USAGE directoryOperation ) 765 5.3.5. pwdHistory 767 This attribute holds a history of previously used passwords. Values 768 of this attribute are transmitted in string format as given by the 769 following ABNF: 771 pwdHistory = time "#" syntaxOID "#" length "#" data 773 time = GeneralizedTime 775 syntaxOID = numericoid ; the string representation of the 776 ; dotted-decimal OID that defines the 777 ; syntax used to store the password. 779 length = number ; the number of octets in data. 781 data = . 784 GeneralizedTime is specified in 3.3.13 of [RFC4517]. numericoid and 785 number are specified in 1.4 of [RFC4512]. 787 This format allows the server to store, and transmit a history of 788 passwords that have been used. In order for equality matching to 789 function properly, the time field needs to adhere to a consistent 790 format. For this purpose, the time field MUST be in GMT format. 792 ( 1.3.6.1.4.1.42.2.27.8.1.20 793 NAME 'pwdHistory' 794 DESC 'The history of user s passwords' 795 EQUALITY octetStringMatch 796 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 797 NO-USER-MODIFICATION 798 USAGE directoryOperation ) 800 5.3.6. pwdGraceUseTime 802 This attribute holds the timestamps of grace authentications after a 803 password has expired. 805 ( 1.3.6.1.4.1.42.2.27.8.1.21 806 NAME 'pwdGraceUseTime' 807 DESC 'The timestamps of the grace authentication after the 808 password has expired' 809 EQUALITY generalizedTimeMatch 810 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 811 NO-USER-MODIFICATION 812 USAGE directoryOperation ) 814 5.3.7. pwdReset 816 This attribute holds a flag to indicate (when TRUE) that the password 817 has been updated by the password administrator and must be changed by 818 the user. 820 ( 1.3.6.1.4.1.42.2.27.8.1.22 821 NAME 'pwdReset' 822 DESC 'The indication that the password has been reset' 823 EQUALITY booleanMatch 824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 825 SINGLE-VALUE 826 USAGE directoryOperation ) 828 5.3.8. pwdPolicySubentry 830 This attribute points to the pwdPolicy subentry in effect for this 831 object. 833 ( 1.3.6.1.4.1.42.2.27.8.1.23 834 NAME 'pwdPolicySubentry' 835 DESC 'The pwdPolicy subentry in effect for this object' 836 EQUALITY distinguishedNameMatch 837 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 838 SINGLE-VALUE 839 NO-USER-MODIFICATION 840 USAGE directoryOperation ) 842 5.3.9. pwdStartTime 844 This attribute specifies the time the entry's password becomes valid 845 for authentication. Authentication attempts made before this time 846 will fail. If this attribute does not exist, then no restriction 847 applies. 849 ( 1.3.6.1.4.1.42.2.27.8.1.27 850 NAME 'pwdStartTime' 851 DESC 'The time the password becomes enabled' 852 EQUALITY generalizedTimeMatch 853 ORDERING generalizedTimeOrderingMatch 854 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 855 SINGLE-VALUE 856 NO-USER-MODIFICATION 857 USAGE directoryOperation ) 859 5.3.10. pwdEndTime 861 This attribute specifies the time the entry's password becomes 862 invalid for authentication. Authentication attempts made after this 863 time will fail, regardless of expiration or grace settings. If this 864 attribute does not exist, then this restriction does not apply. 866 ( 1.3.6.1.4.1.42.2.27.8.1.28 867 NAME 'pwdEndTime' 868 DESC 'The time the password becomes disabled' 869 EQUALITY generalizedTimeMatch 870 ORDERING generalizedTimeOrderingMatch 871 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 872 SINGLE-VALUE 873 NO-USER-MODIFICATION 874 USAGE directoryOperation ) 876 Note that pwdStartTime may be set to a time greater than or equal to 877 pwdEndTime; this simply disables the account. 879 5.3.11. pwdLastSuccess 881 This attribute holds the timestamp of the last successful 882 authentication. 884 ( 1.3.6.1.4.1.42.2.27.8.1.29 885 NAME 'pwdLastSuccess' 886 DESC 'The timestamp of the last successful authentication' 887 EQUALITY generalizedTimeMatch 888 ORDERING generalizedTimeOrderingMatch 889 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 890 SINGLE-VALUE 891 NO-USER-MODIFICATION 892 USAGE directoryOperation ) 894 6. Controls used for Password Policy 896 This section details the controls used while enforcing password 897 policy. A request control is defined that is sent by a client with a 898 request operation in order to elicit a response control. The 899 response control contains various warnings and errors associated with 900 password policy. 902 {TODO: add a note about advertisement and discovery} 904 6.1. Request Control 906 This control MAY be sent with any LDAP request message in order to 907 convey to the server that this client is aware of, and can process 908 the response control described in this document. When a server 909 receives this control, it will return the response control when 910 appropriate and with the proper data. 912 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may 913 be TRUE or FALSE. There is no controlValue. 915 6.2. Response Control 917 If the client has sent a passwordPolicyRequest control, the server 918 (when solicited by the inclusion of the request control) sends this 919 control with the following operation responses: bindResponse, 920 modifyResponse, addResponse, compareResponse and possibly 921 extendedResponse, to inform of various conditions, and MAY be sent 922 with other operations (in the case of the changeAfterReset error). 923 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is 924 the BER encoding of the following type: 926 PasswordPolicyResponseValue ::= SEQUENCE { 927 warning [0] CHOICE { 928 timeBeforeExpiration [0] INTEGER (0 .. maxInt), 929 graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, 930 error [1] ENUMERATED { 931 passwordExpired (0), 932 accountLocked (1), 933 changeAfterReset (2), 934 passwordModNotAllowed (3), 935 mustSupplyOldPassword (4), 936 insufficientPasswordQuality (5), 937 passwordTooShort (6), 938 passwordTooYoung (7), 939 passwordInHistory (8) } OPTIONAL } 941 The timeBeforeExpiration warning specifies the number of seconds 942 before a password will expire. The graceAuthNsRemaining warning 943 specifies the remaining number of times a user will be allowed to 944 authenticate with an expired password. The passwordExpired error 945 signifies that the password has expired and must be reset. The 946 changeAfterReset error signifies that the password must be changed 947 before the user will be allowed to perform any operation other than 948 bind and modify. The passwordModNotAllowed error is set when a user 949 is restricted from changing her password. The 950 insufficientPasswordQuality error is set when a password doesn't pass 951 quality checking. The passwordTooYoung error is set if the age of 952 the password to be modified is not yet old enough. 954 Typically, only either a warning or an error will be encoded though 955 there may be exceptions. For example, if the user is required to 956 change a password after the password administrator set it, and the 957 password will expire in a short amount of time, the control may 958 include the timeBeforeExpiration warning and the changeAfterReset 959 error. 961 7. Policy Decision Points 963 Following are a number of procedures used to make policy decisions. 964 These procedures are typically performed by the server while 965 processing an operation. 967 The following sections contain detailed instructions that refer to 968 attributes of the pwdPolicy object class. When doing so, the 969 attribute of the pwdPolicy object that governs the entry being 970 discussed is implied. 972 7.1. Locked Account Check 974 A status of true is returned to indicate that the account is locked 975 if any of these conditions are met: 977 o The value of the pwdAccountLockedTime attribute is 000001010000Z. 979 o The current time is less than the value of the pwdStartTime 980 attribute. 982 o The current time is greater than or equal to the value of the 983 pwdEndTime attribute. 985 o The current time is greater than or equal to the value of the 986 pwdLastSuccess attribute added to the value of the pwdMaxIdle 987 attribute. 989 o The current time is less than the value of the 990 pwdAccountLockedTime attribute added to the value of the 991 pwdLockoutDuration. 993 Otherwise a status of false is returned. 995 7.2. Password Must be Changed Now Check 997 A status of true is returned to indicate that the password must be 998 changed if all of these conditions are met: 1000 o The pwdMustChange attribute is set to TRUE. 1002 o The pwdReset attribute is set to TRUE. 1004 Otherwise a status of false is returned. 1006 7.3. Password Expiration Check 1008 A status of true is returned indicating that the password has expired 1009 if the current time minus the value of pwdChangedTime is greater than 1010 the value of the pwdMaxAge. 1012 Otherwise, a status of false is returned. 1014 7.4. Remaining Grace AuthN Check 1016 If the pwdGraceUseTime attribute is present, the number of values in 1017 that attribute subtracted from the value of pwdGraceAuthNLimit is 1018 returned. Otherwise zero is returned. A positive result specifies 1019 the number of remaining grace authentications. 1021 7.5. Time Before Expiration Check 1023 If the pwdExpireWarning attribute is not present a zero status is 1024 returned. Otherwise the following steps are followed: 1026 Subtract the time stored in pwdChangedTime from the current time to 1027 arrive at the password's age. If the password's age is greater than 1028 than the value of the pwdMaxAge attribute, a zero status is returned. 1029 Subtract the value of the pwdExpireWarning attribute from the value 1030 of the pwdMaxAge attribute to arrive at the warning age. If the 1031 password's age is equal to or greater than the warning age, the value 1032 of pwdMaxAge minus the password's age is returned. 1034 7.6. Intruder Lockout Check 1036 A status of true indicating that an intruder has been detected is 1037 returned if the following conditions are met: 1039 o The pwdLockout attribute is TRUE. 1041 o The number of values in the pwdFailureTime attribute that are 1042 younger than pwdFailureCountInterval is greater or equal to the 1043 pwdMaxFailure attribute. 1045 Otherwise a status of false is returned. 1047 While performing this check, values of pwdFailureTime that are old by 1048 more than pwdFailureCountInterval are purged and not counted. 1050 7.7. Intruder Delay Check 1052 If the pwdMinDelay attribute is 0 or not set, zero is returned. 1054 Otherwise, a delay time is computed based on the number of values in 1055 the pwdFailureTime attribute. If the computed value is greater than 1056 the pwdMaxDelay attribute, the pwdMaxDelay value is returned. 1058 While performing this check, values of pwdFailureTime that are old by 1059 more than pwdFailureCountInterval are purged and not counted. 1061 7.8. Password Too Young Check 1063 If the Section 7.2 check returned true then this check will return 1064 false, to allow the password to be changed. 1066 A status of true indicating that not enough time has passed since the 1067 password was last updated is returned if: 1069 o The value of pwdMinAge is non-zero and pwdChangedTime is present. 1071 o The value of pwdMinAge is greater than the current time minus the 1072 value of pwdChangedTime. 1074 Otherwise a false status is returned. 1076 8. Server Policy Enforcement Points 1078 The server SHOULD enforce that the password attribute subject to a 1079 password policy as defined in this document, contains one and only 1080 one password value. 1082 Note: The case where a single password value is stored in multiple 1083 formats simultaneously is still considered to be only one password 1084 value. 1086 The scenarios in the following operations assume that the client has 1087 attached a passwordPolicyRequest control to the request message of 1088 the operation. In the event that the passwordPolicyRequest control 1089 was not sent, no passwordPolicyResponse control is returned. All 1090 other instructions remain the same. 1092 For successfully completed operations, unless otherwise stated, no 1093 passwordPolicyResponse control is returned. 1095 8.1. Password-based Authentication 1097 This section contains the policy enforcement rules and policy data 1098 updates used while validating a password. Operations that validate 1099 passwords include, but are not limited to, the Bind operation where 1100 the simple choice specifies a password, and the Compare operation 1101 where the attribute being compared holds a password. Note that while 1102 the Compare operation does not authenticate a user to the LDAP 1103 server, it may be used by an external application for purposes of 1104 authentication. 1106 8.1.1. Fail if the account is locked 1108 If the account is locked as specified in Section 7.1, the server 1109 fails the operation with an appropriate resultCode (i.e. 1110 invalidCredentials (49) in the case of a bind operation, compareFalse 1111 (5) in the case of a compare operation, etc.). The server MAY set 1112 the error: accountLocked (1) in the passwordPolicyResponse in the 1113 controls field of the message. 1115 8.1.2. Validated Password Procedures 1117 If the validation operation indicates that the password validated, 1118 these procedures are followed in order: 1120 8.1.2.1. Policy state updates 1122 Delete the pwdFailureTime and pwdAccountLockedTime attributes. 1124 Set the value of the pwdLastSuccess attribute to the current time. 1126 Note: setting pwdLastSuccess is optional, but it is required if the 1127 policy has pwdMaxIdle defined. 1129 8.1.2.2. Password must be changed now 1131 If the decision in Section 7.2 returns true, the server sends to the 1132 client a response with an appropriate successful resultCode (i.e. 1133 success (0), compareTrue (6), etc.), and includes the 1134 passwordPolicyResponse in the controls field of the bindResponse 1135 message with the warning: changeAfterReset specified. 1137 For bind, the server MUST then disallow all operations issued by this 1138 user except modify password, bind, unbind, abandon and StartTLS 1139 extended operation. 1141 8.1.2.3. Expired password 1143 If the password has expired as per Section 7.3, the server either 1144 returns a success or failure based on the state of grace 1145 authentications. 1147 8.1.2.3.1. Remaining Grace Authentications 1149 If there are remaining grace authentications as per Section 7.4, the 1150 server adds a new value with the current time in pwdGraceUseTime. 1151 Then it sends to the client a response with an appropriate successful 1152 resultCode (i.e. success (0), compareTrue (6), etc.), and includes 1153 the passwordPolicyResponse in the controls field of the response 1154 message with the warning: graceAuthNsRemaining choice set to the 1155 number of grace authentications left. 1157 Implementor's note: The system time of the host machine may be more 1158 granular than is needed to ensure unique values of this attribute. 1159 It is recommended that a mechanism is used to ensure unique 1160 generalized time values. The fractional seconds field may be used 1161 for this purpose. 1163 8.1.2.3.2. No Remaining Grace Authentications 1165 If there are no remaining grace authentications, the server fails the 1166 operation with an appropriate resultCode (invalidCredentials (49), 1167 compareFalse (5), etc.), and includes the passwordPolicyResponse in 1168 the controls field of the bindResponse message with the error: 1169 passwordExpired (0) set. 1171 8.1.2.4. Expiration Warning 1173 If the result of Section 7.5 is a positive number, the server sends 1174 to the client a response with an appropriate successful resultCode 1175 (i.e. success (0), compareTrue (6), etc.), and includes the 1176 passwordPolicyResponse in the controls field of the bindResponse 1177 message with the warning: timeBeforeExiration set to the value as 1178 described above. Otherwise, the server sends a successful response, 1179 and omits the passwordPolicyResponse. 1181 8.1.3. AuthN Failed Procedures 1183 If the authentication process indicates that the password failed 1184 validation due to invalid credentials, these procedures are followed: 1186 8.1.3.1. Policy state update 1188 Add the current time as a value of the pwdFailureTime attribute. 1190 Implementor's note: The system time of the host machine may be more 1191 granular than is needed to ensure unique values of this attribute. 1192 It is recommended that a mechanism is used to ensure unique 1193 generalized time values. The fractional seconds field may be used 1194 for this purpose. 1196 8.1.3.2. Handle Intruder Detection 1198 If the check in Section 7.6 returns a true state, the server locks 1199 the account by setting the value of the pwdAccountLockedTime 1200 attribute to the current time. After locking the account, the server 1201 fails the operation with an appropriate resultCode 1202 (invalidCredentials (49), compareFalse (5), etc.), and includes the 1203 passwordPolicyResponse in the controls field of the message with the 1204 error: accountLocked (1). 1206 If the check in Section 7.7 returns a non-zero value, the server 1207 waits that number of seconds before sending the authentication 1208 response back to the client. 1210 8.2. Password Update Operations 1212 Because the password is stored in an attribute, various operations 1213 (like add and modify) may be used to create or update a password. 1214 But some alternate mechanisms have been defined or may be defined, 1215 such as the LDAP Password Modify Extended Operation [RFC3062]. 1217 While processing a password update, the server performs the following 1218 steps: 1220 8.2.1. Safe Modification 1222 If pwdSafeModify is set to TRUE and if there is an existing password 1223 value, the server ensures that the password update operation includes 1224 the user's existing password. 1226 When the LDAP modify operation is used to modify a password, this is 1227 done by specifying both a delete action and an add or replace action, 1228 where the delete action specifies the existing password, and the add 1229 or replace action specifies the new password. Other password update 1230 operations SHOULD employ a similar mechanism. Otherwise this policy 1231 will fail. 1233 If the existing password is not specified, the server does not 1234 process the operation and sends the appropriate response message to 1235 the client with the resultCode: insufficientAccessRights (50), and 1236 includes the passwordPolicyResponse in the controls field of the 1237 response message with the error: mustSupplyOldPassword (4). 1239 8.2.2. Change After Reset 1241 If the decision in Section 7.2 returns true, the server ensures that 1242 the password update operation contains no modifications other than 1243 the modification of the password attribute. If other modifications 1244 exist, the server sends a response message to the client with the 1245 resultCode: insufficientAccessRights (50), and includes the 1246 passwordPolicyResponse in the controls field of the response message 1247 with the error: changeAfterReset (2). 1249 8.2.3. Rights Check 1251 Check to see whether the bound identity has sufficient rights to 1252 update the password. If the bound identity is a user changing its 1253 own password, this MAY be done by checking the pwdAllowUserChange 1254 attribute or using an access control mechanism. The determination of 1255 this is implementation specific. If the user is not allowed to 1256 update her password, the server sends a response message to the 1257 client with the resultCode: insufficientAccessRights (50), and 1258 includes the passwordPolicyResponse in the controls field of the 1259 response message with the error: passwordModNotAllowed (3). 1261 8.2.4. Too Early to Update 1263 If the check in Section 7.8 results in a true status The server sends 1264 a response message to the client with the resultCode: 1265 constraintViolation (19), and includes the passwordPolicyResponse in 1266 the controls field of the response message with the error: 1267 passwordTooYoung (7). 1269 8.2.5. Password Quality 1271 Check the value of the pwdCheckQuality attribute. If the value is 1272 non-zero, the server: 1274 o Ensure that the password meets the quality criteria enforced by 1275 the server. This enforcement is implementation specific. If the 1276 server is unable to check the quality (due to a hashed password or 1277 otherwise), the value of pwdCheckQuality is evaluated. If the 1278 value is 1, operation continues. If the value is 2, the server 1279 sends a response message to the client with the resultCode: 1280 constraintViolation (19), and includes the passwordPolicyResponse 1281 in the controls field of the response message with the error: 1282 insufficientPasswordQuality (5). If the server is able to check 1283 the password quality, and the check fails, the server sends a 1284 response message to the client with the resultCode: 1285 constraintViolation (19), and includes the passwordPolicyResponse 1286 in the controls field of the response message with the error: 1287 insufficientPasswordQuality (5). 1289 o checks the value of the pwdMinLength attribute. If the value is 1290 non-zero, it ensures that the new password is of at least the 1291 minimum length. If the server is unable to check the length (due 1292 to a hashed password or otherwise), the value of pwdCheckQuality 1293 is evaluated. If the value is 1, operation continues. If the 1294 value is 2, the server sends a response message to the client with 1295 the resultCode: constraintViolation (19), and includes the 1296 passwordPolicyResponse in the controls field of the response 1297 message with the error: passwordTooShort (6). If the server is 1298 able to check the password length, and the check fails, the server 1299 sends a response message to the client with the resultCode: 1300 constraintViolation (19), and includes the passwordPolicyResponse 1301 in the controls field of the response message with the error: 1302 passwordTooShort (6). 1304 8.2.6. Invalid Reuse 1306 If pwdInHistory is present and its value is non-zero, the server 1307 checks whether this password exists in the entry's pwdHistory 1308 attribute or in the current password attribute. If the password does 1309 exist in the pwdHistory attribute or in the current password 1310 attribute, the server sends a response message to the client with the 1311 resultCode: constraintViolation (19), and includes the 1312 passwordPolicyResponse in the controls field of the response message 1313 with the error: passwordInHistory (8). 1315 8.2.7. Policy State Updates 1317 If the steps have completed without causing an error condition, the 1318 server performs the following steps in order to update the necessary 1319 password policy state attributes: 1321 If the value of either pwdMaxAge or pwdMinAge is non-zero, the server 1322 updates the pwdChangedTime attribute on the entry to the current 1323 time. 1325 If the value of pwdInHistory is non-zero, the server adds the 1326 previous password (if one existed) to the pwdHistory attribute. If 1327 the number of attributes held in the pwdHistory attribute exceeds the 1328 value of pwdInHistory, the server removes the oldest excess 1329 passwords. 1331 If the value the pwdMustChange is TRUE and the modification is 1332 performed by a password administrator, then the pwdReset attribute is 1333 set to TRUE. Otherwise, the pwdReset is removed from the user's 1334 entry if it exists. 1336 The pwdFailureTime and pwdGraceUseTime attributes is removed from the 1337 user's entry if they exist. 1339 8.3. Other Operations 1341 For operations other than bind, password update, unbind, abandon or 1342 StartTLS, if the decision in Section 7.2 returns true, the server 1343 sends a response message to the client with the resultCode: 1344 insufficientAccessRights (50), and includes the 1345 passwordPolicyResponse in the controls field of the response message 1346 with the error: changeAfterReset (2). 1348 9. Client Policy Enforcement Points 1350 These sections illustrate possible scenarios for each LDAP operation 1351 and define the types of responses that identify those scenarios. 1353 The scenarios in the following operations assume that the client 1354 attached a passwordPolicyRequest control to the request message of 1355 the operation, and thus may receive a passwordPolicyResponse control 1356 in the response message. In the event that the passwordPolicyRequest 1357 control was not sent, no passwordPolicyResponse control is returned. 1358 All other instructions remain the same. 1360 9.1. Bind Operation 1362 For every bind response received, the client checks the resultCode of 1363 the bindResponse and checks for a passwordPolicyResponse control to 1364 determine if any of the following conditions are true and MAY prompt 1365 the user accordingly. 1367 o bindResponse.resultCode = insufficientAccessRights (50), 1368 passwordPolicyResponse.error = accountLocked (1): The password 1369 failure limit has been reached and the account is locked. The 1370 user needs to retry later or contact the password administrator to 1371 reset the password. 1373 o bindResponse.resultCode = success (0), 1374 passwordPolicyResponse.error = changeAfterReset (2): The user is 1375 binding for the first time after the password administrator set 1376 the password. In this scenario, the client SHOULD prompt the user 1377 to change his password immediately. 1379 o bindResponse.resultCode = success (0), 1380 passwordPolicyResponse.warning = graceAuthNsRemaining: The 1381 password has expired but there are remaining grace 1382 authentications. The user needs to change it. 1384 o bindResponse.resultCode = invalidCredentials (49), 1385 passwordPolicyResponse.error = passwordExpired (0): The password 1386 has expired and there are no more grace authentications. The user 1387 contacts the password administrator in order to have its password 1388 reset. 1390 o bindResponse.resultCode = success (0), 1391 passwordPolicyResponse.warning = timeBeforeExpiration: The user's 1392 password will expire in n number of seconds. 1394 9.2. Modify Operations 1396 9.2.1. Modify Request 1398 If the application or client encrypts the password prior to sending 1399 it in a password modification operation (whether done through 1400 modifyRequest or another password modification mechanism), it SHOULD 1401 check the values of the pwdMinLength, and pwdCheckQuality attributes 1402 and SHOULD enforce these policies. 1404 9.2.2. Modify Response 1406 If the modifyRequest operation was used to change the password, or if 1407 another mechanism is used --such as an extendedRequest-- the 1408 modifyResponse or other appropriate response MAY contain information 1409 pertinent to password policy. The client checks the resultCode of 1410 the response and checks for a passwordPolicyResponse control to 1411 determine if any of the following conditions are true and optionally 1412 notify the user of the condition. 1414 o pwdModResponse.resultCode = insufficientAccessRights (50), 1415 passwordPolicyResponse.error = mustSupplyOldPassword (4): The user 1416 attempted to change her password without specifying the old 1417 password but the password policy requires this. 1419 o pwdModResponse.resultCode = insufficientAccessRights (50), 1420 passwordPolicyResponse.error = changeAfterReset (2): The user must 1421 change her password before submitting any other LDAP requests. 1423 o pwdModResponse.resultCode = insufficientAccessRights (50), 1424 passwordPolicyResponse.error = passwordModNotAllowed (3): The user 1425 doesn't have sufficient rights to change his password. 1427 o pwdModResponse.resultCode = constraintViolation (19), 1428 passwordPolicyResponse.error = passwordTooYoung (7): It is too 1429 soon after the last password modification to change the password. 1431 o pwdModResponse.resultCode = constraintViolation (19), 1432 passwordPolicyResponse.error = insufficientPasswordQuality (5): 1433 The password failed quality checking. 1435 o pwdModResponse.resultCode = constraintViolation (19), 1436 passwordPolicyResponse.error = passwordTooShort (6): The length of 1437 the password is too short. 1439 o pwdModResponse.resultCode = constraintViolation (19), 1440 passwordPolicyResponse.error = passwordInHistory (8): The password 1441 has already been used; the user must choose a different one. 1443 9.3. Add Operation 1445 If a password is specified in an addRequest, the client checks the 1446 resultCode of the addResponse and checks for a passwordPolicyResponse 1447 control to determine if any of the following conditions are true and 1448 may prompt the user accordingly. 1450 o addResponse.resultCode = insufficientAccessRights (50), 1451 passwordPolicyResponse.error = passwordModNotAllowed (3): The user 1452 doesn't have sufficient rights to add this password. 1454 o addResponse.resultCode = constraintViolation (19), 1455 passwordPolicyResponse.error = insufficientPasswordQuality (5): 1456 The password failed quality checking. 1458 o addResponse.resultCode = constraintViolation (19), 1459 passwordPolicyResponse.error = passwordTooShort (6): The length of 1460 the password is too short. 1462 9.4. Compare Operation 1464 When a compare operation is used to compare a password, the client 1465 checks the resultCode of the compareResponse and checks for a 1466 passwordPolicyResponse to determine if any of the following 1467 conditions are true and MAY prompt the user accordingly. These 1468 conditions assume that the result of the comparison was true. 1470 o compareResponse.resultCode = compareFalse (5), 1471 passwordPolicyResponse.error = accountLocked (1): The password 1472 failure limit has been reached and the account is locked. The 1473 user needs to retry later or contact the password administrator to 1474 reset the password. 1476 o compareResponse.resultCode = compareTrue (6), 1477 passwordPolicyResponse.warning = graceAuthNsRemaining: The 1478 password has expired but there are remaining grace 1479 authentications. The user needs to change it. 1481 o compareResponse.resultCode = compareFalse (5), 1482 passwordPolicyResponse.error = passwordExpired (0): The password 1483 has expired and there are no more grace authentications. The user 1484 must contact the password administrator to reset the password. 1486 o compareResponse.resultCode = compareTrue (6), 1487 passwordPolicyResponse.warning = timeBeforeExpiration: The user's 1488 password will expire in n number of seconds. 1490 9.5. Other Operations 1492 For operations other than bind, unbind, abandon or StartTLS, the 1493 client checks the result code and control to determine if any other 1494 actions are needed. 1496 o .resultCode = insufficientAccessRights (50), 1497 passwordPolicyResponse.error = accountLocked (1) : The password 1498 failure limit has been reached and the account is locked. The 1499 user needs to retry later or contact the password administrator to 1500 reset the password. 1502 o .resultCode = insufficientAccessRights (50), 1503 passwordPolicyResponse.error = changeAfterReset (2) : The user 1504 needs to change the password immediately. 1506 10. Administration of the Password Policy 1508 {TODO: Need to define an administrativeRole (need OID). Need to 1509 describe whether pwdPolicy admin areas can overlap} 1511 A password policy is defined for a particular subtree of the DIT by 1512 adding to an LDAP subentry whose immediate superior is the root of 1513 the subtree, the pwdPolicy auxiliary object class. The scope of the 1514 password policy is defined by the SubtreeSpecification attribute of 1515 the LDAP subentry as specified in [RFC3672]. 1517 It is possible to define password policies for different password 1518 attributes within the same pwdPolicy entry, by specifying multiple 1519 values of the pwdAttribute. But password policies could also be in 1520 separate sub entries as long as they are contained under the same 1521 LDAP subentry. 1523 Only one policy may be in effect for a given password attribute in 1524 any entry. If multiple policies exist which overlap in the range of 1525 entries affected, the resulting behavior is undefined. 1527 Modifying the password policy MUST NOT result in any change in users' 1528 entries to which the policy applies. 1530 It SHOULD be possible to overwrite the password policy for one user 1531 by defining a new policy in a subentry of the user entry. 1533 Each object that is controlled by password policy advertises the 1534 subentry that is being used to control its policy in its 1535 pwdPolicySubentry attribute. Clients wishing to examine or manage 1536 password policy for an object may interrogate the pwdPolicySubentry 1537 for that object in order to arrive at the proper pwdPolicy subentry. 1539 11. Password Policy and Replication 1541 {TODO: This section needs to be changed to highlight the pitfalls of 1542 replication, suggest some implementation choices to overcome those 1543 pitfalls, but remove prescriptive language relating to the update of 1544 state information} 1546 The pwdPolicy object defines the password policy for a portion of the 1547 DIT and MUST be replicated on all the replicas of this subtree, as 1548 any subentry would be, in order to have a consistent policy among all 1549 replicated servers. 1551 The elements of the password policy that are related to the users are 1552 stored in the entry themselves as operational attributes. As these 1553 attributes are subject to modifications even on a read-only replica, 1554 replicating them must be carefully considered. 1556 The pwdChangedTime attribute MUST be replicated on all replicas, to 1557 allow expiration of the password. 1559 The pwdReset attribute MUST be replicated on all replicas, to deny 1560 access to operations other than bind and modify password. 1562 The pwdHistory attribute MUST be replicated to writable replicas. It 1563 doesn't have to be replicated to a read-only replica, since the 1564 password will never be directly modified on this server. 1566 The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime 1567 attributes SHOULD be replicated to writable replicas, making the 1568 password policy global for all servers. When the user entry is 1569 replicated to a read-only replica, these attributes SHOULD NOT be 1570 replicated. This means that the number of failures, of grace 1571 authentications and the locking will take place on each replicated 1572 server. For example, the effective number of failed attempts on a 1573 user password will be N x M (where N is the number of servers and M 1574 the value of pwdMaxFailure attribute). Replicating these attributes 1575 to a read-only replica MAY reduce the number of tries globally but 1576 MAY also introduce some inconstancies in the way the password policy 1577 is applied. 1579 Note: there are some situations where global replication of these 1580 state attributes may not be desired. For example, if two clusters of 1581 replicas are geographically remote and joined by a slow network link, 1582 and their users only login from one of the two locations, it may be 1583 unnecessary to propagate all of the state changes from one cluster to 1584 the other. Servers SHOULD allow administrators to control which 1585 attributes are replicated on a case-by-case basis. 1587 Servers participating in a loosely consistent multi-master 1588 replication agreement SHOULD employ a mechanism which ensures 1589 uniqueness of values when populating the attributes pwdFailureTime 1590 and pwdGraceUseTime. The method of achieving this is a local matter 1591 and may consist of using a single authoritative source for the 1592 generation of unique time values, or may consist of the use of the 1593 fractional seconds part to hold a replica identifier. 1595 12. Security Considerations 1597 This document defines a set of rules to implement in an LDAP server, 1598 in order to mitigate some of the security risks associated with the 1599 use of passwords and to make it difficult for password cracking 1600 programs to break into directories. 1602 Authentication with a password MUST follow the recommendations made 1603 in [RFC4513]. 1605 Modifications of passwords SHOULD only occur when the connection is 1606 protected with confidentiality and secure authentication. 1608 Access controls SHOULD be used to restrict access to the password 1609 policy attributes. The attributes defined to maintain the password 1610 policy state information SHOULD only be modifiable by the password 1611 administrator or higher authority. The pwdHistory attribute MUST be 1612 subject to the same level of access control as the attrbute holding 1613 the password. 1615 As it is possible to define a password policy for one specific user 1616 by adding a subentry immediately under the user's entry, Access 1617 Controls SHOULD be used to restrict the use of the pwdPolicy object 1618 class or the LDAP subentry object class. 1620 When the intruder detection password policy is enforced, the LDAP 1621 directory is subject to a denial of service attack. A malicious user 1622 could deliberately lock out one specific user's account (or all of 1623 them) by sending bind requests with wrong passwords. There is no way 1624 to protect against this kind of attack. The LDAP directory server 1625 SHOULD log as much information as it can (such as client IP address) 1626 whenever an account is locked, in order to be able to identify the 1627 origin of the attack. Denying anonymous access to the LDAP directory 1628 is also a way to restrict this kind of attack. Using the login delay 1629 instead of the lockout mechanism will also help avoid this denial of 1630 service. 1632 Returning certain status codes (such as passwordPolicyResponse.error 1633 = accountLocked) allows a denial of service attacker to know that it 1634 has successfully denied service to an account. Servers SHOULD 1635 implement additional checks which return the same status when it is 1636 sensed that some number of failed authentication requests has occured 1637 on a single connection, or from a client address. Server 1638 implementors are encouraged to invent other checks similar to this in 1639 order to thwart this type of DoS attack. 1641 13. IANA Considerations 1643 <<>> 1645 14. Acknowledgement 1647 This document is based in part on prior work done by Valerie Chu from 1648 Netscape Communications Corp, published as 1649 draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera 1650 participated in early revisions of this document. 1652 15. Normative References 1654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1655 Requirement Levels", BCP 14, RFC 2119, March 1997. 1657 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 1658 AUTHorize Extension for Simple Challenge/Response", 1659 RFC 2195, September 1997. 1661 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 1662 SASL Mechanism", RFC 2831, May 2000. 1664 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 1665 RFC 3062, February 2001. 1667 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1668 Considerations for the Lightweight Directory Access 1669 Protocol (LDAP)", RFC 3383, September 2002. 1671 [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory 1672 Access Protocol (LDAP)", RFC 3672, December 2003. 1674 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1675 Security Layer (SASL)", RFC 4422, June 2006. 1677 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 1678 (LDAP): The Protocol", RFC 4511, June 2006. 1680 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 1681 (LDAP): Directory Information Models", RFC 4512, 1682 June 2006. 1684 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 1685 (LDAP): Authentication Methods and Security Mechanisms", 1686 RFC 4513, June 2006. 1688 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 1689 Syntaxes and Matching Rules", RFC 4517, June 2006. 1691 [X.680] International Telecommunications Union, "Abstract Syntax 1692 Notation One (ASN.1): Specification of basic notation", 1693 ITU-T Recommendation X.680, July 2002. 1695 [X.690] International Telecommunications Union, "Information 1696 Technology - ASN.1 encoding rules: Specification of Basic 1697 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1698 Distinguished Encoding Rules (DER)", ITU-T 1699 Recommendation X.690, July 2002. 1701 Authors' Addresses 1703 Jim Sermersheim 1704 Novell, Inc 1705 1800 South Novell Place 1706 Provo, Utah 84606 1707 US 1709 Phone: +1 801 861-3088 1710 Email: jimse@novell.com 1712 Ludovic Poitou 1713 Sun Microsystems 1714 180, Avenue de l'Europe 1715 Zirst de Montbonnot, Saint Ismier cedex 38334 1716 FR 1718 Phone: +33 476 188 212 1719 Email: ludovic.poitou@sun.com 1721 Howard Chu (editor) 1722 Symas Corp. 1723 18740 Oxnard Street, Suite 313A 1724 Tarzana, California 91356 1725 US 1727 Phone: +1 818 757-7087 1728 Email: hyc@symas.com