--- 1/draft-ietf-ldapbis-protocol-30.txt 2006-02-05 00:12:36.000000000 +0100 +++ 2/draft-ietf-ldapbis-protocol-31.txt 2006-02-05 00:12:36.000000000 +0100 @@ -1,51 +1,52 @@ + Internet-Draft Editor: J. Sermersheim Intended Category: Standard Track Novell, Inc -Document: draft-ietf-ldapbis-protocol-30.txt Feb 2005 +Document: draft-ietf-ldapbis-protocol-31.txt May 2005 Obsoletes: RFCs 2251, 2830, 3771 LDAP: The Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + which he or she becomes aware will be disclosed, in accordance with + Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at . The list of Internet-Draft Shadow Directories can be accessed at . - This Internet-Draft will expire in February 2005. + This Internet-Draft will expire in November 2005. Technical discussion of this document will take place on the IETF LDAP Revision Working Group (LDAPbis) mailing list . Please send editorial comments directly to the editor . Copyright Notice - Copyright (C) The Internet Society 2004. All Rights Reserved. + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). @@ -78,24 +79,24 @@ 4.6. Modify Operation.............................................29 4.7. Add Operation................................................31 4.8. Delete Operation.............................................31 4.9. Modify DN Operation..........................................32 4.10. Compare Operation...........................................33 4.11. Abandon Operation...........................................34 4.12. Extended Operation..........................................35 4.13. IntermediateResponse Message................................36 4.14. StartTLS Operation..........................................37 5. Protocol Encoding, Connection, and Transfer....................39 - 5.1. Protocol Encoding............................................40 + 5.1. Protocol Encoding............................................39 5.2. Transmission Control Protocol (TCP)..........................40 5.3. Termination of the LDAP session..............................40 - 6. Security Considerations........................................41 + 6. Security Considerations........................................40 7. Acknowledgements...............................................42 8. Normative References...........................................42 9. Informative References.........................................44 10. IANA Considerations...........................................44 11. Editor's Address..............................................45 Appendix A - LDAP Result Codes....................................46 A.1 Non-Error Result Codes........................................46 A.2 Result Codes..................................................46 Appendix B - Complete ASN.1 Definition............................51 Appendix C - Changes..............................................57 @@ -118,33 +119,32 @@ Directory Access Protocol (LDAP), along with their semantics. Following the description of protocol elements, it describes the way in which the protocol elements are encoded and transferred. 1.1. Relationship to Other LDAP Specifications This document is an integral part of the LDAP Technical Specification [Roadmap] which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety. - This document obsoletes all of RFC 2251 except the following: - Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, - 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) are - obsoleted by [Models]. - Section 3.3 is obsoleted by [Roadmap]. - Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth]. - - Appendix C.1 summarizes substantive changes to the remaining - sections. + This document, together with [Roadmap], [AuthMeth], and [Models], + obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by + [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by + [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, + 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) + are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by + this document. Appendix C.1 summarizes substantive changes in the + remainder. - This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The - remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 - summarizes substantive changes to the remaining sections. + This document obsoletes RFC 2830, Sections 2 and 4. The remainder of + RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes + substantive changes to the remaining sections. This document also obsoletes RFC 3771 in entirety. 2. 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 [Keyword]. Character names in this document use the notation for code points and @@ -162,23 +162,23 @@ established by these services. The term "TLS layer" refers to TLS services used in providing security services, as well as associations established by these services. The term "SASL layer" refers to SASL services used in providing security services, as well as associations established by these services. - The term "LDAP message layer" refers to the LDAP Message (PDU) - services used in providing directory services, as well as - associations established by these services. + The term "LDAP message layer" refers to the LDAP Message Protocol + Data Unit (PDU) services used in providing directory services, as + well as associations established by these services. The term "LDAP session" refers to combined services (transport connection, TLS layer, SASL layer, LDAP message layer) and their associations. See the table in Section 5 for an illustration of these four terms. 3. Protocol Model The general model adopted by this protocol is one of clients @@ -287,31 +287,31 @@ MessageID ::= INTEGER (0 .. maxInt) maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- The ASN.1 type Controls is defined in Section 4.1.11. The function of the LDAPMessage is to provide an envelope containing common fields required in all protocol exchanges. At this time the only common fields are the messageID and the controls. - If the server receives a PDU from the client in which the LDAPMessage - SEQUENCE tag cannot be recognized, the messageID cannot be parsed, - the tag of the protocolOp is not recognized as a request, or the - encoding structures or lengths of data fields are found to be + If the server receives an LDAPMessage from the client in which the + LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot + be parsed, the tag of the protocolOp is not recognized as a request, + or the encoding structures or lengths of data fields are found to be incorrect, then the server SHOULD return the Notice of Disconnection described in Section 4.4.1, with the resultCode set to protocolError, and MUST immediately terminate the LDAP session as described in Section 5.3. - In other cases where the client or server cannot parse a PDU, it - SHOULD abruptly terminate the LDAP session (Section 5.3) where + In other cases where the client or server cannot parse an LDAP PDU, + it SHOULD abruptly terminate the LDAP session (Section 5.3) where further communication (including providing notice) would be pernicious. Otherwise, server implementations MUST return an appropriate response to the request, with the resultCode set to protocolError. Lightweight Directory Access Protocol Version 3 4.1.1.1. Message ID All LDAPMessage envelopes encapsulating responses contain the @@ -660,34 +660,35 @@ request control. The criticality field only has meaning in controls attached to request messages (except UnbindRequest). For controls attached to response messages and the UnbindRequest, the criticality field SHOULD be FALSE, and MUST be ignored by the receiving protocol peer. A value of TRUE indicates that it is unacceptable to perform the operation without applying the semantics of the control. Specifically, the criticality field is applied as follows: - - Regardless of the value of the criticality field, if the server - recognizes the control type and it is appropriate for the - operation, the server is to make use of the control when - performing the operation. + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and the criticality + field is TRUE, the server MUST NOT perform the operation, and for + operations that have a response message, MUST return with the + resultCode set to unavailableCriticalExtension. - - If the server does not recognize the control type or it is not - appropriate for the operation, and the criticality field is TRUE, - the server MUST NOT perform the operation, and for operations that - have a response message, MUST return with the resultCode set to - unavailableCriticalExtension. + - If the server does not recognize the control type, determines that + it is not appropriate for the operation, or is otherwise unwilling + to perform the operation with the control, and the criticality + field is FALSE, the server MUST ignore the control. - - If the server does not recognize the control type or it is not - appropriate for the operation, and the criticality field is FALSE, - the server MUST ignore the control. + - Regardless of criticality, if a control is applied to an + operation, it is applied consistently and impartially to the + entire operation. Lightweight Directory Access Protocol Version 3 The controlValue may contain information associated with the controlType. Its format is defined by the specification of the control. Implementations MUST be prepared to handle arbitrary contents of the controlValue octet string, including zero bytes. It is absent only if there is no value information which is associated with a control of its type. When a controlValue is defined in terms of ASN.1, and BER encoded according to Section 5.1, it also follows @@ -696,26 +697,29 @@ Servers list the controlType of request controls they recognize in the 'supportedControl' attribute in the root DSE (Section 5.1 of [Models]). Controls SHOULD NOT be combined unless the semantics of the combination has been specified. The semantics of control combinations, if specified, are generally found in the control specification most recently published. When a combination of controls is encountered whose semantics are invalid, not specified (or not known), the message is considered to be not well-formed, thus the - operation fails with protocolError. Additionally, unless order- - dependent semantics are given in a specification, the order of a - combination of controls in the SEQUENCE is ignored. Where the order - is to be ignored but cannot be ignored by the server, the message is - considered not well-formed and the operation fails with - protocolError. + operation fails with protocolError. Controls with a criticality of + FALSE may be ignored in order to arrive at a valid combination. + Additionally, unless order-dependent semantics are given in a + specification, the order of a combination of controls in the SEQUENCE + is ignored. Where the order is to be ignored but cannot be ignored by + the server, the message is considered not well-formed and the + operation fails with protocolError. Again, controls with a + criticality of FALSE may be ignored in order to arrive at a valid + combination. This document does not specify any controls. Controls may be specified in other documents. Documents detailing control extensions are to provide for each control: - the OBJECT IDENTIFIER assigned to the control, - direction as to what value the sender should provide for the criticality field (note: the semantics of the criticality field are defined above should not be altered by the control's @@ -723,29 +727,28 @@ - whether the controlValue field is present, and if so, the format of its contents, - the semantics of the control, and - optionally, semantics regarding the combination of the control with other controls. 4.2. Bind Operation + Lightweight Directory Access Protocol Version 3 The function of the Bind operation is to allow authentication information to be exchanged between the client and server. The Bind operation should be thought of as the "authenticate" operation. Operational, authentication, and security-related semantics of this operation are given in [AuthMeth]. - Lightweight Directory Access Protocol Version 3 - The Bind request is defined as follows: BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication AuthenticationChoice } AuthenticationChoice ::= CHOICE { simple [0] OCTET STRING, -- 1 and 2 reserved @@ -775,24 +778,24 @@ - authentication: information used in authentication. This type is extensible as defined in Section 3.7 of [LDAPIANA]. Servers that do not support a choice supplied by a client return a BindResponse with the resultCode set to authMethodNotSupported. Textual passwords (consisting of a character sequence with a known character set and encoding) transferred to the server using the simple AuthenticationChoice SHALL be transferred as [UTF-8] encoded [Unicode]. Prior to transfer, clients SHOULD prepare text - passwords by applying the [SASLprep] profile of the [Stringprep] - algorithm. Passwords consisting of other data (such as random - octets) MUST NOT be altered. The determination of whether a - password is textual is a local client matter. + passwords as "query" strings by applying the [SASLprep] profile of + the [Stringprep] algorithm. Passwords consisting of other data + (such as random octets) MUST NOT be altered. The determination of + whether a password is textual is a local client matter. Lightweight Directory Access Protocol Version 3 4.2.1. Processing of the Bind Request Before processing a BindRequest, all uncompleted operations MUST either complete or be abandoned. The server may either wait for the uncompleted operations to complete, or abandon them. The server then proceeds to authenticate the client in either a single-step, or multi-step Bind process. Each step requires the server to return a @@ -800,22 +803,22 @@ After sending a BindRequest, clients MUST NOT send further LDAP PDUs until receiving the BindResponse. Similarly, servers SHOULD NOT process or respond to requests received while processing a BindRequest. If the client did not bind before sending a request and receives an operationsError to that request, it may then send a BindRequest. If this also fails or the client chooses not to bind on the existing LDAP session, it may terminate the LDAP session, re-establish it and - begin again by first sending a PDU with a BindRequest. This will aid - in interoperating with servers implementing other versions of LDAP. + begin again by first sending a BindRequest. This will aid in + interoperating with servers implementing other versions of LDAP. Clients may send multiple Bind requests to change the authentication and/or security associations or to complete a multi-stage Bind process. Authentication from earlier binds is subsequently ignored. For some SASL authentication mechanisms, it may be necessary for the client to invoke the BindRequest multiple times ([AuthMeth] Section 8.2). Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage Bind. @@ -1124,124 +1127,135 @@ - The attribute type does not define the appropriate matching rule. - A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type. - The type of filtering requested is not implemented. - The assertion value is invalid. - Lightweight Directory Access Protocol Version 3 - For example, if a server did not recognize the attribute type - shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, and the - filters (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would each - evaluate to Undefined. + shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and + (shoeSize<=12) would each evaluate to Undefined. Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511]. + Lightweight Directory Access Protocol Version 3 + 4.5.1.7.1 SearchRequest.filter.equalityMatch - The matching rule for equalityMatch filter items is defined by the - EQUALITY matching rule for the attribute type. + The matching rule for an equalityMatch filter is defined by the + EQUALITY matching rule for the attribute type or subtype. The filter + is TRUE when the EQUALITY rule returns TRUE as applied to the + attribute or subtype and the asserted value. 4.5.1.7.2 SearchRequest.filter.substrings There SHALL be at most one 'initial', and at most one 'final' in the 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL be the first element of 'substrings'. If 'final' is present, it SHALL be the last element of 'substrings'. The matching rule for an AssertionValue in a substrings filter item - is defined by the SUBSTR matching rule for the attribute type. Note - that the AssertionValue in a substrings filter item conforms to the - assertion syntax of the EQUALITY matching rule for the attribute type - rather than the assertion syntax of the SUBSTR matching rule for the - attribute type. Conceptually, the entire SubstringFilter is converted - into an assertion value of the substrings matching rule prior to - applying the rule. + is defined by the SUBSTR matching rule for the attribute type or + subtype. The filter is TRUE when the SUBSTR rule returns TRUE as + applied to the attribute or subtype and the asserted value. + + Note that the AssertionValue in a substrings filter item conforms to + the assertion syntax of the EQUALITY matching rule for the attribute + type rather than the assertion syntax of the SUBSTR matching rule for + the attribute type. Conceptually, the entire SubstringFilter is + converted into an assertion value of the substrings matching rule + prior to applying the rule. 4.5.1.7.3 SearchRequest.filter.greaterOrEqual - The matching rule for the greaterOrEqual filter item is defined by - the ORDERING and EQUALITY matching rules for the attribute type. + The matching rule for a greaterOrEqual filter is defined by the + ORDERING matching rule for the attribute type or subtype. The filter + is TRUE when the ORDERING rule returns FALSE as applied to the + attribute or subtype and the asserted value. 4.5.1.7.4 SearchRequest.filter.lessOrEqual - The matching rule for the lessOrEqual filter item is defined by the - ORDERING matching rule for the attribute type. + The matching rules for a lessOrEqual filter are defined by the + ORDERING and EQUALITY matching rules for the attribute type or + subtype. The filter is TRUE when either the ORDERING or EQUALITY rule + returns TRUE as applied to the attribute or subtype and the asserted + value. 4.5.1.7.5 SearchRequest.filter.present - The present match evaluates to TRUE where there is an attribute or - subtype of the specified attribute description present in an entry, - and FALSE otherwise (including a presence test with an unrecognized - attribute description). + A present filter is TRUE when there is an attribute or subtype of the + specified attribute description present in an entry, FALSE when no + attribute or subtype of the specified attribute description is + present in an entry, and Undefined otherwise. Lightweight Directory Access Protocol Version 3 4.5.1.7.6 SearchRequest.filter.approxMatch - An approxMatch filter item evaluates to TRUE when there is a value of - the attribute or subtype for which some locally-defined approximate - matching algorithm (e.g. spelling variations, phonetic match, etc.) - returns TRUE. If an item matches for equality, it also satisfies an + An approxMatch filter is TRUE when there is a value of the attribute + type or subtype for which some locally-defined approximate matching + algorithm (e.g. spelling variations, phonetic match, etc.) returns + TRUE. If a value matches for equality, it also satisfies an approximate match. If approximate matching is not supported for the attribute, this filter item should be treated as an equalityMatch. 4.5.1.7.7 SearchRequest.filter.extensibleMatch The fields of the extensibleMatch filter item are evaluated as follows: - If the matchingRule field is absent, the type field MUST be present, and an equality match is performed for that type. - If the type field is absent and the matchingRule is present, the matchValue is compared against all attributes in an entry which support that matchingRule. - If the type field is present and the matchingRule is present, the - matchValue is compared against entry attributes of the specified - type. + matchValue is compared against the specified attribute type and + its subtypes. - If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and evaluates to TRUE if there is - at least one attribute in the distinguished name for which the - filter item evaluates to TRUE. The dnAttributes field is present - to alleviate the need for multiple versions of generic matching - rules (such as word matching), where one applies to entries and - another applies to entries and DN attributes as well. + at least one attribute or subtype in the distinguished name for + which the filter item evaluates to TRUE. The dnAttributes field is + present to alleviate the need for multiple versions of generic + matching rules (such as word matching), where one applies to + entries and another applies to entries and DN attributes as well. The matchingRule used for evaluation determines the syntax for the assertion value. Once the matchingRule and attribute(s) have been - determined, the filter item evaluates to TRUE if it matches with at - least one attribute in the entry, FALSE if it does not match any - attribute in the entry, and Undefined if the matchingRule is not - recognized, the matchingRule is unsuitable for use with the specified - type, or the assertionValue is invalid. + determined, the filter item evaluates to TRUE if it matches at least + one attribute type or subtype in the entry, FALSE if it does not + match any attribute type or subtype in the entry, and Undefined if + the matchingRule is not recognized, the matchingRule is unsuitable + for use with the specified type, or the assertionValue is invalid. 4.5.1.7 SearchRequest.attributes A selection list of the attributes to be returned from each entry - which matches the search filter. LDAPString values of this field are - constrained to the following Augmented Backus-Naur Form ([ABNF]): + which matches the search filter. Attributes which are subtypes of + listed attributes are implicitly included. LDAPString values of this + field are constrained to the following Augmented Backus-Naur Form + ([ABNF]): attributeSelector = attributedescription / selectorspecial + Lightweight Directory Access Protocol Version 3 selectorspecial = noattrs / alluserattrs - Lightweight Directory Access Protocol Version 3 noattrs = %x31.2E.31 ; "1.1" alluserattrs = %x2A ; asterisk ("*") The production is defined in Section 2.5 of [Models]. There are three special cases which may appear in the attributes selection list: @@ -1278,34 +1292,34 @@ 4.5.2. Search Result The results of the Search operation are returned as zero or more SearchResultEntry and/or SearchResultReference messages, followed by a single SearchResultDone message. SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } + Lightweight Directory Access Protocol Version 3 PartialAttributeList ::= SEQUENCE OF partialAttribute PartialAttribute - Lightweight Directory Access Protocol Version 3 SearchResultReference ::= [APPLICATION 19] SEQUENCE SIZE (1..MAX) OF uri URI SearchResultDone ::= [APPLICATION 5] LDAPResult Each SearchResultEntry represents an entry found during the Search. Each SearchResultReference represents an area not yet explored during - the Search. The SearchResultEntry and SearchResultReference PDUs may - come in any order. Following all the SearchResultReference and + the Search. The SearchResultEntry and SearchResultReference messages + may come in any order. Following all the SearchResultReference and SearchResultEntry responses, the server returns a SearchResultDone response, which contains an indication of success, or detailing any errors that have occurred. Each entry returned in a SearchResultEntry will contain all appropriate attributes as specified in the attributes field of the Search Request, subject to access control and other administrative policy. Note that the PartialAttributeList may hold zero elements. This may happen when none of the attributes of an entry were requested, or could be returned. Note also that the partialAttribute @@ -1926,84 +1940,75 @@ The Start Transport Layer Security (StartTLS) operation's purpose is to initiate installation of a TLS layer. The StartTLS operation is defined using the Extended operation mechanism described in Section 4.12. Lightweight Directory Access Protocol Version 3 4.14.1. StartTLS Request A client requests TLS establishment by transmitting a StartTLS - request PDU to the server. The StartTLS request is defined in terms - of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", - and the requestValue field is always absent. + request message to the server. The StartTLS request is defined in + terms of an ExtendedRequest. The requestName is + "1.3.6.1.4.1.1466.20037", and the requestValue field is always + absent. - The client MUST NOT send any PDUs at this LDAP message layer + The client MUST NOT send any LDAP PDUs at this LDAP message layer following this request until it receives a StartTLS Extended response and, in the case of a successful response, completes TLS negotiations. Detected sequencing problems (particularly those detailed in Section 3.1.1 of [AuthMeth]) result in the resultCode being set to operationsError. If the server does not support TLS (whether by design or by current configuration), it returns with the resultCode set to protocolError as described in Section 4.12. 4.14.2. StartTLS Response When a StartTLS request is made, servers supporting the operation - MUST return a StartTLS response PDU to the requestor. The + MUST return a StartTLS response message to the requestor. The responseName, if present, is also "1.3.6.1.4.1.1466.20037". The responseValue is absent. If the server is willing and able to negotiate TLS, it returns with the resultCode set to success. Refer to Section 4 of [AuthMeth] for details. If the server is otherwise unwilling or unable to perform this operation, the server is to return an appropriate result code indicating the nature of the problem. For example, if the TLS subsystem is not presently available, the server may indicate so by returning with the resultCode set to unavailable. 4.14.3. Removal of the TLS Layer Either the client or server MAY remove the TLS layer and leave the LDAP message layer intact by sending and receiving a TLS closure alert. - The initiating protocol peer sends the TLS closure alert. If it - wishes to leave the LDAP message layer intact, it then MUST cease to - send further PDUs and MUST ignore any received LDAP PDUs until it - receives a TLS closure alert from the other peer. - - Once the initiating protocol peer receives a TLS closure alert from - the other peer it MAY send and receive LDAP PDUs. + The initiating protocol peer sends the TLS closure alert and MUST + wait until it receives a TLS closure alert from the other peer before + sending further LDAP PDUs. Lightweight Directory Access Protocol Version 3 When a protocol peer receives the initial TLS closure alert, it may choose to allow the LDAP message layer to remain intact. In this case, it MUST immediately transmit a TLS closure alert. Following this, it MAY send and receive LDAP PDUs. Protocol peers MAY terminate the LDAP session after sending or receiving a TLS closure alert. - After the TLS layer has been removed, the server MUST NOT send - responses to any request message received before the TLS closure - alert. Thus, clients wishing to receive responses to messages sent - while the TLS layer is intact MUST wait for those message responses - before sending the TLS closure alert. - 5. Protocol Encoding, Connection, and Transfer This protocol is designed to run over connection-oriented, reliable transports, where the data stream is divided into octets (8-bit units), with each octet and each bit being significant. One underlying service, LDAP over TCP, is defined in Section 5.2. This service is generally applicable to applications providing or consuming X.500-based directory services on the Internet. This specification was generally written with the TCP mapping in mind. @@ -2021,32 +2026,33 @@ +----------------------+ > LDAP PDUs +----------------------+ < data | SASL layer | +----------------------+ > SASL-protected data +----------------------+ < data | TLS layer | Application +----------------------+ > TLS-protected data ------------+----------------------+ < data Transport | transport connection | +----------------------+ - Lightweight Directory Access Protocol Version 3 5.1. Protocol Encoding The protocol elements of LDAP SHALL be encoded for exchange using the Basic Encoding Rules [BER] of [ASN.1] with the following restrictions: - Only the definite form of length encoding is used. - OCTET STRING values are encoded in the primitive form only. + Lightweight Directory Access Protocol Version 3 + - If the value of a BOOLEAN type is true, the encoding of the value octet is set to hex "FF". - If a value of a type is its default value, it is absent. Only some BOOLEAN and INTEGER types have default values in this protocol definition. These restrictions are meant to ease the overhead of encoding and decoding certain elements in BER. @@ -2060,72 +2066,82 @@ bytestream using the BER-based encoding described in Section 5.1. It is recommended that server implementations running over the TCP provide a protocol listener on the Internet Assigned Numbers Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port. 5.3. Termination of the LDAP session Termination of the LDAP session is typically initiated by the client - sending an UnbindRequst (Section 4.3), or by the server sending a + sending an UnbindRequest (Section 4.3), or by the server sending a Notice of Disconnection (Section 4.4.1). In these cases each protocol peer gracefully terminates the LDAP session by ceasing exchanges at the LDAP message layer, tearing down any SASL layer, tearing down any TLS layer, and closing the transport connection. A protocol peer may determine that the continuation of any communication would be pernicious, and in this case may abruptly terminate the session by ceasing communication and closing the transport connection. In either case, when the LDAP session is terminated, uncompleted operations are handled as specified in Section 3.1. - Lightweight Directory Access Protocol Version 3 - 6. Security Considerations This version of the protocol provides facilities for simple authentication using a cleartext password, as well as any [SASL] mechanism. Installing SASL and/or TLS layers can provide integrity and other data security services. It is also permitted that the server can return its credentials to the client, if it chooses to do so. + Lightweight Directory Access Protocol Version 3 + Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties. Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [AuthMeth]. Security considerations for authentication methods, SASL mechanisms, and TLS are described in [AuthMeth]. It should be noted that SASL authentication exchanges do not provide data confidentiality nor integrity protection for the version or name fields of the BindRequest nor the resultCode, diagnosticMessage, or referral fields of the BindResponse nor of any information contained in controls attached to Bind requests or responses. Thus information contained in these fields SHOULD NOT be relied on unless otherwise protected (such as by establishing protections at the transport layer). - Server implementors should plan for the possibility of (protocol or - external) events which alter the information used to establish - security factors (e.g., credentials, authorization identities, access - controls) during the course of the LDAP session, and even during the - performance of a particular operation, and should take steps to avoid - insecure side effects of these changes. The ways in which these - issues are addressed are application and/or implementation specific. + Implementors should note that various security factors, including + authentication and authorization information and data security + services may change during the course of the LDAP session, or even + during the performance of a particular operation. For instance, + credentials could expire, authorization identities or access controls + could change, or the underlying security layer(s) could be replaced + or terminated. Implementations should be robust in the handling of + changing security factors. + In some cases, it may be appropriate to continue the operation even + in light of security factor changes. For instance, it may be + appropriate to continue an Abandon operation regardless of the + change, or to continue an operation when the change upgraded (or + maintained) the security factor. In other cases, it may be + appropriate to fail, or alter the processing of the operation. For + instance, if confidential protections were removed, it would be + appropriate to either fail a request to return sensitive data, or + minimally, to exclude the return of sensitive data. Implementations which cache attributes and entries obtained via LDAP MUST ensure that access controls are maintained if that information is to be provided to multiple clients, since servers may have access control policies which prevent the return of entries or attributes in Search results except to particular authenticated clients. For example, caches could serve result information only to the client whose request caused it to be in the cache. Servers may return referrals or Search result references which @@ -2170,21 +2186,22 @@ It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga. RFC 3771 was an individual submission to the IETF. This document is a product of the IETF LDAPBIS Working Group. Significant contributors of technical review and content include Kurt Zeilenga, Steven Legg, and Hallvard Furuseth. 8. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. + Specifications: ABNF", draft-crocker-abnf-rfc2234bis- + xx.txt, (a work in progress). [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation" [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth- xx.txt, (a work in progress). Lightweight Directory Access Protocol Version 3 @@ -2282,21 +2299,22 @@ dapv3/> [PortReg] IANA, "Port Numbers", http://www.iana.org/assignments/port-numbers 10. IANA Considerations It is requested that the Internet Assigned Numbers Authority (IANA) update the LDAP result code registry to indicate that this document provides the definitive technical specification for result codes 0- - 36, 48-54, 64-70, 80-90. + 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value + (strongAuthRequired) has been renamed (to strongerAuthRequired). It is requested that the IANA update the LDAP Protocol Mechanism registry to indicate that this document and [AuthMeth] provides the definitive technical specification for the StartTLS (1.3.6.1.4.1.1466.20037) Extended operation. Lightweight Directory Access Protocol Version 3 It is requested that the IANA update the occurrence of "RFC XXXX" in Appendix B with this RFC number at publication. @@ -2544,21 +2562,21 @@ other (80) Indicates the server has encountered an internal error. Lightweight Directory Access Protocol Version 3 Appendix B - Complete ASN.1 Definition This appendix is normative. Lightweight-Directory-Access-Protocol-V3 - -- Copyright (C) The Internet Society (2004). This version of + -- Copyright (C) The Internet Society (2005). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. DEFINITIONS IMPLICIT TAGS EXTENSIBILITY IMPLIED ::= BEGIN LDAPMessage ::= SEQUENCE { messageID MessageID, @@ -2930,20 +2948,24 @@ C.1.11 Section 4.1.12 (Controls) - Specified how control values defined in terms of ASN.1 are to be encoded. Lightweight Directory Access Protocol Version 3 - Noted that the criticality field is only applied to request messages (except UnbindRequest), and must be ignored when present on response messages and UnbindRequest. + - Specified that non-critical controls may be ignored at the + server's discretion. There was confusion in the original wording + which led some to believe that recognized controls may not be + ignored as long as they were associated with a proper request. - Added language regarding combinations of controls and the ordering of controls on a message. - Specified that when the semantics of the combination of controls is undefined or unknown, it results in a protocolError. - Changed "The server MUST be prepared" to "Implementations MUST be prepared" in the eighth paragraph to reflect that both client and server implementations must be able to handle this (as both parse controls). C.1.12 Section 4.2 (Bind Operation) @@ -2972,28 +2994,27 @@ If there are dependencies between multiple negotiations of a particular SASL mechanism, the technical specification for that SASL mechanism details how applications are to deal with them. LDAP should not require any special handling. - Dropped MUST imperative in paragraph 3 to align with [Keywords]. - Mandated that clients not send non-Bind operations while a Bind is in progress, and suggested that servers not process them if they are received. This is needed to ensure proper sequencing of the Bind in relationship to other operations. + Lightweight Directory Access Protocol Version 3 + C.1.14 Section 4.2.3 (Bind Response) - Moved most error-related text to Appendix A, and added text regarding certain errors used in conjunction with the Bind operation. - - Lightweight Directory Access Protocol Version 3 - - Prohibited the server from specifying serverSaslCreds when not appropriate. C.1.15 Section 4.3 (Unbind Operation) - Specified that both peers are to cease transmission and terminate the LDAP session for the Unbind operation. C.1.16 Section 4.4 (Unsolicited Notification) @@ -3003,45 +3024,49 @@ C.1.17 Section 4.5.1 (Search Request) - SearchRequest attributes is now defined as an AttributeSelection type rather than AttributeDescriptionList, and an ABNF is provided. - SearchRequest attributes may contain duplicate attribute descriptions. This was previously prohibited. Now servers are instructed to ignore subsequent names when they are duplicated. This was relaxed in order to allow different short names and also OIDs to be requested for an attribute. + - The present search filter now evaluates to Undefined when the + specified attribute is not known to the server. It used to + evaluate to FALSE, which caused behavior inconsistent with what + most would expect, especially when the not operator was used. - The Filter choice SubstringFilter substrings type is now defined with a lower bound of 1. - The SubstringFilter substrings 'initial, 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added imperatives stating that 'initial' (if present) must be listed first, and 'final' (if present) must be listed last. - Disambiguated the semantics of the derefAliases choices. There was question as to whether derefInSearching applied to the base object in a wholeSubtree Search. - Added instructions for equalityMatch, substrings, greaterOrEqual, lessOrEqual, and approxMatch. C.1.18 Section 4.5.2 (Search Result) - Recommended that servers not use attribute short names when it knows they are ambiguous or may cause interoperability problems. - Removed all mention of ExtendedResponse due to lack of implementation. + Lightweight Directory Access Protocol Version 3 + C.1.19 Section 4.5.3 (Continuation References in the Search Result) - Made changes similar to those made to Section 4.1.11. - Lightweight Directory Access Protocol Version 3 - C.1.20 Section 4.5.3.1 (Example) - Fixed examples to adhere to changes made to Section 4.5.3. C.1.21 Section 4.6 (Modify Operation) - Replaced AttributeTypeAndValues with Attribute as they are equivalent. - Specified the types of modification changes which might temporarily violate schema. Some readers were under the impression @@ -3071,84 +3096,83 @@ C.1.24 Section 4.10 (Compare Operation) - Specified that compareFalse means that the Compare took place and the result is false. There was confusion which lead people to believe that an Undefined match resulted in compareFalse. - Required servers to not dereference aliases for Compare. This was added for consistency with other operations and to help ensure data consistency. + Lightweight Directory Access Protocol Version 3 + C.1.25 Section 4.11 (Abandon Operation) - Explained that since Abandon returns no response, clients should not use it if they need to know the outcome. - Specified that Abandon and Unbind cannot be abandoned. - Lightweight Directory Access Protocol Version 3 - C.1.26 Section 4.12 (Extended Operation) - Specified how values of Extended operations defined in terms of ASN.1 are to be encoded. - Added instructions on what Extended operation specifications consist of. - Added a recommendation that servers advertise supported Extended operations. C.1.27 Section 5.2 (Transfer Protocols) - Moved referral-specific instructions into referral-related sections. C.1.28 Section 7 (Security Considerations) - Reworded notes regarding SASL not protecting certain aspects of - the LDAP Bind PDUs. + the LDAP Bind messages. - Noted that Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [AuthMeth]. - - Added a note regarding the scenario where an identity is changed - (deleted, privileges or credentials modified, etc.). + - Added a note regarding the possibility of changes to security + factors (authentication, authorization, data confidentiality). - Warned against following referrals that may have been injected in the data stream. - Noted that servers should protect information equally, whether in an error condition or not, and mentioned specifically; matchedDN, diagnosticMessage, and resultCodes. - Added a note regarding malformed and long encodings. C.1.29 Appendix A (Complete ASN.1 Definition) - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - Removed AttributeType. It is not used. C.2 Changes made to RFC 2830: This section summarizes the substantive changes made to Sections of RFC 2830. Readers should consult [AuthMeth] for summaries of changes to other sections. + Lightweight Directory Access Protocol Version 3 + C.2.1 Section 2.3 (Response other than "success") - Removed wording indicating that referrals can be returned from StartTLS. - Removed requirement that only a narrow set of result codes can be returned. Some result codes are required in certain scenarios, but any other may be returned if appropriate. - Lightweight Directory Access Protocol Version 3 - C.2.1 Section 4 (Closing a TLS Connection) - - Reworded most of this section and added the requirement that after - the TLS connection has been closed, the server MUST NOT send - responses to any request message received before the TLS closure. + - Reworded most of this section to align with definitions of the + LDAP protocol layers. - Removed instructions on abrupt closure as this is covered in other areas of the document (specifically, Section 5.3) C.3 Changes made to RFC 3771: - Rewrote to fit into this document. In general, semantics were preserved. Supporting and background language seen as redundant due to its presence in this document was omitted. - Specified that Intermediate responses to a request may be of different types, and one of the response types may be specified to @@ -3185,18 +3209,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.