[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                   Kurt D. Zeilenga
Intended Category: Standards Track               Isode Limited
Expires in six months                            31 March 2008



                            Passwords in LDAP
                  <draft-zeilenga-ldap-passwords-00.txt>


Status of this Memo

  Distribution of this memo is unlimited.  Technical discussion of this
  document will take place on the IETF LDAP Extensions mailing list
  <ldapext@ietf.org>.  Please send editorial comments directly to the
  author <Kurt.Zeilenga@Isode.COM>.

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference material
  or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.


  Copyright (C) The IETF Trust (2008).

  Please see the Full Copyright section near the end of this document
  for more information.









Zeilenga                    Passwords in LDAP                   [Page 1]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


Abstract

  The Lightweight Directory Access Protocol (LDAP) provides a number of
  password-based mechanisms for authenticating directory users to the
  directory service.  This document discusses the use of passwords in
  directory user authentication.  The document specifies schema for
  representing a basic password policy and directory service enforcement
  of password policy.


Table of Contents

  TBD


1.  Introduction

  The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
  number of password-based mechanisms for authenticating directory users
  to the directory service.  Supported password-based mechanisms include
  the Simple DN/password mechanism [RFC4511] and the Simple
  Authentication and Security Layer (SASL) [RFC4422] PLAIN [RFC4616]
  mechanism.  Likewise, the Directory Access Protocol (DAP) [X.511]
  provides a password-based authentication mechanism.

  This document discusses the use of passwords in directory
  authentication, management of passwords held in the directory, and
  application of password policy.

  To improve directory security and interoperability, the document
  specifies an an administrative model for password policy in LDAP and
  X.500 [X.500] directory systems, defines schema elements for
  representing a basic password policy, and details directory service
  enforcement of password policy.

  Among other things, this policy statement includes:

  - whether passwords must adhere to various constraints;
  - whether passwords expire and, if so, when; and
  - whether human-generated or machine-generated passwords
      are to be used.

  This policy, which is intended to be enforced by Directory System
  Agents (or servers), applies to authentication and authorization of
  Directory User Agents (or clients) to the directory service, as well
  as directory user password administration.

  Applicability of this policy to other uses, such as authentication of



Zeilenga                    Passwords in LDAP                   [Page 2]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  users to a directory user agent, may be limited.  Such uses are not
  further discussed in this document.

  Directory System Agents (DSAs) implementing this specification SHOULD
  support the LDAP Password Modify Extended Operation [RFC3062].


2. Terminology

  DIT stands for Directory Information Tree.
  DSA stands for Directory System Agent (or server).
  DSE stands for DSA-specific Entry.
  DUA stands for Directory User Agent (or client).

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

  Schema definitions are provided using LDAP description formats
  [RFC4512].  Definitions provided here are formatted (line wrapped) for
  readability.


3.  Password Policy Administrative Model

  This document extends the X.500 administrative model to support
  password policy.

  The administration of a DIT Domain is extended to involve execution of
  an additional function, password administration.

  The term Password Authority identifies the role of the Administrative
  Authority as it pertains to the establishment, administration and
  execution of password policy governing use of passwords in a DIT
  Domain.  The Password Authority is a specific Administrative
  Authority.

  [...]

  Any user governed by a password policy is restricted to a single
  password.  This restriction is enforced upon password update.


3.1.  Schema for Password Policy

  The following schema is used to specify a password policy for a
  subtree of the DIT.




Zeilenga                    Passwords in LDAP                   [Page 3]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


3.1.1. 'passwdPolicy'

  A subentry object belonging to the 'passwdPolicy' auxiliary class is
  used to state the password policy for a subtree of the DIT.

       ( IANA-ASSIGNED-OID.1.1
         NAME 'passwdPolicy' AUXILIARY
         MAY ( passwdAttribute $
            passwdExpiry $ passwdExpiryWarning $
            passwdGraces $ passwdGracesExpiry $
            passwdContraints $ passwdHistoryDuration $
            passwdRequireChange $ passwdRequireOld $
            passwdRequireGenerated $ passwdOnBindConstraints ) )

3.1.2. 'passwdAttribute'

  The 'passwdAttribute'  attribute specifies the attribute to which the
  password policy applies.

       ( IANA-ASSIGNED-OID.1.2
         NAME 'passwdAttribute'
         EQUALITY objectIdentifierMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
         SINGLE-VALUE
         USAGE directoryOperation )

  If absent, the policy applies to passwords held in any external
  password store.

  Note: replaces 'pwdAttribute' [BEHERA]


3.1.3. 'passwdExpiry'

  The 'passwdExpiry' attribute specifies the age, in seconds, in which a
  password expires.

       ( IANA-ASSIGNED-OID.1.3
         NAME 'passwdExpiry'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE
         USAGE directoryOperation )

  If the attribute is absent, is zero (0) or negative, passwords do not
  expire.

  Note: replaces 'pwdMaxAge' [BEHERA]



Zeilenga                    Passwords in LDAP                   [Page 4]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


3.1.4. 'passwdExpiryWarning'

  The 'passwdExpiryWarning' attribute specifies the time, in seconds,
  before password expiry that warning of the expiry should be provided.

       ( IANA-ASSIGNED-OID.1.4
         NAME 'passwdExpiryWarning'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE
         USAGE directoryOperation )

  If the attribute is absent, is zero (0) or negative, no warnings are
  to be provided.

  Note: replaces 'pwdExpireWarning' [BEHERA]


3.1.5. 'passwdGraces'

  The 'passwdGraces' attribute specifies the number of times the user
  may authenticate using an expired password for the purpose of setting
  a new password.

       ( IANA-ASSIGNED-OID.1.5
         NAME 'passwdGraces'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE
         USAGE directoryOperation )

  If the attribute is absent, is zero (0) or negative, no grace is
  given.

  Note: replaces 'pwdGraceAuthNLimit' [BEHERA]

3.1.6. 'passwdGracesExpiry'

  The 'passwdGracesExiry' attribute specifies the number of seconds
  allowed graces (passwdGraces) are valid.

       ( IANA-ASSIGNED-OID.1.5
         NAME 'passwdGracesExpiry'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE
         USAGE directoryOperation )




Zeilenga                    Passwords in LDAP                   [Page 5]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  If the attribute is absent, is zero (0) or negative, allowed graces do
  not expire.


3.1.7. 'passwdHistoryDuration'

  The 'passwdHistoryDuration' attribute specifies the length of time, in
  seconds, that passwords are to remembered.

       ( IANA-ASSIGNED-OID.1.7
         NAME 'passwdHistoryDuration'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         SINGLE-VALUE
         USAGE directoryOperation )

  If the attribute is absent or is zero (0) or negative, no history is
  maintained.

  Note: replaces 'pwdInHistory' [BEHERA]


3.1.8 'passwdRequireChange'

  The 'passwdRequireChange' attribute specifies whether user is required
  to change their password after it has been set by a password
  administrator.   When TRUE, the server is expected to require the user
  to change their password after it has been set by an administrator.
  Otherwise, the user is not required to change their password after it
  has been set by an administrator.

       ( IANA-ASSIGNED-OID.1.8
         NAME 'passwdRequireChange'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         SINGLE-VALUE
         USAGE directoryOperation )

  Note: replaces 'pwdMustChange' [BEHERA]


3.1.9 'passwdRequireOld'

  The 'passwdRequireOld' attribute specifies whether user is required to
  prove they know the current password before setting the password.
  When TRUE, the server is expected to reject a user's request to change
  their password when the user has not proven they know the current
  password.  Such proof generally should be provided in the same



Zeilenga                    Passwords in LDAP                   [Page 6]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  directory operation sets a new password.  When FALSE or absent, the
  server is not expected to require proof the user knows the current
  password before setting a new password.

       ( IANA-ASSIGNED-OID.1.9
         NAME 'passwdRequireChange'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         SINGLE-VALUE
         USAGE directoryOperation )

  Note: replaces 'pwdSafeModify' [BEHERA]


3.1.10 'passwdRequireGenerated'

  The 'passwdRequireGenerated' attribute specifies whether passwords are
  to be DSA-generated.  If the value of this attribute is TRUE, DSA-
  generation of passwords is required.  Otherwise, not.

       ( IANA-ASSIGNED-OID.1.10
         NAME 'passwdRequireGenerated'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         SINGLE-VALUE
         USAGE directoryOperation )


3.1.11 'passwdOnBindContraints'

  This attribute specifies whether constraints upon apply to current
  passwords as well as new passwords.

  When this attribute is TRUE, the DSA is expected to verify that a
  user's password used in authentication meets constraints placed upon
  passwords and, where the password fails to met the constraints, a
  password change is required.

  When this attribute is FALSE or absent,

       ( IANA-ASSIGNED-OID.1.11
         NAME 'passwdOnBindConstraints'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         SINGLE-VALUE
         USAGE directoryOperation )





Zeilenga                    Passwords in LDAP                   [Page 7]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


3.1.12. 'passwdConstraints'

  Values of 'passwdContraints' attribute represent constraints upon
  passwords, for instance a minimum size constraint.  Each value
  consists of a OID identifying the constraint type and a type-specific
  parameter.  A number of constraints are defined in this document (see
  Section 4), others may be defined in other documents.

       ( IANA-ASSIGNED-OID.1.12
         NAME 'passwdConstraints'
         EQUALITY TBD
         SYNTAX TBD
         USAGE directoryOperation )

  Values of this attribute are of the following ASN.1 type:

       PasswordConstraintAssertion ::= SEQUENCE {
            type      PASSWORD-CONSTRAINT.&id,
            parameter PASSWORD-CONSTRAINT.&type
       }

  where LDAPOID and AssertionValue as a defined in the Lightweight-
  Directory-Access-Protocol-V3 [RFC4511] module.  Values of this syntax
  are encoded using the Generic String Encoding Rules (GSER) [RFC3641].

  Note: replaces 'pwdCheckQuality' [BEHERA]


3.2. Schema for Password Policy State

  The following schema is used to hold password policy state for a user.
  Each state attribute is held in the user's entry.

3.2.1. 'passwdChangeTime'

  This attribute specifies the time the user's password was last
  changed.

       ( IANA-ASSIGNED-OID.2.1
         NAME 'passwdChangeTime'
         EQUALITY generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE NO-USER-MODIFICATION
         USAGE directoryOperation )

  This attribute should be maintained regardless of what, if any,
  password policy is enforce.   Zulu time should be used.



Zeilenga                    Passwords in LDAP                   [Page 8]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  Note: replaces 'pwdChangeTime' [BEHERA]


3.2.2. 'passwdGracesUsed'

  This attribute holds times of graces used after a password has
  expired.

       ( IANA-ASSIGNED-OID.2.2
         NAME 'passwdGracesUsed'
         EQUALITY generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE NO-USER-MODIFICATION
         USAGE directoryOperation )

  Note: replaces 'pwdGraceUseTime' [BEHERA]


3.2.3. 'passwdChangeRequired'

  This attribute indicates when TRUE that the user's password is
  required to be changed.

       ( IANA-ASSIGNED-OID.2.3
         NAME 'passwdChangeRequired'
         EQUALITY booleanMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
         NO-USER-MODIFICATION
         USAGE directoryOperation )

  Note: replaces 'pwdReset' [BEHERA]


3.3. Additional schema elements

3.3.1. 'passwdPolicySubentry'

  The 'passwdPolicySubentry' holds the name of the governing password
  policy subentry for this entry.

  DSAs SHOULD provide, subject to access controls, this attribute in all
  entries governed by a password policy subentry.

       ( IANA-ASSIGNED-OID.3.1
         NAME 'passwdPolicySubentry'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12



Zeilenga                    Passwords in LDAP                   [Page 9]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


         SINGLE-VALUE NO-USER-MODIFICATION
         USAGE directoryOperation )

  Note: replaces 'pwdPolicySubentry' [BEHERA]


3.3.2. 'passwdPolicyExclude'

  The 'passwdPolicyExclude' indicates whether the user is subject to
  password policy.  If 'FALSE' or absent, the user is subject to
  password policy.  If 'TRUE', the user is not subject to password
  policy.

       ( IANA-ASSIGNED-OID.3.2        NAME 'passwdRequireChange'
  EQUALITY booleanMatch        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
  SINGLE-VALUE        USAGE directoryOperation )


4. Password Constraints

  Password Constraints restrict allowed passwords.  A number of
  constraints are specified in this section, others may be specified in
  other documents.

  4.1. UTF-8

  The UTF-8 constraint restricts password values to octet strings which
  form valid UTF-8 [RFC3629] encodings of Unicode [Unicode] code points.
  The syntax of the parameter is NULL.

  This constraint is identified by the OID IANA-ASSIGNED.4.1.


  4.1. SASLprep

  The SASLprep constraint restricts password values to UTF-8 [RFC3629]
  encoded Unicode [Unicode] character strings prepared by the SASLprep
  [RFC4013] algorithm, treating the value as a "stored" string
  ([RFC3454], Section 7).

  This constraint is identified by the OID IANA-ASSIGNED.4.2.


4.2. Minimum Length

  The Minimum Length constraint restricts the length of allowed
  passwords, requiring all passwords to have at least the number of
  octets specified in the parameter.  The syntax of the parameter is:



Zeilenga                    Passwords in LDAP                  [Page 10]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


       MinLenValue ::= INTEGER (SIZE(1..MAX))

  This constraint is identified by the OID IANA-ASSIGNED.4.2.

4.X Additional Constraints

  TBD

5.  Application of Password Policy

  Password policy applies in a number of different circumstances:
     1) Bind operations utilizing password-based authentication
     mechanisms,

     2) Password update operations, and

     3) Other operations.

