Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-29.txt Feb 2005
+Document: draft-ietf-ldapbis-protocol-31.txt May 2005
Obsoletes: RFCs 2251, 2830, 3771
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
The list of Internet-Draft Shadow Directories can be accessed at
<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
LDAP Revision Working Group (LDAPbis) mailing list <ietf-
Copyright Notice
- Copyright (C) The Internet Society 2004. All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Protocol (DAP).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 1
+Sermersheim Internet-Draft - Expires Nov 2005 Page 1
\f
Lightweight Directory Access Protocol Version 3
1.1. Relationship to Other LDAP Specifications.....................3
2. Conventions.....................................................3
3. Protocol Model..................................................4
- 3.1 Operation and LDAP Message Layer Relationship..................4
+ 3.1 Operation and LDAP Message Layer Relationship..................5
4. Elements of Protocol............................................5
4.1. Common Elements...............................................5
4.1.1. Message Envelope............................................5
4.1.8. Matching Rule Identifier....................................9
4.1.9. Result Message..............................................9
4.1.10. Referral..................................................11
- 4.1.11. Controls..................................................12
+ 4.1.11. Controls..................................................13
4.2. Bind Operation...............................................14
4.3. Unbind Operation.............................................17
4.4. Unsolicited Notification.....................................17
- 4.6. Modify Operation.............................................28
- 4.7. Add Operation................................................29
- 4.8. Delete Operation.............................................30
- 4.9. Modify DN Operation..........................................31
- 4.10. Compare Operation...........................................32
- 4.11. Abandon Operation...........................................33
- 4.12. Extended Operation..........................................34
- 4.13. IntermediateResponse Message................................35
- 4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse......36
- 4.13.2. Usage with LDAP Request Controls..........................36
- 4.14. StartTLS Operation..........................................36
- 5. Protocol Encoding, Connection, and Transfer....................38
- 5.1. Protocol Encoding............................................38
- 5.2. Transmission Control Protocol (TCP)..........................39
- 5.3. Termination of the LDAP session..............................39
- 6. Security Considerations........................................39
- 7. Acknowledgements...............................................41
- 8. Normative References...........................................41
- 9. Informative References.........................................43
- 10. IANA Considerations...........................................43
- 11. Editor's Address..............................................43
- Appendix A - LDAP Result Codes....................................45
- A.1 Non-Error Result Codes........................................45
- A.2 Result Codes..................................................45
- Appendix B - Complete ASN.1 Definition............................50
- Appendix C - Changes..............................................56
- C.1 Changes made to RFC 2251:.....................................56
- C.2 Changes made to RFC 2830:.....................................61
- C.3 Changes made to RFC 3771:.....................................62
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 2
+ 4.5. Search Operation.............................................18
+ 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............................................39
+ 5.2. Transmission Control Protocol (TCP)..........................40
+ 5.3. Termination of the LDAP session..............................40
+ 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
+ C.1 Changes made to RFC 2251:.....................................57
+ C.2 Changes made to RFC 2830:.....................................62
+ C.3 Changes made to RFC 3771:.....................................63
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 2
\f
Lightweight Directory Access Protocol Version 3
-
1. Introduction
The Directory is "a collection of open systems cooperating to provide
[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.
Information on the Unicode character encoding model can be found in
[CharModel].
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 3
+Sermersheim Internet-Draft - Expires Nov 2005 Page 3
\f
Lightweight Directory Access Protocol Version 3
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
implementations acting as a gateway to X.500 directories may need to
make multiple DAP requests to service a single LDAP request.
-
-3.1 Operation and LDAP Message Layer Relationship
-
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 4
+Sermersheim Internet-Draft - Expires Nov 2005 Page 4
\f
Lightweight Directory Access Protocol Version 3
+
+3.1 Operation and LDAP Message Layer Relationship
+
Protocol operations are exchanged at the LDAP message layer. When the
transport connection is closed, any uncompleted operations at the
LDAP message layer, when possible, are abandoned, and when not
encapsulated in a common envelope, the LDAPMessage, which is defined
as follows:
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 5
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 5
-\f
- Lightweight Directory Access Protocol Version 3
-
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
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.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 6
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.1.1.1. Message ID
All LDAPMessage envelopes encapsulating responses contain the
The message ID of a request MUST have a non-zero value different from
the messageID of any other request in progress in the same LDAP
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 6
-\f
- Lightweight Directory Access Protocol Version 3
-
session. The zero value is reserved for the unsolicited notification
message.
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 7
+\f
+ Lightweight Directory Access Protocol Version 3
+
A RelativeLDAPDN is defined to be the representation of a Relative
Distinguished Name (RDN) after encoding according to the
RelativeLDAPDN ::= LDAPString
-- Constrained to <name-component> [LDAPDN]
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 7
-\f
- Lightweight Directory Access Protocol Version 3
-
4.1.4. Attribute Descriptions
value suitable for that type. Elements of this type are typically
used to assert that the value in assertionValue matches a value of an
attribute.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 8
+\f
+ Lightweight Directory Access Protocol Version 3
+
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
AssertionValue ::= OCTET STRING
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 8
-\f
- Lightweight Directory Access Protocol Version 3
-
The syntax of the AssertionValue depends on the context of the LDAP
operation being performed. For example, the syntax of the EQUALITY
matching rule for an attribute is used when performing a Compare
in LDAPResult to indicate the final status of the protocol operation
request.
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 9
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 9
-\f
- Lightweight Directory Access Protocol Version 3
-
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 10
+\f
+ Lightweight Directory Access Protocol Version 3
+
The resultCode enumeration is extensible as defined in Section 3.6 of
[LDAPIANA]. The meanings of the listed result codes are given in
Appendix A. If a server detects multiple errors for an operation,
The diagnosticMessage field of this construct may, at the server's
option, be used to return a string containing a textual, human-
readable (terminal control and page formatting characters should be
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 10
-\f
- Lightweight Directory Access Protocol Version 3
-
avoided) diagnostic message. As this diagnostic message is not
standardized, implementations MUST NOT rely on the values returned.
Diagnostic messages typically supplement the resultCode with
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 11
+\f
+ Lightweight Directory Access Protocol Version 3
+
URI ::= LDAPString -- limited to characters permitted in
-- URIs
Clients that follow referrals MUST ensure that they do not loop
between servers. They MUST NOT repeatedly contact the same server for
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 11
-\f
- Lightweight Directory Access Protocol Version 3
-
the same request with the same parameters. Some clients use a counter
that is incremented each time referral handling occurs for an
operation, and these kinds of clients MUST be able to handle at least
URIs is left to future specifications. Clients may ignore URIs that
they do not support.
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 12
+\f
+ Lightweight Directory Access Protocol Version 3
+
UTF-8 encoded characters appearing in the string representation of a
DN, search filter, or other fields of the referral value may not be
legal for URIs (e.g. spaces) and MUST be escaped using the % method
existing LDAP operations may be extended. One or more controls may be
attached to a single LDAP message. A control only affects the
semantics of the message it is attached to.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 12
-\f
- Lightweight Directory Access Protocol Version 3
-
Controls sent by clients are termed 'request controls' and those sent
by servers are termed 'response controls'.
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 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 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 FALSE,
- the server MUST ignore the control.
+ - 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.
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 13
+\f
+ 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
the 'supportedControl' attribute in the root DSE (Section 5.1 of
[Models]).
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 13
-\f
- Lightweight Directory Access Protocol Version 3
-
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
4.2. Bind Operation
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 14
+\f
+ 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.
sasl [3] SaslCredentials,
... }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 14
-\f
- Lightweight Directory Access Protocol Version 3
-
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
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.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 15
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.2.1. Processing of the Bind Request
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
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 15
-\f
- Lightweight Directory Access Protocol Version 3
-
- 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
BindResponse consists simply of an indication from the server of the
status of the client's request for authentication.
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 16
+\f
+ Lightweight Directory Access Protocol Version 3
+
A successful Bind operation is indicated by a BindResponse with a
resultCode set to success. Otherwise, an appropriate result code is
set in the BindResponse. For BindResponse, the protocolError result
mechanism to allow the client to authenticate the server to which it
is communicating, or to perform "challenge-response" authentication.
If the client bound with the simple choice, or the SASL mechanism
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 16
-\f
- Lightweight Directory Access Protocol Version 3
-
does not require the server to return information to the client, then
this field SHALL NOT be included in the BindResponse.
notification is of an advisory nature, and the server will not expect
any response to be returned from the client.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 17
+\f
+ Lightweight Directory Access Protocol Version 3
+
The unsolicited notification is structured as an LDAPMessage in which
the messageID is zero and protocolOp is set to the extendedResp
choice using the ExtendedResponse type (See Section 4.12). The
4.4.1. Notice of Disconnection
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 17
-\f
- Lightweight Directory Access Protocol Version 3
-
This notification may be used by the server to advise the client that
the server is about to terminate the LDAP session on its own
initiative. This notification is intended to assist clients in
4.5.1. Search Request
The Search request is defined as follows:
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 18
+\f
+ Lightweight Directory Access Protocol Version 3
+
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.7
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 18
-\f
- Lightweight Directory Access Protocol Version 3
-
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 19
+\f
+ Lightweight Directory Access Protocol Version 3
+
Note that an X.500 "list"-like operation can be emulated by the
client requesting a singleLevel Search operation with a filter
checking for the presence of the 'objectClass' attribute, and that an
singleLevel: The scope is constrained to the immediate
subordinates of the entry named by baseObject.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 19
-\f
- Lightweight Directory Access Protocol Version 3
-
wholeSubtree: the scope is constrained to the entry named by the
baseObject, and all its subordinates.
neverDerefAliases: Do not dereference aliases in searching or in
locating the base object of the Search.
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 20
+\f
+ Lightweight Directory Access Protocol Version 3
+
derefInSearching: While searching subordinates of the base object,
dereference any alias within the search scope. Dereferenced
objects become the vertices of further search scopes where the
a Search. A value of zero in this field indicates that no client-
requested time limit restrictions are in effect for the Search.
Servers may also enforce a maximum time limit for the Search.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 20
-\f
- Lightweight Directory Access Protocol Version 3
-
4.5.1.6 SearchRequest.typesOnly
attribute descriptions and values to be returned.
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 21
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.5.1.7 SearchRequest.filter
A filter that defines the conditions that must be fulfilled in order
the server or is not valid for the attribute type.
- The type of filtering requested is not implemented.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 21
-\f
- Lightweight Directory Access Protocol Version 3
-
- The assertion value is invalid.
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].
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 22
+\f
+ 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
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,
-
+ 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.
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 22
+Sermersheim Internet-Draft - Expires Nov 2005 Page 23
\f
Lightweight Directory Access Protocol Version 3
- and FALSE otherwise (including a presence test with an unrecognized
- attribute description).
-
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.
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
-Sermersheim Internet-Draft - Expires Aug 2005 Page 23
+Sermersheim Internet-Draft - Expires Nov 2005 Page 24
\f
Lightweight Directory Access Protocol Version 3
- attributeSelector = attributedescription / selectorspecial
selectorspecial = noattrs / alluserattrs
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 24
+Sermersheim Internet-Draft - Expires Nov 2005 Page 25
\f
Lightweight Directory Access Protocol Version 3
-
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
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.
noSuchObject result code (depending on the server's knowledge of the
entry named in the baseObject).
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 25
+Sermersheim Internet-Draft - Expires Nov 2005 Page 26
\f
Lightweight Directory Access Protocol Version 3
SearchResultReference.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 26
+Sermersheim Internet-Draft - Expires Nov 2005 Page 27
\f
Lightweight Directory Access Protocol Version 3
Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
requested to the contacted server, it may return the following:
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??base
- ldap://hostc/OU=People,DC=Example,DC=NET??base }
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 27
+Sermersheim Internet-Draft - Expires Nov 2005 Page 28
\f
Lightweight Directory Access Protocol Version 3
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
SearchResultReference {
ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
SearchResultDone (success)
modification. The values of this field have the following
semantics respectively:
- add: add values listed to the modification attribute,
- creating the attribute if necessary;
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 28
+Sermersheim Internet-Draft - Expires Nov 2005 Page 29
\f
Lightweight Directory Access Protocol Version 3
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary;
+
delete: delete values listed from the modification attribute.
If no values are listed, or if all current values of the
attribute are listed, the entire attribute is removed;
change. If successful, the final effect of the operations on the
entry MUST be identical.
-
-4.7. Add Operation
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 29
+Sermersheim Internet-Draft - Expires Nov 2005 Page 30
\f
Lightweight Directory Access Protocol Version 3
+
+4.7. Add Operation
+
The Add operation allows a client to request the addition of an entry
into the Directory. The Add Request is defined as follows:
entry from the Directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 30
+Sermersheim Internet-Draft - Expires Nov 2005 Page 31
\f
Lightweight Directory Access Protocol Version 3
+
The Delete Request consists of the name of the entry to be deleted.
The server SHALL NOT dereference aliases while resolving the name of
the target entry to be removed.
the name change and return the result in the Modify DN Response,
defined as follows:
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-Sermersheim Internet-Draft - Expires Aug 2005 Page 31
+Sermersheim Internet-Draft - Expires Nov 2005 Page 32
\f
Lightweight Directory Access Protocol Version 3
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
For example, if the entry named in the entry field was <cn=John
Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
Upon receipt of a Compare Request, a server will attempt to perform
the requested comparison and return the result in the Compare
Response, defined as follows:
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 32
+Sermersheim Internet-Draft - Expires Nov 2005 Page 33
\f
Lightweight Directory Access Protocol Version 3
+
CompareResponse ::= [APPLICATION 15] LDAPResult
The resultCode is set to compareTrue, compareFalse, or an appropriate
operations it has abandoned (since these may have been in transit
when the Abandon was requested, or are not able to be abandoned).
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 33
+Sermersheim Internet-Draft - Expires Nov 2005 Page 34
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 34
+Sermersheim Internet-Draft - Expires Nov 2005 Page 35
\f
Lightweight Directory Access Protocol Version 3
- the format of the contents of the responseValue (if any), and
-Sermersheim Internet-Draft - Expires Aug 2005 Page 35
+Sermersheim Internet-Draft - Expires Nov 2005 Page 36
\f
Lightweight Directory Access Protocol Version 3
4.12.
-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
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 36
+Sermersheim Internet-Draft - Expires Nov 2005 Page 37
\f
Lightweight Directory Access Protocol Version 3
- of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
- and the requestValue field is always absent.
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ 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.
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.
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.
+ 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.
- Once the initiating protocol peer receives a TLS closure alert from
- the other peer it MAY send and receive LDAP PDUs.
-
- When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the LDAP message layer to remain intact. In this
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 37
+Sermersheim Internet-Draft - Expires Nov 2005 Page 38
\f
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
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.
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 38
+Sermersheim Internet-Draft - Expires Nov 2005 Page 39
\f
Lightweight Directory Access Protocol Version 3
-
- - OCTET STRING values are encoded in the primitive form only.
-
- If the value of a BOOLEAN type is true, the encoding of the value
octet is set to hex "FF".
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
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.
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 39
+Sermersheim Internet-Draft - Expires Nov 2005 Page 40
\f
Lightweight Directory Access Protocol Version 3
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
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.
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.
+ layer).
+
+ 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
confidentiality measures are not in place. Clients are advised to
reject referrals from the StartTLS operation.
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 41
+\f
+ Lightweight Directory Access Protocol Version 3
+
The matchedDN and diagnosticMessage fields, as well as some
resultCode values (e.g., attributeOrValueExists and
entryAlreadyExists), could disclose the presence or absence of
access to protected information equally under both normal and error
conditions.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 40
-\f
- Lightweight Directory Access Protocol Version 3
-
Protocol peers MUST be prepared to handle invalid and arbitrary
length protocol encodings. Invalid protocol encodings include: BER
encoding exceptions, format string and UTF-8 encoding exceptions,
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
Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
xx.txt, (a work in progress).
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 42
+\f
+ Lightweight Directory Access Protocol Version 3
+
[BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
"Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
[IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
September 1981
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 41
-\f
- Lightweight Directory Access Protocol Version 3
-
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 43
+\f
+ Lightweight Directory Access Protocol Version 3
+
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 42
-\f
- Lightweight Directory Access Protocol Version 3
-
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
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.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 44
+\f
+ 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.
Jim Sermersheim
Novell, Inc.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 43
-\f
- Lightweight Directory Access Protocol Version 3
-
1800 South Novell Place
Provo, Utah 84606, USA
jimse@novell.com
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 44
+Sermersheim Internet-Draft - Expires Nov 2005 Page 45
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 45
+Sermersheim Internet-Draft - Expires Nov 2005 Page 46
\f
Lightweight Directory Access Protocol Version 3
Indicates a critical control is unrecognized (see Section
4.1.11).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 46
+Sermersheim Internet-Draft - Expires Nov 2005 Page 47
\f
Lightweight Directory Access Protocol Version 3
not conform to the required syntax or contains attribute
values which do not conform to the syntax of the attribute's
type.
-
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 47
+Sermersheim Internet-Draft - Expires Nov 2005 Page 48
\f
Lightweight Directory Access Protocol Version 3
+
aliasDereferencingProblem (36)
Indicates that a problem occurred while dereferencing an
alias. Typically an alias was encountered in a situation
entryAlreadyExists (68)
Indicates that the request cannot be fulfilled (added, moved,
or renamed) as the target entry already exists.
-
- objectClassModsProhibited (69)
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 48
+Sermersheim Internet-Draft - Expires Nov 2005 Page 49
\f
Lightweight Directory Access Protocol Version 3
+
+ objectClassModsProhibited (69)
Indicates that an attempt to modify the object class(es) of
an entry's 'objectClass' attribute is prohibited.
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 49
+Sermersheim Internet-Draft - Expires Nov 2005 Page 50
\f
Lightweight Directory Access Protocol Version 3
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
LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-- [LDAPDN]
- RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 50
+Sermersheim Internet-Draft - Expires Nov 2005 Page 51
\f
Lightweight Directory Access Protocol Version 3
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-- [LDAPDN]
AttributeDescription ::= LDAPString
MatchingRuleId ::= LDAPString
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 52
+\f
+ Lightweight Directory Access Protocol Version 3
+
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 51
-\f
- Lightweight Directory Access Protocol Version 3
-
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
referral [3] Referral OPTIONAL }
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 53
+\f
+ Lightweight Directory Access Protocol Version 3
+
URI ::= LDAPString -- limited to characters permitted in
-- URIs
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 52
-\f
- Lightweight Directory Access Protocol Version 3
-
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
-- The LDAPString is constrained to
-- <attributeSelector> in Section 4.5.1.7
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 54
+\f
+ Lightweight Directory Access Protocol Version 3
+
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 53
-\f
- Lightweight Directory Access Protocol Version 3
-
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 55
+\f
+ Lightweight Directory Access Protocol Version 3
+
AttributeList ::= SEQUENCE OF attribute Attribute
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 54
-\f
- Lightweight Directory Access Protocol Version 3
-
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 55
+Sermersheim Internet-Draft - Expires Nov 2005 Page 56
\f
Lightweight Directory Access Protocol Version 3
- Required that the messageID of requests MUST be non-zero as the
zero is reserved for Notice of Disconnection.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 56
+Sermersheim Internet-Draft - Expires Nov 2005 Page 57
\f
Lightweight Directory Access Protocol Version 3
- Specified how control values defined in terms of ASN.1 are to be
encoded.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 57
+Sermersheim Internet-Draft - Expires Nov 2005 Page 58
\f
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
Bind in relationship to other operations.
-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.
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 58
+Sermersheim Internet-Draft - Expires Nov 2005 Page 59
\f
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.
- Prohibited the server from specifying serverSaslCreds when not
appropriate.
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
knows they are ambiguous or may cause interoperability problems.
- Removed all mention of ExtendedResponse due to lack of
implementation.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 60
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.1.19 Section 4.5.3 (Continuation References in the Search Result)
C.1.20 Section 4.5.3.1 (Example)
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 59
-\f
- Lightweight Directory Access Protocol Version 3
-
- Fixed examples to adhere to changes made to Section 4.5.3.
added for consistency with other operations and to help ensure
data consistency.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 61
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.1.25 Section 4.11 (Abandon Operation)
C.1.26 Section 4.12 (Extended Operation)
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 60
-\f
- Lightweight Directory Access Protocol Version 3
-
- Specified how values of Extended operations defined in terms of
ASN.1 are to be encoded.
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
to other sections.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 62
+\f
+ 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
any other may be returned if appropriate.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 61
-\f
- 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)
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 62
+Sermersheim Internet-Draft - Expires Nov 2005 Page 63
\f
Lightweight Directory Access Protocol Version 3
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.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 63
-\f
+Sermersheim Internet-Draft - Expires Nov 2005 Page 64
+\f
\ No newline at end of file
projects / openldap / blobdiff