From: Kurt Zeilenga Date: Thu, 15 Apr 2004 02:20:53 +0000 (+0000) Subject: Suck in latest docs X-Git-Tag: OPENLDAP_REL_ENG_2_2_9~9 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=59f542d6e7094d958aaa1a9ee4e49856e5da5755;p=openldap Suck in latest docs --- 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-joslin-config-schema-xx.txt b/doc/drafts/draft-joslin-config-schema-xx.txt new file mode 100644 index 0000000000..f26615d409 --- /dev/null +++ b/doc/drafts/draft-joslin-config-schema-xx.txt @@ -0,0 +1,1680 @@ + + + +Application Working Group M. Ansari +INTERNET-DRAFT Sun Microsystems, Inc. +Expires Febuary 2003 L. Howard + PADL Software Pty. Ltd. + B. Joslin [ed.] + Hewlett-Packard Company + + September 15th, 2003 +Intended Category: Informational + + + A Configuration Schema for LDAP Based + Directory User Agents + + + +Status of this Memo + + This memo provides information for the Internet community. This + memo does not specify an Internet standard of any kind. Distribu- + tion of this memo is unlimited. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or made obsolete + by other documents at any time. It is not appropriate to use + Internet-Drafts as reference material or to cite them other than as + a "working draft" or "work in progress". + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + Distribution of this document is unlimited. + +Abstract + + This document describes a mechanism for global configuration of + similar directory user agents. This document defines a schema for + + + +Joslin [Page 1] + +Internet-Draft DUA Configuration Schema October 2002 + + + configuration of these DUAs that may be discovered using the Light- + weight Directory Access Protocol in RFC 2251[17]. A set of attri- + bute types and an objectclass are proposed, along with specific + guidelines for interpreting them. A significant feature of the + global configuration policy for DUAs is a mechanism that allows + DUAs to re-configure their schema to that of the end user's + environment. This configuration is achieved through attribute and + objectclass mapping. This document is intended to be a skeleton + for future documents that describe configuration of specific DUA + services. + + +1. Background & Motivation + + The LDAP protocol has brought about a new and nearly ubiquitous + acceptance of the directory server. Many new client applications + (DUAs) are being created that use LDAP directories for many dif- + ferent services. And although the LDAP protocol has eased the + development of these applications, some challenges still exist for + both developers and directory administrators. + + The authors of this document are implementers of DUAs described by + RFC 2307 [14]. In developing these agents, we felt there are + several issues that still need to be addressed to ease the deploy- + ment and configuration of a large network of these DUAs. + + One of these challenges stems from the lack of a utopian schema. A + utopian schema would be one that every application developer could + agree upon and that would support every application. Unfortunately + today, many DUAs define their own schema (like RFC 2307 vs. + Microsoft's Services for Unix [13]) containing similar attributes, + but with different attribute names. This can lead to data redun- + dancy within directory entries and give directory administrators + unwanted challenges, updating schemas and synchronizing data. + + So, one goal of this document is to eliminate data redundancy by + having DUAs configure themselves to the schema of the deployed + directory, instead of forcing it's own schema on the directory. + + Another goal of this document is to provide the DUA with enough + configuration information so that it can discover how to retrieve + its data in the directory, such as what locations to search in the + directory tree. + + Finally, this document intends to describe a configuration method + for DUAs that can be shared among many DUAs, on various platforms, + providing as such, a configuration profile, the purpose is to cen- + tralize and simplify management of DUAs. + + + +Joslin [Page 2] + +Internet-Draft DUA Configuration Schema October 2002 + + + This document is intended to provide the skeleton framework for + future drafts, which will describe the individual implementation + details for the particular services provided by that DUA. The + authors of this document plan to develop such a document for the + Network Information Service DUA, described by RFC 2307 or its suc- + cessor. + + We expect that as DUAs take advantage of this configuration scheme, + each DUA will require additional configuration parameters, not + specified by this document. Thus, we would expect that new auxili- + ary object classes, containing new configuration attributes will be + created, and then joined with the structural class defined by this + document to create a configuration profile for a particular DUA + service. And that by joining various auxiliary objectclasses for + different DUA services, that configuration of various DUA services + can be controlled by a single configuration profile entry. + + +2. General Issues + + The schema defined by this document is defined under the "DUA Con- + figuration Schema." This schema is derived from the OID: iso (1) + org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett- + Packard Company (11) directory (1) LDAP-UX Integration Project (3) + DUA Configuration Schema (1). This OID is represented in this + document by the keystring "DUAConfSchemaOID" + (1.3.6.1.4.1.11.1.3.1). + +2.1 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119 [15]. + +2.2 Attributes + + The attributes and classes defined in this document are summarized + below. + + The following attributes are defined in this document: + + preferredServerList + defaultServerList + defaultSearchBase + defaultSearchScope + authenticationMethod + credentialLevel + serviceSearchDescriptor + + + +Joslin [Page 3] + +Internet-Draft DUA Configuration Schema October 2002 + + + serviceCredentialLevel + serviceAuthenticationMethod + attributeMap + objectclassMap + searchTimeLimit + bindTimeLimit + followReferrals + dereferenceAliases + profileTTL + +2.3 Object Classes + + The following object class is defined in this document: + + DUAConfigProfile + +2.4 Syntax Definitions + + The following syntax definitions are used throughout this document. + This document does not define new syntaxes that must be supported + by the directory server. The string encoding used by the attri- + butes defined in this document can be found section 5. + + keystring as defined by RFC 2252 [2] + descr as defined by RFC 2252 section 4.1 + a as defined by RFC 2252 section 4.1 + d as defined by RFC 2252 section 4.1 + space as defined by RFC 2252 section 4.1 + whsp as defined by RFC 2252 section 4.1 + base as defined by RFC 2253 [3] + DistinguishedName as defined by RFC 2253 section 2 + RelativeDistinguishedName as defined by RFC 2253 section 2 + scope as defined by RFC 2255 [5] + IPv4address as defined by RFC 2396 [9] + hostport as defined by RFC 2396 section 3.2.2 + port as defined by RFC 2396 section 3.2.2 + ipv6reference as defined by RFC 2732 [10] + host as defined by RFC 2732 section 3 + serviceID = keystring + + +3. Attribute Definitions + + This section contains attribute definitions to be used by DUAs when + discovering their configuration. + + ( DUAConfSchemaOID.1.0 NAME 'defaultServerList' + DESC 'Default LDAP server host address used by a DUA' + + + +Joslin [Page 4] + +Internet-Draft DUA Configuration Schema October 2002 + + + EQUALITY caseIgnoreMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase' + DESC 'Default LDAP base DN used by a DUA' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.2 NAME 'preferredServerList' + DESC 'Preferred LDAP server host addresses to be used by a + DUA' + EQUALITY caseIgnoreMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit' + DESC 'Maximum time in seconds a DUA should allow for a + search to complete' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit' + DESC 'Maximum time in seconds a DUA should allow for the + bind operation to complete' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.5 NAME 'followReferrals' + DESC 'Tells DUA if it should follow referrals + returned by a DSA search result' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases' + DESC 'Tells DUA if it should dereference aliases' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod' + DESC 'A keystring which identifies the type of + authentication method used to contact the DSA' + EQUALITY caseIgnoreMatch + + + +Joslin [Page 5] + +Internet-Draft DUA Configuration Schema October 2002 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.7 NAME 'profileTTL' + DESC 'Time to live, in seconds, before a client DUA + should re-read this configuration profile' + EQUALITY integerMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor' + DESC 'LDAP search descriptor list used by a DUA' + EQUALITY caseExactMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + ( DUAConfSchemaOID.1.9 NAME 'attributeMap' + DESC 'Attribute mappings used by a DUA' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( DUAConfSchemaOID.1.10 NAME 'credentialLevel' + DESC 'Identifies type of credentials a DUA should + use when binding to the LDAP server' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.11 NAME 'objectclassMap' + DESC 'Objectclass mappings used by a DUA' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope' + DESC 'Default search scope used by a DUA' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + SINGLE-VALUE ) + + ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel' + DESC 'Identifies type of credentials a DUA + should use when binding to the LDAP server for a + specific service' + EQUALITY caseIgnoreIA5Match + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod' + DESC 'Authentication method used by a service of the DUA' + EQUALITY caseIgnoreMatch + + + +Joslin [Page 6] + +Internet-Draft DUA Configuration Schema October 2002 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + +4. Class Definition + + The objectclass below is constructed from the attributes defined in + 3, with the exception of the cn attribute, which is defined in RFC + 2256 [8]. cn is used to represent the name of the DUA configura- + tion profile. + + ( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile' + SUP top STRUCTURAL + DESC 'Abstraction of a base configuration for a DUA' + MUST ( cn ) + MAY ( defaultServerList $ preferredServerList $ + defaultSearchBase $ defaultSearchScope $ + searchTimeLimit $ bindTimeLimit $ + credentialLevel $ authenticationMethod $ + followReferrals $ dereferenceAliases $ + serviceSearchDescriptor $ serviceCredentialLevel $ + serviceAuthenticationMethod $ objectclassMap $ + attributeMap $ profileTTL ) ) + + +5. Implementation Details + +5.1.1 Interpreting the preferredServerList attribute + + Interpretation: + + As described by the syntax, the preferredServerList parameter + is a white-space separated list of server addresses and asso- + ciated port numbers. When the DUA needs to contact a DSA, the + DUA MUST first attempt to contact one of the servers listed in + the preferredServerList attribute. The DUA MUST contact the + DSA specified by the first server address in the list. If + that DSA is unavailable, the remaining DSAs MUST be queried in + the order provided until a connection is established with a + DSA. Once a connection with a DSA is established, the DUA + SHOULD NOT attempt to establish a connection with the remain- + ing DSAs. + + If the DUA is unable to contact any of the DSAs specified by + the preferredServerList, the defaultServerList attribute MUST + be examined, as described in 5.1.2. The servers identified by + the preferredServerList MUST be contacted before attempting to + contact any of the servers specified by the defaultServerList. + + + + +Joslin [Page 7] + +Internet-Draft DUA Configuration Schema October 2002 + + + Syntax: + + serverList = host *(space [host]) + + Default Value: + + The preferredServerList attribute does not have a default + value. Instead a DUA MUST examine the defaultServerList + attribute. + + Other attribute notes: + + This attribute is used in conjunction with the defaultServer- + List attribute. Please see section 5.1.2 for additional + implementation notes. Determining how the DUA should query + the DSAs also depends on the additional configuration attri- + butes, credentialLevel, serviceCredentialLevel, bindTimeLimit, + serviceAuthenticationMethod and authenticationMethod. Please + review section 5.2 for details on how a Posix DUA should prop- + erly bind to a DSA. + + Example: + + preferredServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389 + [1080::8:800:200C:417A]:1389 + +5.1.2 Interpreting the defaultServerList attribute + + Interpretation: + + The defaultServerList attribute MUST only be examined if the + preferredServerList attribute is not provided, or the DUA is + unable to establish a connection with one of the DSAs speci- + fied by the preferredServerList. + + If more than one address is provided, the DUA may choose to + either accept the order provided, or choose to create its own + order, based on what the DUA determines is the "best" order of + servers to query. For example, the DUA may choose to examine + the server list and choose to query the DSAs in order based on + the "closest" server or the server with the least amount of + "load." Interpretation of the "best" server order is entirely + up to the DUA, and not part of this document. + + Once the order of server addresses is determined, the DUA con- + tacts the DSA specified by the first server address in the + list. If that DSA is unavailable, the remaining DSAs SHOULD + be queried until an available DSA is found or no more DSAs are + + + +Joslin [Page 8] + +Internet-Draft DUA Configuration Schema October 2002 + + + available. If a server address or port is invalid, the DUA + SHOULD proceed to the next server address as described just + above. + + Syntax: + + serverList = host *(space [host]) + + Default Value: + + If a defaultServerList attribute is not provided, the DUA + should xxx attempt to contact the same DSA that provided the + configuration profile entry itself. The default DSA is con- + tacted only if the preferredServerList attribute is also not + provided. + + Other attribute notes: + + This attribute is used in conjunction with the preferredSer- + verList attribute. Please see section 5.1.1 for additional + implementation notes. Determining how the DUA should query + the DSAs also depends on the additional configuration attri- + butes, credentialLevel, serviceCredentialLevel, bindTimeLimit, + serviceAuthenticationMethod and authenticationMethod. Please + review section 5.2 for details on how a DUA should properly + contact a DSA. + + Example: + + defaultServerList: 1.2.3.4 ldap1.mycorp.com ldap2:1389 + [1080::8:800:200C:417A]:1389 + +5.1.3 Interpreting the defaultSearchBase attribute + + Interpretation: + + When a DUA needs to search the DSA for information, this + attribute provides the "base" for the search. This parameter + can be overridden or appended by the serviceSearchDescriptor + attribute. See section 5.1.6. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 + + Default Value: + + There is no default value for the defaultSearchBase. A DUA + + + +Joslin [Page 9] + +Internet-Draft DUA Configuration Schema October 2002 + + + MAY define its own method for determining the search base, if + the defaultSearchBase is not provided. + + Other attribute notes: + + This attribute is used in conjunction with the serviceSear- + chDescriptor attribute. See section 5.1.6. + + Example: + + defaultSearchBase: dc=mycompany,dc=com + +5.1.4 Interpreting the authenticationMethod attribute + + Interpretation: + + The authenticationMethod attribute defines an ordered list of + LDAP bind methods to be used when attempting to contact a + DSA[1]. The serviceAuthenticationMethod overrides this value + for a particular service (see 5.1.15.) Each method MUST be + attempted in the order provided by the attribute, until a suc- + cessful LDAP bind is performed ("none" is assumed to always be + successful.) However the DUA MAY skip over one or more + methods. See section 5.2 for more information. + + none - The DUA does not perform an LDAP bind. + simple - The DUA performs an LDAP simple bind. + sasl - The DUA performs an LDAP SASL bind using the + specified SASL mechanism and options. + tls - The DUA performs an LDAP StartTLS operation + followed by the specified bind method (for more + information refer to section 5.1 of RFC 2830 [12]). + + Syntax: + + authMethod = method *(";" method) + method = none | simple | sasl | tls + none = "none" + simple = "simple" + sasl = "sasl/" saslmech [ ":" sasloption ] + sasloption = "auth-conf" | "auth-int" + tls = "tls:" (none | simple | sasl) + saslmech = SASL mechanism name as defined in + RFC 2222[7], section 3 + + Note: Although multiple authentication methods may be speci- + fied in the syntax, at most one of each type is allowed. + + + + +Joslin [Page 10] + +Internet-Draft DUA Configuration Schema October 2002 + + + Default Value: + + If the authenticationMethod or serviceAuthenticationMethod + (for that particular service) attributes are not provided, the + DUA MAY choose to bind to the DSA using any method defined by + the DUA. However, if either authenticationMethod or servi- + ceAuthenticationMethod are provided, the DUA MUST only use the + methods specified. + + Other attribute notes: + + When using TLS, the string "tls:sasl/EXTERNAL" implies that + two way authentication is to be performed. Any other TLS + authentication method implies one way (DSA side credential) + authentication. + + Determining how the DUA should bind to the DSAs also depends + on the additional configuration attributes, credentialLevel, + serviceCredentialLevel, serviceAuthenticationMethod and + bindTimeLimit. Please review section 5.2 for details on how + to properly bind to a DSA. + + Example: + + authenticationMethod: tls:simple;sasl/DIGEST-MD5 + (see [11]) + +5.1.5 Interpreting the credentialLevel attribute + + Interpretation: + + The credentialLevel attribute defines what type(s) of + credential(s) the DUA SHOULD use when contacting the DSA. The + serviceCredentialLevel overrides this value for a particular + service (5.1.16.) The credentialLevel can contain more than + one credential type, separated by white space. + + anonymous - The DUA SHOULD NOT use a credential when binding + to the DSA. + + proxy - The DUA SHOULD use a known proxy identity when binding + to the DSA. A proxy identity is a specific credential that + was created to represent the DUA. This document does not + define how the proxy user should be created, or how the DUA + should determine what the proxy user's credential is. This + functionality is up to each implementation. + + self - When the DUA is acting on behalf of a "real user" the + + + +Joslin [Page 11] + +Internet-Draft DUA Configuration Schema October 2002 + + + DUA SHOULD attempt to bind to the DSA as that user. The DUA + SHOULD map the user's identity to a credential used in the + directory. + + If the credentialLevel contains more than one credential type, + the DUA MUST use the credential types in the order specified. + However, the DUA MAY skip over one or more credential types. + As soon as the DUA is able to successfully bind to the DSA, + the DUA SHOULD NOT attempt to bind using the remaining creden- + tial types. + + Syntax: + + credentialLevel = level *(space level) + level = self | proxy | anonymous + self = "self" + proxy = "proxy" + anonymous = "anonymous" + + Note: Although multiple credential levels may be specified in + the syntax, at most one of each type is allowed. Refer to + implementation notes in section 5.2 for additional syntax + requirements for the credentialLevel attribute. + + Default Value: + + If the credentialLevel attribute is not defined, the DUA + SHOULD NOT use a credential when binding to the DSA (also + known as anonymous.) + + Other attribute notes: + + Determining how the DUA should bind to the DSAs also depends + on the additional configuration attributes, authentication- + Method, serviceAuthenticationMethod, serviceCredentialLevel + and bindTimeLimit. Please review section 5.2 for details on + how to properly bind to a DSA. + + Example: + + credentialLevel: proxy anonymous + +5.1.6 Interpreting the serviceSearchDescriptor attribute + + Interpretation: + + The serviceSearchDescriptor attribute defines how and where a + DUA SHOULD search for information for a particular service. + + + +Joslin [Page 12] + +Internet-Draft DUA Configuration Schema October 2002 + + + The serviceSearchDescriptor contains a serviceID, followed by + one or more base-scope-filter triples. These base-scope- + filter triples are used to define searches only for the + specific service. Multiple base-scope-filters allow the DUA + to search for data in multiple locations of the DIT. Although + this syntax is very similar to the LDAP URL[6], this draft + requires the ability to supply multiple hosts as part of the + configuration of the DSA. In addition, an ordered list of + search descritors is required, which can not be specified by + the LDAP URL. + + In addition to the triples, serviceSearchDescriptor might also + contain the DN of an entry that will contain an alternate pro- + file. The DSA SHOULD re-evaluate the alternate profile and + perform searches as specified by that profile. + + If the base, as defined in the serviceSearchDescriptor, is + followed by the "," (ASCII 0x2C) character, this base is known + as a relative base. This relative base may be constructed of + one or more RDN components. The DUA MUST define the search + base by appending the relative base with the defaultSear- + chBase. + + Syntax: + + serviceSearchList = serviceID ":" serviceSearchDesc + *(";" serviceSearchDesc) + serviceSearchDesc = confReferral | searchDescriptor + searchDescriptor = [base] ["?" [scope] ["?" [filter]]] + confReferral = "ref:" DistinguishedName + base = DistinguishedName | + RelativeBaseName + RelativeBaseName = 1*(RelativeDistinguishedName ",") + filter = UTF-8 encoded string + + If the base or filter contains the ";" (ASCII 0x3B) "?" (ASCII + 0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those + characters MUST be escaped (preceded with the "\" character.) + Alternately the DN may be surrounded by quotes (ASCII 0x22.) + Refer to RFC 2253, section 4. If the base or filter are sur- + rounded by quotes, only the """ character needs to be escaped. + Any character that is preceded by the "\" character, which + does not need to be escaped results in both "\" character and + the character itself. + + The usage and syntax of the filter string MUST be defined by + the DUA service. A suggested syntax would be that as defined + by RFC 2254. + + + +Joslin [Page 13] + +Internet-Draft DUA Configuration Schema October 2002 + + + If a DUA is performing a search for a particular service, + which has a serviceSearchDescriptor defined, the DUA MUST set + the base, scope and filter as defined. Each base-scope-filter + triple represents a single LDAP search operation. If multiple + base-scope-filter triples are provided in the serviceSear- + chDescriptor, the DUA SHOULD perform multiple search requests + and in that case it MUST be in the order specified by the ser- + viceSearchDescriptor. + + FYI: Service search descriptors do not exactly follow the LDAP + URL syntax [5]. The reasoning for this difference is to + separate the host name(s) from the filter. This allows the + DUA to have a more flexible solution in choosing its provider. + + Default Values: + + If a serviceSearchDescriptor, or an element their-of, is not + defined for a particular service, the DUA SHOULD create the + base, scope and filter as follows: + + base - Same as the defaultSearchBase or as + defined by the DUA service. + scope - Same as the defaultSearchScope or as + defined by the DUA service. + filter - Use defaults as defined by DUAs service. + + If the defaultSearchBase or defaultSearchScope are not + defined, then the DUA service may use its own default. + + + Other attribute notes: + + If a serviceSearchDescriptor exists for a given service, the + service MUST use at least one base-scope-filter triple in per- + forming searches. It SHOULD perform multiple searches per + service if multiple base-scope-filter triples are defined for + that service. + + The details of how the "filter" is interpreted by each DUA's + service is defined by that service. This means the filter is + NOT REQUIRED to be a legal LDAP filter [4]. Furthermore, + determining how attribute and objectclass mapping affects that + search filter MUST be defined by the service. I.E. The DUA + SHOULD specify if the filter has been assumed to already have + been mapped, or if it is expected that mapping would be + applied to the filter. In general practice, implementation + and usability suggests that attribute and objectclass mapping + (sections 5.1.7 and 5.1.13) SHOULD NOT be applied to the + + + +Joslin [Page 14] + +Internet-Draft DUA Configuration Schema October 2002 + + + filter defined in the serviceSearchDescriptor. + + It is assumed the serviceID is unique to a given service + within the scope of any DUA that might use the given profile. + + Example: + + defaultSearchBase: dc=mycompany,dc=com + + serviceSearchDescriptor: email:ou=people,ou=org1,? + one;ou=contractor,?one; + ref:cn=profile,dc=mycompany,dc=com + + In this example, the DUA MUST search in + "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then + SHOULD search in "ou=contractor,dc=mycompany,dc=com", and + finally it SHOULD search other locations as specified in the + profile described at "cn=profile,dc=mycompany,dc=com". For + more examples, see section 9. + + +5.1.7 Interpreting the attributeMap attribute + + Interpretation: + + A DUA SHOULD perform attribute mapping for all LDAP operations + performed for a service that has an attributeMap entry. + Because attribute mapping is specific to each service within + the DUA, a "serviceID" is required as part of the attributeMap + syntax. I.E. not all DUA services should necessarily perform + the same attribute mapping. + + Attribute mapping in general is expected be used to map attri- + butes of similar syntaxes as specified by the service sup- + ported by the DUA. However, a DUA is NOT REQUIRED to verify + syntaxes of mapped attributes. If the DUA does discover that + the syntax of the mapped attribute does not match that of the + original attribute, the DUA MAY perform translation between + the original syntax and the new syntax. When DUAs do support + attribute value translation, the list of capabable transla- + tions SHOULD be documented in a description of the DUA ser- + vice. + + Syntax: + + attributeMap = serviceID ":" origAttribute "=" + attributes + origAttribute = attribute + + + +Joslin [Page 15] + +Internet-Draft DUA Configuration Schema October 2002 + + + attributes = wattribute *( space wattribute ) + wattribute = whsp newAttribute whsp + newAttribute = descr | "*NULL*" + attribute = descr + + Values of the origAttribute are defined by and SHOULD be docu- + mented for the DUA service, as a list of known supported + attributes. + + Default Value: + + By default, attributes that are used by a DUA service are not + mapped unless mapped by the attributeMap attributes. The DUA + MUST NOT map an attribute unless it is explicitly defined by + an attributeMap attribute. + + Other attribute notes: + + When an attribute is mapped to the special keystring "*NULL*", + the DUA SHOULD NOT request that attribute from the DSA, when + performing a search or compare request. If the DUA is also + capable of performing modification on the DSA, the DUA SHOULD + NOT attempt to modify any attribute which has been mapped to + "*NULL*". + + It is assumed the serviceID is unique to a given service + within the scope of the DSA. + + A DUA SHOULD support attribute mapping. If it does, the fol- + lowing additional rules apply: + + 1) The list of attributes that are allowed to be mapped SHOULD + defined by and documented for the service. + + 2) Any supported translation of mapping from attributes of + dissimilar syntax SHOULD also be defined and documented. + + 3) If an attribute may be mapped to multiple attributes the + DSA SHOULD define a syntax or usage statement for how the new + attribute value will be evaluated. Furthermore, the resulting + translated syntax of the combined attributes MUST be the same + as the attribute being mapped. + + 4) A DUA MUST support mapping of attributes using the attri- + bute OID. It SHOULD support attribute mapping based on the + attribute name. + + 5) It is recommended that attribute mapping not be applied to + + + +Joslin [Page 16] + +Internet-Draft DUA Configuration Schema October 2002 + + + parents of the target entries. + + 6) Attribute mapping is not recursive. In other words, if an + attribute has been mapped to a target attribute, that new tar- + get attribute MUST NOT be mapped to a third attribute. + + 7) A given attribute MUST only be mapped once for a given ser- + vice. + + + Example: + + Suppose a DUA is acting on behalf of an email service. By + default the "email" service uses the "mail", "cn" and "sn" + attributes to discover mail addresses. However, the email + service has been deployed in an environment that uses "employ- + eeName" instead of "cn." And also instead of using the "mail" + attribute for email addresses, the "email" attribute is used + for that purpose. In this case, the attribute "cn" can be + mapped to "employeeName," allowing the DUA to perform searches + using the "employeeName" attribute as part of the search + filter, instead of "cn". And "mail" can be mapped to "email" + when attempting to retrieve the email address. This mapping + is performed by adding the attributeMap attributes to the con- + figuration profile entry as follows (represented in LDIF[18]): + + attributeMap: email:cn=employeeName + attributeMap: email:mail=email + + As described above, the DUA MAY also map a single attribute to + multiple attributes. When mapping a single attribute to more + than one attribute, the new syntax or usage of the mapped + attribute must be intrinsically defined by the DUAs service. + + attributeMap: email:cn=firstName lastName + + In the above example, the DUA creates the new value by gen- + erating space separated string using the values of the mapped + attributes. In this case, a special mapping must be defined + so that a proper search filter can be created. For further + information on this example, please refer to section 9. + + Another possibility for multiple attribute mapping might come + in when constructing returned attributes. For example, + perhaps all email addresses are of a guaranteed syntax of + "uid@domain". And in this example, the uid and domain are + separate attributes in the directory. The email service may + define that if the "mail" attribute is mapped to two different + + + +Joslin [Page 17] + +Internet-Draft DUA Configuration Schema October 2002 + + + attributes, it will construct the email address as a concate- + nation of the uid and domain attributes, placing the "@" char- + acter between them. + + attributeMap: email:mail=uid domain + + +5.1.8 Interpreting the searchTimeLimit attribute + + Interpretation: + + The searchTimeLimit attribute defines the maximum time, in + seconds, that a DUA SHOULD allow to perform a search request. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. + + Default Value: + + If the searchTimeLimit attribute is not defined or is zero, + the search time limit is not enforced by the DUA. + + Other attribute notes: + + This time limit only includes the amount of time required to + perform the LDAP search operation. If other operations are + required, those operations do not need to be considered part + of the search time. See bindTimeLimit for the LDAP bind + operation. + +5.1.9 Interpreting the bindTimeLimit attribute + + Interpretation: + + The bindTimeLimit attribute defines the maximum time, in + seconds, that a DUA SHOULD allow to perform an LDAP bind + request against each server on the preferredServerList or + defaultServerList. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. + + Default Value: + + If the bindTimeLimit attribute is not defined or is zero, the + bind time limit is not enforced by the DUA. + + + +Joslin [Page 18] + +Internet-Draft DUA Configuration Schema October 2002 + + + Other attribute notes: + + This time limit only includes the amount of time required to + perform the LDAP bind operation. If other operations are + required, those operations do not need to be considered part + of the bind time. See searchTimeLimit for the LDAP search + operation. + +5.1.10 Interpreting the followReferrals attribute + + Interpretation: + + If set to TRUE, the DUA SHOULD follow any referrals if + discovered. + + If set to FALSE, the DUA MUST NOT follow referrals. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. + + Default Value: + + If the followReferrals attribute is not set or set to an + invalid value the default value is TRUE. + +5.1.11 Interpreting the dereferenceAliases attribute + + Interpretation: + + If set to TRUE, the DUA SHOULD enable alias dereferening. + + If set to FALSE, the DUA MUST NOT enable alias dereferencing. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. + + Default Value: + + If the dereferenceAliases attribute is not set or set to an + invalid value the default value is TRUE. + +5.1.12 Interpreting the profileTTL attribute + + Interpretation: + + The profileTTL attribute defines how often the DUA SHOULD re- + + + +Joslin [Page 19] + +Internet-Draft DUA Configuration Schema October 2002 + + + load and reconfigure itself using the corresponding configura- + tion profile entry. The value is represented in seconds. + Once a DUA reloads the profile entry, it SHOULD re-configure + itself with the new values. + + Syntax: + + Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. + + Default Value: + + If not specified the DUA MAY use its own reconfiguration pol- + icy. + + Other attribute notes: + + If the profileTTL value is zero, the DUA SHOULD NOT automati- + cally re-load the configuration profile. + +5.1.13 Interpreting the objectclassMap attribute + + Interpretation: + + A DUA MAY perform objectclass mapping for all LDAP operations + performed for a service that has an objectclassMap entry. + Because objectclass mapping is specific for each service + within the DUA, a "serviceID" is required as part of the + objectclassMap syntax. I.E. Not all DUA services should + necessarily perform the same objectclass mapping. + + Objectclass mapping SHOULD be used in conjunction with attri- + bute mapping to map the required schema by the service to an + equivalent schema that is available in the directory. + + Objectclass mapping may or may not be required by a DUA. In + general, the objectclass attribute is used primarily in search + filters. If a service search descriptor is provided, it is + expected that the search filter contains a "correct" search + filter (though this is not a requirement,) which does not need + to be re-mapped. However, when the service search descriptor + is not provided, and the default search filter for that ser- + vice contains the objectclass attribute, that search filter + SHOULD be re-defined by objectclass mapping. If a default + search filter is not used, it SHOULD be re-defined through the + serviceSearchDescriptor. If a serviceSearchDescriptor is + defined for a particular service, it SHOULD NOT be re-mapped + by either the objectclassMap or attributeMap values. + + + + +Joslin [Page 20] + +Internet-Draft DUA Configuration Schema October 2002 + + + One condition where the objectclassMap SHOULD be used is when + the DUA is providing gateway functionality. In this case, the + DUA is acting on behalf of another service, which may pass in + a search filter itself. In this type of DUA, the DUA may + alter the search filter according to the appropriate attribu- + teMap and objectclassMap values. And in this case, it is also + assumed that a serviceSearchDescriptor is not defined. + + Syntax: + + objectclassMap = serviceID ":" origObjectclass "=" + objectclass + origObjectclass = objectclass + objectclass = keystring + + Values of the origObjectclass depend on the type of DUA Ser- + vice using the objectclass mapping feature. + + Default Value: + + The DUA MUST NOT remap an objectclass unless it is explicitly + defined by an objectclassMap attribute. + + Other attribute notes: + + A DUA SHOULD support objectclass mapping. If it does, the DUA + MUST support mapping of objectclasses using the objectclass + OID. It SHOULD support objectclass mapping based on the + objectclass name. + + It is assumed the serviceID is unique to a given service + within the scope of the DSA. + + Example: + + Suppose a DUA is acting on behalf of an email service. By + default the "email" service uses the "mail", "cn" and "sn" + attributes to discover mail addresses in entries created using + inetOrgPerson objectclass [16]. However, the email service + has been deployed in an environment that uses entries created + using "employee" objectclass. In this case, the attribute + "cn" can be mapped to "employeeName", and "inetOrgPerson" can + be mapped to "employee", allowing the DUA to perform LDAP + operations using the entries that exist in the directory. + This mapping is performed by adding attributeMap and + objectclassMap attributes to the configuration profile entry + as follows (represented in LDIF[18]): + + + + +Joslin [Page 21] + +Internet-Draft DUA Configuration Schema October 2002 + + + attributeMap: email:cn=employeeName + objectclassMap: email:inetOrgPerson=employee + + +5.1.14 Interpreting the defaultSearchScope attribute + + Interpretation: + + When a DUA needs to search the DSA for information, this + attribute provides the "scope" for the search. This parameter + can be overridden by the serviceSearchDescriptor attribute. + See section 5.1.6. + + Syntax: + + scopeSyntax = "base" | "one" | "sub" + + Default Value: + + The default value for the defaultSearchScope SHOULD be defined + by the DUA service. If the default search scope for a service + is not defined then the scope SHOULD be for the DUA to perform + a subtree search. + + +5.1.15 Interpreting the serviceAuthenticationMethod attribute + + Interpretation: + + The serviceAuthenticationMethod attribute defines an ordered + list of LDAP bind methods to be used when attempting to con- + tact a DSA for a particular service. Interpretation and use + of this attribute is the same as 5.1.4, but specific for each + service. + + Syntax: + + svAuthMethod = service ":" method *(";" method) + + Note: Although multiple authentication methods may be speci- + fied in the syntax, at most one of each type is allowed. + + Default Value: + + If the serviceAuthenticationMethod attribute is not provided, + the authenticationMethod SHOULD be followed, or its default. + + Other attribute notes: + + + +Joslin [Page 22] + +Internet-Draft DUA Configuration Schema October 2002 + + + Determining how the DUA should bind to the DSAs also depends + on the additional configuration attributes, credentialLevel, + serviceCredentialLevel and bindTimeLimit. Please review sec- + tion 5.2 for details on how to properly bind to a DSA. + + Example: + + serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5 + + +5.1.16 Interpreting the serviceCredentialLevel attribute + + Interpretation: + + The serviceCredentialLevel attribute defines what type(s) of + credential(s) the DUA SHOULD use when contacting the DSA for a + particular service. Interpretation and used of this attribute + are the same as 5.1.5. + + Syntax: + + svCredentialLevel = service ":" level *(space level) + + Refer to implementation notes in section 5.2 for additional + syntax requirements for the credentialLevel attribute. + + Note: Although multiple credential levels may be specified in + the syntax, at most one of each type is allowed. + + Default Value: + + If the serviceCredentialLevel attribute is not defined, the + DUA MUST examine the credentialLevel attribute, or follow its + default if not provided. + + Other attribute notes: + + Determining how the DUA should bind to the DSAs also depends + on the additional configuration attributes, serviceAuthentica- + tionMethod, authenticationMethod and bindTimeLimit. Please + review section 5.2 for details on how to properly bind to a + DSA. + + Example: + + serviceCredentialLevel: email:proxy anonymous + + + + + +Joslin [Page 23] + +Internet-Draft DUA Configuration Schema October 2002 + + +5.2 Binding to the Directory Server + + The DUA SHOULD use the following algorithm when binding to the + server: + + for (clevel in credLevel) [see note 1] + if (clevel is "anonymous") + for (host in hostnames) [see note 2] + if (server is responding) + return success + return failure + else + for (amethod in authMethod) [see note 3] + if (amethod is none) + for (host in hostnames) + if (server is responding) + return success + return failure + else + for (host in hostnames) + authenticate using amethod and clevel + if (authentication passed) + return success + return failure + + Note 1: The credLevel is a list of credential levels as defined + in serviceCredentialLevel (section 5.1.16) for a given + service. If the serviceCredentialLevel is not defined, + the DUA MUST examine the credentialLevel attribute. + + Note 2: hostnames is the list of servers to contact as defined + in 5.1.1 & 5.1.2. + + Note 3: The authMethod a list of authentication methods as defined + in serviceAuthenticationMethod (section 5.1.15) for a + given service. If the serviceAuthenticationMethod is not + defined, the DUA MUST examine the authenticationMethod + attribute. + + + +6. Security Considerations + + The profile entries MUST be protected against unauthorized modifi- + cation. Since the profile is most useful if its content is avail- + able broadly, it is recommended that the profile entries will be + readable anonymously. However, ultimately each service needs to + consider implications of providing its service configuration as + + + +Joslin [Page 24] + +Internet-Draft DUA Configuration Schema October 2002 + + + part of this profile and limit access to the profile entries + accordingly. Additionally, the management of the authentication + credentials for the DUA is outside the scope of this document and + needs to be handled by the DUA. + + The algorithm described by section 5.2 also has security considera- + tions. Altering that design will alter the security aspectes of + the configuration profile. + + +7. Acknowledgments + + There were several additional authors of this document. However we + chose to represent only one author per company in the heading. + From Sun we also would like to acknowledge Roberto Tam for his + design work on Sun's first LDAP name service product and his input + for this document. From Hewlett-Packard we'd like to acknowledge + Dave Binder for his work architecting Hewlett-Packard's LDAP name + service product as well as his design guidance on this document. + We'd also like to acknowledge Grace Lu from HP, for her input and + implementation of HP's configuration profile manager code. + + +8. References + +[1] + M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication + Methods for LDAP", RFC 2828, May 2000 + +[2] + M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory + Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, + December 1997. + +[3] + M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol + (v3): UTF-8 String Representation of Distinguished Names", RFC + 2253, December 1997. + +[4] + T. Howes, "The String Representation of LDAP Search Filters", RFC + 2254, December 1997. + +[5] + T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. + +[6] + T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource + + + +Joslin [Page 25] + +Internet-Draft DUA Configuration Schema October 2002 + + + Locators (URL)", RFC 1738, December 1994. + +[7] + J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC + 2222, October 1997 + +[8] + M. Wahl, "A Summary of the X.500(96) User Schema for use with + LDAPv3", RFC 2256, December 1997. + +[9] + T. Berners-Lee, R. Fielding, R. Fielding, "Uniform Resource Iden- + tifiers (URI): Generic Syntax", RFC 2396, August 1998. + +[10] + R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6 + Addresses in URL's, RFC 2732, December 1999. + +[11] + P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechan- + ism", RFC 2831, May 2000 + +[12] + J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto- + col [v3]: Extension for Transport Layer Security", RFC 2830, May + 2000 + +[13] + Microsoft Corporation, "Services for Unix 2.0", + http://www.microsoft.com/WINDOWS2000/sfu/default.asp + +[14] + L. Howard, "An Approach for Using LDAP as a Network Information + Service", RFC 2307, March 1998. + +[15] + S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- + els", RFC 2119, March 1997. + +[16] + M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC + 2789, April 2000 + +[17] + M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol + (v3)", RFC 2251, December 1997. + +[18] + + + +Joslin [Page 26] + +Internet-Draft DUA Configuration Schema October 2002 + + + G. Good, "The LDAP Data Interchange Format (LDIF) - Technical + Specification", RFC 2849, June 2000. + + +9. Examples + + In this section we will describe a fictional DUA which provides one + service, called the "email" service. This service would be similar + to an email client that uses an LDAP directory to discover email + addresses based on a textual representation of the recipient's col- + loquial name. + + This email service is defined by default to expect that users with + email addresses will be of the "inetOrgPerson" objectclass type + [16]. And by default, the "email" service expects the colloquial + name to be stored in the "cn" attribute, while it expects the email + address to be stored in the "mail" attribute (as one would expect + as defined by the inetOrgPerson objectclass.) + + As a special feature, the "email" service will perform a special + type of attribute mapping, when performing searches. If the "cn" + attribute has been mapped to two or more attributes, the "email" + service will parse the requested search string and map each white- + space separated token into the mapped attributes, respectively. + + The default search filter for the "email" service is + "(objectclass=inetOrgPerson)". The email service also defines that + when it performs a name to address discovery, it will wrap the + search filter inside a complex search filter as follows: + + (&()(cn~=) + + or if "cn" has been mapped to multiple attributes, that wrapping + would appear as follows: + + (&()(attr1~=)(attr2~=)...) + + The below examples show how the "email" service builds it search + requests, based on the defined profile. In all cases, the + defaultSearchBase is "o=airius.com" and the defaultSearchScope is + undefined. + + In addition, for all examples, we assume that the "email" service + has been requested to discover the email address for "Jane Hernan- + dez." + + + Example 1: + + + +Joslin [Page 27] + +Internet-Draft DUA Configuration Schema October 2002 + + + serviceSearchDescriptor: email:"ou=marketing," + + base: ou=marketing,o=airius.com + scope: sub + filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez)) + + Example 2: + + serviceSearchDescriptor: email:"ou=marketing,"?one? + (&(objectclass=inetOrgPerson)(c=us)) + attributeMap: email:cn=2.5.4.42 sn + + Note: 2.5.4.42 is the OID that represents the "givenName" + attribute. + + In this example, the email service performs parsing + as described above to generate a complex search filter. The above + example results in one search. + + base: ou=marketing,o=airius.com + scope: one + filter: (&(&(objectclass=inetOrgPerson)(c=us)) + (2.5.4.42~=Jane)(sn~=Hernandez)) + + Example 3: + + serviceSearchDescriptor: email:ou=marketing,"?base + attributeMap: email:cn=name + + This example is invalid, because either the quote should have been + escaped, or there should have been a leading quote. + + Example 4: + + serviceSearchDescriptor: email:ou=\mar\\keting,\"?base + attributeMap: email:cn=name + + base: ou=\mar\keting," + scope: base + filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez)) + + Example 5: + + serviceSearchDescriptor: email:ou="marketing",o=supercom + + This example is invalid, since the quote was not a leading quote, + and thus should have been escaped. + + + + +Joslin [Page 28] + +Internet-Draft DUA Configuration Schema October 2002 + + + Example 6: + + serviceSearchDescriptor: email:??(&(objectclass=person) + (ou=Org1 \\(temporary\\))) + + base: o=airius.com + scope: sub + filter: (&((&(objectclass=person)(ou=Org1 \(Temporary\))) + (cn~=Jane Henderson))) + + Example 7: + + serviceSearchDescriptor: email:"ou=funny?org," + + base: ou=funny?org,o=airius.com + scope: sub + filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez)) + + +10. Author's Addresses + + Luke Howard + PADL Software Pty. Ltd. + PO Box 59 + Central Park Vic 3145 + Australia + + EMail: lukeh@padl.com + + + Bob Joslin + Hewlett-Packard Company + 19420 Homestead RD MS43-LF + Cupertino, CA 95014 + USA + + Phone: +1 408 447-3044 + EMail: bob_joslin@hp.com + + + Morteza Ansari + Sun Microsystems, Inc. + 901 San Antonio RD MS MPK17-203 + Palo Alto, CA 94303 + USA + + Phone: +1 650 786-6178 + EMail: morteza.ansari@sun.com + + + +Joslin [Page 29] + +Internet-Draft DUA Configuration Schema October 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Joslin [Page 30] + 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] + + diff --git a/doc/man/man5/slapd.conf.5 b/doc/man/man5/slapd.conf.5 index 5857fb2889..e642a476f5 100644 --- a/doc/man/man5/slapd.conf.5 +++ b/doc/man/man5/slapd.conf.5 @@ -284,195 +284,6 @@ feature. The default is 0. .B include Read additional configuration information from the given file before continuing with the next line of the current file. -.TP -.B limits [ [...]] -Specify time and size limits based on who initiated an operation. -The argument -.B who -can be any of -.RS -.RS -.TP -anonymous | users | [dn[.