From 9b66997e37818f6fe1943369cdde8b0ce4822d86 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Thu, 15 Apr 2004 01:35:13 +0000 Subject: [PATCH] relevant I-Ds --- .../draft-behera-ldap-password-policy-xx.txt | 1961 +++++++++++++++++ .../draft-sermersheim-ldap-chaining-xx.txt | 406 ++++ .../draft-zeilenga-ldap-readentry-xx.txt | 451 ++++ doc/drafts/draft-zeilenga-ldap-turn-xx.txt | 339 +++ 4 files changed, 3157 insertions(+) create mode 100644 doc/drafts/draft-behera-ldap-password-policy-xx.txt create mode 100644 doc/drafts/draft-sermersheim-ldap-chaining-xx.txt create mode 100644 doc/drafts/draft-zeilenga-ldap-readentry-xx.txt create mode 100644 doc/drafts/draft-zeilenga-ldap-turn-xx.txt diff --git a/doc/drafts/draft-behera-ldap-password-policy-xx.txt b/doc/drafts/draft-behera-ldap-password-policy-xx.txt new file mode 100644 index 0000000000..8e68484a13 --- /dev/null +++ b/doc/drafts/draft-behera-ldap-password-policy-xx.txt @@ -0,0 +1,1961 @@ + + +Internet-Draft P. Behera +draft behera-ldap-password-policy-07.txt L. Poitou +Intended Category: Proposed Standard Sun Microsystems +Expires: August 2004 J. Sermersheim + Novell + + February 2004 + + + Password Policy for LDAP Directories + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + 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. + + Technical discussions of this draft are held on the LDAPEXT Working + Group mailing list at ietf-ldapext@netscape.com. Editorial comments + may be sent to the authors listed in Section 13. + + Copyright (C) The Internet Society (2004). All rights Reserved. + + Please see the Copyright Section near the end of this document for + more information. + + + +Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document + are to be interpreted as described in RFC 2119 [RFC-2119]. + + + +Behera, et. al. Expires August 15, 2004 Page 1 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + +1. Abstract + + Password policy as described in this document is a set of rules that + controls how passwords are used and administered in LDAP + 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 users are locked out + after a certain number of failed attempts. + + + +2. 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: + + - Whether and when passwords expire. + - Whether failed bind attempts cause the account to be locked. + - 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. + +2.1. 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 [RFC-2251] or the + case of password based SASL [RFC-2222] authentication such as CRAM- + MD5 [RFC-2195] and DIGEST-MD5 [RFC-Digest]. + + + + +Behera, et. al. Expires August 15, 2004 Page 2 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + 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. + + The term "directory administrator" refers to a user that has + sufficient access control privileges to modify users' passwords, and + the pwdPolicy object defined in this document. The access control + that is used to determine whether an identity is a directory + administrator is beyond the scope of this document, but typically + implies that the administrator has 'write' privileges to the + password attribute. + +3. 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 Sections 6 and 7. + +3.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. + +3.1.1. Password Guessing limit + + In order to prevent intruders from guessing a user's password, a + mechanism exists to track the number of failed authentication + attempts, and take action when a limit is reached. + + This policy consists of five parts: + + - A configurable limit on failed authentication attempts. + + - A counter to track the number of failed authentication attempts. + + - A timeframe in which the limit of consecutive failed + authentication attempts must happen before action is taken. + + + + +Behera, et. al. Expires August 15, 2004 Page 3 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + - The action to be taken when the limit is reached. The action will + either be nothing, or the account will be locked. + + - An amount of time the account is locked (if it is to be locked). + This can be indefinite. + +3.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 + userPassword attribute during an add or modify operation, but MAY be + done by other means such as an extended operation. + + +3.2.1. Password Expiration, Expiration Warning, and Grace binds + + 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. + + Directory 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: + + - The user is sent a warning 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. + + - 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' binds, her account will be locked. + +3.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). + + + + +Behera, et. al. Expires August 15, 2004 Page 4 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + In order to do this; a history of used passwords is kept. The + directory 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. + +3.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. + +3.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 criteria 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: + + - Disallowing trivial or well-known words make up the password. + + - Forcing a certain number of digits be used. + + - Disallowing anagrams of the user's name. + + The implementation of this policy meets with the following problems: + + - 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. + + - There are no specific definitions of what 'quality checking' + means. This can lead to unexpected behavior in a heterogeneous + environment. + +3.2.5. User Defined Passwords + + + + +Behera, et. al. Expires August 15, 2004 Page 5 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + In some cases, it is desirable to disallow users from adding and + updating their own passwords. This policy makes this functionality + possible. + + This implies that certain other policy, such as password expiration + is not enforced. + +3.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 the directory + administrator. + + This is needed in scenarios where a directory administrator has set + or reset the password to a well-known value. + +3.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. + +3.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, + contains one and only one password value. + + +4. 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. + +4.1. The pwdPolicy Object Class + + This object class contains the attributes defining a password policy + in effect for a set of users. Section 8 describes the administration + + +Behera, et. al. Expires August 15, 2004 Page 6 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + 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 $ pwdExpireWarning $ pwdGraceLoginLimit $ pwdLockout + $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ + pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) + +4.2. Attribute Types used in the pwdPolicy ObjectClass + + Following are the attribute types used by the pwdPolicy object + class. + +4.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 ) + +4.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. + + ( 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 ) + +4.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. + + +Behera, et. al. Expires August 15, 2004 Page 7 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + ( 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 ) + +4.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 ) + +4.2.5. pwdCheckQuality + + This attribute indicates how the password quality will be verified + 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 ) + +4.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'). + + + +Behera, et. al. Expires August 15, 2004 Page 8 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + ( 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 ) + +4.2.7. 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 sent. 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 ) + +4.2.8. pwdGraceLoginLimit + + 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 'pwdGraceLoginLimit' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + +4.2.9. 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 + 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 ) + + + +Behera, et. al. Expires August 15, 2004 Page 9 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + +4.2.10. 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 an 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 ) + +4.2.11. 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 ) + +4.2.12. 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. + + ( 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 ) + +4.2.13. 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 the 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 administrator sets or + resets the password. + + +Behera, et. al. Expires August 15, 2004 Page 10 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + ( 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 ) + +4.2.14. 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. + + ( 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 ) + +4.2.15. pwdSafeModify + + This attribute specifies whether or not the existing password must + be sent when changing a password. 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 ) + +4.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, pwdExpirationWarned, + pwdFailureTime, pwdHistory, pwdGraceUseTime, pwdReset, + pwdPolicySubEntry. + +4.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 is applies to. + The password policy option is defined as the following: + pwd- + + + +Behera, et. al. Expires August 15, 2004 Page 11 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + 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. + + +4.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' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SINGLE-VALUE + USAGE directoryOperation) + +4.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 0 value means that the account has been locked + permanently, and that only an administrator can unlock the account. + + ( 1.3.6.1.4.1.42.2.27.8.1.17 + NAME 'pwdAccountLockedTime' + DESC 'The time an user account was locked' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SINGLE-VALUE + USAGE directoryOperation) + +4.3.4. pwdExpirationWarned + + + + +Behera, et. al. Expires August 15, 2004 Page 12 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + This attribute contains the time when the password expiration + warning was first sent to the client. The password will expire in + the pwdExpireWarning time. + + ( 1.3.6.1.4.1.42.2.27.8.1.18 + NAME 'pwdExpirationWarned' + DESC 'The time the user was first warned about the coming + expiration of the password' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SINGLE-VALUE + USAGE directoryOperation ) + +4.3.5. 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' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + USAGE directoryOperation ) + + +4.3.6. 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 = + + syntaxOID = numericoid ; the string representation of the + ; dotted-decimal OID that defines the + ; syntax used to store the password. + ; numericoid is described in 4.1 of + ; [RFC2252]. + + length = numericstring ; the number of octets in data. + ; numericstring is described in 4.1 of + + +Behera, et. al. Expires August 15, 2004 Page 13 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + ; [RFC2252]. + + data = . + + This format allows the server to store, and transmit a history of + 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' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + EQUALITY octetStringMatch + USAGE directoryOperation) + +4.3.7. pwdGraceUseTime + + This attribute holds the timestamps of grace login once a password + has expired. + + ( 1.3.6.1.4.1.42.2.27.8.1.21 + NAME 'pwdGraceUseTime' + DESC 'The timestamps of the grace login once the password has + expired' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + EQUALITY generalizedTimeMatch + + USAGE directoryOperation) + +4.3.8. pwdReset + + This attribute holds a flag to indicate (when TRUE) that the + password has been reset and therefore must be changed by the user on + first authentication. + + ( 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) + +4.3.9. pwdPolicySubentry + + This attribute points to the pwdPolicy subentry in effect for this + object. + + +Behera, et. al. Expires August 15, 2004 Page 14 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + ( 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 + USAGE directoryOperation) + +5. 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. + +5.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 + MUST be FALSE. There is no controlValue. + + passwordPolicyRequest + + controlType: 1.3.6.1.4.1.42.2.27.8.5.1 + criticality: FALSE + controlValue: None + +5.2. Response Control + + If the client has sent a passwordPolicyRequest control, the server + 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). + + passwordPolicyResponse + + controlType: 1.3.6.1.4.1.42.2.27.8.5.1 + criticality: FALSE + controlValue: an OCTET STRING, whose value is the BER encoding of the + following type: + + +Behera, et. al. Expires August 15, 2004 Page 15 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + PasswordPolicyResponseValue ::= SEQUENCE { + warning [0] CHOICE { + timeBeforeExpiration [0] INTEGER (0 .. maxInt), + graceLoginsRemaining [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 + before a password will expire. The graceLoginsRemaining 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 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. + + +6. Server Implementation by LDAP 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. + + 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. + + The scenarios in the following operations assume that the client has + attached a passwordPolicyRequest control to the request message of + + +Behera, et. al. Expires August 15, 2004 Page 16 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + the operation. In the event that the passwordPolicyRequest control + was not sent, no passwordPolicyRequest control is returned. All + other instructions remain the same. + + +6.1. Bind Operation + + When processing a bind request, the server MUST perform the + following steps: + + 1. Check for a locked account: + + If the value of the pwdAccountLockedTime attribute is 0, or if + the current time is less than the value of the + pwdAccountLockedTime attribute added to the value of the + pwdLockoutDuration, the account is locked. + + If the account is locked, the server MUST send a bindResponse to + the client with the resultCode: unwillingToPerform (53), and MUST + include the passwordPolicyResponse in the controls field of the + bindResponse message with the error: accountLocked (1). + + If the account is not locked, the server MUST proceed with the + bind operation. + + 2. Check the result of the bind operation: + + If the bind operation succeeds with authentication, the server + MUST do the following: + + A. Delete the pwdFailureTime attribute. + + B. Check whether the password must be changed now. + + If the pwdMustChange attribute is set to TRUE, and if the + pwdReset attribute is set to TRUE, the password must be + changed now. + + If the password must be changed now, the server MUST send a + bindResponse to the client with the resultCode: success (0), + and MUST include the passwordPolicyResponse in the controls + field of the bindResponse message with the warning: + changeAfterReset specified. + The server MUST then disallow all operations issued by this + user except modify password, bind, unbind, abandon and + StartTLS extended operation. + + If the password does not need to be changed now, the operation + proceeds. + + +Behera, et. al. Expires August 15, 2004 Page 17 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + C. Check for password expiration + + The password has expired when either of the following + conditions is met: + + - If the value of the pwdExpireWarning attribute is 0, the + server subtracts the current time from the time stored in + pwdChangedTime to arrive at the password's age. If the age + is greater than the value in the pwdMaxAge attribute, the + password has expired. + + - If the value of the pwdExpireWarning attribute is non- + zero, and the pwdExpirationWarned attribute is present and + has a time value, the server subtracts the current time + from the time stored in the pwdExpirationWarned to arrive + at the first warning age. If the age is greater than the + value in the pwdExpireWarning attribute, the password has + expired. + + If the password has expired, the server MUST check for + remaining grace logins. + + If the pwdGraceUseTime attribute is present, the server + MUST count the number of values in that attribute and + subtract it from the pwdGraceLoginLimit. A positive result + specifies the number of remaining grace logins. + + If there are remaining grace logins, the server MUST add a + new value with the current time in pwdGraceUseTime. Then + it MUST send a bindResponse with the resultCode: success + (0), and MUST include the passwordPolicyResponse in the + controls field of the bindResponse message with the + warning: graceLoginsRemaining choice set to the number of + grace logins left. + + If there are no remaining grace logins, the server MUST + send a bindResponse with the resultCode: + invalidCredentials (49), and MUST include the + passwordPolicyResponse in the controls field of the + bindResponse message with the error: passwordExpired (0) + set. + + If the password has not expired, execution continues. + + D. Calculates whether the time before expiration warning should + be sent. + + + + +Behera, et. al. Expires August 15, 2004 Page 18 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + If the pwdExpireWarning attribute is present and contains a + value, the server MUST perform the following steps. + + If the pwdExpirationWarned attribute is present and has a + time value, the warning time is the value of the + pwdExpirationWarned attribute plus the value of the + pwdExpireWarning attribute minus the current time. + + If the pwdExpirationWarned attribute is not present, the + server MUST subtract the current time from the time stored + in pwdChangedTime to arrive at the password's age. If the + age is greater than the value of the pwdMaxAge attribute + minus the value of the pwdExpireWarning attribute, the + server MUST set the current time as the value of the + pwdExpirationWarned attribute, and the warning time is the + value of pwdMaxAge minus the password's age. + + If the warning time is a positive number, the server MUST + send a bindResponse with the resultCode: success (0), and + MUST include the passwordPolicyResponse in the controls + field of the bindResponse message with the warning: + timeBeforeExiration set to the value as described above. + + If the warning time is zero, or wasn't calculated, the + server MUST send a bindResponse with the resultCode: + success (0), and MUST include the passwordPolicyResponse + with nothing in the SEQUENCE. + + If the pwdExpireWarning attribute is not present, the server + MUST send a bindResponse with the resultCode: success (0), + and MUST include the passwordPolicyResponse with nothing in + the SEQUENCE. + + If the bind operation fails authentication due to invalid + credentials, the server MUST do the following: + + A. Add the current time as a value of the pwdFailureTime + attribute. + + B. If the pwdLockout attribute is TRUE, the server MUST also do + the following: + + Count the number of values in the pwdFailureTime attribute + that are younger than pwdFailureCountInterval. + + If the number of these failures is greater or equal to the + pwdMaxFailure attribute, the server MUST lock the account + by setting the value of the pwdAccountLockedTime attribute + to the current time. After locking the account, the server + + +Behera, et. al. Expires August 15, 2004 Page 19 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + MUST send a bindResponse to the client with the + resultCode: unwillingToPerform (53), and MUST include the + passwordPolicyResponse in the controls field of the + bindResponse message with the error: accountLocked (1). + + If the number of failures is less than the pwdMaxFailure + attribute, operation proceeds. + + C. Failure times that are old by more than + pwdFailureCountInterval are purged from the pwdFailureTime + attribute. + + + +6.2. Modify Password Operation + + Because the password is stored in an attribute, the modify operation + 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 [RFC-3062]. + + + + + While processing a password modification, the server MUST perform + the following steps: + + 1. Check the pwdSafeModify attribute. If set to TRUE, the server + MUST ensure that the modify password operation included 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 is + first, and specifies the existing password, and the add or + replace action specifies the new password. Other password modify + operations SHOULD employ a similar mechanism. Otherwise this + policy will fail. + + If the existing password is not specified, the server MUST NOT + process the operation and MUST send the appropriate response + message to the client with the resultCode: unwillingToPerform + (53), and MUST include the passwordPolicyResponse in the controls + field of the response message with the error: + mustSupplyOldPassword (4). + + + 2. Check the value of the pwdMustChange attribute. If TRUE, the + server MUST check the pwdReset attribute in the user's entry, to + see if a directory administrator has reset the password. If so, + it MUST ensure that the modify password operation contains no + + +Behera, et. al. Expires August 15, 2004 Page 20 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + modifications other than the modification of the password + attribute. If other modifications exist, the server MUST send a + response message to the client with the resultCode: + unwillingToPerform (53), and MUST include the + passwordPolicyResponse in the controls field of the response + message with the error: changeAfterReset (2). + + 3. Check to see whether the bound identity has sufficient rights to + modify 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 + change her password, the server MUST send a response message to + the client with the resultCode: unwillingToPerform (53), and MUST + include the passwordPolicyResponse in the controls field of the + response message with the error: passwordModNotAllowed (3). + + 4. Check the value of the pwdMinAge attribute. If it is set to a + non-zero value, the server MUST subtract the current time from + the value of the pwdChangedTime attribute to arrive at the + password's age. If the password's age is less than the value of + the pwdMinAge attribute, the password is too young to modify. In + this case, the server MUST send a response message to the client + with the resultCode: constraintViolation (19), and MUST include + the passwordPolicyResponse in the controls field of the response + message with the error: passwordTooYoung (7). + + 5. Check the value of the pwdCheckQuality attribute. + + If the value is non-zero, The server: + + A. MUST 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 MUST continue. If the + value is 2, the server MUST send a response message to the + client with the resultCode: constraintViolation (19), and MUST + include 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 MUST send a response message to the + client with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + + + +Behera, et. al. Expires August 15, 2004 Page 21 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + the response message with the error: + insufficientPasswordQuality (5). + + B. MUST check the value of the pwdMinLength attribute. If the + value is non-zero, it MUST ensure 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 MUST continue. If the + value is 2, the server MUST send a response message to the + client with the resultCode: constraintViolation (19), and MUST + include 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 MUST send a response message to the + client with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + the response message with the error: passwordTooShort (6). + + 6. Check the value of the pwdInHistory attribute. If the value is + non-zero, the server MUST check 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 MUST send a + response message to the client with the resultCode: + constraintViolation (19), and MUST include the + passwordPolicyResponse in the controls field of the response + message with the error: passwordInHistory (8). + + If the steps have completed without causing an error condition, the + server MUST follow the following steps in order to update the + necessary password policy state attributes: + + 7. Check the value of the pwdMaxAge attribute. If the value is non- + zero, or if the value of the pwdMinAge attribute is non-zero, the + server MUST update the pwdChangedTime attribute on the entry to + the current time. + + 8. If the value of the pwdInHistory attribute is non-zero, the + server MUST add the previous password to the pwdHistory + attribute. If the number of attributes held in the pwdHistory + attribute exceeds the value of pwdInHistory, the server MUST + remove the oldest excess passwords. + + 9. Remove the pwdFailureTime, pwdReset, pwdGraceUseTime and + pwdExpirationWarned attributes from the user's entry if they + + + +Behera, et. al. Expires August 15, 2004 Page 22 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + exist. + + The server MUST then apply the modify password operation. + +6.3. Add Operation + + The password MAY be set during an Add operation. If it is, the + server MUST perform the following steps while processing the add + operation. Note that these are essentially duplicates of steps 3, 5 + and 7 from Section 6.2 with the exception that pwdAllowUserChange is + not checked. + + 1. Check to see whether the bound identity has sufficient rights to + modify the password. This MAY be done by the use of an access + control mechanism. If the user is not allowed to add this + password, the server MUST send an addResponse to the client with + the resultCode: unwillingToPerform (53), and MUST include the + passwordPolicyResponse in the controls field of the addResponse + message with the error: passwordModNotAllowed (3). + + 2. Check the value of the pwdCheckQuality attribute. + + If the value is non-zero, The server: + + A. MUST 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 MUST be + evaluated. If the value is 1, operation MUST continue. If the + value is 2, the server MUST send an addResponse to the client + with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + the addResponse message with the error: + insufficientPasswordQuality (5). + + If the server is able to check the password quality, and the + check fails, the server MUST send an addResponse to the client + with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + the addResponse message with the error: + insufficientPasswordQuality (5). + + B. MUST check the value of the pwdMinLength attribute. If the + value is non-zero, it MUST ensure that the new password is of + at least the minimum length. + + + + +Behera, et. al. Expires August 15, 2004 Page 23 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + If the server is unable to check the length (due to a hashed + password or otherwise), the value of pwdCheckQuality MUST be + evaluated. If the value is 1, operation MUST continue. If the + value is 2, the server MUST send an addResponse to the client + with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + the addResponse message with the error: passwordTooShort (6). + + If the server is able to check the password length, and the + check fails, the server MUST send an addResponse to the client + with the resultCode: constraintViolation (19), and MUST + include the passwordPolicyResponse in the controls field of + the addResponse message with the error: passwordTooShort (6). + + If the steps above have completed without causing an error + condition, the server MUST follow the steps below in order to update + the necessary password policy state attributes. + + 3. Check the value of the pwdMaxAge attribute. If the value is non- + zero, or if the value of the pwdMinAge attribute is non-zero, the + server MUST update the pwdChangedTime attribute on the entry to + the current time. + +6.4. Compare Operation + + The compare operation MAY be used to compare a password. This might + be performed when a client wishes to verify that user's supplied + password is correct. An example of this is an LDAP HTTP + authentication redirector. It may be desirable to use this rather + than performing a bind operation in order to reduce possible + overhead involved in performing a bind. Access Controls SHOULD be + used to restrict this comparison from being made. + + If a server supports this behavior, it MUST comply with the + following. Otherwise the password policy described in this document + may be circumvented. + + While comparing password attributes, the server MUST perform the + following steps: + + 1. Check for a locked account: + + If the value of the pwdAccountLockedTime attribute is 0, or if + the current time is less than the value of the + pwdAccountLockedTime attribute added to the value of the + pwdLockoutDuration, the account is locked. + + If the account is locked, the server MUST send a compareResponse + to the client with the resultCode: compareFalse (5), and MUST + + +Behera, et. al. Expires August 15, 2004 Page 24 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + include the passwordPolicyResponse in the controls field of the + compareResponse message with the error: accountLocked (1). + + If the account is not locked, the server MUST proceed with the + compare operation. + + 2. If Access Controls permit, the server MUST proceed with compare + operation and MUST check the result. + + If the result of the compare operation is true, the server MUST + do the following: + + A. Delete the pwdFailureTime attribute. + + B. Check for password expiration + + The password has expired when either of the following + conditions is met: + + - If the value of the pwdExpireWarning attribute is 0, the + server MUST subtract the current time from the time stored + in pwdChangedTime to arrive at the password's age. If the + age is greater than the value in the pwdMaxAge attribute, + the password has expired. + + - If the value of the pwdExpireWarning attribute is non- + zero, and the pwdExpirationWarned attribute is present and + has a time value, the server MUST subtract the current + time from the time stored in the pwdExpirationWarned to + arrive at the first warning age. If the age is greater + than the value in the pwdExpireWarning attribute, the + password has expired. + + If the password has expired, the server MUST check for + remaining grace logins. + + If the pwdGraceUseTime attribute is present, the server + MUST count the number of values in that attribute and MUST + subtract it from the pwdGraceLoginLimit. A positive result + specifies the number of remaining grace logins. + + If there are remaining grace logins, the server MUST add a + new value with the current time in pwdGraceUseTime. Then + it MUST send a compareResponse with the resultCode: + compareTrue (6), and MUST include the + passwordPolicyResponse in the controls field of the + compareResponse message with the warning: + graceLoginsRemaining choice set to the number of grace + logins left. + + +Behera, et. al. Expires August 15, 2004 Page 25 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + If there are no remaining grace logins, the server MUST + send a compareResponse with the resultCode: compareFalse + (5), and MUST include the passwordPolicyResponse in the + controls field of the compareResponse message with the + error: passwordExpired (0) set. + + If the password has not expired, execution MUST continue. + + C. Calculate whether the time before expiration warning should be + sent. + + If the pwdExpireWarning attribute is present and contains a + value, the server MUST perform the following steps. + + If the pwdExpirationWarned attribute is present and has a + time value, the warning time is the value of the + pwdExpirationWarned attribute plus the value of the + pwdExpireWarning attribute minus the current time. + + If the pwdExpirationWarned attribute is not present, the + server MUST subtract the current time from the time stored + in pwdChangedTime to arrive at the password's age. If the + age is greater than the value of the pwdMaxAge attribute + minus the value of the pwdExpireWarning attribute, the + server MUST set the current time as the value of the + pwdExpirationWarned attribute, and the warning time is the + value of pwdMaxAge minus the password's age. + + If the warning time is a positive number, the server MUST + send a compareResponse with the resultCode: compareTrue + (6), and MUST include the passwordPolicyResponse in the + controls field of the compareResponse message with the + warning: timeBeforeExiration set to the value as described + above. + + If the warning time is zero, or wasn't calculated, the + server MUST send a compareResponse with the resultCode: + compareTrue (6), and MUST include the + passwordPolicyResponse with nothing in the SEQUENCE. + + If the pwdExpireWarning attribute is not present, the server + MUST send a compareResponse with the resultCode: compareTrue + (6), and MUST include the passwordPolicyResponse with nothing + in the SEQUENCE. + + If the result of the compare operation is false, the server MUST + do the following: + + + +Behera, et. al. Expires August 15, 2004 Page 26 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + A. Add the current time as a value of the pwdFailureTime + attribute. + + B. If the pwdLockout attribute is TRUE, the server MUST do + the following: + + Count the number of values in the pwdFailureTime + attribute that are younger than + pwdFailureCountInterval. + + If the number of these failures is greater or equal to + the pwdMaxFailure attribute, the server MUST lock the + account by setting the value of the + pwdAccountLockedTime attribute to the current time. + After locking the account, the server MUST send a + compareResponse to the client with the resultCode: + compareFalse (5), and MUST include the + passwordPolicyResponse in the controls field of the + compareResponse message with the error: accountLocked + (1). + + If the number of failures is less than the + pwdMaxFailure attribute, operation MUST proceed. + + If the pwdLockout attribute is FALSE, operation MUST + continue. + + C. Failure times that are old by more than + pwdFailureCountInterval, MUST be purged from the + pwdFailureTime attribute. + + D. If no errors were returned, the server MUST send a + compareResponse with the resultCode: compareTrue (6), and + MUST include the passwordPolicyResponse with nothing in + the SEQUENCE. + +7. Client Implementation by LDAP operation + + 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 passwordPolicyRequest control is returned. + All other instructions remain the same. + +7.1. Bind Operation + + +Behera, et. al. Expires August 15, 2004 Page 27 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + For every bind response received, the client MUST check the + resultCode of the bindResponse and MUST check for a + passwordPolicyResponse to determine if any of the following + conditions are true and MAY prompt the user accordingly. + + 1. The password failure limit has been reached and the account is + locked. The user needs to retry later or contact the directory + administrator to reset the password. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: accountLocked (1) + + 2. The user is binding for the first time after the directory + administrator set the password. In this scenario, the client + SHOULD prompt the user to change his password immediately. + + resultCode: success (0) + passwordPolicyResponse: error: changeAfterReset (2) + + 3. The password has expired but there are remaining grace logins. + The user needs to change it. + + resultCode: success (0) + passwordPolicyResponse: warning: graceLoginsRemaining + + 4. The password has expired and there are no more grace logins. The + user MUST contact the directory administrator in order to have + its password reset. + + resultCode: invalidCredentials (49) + passwordPolicyResponse: error: passwordExpired (0) + + 5. The user's password will expire in n number of seconds. + + resultCode: success (0) + passwordPolicyResponse: warning: timeBeforeExpiration + +7.2. Modify Operations + +7.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. + +7.2.2. Modify Response + + +Behera, et. al. Expires August 15, 2004 Page 28 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + 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 MUST check the resultCode + of the response and MUST check for a passwordPolicyResponse to + determine if any of the following conditions are true and optionally + notify the user of the condition. + + 1. The user attempted to change her password without specifying the + old password but the password policy requires this. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: mustSupplyOldPassword (4) + + 2. The user MUST change her password before submitting any other + LDAP requests. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: changeAfterReset (2) + + 3. The user doesn't have sufficient rights to change his password. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: passwordModNotAllowed (3) + + 4. It is too soon after the last password modification to change the + password. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: passwordTooYoung (7) + + 5. The password failed quality checking. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: + insufficientPasswordQuality (5) + + 6. The length of the password is too short. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: passwordTooShort (6) + + 7. The password has already been used; the user MUST choose a + different one. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: passwordInHistory (8) + + + +Behera, et. al. Expires August 15, 2004 Page 29 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + +7.3. Add Operation + + If a password is specified in an addRequest, the client MUST check + the resultCode of the addResponse and MUST check for a + passwordPolicyResponse to determine if any of the following + conditions are true and may prompt the user accordingly. + + 1. The user doesn't have sufficient rights to add this password. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: passwordModNotAllowed (3) + + 2. The password failed quality checking. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: + insufficientPasswordQuality (5) + + 3. The length of the password is too short. + + resultCode: constraintViolation (19) + passwordPolicyResponse: error: passwordTooShort (6) + + +7.4. Compare Operation + + When a compare operation is used to compare a password, the client + MUST check the resultCode of the compareResponse and MUST check 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. + + 1. The password failure limit has been reached and the account is + locked. The user needs to retry later or contact the directory + administrator to reset the password. + + resultCode: compareFalse (5) + passwordPolicyResponse: error: accountLocked (1) + + 2. The password has expired but there are remaining grace logins. + The user needs to change it. + + resultCode: compareTrue (6) + passwordPolicyResponse: warning: graceLoginsRemaining + + 3. The password has expired and there are no more grace logins. The + user MUST contact the directory administrator to reset the + password. + + +Behera, et. al. Expires August 15, 2004 Page 30 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + + resultCode: compareFalse (5) + passwordPolicyResponse: error: passwordExpired (0) + + 4. The user's password will expire in n number of seconds. + + resultCode: compareTrue (6) + passwordPolicyResponse: warning: timeBeforeExpiration + + +7.5. Other Operations + + For operations other than bind, unbind, abandon, search or StartTLS, + the client MUST check the following result code and control to + determine if the user needs to change the password immediately. + + 1. The user needs to change password. The user SHOULD be prompted to + change the password immediately. + + resultCode: unwillingToPerform (53) + passwordPolicyResponse: error: changeAfterReset (2) + +8. Administration of a Password Policy + + + A password policy MUST be 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 + RFC 3672 [RFC-3672]. + + 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. + + 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 SHALL advertise + 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, MUST interrogate the + + + +Behera, et. al. Expires August 15, 2004 Page 31 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + pwdPolicySubentry for that object in order to arrive at the proper + pwdPolicy subentry. + +9. Password Policy and Replication + + 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, pwdExpirationWarned, pwdFailureTime and + pwdGraceUseTime attributes MUST 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 logins 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. + + +10. 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 RFC 2829 [RFC-2829]. + + + +Behera, et. al. Expires August 15, 2004 Page 32 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + 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. Especially all the attributes defined to maintain + the Password Policy state information SHOULD not be modifiable by + anyone but the Administrator of the directory server. + + 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 a password policy is put in place, 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 attacks. + + +11. 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). + + +12. Normative References + + [RFC-2119] S. Bradner, "Key Words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC-2195] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize + Extension for Simple Challenge/Response", RFC 2195, September 1997. + + [RFC-2222] J. Myers, "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [RFC-2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory + Access Protocol (v3)", RFC 2251, August 1997. + + [RFC-2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., + "Lightweight Directory Access Protocol (v3): Attribute Syntax + Definitions", RFC 2252, December 1997. + + + +Behera, et. al. Expires August 15, 2004 Page 33 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + [RFC-Digest] Paul J. Leach, Chris Newman, "Using Digest + Authentication as a SASL Mechanism", RFC 2831, May 2000. + + [RFC-3062] K. Zeilenga, "LDAP Password Modify Extended Operation", + RFC 3062, February 2001. + + [RFC-3672] K. Zeilenga, S. Legg, "Subentries in the Lightweight + Directory Access Protocol (LDAP)", RFC 3672, December. + + +13. Authors' Addresses + + Prasanta Behera + 18366 Chelmsford Dr. + Cupertino, CA 95014 + USA + prasantabehera@yahoo.com + + Ludovic Poitou + Sun Microsystems Inc. + 180, Avenue de l'Europe + Zirst de Montbonnot + 38334 Saint Ismier cedex + France + +33 476 188 212 + ludovic.poitou@sun.com + + Jim Sermersheim + Novell, Inc. + 1800 South Novell Place + Provo, Utah 84606, USA + +1 801 861-3088 + jimse@novell.com + +14. Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights + Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + + +Behera, et. al. Expires August 15, 2004 Page 34 + +INTERNET DRAFT LDAP Password Policy 15 February 2004 + + + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 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." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Behera, et. al. Expires August 15, 2004 Page 35 + + diff --git a/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt b/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt new file mode 100644 index 0000000000..a6412e3b27 --- /dev/null +++ b/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt @@ -0,0 +1,406 @@ + +Internet Draft J. Sermersheim +Personal Submission R. Harrison +Intended Category: Standard Track Novell, Inc +Document: draft-sermersheim-ldap-chaining-02.txt Feb 2004 + + + + LDAP Control to Specify Chaining Behavior + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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. + + Distribution of this memo is unlimited. Technical discussion of this + document will take place on the IETF LDAP Extensions Working Group + mailing list . Editorial comments may be sent to + the author . + + +Abstract + + This document describes a Lightweight Directory Access Protocol + (LDAP) request control that allows specification of chaining behavior + for LDAP operations. By using the control with various LDAP + operations, a directory client (DUA), or directory server (DSA) + specifies whether or not a DSA or secondary DSA chains operations to + other DSAs or returns referrals and/or search result references to + the client. + + +1. Introduction + + Many directory servers have the ability through the use of various + mechanisms to participate in a distributed directory model. A + distributed directory is one where the DIT is distributed over + multiple DSAs. One operation completion mechanism used by DSAs in a + distributed directory is chaining. Chaining is defined in [X.518], + and is the act of one DSA communicating a directory operation that + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 1 + LDAP Control to Specify Chaining Behavior + + originated from a DUA to another DSA in a distributed directory. + Contrast this with the act of passing referrals (4.1.11 of [RFC2251]) + and SearchResultReferences (4.5.2 of [RFC2251]) back to the client. + Chaining may happen during the name resolution part of an operation + or during other parts of operations like search which apply to a + number of entries in a subtree. + + This document does not attempt to define the distributed directory + model, nor does it attempt to define the manner in which DSAs chain + requests. This document defines a request control that the client can + use to specify whether parts of an operation should or should not be + chained. + + +2. Conventions + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + used in this document carry the meanings described in [RFC2119]. + + The term chaining may apply to uni-chaining as well as multi-chaining + (see [X.518]) depending on the capabilities and configuration of the + DSAs. + + +3. The Control + + Support for the control is advertised by the presence of its + controlType in the supportedControl attribute of a server's root DSE. + + This control MAY be included in any LDAP request operation except + abandon, unbind, and StartTLS as part of the controls field of the + LDAPMessage, as defined in Section 4.1.12 of [RFC2251]: + + The controlType is set to . The criticality MAY + be set to either TRUE or FALSE. The controlValue is an OCTET STRING, + whose value is the following ChainingBehavior type, BER encoded + following the rules in Section 5.1 of [RFC2251]: + + ChainingBehavior ::= SEQUENCE { + resolveBehavior Behavior OPTIONAL, + continuationBehavior Behavior OPTIONAL } + + Behavior :: = ENUMERATED { + chainingPreferred (0), + chainingRequired (1), + referralsPreferred (2), + referralsRequired (3) } + + resolveBehavior instructs the DSA what to do when a referral is + encountered during the local name resolution part of an operation. If + this field is not specified, other policy dictates the DSA's + behavior. + + + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 2 + LDAP Control to Specify Chaining Behavior + + continuationBehavior instructs the DSA what to do when a referral is + encountered after the name resolution part of an operation has + completed. This scenario occurs during search operations, and may + occur during yet to be defined future operations. If this field is + not specified, other policy dictates the DSA's behavior. + + Behavior specifies whether the DSA should chain the operation or + return referrals when a target object is held by a remote service. + + chainingPreferred indicates that the preference is that + chaining, rather than referrals, be used to provide the service. + When this value is set, the server attempts to chain the request + but if it can't it returns referrals. + + chainingRequired indicates that chaining is to be used rather + than referrals to service the request. When this value is set, + the server MUST NOT return referrals. It either chains the + request or fails. + + referralsPreferred indicates that the client wishes to receive + referrals rather than allow the server to chain the operation. + When this value is set, the server return referrals and search + references when possible, but may chain the operation otherwise. + + referralsRequired indicates that chaining is prohibited. When + this value is set, the server MUST NOT chain the request to + other DSAs. Instead it returns referrals as necessary, or fails. + + The following list assigns meanings to some of the result codes that + may occur due to this control being present: + + - chainingRequired (IANA-ASSIGNED-1) Unable to process without + chaining. + - cannotChain (IANA-ASSIGNED-2) Unable to chain the request. + + +4. Notes to Implementors + + + + +4.1 Unbind and Abandon + + Clients MUST NOT include the ChainingBehavior control with an Abandon + operation or an Unbind operation. Servers MUST ignore any chaining + control on the abandon and unbind requests. Servers that chain + operation are responsible to keep track of where an operation was + chained to for the purposes of unbind and abandon. + + +4.2 StartTLS + + This operation cannot be chained because the TLS handshake protocol + does not allow man-in-the-middle attacks. + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 3 + LDAP Control to Specify Chaining Behavior + + + +5. Relationship with other Extensions + + This control MAY be used with other controls or with extended + operations. When it is used with other controls or with extended + operations not listed here, server behavior is undefined unless + otherwise specified. + + +5.1 Relationship with ManageDsaIT + + When this control is used along with the ManageDsaIT control, the + resolveBehavior value is evaluated. If resolveBehavior is such that + chaining is allowed, the DSA is allowed to chain the operation as + necessary until the last RDN is found. + + For example: DSA1 holds the naming context and a subordinate + reference to , DSA2 holds the naming context + and a subordinate reference to + . + + A modify operation accompanied by the ManageDsaIT control alone is + sent to DSA1. The base object of the modify operation is set to + . Since DSA1 does not hold the + IT DSE, a referral is returned for + . + + Next, the same modify operation is accompanied by both the + ManageDsaIT and the ChainingBehavior control where the + ChainingBehavior.resolveBehavior is set to chainingPreferred. In this + case, DSA1 chains to DSA2 when it encounters and + DSA2 continues the operation. Since DSA2 holds the IT DSE + , the resolve portion completes, and the + rest of the operation proceeds. + + +6. Security Considerations + + Because this control directs a DSA to chain requests to other DSAs, + it may be used in a denial of service attack. Implementers should be + cognizant of this possibility. + + This control may be used to allow access to hosts and portions of the + DIT not normally available to clients. Servers supporting this + control should provide sufficient policy to prevent unwanted + occurrences of this. + + +7. IANA Considerations + + Registration of the following values is requested [RFC3383]. + + + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 4 + LDAP Control to Specify Chaining Behavior + +7.1. Object Identifiers + + It is requested that IANA register upon Standards Action an LDAP + Object Identifier in identifying the protocol elements defined in + this technical specification. The following registration template is + suggested: + + Subject: Request for LDAP OID Registration + Person & email address to contact for further information: + Jim Sermersheim + jimse@novell.com + Specification: RFCXXXX + Author/Change Controller: IESG + Comments: + One delegation will be made under the assigned OID: + + IANA-ASSIGNED-OID.1 Chaining Behavior Request Control + + +7.2. LDAP Protocol Mechanism + + It is requested that IANA register upon Standards Action the LDAP + protocol mechanism described in this document. The following + registration template is suggested: + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: IANA-ASSIGNED-OID.1 + Description: Chaining Behavior Request Control + Person & email address to contact for further information: + Jim Sermersheim + jimse@novell.com + Usage: Control + Specification: RFCXXXX + Author/Change Controller: IESG + Comments: none + + +7.3. LDAP Result Codes + + It is requested that IANA register upon Standards Action the LDAP + result codes: + + chainingRequired (IANA-ASSIGNED-1) + cannotChain (IANA-ASSIGNED-2) + + The following registration template is suggested: + + Subject: LDAP Result Code Registration + Person & email address to contact for further information: + Jim Sermersheim + jimse@novell.com + Result Code Name: chainingRequired + Result Code Name: cannotChain + Specification: RFCXXXX + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 5 + LDAP Control to Specify Chaining Behavior + + Author/Change Controller: IESG + Comments: request consecutive result codes be assigned + + +8. Normative References + + [X.518] + ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993. + + [RFC2119] + Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement + Levels", Internet Draft, March 1997. + Available as RFC2119. + + [RFC2251] + Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access + Protocol (v3)", Internet Standard, December, 1997. + Available as RFC2251. + + +9. Authors' Addresses + + Jim Sermersheim + Novell, Inc. + 1800 South Novell Place + Provo, Utah 84606, USA + jimse@novell.com + +1 801 861-3088 + + Roger Harrison + Novell, Inc. + 1800 South Novell Place + Provo, Utah 84606, USA + rharrison@novell.com + +1 801 861-2642 + + + + + + + + + + + + + + + + + + + + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 6 + LDAP Control to Specify Chaining Behavior + +Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification + can be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain + it or assist in its implementation may be prepared, copied, + published and distributed, in whole or in part, without restriction + of any kind, provided that the above copyright notice and this + paragraph are included on all such copies and derivative works. + However, this document itself may not be modified in any way, such + as by removing the copyright notice or references to the Internet + Society or other Internet organizations, except as needed for the + purpose of developing Internet standards in which case the + procedures for copyrights defined in the Internet Standards process + must be followed, or as required to translate it into languages + other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on + an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 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. + + + + + +Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 7 + diff --git a/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt b/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt new file mode 100644 index 0000000000..62fc74c8ed --- /dev/null +++ b/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt @@ -0,0 +1,451 @@ + + + + + + +INTERNET-DRAFT Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires in six months 26 October 2003 + + + LDAP Read Entry Controls + + + +1. Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + This document is intended to be, after appropriate review and + revision, submitted to the RFC Editor as a Standard Track document. + Distribution of this memo is unlimited. Technical discussion of this + document will take place on the IETF LDAP Extensions mailing list + . Please send editorial comments directly to the + author . + + 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 + . The list of + Internet-Draft Shadow Directories can be accessed at + . + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + Please see the Full Copyright section near the end of this document + for more information. + + +Abstract + + This specification describes controls which can be attached to a + Lightweight Directory Access Protocol (LDAP) update request to obtain + copies of the target entry before and/or after the requested update is + applied. + + + + + +Zeilenga LDAP Read Entry Controls [Page 1] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + +1. Background and Intent of Use + + This specification describes controls [RFC2251] which can be attached + to Lightweight Directory Access Protocol (LDAP) [RFC3377] update + requests to request and return copies of the target entry. One + request control, called the Pre-Read request control, indicates that a + copy of the entry before application of update is to be returned. + Another control, called the Post-Read request control, indicates that + a copy of the entry after application of the update is to be returned. + Each request control has a corresponding response control used to + return the entry. + + The functionality offered by these controls is based upon similar + functionality in the X.500 Directory Access Protocol (DAP) [X.511]. + + The Pre-Read controls may be used to obtain replaced or deleted values + of modified attributes or a copy of the entry being deleted. + + The Post-Read controls may be used to obtain values of operational + attributes, such as the 'entryUUID' [EntryUUID] and 'modifytimestamp' + [RFC2252] attributes, updated by the server as part of the update + operation. + + +2. Terminology + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded using + the Basic Encoding Rules [X.690] under the restrictions detailed in + Section 5.1 of [RFC2251]. + + DN stands for Distinguished Name. + DSA stands for Directory System Agent (i.e., a directory server). + DSE stands for DSA-specific Entry. + + 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 BCP 14 [RFC2119]. + + +3. Read Entry Controls + +3.1. The Pre-Read Controls + + The Pre-Read request and response controls are identified by the + IANA-ASSIGNED-OID.1 object identifier. Servers implementing these + controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the + 'supportedControl' [RFC2252] in their root DSE. + + + +Zeilenga LDAP Read Entry Controls [Page 2] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + The Pre-Read request control is an LDAP Control [RFC2251] whose + controlType is IANA-ASSIGNED-OID.1 and controlValue is a BER-encoded + AttributeDescriptionList [RFC2251]. The criticality may be TRUE or + FALSE. This control is appropriate for the modifyRequest, delRequest, + and modDNRequest LDAP messages. + + The corresponding response control is a LDAP Control whose controlType + is IANA-ASSIGNED-OID.1 and the controlValue, an OCTET STRING, contains + a BER-encoded SearchResultEntry. The criticality may be TRUE or + FALSE. This control is appropriate for the modifyResponse, + delResponse, and modDNResponse LDAP messages with a resultCode of + success (0). + + When the request control is attached to an appropriate update LDAP + request, the control requests the return of a copy of target entry + prior to the application of the update. The AttributeDescriptionList + indicates which attributes are requested to appear in the copy. There + are two special AttributeDescriptions which may be included in the + list, "*" and "+". "*" requests all user attributes. "+" requests + all operational attributes. If the list is empty, all user attributes + are requested. If the list contains an unrecognized attribute type, + that type is simply ignored. If all attribute types are unrecognized, + no attributes are to be returned. The server is to return a + SearchResultEntry containing, subject to access controls and other + constraints, values of the requested attributes. + + The normal processing of the update operation and the processing of + this control MUST be performed as one atomic action isolated from + other update operations. + + If the update operation fails, no response control is provided. + + +3.2. The Post-Read Controls + + The Post-Read request and response controls are identified by the + IANA-ASSIGNED-OID.2 object identifier. Servers implementing these + controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the + 'supportedControl' [RFC2252] in their root DSE. + + The Post-Read request control is an LDAP Control [RFC2251] whose + controlType is IANA-ASSIGNED-OID.2 and controlValue, an OCTET STRING, + contains a BER-encoded AttributeDescriptionList [RFC2251]. The + criticality may be TRUE or FALSE. This control is appropriate for the + addRequest, modifyRequest, and modDNRequest LDAP messages. + + The corresponding response control is a LDAP Control whose controlType + is IANA-ASSIGNED-OID.2 and controlValue is a BER-encoded + + + +Zeilenga LDAP Read Entry Controls [Page 3] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + SearchResultEntry. The criticality may be TRUE or FALSE. This + control is appropriate for the addResponse, modifyResponse, and + modDNResponse LDAP messages with a resultCode of success (0). + + When the request control is attached to an appropriate update LDAP + request, the control requests the return of a copy of target entry + after the application of the update. The AttributeDescriptionList + indicates which attributes are requested to appear in the copy. There + are two special AttributeDescriptions which may be included in the + list, "*" and "+". "*" requests all user attributes. "+" requests + all operational attributes. If the list is empty, all user attributes + are requested. If the list contains an unrecognized attribute type, + that type is simply ignored. If all attribute types are unrecognized, + no attributes are to be returned. The server is to return a + SearchResultEntry containing, subject to access controls and other + constraints, values of the requested attributes. + + The normal processing of the update operation and the processing of + this control MUST be performed as one atomic action isolated from + other update operations. + + If the update operation fails, no response control is provided. + + +4. Interaction with other controls + + The Pre- and Post-Read controls may be combined with each other and/or + with a variety of other controls. When combined with the assertion + control [ASSERT], the manageDsaIT control [RFC3296], and/or the proxy + authorization control [PROXYAUTH], the semantics of each control + included in the combination apply. The Pre- and Post-Read controls + may be combined with other controls as detailed in other technical + specifications. + + +5. Security Considerations + + The controls defined in this document extend update operations to + support read capabilities. Servers MUST ensure that the client is + authorized both for reading of the information provided in this + control in addition to ensuring the client is authorized to perform + the requested directory update. + + Implementors of this (or any) LDAP extension should be familiar with + general LDAP security considerations [RFC3377]. + + +6. IANA Considerations + + + +Zeilenga LDAP Read Entry Controls [Page 4] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + Registration of the following protocol values [RFC3383] is requested. + + +6.1. Object Identifier + + It is requested that IANA register an LDAP Object Identifier to + identify LDAP protocol elements defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga + Specification: RFC XXXX + Author/Change Controller: IESG + Comments: + Identifies the LDAP Read Entry Controls + + +6.2. LDAP Protocol Mechanisms + + It is requested that IANA register the LDAP Protocol Mechanism + described in this document. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: IANA-ASSIGNED-OID.1 + Description: LDAP Pre-read Control + Person & email address to contact for further information: + Kurt Zeilenga + Usage: Control + Specification: RFC XXXX + Author/Change Controller: IESG + Comments: none + in 2 + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: IANA-ASSIGNED-OID.2 + Description: LDAP Post-read Control + Person & email address to contact for further information: + Kurt Zeilenga + Usage: Control + Specification: RFC XXXX + Author/Change Controller: IESG + Comments: none + in 2 + + +7. Acknowledgment + + The LDAP Pre- and Post-Read controls are modeled after similar + + + +Zeilenga LDAP Read Entry Controls [Page 5] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + capabilities offered in the DAP [X.511]. + + +8. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14 (also RFC 2119), March 1997. + + [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight + Directory Access Protocol (v3): Extension for Transport + Layer Security", RFC 2830, May 2000. + + [RFC3296] Zeilenga, K., "Named Subordinate References in + Lightweight Directory Access Protocol (LDAP) + Directories", RFC 3296, July 2002. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [X.680] International Telecommunication Union - + Telecommunication Standardization Sector, "Abstract + Syntax Notation One (ASN.1) - Specification of Basic + Notation", X.680(1997) (also ISO/IEC 8824-1:1998). + + [X.690] International Telecommunication Union - + Telecommunication Standardization Sector, "Specification + of ASN.1 encoding rules: Basic Encoding Rules (BER), + Canonical Encoding Rules (CER), and Distinguished + Encoding Rules (DER)", X.690(1997) (also ISO/IEC + 8825-1:1998). + + [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", draft- + weltman-ldapv3-proxy-xx.txt, a work in progress. + + [ASSERT] Zeilenga, K., "LDAP Assertion Control", + draft-zeilenga-ldap-assert-xx.txt, a work in progress. + + +9. Informative References + + + + +Zeilenga LDAP Read Entry Controls [Page 6] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 + (also RFC 3383), September 2002. + + [X.511] International Telecommunication Union - + Telecommunication Standardization Sector, "The + Directory: Abstract Service Definition", X.511(1993). + + [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational + Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in + progress. + + +10. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + + + +Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it has made any + effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can be obtained + from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + +Full Copyright + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + + + +Zeilenga LDAP Read Entry Controls [Page 7] + +INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003 + + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be followed, + or as required to translate it into languages other than English. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga LDAP Read Entry Controls [Page 8] + diff --git a/doc/drafts/draft-zeilenga-ldap-turn-xx.txt b/doc/drafts/draft-zeilenga-ldap-turn-xx.txt new file mode 100644 index 0000000000..8d2dd51d84 --- /dev/null +++ b/doc/drafts/draft-zeilenga-ldap-turn-xx.txt @@ -0,0 +1,339 @@ + + + + + +INTERNET-DRAFT Kurt D. Zeilenga +Intended Category: Experimental OpenLDAP Foundation +Expires in six months 8 February 2004 + + + + LDAP Turn Operation + + + +1. Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + This document is intended to be, after appropriate review and + revision, submitted to the RFC Editor for publication as an + Experimental document. Distribution of this memo is unlimited. + Technical discussion of this document will take place on the IETF LDAP + Extensions mailing list . Please send editorial + comments directly to the author . + + 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 + . The list of + Internet-Draft Shadow Directories can be accessed at + . + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + Please see the Full Copyright section near the end of this document + for more information. + + +Abstract + + This specification describes a Lightweight Directory Access Protocol + (LDAP) extended operation to reverse (or "turn") the roles of client + and server for subsequent protocol exchanges in the session. + + + + + +Zeilenga LDAP Turn Op [Page 1] + +INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004 + + +1. Background and Intent of Use + + The Lightweight Directory Access Protocol (LDAP) [RFC3377] is a client + / server protocol which typically operates over reliable octet stream + transports such as the Transport Control Protocol (TCP). Generally, + the client initiates the stream by connecting to the server's listener + at some well-known address. + + There are cases where it is desirable for the server to initiate the + stream. While it certainly is possible to write a technical + specification detailing how to implement server-initiated LDAP + sessions, this would requiring designing new authentication and other + security features to support server-initiated LDAP sessions. + + This document instead introduces an operation, the Turn operation, + which may be used to reverse the client / server roles of the + protocol peers. This allows the initiating protocol peer to be server + (after reversal). + + As an additional feature, the Turn operation may be used to allow both + peers to act in both roles. This is useful where both peers are + directory servers which desire to issue, as LDAP clients, operations + against the other. This may be useful in replicated environments. + + This operation is intended to used between protocol peers which have + established a mutual agreement, by means outside of the protocol, + which requires reversal of client / server roles or both peers to act + both as client and server. + + +1.1 Terminology + + Protocol elements are described using ASN.1 [X.680] with implicit + tags. The term "BER-encoded" means the element is to be encoded using + the Basic Encoding Rules [X.690] under the restrictions detailed in + Section 5.1 of [RFC2251]. + + 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 BCP 14 [RFC2119]. + + +2. Turn Operation + + The Turn operation is defined as a LDAP Extended Operation [RFC2251, + Section 4.12] identified by the IANA-ASSIGNED-OID. The function of + the Turn Operation is to request that the client / server roles be + reversed, or, optionally to request that both protocol peers to be + + + +Zeilenga LDAP Turn Op [Page 2] + +INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004 + + + able to act both as client and server. + + +2.1. Turn Request + + The Turn request is an ExtendedRequest with the requestName field + containing the IANA-ASSIGNED-OID and a requestValue field is a + BER-encoded turnValue: + + turnValue ::= SEQUENCE { + mutual BOOLEAN DEFAULT FALSE, + identifier LDAPString, + } + + A TRUE value of the mutual field indicates a request to allow both + peers to act both as client and server while a FALSE value indicates a + request to reserve the client and server roles. + + The value of the identifier field is a locally-defined policy + identifier (typicallly associated with a mutual agreement for which + this turn is be executed as part of). This policy identifier is + called the turn indicator. + + +2.2. Turn Response + + A Turn response is an ExtendedResponse where the responseName and + response fields are absent. A resultCode of success is returned if + and only if the responder is willing and able to turn the session as + requested. Otherwise, a different resultCode is returned. + + +3. Security Considerations + + It is generally recommended that before issuing the Turn operation the + protocol peers: + + - establish each other identities through appropriate authentication + mechanism, + - establish appropriate data integrity, data confidentiality, and + other protections, + - establish an LDAP association between the initiating peer and the + responding peer. + + And upon successful completion of turn: + - establish an LDAP association in reverse. + + That is, for peer A connecting to peer B listening and where TLS and + + + +Zeilenga LDAP Turn Op [Page 3] + +INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004 + + + SASL/EXTERNAL were to be used, the sequence of operations would be: + + A->B: StartTLS + A->B: Bind(SASL,EXTERNAL) + A->B: Turn + B->A: Bind(SASL,EXTERNAL) + + +4. IANA Considerations + + Registration of the following values [RFC3383] is requested. + + +4.1. Object Identifier + + It is requested that IANA assign an LDAP Object Identifier to identify + the LDAP Turn Operation as defined in this document. + + Subject: Request for LDAP Object Identifier Registration + Person & email address to contact for further information: + Kurt Zeilenga + Specification: RFC XXXX + Author/Change Controller: Author + Comments: + Identifies the LDAP Turn Operation + + +4.2. LDAP Protocol Mechanism + + It is requested that IANA register the LDAP Protocol Mechanism + described in this document. + + Subject: Request for LDAP Protocol Mechanism Registration + Object Identifier: IANA-ASSIGNED-OID + Description: LDAP Turn Operation + Person & email address to contact for further information: + Kurt Zeilenga + Usage: Extended Operation + Specification: RFC XXXX + Author/Change Controller: Author + Comments: none + + +5. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14 (also RFC 2119), March 1997. + + + + +Zeilenga LDAP Turn Op [Page 4] + +INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004 + + + [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. + + [X.680] International Telecommunication Union - + Telecommunication Standardization Sector, "Abstract + Syntax Notation One (ASN.1) - Specification of Basic + Notation", X.680(1997) (also ISO/IEC 8824-1:1998). + + [X.690] International Telecommunication Union - + Telecommunication Standardization Sector, "Specification + of ASN.1 encoding rules: Basic Encoding Rules (BER), + Canonical Encoding Rules (CER), and Distinguished + Encoding Rules (DER)", X.690(1997) (also ISO/IEC + 8825-1:1998). + + +6. Informative References + + [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 + (also RFC 3383), September 2002. + + +7. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + Email: Kurt@OpenLDAP.org + + + +Intellectual Property Rights + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it has made any + effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 + + + +Zeilenga LDAP Turn Op [Page 5] + +INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004 + + + rights by implementors or users of this specification can be obtained + from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + +Full Copyright + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be followed, + or as required to translate it into languages other than English. + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga LDAP Turn Op [Page 6] + + -- 2.39.5