INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Standards Track Isode Limited Expires in six months 31 March 2008 Passwords in LDAP Status of this Memo Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Extensions mailing list . Please send editorial comments directly to the author . By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The IETF Trust (2008). Please see the Full Copyright section near the end of this document for more information. Zeilenga Passwords in LDAP [Page 1] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 Abstract The Lightweight Directory Access Protocol (LDAP) provides a number of password-based mechanisms for authenticating directory users to the directory service. This document discusses the use of passwords in directory user authentication. The document specifies schema for representing a basic password policy and directory service enforcement of password policy. Table of Contents TBD 1. Introduction The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a number of password-based mechanisms for authenticating directory users to the directory service. Supported password-based mechanisms include the Simple DN/password mechanism [RFC4511] and the Simple Authentication and Security Layer (SASL) [RFC4422] PLAIN [RFC4616] mechanism. Likewise, the Directory Access Protocol (DAP) [X.511] provides a password-based authentication mechanism. This document discusses the use of passwords in directory authentication, management of passwords held in the directory, and application of password policy. To improve directory security and interoperability, the document specifies an an administrative model for password policy in LDAP and X.500 [X.500] directory systems, defines schema elements for representing a basic password policy, and details directory service enforcement of password policy. Among other things, this policy statement includes: - whether passwords must adhere to various constraints; - whether passwords expire and, if so, when; and - whether human-generated or machine-generated passwords are to be used. This policy, which is intended to be enforced by Directory System Agents (or servers), applies to authentication and authorization of Directory User Agents (or clients) to the directory service, as well as directory user password administration. Applicability of this policy to other uses, such as authentication of Zeilenga Passwords in LDAP [Page 2] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 users to a directory user agent, may be limited. Such uses are not further discussed in this document. Directory System Agents (DSAs) implementing this specification SHOULD support the LDAP Password Modify Extended Operation [RFC3062]. 2. Terminology DIT stands for Directory Information Tree. DSA stands for Directory System Agent (or server). DSE stands for DSA-specific Entry. DUA stands for Directory User Agent (or client). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Schema definitions are provided using LDAP description formats [RFC4512]. Definitions provided here are formatted (line wrapped) for readability. 3. Password Policy Administrative Model This document extends the X.500 administrative model to support password policy. The administration of a DIT Domain is extended to involve execution of an additional function, password administration. The term Password Authority identifies the role of the Administrative Authority as it pertains to the establishment, administration and execution of password policy governing use of passwords in a DIT Domain. The Password Authority is a specific Administrative Authority. [...] Any user governed by a password policy is restricted to a single password. This restriction is enforced upon password update. 3.1. Schema for Password Policy The following schema is used to specify a password policy for a subtree of the DIT. Zeilenga Passwords in LDAP [Page 3] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 3.1.1. 'passwdPolicy' A subentry object belonging to the 'passwdPolicy' auxiliary class is used to state the password policy for a subtree of the DIT. ( IANA-ASSIGNED-OID.1.1 NAME 'passwdPolicy' AUXILIARY MAY ( passwdAttribute $ passwdExpiry $ passwdExpiryWarning $ passwdGraces $ passwdGracesExpiry $ passwdContraints $ passwdHistoryDuration $ passwdRequireChange $ passwdRequireOld $ passwdRequireGenerated $ passwdOnBindConstraints ) ) 3.1.2. 'passwdAttribute' The 'passwdAttribute' attribute specifies the attribute to which the password policy applies. ( IANA-ASSIGNED-OID.1.2 NAME 'passwdAttribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE USAGE directoryOperation ) If absent, the policy applies to passwords held in any external password store. Note: replaces 'pwdAttribute' [BEHERA] 3.1.3. 'passwdExpiry' The 'passwdExpiry' attribute specifies the age, in seconds, in which a password expires. ( IANA-ASSIGNED-OID.1.3 NAME 'passwdExpiry' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) If the attribute is absent, is zero (0) or negative, passwords do not expire. Note: replaces 'pwdMaxAge' [BEHERA] Zeilenga Passwords in LDAP [Page 4] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 3.1.4. 'passwdExpiryWarning' The 'passwdExpiryWarning' attribute specifies the time, in seconds, before password expiry that warning of the expiry should be provided. ( IANA-ASSIGNED-OID.1.4 NAME 'passwdExpiryWarning' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) If the attribute is absent, is zero (0) or negative, no warnings are to be provided. Note: replaces 'pwdExpireWarning' [BEHERA] 3.1.5. 'passwdGraces' The 'passwdGraces' attribute specifies the number of times the user may authenticate using an expired password for the purpose of setting a new password. ( IANA-ASSIGNED-OID.1.5 NAME 'passwdGraces' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) If the attribute is absent, is zero (0) or negative, no grace is given. Note: replaces 'pwdGraceAuthNLimit' [BEHERA] 3.1.6. 'passwdGracesExpiry' The 'passwdGracesExiry' attribute specifies the number of seconds allowed graces (passwdGraces) are valid. ( IANA-ASSIGNED-OID.1.5 NAME 'passwdGracesExpiry' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) Zeilenga Passwords in LDAP [Page 5] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 If the attribute is absent, is zero (0) or negative, allowed graces do not expire. 3.1.7. 'passwdHistoryDuration' The 'passwdHistoryDuration' attribute specifies the length of time, in seconds, that passwords are to remembered. ( IANA-ASSIGNED-OID.1.7 NAME 'passwdHistoryDuration' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation ) If the attribute is absent or is zero (0) or negative, no history is maintained. Note: replaces 'pwdInHistory' [BEHERA] 3.1.8 'passwdRequireChange' The 'passwdRequireChange' attribute specifies whether user is required to change their password after it has been set by a password administrator. When TRUE, the server is expected to require the user to change their password after it has been set by an administrator. Otherwise, the user is not required to change their password after it has been set by an administrator. ( IANA-ASSIGNED-OID.1.8 NAME 'passwdRequireChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) Note: replaces 'pwdMustChange' [BEHERA] 3.1.9 'passwdRequireOld' The 'passwdRequireOld' attribute specifies whether user is required to prove they know the current password before setting the password. When TRUE, the server is expected to reject a user's request to change their password when the user has not proven they know the current password. Such proof generally should be provided in the same Zeilenga Passwords in LDAP [Page 6] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 directory operation sets a new password. When FALSE or absent, the server is not expected to require proof the user knows the current password before setting a new password. ( IANA-ASSIGNED-OID.1.9 NAME 'passwdRequireChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) Note: replaces 'pwdSafeModify' [BEHERA] 3.1.10 'passwdRequireGenerated' The 'passwdRequireGenerated' attribute specifies whether passwords are to be DSA-generated. If the value of this attribute is TRUE, DSA- generation of passwords is required. Otherwise, not. ( IANA-ASSIGNED-OID.1.10 NAME 'passwdRequireGenerated' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) 3.1.11 'passwdOnBindContraints' This attribute specifies whether constraints upon apply to current passwords as well as new passwords. When this attribute is TRUE, the DSA is expected to verify that a user's password used in authentication meets constraints placed upon passwords and, where the password fails to met the constraints, a password change is required. When this attribute is FALSE or absent, ( IANA-ASSIGNED-OID.1.11 NAME 'passwdOnBindConstraints' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) Zeilenga Passwords in LDAP [Page 7] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 3.1.12. 'passwdConstraints' Values of 'passwdContraints' attribute represent constraints upon passwords, for instance a minimum size constraint. Each value consists of a OID identifying the constraint type and a type-specific parameter. A number of constraints are defined in this document (see Section 4), others may be defined in other documents. ( IANA-ASSIGNED-OID.1.12 NAME 'passwdConstraints' EQUALITY TBD SYNTAX TBD USAGE directoryOperation ) Values of this attribute are of the following ASN.1 type: PasswordConstraintAssertion ::= SEQUENCE { type PASSWORD-CONSTRAINT.&id, parameter PASSWORD-CONSTRAINT.&type } where LDAPOID and AssertionValue as a defined in the Lightweight- Directory-Access-Protocol-V3 [RFC4511] module. Values of this syntax are encoded using the Generic String Encoding Rules (GSER) [RFC3641]. Note: replaces 'pwdCheckQuality' [BEHERA] 3.2. Schema for Password Policy State The following schema is used to hold password policy state for a user. Each state attribute is held in the user's entry. 3.2.1. 'passwdChangeTime' This attribute specifies the time the user's password was last changed. ( IANA-ASSIGNED-OID.2.1 NAME 'passwdChangeTime' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) This attribute should be maintained regardless of what, if any, password policy is enforce. Zulu time should be used. Zeilenga Passwords in LDAP [Page 8] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 Note: replaces 'pwdChangeTime' [BEHERA] 3.2.2. 'passwdGracesUsed' This attribute holds times of graces used after a password has expired. ( IANA-ASSIGNED-OID.2.2 NAME 'passwdGracesUsed' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) Note: replaces 'pwdGraceUseTime' [BEHERA] 3.2.3. 'passwdChangeRequired' This attribute indicates when TRUE that the user's password is required to be changed. ( IANA-ASSIGNED-OID.2.3 NAME 'passwdChangeRequired' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 NO-USER-MODIFICATION USAGE directoryOperation ) Note: replaces 'pwdReset' [BEHERA] 3.3. Additional schema elements 3.3.1. 'passwdPolicySubentry' The 'passwdPolicySubentry' holds the name of the governing password policy subentry for this entry. DSAs SHOULD provide, subject to access controls, this attribute in all entries governed by a password policy subentry. ( IANA-ASSIGNED-OID.3.1 NAME 'passwdPolicySubentry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 Zeilenga Passwords in LDAP [Page 9] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) Note: replaces 'pwdPolicySubentry' [BEHERA] 3.3.2. 'passwdPolicyExclude' The 'passwdPolicyExclude' indicates whether the user is subject to password policy. If 'FALSE' or absent, the user is subject to password policy. If 'TRUE', the user is not subject to password policy. ( IANA-ASSIGNED-OID.3.2 NAME 'passwdRequireChange' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) 4. Password Constraints Password Constraints restrict allowed passwords. A number of constraints are specified in this section, others may be specified in other documents. 4.1. UTF-8 The UTF-8 constraint restricts password values to octet strings which form valid UTF-8 [RFC3629] encodings of Unicode [Unicode] code points. The syntax of the parameter is NULL. This constraint is identified by the OID IANA-ASSIGNED.4.1. 4.1. SASLprep The SASLprep constraint restricts password values to UTF-8 [RFC3629] encoded Unicode [Unicode] character strings prepared by the SASLprep [RFC4013] algorithm, treating the value as a "stored" string ([RFC3454], Section 7). This constraint is identified by the OID IANA-ASSIGNED.4.2. 4.2. Minimum Length The Minimum Length constraint restricts the length of allowed passwords, requiring all passwords to have at least the number of octets specified in the parameter. The syntax of the parameter is: Zeilenga Passwords in LDAP [Page 10] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 MinLenValue ::= INTEGER (SIZE(1..MAX)) This constraint is identified by the OID IANA-ASSIGNED.4.2. 4.X Additional Constraints TBD 5. Application of Password Policy Password policy applies in a number of different circumstances: 1) Bind operations utilizing password-based authentication mechanisms, 2) Password update operations, and 3) Other operations. 5.1. Password-based Bind Operations 5.2. Password update operations 5.3. Other operations 6. Security Considerations Security issues are discussed throughout this document. This document expand upon many of the password-related security considerations discussed in documents comprising the LDAP Technical Specification [RFC4510], in particular [RFC4511], [RFC4512], [RFC4513], and [RFC4519]. Readers are encouraged to familiarize themselves with the security considerations detailed these documents, as well as all documents referenced by this specification. 7. IANA Considerations TBD 8. Acknowledgments This document is based in part upon prior work in the area done by Jim Sermersheim, Ludovic Poitou, Prasanta Behera, and Valerie Chu. Zeilenga Passwords in LDAP [Page 11] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 9. Author's Address Kurt D. Zeilenga Isode Limited Email: Kurt.Zeilenga@Isode.COM 10. References [[Note to the RFC Editor: please replace the citation tags used in referencing Internet-Drafts with tags of the form RFCnnnn where possible.]] 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003. [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1 Types", RFC 3641, October 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification Road Map", RFC 4510, June 2006. [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC 4511, June 2006. [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information Models", RFC 4512, June 2006. [RFC4513] Harrison, R. (editor), "LDAP: Authentication Methods and Security Mechanisms", RFC 4513, June 2006. [RFC4519] Sciberras, A. (editor), "LDAP: Schema for User Applications", RFC 4519, June 2006. [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994). Zeilenga Passwords in LDAP [Page 12] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993). [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 10.2. Informative References [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002. [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006. [BEHERA] Sermersheim, J., and L. Poitou, "Password Policy for LDAP Directories", draft-behera-ldap- password-policy-xx.txt (expired "work in progress"). Appendix A. This appendix is non-normative. This document offers an alternative to the Password Policy proposal detailed in [BEHERA]. This appendix discusses how the approaches differ. [BEHERA] included an "intruder detection check" (also referred to as a "guessing limit"). This feature intended to deter or slow online dictionary attacks. The feature caused authentication against the user's password to be blocked after too many failed after too many Zeilenga Passwords in LDAP [Page 13] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 failed password authentication attempts. However, the feature doesn't necessarily hinder online dictionary attacks, especially those attacking passwords of multiple users simultaneously, and can easily be used to mount denial of service attacks. This document does not offer any specific facility intended to hinder online dictionary attacks, or to detect intruders. While implementations can employs facilities of their own making, caution should be taken to prevent these facilities from being used to mount denial of service attacks. [BEHERA] also included a feature that allowed administrators to lock a user's password and thereby preventing the user from authenticating to the directory with that password. Due possibly to how [BEHERA] describes the feature, the feature has been perceived as a general account lock mechanism. The design of this feature in [BEHERA] is flawed in that overloads the attribute used for indicate intruder lockout with an incompatible usage (directoryOperation versus dsaOperation). This document does not provide a mechanism for the administrator to lock a password, or to lock an account. The latter is more appropriately standardized in a manner not tied to the particular form of credentials. [BEHERA] provided a feature allowing users to authenticate an limited number of times with an expired password in order to set a new password known. While these grace authentications were intended to be used soon after the expiration of the password, [BEHERA] provided no time constraint on their use. This is problematic where the user no longer regularly uses password authentication as it allows access to the directory via a password long after that password has expired, such as in the case where the user authenticates to the directory using mechanism not based upon password (e.g., Kerberos). This document provides a time-constrained grace authentication mechanism. [BEHERA] included a feature that allowed administrators to disallow user password changes, intended to be used in absence of a suitable access control mechanism. While there may be DSAs which do not provide a suitable access control mechanism, this inadequacy seems more appropriately addressed through access control enhancements. To reduce complexity in DSAs which do provide suitable access control mechanisms, this document does not include a user change control feature. [BEHERA] included a protocol extension to request and provide password policy related information. The extension is used both for providing information about the password acted upon by an operation, and information about password policy impacting an operation. The extension has significant limited on when information can be provided. For instance, a time before expiration warning can only be provided in an authentication response. However, it would be useful to provide Zeilenga Passwords in LDAP [Page 14] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 the warning in password update response, as well as any other response as might be useful in communicating a new warning (such as after a change in the maximum password age constraint). This document provides protocol extensions to request and provide password policy related information designed to allow flexible return of password policy information, and to be extensible. [BEHERA] password policy was applied not only to authentication of directory user to the directory service (e.g., Bind operation), but also to application user to directory applications (e.g., Compare operation). [BEHERA] did not include a feature to require DSA-generated passwords. As humans are generally regarded as poor password generators, this document offers a feature to require DSA-generated passwords. This feature is intended to be used in conjunction with LDAP Password Modify [RFC3062] operations requesting DSA-generation of passwords. [BEHERA] included a feature, as part of password quality check feature, to enforce a minimum password length. This document offers features to enforce both minimum length and maximum length. These length checks are offered independently of the quality check feature as the reasons for enforcing length restrictions may be independent of the reasons for enforcing a quality check. For instance, the directory service may have to support DUAs unable to handle password greater than a particular length, necessitating the need for a maximum password length. Of course, DUAs should be designed to handle long passwords. [BEHERA] includes a password history feature. When enabled, previously used passwords are stored in an attribute. The user is prevented from changing their password to any value in the history, as well as reusing the current password. To ensure the attribute doesn't grown to an excessive size, the administrator is required to specify the maximum size for this attribute. When addition of an old password would cause the maximum size to be exceeded, the oldest password in the history is removed. As a user desiring to reuse a password in the history might repeated change their password until the desired password is removed from the history, and hence allowing its reuse, [BEHERA] provides a "minimum age" constraint which prevents uses from passwords which are too young. However, this constraint disallows well-intended changes when the password is too young. For instance, when a user believes their password has been comprised, the user could be precluded from immediately changing their password due to this constraint. The constraint is also problematic when the administrator resets the password as it disallows a user (who may be required to change the password on reset) from immediately resetting the password. Zeilenga Passwords in LDAP [Page 15] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 This document includes a password history feature designed to prevent users from reusing any directory password they have used within a policy-defined period. Unlike [BEHERA], this document does not specify an attribute to hold the password history. As with storage of the user's current password, storage of password history, is a local matter. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS Zeilenga Passwords in LDAP [Page 16] INTERNET-DRAFT draft-zeilenga-ldap-passwords-00 31 March 2008 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zeilenga Passwords in LDAP [Page 17]