1 2 3 4Network Working Group J. Sermersheim 5Internet-Draft Novell, Inc 6Intended status: Standards Track L. Poitou 7Expires: February 10, 2010 Sun Microsystems 8 H. Chu, Ed. 9 Symas Corp. 10 August 9, 2009 11 12 13 Password Policy for LDAP Directories 14 draft-behera-ldap-password-policy-10.txt 15 16Status of this Memo 17 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on February 10, 2010. 38 39Copyright Notice 40 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 43 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 49 50 51 52 53 54 55Sermersheim, et al. Expires February 10, 2010 [Page 1] 56 57Internet-Draft Password Policy for LDAP Directories August 2009 58 59 60Abstract 61 62 Password policy as described in this document is a set of rules that 63 controls how passwords are used and administered in Lightweight 64 Directory Access Protocol (LDAP) based directories. In order to 65 improve the security of LDAP directories and make it difficult for 66 password cracking programs to break into directories, it is desirable 67 to enforce a set of rules on password usage. These rules are made to 68 ensure that users change their passwords periodically, passwords meet 69 construction requirements, the re-use of old password is restricted, 70 and to deter password guessing attacks. 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Sermersheim, et al. Expires February 10, 2010 [Page 2] 112 113Internet-Draft Password Policy for LDAP Directories August 2009 114 115 116Table of Contents 117 118 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 119 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5 120 3. Application of Password Policy . . . . . . . . . . . . . . . 6 121 4. Articles of Password Policy . . . . . . . . . . . . . . . . 7 122 4.1. Password Usage Policy . . . . . . . . . . . . . . . . . . . 7 123 4.2. Password Modification Policy . . . . . . . . . . . . . . . . 8 124 4.3. Restriction of the Password Policy . . . . . . . . . . . . . 10 125 5. Schema used for Password Policy . . . . . . . . . . . . . . 12 126 5.1. The pwdPolicy Object Class . . . . . . . . . . . . . . . . . 12 127 5.2. Attribute Types used in the pwdPolicy ObjectClass . . . . . 12 128 5.3. Attribute Types for Password Policy State Information . . . 18 129 6. Controls used for Password Policy . . . . . . . . . . . . . 24 130 6.1. Request Control . . . . . . . . . . . . . . . . . . . . . . 24 131 6.2. Response Control . . . . . . . . . . . . . . . . . . . . . . 24 132 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . 26 133 7.1. Locked Account Check . . . . . . . . . . . . . . . . . . . . 26 134 7.2. Password Must be Changed Now Check . . . . . . . . . . . . . 26 135 7.3. Password Expiration Check . . . . . . . . . . . . . . . . . 27 136 7.4. Remaining Grace AuthN Check . . . . . . . . . . . . . . . . 27 137 7.5. Time Before Expiration Check . . . . . . . . . . . . . . . . 27 138 7.6. Intruder Lockout Check . . . . . . . . . . . . . . . . . . . 27 139 7.7. Intruder Delay Check . . . . . . . . . . . . . . . . . . . . 27 140 7.8. Password Too Young Check . . . . . . . . . . . . . . . . . . 28 141 8. Server Policy Enforcement Points . . . . . . . . . . . . . . 29 142 8.1. Password-based Authentication . . . . . . . . . . . . . . . 29 143 8.2. Password Update Operations . . . . . . . . . . . . . . . . . 31 144 8.3. Other Operations . . . . . . . . . . . . . . . . . . . . . . 34 145 9. Client Policy Enforcement Points . . . . . . . . . . . . . . 35 146 9.1. Bind Operation . . . . . . . . . . . . . . . . . . . . . . . 35 147 9.2. Modify Operations . . . . . . . . . . . . . . . . . . . . . 36 148 9.3. Add Operation . . . . . . . . . . . . . . . . . . . . . . . 37 149 9.4. Compare Operation . . . . . . . . . . . . . . . . . . . . . 37 150 9.5. Other Operations . . . . . . . . . . . . . . . . . . . . . . 38 151 10. Administration of the Password Policy . . . . . . . . . . . 39 152 11. Password Policy and Replication . . . . . . . . . . . . . . 40 153 12. Security Considerations . . . . . . . . . . . . . . . . . . 42 154 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 155 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 44 156 15. Normative References . . . . . . . . . . . . . . . . . . . . 45 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 158 159 160 161 162 163 164 165 166 167Sermersheim, et al. Expires February 10, 2010 [Page 3] 168 169Internet-Draft Password Policy for LDAP Directories August 2009 170 171 1721. Overview 173 174 LDAP-based directory services are currently accepted by many 175 organizations as the access protocol for directories. The ability to 176 ensure the secure read and update access to directory information 177 throughout the network is essential to the successful deployment. 178 Most LDAP implementations support many authentication schemes - the 179 most basic and widely used is the simple authentication i.e., user DN 180 and password. In this case, many LDAP servers have implemented some 181 kind of policy related to the password used to authenticate. Among 182 other things, this policy includes: 183 184 o Whether and when passwords expire. 185 186 o Whether failed bind attempts cause the account to be locked. 187 188 o If and how users are able to change their passwords. 189 190 In order to achieve greater security protection and ensure 191 interoperability in a heterogeneous environment, LDAP needs to 192 standardize on a common password policy model. This is critical to 193 the successful deployment of LDAP directories. 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Sermersheim, et al. Expires February 10, 2010 [Page 4] 224 225Internet-Draft Password Policy for LDAP Directories August 2009 226 227 2282. Conventions 229 230 Imperative keywords defined in [RFC2119] are used in this document, 231 and carry the meanings described there. 232 233 All ASN.1 [X.680] Basic Encoding Rules (BER) [X.690] encodings follow 234 the conventions found in Section 5.1 of [RFC4511]. 235 236 The term "password administrator" refers to a user that has 237 sufficient access control privileges to modify users' passwords. The 238 term "password policy administrator" refers to a user that has 239 sufficient access control privileges to modify the pwdPolicy object 240 defined in this document. The access control that is used to 241 determine whether an identity is a password administrator or password 242 policy administrator is beyond the scope of this document, but 243 typically implies that the password administrator has 'write' 244 privileges to the password attribute. 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Sermersheim, et al. Expires February 10, 2010 [Page 5] 280 281Internet-Draft Password Policy for LDAP Directories August 2009 282 283 2843. Application of Password Policy 285 286 The password policy defined in this document can be applied to any 287 attribute holding a user's password used for an authenticated LDAP 288 bind operation. In this document, the term "user" represents any 289 LDAP client application that has an identity in the directory. 290 291 This policy is typically applied to the userPassword attribute in the 292 case of the LDAP simple authentication method [RFC4511] or the case 293 of password based SASL [RFC4422] authentication such as CRAM-MD5 294 [RFC2195] and DIGEST-MD5 [RFC2831]. 295 296 The policy described in this document assumes that the password 297 attribute holds a single value. No considerations are made for 298 directories or systems that allow a user to maintain multi-valued 299 password attributes. 300 301 Server implementations MAY institute internal policy whereby certain 302 identities (such as directory administrators) are not forced to 303 comply with any of password policy. In this case, the password for a 304 directory administrator never expires; the account is never locked, 305 etc. 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Sermersheim, et al. Expires February 10, 2010 [Page 6] 336 337Internet-Draft Password Policy for LDAP Directories August 2009 338 339 3404. Articles of Password Policy 341 342 The following sections explain in general terms each aspect of the 343 password policy defined in this document as well as the need for 344 each. These policies are subdivided into the general groups of 345 password usage and password modification. Implementation details are 346 presented in Section 8 and Section 9. 347 3484.1. Password Usage Policy 349 350 This section describes policy enforced when a password is used to 351 authenticate. The general focus of this policy is to minimize the 352 threat of intruders once a password is in use. 353 3544.1.1. Password Validity Policy 355 356 These mechanisms allow account usage to be controlled independent of 357 any password expiration policies. The policy defines the absolute 358 period of time for which an account may be used. This allows an 359 administrator to define an absolute starting time after which a 360 password becomes valid, and an absolute ending time after which the 361 password is disabled. 362 363 A mechanism is also provided to define the period of time for which 364 an account may remain unused before being disabled. 365 3664.1.2. Password Guessing Limit 367 368 In order to prevent intruders from guessing a user's password, a 369 mechanism exists to track the number of consecutive failed 370 authentication attempts, and take action when a limit is reached. 371 This policy consists of several parts: 372 373 o A counter to track the number of failed authentication attempts. 374 375 o The amount of time to delay on the first authentication failure. 376 377 o The maximum amount of time to delay on subsequent failures. 378 379 o A timeframe in which the limit of consecutive failed 380 authentication attempts must happen before action is taken. 381 382 o A configurable limit on failed authentication attempts. 383 384 o The action to be taken when the limit is reached. The action will 385 either be nothing, or the account will be locked. 386 387 388 389 390 391Sermersheim, et al. Expires February 10, 2010 [Page 7] 392 393Internet-Draft Password Policy for LDAP Directories August 2009 394 395 396 o An amount of time the account is locked (if it is to be locked). 397 This can be indefinite. 398 399 Note that using the account lock feature provides an easy avenue for 400 Denial-of-Service (DoS) attacks on user accounts. While some sites' 401 policies require accounts to be locked, this feature is discouraged 402 in favor of delaying each failed login attempt. 403 404 The delay time will be doubled on each subsequent failure, until it 405 reaches the maximum time configured. 406 407 [TBD: we could also provide a syntax for configuring a backoff 408 algorithm. E.g. "+<int>" for linearly incrementing delay, "x<int>" 409 for constant multiplier, "^<int> for geometric. But it's probably 410 overkill to add a calculator language to the server.] 411 4124.2. Password Modification Policy 413 414 This section describes policy enforced while users are modifying 415 passwords. The general focus of this policy is to ensure that when 416 users add or change their passwords, the security and effectiveness 417 of their passwords is maximized. In this document, the term "modify 418 password operation" refers to any operation that is used to add or 419 modify a password attribute. Often this is done by updating the 420 password attribute during an add or modify operation, but MAY be done 421 by other means such as an extended operation. 422 4234.2.1. Password Expiration, Expiration Warning, and Grace 424 Authentications 425 426 One of the key properties of a password is the fact that it is not 427 well known. If a password is frequently changed, the chances of that 428 user's account being broken into are minimized. 429 430 Password policy administrators may deploy a password policy that 431 causes passwords to expire after a given amount of time - thus 432 forcing users to change their passwords periodically. 433 434 As a side effect, there needs to be a way in which users are made 435 aware of this need to change their password before actually being 436 locked out of their accounts. One or both of the following methods 437 handle this: 438 439 o A warning may be returned to the user sometime before his password 440 is due to expire. If the user fails to heed this warning before 441 the expiration time, his account will be locked. 442 443 444 445 446 447Sermersheim, et al. Expires February 10, 2010 [Page 8] 448 449Internet-Draft Password Policy for LDAP Directories August 2009 450 451 452 o The user may bind to the directory a preset number of times after 453 her password has expired. If she fails to change her password 454 during one of her 'grace' authentications, her account will be 455 locked. 456 4574.2.2. Password History 458 459 When the Password Expiration policy is used, an additional mechanism 460 may be employed to prevent users from simply re-using a previous 461 password (as this would effectively circumvent the expiration 462 policy). 463 464 In order to do this; a history of used passwords is kept. The 465 password policy administrator sets the number of passwords to be 466 stored at any given time. Passwords are stored in this history 467 whenever the password is changed. Users aren't allowed to specify 468 any passwords that are in the history list while changing passwords. 469 4704.2.3. Password Minimum Age 471 472 Users may circumvent the Password History mechanism by quickly 473 performing a series of password changes. If they change their 474 password enough times, their 'favorite' password will be pushed out 475 of the history list. 476 477 This process may be made less attractive to users by employing a 478 minimum age for passwords. If users are forced to wait 24 hours 479 between password changes, they may be less likely to cycle through a 480 history of 10 passwords. 481 4824.2.4. Password Quality and Minimum length 483 484 In order to prevent users from creating or updating passwords that 485 are easy to guess, a password quality policy may be employed. This 486 policy consists of two general mechanisms - ensuring that passwords 487 conform to a defined quality criterion and ensuring that they are of 488 a minimum length. 489 490 Forcing a password to comply with the quality policy may imply a 491 variety of things including: 492 493 o Disallowing trivial or well-known words make up the password. 494 495 o Forcing a certain number of digits be used. 496 497 o Disallowing anagrams of the user's name. 498 499 The implementation of this policy meets with the following problems: 500 501 502 503Sermersheim, et al. Expires February 10, 2010 [Page 9] 504 505Internet-Draft Password Policy for LDAP Directories August 2009 506 507 508 o If the password to be added or updated is encrypted by the client 509 before being sent, the server has no way of enforcing this policy. 510 Therefore, the onus of enforcing this policy falls upon client 511 implementations. 512 513 o There are no specific definitions of what 'quality checking' 514 means. This can lead to unexpected behavior in a heterogeneous 515 environment. 516 5174.2.5. User Defined Passwords 518 519 In some cases, it is desirable to disallow users from adding and 520 updating their own passwords. This policy makes this functionality 521 possible. 522 5234.2.6. Password Change after Reset 524 525 This policy forces the user to update her password after it has been 526 set for the first time, or has been reset by a password 527 administrator. 528 529 This is needed in scenarios where a password administrator has set or 530 reset the password to a well-known value. 531 5324.2.7. Safe Modification 533 534 As directories become more commonly used, it will not be unusual for 535 clients to connect to a directory and leave the connection open for 536 an extended period. This opens up the possibility for an intruder to 537 make modifications to a user's password while that user's computer is 538 connected but unattended. 539 540 This policy forces the user to prove his identity by specifying the 541 old password during a password modify operation. 542 543 {TODO: This allows a dictionary attack unless we specify that this is 544 also subject to intruder detection. One solution is to require users 545 to authN prior to changing password. Another solution is to perform 546 intruder detection checks when the password for a non-authenticated 547 identity is being updated} 548 5494.3. Restriction of the Password Policy 550 551 The password policy defined in this document can apply to any 552 attribute containing a password. Password policy state information 553 is held in the user's entry, and applies to a password attribute, not 554 a particular password attribute value. Thus the server SHOULD 555 enforce that the password attribute subject to password policy, 556 557 558 559Sermersheim, et al. Expires February 10, 2010 [Page 10] 560 561Internet-Draft Password Policy for LDAP Directories August 2009 562 563 564 contains one and only one password value. 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Sermersheim, et al. Expires February 10, 2010 [Page 11] 616 617Internet-Draft Password Policy for LDAP Directories August 2009 618 619 6205. Schema used for Password Policy 621 622 The schema elements defined here fall into two general categories. A 623 password policy object class is defined which contains a set of 624 administrative password policy attributes, and a set of operational 625 attributes are defined that hold general password policy state 626 information for each user. 627 6285.1. The pwdPolicy Object Class 629 630 This object class contains the attributes defining a password policy 631 in effect for a set of users. Section 10 describes the 632 administration of this object, and the relationship between it and 633 particular objects. 634 635 ( 1.3.6.1.4.1.42.2.27.8.2.1 636 NAME 'pwdPolicy' 637 SUP top 638 AUXILIARY 639 MUST ( pwdAttribute ) 640 MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ 641 pwdMinLength $ pwdMaxLength $ pwdExpireWarning $ 642 pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $ 643 pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ 644 pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $ 645 pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) ) 646 6475.2. Attribute Types used in the pwdPolicy ObjectClass 648 649 Following are the attribute types used by the pwdPolicy object class. 650 6515.2.1. pwdAttribute 652 653 This holds the name of the attribute to which the password policy is 654 applied. For example, the password policy may be applied to the 655 userPassword attribute. 656 657 ( 1.3.6.1.4.1.42.2.27.8.1.1 658 NAME 'pwdAttribute' 659 EQUALITY objectIdentifierMatch 660 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 661 6625.2.2. pwdMinAge 663 664 This attribute holds the number of seconds that must elapse between 665 modifications to the password. If this attribute is not present, 0 666 seconds is assumed. 667 668 669 670 671Sermersheim, et al. Expires February 10, 2010 [Page 12] 672 673Internet-Draft Password Policy for LDAP Directories August 2009 674 675 676 ( 1.3.6.1.4.1.42.2.27.8.1.2 677 NAME 'pwdMinAge' 678 EQUALITY integerMatch 679 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 680 SINGLE-VALUE ) 681 6825.2.3. pwdMaxAge 683 684 This attribute holds the number of seconds after which a modified 685 password will expire. 686 687 If this attribute is not present, or if the value is 0 the password 688 does not expire. If not 0, the value must be greater than or equal 689 to the value of the pwdMinAge. 690 691 ( 1.3.6.1.4.1.42.2.27.8.1.3 692 NAME 'pwdMaxAge' 693 EQUALITY integerMatch 694 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 695 SINGLE-VALUE ) 696 6975.2.4. pwdInHistory 698 699 This attribute specifies the maximum number of used passwords stored 700 in the pwdHistory attribute. 701 702 If this attribute is not present, or if the value is 0, used 703 passwords are not stored in the pwdHistory attribute and thus may be 704 reused. 705 706 ( 1.3.6.1.4.1.42.2.27.8.1.4 707 NAME 'pwdInHistory' 708 EQUALITY integerMatch 709 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 710 SINGLE-VALUE ) 711 7125.2.5. pwdCheckQuality 713 714 {TODO: Consider changing the syntax to OID. Each OID will list a 715 quality rule (like min len, # of special characters, etc). These 716 rules can be specified outside this document.} 717 718 {TODO: Note that even though this is meant to be a check that happens 719 during password modification, it may also be allowed to happen during 720 authN. This is useful for situations where the password is encrypted 721 when modified, but decrypted when used to authN.} 722 723 This attribute indicates how the password quality will be verified 724 725 726 727Sermersheim, et al. Expires February 10, 2010 [Page 13] 728 729Internet-Draft Password Policy for LDAP Directories August 2009 730 731 732 while being modified or added. If this attribute is not present, or 733 if the value is '0', quality checking will not be enforced. A value 734 of '1' indicates that the server will check the quality, and if the 735 server is unable to check it (due to a hashed password or other 736 reasons) it will be accepted. A value of '2' indicates that the 737 server will check the quality, and if the server is unable to verify 738 it, it will return an error refusing the password. 739 740 ( 1.3.6.1.4.1.42.2.27.8.1.5 741 NAME 'pwdCheckQuality' 742 EQUALITY integerMatch 743 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 744 SINGLE-VALUE ) 745 7465.2.6. pwdMinLength 747 748 When quality checking is enabled, this attribute holds the minimum 749 number of characters that must be used in a password. If this 750 attribute is not present, no minimum password length will be 751 enforced. If the server is unable to check the length (due to a 752 hashed password or otherwise), the server will, depending on the 753 value of the pwdCheckQuality attribute, either accept the password 754 without checking it ('0' or '1') or refuse it ('2'). 755 756 ( 1.3.6.1.4.1.42.2.27.8.1.6 757 NAME 'pwdMinLength' 758 EQUALITY integerMatch 759 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 760 SINGLE-VALUE ) 761 7625.2.7. pwdMaxLength 763 764 When quality checking is enabled, this attribute holds the maximum 765 number of characters that may be used in a password. If this 766 attribute is not present, no maximum password length will be 767 enforced. If the server is unable to check the length (due to a 768 hashed password or otherwise), the server will, depending on the 769 value of the pwdCheckQuality attribute, either accept the password 770 without checking it ('0' or '1') or refuse it ('2'). 771 772 ( 1.3.6.1.4.1.42.2.27.8.1.31 773 NAME 'pwdMaxLength' 774 EQUALITY integerMatch 775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 776 SINGLE-VALUE ) 777 778 779 780 781 782 783Sermersheim, et al. Expires February 10, 2010 [Page 14] 784 785Internet-Draft Password Policy for LDAP Directories August 2009 786 787 7885.2.8. pwdExpireWarning 789 790 This attribute specifies the maximum number of seconds before a 791 password is due to expire that expiration warning messages will be 792 returned to an authenticating user. 793 794 If this attribute is not present, or if the value is 0 no warnings 795 will be returned. If not 0, the value must be smaller than the value 796 of the pwdMaxAge attribute. 797 798 ( 1.3.6.1.4.1.42.2.27.8.1.7 799 NAME 'pwdExpireWarning' 800 EQUALITY integerMatch 801 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 802 SINGLE-VALUE ) 803 8045.2.9. pwdGraceAuthNLimit 805 806 This attribute specifies the number of times an expired password can 807 be used to authenticate. If this attribute is not present or if the 808 value is 0, authentication will fail. 809 810 ( 1.3.6.1.4.1.42.2.27.8.1.8 811 NAME 'pwdGraceAuthNLimit' 812 EQUALITY integerMatch 813 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 814 SINGLE-VALUE ) 815 8165.2.10. pwdGraceExpiry 817 818 This attribute specifies the number of seconds the grace 819 authentications are valid. If this attribute is not present or if 820 the value is 0, there is no time limit on the grace authentications. 821 822 ( 1.3.6.1.4.1.42.2.27.8.1.30 823 NAME 'pwdGraceExpire' 824 EQUALITY integerMatch 825 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 826 SINGLE-VALUE ) 827 8285.2.11. pwdLockout 829 830 This attribute indicates, when its value is "TRUE", that the password 831 may not be used to authenticate after a specified number of 832 consecutive failed bind attempts. The maximum number of consecutive 833 failed bind attempts is specified in pwdMaxFailure. 834 835 If this attribute is not present, or if the value is "FALSE", the 836 837 838 839Sermersheim, et al. Expires February 10, 2010 [Page 15] 840 841Internet-Draft Password Policy for LDAP Directories August 2009 842 843 844 password may be used to authenticate when the number of failed bind 845 attempts has been reached. 846 847 ( 1.3.6.1.4.1.42.2.27.8.1.9 848 NAME 'pwdLockout' 849 EQUALITY booleanMatch 850 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 851 SINGLE-VALUE ) 852 8535.2.12. pwdLockoutDuration 854 855 This attribute holds the number of seconds that the password cannot 856 be used to authenticate due to too many failed bind attempts. If 857 this attribute is not present, or if the value is 0 the password 858 cannot be used to authenticate until reset by a password 859 administrator. 860 861 ( 1.3.6.1.4.1.42.2.27.8.1.10 862 NAME 'pwdLockoutDuration' 863 EQUALITY integerMatch 864 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 865 SINGLE-VALUE ) 866 8675.2.13. pwdMaxFailure 868 869 This attribute specifies the number of consecutive failed bind 870 attempts after which the password may not be used to authenticate. 871 If this attribute is not present, or if the value is 0, this policy 872 is not checked, and the value of pwdLockout will be ignored. 873 874 ( 1.3.6.1.4.1.42.2.27.8.1.11 875 NAME 'pwdMaxFailure' 876 EQUALITY integerMatch 877 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 878 SINGLE-VALUE ) 879 8805.2.14. pwdFailureCountInterval 881 882 This attribute holds the number of seconds after which the password 883 failures are purged from the failure counter, even though no 884 successful authentication occurred. 885 886 If this attribute is not present, or if its value is 0, the failure 887 counter is only reset by a successful authentication. 888 889 890 891 892 893 894 895Sermersheim, et al. Expires February 10, 2010 [Page 16] 896 897Internet-Draft Password Policy for LDAP Directories August 2009 898 899 900 ( 1.3.6.1.4.1.42.2.27.8.1.12 901 NAME 'pwdFailureCountInterval' 902 EQUALITY integerMatch 903 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 904 SINGLE-VALUE ) 905 9065.2.15. pwdMustChange 907 908 This attribute specifies with a value of "TRUE" that users must 909 change their passwords when they first bind to the directory after a 910 password is set or reset by a password administrator. If this 911 attribute is not present, or if the value is "FALSE", users are not 912 required to change their password upon binding after the password 913 administrator sets or resets the password. This attribute is not set 914 due to any actions specified by this document, it is typically set by 915 a password administrator after resetting a user's password. 916 917 ( 1.3.6.1.4.1.42.2.27.8.1.13 918 NAME 'pwdMustChange' 919 EQUALITY booleanMatch 920 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 921 SINGLE-VALUE ) 922 9235.2.16. pwdAllowUserChange 924 925 This attribute indicates whether users can change their own 926 passwords, although the change operation is still subject to access 927 control. If this attribute is not present, a value of "TRUE" is 928 assumed. This attribute is intended to be used in the absence of an 929 access control mechanism. 930 931 ( 1.3.6.1.4.1.42.2.27.8.1.14 932 NAME 'pwdAllowUserChange' 933 EQUALITY booleanMatch 934 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 935 SINGLE-VALUE ) 936 9375.2.17. pwdSafeModify 938 939 This attribute specifies whether or not the existing password must be 940 sent along with the new password when being changed. If this 941 attribute is not present, a "FALSE" value is assumed. 942 943 ( 1.3.6.1.4.1.42.2.27.8.1.15 944 NAME 'pwdSafeModify' 945 EQUALITY booleanMatch 946 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 947 SINGLE-VALUE ) 948 949 950 951Sermersheim, et al. Expires February 10, 2010 [Page 17] 952 953Internet-Draft Password Policy for LDAP Directories August 2009 954 955 9565.2.18. pwdMinDelay 957 958 This attribute specifies the number of seconds to delay responding to 959 the first failed authentication attempt. If this attribute is not 960 set or is 0, no delays will be used. pwdMaxDelay must also be 961 specified if pwdMinDelay is set. 962 963 ( 1.3.6.1.4.1.42.2.27.8.1.24 964 NAME 'pwdMinDelay' 965 EQUALITY integerMatch 966 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 967 SINGLE-VALUE ) 968 9695.2.19. pwdMaxDelay 970 971 This attribute specifies the maximum number of seconds to delay when 972 responding to a failed authentication attempt. The time specified in 973 pwdMinDelay is used as the starting time and is then doubled on each 974 failure until the delay time is greater than or equal to pwdMaxDelay 975 (or a successful authentication occurs, which resets the failure 976 counter). pwdMinDelay must be specified if pwdMaxDelay is set. 977 978 ( 1.3.6.1.4.1.42.2.27.8.1.25 979 NAME 'pwdMaxDelay' 980 EQUALITY integerMatch 981 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 982 SINGLE-VALUE ) 983 9845.2.20. pwdMaxIdle 985 986 This attribute specifies the number of seconds an account may remain 987 unused before it becomes locked. If this attribute is not set or is 988 0, no check is performed. 989 990 ( 1.3.6.1.4.1.42.2.27.8.1.26 991 NAME 'pwdMaxIdle' 992 EQUALITY integerMatch 993 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 994 SINGLE-VALUE ) 995 9965.3. Attribute Types for Password Policy State Information 997 998 Password policy state information must be maintained for each user. 999 The information is located in each user entry as a set of operational 1000 attributes. These operational attributes are: pwdChangedTime, 1001 pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime, 1002 pwdReset, pwdPolicySubEntry, pwdStartTime, pwdEndTime, 1003 pwdLastSuccess. 1004 1005 1006 1007Sermersheim, et al. Expires February 10, 2010 [Page 18] 1008 1009Internet-Draft Password Policy for LDAP Directories August 2009 1010 1011 10125.3.1. Password Policy State Attribute Option 1013 1014 Since the password policy could apply to several attributes used to 1015 store passwords, each of the above operational attributes must have 1016 an option to specify which pwdAttribute it applies to. The password 1017 policy option is defined as the following: 1018 1019 pwd-<passwordAttribute> 1020 1021 where passwordAttribute a string following the OID syntax 1022 (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor 1023 (short name) MUST be used. 1024 1025 For example, if the pwdPolicy object has for pwdAttribute 1026 "userPassword" then the pwdChangedTime operational attribute, in a 1027 user entry, will be: 1028 1029 pwdChangedTime;pwd-userPassword: 20000103121520Z 1030 1031 This attribute option follows sub-typing semantics. If a client 1032 requests a password policy state attribute to be returned in a search 1033 operation, and does not specify an option, all subtypes of that 1034 policy state attribute are returned. 1035 10365.3.2. pwdChangedTime 1037 1038 This attribute specifies the last time the entry's password was 1039 changed. This is used by the password expiration policy. If this 1040 attribute does not exist, the password will never expire. 1041 1042 ( 1.3.6.1.4.1.42.2.27.8.1.16 1043 NAME 'pwdChangedTime' 1044 DESC 'The time the password was last changed' 1045 EQUALITY generalizedTimeMatch 1046 ORDERING generalizedTimeOrderingMatch 1047 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1048 SINGLE-VALUE 1049 NO-USER-MODIFICATION 1050 USAGE directoryOperation ) 1051 10525.3.3. pwdAccountLockedTime 1053 1054 This attribute holds the time that the user's account was locked. A 1055 locked account means that the password may no longer be used to 1056 authenticate. A 000001010000Z value means that the account has been 1057 locked permanently, and that only a password administrator can unlock 1058 the account. 1059 1060 1061 1062 1063Sermersheim, et al. Expires February 10, 2010 [Page 19] 1064 1065Internet-Draft Password Policy for LDAP Directories August 2009 1066 1067 1068 ( 1.3.6.1.4.1.42.2.27.8.1.17 1069 NAME 'pwdAccountLockedTime' 1070 DESC 'The time an user account was locked' 1071 EQUALITY generalizedTimeMatch 1072 ORDERING generalizedTimeOrderingMatch 1073 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1074 SINGLE-VALUE 1075 NO-USER-MODIFICATION 1076 USAGE directoryOperation ) 1077 10785.3.4. pwdFailureTime 1079 1080 This attribute holds the timestamps of the consecutive authentication 1081 failures. 1082 1083 ( 1.3.6.1.4.1.42.2.27.8.1.19 1084 NAME 'pwdFailureTime' 1085 DESC 'The timestamps of the last consecutive authentication 1086 failures' 1087 EQUALITY generalizedTimeMatch 1088 ORDERING generalizedTimeOrderingMatch 1089 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1090 NO-USER-MODIFICATION 1091 USAGE directoryOperation ) 1092 10935.3.5. pwdHistory 1094 1095 This attribute holds a history of previously used passwords. Values 1096 of this attribute are transmitted in string format as given by the 1097 following ABNF: 1098 1099 pwdHistory = time "#" syntaxOID "#" length "#" data 1100 1101 time = GeneralizedTime 1102 1103 syntaxOID = numericoid ; the string representation of the 1104 ; dotted-decimal OID that defines the 1105 ; syntax used to store the password. 1106 1107 length = number ; the number of octets in data. 1108 1109 data = <octets representing the password in the format 1110 specified by syntaxOID>. 1111 1112 GeneralizedTime is specified in 3.3.13 of [RFC4517]. numericoid and 1113 number are specified in 1.4 of [RFC4512]. 1114 1115 This format allows the server to store, and transmit a history of 1116 1117 1118 1119Sermersheim, et al. Expires February 10, 2010 [Page 20] 1120 1121Internet-Draft Password Policy for LDAP Directories August 2009 1122 1123 1124 passwords that have been used. In order for equality matching to 1125 function properly, the time field needs to adhere to a consistent 1126 format. For this purpose, the time field MUST be in GMT format. 1127 1128 ( 1.3.6.1.4.1.42.2.27.8.1.20 1129 NAME 'pwdHistory' 1130 DESC 'The history of user s passwords' 1131 EQUALITY octetStringMatch 1132 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1133 NO-USER-MODIFICATION 1134 USAGE directoryOperation ) 1135 11365.3.6. pwdGraceUseTime 1137 1138 This attribute holds the timestamps of grace authentications after a 1139 password has expired. 1140 1141 ( 1.3.6.1.4.1.42.2.27.8.1.21 1142 NAME 'pwdGraceUseTime' 1143 DESC 'The timestamps of the grace authentication after the 1144 password has expired' 1145 EQUALITY generalizedTimeMatch 1146 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1147 NO-USER-MODIFICATION 1148 USAGE directoryOperation ) 1149 11505.3.7. pwdReset 1151 1152 This attribute holds a flag to indicate (when TRUE) that the password 1153 has been updated by the password administrator and must be changed by 1154 the user. 1155 1156 ( 1.3.6.1.4.1.42.2.27.8.1.22 1157 NAME 'pwdReset' 1158 DESC 'The indication that the password has been reset' 1159 EQUALITY booleanMatch 1160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1161 SINGLE-VALUE 1162 USAGE directoryOperation ) 1163 11645.3.8. pwdPolicySubentry 1165 1166 This attribute points to the pwdPolicy subentry in effect for this 1167 object. 1168 1169 1170 1171 1172 1173 1174 1175Sermersheim, et al. Expires February 10, 2010 [Page 21] 1176 1177Internet-Draft Password Policy for LDAP Directories August 2009 1178 1179 1180 ( 1.3.6.1.4.1.42.2.27.8.1.23 1181 NAME 'pwdPolicySubentry' 1182 DESC 'The pwdPolicy subentry in effect for this object' 1183 EQUALITY distinguishedNameMatch 1184 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1185 SINGLE-VALUE 1186 NO-USER-MODIFICATION 1187 USAGE directoryOperation ) 1188 11895.3.9. pwdStartTime 1190 1191 This attribute specifies the time the entry's password becomes valid 1192 for authentication. Authentication attempts made before this time 1193 will fail. If this attribute does not exist, then no restriction 1194 applies. 1195 1196 ( 1.3.6.1.4.1.42.2.27.8.1.27 1197 NAME 'pwdStartTime' 1198 DESC 'The time the password becomes enabled' 1199 EQUALITY generalizedTimeMatch 1200 ORDERING generalizedTimeOrderingMatch 1201 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1202 SINGLE-VALUE 1203 NO-USER-MODIFICATION 1204 USAGE directoryOperation ) 1205 12065.3.10. pwdEndTime 1207 1208 This attribute specifies the time the entry's password becomes 1209 invalid for authentication. Authentication attempts made after this 1210 time will fail, regardless of expiration or grace settings. If this 1211 attribute does not exist, then this restriction does not apply. 1212 1213 ( 1.3.6.1.4.1.42.2.27.8.1.28 1214 NAME 'pwdEndTime' 1215 DESC 'The time the password becomes disabled' 1216 EQUALITY generalizedTimeMatch 1217 ORDERING generalizedTimeOrderingMatch 1218 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1219 SINGLE-VALUE 1220 NO-USER-MODIFICATION 1221 USAGE directoryOperation ) 1222 1223 Note that pwdStartTime may be set to a time greater than or equal to 1224 pwdEndTime; this simply disables the account. 1225 1226 1227 1228 1229 1230 1231Sermersheim, et al. Expires February 10, 2010 [Page 22] 1232 1233Internet-Draft Password Policy for LDAP Directories August 2009 1234 1235 12365.3.11. pwdLastSuccess 1237 1238 This attribute holds the timestamp of the last successful 1239 authentication. 1240 1241 ( 1.3.6.1.4.1.42.2.27.8.1.29 1242 NAME 'pwdLastSuccess' 1243 DESC 'The timestamp of the last successful authentication' 1244 EQUALITY generalizedTimeMatch 1245 ORDERING generalizedTimeOrderingMatch 1246 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1247 SINGLE-VALUE 1248 NO-USER-MODIFICATION 1249 USAGE directoryOperation ) 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287Sermersheim, et al. Expires February 10, 2010 [Page 23] 1288 1289Internet-Draft Password Policy for LDAP Directories August 2009 1290 1291 12926. Controls used for Password Policy 1293 1294 This section details the controls used while enforcing password 1295 policy. A request control is defined that is sent by a client with a 1296 request operation in order to elicit a response control. The 1297 response control contains various warnings and errors associated with 1298 password policy. 1299 1300 {TODO: add a note about advertisement and discovery} 1301 13026.1. Request Control 1303 1304 This control MAY be sent with any LDAP request message in order to 1305 convey to the server that this client is aware of, and can process 1306 the response control described in this document. When a server 1307 receives this control, it will return the response control when 1308 appropriate and with the proper data. 1309 1310 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may 1311 be TRUE or FALSE. There is no controlValue. 1312 13136.2. Response Control 1314 1315 If the client has sent a passwordPolicyRequest control, the server 1316 (when solicited by the inclusion of the request control) sends this 1317 control with the following operation responses: bindResponse, 1318 modifyResponse, addResponse, compareResponse and possibly 1319 extendedResponse, to inform of various conditions, and MAY be sent 1320 with other operations (in the case of the changeAfterReset error). 1321 The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is 1322 the BER encoding of the following type: 1323 1324 PasswordPolicyResponseValue ::= SEQUENCE { 1325 warning [0] CHOICE { 1326 timeBeforeExpiration [0] INTEGER (0 .. maxInt), 1327 graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, 1328 error [1] ENUMERATED { 1329 passwordExpired (0), 1330 accountLocked (1), 1331 changeAfterReset (2), 1332 passwordModNotAllowed (3), 1333 mustSupplyOldPassword (4), 1334 insufficientPasswordQuality (5), 1335 passwordTooShort (6), 1336 passwordTooYoung (7), 1337 passwordInHistory (8) } OPTIONAL } 1338 1339 The timeBeforeExpiration warning specifies the number of seconds 1340 1341 1342 1343Sermersheim, et al. Expires February 10, 2010 [Page 24] 1344 1345Internet-Draft Password Policy for LDAP Directories August 2009 1346 1347 1348 before a password will expire. The graceAuthNsRemaining warning 1349 specifies the remaining number of times a user will be allowed to 1350 authenticate with an expired password. The passwordExpired error 1351 signifies that the password has expired and must be reset. The 1352 changeAfterReset error signifies that the password must be changed 1353 before the user will be allowed to perform any operation other than 1354 bind and modify. The passwordModNotAllowed error is set when a user 1355 is restricted from changing her password. The 1356 insufficientPasswordQuality error is set when a password doesn't pass 1357 quality checking. The passwordTooYoung error is set if the age of 1358 the password to be modified is not yet old enough. 1359 1360 Typically, only either a warning or an error will be encoded though 1361 there may be exceptions. For example, if the user is required to 1362 change a password after the password administrator set it, and the 1363 password will expire in a short amount of time, the control may 1364 include the timeBeforeExpiration warning and the changeAfterReset 1365 error. 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399Sermersheim, et al. Expires February 10, 2010 [Page 25] 1400 1401Internet-Draft Password Policy for LDAP Directories August 2009 1402 1403 14047. Policy Decision Points 1405 1406 Following are a number of procedures used to make policy decisions. 1407 These procedures are typically performed by the server while 1408 processing an operation. 1409 1410 The following sections contain detailed instructions that refer to 1411 attributes of the pwdPolicy object class. When doing so, the 1412 attribute of the pwdPolicy object that governs the entry being 1413 discussed is implied. 1414 14157.1. Locked Account Check 1416 1417 A status of true is returned to indicate that the account is locked 1418 if any of these conditions are met: 1419 1420 o The value of the pwdAccountLockedTime attribute is 000001010000Z. 1421 1422 o The current time is less than the value of the pwdStartTime 1423 attribute. 1424 1425 o The current time is greater than or equal to the value of the 1426 pwdEndTime attribute. 1427 1428 o The current time is greater than or equal to the value of the 1429 pwdLastSuccess attribute added to the value of the pwdMaxIdle 1430 attribute. 1431 1432 o The current time is less than the value of the 1433 pwdAccountLockedTime attribute added to the value of the 1434 pwdLockoutDuration. 1435 1436 Otherwise a status of false is returned. 1437 14387.2. Password Must be Changed Now Check 1439 1440 A status of true is returned to indicate that the password must be 1441 changed if all of these conditions are met: 1442 1443 o The pwdMustChange attribute is set to TRUE. 1444 1445 o The pwdReset attribute is set to TRUE. 1446 1447 Otherwise a status of false is returned. 1448 1449 1450 1451 1452 1453 1454 1455Sermersheim, et al. Expires February 10, 2010 [Page 26] 1456 1457Internet-Draft Password Policy for LDAP Directories August 2009 1458 1459 14607.3. Password Expiration Check 1461 1462 A status of true is returned indicating that the password has expired 1463 if the current time minus the value of pwdChangedTime is greater than 1464 the value of the pwdMaxAge. 1465 1466 Otherwise, a status of false is returned. 1467 14687.4. Remaining Grace AuthN Check 1469 1470 If the pwdGraceUseTime attribute is present, the number of values in 1471 that attribute subtracted from the value of pwdGraceAuthNLimit is 1472 returned. Otherwise zero is returned. A positive result specifies 1473 the number of remaining grace authentications. 1474 14757.5. Time Before Expiration Check 1476 1477 If the pwdExpireWarning attribute is not present a zero status is 1478 returned. Otherwise the following steps are followed: 1479 1480 Subtract the time stored in pwdChangedTime from the current time to 1481 arrive at the password's age. If the password's age is greater than 1482 than the value of the pwdMaxAge attribute, a zero status is returned. 1483 Subtract the value of the pwdExpireWarning attribute from the value 1484 of the pwdMaxAge attribute to arrive at the warning age. If the 1485 password's age is equal to or greater than the warning age, the value 1486 of pwdMaxAge minus the password's age is returned. 1487 14887.6. Intruder Lockout Check 1489 1490 A status of true indicating that an intruder has been detected is 1491 returned if the following conditions are met: 1492 1493 o The pwdLockout attribute is TRUE. 1494 1495 o The number of values in the pwdFailureTime attribute that are 1496 younger than pwdFailureCountInterval is greater or equal to the 1497 pwdMaxFailure attribute. 1498 1499 Otherwise a status of false is returned. 1500 1501 While performing this check, values of pwdFailureTime that are old by 1502 more than pwdFailureCountInterval are purged and not counted. 1503 15047.7. Intruder Delay Check 1505 1506 If the pwdMinDelay attribute is 0 or not set, zero is returned. 1507 1508 1509 1510 1511Sermersheim, et al. Expires February 10, 2010 [Page 27] 1512 1513Internet-Draft Password Policy for LDAP Directories August 2009 1514 1515 1516 Otherwise, a delay time is computed based on the number of values in 1517 the pwdFailureTime attribute. If the computed value is greater than 1518 the pwdMaxDelay attribute, the pwdMaxDelay value is returned. 1519 1520 While performing this check, values of pwdFailureTime that are old by 1521 more than pwdFailureCountInterval are purged and not counted. 1522 15237.8. Password Too Young Check 1524 1525 If the Section 7.2 check returned true then this check will return 1526 false, to allow the password to be changed. 1527 1528 A status of true indicating that not enough time has passed since the 1529 password was last updated is returned if: 1530 1531 o The value of pwdMinAge is non-zero and pwdChangedTime is present. 1532 1533 o The value of pwdMinAge is greater than the current time minus the 1534 value of pwdChangedTime. 1535 1536 Otherwise a false status is returned. 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567Sermersheim, et al. Expires February 10, 2010 [Page 28] 1568 1569Internet-Draft Password Policy for LDAP Directories August 2009 1570 1571 15728. Server Policy Enforcement Points 1573 1574 The server SHOULD enforce that the password attribute subject to a 1575 password policy as defined in this document, contains one and only 1576 one password value. 1577 1578 Note: The case where a single password value is stored in multiple 1579 formats simultaneously is still considered to be only one password 1580 value. 1581 1582 The scenarios in the following operations assume that the client has 1583 attached a passwordPolicyRequest control to the request message of 1584 the operation. In the event that the passwordPolicyRequest control 1585 was not sent, no passwordPolicyResponse control is returned. All 1586 other instructions remain the same. 1587 1588 For successfully completed operations, unless otherwise stated, no 1589 passwordPolicyResponse control is returned. 1590 15918.1. Password-based Authentication 1592 1593 This section contains the policy enforcement rules and policy data 1594 updates used while validating a password. Operations that validate 1595 passwords include, but are not limited to, the Bind operation where 1596 the simple choice specifies a password, and the Compare operation 1597 where the attribute being compared holds a password. Note that while 1598 the Compare operation does not authenticate a user to the LDAP 1599 server, it may be used by an external application for purposes of 1600 authentication. 1601 16028.1.1. Fail if the account is locked 1603 1604 If the account is locked as specified in Section 7.1, the server 1605 fails the operation with an appropriate resultCode (i.e. 1606 invalidCredentials (49) in the case of a bind operation, compareFalse 1607 (5) in the case of a compare operation, etc.). The server MAY set 1608 the error: accountLocked (1) in the passwordPolicyResponse in the 1609 controls field of the message. 1610 16118.1.2. Validated Password Procedures 1612 1613 If the validation operation indicates that the password validated, 1614 these procedures are followed in order: 1615 16168.1.2.1. Policy state updates 1617 1618 Delete the pwdFailureTime and pwdAccountLockedTime attributes. 1619 1620 1621 1622 1623Sermersheim, et al. Expires February 10, 2010 [Page 29] 1624 1625Internet-Draft Password Policy for LDAP Directories August 2009 1626 1627 1628 Set the value of the pwdLastSuccess attribute to the current time. 1629 1630 Note: setting pwdLastSuccess is optional, but it is required if the 1631 policy has pwdMaxIdle defined. 1632 16338.1.2.2. Password must be changed now 1634 1635 If the decision in Section 7.2 returns true, the server sends to the 1636 client a response with an appropriate successful resultCode (i.e. 1637 success (0), compareTrue (6), etc.), and includes the 1638 passwordPolicyResponse in the controls field of the bindResponse 1639 message with the warning: changeAfterReset specified. 1640 1641 For bind, the server MUST then disallow all operations issued by this 1642 user except modify password, bind, unbind, abandon and StartTLS 1643 extended operation. 1644 16458.1.2.3. Expired password 1646 1647 If the password has expired as per Section 7.3, the server either 1648 returns a success or failure based on the state of grace 1649 authentications. 1650 16518.1.2.3.1. Remaining Grace Authentications 1652 1653 If there are remaining grace authentications as per Section 7.4, the 1654 server adds a new value with the current time in pwdGraceUseTime. 1655 Then it sends to the client a response with an appropriate successful 1656 resultCode (i.e. success (0), compareTrue (6), etc.), and includes 1657 the passwordPolicyResponse in the controls field of the response 1658 message with the warning: graceAuthNsRemaining choice set to the 1659 number of grace authentications left. 1660 1661 Implementor's note: The system time of the host machine may be more 1662 granular than is needed to ensure unique values of this attribute. 1663 It is recommended that a mechanism is used to ensure unique 1664 generalized time values. The fractional seconds field may be used 1665 for this purpose. 1666 16678.1.2.3.2. No Remaining Grace Authentications 1668 1669 If there are no remaining grace authentications, the server fails the 1670 operation with an appropriate resultCode (invalidCredentials (49), 1671 compareFalse (5), etc.), and includes the passwordPolicyResponse in 1672 the controls field of the bindResponse message with the error: 1673 passwordExpired (0) set. 1674 1675 1676 1677 1678 1679Sermersheim, et al. Expires February 10, 2010 [Page 30] 1680 1681Internet-Draft Password Policy for LDAP Directories August 2009 1682 1683 16848.1.2.4. Expiration Warning 1685 1686 If the result of Section 7.5 is a positive number, the server sends 1687 to the client a response with an appropriate successful resultCode 1688 (i.e. success (0), compareTrue (6), etc.), and includes the 1689 passwordPolicyResponse in the controls field of the bindResponse 1690 message with the warning: timeBeforeExiration set to the value as 1691 described above. Otherwise, the server sends a successful response, 1692 and omits the passwordPolicyResponse. 1693 16948.1.3. AuthN Failed Procedures 1695 1696 If the authentication process indicates that the password failed 1697 validation due to invalid credentials, these procedures are followed: 1698 16998.1.3.1. Policy state update 1700 1701 Add the current time as a value of the pwdFailureTime attribute. 1702 1703 Implementor's note: The system time of the host machine may be more 1704 granular than is needed to ensure unique values of this attribute. 1705 It is recommended that a mechanism is used to ensure unique 1706 generalized time values. The fractional seconds field may be used 1707 for this purpose. 1708 17098.1.3.2. Handle Intruder Detection 1710 1711 If the check in Section 7.6 returns a true state, the server locks 1712 the account by setting the value of the pwdAccountLockedTime 1713 attribute to the current time. After locking the account, the server 1714 fails the operation with an appropriate resultCode 1715 (invalidCredentials (49), compareFalse (5), etc.), and includes the 1716 passwordPolicyResponse in the controls field of the message with the 1717 error: accountLocked (1). 1718 1719 If the check in Section 7.7 returns a non-zero value, the server 1720 waits that number of seconds before sending the authentication 1721 response back to the client. 1722 17238.2. Password Update Operations 1724 1725 Because the password is stored in an attribute, various operations 1726 (like add and modify) may be used to create or update a password. 1727 But some alternate mechanisms have been defined or may be defined, 1728 such as the LDAP Password Modify Extended Operation [RFC3062]. 1729 1730 While processing a password update, the server performs the following 1731 steps: 1732 1733 1734 1735Sermersheim, et al. Expires February 10, 2010 [Page 31] 1736 1737Internet-Draft Password Policy for LDAP Directories August 2009 1738 1739 17408.2.1. Safe Modification 1741 1742 If pwdSafeModify is set to TRUE and if there is an existing password 1743 value, the server ensures that the password update operation includes 1744 the user's existing password. 1745 1746 When the LDAP modify operation is used to modify a password, this is 1747 done by specifying both a delete action and an add or replace action, 1748 where the delete action specifies the existing password, and the add 1749 or replace action specifies the new password. Other password update 1750 operations SHOULD employ a similar mechanism. Otherwise this policy 1751 will fail. 1752 1753 If the existing password is not specified, the server does not 1754 process the operation and sends the appropriate response message to 1755 the client with the resultCode: insufficientAccessRights (50), and 1756 includes the passwordPolicyResponse in the controls field of the 1757 response message with the error: mustSupplyOldPassword (4). 1758 17598.2.2. Change After Reset 1760 1761 If the decision in Section 7.2 returns true, the server ensures that 1762 the password update operation contains no modifications other than 1763 the modification of the password attribute. If other modifications 1764 exist, the server sends a response message to the client with the 1765 resultCode: insufficientAccessRights (50), and includes the 1766 passwordPolicyResponse in the controls field of the response message 1767 with the error: changeAfterReset (2). 1768 17698.2.3. Rights Check 1770 1771 Check to see whether the bound identity has sufficient rights to 1772 update the password. If the bound identity is a user changing its 1773 own password, this MAY be done by checking the pwdAllowUserChange 1774 attribute or using an access control mechanism. The determination of 1775 this is implementation specific. If the user is not allowed to 1776 update her password, the server sends a response message to the 1777 client with the resultCode: insufficientAccessRights (50), and 1778 includes the passwordPolicyResponse in the controls field of the 1779 response message with the error: passwordModNotAllowed (3). 1780 17818.2.4. Too Early to Update 1782 1783 If the check in Section 7.8 results in a true status The server sends 1784 a response message to the client with the resultCode: 1785 constraintViolation (19), and includes the passwordPolicyResponse in 1786 the controls field of the response message with the error: 1787 passwordTooYoung (7). 1788 1789 1790 1791Sermersheim, et al. Expires February 10, 2010 [Page 32] 1792 1793Internet-Draft Password Policy for LDAP Directories August 2009 1794 1795 17968.2.5. Password Quality 1797 1798 Check the value of the pwdCheckQuality attribute. If the value is 1799 non-zero, the server: 1800 1801 o Ensure that the password meets the quality criteria enforced by 1802 the server. This enforcement is implementation specific. If the 1803 server is unable to check the quality (due to a hashed password or 1804 otherwise), the value of pwdCheckQuality is evaluated. If the 1805 value is 1, operation continues. If the value is 2, the server 1806 sends a response message to the client with the resultCode: 1807 constraintViolation (19), and includes the passwordPolicyResponse 1808 in the controls field of the response message with the error: 1809 insufficientPasswordQuality (5). If the server is able to check 1810 the password quality, and the check fails, the server sends a 1811 response message to the client with the resultCode: 1812 constraintViolation (19), and includes the passwordPolicyResponse 1813 in the controls field of the response message with the error: 1814 insufficientPasswordQuality (5). 1815 1816 o checks the value of the pwdMinLength attribute. If the value is 1817 non-zero, it ensures that the new password is of at least the 1818 minimum length. If the server is unable to check the length (due 1819 to a hashed password or otherwise), the value of pwdCheckQuality 1820 is evaluated. If the value is 1, operation continues. If the 1821 value is 2, the server sends a response message to the client with 1822 the resultCode: constraintViolation (19), and includes the 1823 passwordPolicyResponse in the controls field of the response 1824 message with the error: passwordTooShort (6). If the server is 1825 able to check the password length, and the check fails, the server 1826 sends a response message to the client with the resultCode: 1827 constraintViolation (19), and includes the passwordPolicyResponse 1828 in the controls field of the response message with the error: 1829 passwordTooShort (6). 1830 18318.2.6. Invalid Reuse 1832 1833 If pwdInHistory is present and its value is non-zero, the server 1834 checks whether this password exists in the entry's pwdHistory 1835 attribute or in the current password attribute. If the password does 1836 exist in the pwdHistory attribute or in the current password 1837 attribute, the server sends a response message to the client with the 1838 resultCode: constraintViolation (19), and includes the 1839 passwordPolicyResponse in the controls field of the response message 1840 with the error: passwordInHistory (8). 1841 1842 1843 1844 1845 1846 1847Sermersheim, et al. Expires February 10, 2010 [Page 33] 1848 1849Internet-Draft Password Policy for LDAP Directories August 2009 1850 1851 18528.2.7. Policy State Updates 1853 1854 If the steps have completed without causing an error condition, the 1855 server performs the following steps in order to update the necessary 1856 password policy state attributes: 1857 1858 If the value of either pwdMaxAge or pwdMinAge is non-zero, the server 1859 updates the pwdChangedTime attribute on the entry to the current 1860 time. 1861 1862 If the value of pwdInHistory is non-zero, the server adds the 1863 previous password (if one existed) to the pwdHistory attribute. If 1864 the number of attributes held in the pwdHistory attribute exceeds the 1865 value of pwdInHistory, the server removes the oldest excess 1866 passwords. 1867 1868 If the value the pwdMustChange is TRUE and the modification is 1869 performed by a password administrator, then the pwdReset attribute is 1870 set to TRUE. Otherwise, the pwdReset is removed from the user's 1871 entry if it exists. 1872 1873 The pwdFailureTime and pwdGraceUseTime attributes is removed from the 1874 user's entry if they exist. 1875 18768.3. Other Operations 1877 1878 For operations other than bind, password update, unbind, abandon or 1879 StartTLS, if the decision in Section 7.2 returns true, the server 1880 sends a response message to the client with the resultCode: 1881 insufficientAccessRights (50), and includes the 1882 passwordPolicyResponse in the controls field of the response message 1883 with the error: changeAfterReset (2). 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903Sermersheim, et al. Expires February 10, 2010 [Page 34] 1904 1905Internet-Draft Password Policy for LDAP Directories August 2009 1906 1907 19089. Client Policy Enforcement Points 1909 1910 These sections illustrate possible scenarios for each LDAP operation 1911 and define the types of responses that identify those scenarios. 1912 1913 The scenarios in the following operations assume that the client 1914 attached a passwordPolicyRequest control to the request message of 1915 the operation, and thus may receive a passwordPolicyResponse control 1916 in the response message. In the event that the passwordPolicyRequest 1917 control was not sent, no passwordPolicyResponse control is returned. 1918 All other instructions remain the same. 1919 19209.1. Bind Operation 1921 1922 For every bind response received, the client checks the resultCode of 1923 the bindResponse and checks for a passwordPolicyResponse control to 1924 determine if any of the following conditions are true and MAY prompt 1925 the user accordingly. 1926 1927 o bindResponse.resultCode = insufficientAccessRights (50), 1928 passwordPolicyResponse.error = accountLocked (1): The password 1929 failure limit has been reached and the account is locked. The 1930 user needs to retry later or contact the password administrator to 1931 reset the password. 1932 1933 o bindResponse.resultCode = success (0), 1934 passwordPolicyResponse.error = changeAfterReset (2): The user is 1935 binding for the first time after the password administrator set 1936 the password. In this scenario, the client SHOULD prompt the user 1937 to change his password immediately. 1938 1939 o bindResponse.resultCode = success (0), 1940 passwordPolicyResponse.warning = graceAuthNsRemaining: The 1941 password has expired but there are remaining grace 1942 authentications. The user needs to change it. 1943 1944 o bindResponse.resultCode = invalidCredentials (49), 1945 passwordPolicyResponse.error = passwordExpired (0): The password 1946 has expired and there are no more grace authentications. The user 1947 contacts the password administrator in order to have its password 1948 reset. 1949 1950 o bindResponse.resultCode = success (0), 1951 passwordPolicyResponse.warning = timeBeforeExpiration: The user's 1952 password will expire in n number of seconds. 1953 1954 1955 1956 1957 1958 1959Sermersheim, et al. Expires February 10, 2010 [Page 35] 1960 1961Internet-Draft Password Policy for LDAP Directories August 2009 1962 1963 19649.2. Modify Operations 1965 19669.2.1. Modify Request 1967 1968 If the application or client encrypts the password prior to sending 1969 it in a password modification operation (whether done through 1970 modifyRequest or another password modification mechanism), it SHOULD 1971 check the values of the pwdMinLength, and pwdCheckQuality attributes 1972 and SHOULD enforce these policies. 1973 19749.2.2. Modify Response 1975 1976 If the modifyRequest operation was used to change the password, or if 1977 another mechanism is used --such as an extendedRequest-- the 1978 modifyResponse or other appropriate response MAY contain information 1979 pertinent to password policy. The client checks the resultCode of 1980 the response and checks for a passwordPolicyResponse control to 1981 determine if any of the following conditions are true and optionally 1982 notify the user of the condition. 1983 1984 o pwdModResponse.resultCode = insufficientAccessRights (50), 1985 passwordPolicyResponse.error = mustSupplyOldPassword (4): The user 1986 attempted to change her password without specifying the old 1987 password but the password policy requires this. 1988 1989 o pwdModResponse.resultCode = insufficientAccessRights (50), 1990 passwordPolicyResponse.error = changeAfterReset (2): The user must 1991 change her password before submitting any other LDAP requests. 1992 1993 o pwdModResponse.resultCode = insufficientAccessRights (50), 1994 passwordPolicyResponse.error = passwordModNotAllowed (3): The user 1995 doesn't have sufficient rights to change his password. 1996 1997 o pwdModResponse.resultCode = constraintViolation (19), 1998 passwordPolicyResponse.error = passwordTooYoung (7): It is too 1999 soon after the last password modification to change the password. 2000 2001 o pwdModResponse.resultCode = constraintViolation (19), 2002 passwordPolicyResponse.error = insufficientPasswordQuality (5): 2003 The password failed quality checking. 2004 2005 o pwdModResponse.resultCode = constraintViolation (19), 2006 passwordPolicyResponse.error = passwordTooShort (6): The length of 2007 the password is too short. 2008 2009 o pwdModResponse.resultCode = constraintViolation (19), 2010 passwordPolicyResponse.error = passwordInHistory (8): The password 2011 has already been used; the user must choose a different one. 2012 2013 2014 2015Sermersheim, et al. Expires February 10, 2010 [Page 36] 2016 2017Internet-Draft Password Policy for LDAP Directories August 2009 2018 2019 20209.3. Add Operation 2021 2022 If a password is specified in an addRequest, the client checks the 2023 resultCode of the addResponse and checks for a passwordPolicyResponse 2024 control to determine if any of the following conditions are true and 2025 may prompt the user accordingly. 2026 2027 o addResponse.resultCode = insufficientAccessRights (50), 2028 passwordPolicyResponse.error = passwordModNotAllowed (3): The user 2029 doesn't have sufficient rights to add this password. 2030 2031 o addResponse.resultCode = constraintViolation (19), 2032 passwordPolicyResponse.error = insufficientPasswordQuality (5): 2033 The password failed quality checking. 2034 2035 o addResponse.resultCode = constraintViolation (19), 2036 passwordPolicyResponse.error = passwordTooShort (6): The length of 2037 the password is too short. 2038 20399.4. Compare Operation 2040 2041 When a compare operation is used to compare a password, the client 2042 checks the resultCode of the compareResponse and checks for a 2043 passwordPolicyResponse to determine if any of the following 2044 conditions are true and MAY prompt the user accordingly. These 2045 conditions assume that the result of the comparison was true. 2046 2047 o compareResponse.resultCode = compareFalse (5), 2048 passwordPolicyResponse.error = accountLocked (1): The password 2049 failure limit has been reached and the account is locked. The 2050 user needs to retry later or contact the password administrator to 2051 reset the password. 2052 2053 o compareResponse.resultCode = compareTrue (6), 2054 passwordPolicyResponse.warning = graceAuthNsRemaining: The 2055 password has expired but there are remaining grace 2056 authentications. The user needs to change it. 2057 2058 o compareResponse.resultCode = compareFalse (5), 2059 passwordPolicyResponse.error = passwordExpired (0): The password 2060 has expired and there are no more grace authentications. The user 2061 must contact the password administrator to reset the password. 2062 2063 o compareResponse.resultCode = compareTrue (6), 2064 passwordPolicyResponse.warning = timeBeforeExpiration: The user's 2065 password will expire in n number of seconds. 2066 2067 2068 2069 2070 2071Sermersheim, et al. Expires February 10, 2010 [Page 37] 2072 2073Internet-Draft Password Policy for LDAP Directories August 2009 2074 2075 20769.5. Other Operations 2077 2078 For operations other than bind, unbind, abandon or StartTLS, the 2079 client checks the result code and control to determine if any other 2080 actions are needed. 2081 2082 o <Response>.resultCode = insufficientAccessRights (50), 2083 passwordPolicyResponse.error = accountLocked (1) : The password 2084 failure limit has been reached and the account is locked. The 2085 user needs to retry later or contact the password administrator to 2086 reset the password. 2087 2088 o <Response>.resultCode = insufficientAccessRights (50), 2089 passwordPolicyResponse.error = changeAfterReset (2) : The user 2090 needs to change the password immediately. 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127Sermersheim, et al. Expires February 10, 2010 [Page 38] 2128 2129Internet-Draft Password Policy for LDAP Directories August 2009 2130 2131 213210. Administration of the Password Policy 2133 2134 {TODO: Need to define an administrativeRole (need OID). Need to 2135 describe whether pwdPolicy admin areas can overlap} 2136 2137 A password policy is defined for a particular subtree of the DIT by 2138 adding to an LDAP subentry whose immediate superior is the root of 2139 the subtree, the pwdPolicy auxiliary object class. The scope of the 2140 password policy is defined by the SubtreeSpecification attribute of 2141 the LDAP subentry as specified in [RFC3672]. 2142 2143 It is possible to define password policies for different password 2144 attributes within the same pwdPolicy entry, by specifying multiple 2145 values of the pwdAttribute. But password policies could also be in 2146 separate sub entries as long as they are contained under the same 2147 LDAP subentry. 2148 2149 Only one policy may be in effect for a given password attribute in 2150 any entry. If multiple policies exist which overlap in the range of 2151 entries affected, the resulting behavior is undefined. 2152 2153 Modifying the password policy MUST NOT result in any change in users' 2154 entries to which the policy applies. 2155 2156 It SHOULD be possible to overwrite the password policy for one user 2157 by defining a new policy in a subentry of the user entry. 2158 2159 Each object that is controlled by password policy advertises the 2160 subentry that is being used to control its policy in its 2161 pwdPolicySubentry attribute. Clients wishing to examine or manage 2162 password policy for an object may interrogate the pwdPolicySubentry 2163 for that object in order to arrive at the proper pwdPolicy subentry. 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183Sermersheim, et al. Expires February 10, 2010 [Page 39] 2184 2185Internet-Draft Password Policy for LDAP Directories August 2009 2186 2187 218811. Password Policy and Replication 2189 2190 {TODO: This section needs to be changed to highlight the pitfalls of 2191 replication, suggest some implementation choices to overcome those 2192 pitfalls, but remove prescriptive language relating to the update of 2193 state information} 2194 2195 The pwdPolicy object defines the password policy for a portion of the 2196 DIT and MUST be replicated on all the replicas of this subtree, as 2197 any subentry would be, in order to have a consistent policy among all 2198 replicated servers. 2199 2200 The elements of the password policy that are related to the users are 2201 stored in the entry themselves as operational attributes. As these 2202 attributes are subject to modifications even on a read-only replica, 2203 replicating them must be carefully considered. 2204 2205 The pwdChangedTime attribute MUST be replicated on all replicas, to 2206 allow expiration of the password. 2207 2208 The pwdReset attribute MUST be replicated on all replicas, to deny 2209 access to operations other than bind and modify password. 2210 2211 The pwdHistory attribute MUST be replicated to writable replicas. It 2212 doesn't have to be replicated to a read-only replica, since the 2213 password will never be directly modified on this server. 2214 2215 The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime 2216 attributes SHOULD be replicated to writable replicas, making the 2217 password policy global for all servers. When the user entry is 2218 replicated to a read-only replica, these attributes SHOULD NOT be 2219 replicated. This means that the number of failures, of grace 2220 authentications and the locking will take place on each replicated 2221 server. For example, the effective number of failed attempts on a 2222 user password will be N x M (where N is the number of servers and M 2223 the value of pwdMaxFailure attribute). Replicating these attributes 2224 to a read-only replica MAY reduce the number of tries globally but 2225 MAY also introduce some inconstancies in the way the password policy 2226 is applied. 2227 2228 Note: there are some situations where global replication of these 2229 state attributes may not be desired. For example, if two clusters of 2230 replicas are geographically remote and joined by a slow network link, 2231 and their users only login from one of the two locations, it may be 2232 unnecessary to propagate all of the state changes from one cluster to 2233 the other. Servers SHOULD allow administrators to control which 2234 attributes are replicated on a case-by-case basis. 2235 2236 2237 2238 2239Sermersheim, et al. Expires February 10, 2010 [Page 40] 2240 2241Internet-Draft Password Policy for LDAP Directories August 2009 2242 2243 2244 Servers participating in a loosely consistent multi-master 2245 replication agreement SHOULD employ a mechanism which ensures 2246 uniqueness of values when populating the attributes pwdFailureTime 2247 and pwdGraceUseTime. The method of achieving this is a local matter 2248 and may consist of using a single authoritative source for the 2249 generation of unique time values, or may consist of the use of the 2250 fractional seconds part to hold a replica identifier. 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295Sermersheim, et al. Expires February 10, 2010 [Page 41] 2296 2297Internet-Draft Password Policy for LDAP Directories August 2009 2298 2299 230012. Security Considerations 2301 2302 This document defines a set of rules to implement in an LDAP server, 2303 in order to mitigate some of the security risks associated with the 2304 use of passwords and to make it difficult for password cracking 2305 programs to break into directories. 2306 2307 Authentication with a password MUST follow the recommendations made 2308 in [RFC4513]. 2309 2310 Modifications of passwords SHOULD only occur when the connection is 2311 protected with confidentiality and secure authentication. 2312 2313 Access controls SHOULD be used to restrict access to the password 2314 policy attributes. The attributes defined to maintain the password 2315 policy state information SHOULD only be modifiable by the password 2316 administrator or higher authority. The pwdHistory attribute MUST be 2317 subject to the same level of access control as the attrbute holding 2318 the password. 2319 2320 As it is possible to define a password policy for one specific user 2321 by adding a subentry immediately under the user's entry, Access 2322 Controls SHOULD be used to restrict the use of the pwdPolicy object 2323 class or the LDAP subentry object class. 2324 2325 When the intruder detection password policy is enforced, the LDAP 2326 directory is subject to a denial of service attack. A malicious user 2327 could deliberately lock out one specific user's account (or all of 2328 them) by sending bind requests with wrong passwords. There is no way 2329 to protect against this kind of attack. The LDAP directory server 2330 SHOULD log as much information as it can (such as client IP address) 2331 whenever an account is locked, in order to be able to identify the 2332 origin of the attack. Denying anonymous access to the LDAP directory 2333 is also a way to restrict this kind of attack. Using the login delay 2334 instead of the lockout mechanism will also help avoid this denial of 2335 service. 2336 2337 Returning certain status codes (such as passwordPolicyResponse.error 2338 = accountLocked) allows a denial of service attacker to know that it 2339 has successfully denied service to an account. Servers SHOULD 2340 implement additional checks which return the same status when it is 2341 sensed that some number of failed authentication requests has occured 2342 on a single connection, or from a client address. Server 2343 implementors are encouraged to invent other checks similar to this in 2344 order to thwart this type of DoS attack. 2345 2346 2347 2348 2349 2350 2351Sermersheim, et al. Expires February 10, 2010 [Page 42] 2352 2353Internet-Draft Password Policy for LDAP Directories August 2009 2354 2355 235613. IANA Considerations 2357 2358 <<<TBD>>> 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407Sermersheim, et al. Expires February 10, 2010 [Page 43] 2408 2409Internet-Draft Password Policy for LDAP Directories August 2009 2410 2411 241214. Acknowledgement 2413 2414 This document is based in part on prior work done by Valerie Chu from 2415 Netscape Communications Corp, published as 2416 draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera 2417 participated in early revisions of this document. 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463Sermersheim, et al. Expires February 10, 2010 [Page 44] 2464 2465Internet-Draft Password Policy for LDAP Directories August 2009 2466 2467 246815. Normative References 2469 2470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2471 Requirement Levels", BCP 14, RFC 2119, March 1997. 2472 2473 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 2474 AUTHorize Extension for Simple Challenge/Response", 2475 RFC 2195, September 1997. 2476 2477 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 2478 SASL Mechanism", RFC 2831, May 2000. 2479 2480 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 2481 RFC 3062, February 2001. 2482 2483 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2484 Considerations for the Lightweight Directory Access 2485 Protocol (LDAP)", RFC 3383, September 2002. 2486 2487 [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory 2488 Access Protocol (LDAP)", RFC 3672, December 2003. 2489 2490 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2491 Security Layer (SASL)", RFC 4422, June 2006. 2492 2493 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 2494 (LDAP): The Protocol", RFC 4511, June 2006. 2495 2496 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 2497 (LDAP): Directory Information Models", RFC 4512, 2498 June 2006. 2499 2500 [RFC4513] Harrison, R., "Lightweight Directory Access Protocol 2501 (LDAP): Authentication Methods and Security Mechanisms", 2502 RFC 4513, June 2006. 2503 2504 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 2505 Syntaxes and Matching Rules", RFC 4517, June 2006. 2506 2507 [X.680] International Telecommunications Union, "Abstract Syntax 2508 Notation One (ASN.1): Specification of basic notation", 2509 ITU-T Recommendation X.680, July 2002. 2510 2511 [X.690] International Telecommunications Union, "Information 2512 Technology - ASN.1 encoding rules: Specification of Basic 2513 Encoding Rules (BER), Canonical Encoding Rules (CER) and 2514 Distinguished Encoding Rules (DER)", ITU-T 2515 Recommendation X.690, July 2002. 2516 2517 2518 2519Sermersheim, et al. Expires February 10, 2010 [Page 45] 2520 2521Internet-Draft Password Policy for LDAP Directories August 2009 2522 2523 2524Authors' Addresses 2525 2526 Jim Sermersheim 2527 Novell, Inc 2528 1800 South Novell Place 2529 Provo, Utah 84606 2530 US 2531 2532 Phone: +1 801 861-3088 2533 Email: jimse@novell.com 2534 2535 2536 Ludovic Poitou 2537 Sun Microsystems 2538 180, Avenue de l'Europe 2539 Zirst de Montbonnot, Saint Ismier cedex 38334 2540 FR 2541 2542 Phone: +33 476 188 212 2543 Email: ludovic.poitou@sun.com 2544 2545 2546 Howard Chu (editor) 2547 Symas Corp. 2548 18740 Oxnard Street, Suite 313A 2549 Tarzana, California 91356 2550 US 2551 2552 Phone: +1 818 757-7087 2553 Email: hyc@symas.com 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575Sermersheim, et al. Expires February 10, 2010 [Page 46] 2576 2577