5.1. Password-based Bind Operations


5.2. Password update operations

5.3. Other operations


6.  Security Considerations

  Security issues are discussed throughout this document.

  This document expand upon many of the password-related security
  considerations discussed in documents comprising the LDAP Technical
  Specification [RFC4510], in particular [RFC4511], [RFC4512],
  [RFC4513], and [RFC4519].  Readers are encouraged to familiarize
  themselves with the security considerations detailed these documents,
  as well as all documents referenced by this specification.


7.  IANA Considerations

  TBD


8.  Acknowledgments

  This document is based in part upon prior work in the area done by Jim
  Sermersheim, Ludovic Poitou, Prasanta Behera, and Valerie Chu.




Zeilenga                    Passwords in LDAP                  [Page 11]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


9.  Author's Address

  Kurt D. Zeilenga
  Isode Limited

  Email: Kurt.Zeilenga@Isode.COM


10. References

  [[Note to the RFC Editor: please replace the citation tags used in
  referencing Internet-Drafts with tags of the form RFCnnnn where
  possible.]]


10.1. Normative References

  [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14 (also RFC 2119), March 1997.

  [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 3629 (also STD 63), November 2003.

  [RFC3641]     Legg, S., "Generic String Encoding Rules for ASN.1
                Types", RFC 3641, October 2003.

  [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
                Names and Passwords", RFC 4013, February 2005.

  [RFC4510]     Zeilenga, K. (editor), "LDAP: Technical Specification
                Road Map", RFC 4510, June 2006.

  [RFC4511]     Sermersheim, J. (editor), "LDAP: The Protocol", RFC
                4511, June 2006.

  [RFC4512]     Zeilenga, K. (editor), "LDAP: Directory Information
                Models", RFC 4512, June 2006.

  [RFC4513]     Harrison, R. (editor), "LDAP: Authentication Methods and
                Security Mechanisms", RFC 4513, June 2006.

  [RFC4519]     Sciberras, A. (editor), "LDAP: Schema for User
                Applications", RFC 4519, June 2006.

  [X.500]       International Telecommunication Union -
                Telecommunication Standardization Sector, "The Directory
                -- Overview of concepts, models and services,"
                X.500(1993) (also ISO/IEC 9594-1:1994).



Zeilenga                    Passwords in LDAP                  [Page 12]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  [X.511]       International Telecommunication Union -
                Telecommunication Standardization Sector, "The
                Directory: Abstract Service Definition", X.511(1993)
                (also ISO/IEC 9594-3:1993).

  [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
                3.2.0" is defined by "The Unicode Standard, Version 3.0"
                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
                as amended by the "Unicode Standard Annex #27: Unicode
                3.1" (http://www.unicode.org/reports/tr27/) and by the
                "Unicode Standard Annex #28: Unicode 3.2"
                (http://www.unicode.org/reports/tr28/).


10.2. Informative References

  [RFC3062]     Zeilenga, K., "LDAP Password Modify Extended Operation",
                RFC 3062, February 2001.

  [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ('stringprep')", RFC 3454,
                December 2002.

  [RFC4422]     Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple
                Authentication and Security Layer (SASL)", RFC 4422,
                June 2006.

  [RFC4616]     Zeilenga, K., "The PLAIN Simple Authentication and
                Security Layer (SASL) Mechanism", RFC 4616, August 2006.


                [BEHERA]   Sermersheim, J., and L. Poitou, "Password
                Policy for LDAP Directories", draft-behera-ldap-
                password-policy-xx.txt (expired "work in progress").


Appendix A.

  This appendix is non-normative.

  This document offers an alternative to the Password Policy proposal
  detailed in [BEHERA].  This appendix discusses how the approaches
  differ.

  [BEHERA] included an "intruder detection check" (also referred to as a
  "guessing limit").  This feature intended to deter or slow online
  dictionary attacks.  The feature caused authentication against the
  user's password to be blocked after too many failed after too many



Zeilenga                    Passwords in LDAP                  [Page 13]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  failed password authentication attempts.  However, the feature doesn't
  necessarily hinder online dictionary attacks, especially those
  attacking passwords of multiple users simultaneously,  and can easily
  be used to mount denial of service attacks.  This document does not
  offer any specific facility intended to hinder online dictionary
  attacks, or to detect intruders.  While implementations can employs
  facilities of their own making, caution should be taken to prevent
  these facilities from being used to mount denial of service attacks.

  [BEHERA] also included a feature that allowed administrators to lock a
  user's password and thereby preventing the user from authenticating to
  the directory with that password.  Due possibly to how [BEHERA]
  describes the feature, the feature has been perceived as a general
  account lock mechanism.  The design of this feature in [BEHERA] is
  flawed in that overloads the attribute used for indicate intruder
  lockout with an incompatible usage (directoryOperation versus
  dsaOperation).  This document does not provide a mechanism for the
  administrator to lock a password, or to lock an account.  The latter
  is more appropriately standardized in a manner not tied to the
  particular form of credentials.

  [BEHERA] provided a feature allowing users to authenticate an limited
  number of times with an expired password in order to set a new
  password known.  While these grace authentications were intended to be
  used soon after the expiration of the password, [BEHERA] provided no
  time constraint on their use.  This is problematic where the user no
  longer regularly uses password authentication as it allows access to
  the directory via a password long after that password has expired,
  such as in the case where the user authenticates to the directory
  using mechanism not based upon password (e.g., Kerberos).  This
  document provides a time-constrained grace authentication mechanism.

  [BEHERA] included a feature that allowed administrators to disallow
  user password changes, intended to be used in absence of a suitable
  access control mechanism.   While there may be DSAs which do not
  provide a suitable access control mechanism, this inadequacy seems
  more appropriately addressed through access control enhancements.  To
  reduce complexity in DSAs which do provide suitable access control
  mechanisms, this document does not include a user change control
  feature.

  [BEHERA] included a protocol extension to request and provide password
  policy related information.  The extension is used both for providing
  information about the password acted upon by an operation, and
  information about password policy impacting an operation.  The
  extension has significant limited on when information can be provided.
  For instance, a time before expiration warning can only be provided in
  an authentication response.  However, it would be useful to provide



Zeilenga                    Passwords in LDAP                  [Page 14]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  the warning in password update response, as well as any other response
  as might be useful in communicating a new warning (such as after a
  change in the maximum password age constraint).  This document
  provides protocol extensions to request and provide password policy
  related information designed to allow flexible return of password
  policy information, and to be extensible.

  [BEHERA] password policy was applied not only to authentication of
  directory user to the directory service (e.g., Bind operation), but
  also to application user to directory applications (e.g., Compare
  operation).

  [BEHERA] did not include a feature to require DSA-generated passwords.
  As humans are generally regarded as poor password generators, this
  document offers a feature to require DSA-generated passwords.  This
  feature is intended to be used in conjunction with LDAP Password
  Modify [RFC3062] operations requesting DSA-generation of passwords.

  [BEHERA] included a feature, as part of password quality check
  feature, to enforce a minimum password length.  This document offers
  features to enforce both minimum length and maximum length.  These
  length checks are offered independently of the quality check feature
  as the reasons for enforcing length restrictions may be independent of
  the reasons for enforcing a quality check.  For instance, the
  directory service may have to support DUAs unable to handle password
  greater than a particular length, necessitating the need for a maximum
  password length.  Of course, DUAs should be designed to handle long
  passwords.

  [BEHERA] includes a password history feature. When enabled, previously
  used passwords are stored in an attribute.  The user is prevented from
  changing their password to any value in the history, as well as
  reusing the current password.  To ensure the attribute doesn't grown
  to an excessive size, the administrator is required to specify the
  maximum size for this attribute.  When addition of an old password
  would cause the maximum size to be exceeded, the oldest password in
  the history is removed.  As a user desiring to reuse a password in the
  history might repeated change their password until the desired
  password is removed from the history, and hence allowing its reuse,
  [BEHERA] provides a "minimum age" constraint which prevents uses from
  passwords which are too young.  However, this constraint disallows
  well-intended changes when the password is too young.  For instance,
  when a user believes their password has been comprised, the user could
  be precluded from immediately changing their password due to this
  constraint.  The constraint is also problematic when the administrator
  resets the password as it disallows a user (who may be required to
  change the password on reset) from immediately resetting the password.




Zeilenga                    Passwords in LDAP                  [Page 15]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  This document includes a password history feature designed to prevent
  users from reusing any directory password they have used within a
  policy-defined period.

  Unlike [BEHERA], this document does not specify an attribute to hold
  the password history.  As with storage of the user's current password,
  storage of password history, is a local matter.



Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at
  ietf-ipr@ietf.org.



Full Copyright

  Copyright (C) The IETF Trust (2008).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
  THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS



Zeilenga                    Passwords in LDAP                  [Page 16]


INTERNET-DRAFT      draft-zeilenga-ldap-passwords-00       31 March 2008


  OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















































Zeilenga                    Passwords in LDAP                  [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/