idnits 2.17.1 draft-zeilenga-ldap-passwords-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 717. 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 Copyright Line does not match the current year -- 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 (31 March 2008) is 5868 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) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- No information found for draft-behera-ldap-password-policy-xx - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standards Track Isode Limited 4 Expires in six months 31 March 2008 6 Passwords in LDAP 7 9 Status of this Memo 11 Distribution of this memo is unlimited. Technical discussion of this 12 document will take place on the IETF LDAP Extensions mailing list 13 . Please send editorial comments directly to the 14 author . 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware have 18 been or will be disclosed, and any of which he or she becomes aware 19 will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright (C) The IETF Trust (2008). 38 Please see the Full Copyright section near the end of this document 39 for more information. 41 Abstract 43 The Lightweight Directory Access Protocol (LDAP) provides a number of 44 password-based mechanisms for authenticating directory users to the 45 directory service. This document discusses the use of passwords in 46 directory user authentication. The document specifies schema for 47 representing a basic password policy and directory service enforcement 48 of password policy. 50 Table of Contents 52 TBD 54 1. Introduction 56 The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a 57 number of password-based mechanisms for authenticating directory users 58 to the directory service. Supported password-based mechanisms include 59 the Simple DN/password mechanism [RFC4511] and the Simple 60 Authentication and Security Layer (SASL) [RFC4422] PLAIN [RFC4616] 61 mechanism. Likewise, the Directory Access Protocol (DAP) [X.511] 62 provides a password-based authentication mechanism. 64 This document discusses the use of passwords in directory 65 authentication, management of passwords held in the directory, and 66 application of password policy. 68 To improve directory security and interoperability, the document 69 specifies an an administrative model for password policy in LDAP and 70 X.500 [X.500] directory systems, defines schema elements for 71 representing a basic password policy, and details directory service 72 enforcement of password policy. 74 Among other things, this policy statement includes: 76 - whether passwords must adhere to various constraints; 77 - whether passwords expire and, if so, when; and 78 - whether human-generated or machine-generated passwords 79 are to be used. 81 This policy, which is intended to be enforced by Directory System 82 Agents (or servers), applies to authentication and authorization of 83 Directory User Agents (or clients) to the directory service, as well 84 as directory user password administration. 86 Applicability of this policy to other uses, such as authentication of 87 users to a directory user agent, may be limited. Such uses are not 88 further discussed in this document. 90 Directory System Agents (DSAs) implementing this specification SHOULD 91 support the LDAP Password Modify Extended Operation [RFC3062]. 93 2. Terminology 95 DIT stands for Directory Information Tree. 96 DSA stands for Directory System Agent (or server). 97 DSE stands for DSA-specific Entry. 98 DUA stands for Directory User Agent (or client). 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 Schema definitions are provided using LDAP description formats 105 [RFC4512]. Definitions provided here are formatted (line wrapped) for 106 readability. 108 3. Password Policy Administrative Model 110 This document extends the X.500 administrative model to support 111 password policy. 113 The administration of a DIT Domain is extended to involve execution of 114 an additional function, password administration. 116 The term Password Authority identifies the role of the Administrative 117 Authority as it pertains to the establishment, administration and 118 execution of password policy governing use of passwords in a DIT 119 Domain. The Password Authority is a specific Administrative 120 Authority. 122 [...] 124 Any user governed by a password policy is restricted to a single 125 password. This restriction is enforced upon password update. 127 3.1. Schema for Password Policy 129 The following schema is used to specify a password policy for a 130 subtree of the DIT. 132 3.1.1. 'passwdPolicy' 134 A subentry object belonging to the 'passwdPolicy' auxiliary class is 135 used to state the password policy for a subtree of the DIT. 137 ( IANA-ASSIGNED-OID.1.1 138 NAME 'passwdPolicy' AUXILIARY 139 MAY ( passwdAttribute $ 140 passwdExpiry $ passwdExpiryWarning $ 141 passwdGraces $ passwdGracesExpiry $ 142 passwdContraints $ passwdHistoryDuration $ 143 passwdRequireChange $ passwdRequireOld $ 144 passwdRequireGenerated $ passwdOnBindConstraints ) ) 146 3.1.2. 'passwdAttribute' 148 The 'passwdAttribute' attribute specifies the attribute to which the 149 password policy applies. 151 ( IANA-ASSIGNED-OID.1.2 152 NAME 'passwdAttribute' 153 EQUALITY objectIdentifierMatch 154 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 155 SINGLE-VALUE 156 USAGE directoryOperation ) 158 If absent, the policy applies to passwords held in any external 159 password store. 161 Note: replaces 'pwdAttribute' [BEHERA] 163 3.1.3. 'passwdExpiry' 165 The 'passwdExpiry' attribute specifies the age, in seconds, in which a 166 password expires. 168 ( IANA-ASSIGNED-OID.1.3 169 NAME 'passwdExpiry' 170 EQUALITY integerMatch 171 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 172 SINGLE-VALUE 173 USAGE directoryOperation ) 175 If the attribute is absent, is zero (0) or negative, passwords do not 176 expire. 178 Note: replaces 'pwdMaxAge' [BEHERA] 180 3.1.4. 'passwdExpiryWarning' 182 The 'passwdExpiryWarning' attribute specifies the time, in seconds, 183 before password expiry that warning of the expiry should be provided. 185 ( IANA-ASSIGNED-OID.1.4 186 NAME 'passwdExpiryWarning' 187 EQUALITY integerMatch 188 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 189 SINGLE-VALUE 190 USAGE directoryOperation ) 192 If the attribute is absent, is zero (0) or negative, no warnings are 193 to be provided. 195 Note: replaces 'pwdExpireWarning' [BEHERA] 197 3.1.5. 'passwdGraces' 199 The 'passwdGraces' attribute specifies the number of times the user 200 may authenticate using an expired password for the purpose of setting 201 a new password. 203 ( IANA-ASSIGNED-OID.1.5 204 NAME 'passwdGraces' 205 EQUALITY integerMatch 206 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 207 SINGLE-VALUE 208 USAGE directoryOperation ) 210 If the attribute is absent, is zero (0) or negative, no grace is 211 given. 213 Note: replaces 'pwdGraceAuthNLimit' [BEHERA] 215 3.1.6. 'passwdGracesExpiry' 217 The 'passwdGracesExiry' attribute specifies the number of seconds 218 allowed graces (passwdGraces) are valid. 220 ( IANA-ASSIGNED-OID.1.5 221 NAME 'passwdGracesExpiry' 222 EQUALITY integerMatch 223 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 224 SINGLE-VALUE 225 USAGE directoryOperation ) 227 If the attribute is absent, is zero (0) or negative, allowed graces do 228 not expire. 230 3.1.7. 'passwdHistoryDuration' 232 The 'passwdHistoryDuration' attribute specifies the length of time, in 233 seconds, that passwords are to remembered. 235 ( IANA-ASSIGNED-OID.1.7 236 NAME 'passwdHistoryDuration' 237 EQUALITY integerMatch 238 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 239 SINGLE-VALUE 240 USAGE directoryOperation ) 242 If the attribute is absent or is zero (0) or negative, no history is 243 maintained. 245 Note: replaces 'pwdInHistory' [BEHERA] 247 3.1.8 'passwdRequireChange' 249 The 'passwdRequireChange' attribute specifies whether user is required 250 to change their password after it has been set by a password 251 administrator. When TRUE, the server is expected to require the user 252 to change their password after it has been set by an administrator. 253 Otherwise, the user is not required to change their password after it 254 has been set by an administrator. 256 ( IANA-ASSIGNED-OID.1.8 257 NAME 'passwdRequireChange' 258 EQUALITY booleanMatch 259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 260 SINGLE-VALUE 261 USAGE directoryOperation ) 263 Note: replaces 'pwdMustChange' [BEHERA] 265 3.1.9 'passwdRequireOld' 267 The 'passwdRequireOld' attribute specifies whether user is required to 268 prove they know the current password before setting the password. 269 When TRUE, the server is expected to reject a user's request to change 270 their password when the user has not proven they know the current 271 password. Such proof generally should be provided in the same 272 directory operation sets a new password. When FALSE or absent, the 273 server is not expected to require proof the user knows the current 274 password before setting a new password. 276 ( IANA-ASSIGNED-OID.1.9 277 NAME 'passwdRequireChange' 278 EQUALITY booleanMatch 279 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 280 SINGLE-VALUE 281 USAGE directoryOperation ) 283 Note: replaces 'pwdSafeModify' [BEHERA] 285 3.1.10 'passwdRequireGenerated' 287 The 'passwdRequireGenerated' attribute specifies whether passwords are 288 to be DSA-generated. If the value of this attribute is TRUE, DSA- 289 generation of passwords is required. Otherwise, not. 291 ( IANA-ASSIGNED-OID.1.10 292 NAME 'passwdRequireGenerated' 293 EQUALITY booleanMatch 294 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 295 SINGLE-VALUE 296 USAGE directoryOperation ) 298 3.1.11 'passwdOnBindContraints' 300 This attribute specifies whether constraints upon apply to current 301 passwords as well as new passwords. 303 When this attribute is TRUE, the DSA is expected to verify that a 304 user's password used in authentication meets constraints placed upon 305 passwords and, where the password fails to met the constraints, a 306 password change is required. 308 When this attribute is FALSE or absent, 310 ( IANA-ASSIGNED-OID.1.11 311 NAME 'passwdOnBindConstraints' 312 EQUALITY booleanMatch 313 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 314 SINGLE-VALUE 315 USAGE directoryOperation ) 317 3.1.12. 'passwdConstraints' 319 Values of 'passwdContraints' attribute represent constraints upon 320 passwords, for instance a minimum size constraint. Each value 321 consists of a OID identifying the constraint type and a type-specific 322 parameter. A number of constraints are defined in this document (see 323 Section 4), others may be defined in other documents. 325 ( IANA-ASSIGNED-OID.1.12 326 NAME 'passwdConstraints' 327 EQUALITY TBD 328 SYNTAX TBD 329 USAGE directoryOperation ) 331 Values of this attribute are of the following ASN.1 type: 333 PasswordConstraintAssertion ::= SEQUENCE { 334 type PASSWORD-CONSTRAINT.&id, 335 parameter PASSWORD-CONSTRAINT.&type 336 } 338 where LDAPOID and AssertionValue as a defined in the Lightweight- 339 Directory-Access-Protocol-V3 [RFC4511] module. Values of this syntax 340 are encoded using the Generic String Encoding Rules (GSER) [RFC3641]. 342 Note: replaces 'pwdCheckQuality' [BEHERA] 344 3.2. Schema for Password Policy State 346 The following schema is used to hold password policy state for a user. 347 Each state attribute is held in the user's entry. 349 3.2.1. 'passwdChangeTime' 351 This attribute specifies the time the user's password was last 352 changed. 354 ( IANA-ASSIGNED-OID.2.1 355 NAME 'passwdChangeTime' 356 EQUALITY generalizedTimeMatch 357 ORDERING generalizedTimeOrderingMatch 358 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 359 SINGLE-VALUE NO-USER-MODIFICATION 360 USAGE directoryOperation ) 362 This attribute should be maintained regardless of what, if any, 363 password policy is enforce. Zulu time should be used. 365 Note: replaces 'pwdChangeTime' [BEHERA] 367 3.2.2. 'passwdGracesUsed' 369 This attribute holds times of graces used after a password has 370 expired. 372 ( IANA-ASSIGNED-OID.2.2 373 NAME 'passwdGracesUsed' 374 EQUALITY generalizedTimeMatch 375 ORDERING generalizedTimeOrderingMatch 376 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 377 SINGLE-VALUE NO-USER-MODIFICATION 378 USAGE directoryOperation ) 380 Note: replaces 'pwdGraceUseTime' [BEHERA] 382 3.2.3. 'passwdChangeRequired' 384 This attribute indicates when TRUE that the user's password is 385 required to be changed. 387 ( IANA-ASSIGNED-OID.2.3 388 NAME 'passwdChangeRequired' 389 EQUALITY booleanMatch 390 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 391 NO-USER-MODIFICATION 392 USAGE directoryOperation ) 394 Note: replaces 'pwdReset' [BEHERA] 396 3.3. Additional schema elements 398 3.3.1. 'passwdPolicySubentry' 400 The 'passwdPolicySubentry' holds the name of the governing password 401 policy subentry for this entry. 403 DSAs SHOULD provide, subject to access controls, this attribute in all 404 entries governed by a password policy subentry. 406 ( IANA-ASSIGNED-OID.3.1 407 NAME 'passwdPolicySubentry' 408 EQUALITY distinguishedNameMatch 409 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 410 SINGLE-VALUE NO-USER-MODIFICATION 411 USAGE directoryOperation ) 413 Note: replaces 'pwdPolicySubentry' [BEHERA] 415 3.3.2. 'passwdPolicyExclude' 417 The 'passwdPolicyExclude' indicates whether the user is subject to 418 password policy. If 'FALSE' or absent, the user is subject to 419 password policy. If 'TRUE', the user is not subject to password 420 policy. 422 ( IANA-ASSIGNED-OID.3.2 NAME 'passwdRequireChange' 423 EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 424 SINGLE-VALUE USAGE directoryOperation ) 426 4. Password Constraints 428 Password Constraints restrict allowed passwords. A number of 429 constraints are specified in this section, others may be specified in 430 other documents. 432 4.1. UTF-8 434 The UTF-8 constraint restricts password values to octet strings which 435 form valid UTF-8 [RFC3629] encodings of Unicode [Unicode] code points. 436 The syntax of the parameter is NULL. 438 This constraint is identified by the OID IANA-ASSIGNED.4.1. 440 4.1. SASLprep 442 The SASLprep constraint restricts password values to UTF-8 [RFC3629] 443 encoded Unicode [Unicode] character strings prepared by the SASLprep 444 [RFC4013] algorithm, treating the value as a "stored" string 445 ([RFC3454], Section 7). 447 This constraint is identified by the OID IANA-ASSIGNED.4.2. 449 4.2. Minimum Length 451 The Minimum Length constraint restricts the length of allowed 452 passwords, requiring all passwords to have at least the number of 453 octets specified in the parameter. The syntax of the parameter is: 455 MinLenValue ::= INTEGER (SIZE(1..MAX)) 457 This constraint is identified by the OID IANA-ASSIGNED.4.2. 459 4.X Additional Constraints 461 TBD 463 5. Application of Password Policy 465 Password policy applies in a number of different circumstances: 466 1) Bind operations utilizing password-based authentication 467 mechanisms, 469 2) Password update operations, and 471 3) Other operations. 473 5.1. Password-based Bind Operations 475 5.2. Password update operations 477 5.3. Other operations 479 6. Security Considerations 481 Security issues are discussed throughout this document. 483 This document expand upon many of the password-related security 484 considerations discussed in documents comprising the LDAP Technical 485 Specification [RFC4510], in particular [RFC4511], [RFC4512], 486 [RFC4513], and [RFC4519]. Readers are encouraged to familiarize 487 themselves with the security considerations detailed these documents, 488 as well as all documents referenced by this specification. 490 7. IANA Considerations 492 TBD 494 8. Acknowledgments 496 This document is based in part upon prior work in the area done by Jim 497 Sermersheim, Ludovic Poitou, Prasanta Behera, and Valerie Chu. 499 9. Author's Address 501 Kurt D. Zeilenga 502 Isode Limited 504 Email: Kurt.Zeilenga@Isode.COM 506 10. References 508 [[Note to the RFC Editor: please replace the citation tags used in 509 referencing Internet-Drafts with tags of the form RFCnnnn where 510 possible.]] 512 10.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 517 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 518 10646", RFC 3629 (also STD 63), November 2003. 520 [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1 521 Types", RFC 3641, October 2003. 523 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 524 Names and Passwords", RFC 4013, February 2005. 526 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification 527 Road Map", RFC 4510, June 2006. 529 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 530 4511, June 2006. 532 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information 533 Models", RFC 4512, June 2006. 535 [RFC4513] Harrison, R. (editor), "LDAP: Authentication Methods and 536 Security Mechanisms", RFC 4513, June 2006. 538 [RFC4519] Sciberras, A. (editor), "LDAP: Schema for User 539 Applications", RFC 4519, June 2006. 541 [X.500] International Telecommunication Union - 542 Telecommunication Standardization Sector, "The Directory 543 -- Overview of concepts, models and services," 544 X.500(1993) (also ISO/IEC 9594-1:1994). 546 [X.511] International Telecommunication Union - 547 Telecommunication Standardization Sector, "The 548 Directory: Abstract Service Definition", X.511(1993) 549 (also ISO/IEC 9594-3:1993). 551 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 552 3.2.0" is defined by "The Unicode Standard, Version 3.0" 553 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 554 as amended by the "Unicode Standard Annex #27: Unicode 555 3.1" (http://www.unicode.org/reports/tr27/) and by the 556 "Unicode Standard Annex #28: Unicode 3.2" 557 (http://www.unicode.org/reports/tr28/). 559 10.2. Informative References 561 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 562 RFC 3062, February 2001. 564 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 565 Internationalized Strings ('stringprep')", RFC 3454, 566 December 2002. 568 [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple 569 Authentication and Security Layer (SASL)", RFC 4422, 570 June 2006. 572 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 573 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 575 [BEHERA] Sermersheim, J., and L. Poitou, "Password 576 Policy for LDAP Directories", draft-behera-ldap- 577 password-policy-xx.txt (expired "work in progress"). 579 Appendix A. 581 This appendix is non-normative. 583 This document offers an alternative to the Password Policy proposal 584 detailed in [BEHERA]. This appendix discusses how the approaches 585 differ. 587 [BEHERA] included an "intruder detection check" (also referred to as a 588 "guessing limit"). This feature intended to deter or slow online 589 dictionary attacks. The feature caused authentication against the 590 user's password to be blocked after too many failed after too many 591 failed password authentication attempts. However, the feature doesn't 592 necessarily hinder online dictionary attacks, especially those 593 attacking passwords of multiple users simultaneously, and can easily 594 be used to mount denial of service attacks. This document does not 595 offer any specific facility intended to hinder online dictionary 596 attacks, or to detect intruders. While implementations can employs 597 facilities of their own making, caution should be taken to prevent 598 these facilities from being used to mount denial of service attacks. 600 [BEHERA] also included a feature that allowed administrators to lock a 601 user's password and thereby preventing the user from authenticating to 602 the directory with that password. Due possibly to how [BEHERA] 603 describes the feature, the feature has been perceived as a general 604 account lock mechanism. The design of this feature in [BEHERA] is 605 flawed in that overloads the attribute used for indicate intruder 606 lockout with an incompatible usage (directoryOperation versus 607 dsaOperation). This document does not provide a mechanism for the 608 administrator to lock a password, or to lock an account. The latter 609 is more appropriately standardized in a manner not tied to the 610 particular form of credentials. 612 [BEHERA] provided a feature allowing users to authenticate an limited 613 number of times with an expired password in order to set a new 614 password known. While these grace authentications were intended to be 615 used soon after the expiration of the password, [BEHERA] provided no 616 time constraint on their use. This is problematic where the user no 617 longer regularly uses password authentication as it allows access to 618 the directory via a password long after that password has expired, 619 such as in the case where the user authenticates to the directory 620 using mechanism not based upon password (e.g., Kerberos). This 621 document provides a time-constrained grace authentication mechanism. 623 [BEHERA] included a feature that allowed administrators to disallow 624 user password changes, intended to be used in absence of a suitable 625 access control mechanism. While there may be DSAs which do not 626 provide a suitable access control mechanism, this inadequacy seems 627 more appropriately addressed through access control enhancements. To 628 reduce complexity in DSAs which do provide suitable access control 629 mechanisms, this document does not include a user change control 630 feature. 632 [BEHERA] included a protocol extension to request and provide password 633 policy related information. The extension is used both for providing 634 information about the password acted upon by an operation, and 635 information about password policy impacting an operation. The 636 extension has significant limited on when information can be provided. 637 For instance, a time before expiration warning can only be provided in 638 an authentication response. However, it would be useful to provide 639 the warning in password update response, as well as any other response 640 as might be useful in communicating a new warning (such as after a 641 change in the maximum password age constraint). This document 642 provides protocol extensions to request and provide password policy 643 related information designed to allow flexible return of password 644 policy information, and to be extensible. 646 [BEHERA] password policy was applied not only to authentication of 647 directory user to the directory service (e.g., Bind operation), but 648 also to application user to directory applications (e.g., Compare 649 operation). 651 [BEHERA] did not include a feature to require DSA-generated passwords. 652 As humans are generally regarded as poor password generators, this 653 document offers a feature to require DSA-generated passwords. This 654 feature is intended to be used in conjunction with LDAP Password 655 Modify [RFC3062] operations requesting DSA-generation of passwords. 657 [BEHERA] included a feature, as part of password quality check 658 feature, to enforce a minimum password length. This document offers 659 features to enforce both minimum length and maximum length. These 660 length checks are offered independently of the quality check feature 661 as the reasons for enforcing length restrictions may be independent of 662 the reasons for enforcing a quality check. For instance, the 663 directory service may have to support DUAs unable to handle password 664 greater than a particular length, necessitating the need for a maximum 665 password length. Of course, DUAs should be designed to handle long 666 passwords. 668 [BEHERA] includes a password history feature. When enabled, previously 669 used passwords are stored in an attribute. The user is prevented from 670 changing their password to any value in the history, as well as 671 reusing the current password. To ensure the attribute doesn't grown 672 to an excessive size, the administrator is required to specify the 673 maximum size for this attribute. When addition of an old password 674 would cause the maximum size to be exceeded, the oldest password in 675 the history is removed. As a user desiring to reuse a password in the 676 history might repeated change their password until the desired 677 password is removed from the history, and hence allowing its reuse, 678 [BEHERA] provides a "minimum age" constraint which prevents uses from 679 passwords which are too young. However, this constraint disallows 680 well-intended changes when the password is too young. For instance, 681 when a user believes their password has been comprised, the user could 682 be precluded from immediately changing their password due to this 683 constraint. The constraint is also problematic when the administrator 684 resets the password as it disallows a user (who may be required to 685 change the password on reset) from immediately resetting the password. 687 This document includes a password history feature designed to prevent 688 users from reusing any directory password they have used within a 689 policy-defined period. 691 Unlike [BEHERA], this document does not specify an attribute to hold 692 the password history. As with storage of the user's current password, 693 storage of password history, is a local matter. 695 Intellectual Property 697 The IETF takes no position regarding the validity or scope of any 698 Intellectual Property Rights or other rights that might be claimed to 699 pertain to the implementation or use of the technology described in 700 this document or the extent to which any license under such rights 701 might or might not be available; nor does it represent that it has 702 made any independent effort to identify any such rights. Information 703 on the procedures with respect to rights in RFC documents can be found 704 in BCP 78 and BCP 79. 706 Copies of IPR disclosures made to the IETF Secretariat and any 707 assurances of licenses to be made available, or the result of an 708 attempt made to obtain a general license or permission for the use of 709 such proprietary rights by implementers or users of this specification 710 can be obtained from the IETF on-line IPR repository at 711 http://www.ietf.org/ipr. 713 The IETF invites any interested party to bring to its attention any 714 copyrights, patents or patent applications, or other proprietary 715 rights that may cover technology that may be required to implement 716 this standard. Please address the information to the IETF at 717 ietf-ipr@ietf.org. 719 Full Copyright 721 Copyright (C) The IETF Trust (2008). 723 This document is subject to the rights, licenses and restrictions 724 contained in BCP 78, and except as set forth therein, the authors 725 retain all their rights. 727 This document and the information contained herein are provided on an 728 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 729 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 730 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 731 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 732 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 733 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.