Working on password policy standardization
Clément OUDOT <[email protected]> Wed, 18 Mar 2015 10:37:05 +0100
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <CAK_oV49mhP3FdbXyZUGfbQ6sSC_zRCMLe=W1vfoXgZKBnxUE3Q@mail.gmail.com> |
Hello, following the mail of Ludovic requesting for help on drafts standardization, and as proposed by Michael, I would like to start a discussion on the password policy subject. As a disclaimer, I would like to say that I never worked on publishing drafts or RFC, it is my first attempt here. So please feel free to point out all the mistakes I could do to help me improve this work. 1/ Current situation We have two drafts on the subject: * draft-behera-ldap-password-policy-10 * draft-zeilenga-ldap-passwords-00 I join them to this message. As far as I know, the only implemented draft is the Behera draft, but only in version 9. This is implemented at least in OpenLDAP, but also in OpenDJ and ApacheDS (needs confirmation). 2/ Main drawbacks A list of drawbacks of the Behera draft is presented in Zeilinga draft in Appendix A. I will not reproduce them all here but focus on the most important (from my point of view): * The lock/unlock feature for directory administrators is not clear, and relies on an operational attributes (pwdAccountLockedTime) that should not be written by administrators * There is no time limit for grace authentications * Disallowing password change should be done with ACL, not ppolicy configuration * PPolicy do not allow DSA-generated passwords I would add some others: * There is no definition of what "directory administrators" are, and how provide them specific rights to handle password policy * There is no indication on how apply a password policy to a group of users (I know there was a discussion on this on ApacheDS mailing list some days ago) * The password checker feature is complex to implement. Default password policy allows to specify min lenght (and max lenght), and history check. Why not define in the standard policy how to check different class of characters (upper, lower, digits, etc.)? And also the possibility to refuse a password containing the value of an attribute of the entry (uid, cn, etc.)? * The "password change after reset" feature is also complex to implement, and often ignored by LDAP clients, as the BIND result is always true (the password change after reset information is only present in response control). * There is not authentication date. This is a common requested feature. It is for example implemented in lastbind overlay in OpenLDAP. And also a remark from Ludovic on this list: > There was a general consensus that the current password policy draft needs to be split in multiple documents to separate the configuration of it, the internal state representation and the management side of it (controls and possible extended operations). 3/ Goals * Split password policy drafts in multiple documents : - Configuration - Internal state representation - Management (controls and extended operation) * Remove all unused features of current drafts (pwdAllowUserChange, ...) * Clarify all the administration operations, and how to allow them to directory administrators * Provide more rules on password policy checking * Propose a technical solution to apply a password policy to a list of users (for example with collective attributes) I would be happy to have your feedback on this message, and advices on how to advance on this topic. Clément OUDOT. _______________________________________________ Ldapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/ldapext
draft-behera-ldap-password-policy-10.txt
(text/plain, 78.5 KB)
Network Working Group J. Sermersheim
Internet-Draft Novell, Inc
Intended status: Standards Track L. Poitou
Expires: February 10, 2010 Sun Microsystems
H. Chu, Ed.
Symas Corp.
August 9, 2009
Password Policy for LDAP Directories
draft-behera-ldap-password-policy-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 10, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Sermersheim, et al. Expires February 10, 2010 [Page 1]
Internet-Draft Password Policy for LDAP Directories August 2009
Abstract
Password policy as described in this document is a set of rules that
controls how passwords are used and administered in Lightweight
Directory Access Protocol (LDAP) based directories. In order to
improve the security of LDAP directories and make it difficult for
password cracking programs to break into directories, it is desirable
to enforce a set of rules on password usage. These rules are made to
ensure that users change their passwords periodically, passwords meet
construction requirements, the re-use of old password is restricted,
and to deter password guessing attacks.
Sermersheim, et al. Expires February 10, 2010 [Page 2]
Internet-Draft Password Policy for LDAP Directories August 2009
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Application of Password Policy . . . . . . . . . . . . . . . 6
4. Articles of Password Policy . . . . . . . . . . . . . . . . 7
4.1. Password Usage Policy . . . . . . . . . . . . . . . . . . . 7
4.2. Password Modification Policy . . . . . . . . . . . . . . . . 8
4.3. Restriction of the Password Policy . . . . . . . . . . . . . 10
5. Schema used for Password Policy . . . . . . . . . . . . . . 12
5.1. The pwdPolicy Object Class . . . . . . . . . . . . . . . . . 12
5.2. Attribute Types used in the pwdPolicy ObjectClass . . . . . 12
5.3. Attribute Types for Password Policy State Information . . . 18
6. Controls used for Password Policy . . . . . . . . . . . . . 24
6.1. Request Control . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Response Control . . . . . . . . . . . . . . . . . . . . . . 24
7. Policy Decision Points . . . . . . . . . . . . . . . . . . . 26
7.1. Locked Account Check . . . . . . . . . . . . . . . . . . . . 26
7.2. Password Must be Changed Now Check . . . . . . . . . . . . . 26
7.3. Password Expiration Check . . . . . . . . . . . . . . . . . 27
7.4. Remaining Grace AuthN Check . . . . . . . . . . . . . . . . 27
7.5. Time Before Expiration Check . . . . . . . . . . . . . . . . 27
7.6. Intruder Lockout Check . . . . . . . . . . . . . . . . . . . 27
7.7. Intruder Delay Check . . . . . . . . . . . . . . . . . . . . 27
7.8. Password Too Young Check . . . . . . . . . . . . . . . . . . 28
8. Server Policy Enforcement Points . . . . . . . . . . . . . . 29
8.1. Password-based Authentication . . . . . . . . . . . . . . . 29
8.2. Password Update Operations . . . . . . . . . . . . . . . . . 31
8.3. Other Operations . . . . . . . . . . . . . . . . . . . . . . 34
9. Client Policy Enforcement Points . . . . . . . . . . . . . . 35
9.1. Bind Operation . . . . . . . . . . . . . . . . . . . . . . . 35
9.2. Modify Operations . . . . . . . . . . . . . . . . . . . . . 36
9.3. Add Operation . . . . . . . . . . . . . . . . . . . . . . . 37
9.4. Compare Operation . . . . . . . . . . . . . . . . . . . . . 37
9.5. Other Operations . . . . . . . . . . . . . . . . . . . . . . 38
10. Administration of the Password Policy . . . . . . . . . . . 39
11. Password Policy and Replication . . . . . . . . . . . . . . 40
12. Security Considerations . . . . . . . . . . . . . . . . . . 42
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 44
15. Normative References . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
Sermersheim, et al. Expires February 10, 2010 [Page 3]
Internet-Draft Password Policy for LDAP Directories August 2009
1. Overview
LDAP-based directory services are currently accepted by many
organizations as the access protocol for directories. The ability to
ensure the secure read and update access to directory information
throughout the network is essential to the successful deployment.
Most LDAP implementations support many authentication schemes - the
most basic and widely used is the simple authentication i.e., user DN
and password. In this case, many LDAP servers have implemented some
kind of policy related to the password used to authenticate. Among
other things, this policy includes:
o Whether and when passwords expire.
o Whether failed bind attempts cause the account to be locked.
o If and how users are able to change their passwords.
In order to achieve greater security protection and ensure
interoperability in a heterogeneous environment, LDAP needs to
standardize on a common password policy model. This is critical to
the successful deployment of LDAP directories.
Sermersheim, et al. Expires February 10, 2010 [Page 4]
Internet-Draft Password Policy for LDAP Directories August 2009
2. Conventions
Imperative keywords defined in [RFC2119] are used in this document,
and carry the meanings described there.
All ASN.1 [X.680] Basic Encoding Rules (BER) [X.690] encodings follow
the conventions found in Section 5.1 of [RFC4511].
The term "password administrator" refers to a user that has
sufficient access control privileges to modify users' passwords. The
term "password policy administrator" refers to a user that has
sufficient access control privileges to modify the pwdPolicy object
defined in this document. The access control that is used to
determine whether an identity is a password administrator or password
policy administrator is beyond the scope of this document, but
typically implies that the password administrator has 'write'
privileges to the password attribute.
Sermersheim, et al. Expires February 10, 2010 [Page 5]
Internet-Draft Password Policy for LDAP Directories August 2009
3. Application of Password Policy
The password policy defined in this document can be applied to any
attribute holding a user's password used for an authenticated LDAP
bind operation. In this document, the term "user" represents any
LDAP client application that has an identity in the directory.
This policy is typically applied to the userPassword attribute in the
case of the LDAP simple authentication method [RFC4511] or the case
of password based SASL [RFC4422] authentication such as CRAM-MD5
[RFC2195] and DIGEST-MD5 [RFC2831].
The policy described in this document assumes that the password
attribute holds a single value. No considerations are made for
directories or systems that allow a user to maintain multi-valued
password attributes.
Server implementations MAY institute internal policy whereby certain
identities (such as directory administrators) are not forced to
comply with any of password policy. In this case, the password for a
directory administrator never expires; the account is never locked,
etc.
Sermersheim, et al. Expires February 10, 2010 [Page 6]
Internet-Draft Password Policy for LDAP Directories August 2009
4. Articles of Password Policy
The following sections explain in general terms each aspect of the
password policy defined in this document as well as the need for
each. These policies are subdivided into the general groups of
password usage and password modification. Implementation details are
presented in Section 8 and Section 9.
4.1. Password Usage Policy
This section describes policy enforced when a password is used to
authenticate. The general focus of this policy is to minimize the
threat of intruders once a password is in use.
4.1.1. Password Validity Policy
These mechanisms allow account usage to be controlled independent of
any password expiration policies. The policy defines the absolute
period of time for which an account may be used. This allows an
administrator to define an absolute starting time after which a
password becomes valid, and an absolute ending time after which the
password is disabled.
A mechanism is also provided to define the period of time for which
an account may remain unused before being disabled.
4.1.2. Password Guessing Limit
In order to prevent intruders from guessing a user's password, a
mechanism exists to track the number of consecutive failed
authentication attempts, and take action when a limit is reached.
This policy consists of several parts:
o A counter to track the number of failed authentication attempts.
o The amount of time to delay on the first authentication failure.
o The maximum amount of time to delay on subsequent failures.
o A timeframe in which the limit of consecutive failed
authentication attempts must happen before action is taken.
o A configurable limit on failed authentication attempts.
o The action to be taken when the limit is reached. The action will
either be nothing, or the account will be locked.
Sermersheim, et al. Expires February 10, 2010 [Page 7]
Internet-Draft Password Policy for LDAP Directories August 2009
o An amount of time the account is locked (if it is to be locked).
This can be indefinite.
Note that using the account lock feature provides an easy avenue for
Denial-of-Service (DoS) attacks on user accounts. While some sites'
policies require accounts to be locked, this feature is discouraged
in favor of delaying each failed login attempt.
The delay time will be doubled on each subsequent failure, until it
reaches the maximum time configured.
[TBD: we could also provide a syntax for configuring a backoff
algorithm. E.g. "+<int>" for linearly incrementing delay, "x<int>"
for constant multiplier, "^<int> for geometric. But it's probably
overkill to add a calculator language to the server.]
4.2. Password Modification Policy
This section describes policy enforced while users are modifying
passwords. The general focus of this policy is to ensure that when
users add or change their passwords, the security and effectiveness
of their passwords is maximized. In this document, the term "modify
password operation" refers to any operation that is used to add or
modify a password attribute. Often this is done by updating the
password attribute during an add or modify operation, but MAY be done
by other means such as an extended operation.
4.2.1. Password Expiration, Expiration Warning, and Grace
Authentications
One of the key properties of a password is the fact that it is not
well known. If a password is frequently changed, the chances of that
user's account being broken into are minimized.
Password policy administrators may deploy a password policy that
causes passwords to expire after a given amount of time - thus
forcing users to change their passwords periodically.
As a side effect, there needs to be a way in which users are made
aware of this need to change their password before actually being
locked out of their accounts. One or both of the following methods
handle this:
o A warning may be returned to the user sometime before his password
is due to expire. If the user fails to heed this warning before
the expiration time, his account will be locked.
Sermersheim, et al. Expires February 10, 2010 [Page 8]
Internet-Draft Password Policy for LDAP Directories August 2009
o The user may bind to the directory a preset number of times after
her password has expired. If she fails to change her password
during one of her 'grace' authentications, her account will be
locked.
4.2.2. Password History
When the Password Expiration policy is used, an additional mechanism
may be employed to prevent users from simply re-using a previous
password (as this would effectively circumvent the expiration
policy).
In order to do this; a history of used passwords is kept. The
password policy administrator sets the number of passwords to be
stored at any given time. Passwords are stored in this history
whenever the password is changed. Users aren't allowed to specify
any passwords that are in the history list while changing passwords.
4.2.3. Password Minimum Age
Users may circumvent the Password History mechanism by quickly
performing a series of password changes. If they change their
password enough times, their 'favorite' password will be pushed out
of the history list.
This process may be made less attractive to users by employing a
minimum age for passwords. If users are forced to wait 24 hours
between password changes, they may be less likely to cycle through a
history of 10 passwords.
4.2.4. Password Quality and Minimum length
In order to prevent users from creating or updating passwords that
are easy to guess, a password quality policy may be employed. This
policy consists of two general mechanisms - ensuring that passwords
conform to a defined quality criterion and ensuring that they are of
a minimum length.
Forcing a password to comply with the quality policy may imply a
variety of things including:
o Disallowing trivial or well-known words make up the password.
o Forcing a certain number of digits be used.
o Disallowing anagrams of the user's name.
The implementation of this policy meets with the following problems:
Sermersheim, et al. Expires February 10, 2010 [Page 9]
Internet-Draft Password Policy for LDAP Directories August 2009
o If the password to be added or updated is encrypted by the client
before being sent, the server has no way of enforcing this policy.
Therefore, the onus of enforcing this policy falls upon client
implementations.
o There are no specific definitions of what 'quality checking'
means. This can lead to unexpected behavior in a heterogeneous
environment.
4.2.5. User Defined Passwords
In some cases, it is desirable to disallow users from adding and
updating their own passwords. This policy makes this functionality
possible.
4.2.6. Password Change after Reset
This policy forces the user to update her password after it has been
set for the first time, or has been reset by a password
administrator.
This is needed in scenarios where a password administrator has set or
reset the password to a well-known value.
4.2.7. Safe Modification
As directories become more commonly used, it will not be unusual for
clients to connect to a directory and leave the connection open for
an extended period. This opens up the possibility for an intruder to
make modifications to a user's password while that user's computer is
connected but unattended.
This policy forces the user to prove his identity by specifying the
old password during a password modify operation.
{TODO: This allows a dictionary attack unless we specify that this is
also subject to intruder detection. One solution is to require users
to authN prior to changing password. Another solution is to perform
intruder detection checks when the password for a non-authenticated
identity is being updated}
4.3. Restriction of the Password Policy
The password policy defined in this document can apply to any
attribute containing a password. Password policy state information
is held in the user's entry, and applies to a password attribute, not
a particular password attribute value. Thus the server SHOULD
enforce that the password attribute subject to password policy,
Sermersheim, et al. Expires February 10, 2010 [Page 10]
Internet-Draft Password Policy for LDAP Directories August 2009
contains one and only one password value.
Sermersheim, et al. Expires February 10, 2010 [Page 11]
Internet-Draft Password Policy for LDAP Directories August 2009
5. Schema used for Password Policy
The schema elements defined here fall into two general categories. A
password policy object class is defined which contains a set of
administrative password policy attributes, and a set of operational
attributes are defined that hold general password policy state
information for each user.
5.1. The pwdPolicy Object Class
This object class contains the attributes defining a password policy
in effect for a set of users. Section 10 describes the
administration of this object, and the relationship between it and
particular objects.
( 1.3.6.1.4.1.42.2.27.8.2.1
NAME 'pwdPolicy'
SUP top
AUXILIARY
MUST ( pwdAttribute )
MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
pwdMinLength $ pwdMaxLength $ pwdExpireWarning $
pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )
5.2. Attribute Types used in the pwdPolicy ObjectClass
Following are the attribute types used by the pwdPolicy object class.
5.2.1. pwdAttribute
This holds the name of the attribute to which the password policy is
applied. For example, the password policy may be applied to the
userPassword attribute.
( 1.3.6.1.4.1.42.2.27.8.1.1
NAME 'pwdAttribute'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
5.2.2. pwdMinAge
This attribute holds the number of seconds that must elapse between
modifications to the password. If this attribute is not present, 0
seconds is assumed.
Sermersheim, et al. Expires February 10, 2010 [Page 12]
Internet-Draft Password Policy for LDAP Directories August 2009
( 1.3.6.1.4.1.42.2.27.8.1.2
NAME 'pwdMinAge'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.3. pwdMaxAge
This attribute holds the number of seconds after which a modified
password will expire.
If this attribute is not present, or if the value is 0 the password
does not expire. If not 0, the value must be greater than or equal
to the value of the pwdMinAge.
( 1.3.6.1.4.1.42.2.27.8.1.3
NAME 'pwdMaxAge'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.4. pwdInHistory
This attribute specifies the maximum number of used passwords stored
in the pwdHistory attribute.
If this attribute is not present, or if the value is 0, used
passwords are not stored in the pwdHistory attribute and thus may be
reused.
( 1.3.6.1.4.1.42.2.27.8.1.4
NAME 'pwdInHistory'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.5. pwdCheckQuality
{TODO: Consider changing the syntax to OID. Each OID will list a
quality rule (like min len, # of special characters, etc). These
rules can be specified outside this document.}
{TODO: Note that even though this is meant to be a check that happens
during password modification, it may also be allowed to happen during
authN. This is useful for situations where the password is encrypted
when modified, but decrypted when used to authN.}
This attribute indicates how the password quality will be verified
Sermersheim, et al. Expires February 10, 2010 [Page 13]
Internet-Draft Password Policy for LDAP Directories August 2009
while being modified or added. If this attribute is not present, or
if the value is '0', quality checking will not be enforced. A value
of '1' indicates that the server will check the quality, and if the
server is unable to check it (due to a hashed password or other
reasons) it will be accepted. A value of '2' indicates that the
server will check the quality, and if the server is unable to verify
it, it will return an error refusing the password.
( 1.3.6.1.4.1.42.2.27.8.1.5
NAME 'pwdCheckQuality'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.6. pwdMinLength
When quality checking is enabled, this attribute holds the minimum
number of characters that must be used in a password. If this
attribute is not present, no minimum password length will be
enforced. If the server is unable to check the length (due to a
hashed password or otherwise), the server will, depending on the
value of the pwdCheckQuality attribute, either accept the password
without checking it ('0' or '1') or refuse it ('2').
( 1.3.6.1.4.1.42.2.27.8.1.6
NAME 'pwdMinLength'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.7. pwdMaxLength
When quality checking is enabled, this attribute holds the maximum
number of characters that may be used in a password. If this
attribute is not present, no maximum password length will be
enforced. If the server is unable to check the length (due to a
hashed password or otherwise), the server will, depending on the
value of the pwdCheckQuality attribute, either accept the password
without checking it ('0' or '1') or refuse it ('2').
( 1.3.6.1.4.1.42.2.27.8.1.31
NAME 'pwdMaxLength'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
Sermersheim, et al. Expires February 10, 2010 [Page 14]
Internet-Draft Password Policy for LDAP Directories August 2009
5.2.8. pwdExpireWarning
This attribute specifies the maximum number of seconds before a
password is due to expire that expiration warning messages will be
returned to an authenticating user.
If this attribute is not present, or if the value is 0 no warnings
will be returned. If not 0, the value must be smaller than the value
of the pwdMaxAge attribute.
( 1.3.6.1.4.1.42.2.27.8.1.7
NAME 'pwdExpireWarning'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.9. pwdGraceAuthNLimit
This attribute specifies the number of times an expired password can
be used to authenticate. If this attribute is not present or if the
value is 0, authentication will fail.
( 1.3.6.1.4.1.42.2.27.8.1.8
NAME 'pwdGraceAuthNLimit'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.10. pwdGraceExpiry
This attribute specifies the number of seconds the grace
authentications are valid. If this attribute is not present or if
the value is 0, there is no time limit on the grace authentications.
( 1.3.6.1.4.1.42.2.27.8.1.30
NAME 'pwdGraceExpire'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.11. pwdLockout
This attribute indicates, when its value is "TRUE", that the password
may not be used to authenticate after a specified number of
consecutive failed bind attempts. The maximum number of consecutive
failed bind attempts is specified in pwdMaxFailure.
If this attribute is not present, or if the value is "FALSE", the
Sermersheim, et al. Expires February 10, 2010 [Page 15]
Internet-Draft Password Policy for LDAP Directories August 2009
password may be used to authenticate when the number of failed bind
attempts has been reached.
( 1.3.6.1.4.1.42.2.27.8.1.9
NAME 'pwdLockout'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
5.2.12. pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
this attribute is not present, or if the value is 0 the password
cannot be used to authenticate until reset by a password
administrator.
( 1.3.6.1.4.1.42.2.27.8.1.10
NAME 'pwdLockoutDuration'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.13. pwdMaxFailure
This attribute specifies the number of consecutive failed bind
attempts after which the password may not be used to authenticate.
If this attribute is not present, or if the value is 0, this policy
is not checked, and the value of pwdLockout will be ignored.
( 1.3.6.1.4.1.42.2.27.8.1.11
NAME 'pwdMaxFailure'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.14. pwdFailureCountInterval
This attribute holds the number of seconds after which the password
failures are purged from the failure counter, even though no
successful authentication occurred.
If this attribute is not present, or if its value is 0, the failure
counter is only reset by a successful authentication.
Sermersheim, et al. Expires February 10, 2010 [Page 16]
Internet-Draft Password Policy for LDAP Directories August 2009
( 1.3.6.1.4.1.42.2.27.8.1.12
NAME 'pwdFailureCountInterval'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.15. pwdMustChange
This attribute specifies with a value of "TRUE" that users must
change their passwords when they first bind to the directory after a
password is set or reset by a password administrator. If this
attribute is not present, or if the value is "FALSE", users are not
required to change their password upon binding after the password
administrator sets or resets the password. This attribute is not set
due to any actions specified by this document, it is typically set by
a password administrator after resetting a user's password.
( 1.3.6.1.4.1.42.2.27.8.1.13
NAME 'pwdMustChange'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
5.2.16. pwdAllowUserChange
This attribute indicates whether users can change their own
passwords, although the change operation is still subject to access
control. If this attribute is not present, a value of "TRUE" is
assumed. This attribute is intended to be used in the absence of an
access control mechanism.
( 1.3.6.1.4.1.42.2.27.8.1.14
NAME 'pwdAllowUserChange'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
5.2.17. pwdSafeModify
This attribute specifies whether or not the existing password must be
sent along with the new password when being changed. If this
attribute is not present, a "FALSE" value is assumed.
( 1.3.6.1.4.1.42.2.27.8.1.15
NAME 'pwdSafeModify'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
Sermersheim, et al. Expires February 10, 2010 [Page 17]
Internet-Draft Password Policy for LDAP Directories August 2009
5.2.18. pwdMinDelay
This attribute specifies the number of seconds to delay responding to
the first failed authentication attempt. If this attribute is not
set or is 0, no delays will be used. pwdMaxDelay must also be
specified if pwdMinDelay is set.
( 1.3.6.1.4.1.42.2.27.8.1.24
NAME 'pwdMinDelay'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.19. pwdMaxDelay
This attribute specifies the maximum number of seconds to delay when
responding to a failed authentication attempt. The time specified in
pwdMinDelay is used as the starting time and is then doubled on each
failure until the delay time is greater than or equal to pwdMaxDelay
(or a successful authentication occurs, which resets the failure
counter). pwdMinDelay must be specified if pwdMaxDelay is set.
( 1.3.6.1.4.1.42.2.27.8.1.25
NAME 'pwdMaxDelay'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.2.20. pwdMaxIdle
This attribute specifies the number of seconds an account may remain
unused before it becomes locked. If this attribute is not set or is
0, no check is performed.
( 1.3.6.1.4.1.42.2.27.8.1.26
NAME 'pwdMaxIdle'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
5.3. Attribute Types for Password Policy State Information
Password policy state information must be maintained for each user.
The information is located in each user entry as a set of operational
attributes. These operational attributes are: pwdChangedTime,
pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
pwdReset, pwdPolicySubEntry, pwdStartTime, pwdEndTime,
pwdLastSuccess.
Sermersheim, et al. Expires February 10, 2010 [Page 18]
Internet-Draft Password Policy for LDAP Directories August 2009
5.3.1. Password Policy State Attribute Option
Since the password policy could apply to several attributes used to
store passwords, each of the above operational attributes must have
an option to specify which pwdAttribute it applies to. The password
policy option is defined as the following:
pwd-<passwordAttribute>
where passwordAttribute a string following the OID syntax
(1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
(short name) MUST be used.
For example, if the pwdPolicy object has for pwdAttribute
"userPassword" then the pwdChangedTime operational attribute, in a
user entry, will be:
pwdChangedTime;pwd-userPassword: 20000103121520Z
This attribute option follows sub-typing semantics. If a client
requests a password policy state attribute to be returned in a search
operation, and does not specify an option, all subtypes of that
policy state attribute are returned.
5.3.2. pwdChangedTime
This attribute specifies the last time the entry's password was
changed. This is used by the password expiration policy. If this
attribute does not exist, the password will never expire.
( 1.3.6.1.4.1.42.2.27.8.1.16
NAME 'pwdChangedTime'
DESC 'The time the password was last changed'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.3. pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 000001010000Z value means that the account has been
locked permanently, and that only a password administrator can unlock
the account.
Sermersheim, et al. Expires February 10, 2010 [Page 19]
Internet-Draft Password Policy for LDAP Directories August 2009
( 1.3.6.1.4.1.42.2.27.8.1.17
NAME 'pwdAccountLockedTime'
DESC 'The time an user account was locked'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.4. pwdFailureTime
This attribute holds the timestamps of the consecutive authentication
failures.
( 1.3.6.1.4.1.42.2.27.8.1.19
NAME 'pwdFailureTime'
DESC 'The timestamps of the last consecutive authentication
failures'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.5. pwdHistory
This attribute holds a history of previously used passwords. Values
of this attribute are transmitted in string format as given by the
following ABNF:
pwdHistory = time "#" syntaxOID "#" length "#" data
time = GeneralizedTime
syntaxOID = numericoid ; the string representation of the
; dotted-decimal OID that defines the
; syntax used to store the password.
length = number ; the number of octets in data.
data = <octets representing the password in the format
specified by syntaxOID>.
GeneralizedTime is specified in 3.3.13 of [RFC4517]. numericoid and
number are specified in 1.4 of [RFC4512].
This format allows the server to store, and transmit a history of
Sermersheim, et al. Expires February 10, 2010 [Page 20]
Internet-Draft Password Policy for LDAP Directories August 2009
passwords that have been used. In order for equality matching to
function properly, the time field needs to adhere to a consistent
format. For this purpose, the time field MUST be in GMT format.
( 1.3.6.1.4.1.42.2.27.8.1.20
NAME 'pwdHistory'
DESC 'The history of user s passwords'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.6. pwdGraceUseTime
This attribute holds the timestamps of grace authentications after a
password has expired.
( 1.3.6.1.4.1.42.2.27.8.1.21
NAME 'pwdGraceUseTime'
DESC 'The timestamps of the grace authentication after the
password has expired'
EQUALITY generalizedTimeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.7. pwdReset
This attribute holds a flag to indicate (when TRUE) that the password
has been updated by the password administrator and must be changed by
the user.
( 1.3.6.1.4.1.42.2.27.8.1.22
NAME 'pwdReset'
DESC 'The indication that the password has been reset'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
USAGE directoryOperation )
5.3.8. pwdPolicySubentry
This attribute points to the pwdPolicy subentry in effect for this
object.
Sermersheim, et al. Expires February 10, 2010 [Page 21]
Internet-Draft Password Policy for LDAP Directories August 2009
( 1.3.6.1.4.1.42.2.27.8.1.23
NAME 'pwdPolicySubentry'
DESC 'The pwdPolicy subentry in effect for this object'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.9. pwdStartTime
This attribute specifies the time the entry's password becomes valid
for authentication. Authentication attempts made before this time
will fail. If this attribute does not exist, then no restriction
applies.
( 1.3.6.1.4.1.42.2.27.8.1.27
NAME 'pwdStartTime'
DESC 'The time the password becomes enabled'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
5.3.10. pwdEndTime
This attribute specifies the time the entry's password becomes
invalid for authentication. Authentication attempts made after this
time will fail, regardless of expiration or grace settings. If this
attribute does not exist, then this restriction does not apply.
( 1.3.6.1.4.1.42.2.27.8.1.28
NAME 'pwdEndTime'
DESC 'The time the password becomes disabled'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
Note that pwdStartTime may be set to a time greater than or equal to
pwdEndTime; this simply disables the account.
Sermersheim, et al. Expires February 10, 2010 [Page 22]
Internet-Draft Password Policy for LDAP Directories August 2009
5.3.11. pwdLastSuccess
This attribute holds the timestamp of the last successful
authentication.
( 1.3.6.1.4.1.42.2.27.8.1.29
NAME 'pwdLastSuccess'
DESC 'The timestamp of the last successful authentication'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
Sermersheim, et al. Expires February 10, 2010 [Page 23]
Internet-Draft Password Policy for LDAP Directories August 2009
6. Controls used for Password Policy
This section details the controls used while enforcing password
policy. A request control is defined that is sent by a client with a
request operation in order to elicit a response control. The
response control contains various warnings and errors associated with
password policy.
{TODO: add a note about advertisement and discovery}
6.1. Request Control
This control MAY be sent with any LDAP request message in order to
convey to the server that this client is aware of, and can process
the response control described in this document. When a server
receives this control, it will return the response control when
appropriate and with the proper data.
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
be TRUE or FALSE. There is no controlValue.
6.2. Response Control
If the client has sent a passwordPolicyRequest control, the server
(when solicited by the inclusion of the request control) sends this
control with the following operation responses: bindResponse,
modifyResponse, addResponse, compareResponse and possibly
extendedResponse, to inform of various conditions, and MAY be sent
with other operations (in the case of the changeAfterReset error).
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
the BER encoding of the following type:
PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
error [1] ENUMERATED {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
insufficientPasswordQuality (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) } OPTIONAL }
The timeBeforeExpiration warning specifies the number of seconds
Sermersheim, et al. Expires February 10, 2010 [Page 24]
Internet-Draft Password Policy for LDAP Directories August 2009
before a password will expire. The graceAuthNsRemaining warning
specifies the remaining number of times a user will be allowed to
authenticate with an expired password. The passwordExpired error
signifies that the password has expired and must be reset. The
changeAfterReset error signifies that the password must be changed
before the user will be allowed to perform any operation other than
bind and modify. The passwordModNotAllowed error is set when a user
is restricted from changing her password. The
insufficientPasswordQuality error is set when a password doesn't pass
quality checking. The passwordTooYoung error is set if the age of
the password to be modified is not yet old enough.
Typically, only either a warning or an error will be encoded though
there may be exceptions. For example, if the user is required to
change a password after the password administrator set it, and the
password will expire in a short amount of time, the control may
include the timeBeforeExpiration warning and the changeAfterReset
error.
Sermersheim, et al. Expires February 10, 2010 [Page 25]
Internet-Draft Password Policy for LDAP Directories August 2009
7. Policy Decision Points
Following are a number of procedures used to make policy decisions.
These procedures are typically performed by the server while
processing an operation.
The following sections contain detailed instructions that refer to
attributes of the pwdPolicy object class. When doing so, the
attribute of the pwdPolicy object that governs the entry being
discussed is implied.
7.1. Locked Account Check
A status of true is returned to indicate that the account is locked
if any of these conditions are met:
o The value of the pwdAccountLockedTime attribute is 000001010000Z.
o The current time is less than the value of the pwdStartTime
attribute.
o The current time is greater than or equal to the value of the
pwdEndTime attribute.
o The current time is greater than or equal to the value of the
pwdLastSuccess attribute added to the value of the pwdMaxIdle
attribute.
o The current time is less than the value of the
pwdAccountLockedTime attribute added to the value of the
pwdLockoutDuration.
Otherwise a status of false is returned.
7.2. Password Must be Changed Now Check
A status of true is returned to indicate that the password must be
changed if all of these conditions are met:
o The pwdMustChange attribute is set to TRUE.
o The pwdReset attribute is set to TRUE.
Otherwise a status of false is returned.
Sermersheim, et al. Expires February 10, 2010 [Page 26]
Internet-Draft Password Policy for LDAP Directories August 2009
7.3. Password Expiration Check
A status of true is returned indicating that the password has expired
if the current time minus the value of pwdChangedTime is greater than
the value of the pwdMaxAge.
Otherwise, a status of false is returned.
7.4. Remaining Grace AuthN Check
If the pwdGraceUseTime attribute is present, the number of values in
that attribute subtracted from the value of pwdGraceAuthNLimit is
returned. Otherwise zero is returned. A positive result specifies
the number of remaining grace authentications.
7.5. Time Before Expiration Check
If the pwdExpireWarning attribute is not present a zero status is
returned. Otherwise the following steps are followed:
Subtract the time stored in pwdChangedTime from the current time to
arrive at the password's age. If the password's age is greater than
than the value of the pwdMaxAge attribute, a zero status is returned.
Subtract the value of the pwdExpireWarning attribute from the value
of the pwdMaxAge attribute to arrive at the warning age. If the
password's age is equal to or greater than the warning age, the value
of pwdMaxAge minus the password's age is returned.
7.6. Intruder Lockout Check
A status of true indicating that an intruder has been detected is
returned if the following conditions are met:
o The pwdLockout attribute is TRUE.
o The number of values in the pwdFailureTime attribute that are
younger than pwdFailureCountInterval is greater or equal to the
pwdMaxFailure attribute.
Otherwise a status of false is returned.
While performing this check, values of pwdFailureTime that are old by
more than pwdFailureCountInterval are purged and not counted.
7.7. Intruder Delay Check
If the pwdMinDelay attribute is 0 or not set, zero is returned.
Sermersheim, et al. Expires February 10, 2010 [Page 27]
Internet-Draft Password Policy for LDAP Directories August 2009
Otherwise, a delay time is computed based on the number of values in
the pwdFailureTime attribute. If the computed value is greater than
the pwdMaxDelay attribute, the pwdMaxDelay value is returned.
While performing this check, values of pwdFailureTime that are old by
more than pwdFailureCountInterval are purged and not counted.
7.8. Password Too Young Check
If the Section 7.2 check returned true then this check will return
false, to allow the password to be changed.
A status of true indicating that not enough time has passed since the
password was last updated is returned if:
o The value of pwdMinAge is non-zero and pwdChangedTime is present.
o The value of pwdMinAge is greater than the current time minus the
value of pwdChangedTime.
Otherwise a false status is returned.
Sermersheim, et al. Expires February 10, 2010 [Page 28]
Internet-Draft Password Policy for LDAP Directories August 2009
8. Server Policy Enforcement Points
The server SHOULD enforce that the password attribute subject to a
password policy as defined in this document, contains one and only
one password value.
Note: The case where a single password value is stored in multiple
formats simultaneously is still considered to be only one password
value.
The scenarios in the following operations assume that the client has
attached a passwordPolicyRequest control to the request message of
the operation. In the event that the passwordPolicyRequest control
was not sent, no passwordPolicyResponse control is returned. All
other instructions remain the same.
For successfully completed operations, unless otherwise stated, no
passwordPolicyResponse control is returned.
8.1. Password-based Authentication
This section contains the policy enforcement rules and policy data
updates used while validating a password. Operations that validate
passwords include, but are not limited to, the Bind operation where
the simple choice specifies a password, and the Compare operation
where the attribute being compared holds a password. Note that while
the Compare operation does not authenticate a user to the LDAP
server, it may be used by an external application for purposes of
authentication.
8.1.1. Fail if the account is locked
If the account is locked as specified in Section 7.1, the server
fails the operation with an appropriate resultCode (i.e.
invalidCredentials (49) in the case of a bind operation, compareFalse
(5) in the case of a compare operation, etc.). The server MAY set
the error: accountLocked (1) in the passwordPolicyResponse in the
controls field of the message.
8.1.2. Validated Password Procedures
If the validation operation indicates that the password validated,
these procedures are followed in order:
8.1.2.1. Policy state updates
Delete the pwdFailureTime and pwdAccountLockedTime attributes.
Sermersheim, et al. Expires February 10, 2010 [Page 29]
Internet-Draft Password Policy for LDAP Directories August 2009
Set the value of the pwdLastSuccess attribute to the current time.
Note: setting pwdLastSuccess is optional, but it is required if the
policy has pwdMaxIdle defined.
8.1.2.2. Password must be changed now
If the decision in Section 7.2 returns true, the server sends to the
client a response with an appropriate successful resultCode (i.e.
success (0), compareTrue (6), etc.), and includes the
passwordPolicyResponse in the controls field of the bindResponse
message with the warning: changeAfterReset specified.
For bind, the server MUST then disallow all operations issued by this
user except modify password, bind, unbind, abandon and StartTLS
extended operation.
8.1.2.3. Expired password
If the password has expired as per Section 7.3, the server either
returns a success or failure based on the state of grace
authentications.
8.1.2.3.1. Remaining Grace Authentications
If there are remaining grace authentications as per Section 7.4, the
server adds a new value with the current time in pwdGraceUseTime.
Then it sends to the client a response with an appropriate successful
resultCode (i.e. success (0), compareTrue (6), etc.), and includes
the passwordPolicyResponse in the controls field of the response
message with the warning: graceAuthNsRemaining choice set to the
number of grace authentications left.
Implementor's note: The system time of the host machine may be more
granular than is needed to ensure unique values of this attribute.
It is recommended that a mechanism is used to ensure unique
generalized time values. The fractional seconds field may be used
for this purpose.
8.1.2.3.2. No Remaining Grace Authentications
If there are no remaining grace authentications, the server fails the
operation with an appropriate resultCode (invalidCredentials (49),
compareFalse (5), etc.), and includes the passwordPolicyResponse in
the controls field of the bindResponse message with the error:
passwordExpired (0) set.
Sermersheim, et al. Expires February 10, 2010 [Page 30]
Internet-Draft Password Policy for LDAP Directories August 2009
8.1.2.4. Expiration Warning
If the result of Section 7.5 is a positive number, the server sends
to the client a response with an appropriate successful resultCode
(i.e. success (0), compareTrue (6), etc.), and includes the
passwordPolicyResponse in the controls field of the bindResponse
message with the warning: timeBeforeExiration set to the value as
described above. Otherwise, the server sends a successful response,
and omits the passwordPolicyResponse.
8.1.3. AuthN Failed Procedures
If the authentication process indicates that the password failed
validation due to invalid credentials, these procedures are followed:
8.1.3.1. Policy state update
Add the current time as a value of the pwdFailureTime attribute.
Implementor's note: The system time of the host machine may be more
granular than is needed to ensure unique values of this attribute.
It is recommended that a mechanism is used to ensure unique
generalized time values. The fractional seconds field may be used
for this purpose.
8.1.3.2. Handle Intruder Detection
If the check in Section 7.6 returns a true state, the server locks
the account by setting the value of the pwdAccountLockedTime
attribute to the current time. After locking the account, the server
fails the operation with an appropriate resultCode
(invalidCredentials (49), compareFalse (5), etc.), and includes the
passwordPolicyResponse in the controls field of the message with the
error: accountLocked (1).
If the check in Section 7.7 returns a non-zero value, the server
waits that number of seconds before sending the authentication
response back to the client.
8.2. Password Update Operations
Because the password is stored in an attribute, various operations
(like add and modify) may be used to create or update a password.
But some alternate mechanisms have been defined or may be defined,
such as the LDAP Password Modify Extended Operation [RFC3062].
While processing a password update, the server performs the following
steps:
Sermersheim, et al. Expires February 10, 2010 [Page 31]
Internet-Draft Password Policy for LDAP Directories August 2009
8.2.1. Safe Modification
If pwdSafeModify is set to TRUE and if there is an existing password
value, the server ensures that the password update operation includes
the user's existing password.
When the LDAP modify operation is used to modify a password, this is
done by specifying both a delete action and an add or replace action,
where the delete action specifies the existing password, and the add
or replace action specifies the new password. Other password update
operations SHOULD employ a similar mechanism. Otherwise this policy
will fail.
If the existing password is not specified, the server does not
process the operation and sends the appropriate response message to
the client with the resultCode: insufficientAccessRights (50), and
includes the passwordPolicyResponse in the controls field of the
response message with the error: mustSupplyOldPassword (4).
8.2.2. Change After Reset
If the decision in Section 7.2 returns true, the server ensures that
the password update operation contains no modifications other than
the modification of the password attribute. If other modifications
exist, the server sends a response message to the client with the
resultCode: insufficientAccessRights (50), and includes the
passwordPolicyResponse in the controls field of the response message
with the error: changeAfterReset (2).
8.2.3. Rights Check
Check to see whether the bound identity has sufficient rights to
update the password. If the bound identity is a user changing its
own password, this MAY be done by checking the pwdAllowUserChange
attribute or using an access control mechanism. The determination of
this is implementation specific. If the user is not allowed to
update her password, the server sends a response message to the
client with the resultCode: insufficientAccessRights (50), and
includes the passwordPolicyResponse in the controls field of the
response message with the error: passwordModNotAllowed (3).
8.2.4. Too Early to Update
If the check in Section 7.8 results in a true status The server sends
a response message to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyResponse in
the controls field of the response message with the error:
passwordTooYoung (7).
Sermersheim, et al. Expires February 10, 2010 [Page 32]
Internet-Draft Password Policy for LDAP Directories August 2009
8.2.5. Password Quality
Check the value of the pwdCheckQuality attribute. If the value is
non-zero, the server:
o Ensure that the password meets the quality criteria enforced by
the server. This enforcement is implementation specific. If the
server is unable to check the quality (due to a hashed password or
otherwise), the value of pwdCheckQuality is evaluated. If the
value is 1, operation continues. If the value is 2, the server
sends a response message to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyResponse
in the controls field of the response message with the error:
insufficientPasswordQuality (5). If the server is able to check
the password quality, and the check fails, the server sends a
response message to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyResponse
in the controls field of the response message with the error:
insufficientPasswordQuality (5).
o checks the value of the pwdMinLength attribute. If the value is
non-zero, it ensures that the new password is of at least the
minimum length. If the server is unable to check the length (due
to a hashed password or otherwise), the value of pwdCheckQuality
is evaluated. If the value is 1, operation continues. If the
value is 2, the server sends a response message to the client with
the resultCode: constraintViolation (19), and includes the
passwordPolicyResponse in the controls field of the response
message with the error: passwordTooShort (6). If the server is
able to check the password length, and the check fails, the server
sends a response message to the client with the resultCode:
constraintViolation (19), and includes the passwordPolicyResponse
in the controls field of the response message with the error:
passwordTooShort (6).
8.2.6. Invalid Reuse
If pwdInHistory is present and its value is non-zero, the server
checks whether this password exists in the entry's pwdHistory
attribute or in the current password attribute. If the password does
exist in the pwdHistory attribute or in the current password
attribute, the server sends a response message to the client with the
resultCode: constraintViolation (19), and includes the
passwordPolicyResponse in the controls field of the response message
with the error: passwordInHistory (8).
Sermersheim, et al. Expires February 10, 2010 [Page 33]
Internet-Draft Password Policy for LDAP Directories August 2009
8.2.7. Policy State Updates
If the steps have completed without causing an error condition, the
server performs the following steps in order to update the necessary
password policy state attributes:
If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
updates the pwdChangedTime attribute on the entry to the current
time.
If the value of pwdInHistory is non-zero, the server adds the
previous password (if one existed) to the pwdHistory attribute. If
the number of attributes held in the pwdHistory attribute exceeds the
value of pwdInHistory, the server removes the oldest excess
passwords.
If the value the pwdMustChange is TRUE and the modification is
performed by a password administrator, then the pwdReset attribute is
set to TRUE. Otherwise, the pwdReset is removed from the user's
entry if it exists.
The pwdFailureTime and pwdGraceUseTime attributes is removed from the
user's entry if they exist.
8.3. Other Operations
For operations other than bind, password update, unbind, abandon or
StartTLS, if the decision in Section 7.2 returns true, the server
sends a response message to the client with the resultCode:
insufficientAccessRights (50), and includes the
passwordPolicyResponse in the controls field of the response message
with the error: changeAfterReset (2).
Sermersheim, et al. Expires February 10, 2010 [Page 34]
Internet-Draft Password Policy for LDAP Directories August 2009
9. Client Policy Enforcement Points
These sections illustrate possible scenarios for each LDAP operation
and define the types of responses that identify those scenarios.
The scenarios in the following operations assume that the client
attached a passwordPolicyRequest control to the request message of
the operation, and thus may receive a passwordPolicyResponse control
in the response message. In the event that the passwordPolicyRequest
control was not sent, no passwordPolicyResponse control is returned.
All other instructions remain the same.
9.1. Bind Operation
For every bind response received, the client checks the resultCode of
the bindResponse and checks for a passwordPolicyResponse control to
determine if any of the following conditions are true and MAY prompt
the user accordingly.
o bindResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = accountLocked (1): The password
failure limit has been reached and the account is locked. The
user needs to retry later or contact the password administrator to
reset the password.
o bindResponse.resultCode = success (0),
passwordPolicyResponse.error = changeAfterReset (2): The user is
binding for the first time after the password administrator set
the password. In this scenario, the client SHOULD prompt the user
to change his password immediately.
o bindResponse.resultCode = success (0),
passwordPolicyResponse.warning = graceAuthNsRemaining: The
password has expired but there are remaining grace
authentications. The user needs to change it.
o bindResponse.resultCode = invalidCredentials (49),
passwordPolicyResponse.error = passwordExpired (0): The password
has expired and there are no more grace authentications. The user
contacts the password administrator in order to have its password
reset.
o bindResponse.resultCode = success (0),
passwordPolicyResponse.warning = timeBeforeExpiration: The user's
password will expire in n number of seconds.
Sermersheim, et al. Expires February 10, 2010 [Page 35]
Internet-Draft Password Policy for LDAP Directories August 2009
9.2. Modify Operations
9.2.1. Modify Request
If the application or client encrypts the password prior to sending
it in a password modification operation (whether done through
modifyRequest or another password modification mechanism), it SHOULD
check the values of the pwdMinLength, and pwdCheckQuality attributes
and SHOULD enforce these policies.
9.2.2. Modify Response
If the modifyRequest operation was used to change the password, or if
another mechanism is used --such as an extendedRequest-- the
modifyResponse or other appropriate response MAY contain information
pertinent to password policy. The client checks the resultCode of
the response and checks for a passwordPolicyResponse control to
determine if any of the following conditions are true and optionally
notify the user of the condition.
o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
attempted to change her password without specifying the old
password but the password policy requires this.
o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = changeAfterReset (2): The user must
change her password before submitting any other LDAP requests.
o pwdModResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = passwordModNotAllowed (3): The user
doesn't have sufficient rights to change his password.
o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordTooYoung (7): It is too
soon after the last password modification to change the password.
o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = insufficientPasswordQuality (5):
The password failed quality checking.
o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordTooShort (6): The length of
the password is too short.
o pwdModResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordInHistory (8): The password
has already been used; the user must choose a different one.
Sermersheim, et al. Expires February 10, 2010 [Page 36]
Internet-Draft Password Policy for LDAP Directories August 2009
9.3. Add Operation
If a password is specified in an addRequest, the client checks the
resultCode of the addResponse and checks for a passwordPolicyResponse
control to determine if any of the following conditions are true and
may prompt the user accordingly.
o addResponse.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = passwordModNotAllowed (3): The user
doesn't have sufficient rights to add this password.
o addResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = insufficientPasswordQuality (5):
The password failed quality checking.
o addResponse.resultCode = constraintViolation (19),
passwordPolicyResponse.error = passwordTooShort (6): The length of
the password is too short.
9.4. Compare Operation
When a compare operation is used to compare a password, the client
checks the resultCode of the compareResponse and checks for a
passwordPolicyResponse to determine if any of the following
conditions are true and MAY prompt the user accordingly. These
conditions assume that the result of the comparison was true.
o compareResponse.resultCode = compareFalse (5),
passwordPolicyResponse.error = accountLocked (1): The password
failure limit has been reached and the account is locked. The
user needs to retry later or contact the password administrator to
reset the password.
o compareResponse.resultCode = compareTrue (6),
passwordPolicyResponse.warning = graceAuthNsRemaining: The
password has expired but there are remaining grace
authentications. The user needs to change it.
o compareResponse.resultCode = compareFalse (5),
passwordPolicyResponse.error = passwordExpired (0): The password
has expired and there are no more grace authentications. The user
must contact the password administrator to reset the password.
o compareResponse.resultCode = compareTrue (6),
passwordPolicyResponse.warning = timeBeforeExpiration: The user's
password will expire in n number of seconds.
Sermersheim, et al. Expires February 10, 2010 [Page 37]
Internet-Draft Password Policy for LDAP Directories August 2009
9.5. Other Operations
For operations other than bind, unbind, abandon or StartTLS, the
client checks the result code and control to determine if any other
actions are needed.
o <Response>.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = accountLocked (1) : The password
failure limit has been reached and the account is locked. The
user needs to retry later or contact the password administrator to
reset the password.
o <Response>.resultCode = insufficientAccessRights (50),
passwordPolicyResponse.error = changeAfterReset (2) : The user
needs to change the password immediately.
Sermersheim, et al. Expires February 10, 2010 [Page 38]
Internet-Draft Password Policy for LDAP Directories August 2009
10. Administration of the Password Policy
{TODO: Need to define an administrativeRole (need OID). Need to
describe whether pwdPolicy admin areas can overlap}
A password policy is defined for a particular subtree of the DIT by
adding to an LDAP subentry whose immediate superior is the root of
the subtree, the pwdPolicy auxiliary object class. The scope of the
password policy is defined by the SubtreeSpecification attribute of
the LDAP subentry as specified in [RFC3672].
It is possible to define password policies for different password
attributes within the same pwdPolicy entry, by specifying multiple
values of the pwdAttribute. But password policies could also be in
separate sub entries as long as they are contained under the same
LDAP subentry.
Only one policy may be in effect for a given password attribute in
any entry. If multiple policies exist which overlap in the range of
entries affected, the resulting behavior is undefined.
Modifying the password policy MUST NOT result in any change in users'
entries to which the policy applies.
It SHOULD be possible to overwrite the password policy for one user
by defining a new policy in a subentry of the user entry.
Each object that is controlled by password policy advertises the
subentry that is being used to control its policy in its
pwdPolicySubentry attribute. Clients wishing to examine or manage
password policy for an object may interrogate the pwdPolicySubentry
for that object in order to arrive at the proper pwdPolicy subentry.
Sermersheim, et al. Expires February 10, 2010 [Page 39]
Internet-Draft Password Policy for LDAP Directories August 2009
11. Password Policy and Replication
{TODO: This section needs to be changed to highlight the pitfalls of
replication, suggest some implementation choices to overcome those
pitfalls, but remove prescriptive language relating to the update of
state information}
The pwdPolicy object defines the password policy for a portion of the
DIT and MUST be replicated on all the replicas of this subtree, as
any subentry would be, in order to have a consistent policy among all
replicated servers.
The elements of the password policy that are related to the users are
stored in the entry themselves as operational attributes. As these
attributes are subject to modifications even on a read-only replica,
replicating them must be carefully considered.
The pwdChangedTime attribute MUST be replicated on all replicas, to
allow expiration of the password.
The pwdReset attribute MUST be replicated on all replicas, to deny
access to operations other than bind and modify password.
The pwdHistory attribute MUST be replicated to writable replicas. It
doesn't have to be replicated to a read-only replica, since the
password will never be directly modified on this server.
The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
attributes SHOULD be replicated to writable replicas, making the
password policy global for all servers. When the user entry is
replicated to a read-only replica, these attributes SHOULD NOT be
replicated. This means that the number of failures, of grace
authentications and the locking will take place on each replicated
server. For example, the effective number of failed attempts on a
user password will be N x M (where N is the number of servers and M
the value of pwdMaxFailure attribute). Replicating these attributes
to a read-only replica MAY reduce the number of tries globally but
MAY also introduce some inconstancies in the way the password policy
is applied.
Note: there are some situations where global replication of these
state attributes may not be desired. For example, if two clusters of
replicas are geographically remote and joined by a slow network link,
and their users only login from one of the two locations, it may be
unnecessary to propagate all of the state changes from one cluster to
the other. Servers SHOULD allow administrators to control which
attributes are replicated on a case-by-case basis.
Sermersheim, et al. Expires February 10, 2010 [Page 40]
Internet-Draft Password Policy for LDAP Directories August 2009
Servers participating in a loosely consistent multi-master
replication agreement SHOULD employ a mechanism which ensures
uniqueness of values when populating the attributes pwdFailureTime
and pwdGraceUseTime. The method of achieving this is a local matter
and may consist of using a single authoritative source for the
generation of unique time values, or may consist of the use of the
fractional seconds part to hold a replica identifier.
Sermersheim, et al. Expires February 10, 2010 [Page 41]
Internet-Draft Password Policy for LDAP Directories August 2009
12. Security Considerations
This document defines a set of rules to implement in an LDAP server,
in order to mitigate some of the security risks associated with the
use of passwords and to make it difficult for password cracking
programs to break into directories.
Authentication with a password MUST follow the recommendations made
in [RFC4513].
Modifications of passwords SHOULD only occur when the connection is
protected with confidentiality and secure authentication.
Access controls SHOULD be used to restrict access to the password
policy attributes. The attributes defined to maintain the password
policy state information SHOULD only be modifiable by the password
administrator or higher authority. The pwdHistory attribute MUST be
subject to the same level of access control as the attrbute holding
the password.
As it is possible to define a password policy for one specific user
by adding a subentry immediately under the user's entry, Access
Controls SHOULD be used to restrict the use of the pwdPolicy object
class or the LDAP subentry object class.
When the intruder detection password policy is enforced, the LDAP
directory is subject to a denial of service attack. A malicious user
could deliberately lock out one specific user's account (or all of
them) by sending bind requests with wrong passwords. There is no way
to protect against this kind of attack. The LDAP directory server
SHOULD log as much information as it can (such as client IP address)
whenever an account is locked, in order to be able to identify the
origin of the attack. Denying anonymous access to the LDAP directory
is also a way to restrict this kind of attack. Using the login delay
instead of the lockout mechanism will also help avoid this denial of
service.
Returning certain status codes (such as passwordPolicyResponse.error
= accountLocked) allows a denial of service attacker to know that it
has successfully denied service to an account. Servers SHOULD
implement additional checks which return the same status when it is
sensed that some number of failed authentication requests has occured
on a single connection, or from a client address. Server
implementors are encouraged to invent other checks similar to this in
order to thwart this type of DoS attack.
Sermersheim, et al. Expires February 10, 2010 [Page 42]
Internet-Draft Password Policy for LDAP Directories August 2009
13. IANA Considerations
<<<TBD>>>
Sermersheim, et al. Expires February 10, 2010 [Page 43]
Internet-Draft Password Policy for LDAP Directories August 2009
14. Acknowledgement
This document is based in part on prior work done by Valerie Chu from
Netscape Communications Corp, published as
draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
participated in early revisions of this document.
Sermersheim, et al. Expires February 10, 2010 [Page 44]
Internet-Draft Password Policy for LDAP Directories August 2009
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
RFC 3062, February 2001.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", RFC 3383, September 2002.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512,
June 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules", RFC 4517, June 2006.
[X.680] International Telecommunications Union, "Abstract Syntax
Notation One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, July 2002.
[X.690] International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T
Recommendation X.690, July 2002.
Sermersheim, et al. Expires February 10, 2010 [Page 45]
Internet-Draft Password Policy for LDAP Directories August 2009
Authors' Addresses
Jim Sermersheim
Novell, Inc
1800 South Novell Place
Provo, Utah 84606
US
Phone: +1 801 861-3088
Email: [email protected]
Ludovic Poitou
Sun Microsystems
180, Avenue de l'Europe
Zirst de Montbonnot, Saint Ismier cedex 38334
FR
Phone: +33 476 188 212
Email: [email protected]
Howard Chu (editor)
Symas Corp.
18740 Oxnard Street, Suite 313A
Tarzana, California 91356
US
Phone: +1 818 757-7087
Email: [email protected]
Sermersheim, et al. Expires February 10, 2010 [Page 46]
draft-zeilenga-ldap-passwords-00.txt
(text/plain, 30.4 KB)
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
<[email protected]>. Please send editorial comments directly to the
author <[email protected]>.
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: [email protected]
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
[email protected].
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]