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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/