One document matched: draft-zeilenga-ldap-passwords-00.txt
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standards Track Isode Limited
Expires in six months 31 March 2008
Passwords in LDAP
<draft-zeilenga-ldap-passwords-00.txt>
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
<ldapext@ietf.org>. Please send editorial comments directly to the
author <Kurt.Zeilenga@Isode.COM>.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:35:29 |