draft-ietf-ldapbis-protocol-19.txt | draft-ietf-ldapbis-protocol-20.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-19.txt Dec 2003 | Document: draft-ietf-ldapbis-protocol-20.txt Jan 2004 | |||
Obsoletes: RFC 2251, 2830 | Obsoletes: RFC 2251, 2830 | |||
LDAP: The Protocol | LDAP: The Protocol | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
skipping to change at line 53 | skipping to change at line 53 | |||
1. Introduction....................................................2 | 1. Introduction....................................................2 | |||
1.1. Relationship to Obsolete Specifications.......................3 | 1.1. Relationship to Obsolete Specifications.......................3 | |||
2. Conventions.....................................................3 | 2. Conventions.....................................................3 | |||
3. Protocol Model..................................................3 | 3. Protocol Model..................................................3 | |||
4. Elements of Protocol............................................4 | 4. Elements of Protocol............................................4 | |||
4.1. Common Elements...............................................4 | 4.1. Common Elements...............................................4 | |||
4.1.1. Message Envelope............................................4 | 4.1.1. Message Envelope............................................4 | |||
4.1.2. String Types................................................6 | 4.1.2. String Types................................................6 | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 1 | Sermersheim Internet-Draft - Expires Jul 2004 Page 1 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
4.1.3. Distinguished Name and Relative Distinguished Name..........6 | 4.1.3. Distinguished Name and Relative Distinguished Name..........6 | |||
4.1.4. Attribute Descriptions......................................7 | 4.1.4. Attribute Descriptions......................................7 | |||
4.1.5. Attribute Value.............................................7 | 4.1.5. Attribute Value.............................................7 | |||
4.1.6. Attribute Value Assertion...................................7 | 4.1.6. Attribute Value Assertion...................................7 | |||
4.1.7. Attribute and PartialAttribute..............................8 | 4.1.7. Attribute and PartialAttribute..............................8 | |||
4.1.8. Matching Rule Identifier....................................8 | 4.1.8. Matching Rule Identifier....................................8 | |||
4.1.9. Result Message..............................................8 | 4.1.9. Result Message..............................................8 | |||
4.1.10. Referral..................................................10 | 4.1.10. Referral..................................................10 | |||
4.1.11. Controls..................................................11 | 4.1.11. Controls..................................................11 | |||
4.2. Bind Operation...............................................12 | 4.2. Bind Operation...............................................12 | |||
4.3. Unbind Operation.............................................15 | 4.3. Unbind Operation.............................................15 | |||
4.4. Unsolicited Notification.....................................16 | 4.4. Unsolicited Notification.....................................15 | |||
4.5. Search Operation.............................................17 | 4.5. Search Operation.............................................17 | |||
4.6. Modify Operation.............................................25 | 4.6. Modify Operation.............................................25 | |||
4.7. Add Operation................................................26 | 4.7. Add Operation................................................27 | |||
4.8. Delete Operation.............................................27 | 4.8. Delete Operation.............................................28 | |||
4.9. Modify DN Operation..........................................28 | 4.9. Modify DN Operation..........................................28 | |||
4.10. Compare Operation...........................................29 | 4.10. Compare Operation...........................................29 | |||
4.11. Abandon Operation...........................................30 | 4.11. Abandon Operation...........................................30 | |||
4.12. Extended Operation..........................................30 | 4.12. Extended Operation..........................................31 | |||
4.13. StartTLS Operation..........................................31 | 4.13. StartTLS Operation..........................................32 | |||
5. Protocol Element Encodings and Transfer........................33 | 5. Protocol Element Encodings and Transfer........................34 | |||
5.1. Protocol Encoding............................................34 | 5.1. Protocol Encoding............................................34 | |||
5.2. Transfer Protocols...........................................34 | 5.2. Transfer Protocols...........................................35 | |||
6. Security Considerations........................................34 | 6. Security Considerations........................................35 | |||
7. Acknowledgements...............................................36 | 7. Acknowledgements...............................................36 | |||
8. Normative References...........................................36 | 8. Normative References...........................................36 | |||
9. Informative References.........................................37 | 9. Informative References.........................................38 | |||
10. IANA Considerations...........................................37 | 10. IANA Considerations...........................................38 | |||
11. Editor's Address..............................................38 | 11. Editor's Address..............................................38 | |||
Appendix A - LDAP Result Codes....................................39 | Appendix A - LDAP Result Codes....................................39 | |||
A.1 Non-Error Result Codes........................................39 | A.1 Non-Error Result Codes........................................39 | |||
A.2 Result Codes..................................................39 | A.2 Result Codes..................................................39 | |||
Appendix B - Complete ASN.1 Definition............................43 | Appendix B - Complete ASN.1 Definition............................43 | |||
Appendix C - Changes..............................................48 | Appendix C - Changes..............................................49 | |||
C.1 Changes made to made to RFC 2251:.............................48 | C.1 Changes made to made to RFC 2251:.............................49 | |||
C.2 Changes made to made to RFC 2830:.............................53 | C.2 Changes made to made to RFC 2830:.............................54 | |||
1. Introduction | 1. Introduction | |||
The Directory is "a collection of open systems cooperating to provide | The Directory is "a collection of open systems cooperating to provide | |||
directory services" [X.500]. A directory user, which may be a human | directory services" [X.500]. A directory user, which may be a human | |||
or other entity, accesses the Directory through a client (or | or other entity, accesses the Directory through a client (or | |||
Directory User Agent (DUA)). The client, on behalf of the directory | Directory User Agent (DUA)). The client, on behalf of the directory | |||
user, interacts with one or more servers (or Directory System Agents | user, interacts with one or more servers (or Directory System Agents | |||
(DSA)). Clients interact with servers using a directory access | (DSA)). Clients interact with servers using a directory access | |||
protocol. | protocol. | |||
This document details the protocol elements of the Lightweight | This document details the protocol elements of the Lightweight | |||
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. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 2 | Sermersheim Internet-Draft - Expires Jul 2004 Page 2 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
1.1. Relationship to Obsolete Specifications | 1.1. Relationship to Obsolete 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 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, | Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, 4.1.5.1, | |||
skipping to change at line 141 | skipping to change at line 141 | |||
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]. | |||
The terms "connection" and "LDAP connection" both refer to the | The terms "connection" and "LDAP connection" both refer to the | |||
underlying transport protocol connection between two protocol peers. | underlying transport protocol connection between two protocol peers. | |||
The term "TLS connection" refers to a TLS-protected LDAP connection. | The term "TLS connection" refers to a [TLS]-protected LDAP | |||
connection. | ||||
The terms "association" and "LDAP association" both refer to the | The terms "association" and "LDAP association" both refer to the | |||
association of the LDAP connection and its current authentication and | association of the LDAP connection and its current authentication and | |||
authorization state. | authorization state. | |||
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 | |||
performing protocol operations against servers. In this model, a | performing protocol operations against servers. In this model, a | |||
client transmits a protocol request describing the operation to be | client transmits a protocol request describing the operation to be | |||
performed to a server. The server is then responsible for performing | performed to a server. The server is then responsible for performing | |||
the necessary operation(s) in the Directory. Upon completion of the | the necessary operation(s) in the Directory. Upon completion of an | |||
operation(s), the server returns a response containing an appropriate | operation, the server typically returns a response containing | |||
result code to the requesting client. | appropriate data to the requesting client. | |||
Although servers are required to return responses whenever such | Although servers are required to return responses whenever such | |||
responses are defined in the protocol, there is no requirement for | responses are defined in the protocol, there is no requirement for | |||
synchronous behavior on the part of either clients or servers. | synchronous behavior on the part of either clients or servers. | |||
Requests and responses for multiple operations may be exchanged | Requests and responses for multiple operations generally may be | |||
between a client and server in any order, provided the client | exchanged between a client and server in any order, provided the | |||
eventually receives a response for every request that requires one. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 3 | Sermersheim Internet-Draft - Expires Jul 2004 Page 3 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
client eventually receives a response for every request that requires | ||||
one. | ||||
The core protocol operations defined in this document can be mapped | The core protocol operations defined in this document can be mapped | |||
to a subset of the X.500 (1993) Directory Abstract Service. However | to a subset of the X.500 (1993) Directory Abstract Service [X.511]. | |||
there is not a one-to-one mapping between LDAP protocol operations | However there is not a one-to-one mapping between LDAP operations and | |||
and X.500 Directory Access Protocol (DAP) operations. Server | X.500 Directory Access Protocol (DAP) operations. Server | |||
implementations acting as a gateway to X.500 directories may need to | implementations acting as a gateway to X.500 directories may need to | |||
make multiple DAP requests to service a single LDAP request. | make multiple DAP requests to service a single LDAP request. | |||
4. Elements of Protocol | 4. Elements of Protocol | |||
The LDAP protocol is described using Abstract Syntax Notation One | The protocol is described using Abstract Syntax Notation One | |||
([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding | ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding | |||
Rules ([BER]). Section 5.1 specifies how the protocol elements are | Rules ([BER]). Section 5.1 specifies how the protocol elements are | |||
encoded and transferred. | encoded and transferred. | |||
In order to support future Standards Track extensions to this | In order to support future extensions to this protocol, extensibility | |||
protocol, extensibility is implied where it is allowed (per ASN.1). | is implied where it is allowed (per ASN.1). In addition, ellipses | |||
In addition, ellipses (...) have been supplied in ASN.1 types that | (...) have been supplied in ASN.1 types that are explicitly | |||
are explicitly extensible as discussed in [LDAPIANA]. Because of the | extensible as discussed in [LDAPIANA]. Because of the implied | |||
implied extensibility, clients and servers MUST (unless otherwise | extensibility, clients and servers MUST (unless otherwise specified) | |||
specified) ignore trailing SEQUENCE components whose tags they do not | ignore trailing SEQUENCE components whose tags they do not recognize. | |||
recognize. | ||||
Changes to the LDAP protocol other than through the extension | Changes to the protocol other than through the extension mechanisms | |||
mechanisms described here require a different version number. A | described here require a different version number. A client indicates | |||
client indicates the version it is using as part of the bind request, | the version it is using as part of the bind request, described in | |||
described in Section 4.2. If a client has not sent a bind, the server | Section 4.2. If a client has not sent a bind, the server MUST assume | |||
MUST assume the client is using version 3 or later. | the client is using version 3 or later. | |||
Clients may determine the protocol versions a server supports by | Clients may determine the protocol versions a server supports by | |||
reading the supportedLDAPVersion attribute from the root DSE (DSA- | reading the 'supportedLDAPVersion' attribute from the root DSE (DSA- | |||
Specific Entry) [Models]. | Specific Entry) [Models]. | |||
4.1. Common Elements | 4.1. Common Elements | |||
This section describes the LDAPMessage envelope Protocol Data Unit | This section describes the LDAPMessage envelope Protocol Data Unit | |||
(PDU) format, as well as data type definitions, which are used in the | (PDU) format, as well as data type definitions, which are used in the | |||
protocol operations. | protocol operations. | |||
4.1.1. Message Envelope | 4.1.1. Message Envelope | |||
For the purposes of protocol exchanges, all protocol operations are | For the purposes of protocol exchanges, all protocol operations are | |||
encapsulated in a common envelope, the LDAPMessage, which is defined | encapsulated in a common envelope, the LDAPMessage, which is defined | |||
as follows: | as follows: | |||
LDAPMessage ::= SEQUENCE { | LDAPMessage ::= SEQUENCE { | |||
messageID MessageID, | messageID MessageID, | |||
protocolOp CHOICE { | protocolOp CHOICE { | |||
bindRequest BindRequest, | bindRequest BindRequest, | |||
bindResponse BindResponse, | bindResponse BindResponse, | |||
unbindRequest UnbindRequest, | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 4 | Sermersheim Internet-Draft - Expires Jul 2004 Page 4 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
unbindRequest UnbindRequest, | ||||
searchRequest SearchRequest, | searchRequest SearchRequest, | |||
searchResEntry SearchResultEntry, | searchResEntry SearchResultEntry, | |||
searchResDone SearchResultDone, | searchResDone SearchResultDone, | |||
searchResRef SearchResultReference, | searchResRef SearchResultReference, | |||
modifyRequest ModifyRequest, | modifyRequest ModifyRequest, | |||
modifyResponse ModifyResponse, | modifyResponse ModifyResponse, | |||
addRequest AddRequest, | addRequest AddRequest, | |||
addResponse AddResponse, | addResponse AddResponse, | |||
delRequest DelRequest, | delRequest DelRequest, | |||
delResponse DelResponse, | delResponse DelResponse, | |||
skipping to change at line 245 | skipping to change at line 247 | |||
abandonRequest AbandonRequest, | abandonRequest AbandonRequest, | |||
extendedReq ExtendedRequest, | extendedReq ExtendedRequest, | |||
extendedResp ExtendedResponse, | extendedResp ExtendedResponse, | |||
... }, | ... }, | |||
controls [0] Controls OPTIONAL } | controls [0] Controls OPTIONAL } | |||
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 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 message ID and the controls. | only common fields are the message ID and the controls. | |||
If the server receives a PDU from the client in which the LDAPMessage | If the server receives a PDU from the client in which the LDAPMessage | |||
SEQUENCE tag cannot be recognized, the messageID cannot be parsed, | SEQUENCE tag cannot be recognized, the messageID cannot be parsed, | |||
the tag of the protocolOp is not recognized as a request, or the | the tag of the protocolOp is not recognized as a request, or the | |||
encoding structures or lengths of data fields are found to be | 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 close the connection. | and MUST immediately close the connection. | |||
In other cases where the client or server cannot parse a PDU, it | In other cases where the client or server cannot parse a PDU, it | |||
SHOULD abruptly close the connection where further communication | SHOULD abruptly close the connection where further communication | |||
(including providing notice) would be pernicious. Otherwise, server | (including providing notice) would be pernicious. Otherwise, server | |||
implementations MUST return an appropriate response to the request, | implementations MUST return an appropriate response to the request, | |||
with the resultCode set to protocolError. | with the resultCode set to protocolError. | |||
The ASN.1 type Controls is defined in Section 4.1.11. | ||||
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 | |||
messageID value of the corresponding request LDAPMessage. | messageID value of the corresponding request LDAPMessage. | |||
The message ID of a request MUST have a non-zero value different from | The message ID of a request MUST have a non-zero value different from | |||
the values of any other requests outstanding in the LDAP association | the values of any other requests outstanding in the LDAP association | |||
of which this message is a part. The zero value is reserved for the | ||||
unsolicited notification message. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 5 | Sermersheim Internet-Draft - Expires Jul 2004 Page 5 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
of which this message is a part. The zero value is reserved for the | ||||
unsolicited notification message. | ||||
Typical clients increment a counter for each request. | Typical clients increment a counter for each request. | |||
A client MUST NOT send a request with the same message ID as an | A client MUST NOT send a request with the same message ID as an | |||
earlier request on the same LDAP association unless it can be | earlier request on the same LDAP association unless it can be | |||
determined that the server is no longer servicing the earlier | determined that the server is no longer servicing the earlier request | |||
request. Otherwise the behavior is undefined. For operations that do | (e.g. after the final response is received, or a subsequent bind | |||
not return responses (unbind, abandon, and abandoned operations), the | completes). Otherwise the behavior is undefined. For this purpose, | |||
client SHOULD assume the operation is in progress until a subsequent | note that abandon and abandoned operations do not send responses. | |||
bind request completes. | ||||
4.1.2. String Types | 4.1.2. String Types | |||
The LDAPString is a notational convenience to indicate that, although | The LDAPString is a notational convenience to indicate that, although | |||
strings of LDAPString type encode as ASN.1 OCTET STRING types, the | strings of LDAPString type encode as ASN.1 OCTET STRING types, the | |||
[ISO10646] character set (a superset of [Unicode]) is used, encoded | [ISO10646] character set (a superset of [Unicode]) is used, encoded | |||
following the [UTF-8] algorithm. Note that Unicode characters U+0000 | following the [UTF-8] algorithm. Note that Unicode characters U+0000 | |||
through U+007F are the same as ASCII 0 through 127, respectively, and | through U+007F are the same as ASCII 0 through 127, respectively, and | |||
have the same single octet UTF-8 encoding. Other Unicode characters | have the same single octet UTF-8 encoding. Other Unicode characters | |||
have a multiple octet UTF-8 encoding. | have a multiple octet UTF-8 encoding. | |||
LDAPString ::= OCTET STRING -- UTF-8 encoded, | LDAPString ::= OCTET STRING -- UTF-8 encoded, | |||
-- [ISO10646] characters | -- [ISO10646] characters | |||
The LDAPOID is a notational convenience to indicate that the | The LDAPOID is a notational convenience to indicate that the | |||
permitted value of this string is a (UTF-8 encoded) dotted-decimal | permitted value of this string is a (UTF-8 encoded) dotted-decimal | |||
representation of an OBJECT IDENTIFIER. Although an LDAPOID is | representation of an OBJECT IDENTIFIER. Although an LDAPOID is | |||
encoded as an OCTET STRING, values are limited to the definition of | encoded as an OCTET STRING, values are limited to the definition of | |||
<numericoid> given in Section 1.3 of [Models]. | <numericoid> given in Section 1.4 of [Models]. | |||
LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] | LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] | |||
For example, | For example, | |||
1.3.6.1.4.1.1466.1.2.3 | 1.3.6.1.4.1.1466.1.2.3 | |||
4.1.3. Distinguished Name and Relative Distinguished Name | 4.1.3. Distinguished Name and Relative Distinguished Name | |||
An LDAPDN is defined to be the representation of a Distinguished Name | An LDAPDN is defined to be the representation of a Distinguished Name | |||
skipping to change at line 328 | skipping to change at line 330 | |||
LDAPDN ::= LDAPString | LDAPDN ::= LDAPString | |||
-- Constrained to <distinguishedName> [LDAPDN] | -- Constrained to <distinguishedName> [LDAPDN] | |||
A RelativeLDAPDN is defined to be the representation of a Relative | A RelativeLDAPDN is defined to be the representation of a Relative | |||
Distinguished Name (RDN) after encoding according to the | Distinguished Name (RDN) after encoding according to the | |||
specification in [LDAPDN]. | specification in [LDAPDN]. | |||
RelativeLDAPDN ::= LDAPString | RelativeLDAPDN ::= LDAPString | |||
-- Constrained to <name-component> [LDAPDN] | -- Constrained to <name-component> [LDAPDN] | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 6 | Sermersheim Internet-Draft - Expires Jul 2004 Page 6 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
4.1.4. Attribute Descriptions | 4.1.4. Attribute Descriptions | |||
The definition and encoding rules for attribute descriptions are | The definition and encoding rules for attribute descriptions are | |||
defined in Section 2.5 of [Models]. Briefly, an attribute description | defined in Section 2.5 of [Models]. Briefly, an attribute description | |||
is an attribute type and zero or more options. | is an attribute type and zero or more options. | |||
AttributeDescription ::= LDAPString | AttributeDescription ::= LDAPString | |||
-- Constrained to <attributedescription> | -- Constrained to <attributedescription> | |||
skipping to change at line 353 | skipping to change at line 355 | |||
A field of type AttributeValue is an OCTET STRING containing an | A field of type AttributeValue is an OCTET STRING containing an | |||
encoded attribute value. The attribute value is encoded according to | encoded attribute value. The attribute value is encoded according to | |||
the LDAP-specific encoding definition of its corresponding syntax. | the LDAP-specific encoding definition of its corresponding syntax. | |||
The LDAP-specific encoding definitions for different syntaxes and | The LDAP-specific encoding definitions for different syntaxes and | |||
attribute types may be found in other documents and in particular | attribute types may be found in other documents and in particular | |||
[Syntaxes]. | [Syntaxes]. | |||
AttributeValue ::= OCTET STRING | AttributeValue ::= OCTET STRING | |||
Note that there is no defined limit on the size of this encoding; | Note that there is no defined limit on the size of this encoding; | |||
thus protocol values may include multi-megabyte attributes (e.g. | thus protocol values may include multi-megabyte attribute values | |||
photographs). | (e.g. photographs). | |||
Attributes may be defined which have arbitrary and non-printable | Attribute values may be defined which have arbitrary and non- | |||
syntax. Implementations MUST NOT display nor attempt to decode a | printable syntax. Implementations MUST NOT display nor attempt to | |||
value if its syntax is not known. The implementation may attempt to | decode an attribute value if its syntax is not known. The | |||
discover the subschema of the source entry, and retrieve the | implementation may attempt to discover the subschema of the source | |||
descriptions of attributeTypes from it [Models]. | entry, and retrieve the descriptions of 'attributeTypes' from it | |||
[Models]. | ||||
Clients MUST NOT send attribute values in a request that are not | Clients MUST only send attribute values in a request that are valid | |||
valid according to the syntax defined for the attributes. | according to the syntax defined for the attributes. | |||
4.1.6. Attribute Value Assertion | 4.1.6. Attribute Value Assertion | |||
The AttributeValueAssertion type definition is similar to the one in | The AttributeValueAssertion (AVA) type definition is similar to the | |||
the X.500 Directory standards. It contains an attribute description | one in the X.500 Directory standards. It contains an attribute | |||
and a matching rule assertion value suitable for that type. | description and a matching rule ([Models Section 4.1.3) assertion | |||
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. | ||||
AttributeValueAssertion ::= SEQUENCE { | AttributeValueAssertion ::= SEQUENCE { | |||
attributeDesc AttributeDescription, | attributeDesc AttributeDescription, | |||
assertionValue AssertionValue } | assertionValue AssertionValue } | |||
AssertionValue ::= OCTET STRING | AssertionValue ::= OCTET STRING | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 7 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The syntax of the AssertionValue depends on the context of the LDAP | The syntax of the AssertionValue depends on the context of the LDAP | |||
operation being performed. For example, the syntax of the EQUALITY | operation being performed. For example, the syntax of the EQUALITY | |||
matching rule for an attribute is used when performing a Compare | matching rule for an attribute is used when performing a Compare | |||
operation. Often this is the same syntax used for values of the | operation. Often this is the same syntax used for values of the | |||
attribute type, but in some cases the assertion syntax differs from | attribute type, but in some cases the assertion syntax differs from | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 7 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
the value syntax. See objectIdentiferFirstComponentMatch in | the value syntax. See objectIdentiferFirstComponentMatch in | |||
[Syntaxes] for an example. | [Syntaxes] for an example. | |||
4.1.7. Attribute and PartialAttribute | 4.1.7. Attribute and PartialAttribute | |||
Attributes and partial attributes consist of an attribute description | Attributes and partial attributes consist of an attribute description | |||
and values of that attribute description. A PartialAttribute allows | and attribute values. A PartialAttribute allows zero values, while | |||
zero values, while Attribute requires at least one value. | Attribute requires at least one value. | |||
PartialAttribute ::= SEQUENCE { | PartialAttribute ::= SEQUENCE { | |||
type AttributeDescription, | type AttributeDescription, | |||
vals SET OF value AttributeValue } | vals SET OF value AttributeValue } | |||
Attribute ::= PartialAttribute(WITH COMPONENTS { | Attribute ::= PartialAttribute(WITH COMPONENTS { | |||
..., | ..., | |||
vals (SIZE(1..MAX))}) | vals (SIZE(1..MAX))}) | |||
Each attribute value is distinct in the set (no duplicates). The set | No two attribute values are equivalent as described by Section 2.3 of | |||
of attribute values is unordered. Implementations MUST NOT rely upon | [Models]. The set of attribute values is unordered. Implementations | |||
the ordering being repeatable. | MUST NOT rely upon the ordering being repeatable. | |||
4.1.8. Matching Rule Identifier | 4.1.8. Matching Rule Identifier | |||
Matching rules are defined in 4.1.3 of [Models]. A matching rule is | Matching rules are defined in Section 4.1.3 of [Models]. A matching | |||
identified in the LDAP protocol by the printable representation of | rule is identified in the protocol by the printable representation of | |||
either its <numericoid>, or one of its short name descriptors | either its <numericoid>, or one of its short name descriptors | |||
[Models], e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33". | [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'. | |||
MatchingRuleId ::= LDAPString | MatchingRuleId ::= LDAPString | |||
4.1.9. Result Message | 4.1.9. Result Message | |||
The LDAPResult is the construct used in this protocol to return | The LDAPResult is the construct used in this protocol to return | |||
success or failure indications from servers to clients. To various | success or failure indications from servers to clients. To various | |||
requests, servers will return responses of LDAPResult or responses | requests, servers will return responses of LDAPResult or responses | |||
containing the components of LDAPResult to indicate the final status | containing the components of LDAPResult to indicate the final status | |||
of a protocol operation request. | of a protocol operation request. | |||
LDAPResult ::= SEQUENCE { | LDAPResult ::= SEQUENCE { | |||
resultCode ENUMERATED { | resultCode ENUMERATED { | |||
success (0), | success (0), | |||
operationsError (1), | operationsError (1), | |||
protocolError (2), | protocolError (2), | |||
timeLimitExceeded (3), | timeLimitExceeded (3), | |||
sizeLimitExceeded (4), | sizeLimitExceeded (4), | |||
compareFalse (5), | compareFalse (5), | |||
compareTrue (6), | compareTrue (6), | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 8 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
authMethodNotSupported (7), | authMethodNotSupported (7), | |||
strongAuthRequired (8), | strongAuthRequired (8), | |||
-- 9 reserved -- | -- 9 reserved -- | |||
referral (10), | referral (10), | |||
adminLimitExceeded (11), | adminLimitExceeded (11), | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 8 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
unavailableCriticalExtension (12), | unavailableCriticalExtension (12), | |||
confidentialityRequired (13), | confidentialityRequired (13), | |||
saslBindInProgress (14), | saslBindInProgress (14), | |||
noSuchAttribute (16), | noSuchAttribute (16), | |||
undefinedAttributeType (17), | undefinedAttributeType (17), | |||
inappropriateMatching (18), | inappropriateMatching (18), | |||
constraintViolation (19), | constraintViolation (19), | |||
attributeOrValueExists (20), | attributeOrValueExists (20), | |||
invalidAttributeSyntax (21), | invalidAttributeSyntax (21), | |||
-- 22-31 unused -- | -- 22-31 unused -- | |||
skipping to change at line 477 | skipping to change at line 482 | |||
objectClassViolation (65), | objectClassViolation (65), | |||
notAllowedOnNonLeaf (66), | notAllowedOnNonLeaf (66), | |||
notAllowedOnRDN (67), | notAllowedOnRDN (67), | |||
entryAlreadyExists (68), | entryAlreadyExists (68), | |||
objectClassModsProhibited (69), | objectClassModsProhibited (69), | |||
-- 70 reserved for CLDAP -- | -- 70 reserved for CLDAP -- | |||
affectsMultipleDSAs (71), | affectsMultipleDSAs (71), | |||
-- 72-79 unused -- | -- 72-79 unused -- | |||
other (80), | other (80), | |||
... }, | ... }, | |||
-- 81-90 reserved for APIs -- | ||||
matchedDN LDAPDN, | matchedDN LDAPDN, | |||
diagnosticMessage LDAPString, | diagnosticMessage LDAPString, | |||
referral [3] Referral OPTIONAL } | referral [3] Referral OPTIONAL } | |||
The resultCode enumeration is extensible as defined in Section 3.5 of | The resultCode enumeration is extensible as defined in Section 3.6 of | |||
[LDAPIANA]. The meanings of the result codes are given in Appendix A. | [LDAPIANA]. The meanings of the listed result codes are given in | |||
If a server detects multiple errors for an operation, only one result | Appendix A. If a server detects multiple errors for an operation, | |||
code is returned. The server should return the result code that best | only one result code is returned. The server should return the result | |||
indicates the nature of the error encountered. | code that best indicates the nature of the error encountered. | |||
The diagnosticMessage field of this construct may, at the server's | The diagnosticMessage field of this construct may, at the server's | |||
option, be used to return a string containing a textual, human- | option, be used to return a string containing a textual, human- | |||
readable (terminal control and page formatting characters should be | readable (terminal control and page formatting characters should be | |||
avoided) diagnostic message. As this diagnostic message is not | avoided) diagnostic message. As this diagnostic message is not | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 9 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
standardized, implementations MUST NOT rely on the values returned. | standardized, implementations MUST NOT rely on the values returned. | |||
If the server chooses not to return a textual diagnostic, the | If the server chooses not to return a textual diagnostic, the | |||
diagnosticMessage field MUST be empty. | diagnosticMessage field MUST be empty. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 9 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
For certain result codes (typically, but not restricted to | For certain result codes (typically, but not restricted to | |||
noSuchObject, aliasProblem, invalidDNSyntax and | noSuchObject, aliasProblem, invalidDNSyntax and | |||
aliasDereferencingProblem), the matchedDN field is set to the name of | aliasDereferencingProblem), the matchedDN field is set to the name of | |||
the lowest entry (object or alias) in the Directory that was matched. | the lowest entry (object or alias) in the Directory that was matched. | |||
If no aliases were dereferenced while attempting to locate the entry, | If no aliases were dereferenced while attempting to locate the entry, | |||
this will be a truncated form of the name provided, or if aliases | this will be a truncated form of the name provided, or if aliases | |||
were dereferenced, of the resulting name, as defined in Section 12.5 | were dereferenced, of the resulting name, as defined in Section 12.5 | |||
of [X.511]. Otherwise the matchedDN field is empty. | of [X.511]. Otherwise the matchedDN field is empty. | |||
4.1.10. Referral | 4.1.10. Referral | |||
skipping to change at line 522 | skipping to change at line 527 | |||
in an LDAPResult if the resultCode field value is referral, and | in an LDAPResult if the resultCode field value is referral, and | |||
absent with all other result codes. It contains one or more | absent with all other result codes. It contains one or more | |||
references to one or more servers or services that may be accessed | references to one or more servers or services that may be accessed | |||
via LDAP or other protocols. Referrals can be returned in response to | via LDAP or other protocols. Referrals can be returned in response to | |||
any operation request (except unbind and abandon which do not have | any operation request (except unbind and abandon which do not have | |||
responses). At least one URI MUST be present in the Referral. | responses). At least one URI MUST be present in the Referral. | |||
During a search operation, after the baseObject is located, and | During a search operation, after the baseObject is located, and | |||
entries are being evaluated, the referral is not returned. Instead, | entries are being evaluated, the referral is not returned. Instead, | |||
continuation references, described in Section 4.5.3, are returned | continuation references, described in Section 4.5.3, are returned | |||
when the search scope spans multiple naming contexts, and several | when other servers would need to be contacted to complete the | |||
different servers would need to be contacted to complete the | ||||
operation. | operation. | |||
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI | Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI | |||
URI ::= LDAPString -- limited to characters permitted in | URI ::= LDAPString -- limited to characters permitted in | |||
-- URIs | -- URIs | |||
If the client wishes to progress the operation, it MUST follow the | If the client wishes to progress the operation, it MUST follow the | |||
referral by contacting one of the services. If multiple URIs are | referral by contacting one of the supported services. If multiple | |||
present, the client assumes that any URI may be used to progress the | URIs are present, the client assumes that any supported URI may be | |||
operation. | used to progress the operation. | |||
Clients that follow referrals MUST ensure that they do not loop | Clients that follow referrals MUST ensure that they do not loop | |||
between servers. They MUST NOT repeatedly contact the same server for | between servers. They MUST NOT repeatedly contact the same server for | |||
the same request with the same target entry name, scope and filter. | the same request with the same target entry name, scope and filter. | |||
Some clients use a counter that is incremented each time referral | Some clients use a counter that is incremented each time referral | |||
handling occurs for an operation, and these kinds of clients MUST be | handling occurs for an operation, and these kinds of clients MUST be | |||
able to handle at least ten nested referrals between the root and a | able to handle at least ten nested referrals between the root and a | |||
leaf entry. | leaf entry. | |||
A URI for a server implementing LDAP and accessible via [TCP]/[IP] | A URI for a server implementing LDAP and accessible via [TCP]/[IP] | |||
(v4 or v6) is written as an LDAP URL according to [LDAPURL]. | (v4 or v6) is written as an LDAP URL according to [LDAPURL]. | |||
When an LDAP URL is used, the following instructions are followed: | When an LDAP URL is used, the following instructions are followed: | |||
- If an alias was dereferenced, the <dn> part of the URL MUST be | ||||
present, with the new target object name. Note that UTF-8 | ||||
characters appearing in a DN or search filter may not be legal | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 10 | Sermersheim Internet-Draft - Expires Jul 2004 Page 10 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
for URLs (e.g. spaces) and MUST be escaped using the % method in | - If an alias was dereferenced, the <dn> part of the URL MUST be | |||
[URI]. | present, with the new target object name. UTF-8 encoded characters | |||
appearing in the string representation of a DN or search filter | ||||
may not be legal for URLs (e.g. spaces) and MUST be escaped using | ||||
the % method in [URI]. | ||||
- It is RECOMMENDED that the <dn> part be present to avoid | - It is RECOMMENDED that the <dn> part be present to avoid | |||
ambiguity. | ambiguity. | |||
- If the <dn> part is present, the client MUST use this name in | - If the <dn> part is present, the client MUST use this name in its | |||
its next request to progress the operation, and if it is not | next request to progress the operation, and if it is not present | |||
present the client will use the same name as in the original | the client will use the same name as in the original request. | |||
request. | ||||
- Some servers (e.g. participating in distributed indexing) may | - Some servers (e.g. participating in distributed indexing) may | |||
provide a different filter in a URL of a referral for a search | provide a different filter in a URL of a referral for a search | |||
operation. | operation. | |||
- If the <filter> part of the LDAP URL is present, the client MUST | - If the <filter> part of the LDAP URL is present, the client MUST | |||
use this filter in its next request to progress this search, and | use this filter in its next request to progress this search, and | |||
if it is not present the client MUST use the same filter as it | if it is not present the client MUST use the same filter as it | |||
used for that search. | used for that search. | |||
- For search, it is RECOMMENDED that the <scope> part be present | - For search, it is RECOMMENDED that the <scope> part be present to | |||
to avoid ambiguity. | avoid ambiguity. | |||
- If the <scope> part is missing, the scope of the original search | - If the <scope> part is missing, the scope of the original search | |||
is used by the client to progress the operation. | is used by the client to progress the operation. | |||
- Other aspects of the new request may be the same as or different | - Other aspects of the new request may be the same as or different | |||
from the request which generated the referral. | from the request which generated the referral. | |||
Other kinds of URIs may be returned. The syntax and semantics of such | Other kinds of URIs may be returned. The syntax and semantics of such | |||
URIs is left to future specifications. Clients ignore URIs that they | URIs is left to future specifications. Clients may ignore URIs that | |||
do not support. | they do not support. | |||
4.1.11. Controls | 4.1.11. Controls | |||
A control is a way to specify extension information for an LDAP | A control is a way to specify extension information for an LDAP | |||
message. A control only alters the semantics of the message it is | message. A control only alters the semantics of the message it is | |||
attached to. | attached to. | |||
Controls ::= SEQUENCE OF control Control | Controls ::= SEQUENCE OF control Control | |||
Control ::= SEQUENCE { | Control ::= SEQUENCE { | |||
controlType LDAPOID, | controlType LDAPOID, | |||
criticality BOOLEAN DEFAULT FALSE, | criticality BOOLEAN DEFAULT FALSE, | |||
controlValue OCTET STRING OPTIONAL } | controlValue OCTET STRING OPTIONAL } | |||
The controlType field is the UTF-8 encoded dotted-decimal | The controlType field is the UTF-8 encoded dotted-decimal | |||
representation of an OBJECT IDENTIFIER which uniquely identifies the | representation of an OBJECT IDENTIFIER which uniquely identifies the | |||
control, or the request control and its paired response control. This | control, or the request control and its paired response control. This | |||
prevents conflicts between control names. | prevents conflicts between control names. | |||
The criticality field is either TRUE or FALSE and only applies to | The criticality field is either TRUE or FALSE and only applies to | |||
request messages that have a corresponding response message. For all | request messages (except unbindRequest). For response messages and | |||
other messages (such as abandonRequest, unbindRequest and all | unbindRequest, the criticality field SHOULD be FALSE, and is ignored | |||
response messages), the criticality field SHOULD be FALSE. | by the receiving protocol peer. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 11 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the server recognizes the control type and it is appropriate for | If the server recognizes the control type and it is appropriate for | |||
the operation, the server will make use of the control when | the operation, the server will make use of the control when | |||
performing the operation. | performing the operation. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 11 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the server does not recognize the control type or it is not | If the server does not recognize the control type or it is not | |||
appropriate for the operation, and the criticality field is TRUE, the | appropriate for the operation, and the criticality field is TRUE, the | |||
server MUST NOT perform the operation, and for operations that have a | server MUST NOT perform the operation, and for operations that have a | |||
response, MUST set the resultCode to unavailableCriticalExtension. | response, MUST return unavailableCriticalExtension in the resultCode. | |||
If the control is unrecognized or inappropriate but the criticality | If the control is unrecognized or inappropriate but the criticality | |||
field is FALSE, the server MUST ignore the control. | field is FALSE, the server MUST ignore the control. | |||
The controlValue contains any information associated with the | The controlValue contains any information associated with the | |||
control. Its format is defined by the specification of the control. | control. Its format is defined by the specification of the control. | |||
Implementations MUST be prepared to handle arbitrary contents of the | Implementations MUST be prepared to handle arbitrary contents of the | |||
controlValue octet string, including zero bytes. It is absent only if | controlValue octet string, including zero bytes. It is absent only if | |||
there is no value information which is associated with a control of | there is no value information which is associated with a control of | |||
its type. controlValues that are defined in terms of ASN.1 and BER | its type. controlValues that are defined in terms of ASN.1 and BER | |||
encoded according to Section 5.1, also follow the extensibility rules | encoded according to Section 5.1, also follow the extensibility rules | |||
in Section 4. | in Section 4. | |||
Servers list the controlType of all request controls they recognize | Servers list the controlType of all request controls they recognize | |||
in the supportedControl attribute [Models] in the root DSE. | in the supportedControl attribute in the root DSE (Section 5.1 of | |||
[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. In the absence of combination | specification most recently published. In the absence of combination | |||
semantics, the behavior of the operation is undefined. | semantics, the behavior of the operation is undefined. | |||
Additionally, unless order-dependent semantics are given in a | Additionally, unless order-dependent semantics are given in a | |||
specification, the order of a combination of controls in the SEQUENCE | specification, the order of a combination of controls in the SEQUENCE | |||
is ignored. | is ignored. | |||
This document does not specify any controls. Controls may be | This document does not specify any controls. Controls may be | |||
specified in other documents. The specification of a control consists | specified in other documents. The specification of a control consists | |||
of: | of: | |||
- the OBJECT IDENTIFIER assigned to the control, | - the OBJECT IDENTIFIER assigned to the control, | |||
- whether the control is always non critical, always critical, or | - whether the criticality field should be always set to TRUE, always | |||
optionally critical, | set to FALSE, or sender's choice, and server behavior when | |||
constraints of this nature are violated, | ||||
- whether there is information associated with the control, and if | - whether there is information associated with the control, and if | |||
so, the format of the controlValue contents, | so, the format of the controlValue 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 | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 12 | ||||
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. | |||
Authentication and security-related semantics of this operation are | Authentication and security-related semantics of this operation are | |||
given in [AuthMeth]. | given in [AuthMeth]. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 12 | ||||
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 | |||
sasl [3] SaslCredentials, | sasl [3] SaslCredentials, | |||
... } | ... } | |||
SaslCredentials ::= SEQUENCE { | SaslCredentials ::= SEQUENCE { | |||
mechanism LDAPString, | mechanism LDAPString, | |||
credentials OCTET STRING OPTIONAL } | credentials OCTET STRING OPTIONAL } | |||
Parameters of the Bind Request are: | Fields of the Bind Request are: | |||
- version: A version number indicating the version of the protocol | - version: A version number indicating the version of the protocol | |||
to be used in this protocol association. This document describes | to be used in this LDAP association. This document describes | |||
version 3 of the LDAP protocol. Note that there is no version | version 3 of the protocol. There is no version negotiation. The | |||
negotiation. The client sets this parameter to the version it | client sets this field to the version it desires. If the server | |||
desires. If the server does not support the specified version, it | does not support the specified version, it MUST respond with | |||
MUST respond with protocolError in the resultCode field of the | protocolError in the resultCode field of the BindResponse. | |||
BindResponse. | ||||
- name: The name of the Directory object that the client wishes to | - name: The name of the Directory object that the client wishes to | |||
bind as. This field may take on a null value (a zero length | bind as. This field may take on a null value (a zero length | |||
string) for the purposes of anonymous binds ([AuthMeth] Section 7) | string) for the purposes of anonymous binds ([AuthMeth] Section | |||
or when using Simple Authentication and Security Layer [SASL] | 5.1) or when using Simple Authentication and Security Layer [SASL] | |||
authentication ([AuthMeth] Section 4.3). Server behavior is | authentication ([AuthMeth] Section 3.3.2). Server behavior is | |||
undefined when the name is a null value, simple authentication is | undefined when the name is a null value, simple authentication is | |||
used, and a password is specified. The server SHALL NOT perform | used, and a non-null password is specified. Where the server | |||
alias dereferencing in determining the object to bind as. | attempts to locate the named object, it SHALL NOT perform alias | |||
dereferencing. | ||||
- authentication: information used in authentication. This type is | ||||
extensible as defined in Section 3.7 of [LDAPIANA]. Servers that | ||||
do not support a choice supplied by a client return | ||||
authMethodNotSupported in the resultCode field of the | ||||
BindResponse. | ||||
- authentication: information used to authenticate the name, if any, | ||||
provided in the Bind Request. This type is extensible as defined | ||||
in Section 3.6 of [LDAPIANA]. Servers that do not support a choice | ||||
supplied by a client will return authMethodNotSupported in the | ||||
resultCode field of the BindResponse. | ||||
The simple form of an AuthenticationChoice specifies a simple | ||||
password to be used for authentication. | ||||
Textual passwords (consisting of a character sequence with a known | Textual passwords (consisting of a character sequence with a known | |||
character set and encoding) SHALL be transferred as [UTF-8] | character set and encoding) transferred to the server using the | |||
encoded [Unicode]. The determination of whether a password is | simple AuthenticationChoice SHALL be transferred as [UTF-8] | |||
textual is a local client matter. | encoded [Unicode]. Prior to transfer, clients SHOULD prepare text | |||
Prior to transfer, clients SHOULD prepare text passwords by | passwords by applying the [SASLprep] profile of the [Stringprep] | |||
applying the [SASLprep] profile of the [Stringprep] algorithm. | ||||
Passwords consisting of other data (such as random octets) MUST | ||||
NOT be altered. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 13 | Sermersheim Internet-Draft - Expires Jul 2004 Page 13 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
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. | ||||
Authorization is the use of this authentication information when | Authorization is the use of this authentication information when | |||
performing operations. Authorization MAY be affected by factors | performing operations. Authorization MAY be affected by factors | |||
outside of the LDAP Bind Request, such as those provided by lower | outside of the LDAP Bind Request, such as those provided by lower | |||
layer security services. | layer security services. | |||
4.2.1. Processing of the Bind Request | 4.2.1. Processing of the Bind Request | |||
Before processing a BindResponse, all outstanding operations MUST | Before processing a BindRequest, all outstanding 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 | |||
outstanding operations to complete, or abandon them. The server then | outstanding 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 | |||
BindResponse to indicate the status of authentication. | BindResponse to indicate the status of authentication. | |||
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 Bind Request. If | operationsError to that request, it may then send a Bind Request. 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 | |||
connection, it may close the connection, reopen it and begin again by | connection, it may close the connection, reopen it and begin again by | |||
skipping to change at line 754 | skipping to change at line 759 | |||
Clients may send multiple Bind Requests on a connection to change the | Clients may send multiple Bind Requests on a connection to change the | |||
authentication and/or security associations or to complete a multi- | authentication and/or security associations or to complete a multi- | |||
stage bind process. Authentication from earlier binds is subsequently | stage bind process. Authentication from earlier binds is subsequently | |||
ignored. | 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. This is indicated by | client to invoke the BindRequest multiple times. This is indicated by | |||
the server sending a BindResponse with the resultCode set to | the server sending a BindResponse with the resultCode set to | |||
saslBindInProgress. This indicates that the server requires the | saslBindInProgress. This indicates that the server requires the | |||
client to send a new bind request, with the same sasl mechanism, to | client to send a new bind request, with the same sasl mechanism, to | |||
continue the authentication process. If at any stage the client | continue the authentication process. Clients MUST NOT invoke | |||
wishes to abort the bind process it MAY unbind and then drop the | operations between two Bind Requests made as part of a multi-stage | |||
underlying connection. Clients MUST NOT invoke operations between two | bind. | |||
Bind Requests made as part of a multi-stage bind. | ||||
A client may abort a SASL bind negotiation by sending a BindRequest | A client may abort a SASL bind negotiation by sending a BindRequest | |||
with a different value in the mechanism field of SaslCredentials, or | with a different value in the mechanism field of SaslCredentials, or | |||
an AuthenticationChoice other than sasl. | an AuthenticationChoice other than sasl. | |||
If the client sends a BindRequest with the sasl mechanism field as an | If the client sends a BindRequest with the sasl mechanism field as an | |||
empty string, the server MUST return a BindResponse with | empty string, the server MUST return a BindResponse with | |||
authMethodNotSupported as the resultCode. This will allow clients to | authMethodNotSupported as the resultCode. This will allow clients to | |||
abort a negotiation if it wishes to try again with the same SASL | abort a negotiation if it wishes to try again with the same SASL | |||
mechanism. | mechanism. | |||
A failed Bind Operation has the effect of leaving the connection in | A failed Bind Operation has the effect of placing the connection in | |||
an anonymous state. An abandoned Bind operation also has the effect | an anonymous state. | |||
of leaving the connection in an anonymous state when (and if) the | ||||
server processes the abandonment of the bind. Client implementers | ||||
should note that the client has no way of being sure when (or if) an | ||||
abandon request succeeds, therefore, to arrive at a known | ||||
authentication state after abandoning a bind operation, clients may | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 14 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
either unbind (which results in the underlying connection being | ||||
closed) or by issuing a bind request and then examining the | ||||
BindResponse returned by the server. | ||||
4.2.2. Bind Response | 4.2.2. Bind Response | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 14 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The Bind Response is defined as follows. | The Bind Response is defined as follows. | |||
BindResponse ::= [APPLICATION 1] SEQUENCE { | BindResponse ::= [APPLICATION 1] SEQUENCE { | |||
COMPONENTS OF LDAPResult, | COMPONENTS OF LDAPResult, | |||
serverSaslCreds [7] OCTET STRING OPTIONAL } | serverSaslCreds [7] OCTET STRING OPTIONAL } | |||
BindResponse consists simply of an indication from the server of the | BindResponse consists simply of an indication from the server of the | |||
status of the client's request for authentication. | status of the client's request for authentication. | |||
A successful bind operation is indicated by a BindResponse with a | A successful bind operation is indicated by a BindResponse with a | |||
resultCode set to success. Otherwise, an appropriate result code is | resultCode set to success. Otherwise, an appropriate result code is | |||
set in the BindResponse. For bind, the protocolError result code may | set in the BindResponse. For bind, the protocolError result code may | |||
be used to indicate that the version number supplied by the client is | be used to indicate that the version number supplied by the client is | |||
unsupported. | unsupported. | |||
If the client receives a BindResponse response where the resultCode | If the client receives a BindResponse where the resultCode field is | |||
field is protocolError, it MUST close the connection as the server | protocolError, it is to assume that the server does not support this | |||
will be unwilling to accept further operations. (This is for | version of LDAP. While the client may be able proceed with another | |||
compatibility with earlier versions of LDAP, in which the bind was | version of this protocol (this may or may not require establishing a | |||
always the first operation, and there was no negotiation.) | new connection), how to proceed with another version of this protocol | |||
is beyond the scope of this document. Clients which are unable or | ||||
unwilling to proceed SHOULD drop the underlying connection. | ||||
The serverSaslCreds are used as part of a SASL-defined bind mechanism | The serverSaslCreds field is used as part of a SASL-defined bind | |||
to allow the client to authenticate the server to which it is | mechanism to allow the client to authenticate the server to which it | |||
communicating, or to perform "challenge-response" authentication. If | is communicating, or to perform "challenge-response" authentication. | |||
the client bound with the simple choice, or the SASL mechanism does | If the client bound with the simple choice, or the SASL mechanism | |||
not require the server to return information to the client, then this | does not require the server to return information to the client, then | |||
field SHALL NOT be included in the BindResponse. | this field SHALL NOT be included in the BindResponse. | |||
4.3. Unbind Operation | 4.3. Unbind Operation | |||
The function of the Unbind Operation is to terminate an LDAP | The function of the Unbind Operation is to terminate an LDAP | |||
association and connection. The Unbind operation is not the | association and connection. The Unbind operation is not the | |||
antithesis of the Bind operation as the name implies. The naming of | antithesis of the Bind operation as the name implies. The naming of | |||
these operations is historical. The Unbind operation should be | these operations is historical. The Unbind operation should be | |||
thought of as the "quit" operation. | thought of as the "quit" operation. | |||
The Unbind Operation is defined as follows: | The Unbind Operation is defined as follows: | |||
UnbindRequest ::= [APPLICATION 2] NULL | UnbindRequest ::= [APPLICATION 2] NULL | |||
The Unbind Operation has no response defined. Upon transmission of | The Unbind Operation has no response defined. Upon transmission of | |||
the UnbindRequest, each protocol peer is to consider the LDAP | the UnbindRequest, each protocol peer is to consider the LDAP | |||
association terminated, MUST cease transmission of messages to the | association terminated, MUST cease transmission of messages to the | |||
other peer, and MUST close the connection. Any outstanding operations | other peer, and MUST close the connection. Outstanding operations are | |||
on the server are, when possible, abandoned, and when not possible, | handled as specified in Section 5.2. | |||
completed without transmission of the response. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 15 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.4. Unsolicited Notification | 4.4. Unsolicited Notification | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 15 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
An unsolicited notification is an LDAPMessage sent from the server to | An unsolicited notification is an LDAPMessage sent from the server to | |||
the client which is not in response to any LDAPMessage received by | the client which is not in response to any LDAPMessage received by | |||
the server. It is used to signal an extraordinary condition in the | the server. It is used to signal an extraordinary condition in the | |||
server or in the connection between the client and the server. The | server or in the connection between the client and the server. The | |||
notification is of an advisory nature, and the server will not expect | notification is of an advisory nature, and the server will not expect | |||
any response to be returned from the client. | any response to be returned from the client. | |||
The unsolicited notification is structured as an LDAPMessage in which | The unsolicited notification is structured as an LDAPMessage in which | |||
the messageID is zero and protocolOp is of the extendedResp form. The | the messageID is zero and protocolOp is of the extendedResp form (See | |||
responseName field of the ExtendedResponse always contains an LDAPOID | Section 4.12). The responseName field of the ExtendedResponse always | |||
which is unique for this notification. | contains an LDAPOID which is unique for this notification. | |||
One unsolicited notification (Notice of Disconnection) is defined in | One unsolicited notification (Notice of Disconnection) is defined in | |||
this document. The specification of an unsolicited notification | this document. The specification of an unsolicited notification | |||
consists of: | consists of: | |||
- the OBJECT IDENTIFIER assigned to the notification (to be | - the OBJECT IDENTIFIER assigned to the notification (to be | |||
specified in the responseName, | specified in the responseName, | |||
- the format of the contents (if any) of the responseValue, | - the format of the contents (if any) of the responseValue, | |||
- the circumstances which will cause the notification to be | - the circumstances which will cause the notification to be | |||
returned, and | returned, and | |||
- the semantics of the operation. | - the semantics of the operation. | |||
4.4.1. Notice of Disconnection | 4.4.1. Notice of Disconnection | |||
This notification may be used by the server to advise the client that | This notification may be used by the server to advise the client that | |||
the server is about to close the connection due to an error | the server is about to close the connection due to an error | |||
condition. Note that this notification is NOT a response to an unbind | condition. This notification is intended to assist clients in | |||
requested by the client: the server MUST follow the procedures of | ||||
Section 4.3. This notification is intended to assist clients in | ||||
distinguishing between an error condition and a transient network | distinguishing between an error condition and a transient network | |||
failure. As with a connection close due to network failure, the | failure. Note that this notification is not a response to an unbind | |||
client MUST NOT assume that any outstanding requests which modified | requested by the client. Outstanding operations are handled as | |||
the Directory have succeeded or failed. | specified in Section 5.2. | |||
The responseName is 1.3.6.1.4.1.1466.20036, the response field is | The responseName is 1.3.6.1.4.1.1466.20036, the response field is | |||
absent, and the resultCode is used to indicate the reason for the | absent, and the resultCode is used to indicate the reason for the | |||
disconnection. | disconnection. | |||
The following result codes have these meanings when used in this | The following result codes have these meanings when used in this | |||
notification: | notification: | |||
- protocolError: The server has received data from the client in | - protocolError: The server has received data from the client in | |||
which the LDAPMessage structure could not be parsed. | which the LDAPMessage structure could not be parsed. | |||
- strongAuthRequired: The server has detected that an established | - strongAuthRequired: The server has detected that an established | |||
security association between the client and server has | security association between the client and server has | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 16 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
unexpectedly failed or been compromised, or that the server now | unexpectedly failed or been compromised, or that the server now | |||
requires the client to authenticate using a strong(er) mechanism. | requires the client to authenticate using a strong(er) mechanism. | |||
- unavailable: This server will stop accepting new connections and | - unavailable: This server will stop accepting new connections and | |||
operations on all existing connections, and be unavailable for an | operations on all existing connections, and be unavailable for an | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 16 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
extended period of time. The client may make use of an alternative | extended period of time. The client may make use of an alternative | |||
server. | server. | |||
Upon transmission of the UnbindRequest, each protocol peer is to | Upon transmission of the Notice of Disconnection, the server is to | |||
consider the LDAP association terminated, MUST cease transmission of | consider the LDAP association terminated, MUST cease transmission of | |||
messages to the other peer, and MUST close the connection. | messages to the client, and MUST close the connection. | |||
4.5. Search Operation | 4.5. Search Operation | |||
The Search Operation is used to request a server to return, subject | The Search Operation is used to request a server to return, subject | |||
to access controls and other restrictions, a set of entries matching | to access controls and other restrictions, a set of entries matching | |||
a complex search criterion. This can be used to read attributes from | a complex search criterion. This can be used to read attributes from | |||
a single entry, from entries immediately subordinate to a particular | a single entry, from entries immediately subordinate to a particular | |||
entry, or a whole subtree of entries. | entry, or a whole subtree of entries. | |||
4.5.1. Search Request | 4.5.1. Search Request | |||
skipping to change at line 944 | skipping to change at line 938 | |||
-- constrained to <attributeSelection> below | -- constrained to <attributeSelection> below | |||
Filter ::= CHOICE { | Filter ::= CHOICE { | |||
and [0] SET SIZE (1..MAX) OF filter Filter, | and [0] SET SIZE (1..MAX) OF filter Filter, | |||
or [1] SET SIZE (1..MAX) OF filter Filter, | or [1] SET SIZE (1..MAX) OF filter Filter, | |||
not [2] Filter, | not [2] Filter, | |||
equalityMatch [3] AttributeValueAssertion, | equalityMatch [3] AttributeValueAssertion, | |||
substrings [4] SubstringFilter, | substrings [4] SubstringFilter, | |||
greaterOrEqual [5] AttributeValueAssertion, | greaterOrEqual [5] AttributeValueAssertion, | |||
lessOrEqual [6] AttributeValueAssertion, | lessOrEqual [6] AttributeValueAssertion, | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 17 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
present [7] AttributeDescription, | present [7] AttributeDescription, | |||
approxMatch [8] AttributeValueAssertion, | approxMatch [8] AttributeValueAssertion, | |||
extensibleMatch [9] MatchingRuleAssertion } | extensibleMatch [9] MatchingRuleAssertion } | |||
SubstringFilter ::= SEQUENCE { | SubstringFilter ::= SEQUENCE { | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 17 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
type AttributeDescription, | type AttributeDescription, | |||
-- at least one must be present, | ||||
-- initial and final can occur at most once | -- initial and final can occur at most once | |||
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { | substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { | |||
initial [0] AssertionValue, | initial [0] AssertionValue, | |||
any [1] AssertionValue, | any [1] AssertionValue, | |||
final [2] AssertionValue } } | final [2] AssertionValue } } | |||
MatchingRuleAssertion ::= SEQUENCE { | MatchingRuleAssertion ::= SEQUENCE { | |||
matchingRule [1] MatchingRuleId OPTIONAL, | matchingRule [1] MatchingRuleId OPTIONAL, | |||
type [2] AttributeDescription OPTIONAL, | type [2] AttributeDescription OPTIONAL, | |||
matchValue [3] AssertionValue, | matchValue [3] AssertionValue, | |||
dnAttributes [4] BOOLEAN DEFAULT FALSE } | dnAttributes [4] BOOLEAN DEFAULT FALSE } | |||
Parameters of the Search Request are: | Fields of the Search Request are: | |||
- baseObject: The name of the base object entry relative to which | - baseObject: The name of the base object entry relative to which | |||
the search is to be performed. | the search is to be performed. | |||
- scope: Specifies the scope of the search to be performed. The | - scope: Specifies the scope of the search to be performed. The | |||
semantics (as described in [X.511]) of the possible values of this | semantics (as described in [X.511]) of the possible values of this | |||
field are: | field are: | |||
baseObject: The scope is constrained to the entry named by | baseObject: The scope is constrained to the entry named by | |||
baseObject. | baseObject. | |||
oneLevel: The scope is constrained to the immediate | singleLevel: The scope is constrained to the immediate | |||
subordinates of the entry named by baseObject. | subordinates of the entry named by baseObject. | |||
wholeSubtree: the scope is constrained to the entry named | wholeSubtree: the scope is constrained to the entry named by | |||
by the baseObject, and all its subordinates. | the baseObject, and all its subordinates. | |||
- derefAliases: An indicator as to how alias objects (as defined in | - derefAliases: An indicator as to how alias entries (as defined in | |||
[X.501]) are to be handled in searching. The semantics of the | [Models]) are to be handled in searching. The semantics of the | |||
possible values of this field are: | possible values of this field are: | |||
neverDerefAliases: Do not dereference aliases in searching | neverDerefAliases: Do not dereference aliases in searching or | |||
or in locating the base object of the search. | in locating the base object of the search. | |||
derefInSearching: While searching, dereference any alias | ||||
object subordinate to the base object which is also in the | ||||
search scope. The filter is applied to the dereferenced | ||||
object(s). If the search scope is wholeSubtree, the search | ||||
continues in the subtree of any dereferenced object. | ||||
Aliases in that subtree are also dereferenced. Servers | ||||
SHOULD detect looping in this process to prevent denial of | ||||
service attacks and duplicate entries. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 18 | derefInSearching: While searching, dereference any alias entry | |||
Lightweight Directory Access Protocol Version 3 | subordinate to the base object which is also in the search | |||
scope. The filter is applied to the dereferenced object(s). If | ||||
the search scope is wholeSubtree, the search continues in the | ||||
subtree of any dereferenced object. Aliases in that subtree are | ||||
also dereferenced. Servers SHOULD eliminate duplicate entries | ||||
that arise due to alias dereferencing while searching. | ||||
derefFindingBaseObj: Dereference aliases in locating the | derefFindingBaseObj: Dereference aliases in locating the base | |||
base object of the search, but not when searching | object of the search, but not when searching subordinates of | |||
subordinates of the base object. | the base object. | |||
derefAlways: Dereference aliases both in searching and in | derefAlways: Dereference aliases both in searching and in | |||
locating the base object of the search. | locating the base object of the search. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 18 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Servers MUST detect looping while dereferencing aliases in order | ||||
to prevent denial of service attacks of this nature. | ||||
- sizeLimit: A size limit that restricts the maximum number of | - sizeLimit: A size limit that restricts the maximum number of | |||
entries to be returned as a result of the search. A value of zero | entries to be returned as a result of the search. A value of zero | |||
in this field indicates that no client-requested size limit | in this field indicates that no client-requested size limit | |||
restrictions are in effect for the search. Servers may enforce a | restrictions are in effect for the search. Servers may also | |||
maximum number of entries to return. | enforce a maximum number of entries to return. | |||
- timeLimit: A time limit that restricts the maximum time (in | - timeLimit: A time limit that restricts the maximum time (in | |||
seconds) allowed for a search. A value of zero in this field | seconds) allowed for a search. A value of zero in this field | |||
indicates that no client-requested time limit restrictions are in | indicates that no client-requested time limit restrictions are in | |||
effect for the search. Servers may enforce a maximum time limit | effect for the search. Servers may also enforce a maximum time | |||
for the search. | limit for the search. | |||
- typesOnly: An indicator as to whether search results are to | - typesOnly: An indicator as to whether search results are to | |||
contain both attribute descriptions and values, or just attribute | contain both attribute descriptions and values, or just attribute | |||
descriptions. Setting this field to TRUE causes only attribute | descriptions. Setting this field to TRUE causes only attribute | |||
descriptions (no values) to be returned. Setting this field to | descriptions (no values) to be returned. Setting this field to | |||
FALSE causes both attribute descriptions and values to be | FALSE causes both attribute descriptions and values to be | |||
returned. | returned. | |||
- filter: A filter that defines the conditions that must be | - filter: A filter that defines the conditions that must be | |||
fulfilled in order for the search to match a given entry. | fulfilled in order for the search to match a given entry. | |||
skipping to change at line 1053 | skipping to change at line 1048 | |||
to either "TRUE", "FALSE" or "Undefined". If the filter evaluates | to either "TRUE", "FALSE" or "Undefined". If the filter evaluates | |||
to TRUE for a particular entry, then the attributes of that entry | to TRUE for a particular entry, then the attributes of that entry | |||
are returned as part of the search result (subject to any | are returned as part of the search result (subject to any | |||
applicable access control restrictions). If the filter evaluates | applicable access control restrictions). If the filter evaluates | |||
to FALSE or Undefined, then the entry is ignored for the search. | to FALSE or Undefined, then the entry is ignored for the search. | |||
A filter of the "and" choice is TRUE if all the filters in the SET | A filter of the "and" choice is TRUE if all the filters in the SET | |||
OF evaluate to TRUE, FALSE if at least one filter is FALSE, and | OF evaluate to TRUE, FALSE if at least one filter is FALSE, and | |||
otherwise Undefined. A filter of the "or" choice is FALSE if all | otherwise Undefined. A filter of the "or" choice is FALSE if all | |||
of the filters in the SET OF evaluate to FALSE, TRUE if at least | of the filters in the SET OF evaluate to FALSE, TRUE if at least | |||
one filter is TRUE, and Undefined otherwise. A filter of the "not" | one filter is TRUE, and Undefined otherwise. A filter of the 'not' | |||
choice is TRUE if the filter being negated is FALSE, FALSE if it | choice is TRUE if the filter being negated is FALSE, FALSE if it | |||
is TRUE, and Undefined if it is Undefined. | is TRUE, and Undefined if it is Undefined. | |||
The present match evaluates to TRUE where there is an attribute or | The present match evaluates to TRUE where there is an attribute or | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 19 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
subtype of the specified attribute description present in an | subtype of the specified attribute description present in an | |||
entry, and FALSE otherwise (including a presence test with an | entry, and FALSE otherwise (including a presence test with an | |||
unrecognized attribute description.) | unrecognized attribute description.) | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 19 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The matching rule for equalityMatch filter items is defined by the | The matching rule for equalityMatch filter items is defined by the | |||
EQUALITY matching rule for the attribute type. | EQUALITY matching rule for the attribute type. | |||
There SHALL be at most one 'initial', and at most one 'final' in | ||||
the 'substrings' of a SubstringFilter. If 'initial' is present, it | ||||
SHALL be the first element of 'substrings'. If 'final' is present, | ||||
it SHALL be the last element of 'substrings'. | ||||
The matching rule for AssertionValues in a substrings filter item | The matching rule for AssertionValues in a substrings filter item | |||
is defined by the SUBSTR matching rule for the attribute type. | is defined by the SUBSTR matching rule for the attribute type. | |||
Note that the AssertionValue in a substrings filter item MUST | Note that the AssertionValue in a substrings filter item conforms | |||
conform to the assertion syntax of the EQUALITY matching rule for | to the assertion syntax of the EQUALITY matching rule for the | |||
the attribute type rather than the assertion syntax of the SUBSTR | attribute type rather than the assertion syntax of the SUBSTR | |||
matching rule for the attribute type. The entire SubstringFilter | matching rule for the attribute type. Conceptually, the entire | |||
is converted into an assertion value of the substrings matching | SubstringFilter is converted into an assertion value of the | |||
rule prior to applying the rule. | substrings matching rule prior to applying the rule. | |||
The matching rule for greaterOrEqual and lessOrEqual filter items | The matching rule for the greaterOrEqual filter item is defined by | |||
is defined by the ORDERING matching rule for the attribute type. | the ORDERING and EQUALITY matching rules for the attribute type. | |||
The approxMatch evaluates to TRUE when there is a value of the | The matching rule for the lessOrEqual filter item is defined by | |||
attribute or subtype for which some locally-defined approximate | the ORDERING matching rule for the attribute type. | |||
matching algorithm (e.g. spelling variations, phonetic match, | ||||
etc.) returns TRUE. If an item matches for equality, it also | ||||
satisfies an approximate match. If approximate matching is not | ||||
supported, this filter item should be treated as an equalityMatch. | ||||
An extensibleMatch is evaluated as follows: | 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 approximate match. If approximate matching is | ||||
not supported, this filter item should be treated as an | ||||
equalityMatch. | ||||
An extensibleMatch filter item is evaluated as 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. The matchingRule determines the | support that matchingRule. The matchingRule determines the | |||
syntax for the assertion value. The filter item evaluates to | syntax for the assertion value. The filter item evaluates to | |||
TRUE if it matches with at least one attribute in the entry, | TRUE if it matches with at least one attribute in the entry, | |||
FALSE if it does not match any attribute in the entry, and | FALSE if it does not match any attribute in the entry, and | |||
Undefined if the matchingRule is not recognized or the | Undefined if the matchingRule is not recognized or the | |||
assertionValue is invalid. | assertionValue is invalid. | |||
If the type field is present and the matchingRule is present, | If the type field is present and the matchingRule is present, | |||
the matchValue is compared against entry attributes of the | the matchValue is compared against entry attributes of the | |||
specified type. In this case, the matchingRule MUST be one | specified type. In this case, the matchingRule MUST be one | |||
suitable for use with the specified type (see [Syntaxes]), | suitable for use with the specified type (see [Syntaxes]), | |||
otherwise the filter item is undefined. | otherwise the filter item is Undefined. | |||
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 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 | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 20 | Sermersheim Internet-Draft - Expires Jul 2004 Page 20 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
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. | another applies to entries and dn attributes as well. | |||
A filter item evaluates to Undefined when the server would not be | A filter item evaluates to Undefined when the server would not be | |||
able to determine whether the assertion value matches an entry. If | able to determine whether the assertion value matches an entry. If | |||
an attribute description in an equalityMatch, substrings, | an attribute description in an equalityMatch, substrings, | |||
greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter | greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter | |||
is not recognized by the server, a matching rule id in the | is not recognized by the server, a matching rule id in the | |||
extensibleMatch is not recognized by the server, the assertion | extensibleMatch is not recognized by the server, the assertion | |||
value is invalid, or the type of filtering requested is not | value is invalid, or the type of filtering requested is not | |||
implemented, then the filter is Undefined. Thus for example if a | implemented, then the filter is Undefined. Thus for example if a | |||
skipping to change at line 1142 | skipping to change at line 1144 | |||
Undefined. | Undefined. | |||
Servers MUST NOT return errors if attribute descriptions or | Servers MUST NOT return errors if attribute descriptions or | |||
matching rule ids are not recognized, assertion values are | matching rule ids are not recognized, assertion values are | |||
invalid, or the assertion syntax is not supported. More details of | invalid, or the assertion syntax is not supported. More details of | |||
filter processing are given in Section 7.8 of [X.511]. | filter processing are given in Section 7.8 of [X.511]. | |||
- attributes: A list of the attributes to be returned from each | - attributes: A list of the attributes to be returned from each | |||
entry which matches the search filter. LDAPString values of this | entry which matches the search filter. LDAPString values of this | |||
field are constrained to the following Augmented Backus-Naur Form | field are constrained to the following Augmented Backus-Naur Form | |||
[(ABNF)]: | ([ABNF]): | |||
attributeSelection = noattrs / | attributeSelection = noattrs / | |||
*( attributedescription / specialattr ) | *( attributedescription / specialattr ) | |||
noattrs = %x31 %x2E %x31 ; "1.1" | noattrs = %x31 %x2E %x31 ; "1.1" | |||
specialattr = ASTERISK | specialattr = ASTERISK | |||
ASTERISK = %x2A ; asterisk ("*") | ASTERISK = %x2A ; asterisk ("*") | |||
<attributedescription> is defined in Section 2.5 of [Models]. | The <attributedescription> production is defined in Section 2.5 of | |||
[Models]. | ||||
There are two special values which may be used: an empty list with | There are two special values which may be used: an empty list with | |||
no attributes, and the attribute description string "*". Both of | no attributes, and the attribute description string "*". Both of | |||
these signify that all user attributes are to be returned. (The | these signify that all user attributes are to be returned. (The | |||
"*" allows the client to request all user attributes in addition | "*" allows the client to request all user attributes in addition | |||
to any specified operational attributes). Client implementors | to any specified operational attributes). Client implementors | |||
should note that even if all user attributes are requested, some | should note that even if all user attributes are requested, some | |||
attributes and or attribute values of the entry may not be | attributes and/or attribute values of the entry may not be | |||
included in search results due to access controls or other | included in search results due to access controls or other | |||
restrictions. Furthermore, servers will not return operational | restrictions. Furthermore, servers will not return operational | |||
attributes, such as objectClasses or attributeTypes, unless they | attributes, such as objectClasses or attributeTypes, unless they | |||
are listed by name. Operational attributes are described in | are listed by name. Operational attributes are described in | |||
[Models]. | [Models]. | |||
Attributes MUST NOT be named more than once in the list, and are | Attributes MUST NOT be named more than once in the list, and are | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 21 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
returned at most once in an entry. If there are attribute | returned at most once in an entry. If there are attribute | |||
descriptions in the list which are not recognized, they are | descriptions in the list which are not recognized, they are | |||
ignored by the server. | ignored by the server. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 21 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the client does not want any attributes returned, it can | If the client does not want any attributes returned, it can | |||
specify a list containing only the attribute with OID "1.1". This | specify a list containing only the attribute with OID "1.1". This | |||
OID was chosen because it does not (and can not) correspond to any | OID was chosen because it does not (and can not) correspond to any | |||
attribute in use. | attribute in use. | |||
Note that an X.500 "list"-like operation can be emulated by the | Note that an X.500 "list"-like operation can be emulated by the | |||
client requesting a one-level LDAP search operation with a filter | client requesting a one-level LDAP search operation with a filter | |||
checking for the presence of the objectClass attribute, and that an | checking for the presence of the 'objectClass' attribute, and that an | |||
X.500 "read"-like operation can be emulated by a base object LDAP | X.500 "read"-like operation can be emulated by a base object LDAP | |||
search operation with the same filter. A server which provides a | search operation with the same filter. A server which provides a | |||
gateway to X.500 is not required to use the Read or List operations, | gateway to X.500 is not required to use the Read or List operations, | |||
although it may choose to do so, and if it does, it must provide the | although it may choose to do so, and if it does, it must provide the | |||
same semantics as the X.500 search operation. | same semantics as the X.500 search operation. | |||
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 messages, zero or more SearchResultReference | searchResultEntry messages, zero or more SearchResultReference | |||
skipping to change at line 1224 | skipping to change at line 1228 | |||
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 PDUs may | |||
come in any order. Following all the SearchResultReference and | 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 | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 22 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Search Request. Return of attributes is subject to access control and | Search Request. Return of attributes is subject to access control and | |||
other administrative policy. | other administrative policy. | |||
Some attributes may be constructed by the server and appear in a | Some attributes may be constructed by the server and appear in a | |||
SearchResultEntry attribute list, although they are not stored | SearchResultEntry attribute list, although they are not stored | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 22 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
attributes of an entry. Clients SHOULD NOT assume that all attributes | attributes of an entry. Clients SHOULD NOT assume that all attributes | |||
can be modified, even if permitted by access control. | can be modified, even if permitted by access control. | |||
If the server's schema defines short names [Models] for an attribute | If the server's schema defines short names [Models] for an attribute | |||
type then the server SHOULD use one of those names in attribute | type then the server SHOULD use one of those names in attribute | |||
descriptions for that attribute type (in preference to using the | descriptions for that attribute type (in preference to using the | |||
<numericoid> [Models] format of the attribute type's object | <numericoid> [Models] format of the attribute type's object | |||
identifier). The server SHOULD NOT use the short name if that name is | identifier). The server SHOULD NOT use the short name if that name is | |||
known by the server to be ambiguous, or otherwise likely to cause | known by the server to be ambiguous, or otherwise likely to cause | |||
interoperability problems. | interoperability problems. | |||
4.5.3. Continuation References in the Search Result | 4.5.3. Continuation References in the Search Result | |||
If the server was able to locate the entry referred to by the | If the server was able to locate the entry referred to by the | |||
baseObject but was unable to search all the entries in the scope at | baseObject but was unable to search one or more non-local entries, | |||
and subordinate to the baseObject, the server may return one or more | the server may return one or more SearchResultReference entries, each | |||
SearchResultReference entries, each containing a reference to another | containing a reference to another set of servers for continuing the | |||
set of servers for continuing the operation. A server MUST NOT return | operation. A server MUST NOT return any SearchResultReference if it | |||
any SearchResultReference if it has not located the baseObject and | has not located the baseObject and thus has not searched any entries; | |||
thus has not searched any entries; in this case it would return a | in this case it would return a SearchResultDone containing a referral | |||
SearchResultDone containing a referral result code. | result code. | |||
If a server holds a copy or partial copy of the subordinate naming | If a server holds a copy or partial copy of the subordinate naming | |||
context, it may use the search filter to determine whether or not to | context [Section 5 of Models], it may use the search filter to | |||
return a SearchResultReference response. Otherwise | determine whether or not to return a SearchResultReference response. | |||
SearchResultReference responses are always returned when in scope. | Otherwise SearchResultReference responses are always returned when in | |||
scope. | ||||
The SearchResultReference is of the same data type as the Referral. | The SearchResultReference is of the same data type as the Referral. | |||
A URI for a server implementing LDAP and accessible via [TCP]/[IP] | A URI for a server implementing LDAP and accessible via [TCP]/[IP] | |||
(v4 or v6) is written as an LDAP URL according to [LDAPURL]. | (v4 or v6) is written as an LDAP URL according to [LDAPURL]. | |||
In order to complete the search, the client issues a new search | In order to complete the search, the client issues a new search | |||
operation for each SearchResultReference that is returned. Note that | operation for each SearchResultReference that is returned. Note that | |||
the abandon operation described in Section 4.11 applies only to a | the abandon operation described in Section 4.11 applies only to a | |||
particular operation sent on an association between a client and | particular operation sent on an association between a client and | |||
skipping to change at line 1280 | skipping to change at line 1285 | |||
wishes to individually. | wishes to individually. | |||
Clients that follow search continuation references MUST ensure that | Clients that follow search continuation references MUST ensure that | |||
they do not loop between servers. They MUST NOT repeatedly contact | they do not loop between servers. They MUST NOT repeatedly contact | |||
the same server for the same request with the same target entry name, | the same server for the same request with the same target entry name, | |||
scope and filter. Some clients use a counter that is incremented each | scope and filter. Some clients use a counter that is incremented each | |||
time search result reference handling occurs for an operation, and | time search result reference handling occurs for an operation, and | |||
these kinds of clients MUST be able to handle at least ten nested | these kinds of clients MUST be able to handle at least ten nested | |||
search result references between the root and a leaf entry. | search result references between the root and a leaf entry. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 23 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
When an LDAP URL is used, the following instructions are followed: | When an LDAP URL is used, the following instructions are followed: | |||
- The <dn> part of the URL MUST be present, with the new target | - The <dn> part of the URL MUST be present, with the new target | |||
object name. The client MUST use this name when following the | object name. The client MUST use this name when following the | |||
referral. Note that UTF-8 characters appearing in a DN or search | reference. UTF-8 encoded characters appearing in the string | |||
filter may not be legal for URLs (e.g. spaces) and MUST be | representation of a DN or search filter may not be legal for URLs | |||
escaped using the % method in [URI]. | (e.g. spaces) and MUST be escaped using the % method in [URI]. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 23 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- It is RECOMMENDED that the <dn> part be present to avoid | ||||
ambiguity. | ||||
- Some servers (e.g. participating in distributed indexing) may | - Some servers (e.g. participating in distributed indexing) may | |||
provide a different filter in a URL of a SearchResultReference. | provide a different filter in a URL of a SearchResultReference. | |||
- If the <filter> part of the URL is present, the client MUST use | - If the <filter> part of the URL is present, the client MUST use | |||
this filter in its next request to progress this search, and if | this filter in its next request to progress this search, and if it | |||
it is not present the client MUST use the same filter as it used | is not present the client MUST use the same filter as it used for | |||
for that search. | that search. | |||
- If the originating search scope was singleLevel, the <scope> | - If the originating search scope was singleLevel, the <scope> part | |||
part of the URL will be "base". | of the URL will be "base". | |||
- it is RECOMMENDED that the <scope> part be present to avoid | - it is RECOMMENDED that the <scope> part be present to avoid | |||
ambiguity. | ambiguity. | |||
- If the <scope> part is missing, the scope of the original search | ||||
is used by the client to progress the operation. | ||||
- Other aspects of the new search request may be the same as or | - Other aspects of the new search request may be the same as or | |||
different from the search request which generated the | different from the search request which generated the | |||
SearchResultReference. | SearchResultReference. | |||
- The name of an unexplored subtree in a SearchResultReference | - The name of an unexplored subtree in a SearchResultReference need | |||
need not be subordinate to the base object. | not be subordinate to the base object. | |||
Other kinds of URIs may be returned. The syntax and semantics of such | Other kinds of URIs may be returned. The syntax and semantics of such | |||
URIs is left to future specifications. Clients ignore URIs that they | URIs is left to future specifications. Clients may ignore URIs that | |||
do not support. | they do not support. | |||
4.5.3.1. Example | 4.5.3.1. Examples | |||
For example, suppose the contacted server (hosta) holds the entry | For example, suppose the contacted server (hosta) holds the entry | |||
"DC=Example,DC=NET" and the entry "CN=Manager,DC=Example,DC=NET". It | <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It | |||
knows that either LDAP-capable servers (hostb) or (hostc) hold | knows that either LDAP-capable servers (hostb) or (hostc) hold | |||
"OU=People,DC=Example,DC=NET" (one is the master and the other server | <OU=People,DC=Example,DC=NET> (one is the master and the other server | |||
a shadow), and that LDAP-capable server (hostd) holds the subtree | a shadow), and that LDAP-capable server (hostd) holds the subtree | |||
"OU=Roles,DC=Example,DC=NET". If a subtree search of | <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree search of | |||
"DC=Example,DC=NET" is requested to the contacted server, it may | <DC=Example,DC=NET> is requested to the contacted server, it may | |||
return the following: | return the following: | |||
SearchResultEntry for DC=Example,DC=NET | SearchResultEntry for DC=Example,DC=NET | |||
SearchResultEntry for CN=Manager,DC=Example,DC=NET | SearchResultEntry for CN=Manager,DC=Example,DC=NET | |||
SearchResultReference { | SearchResultReference { | |||
ldap://hostb/OU=People,DC=Example,DC=NET??sub | ldap://hostb/OU=People,DC=Example,DC=NET??sub | |||
ldap://hostc/OU=People,DC=Example,DC=NET??sub } | ldap://hostc/OU=People,DC=Example,DC=NET??sub } | |||
SearchResultReference { | SearchResultReference { | |||
ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } | ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } | |||
SearchResultDone (success) | SearchResultDone (success) | |||
Client implementors should note that when following a | Client implementors should note that when following a | |||
SearchResultReference, additional SearchResultReference may be | SearchResultReference, additional SearchResultReference may be | |||
generated. Continuing the example, if the client contacted the server | generated. Continuing the example, if the client contacted the server | |||
(hostb) and issued the search for the subtree | (hostb) and issued the search for the subtree | |||
"OU=People,DC=Example,DC=NET", the server might respond as follows: | <OU=People,DC=Example,DC=NET>, the server might respond as follows: | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 24 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
SearchResultEntry for OU=People,DC=Example,DC=NET | SearchResultEntry for OU=People,DC=Example,DC=NET | |||
SearchResultReference { | SearchResultReference { | |||
ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } | ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } | |||
SearchResultReference { | ||||
ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } | ||||
SearchResultDone (success) | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 24 | Similarly, if a singleLevel search of <DC=Example,DC=NET> is | |||
Lightweight Directory Access Protocol Version 3 | requested to the contacted server, it may return the following: | |||
SearchResultEntry for CN=Manager,DC=Example,DC=NET | ||||
SearchResultReference { | SearchResultReference { | |||
ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } | 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) | SearchResultDone (success) | |||
If the contacted server does not hold the base object for the search, | If the contacted server does not hold the base object for the search, | |||
then it will return a referral to the client. For example, if the | then it will return a referral to the client. For example, if the | |||
client requests a subtree search of "DC=Example,DC=ORG" to hosta, the | client requests a subtree search of <DC=Example,DC=ORG> to hosta, the | |||
server may return only a SearchResultDone containing a referral. | server may return only a SearchResultDone containing a referral. | |||
SearchResultDone (referral) { | SearchResultDone (referral) { | |||
ldap://hostg/DC=Example,DC=ORG??sub } | ldap://hostg/DC=Example,DC=ORG??sub } | |||
4.6. Modify Operation | 4.6. Modify Operation | |||
The Modify Operation allows a client to request that a modification | The Modify Operation allows a client to request that a modification | |||
of an entry be performed on its behalf by a server. The Modify | of an entry be performed on its behalf by a server. The Modify | |||
Request is defined as follows: | Request is defined as follows: | |||
ModifyRequest ::= [APPLICATION 6] SEQUENCE { | ModifyRequest ::= [APPLICATION 6] SEQUENCE { | |||
object LDAPDN, | object LDAPDN, | |||
changes SEQUENCE OF change SEQUENCE { | changes SEQUENCE OF change SEQUENCE { | |||
operation ENUMERATED { | operation ENUMERATED { | |||
add (0), | add (0), | |||
delete (1), | delete (1), | |||
replace (2) }, | replace (2) }, | |||
modification PartialAttribute } } | modification PartialAttribute } } | |||
Parameters of the Modify Request are: | Fields of the Modify Request are: | |||
- object: The name of the object to be modified. The value of this | - object: The name of the object to be modified. The value of this | |||
field contains the DN of the entry to be modified. The server | field contains the DN of the entry to be modified. The server | |||
SHALL NOT perform any alias dereferencing in determining the | SHALL NOT perform any alias dereferencing in determining the | |||
object to be modified. | object to be modified. | |||
- changes: A list of modifications to be performed on the entry. The | - changes: A list of modifications to be performed on the entry. The | |||
entire list of modifications MUST be performed in the order they | entire list of modifications MUST be performed in the order they | |||
are listed, as a single atomic operation. While individual | are listed as a single atomic operation. While individual | |||
modifications may violate certain aspects of the directory schema | modifications may violate certain aspects of the directory schema | |||
(such as the object class definition and DIT content rule), the | (such as the object class definition and DIT content rule), the | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 25 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
resulting entry after the entire list of modifications is | resulting entry after the entire list of modifications is | |||
performed MUST conform to the requirements of the directory | performed MUST conform to the requirements of the directory schema | |||
schema. | [Models]. | |||
- operation: Used to specify the type of modification being | - operation: Used to specify the type of modification being | |||
performed. Each operation type acts on the following | performed. Each operation type acts on the following | |||
modification. The values of this field have the following | modification. The values of this field have the following | |||
semantics respectively: | semantics respectively: | |||
add: add values listed to the modification attribute, | add: add values listed to the modification attribute, | |||
creating the attribute if necessary; | creating the attribute if necessary; | |||
delete: delete values listed from the modification | delete: delete values listed from the modification attribute, | |||
attribute, removing the entire attribute if no values are | removing the entire attribute if no values are listed, or if | |||
all current values of the attribute are listed for deletion; | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 25 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
listed, or if all current values of the attribute are | ||||
listed for deletion; | ||||
replace: replace all existing values of the modification | replace: replace all existing values of the modification | |||
attribute with the new values listed, creating the | attribute with the new values listed, creating the attribute | |||
attribute if it did not already exist. A replace with no | if it did not already exist. A replace with no value will | |||
value will delete the entire attribute if it exists, and is | delete the entire attribute if it exists, and is ignored if | |||
ignored if the attribute does not exist. | the attribute does not exist. | |||
- modification: A PartialAttribute (which may have an empty SET of | - modification: A PartialAttribute (which may have an empty SET | |||
vals) used to hold the attribute type or attribute type and | of vals) used to hold the attribute type or attribute type and | |||
values being modified. | values being modified. | |||
Upon receipt of a Modify Request, the server attempts to perform the | Upon receipt of a Modify Request, the server attempts to perform the | |||
necessary modifications to the DIT and returns the result in a Modify | necessary modifications to the DIT and returns the result in a Modify | |||
Response, defined as follows: | Response, defined as follows: | |||
ModifyResponse ::= [APPLICATION 7] LDAPResult | ModifyResponse ::= [APPLICATION 7] LDAPResult | |||
The server will return to the client a single Modify Response | The server will return to the client a single Modify Response | |||
indicating either the successful completion of the DIT modification, | indicating either the successful completion of the DIT modification, | |||
or the reason that the modification failed. Note that due to the | or the reason that the modification failed. Due to the requirement | |||
requirement for atomicity in applying the list of modifications in | for atomicity in applying the list of modifications in the Modify | |||
the Modify Request, the client may expect that no modifications of | Request, the client may expect that no modifications of the DIT have | |||
the DIT have been performed if the Modify Response received indicates | been performed if the Modify Response received indicates any sort of | |||
any sort of error, and that all requested modifications have been | error, and that all requested modifications have been performed if | |||
performed if the Modify Response indicates successful completion of | the Modify Response indicates successful completion of the Modify | |||
the Modify Operation. If the association changes or the connection | Operation. If the association changes or the connection fails, | |||
fails, whether the modification occurred or not is indeterminate. | whether the modification occurred or not is indeterminate. | |||
The Modify Operation cannot be used to remove from an entry any of | The Modify Operation cannot be used to remove from an entry any of | |||
its distinguished values, i.e. those values which form the entry's | its distinguished values, i.e. those values which form the entry's | |||
relative distinguished name. An attempt to do so will result in the | relative distinguished name. An attempt to do so will result in the | |||
server returning the notAllowedOnRDN result code. The Modify DN | server returning the notAllowedOnRDN result code. The Modify DN | |||
Operation described in Section 4.9 is used to rename an entry. | Operation described in Section 4.9 is used to rename an entry. | |||
Note that due to the simplifications made in LDAP, there is not a | Note that due to the simplifications made in LDAP, there is not a | |||
direct mapping of the changes in an LDAP ModifyRequest onto the | direct mapping of the changes in an LDAP ModifyRequest onto the | |||
changes of a DAP ModifyEntry operation, and different implementations | changes of a DAP ModifyEntry operation, and different implementations | |||
of LDAP-DAP gateways may use different means of representing the | of LDAP-DAP gateways may use different means of representing the | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 26 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
change. If successful, the final effect of the operations on the | change. If successful, the final effect of the operations on the | |||
entry MUST be identical. | entry MUST be identical. | |||
4.7. Add Operation | 4.7. Add Operation | |||
The Add Operation allows a client to request the addition of an entry | The Add Operation allows a client to request the addition of an entry | |||
into the Directory. The Add Request is defined as follows: | into the Directory. The Add Request is defined as follows: | |||
AddRequest ::= [APPLICATION 8] SEQUENCE { | AddRequest ::= [APPLICATION 8] SEQUENCE { | |||
entry LDAPDN, | entry LDAPDN, | |||
attributes AttributeList } | attributes AttributeList } | |||
AttributeList ::= SEQUENCE OF attribute Attribute | AttributeList ::= SEQUENCE OF attribute Attribute | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 26 | Fields of the Add Request are: | |||
Lightweight Directory Access Protocol Version 3 | ||||
Parameters of the Add Request are: | ||||
- entry: the name of the entry to be added. Note that the server | - entry: the name of the entry to be added. The server SHALL NOT | |||
SHALL NOT dereference any aliases in locating the entry to be | dereference any aliases in locating the entry to be added. | |||
added. | ||||
- attributes: the list of attributes that make up the content of the | - attributes: the list of attributes that make up the content of the | |||
entry being added. Clients MUST include distinguished values | entry being added. Clients MUST include distinguished values | |||
(those forming the entry's own RDN) in this list, the objectClass | (those forming the entry's own RDN) in this list, the | |||
attribute, and values of any mandatory attributes of the listed | 'objectClass' attribute, and values of any mandatory attributes of | |||
object classes. Clients MUST NOT supply NO-USER-MODIFICATION | the listed object classes. Clients MUST NOT supply NO-USER- | |||
attributes such as the createTimestamp or creatorsName attributes, | MODIFICATION attributes such as the createTimestamp or | |||
since the server maintains these automatically. | creatorsName attributes, since the server maintains these | |||
automatically. | ||||
The entry named in the entry field of the AddRequest MUST NOT exist | The entry named in the entry field of the AddRequest MUST NOT exist | |||
for the AddRequest to succeed. The immediate superior (parent) of an | for the AddRequest to succeed. The immediate superior (parent) of an | |||
object or alias entry to be added MUST exist. For example, if the | object or alias entry to be added MUST exist. For example, if the | |||
client attempted to add "CN=JS,DC=Example,DC=NET", the | client attempted to add <CN=JS,DC=Example,DC=NET>, the | |||
"DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did | <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did | |||
exist, then the server would return the noSuchObject result code with | exist, then the server would return the noSuchObject result code with | |||
the matchedDN field containing "DC=NET". If the parent entry exists | the matchedDN field containing <DC=NET>. If the parent entry exists | |||
but is not in a naming context held by the server, the server SHOULD | but is not in a naming context [Section 5 of Models] held by the | |||
return a referral to the server holding the parent entry. | server, the server SHOULD return a referral to the server holding the | |||
parent entry. | ||||
Server implementations SHOULD NOT restrict where entries can be | Server implementations SHOULD NOT restrict where entries can be | |||
located in the Directory unless DIT structure rules are in place. | located in the Directory unless DIT structure rules are in place. | |||
Some servers allow the administrator to restrict the classes of | Some servers allow the administrator to restrict the classes of | |||
entries which can be added to the Directory. | entries which can be added to the Directory. | |||
Upon receipt of an Add Request, a server will attempt to add the | Upon receipt of an Add Request, a server will attempt to add the | |||
requested entry. The result of the add attempt will be returned to | requested entry. The result of the add attempt will be returned to | |||
the client in the Add Response, defined as follows: | the client in the Add Response, defined as follows: | |||
AddResponse ::= [APPLICATION 9] LDAPResult | AddResponse ::= [APPLICATION 9] LDAPResult | |||
A response of success indicates that the new entry is present in the | A response of success indicates that the new entry has been added to | |||
Directory. | the Directory. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 27 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.8. Delete Operation | 4.8. Delete Operation | |||
The Delete Operation allows a client to request the removal of an | The Delete Operation allows a client to request the removal of an | |||
entry from the Directory. The Delete Request is defined as follows: | entry from the Directory. The Delete Request is defined as follows: | |||
DelRequest ::= [APPLICATION 10] LDAPDN | DelRequest ::= [APPLICATION 10] LDAPDN | |||
The Delete Request consists of the name of the entry to be deleted. | 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 server SHALL NOT dereference aliases while resolving the name of | |||
the target entry to be removed. | the target entry to be removed. | |||
Only leaf entries (those with no subordinate entries) can be deleted | Only leaf entries (those with no subordinate entries) can be deleted | |||
with this operation. | with this operation. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 27 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Upon receipt of a Delete Request, a server will attempt to perform | Upon receipt of a Delete Request, a server will attempt to perform | |||
the entry removal requested and return the result in the Delete | the entry removal requested and return the result in the Delete | |||
Response defined as follows: | Response defined as follows: | |||
DelResponse ::= [APPLICATION 11] LDAPResult | DelResponse ::= [APPLICATION 11] LDAPResult | |||
4.9. Modify DN Operation | 4.9. Modify DN Operation | |||
The Modify DN Operation allows a client to change the Relative | The Modify DN Operation allows a client to change the Relative | |||
Distinguished Name (RDN) of an entry in the Directory, and/or to move | Distinguished Name (RDN) of an entry in the Directory, and/or to move | |||
a subtree of entries to a new location in the Directory. The Modify | a subtree of entries to a new location in the Directory. The Modify | |||
DN Request is defined as follows: | DN Request is defined as follows: | |||
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { | ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { | |||
entry LDAPDN, | entry LDAPDN, | |||
newrdn RelativeLDAPDN, | newrdn RelativeLDAPDN, | |||
deleteoldrdn BOOLEAN, | deleteoldrdn BOOLEAN, | |||
newSuperior [0] LDAPDN OPTIONAL } | newSuperior [0] LDAPDN OPTIONAL } | |||
Parameters of the Modify DN Request are: | Fields of the Modify DN Request are: | |||
- entry: the name of the entry to be changed. This entry may or may | - entry: the name of the entry to be changed. This entry may or may | |||
not have subordinate entries. Note that the server SHALL NOT | not have subordinate entries. | |||
dereference any aliases in locating the entry to be changed. | ||||
- newrdn: the new RDN of the entry. | - newrdn: the new RDN of the entry. | |||
- deleteoldrdn: a boolean parameter that controls whether the old | - deleteoldrdn: a boolean field that controls whether the old RDN | |||
RDN attribute values are to be retained as attributes of the | attribute values are to be retained as attributes of the entry, or | |||
entry, or deleted from the entry. | deleted from the entry. | |||
- newSuperior: if present, this is the name of an existing object | - newSuperior: if present, this is the name of an existing object | |||
entry which becomes the immediate superior (parent) of the | entry which becomes the immediate superior (parent) of the | |||
existing entry. | existing entry. | |||
The server SHALL NOT dereference any aliases in locating the objects | ||||
named in entry or newSuperior. | ||||
Sermersheim Internet-Draft - Expires Jul 2004 Page 28 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Upon receipt of a ModifyDNRequest, a server will attempt to perform | Upon receipt of a ModifyDNRequest, a server will attempt to perform | |||
the name change and return the result in the Modify DN Response, | the name change and return the result in the Modify DN Response, | |||
defined as follows: | defined as follows: | |||
ModifyDNResponse ::= [APPLICATION 13] LDAPResult | ModifyDNResponse ::= [APPLICATION 13] LDAPResult | |||
For example, if the entry named in the "entry" parameter was "cn=John | For example, if the entry named in the entry field was <cn=John | |||
Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the | Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the | |||
newSuperior parameter was absent, then this operation would attempt | newSuperior field was absent, then this operation would attempt to | |||
to rename the entry to be "cn=John Cougar Smith,c=US". If there was | rename the entry to be <cn=John Cougar Smith,c=US>. If there was | |||
already an entry with that name, the operation would fail with the | already an entry with that name, the operation would fail with the | |||
entryAlreadyExists result code. | entryAlreadyExists result code. | |||
The object named in newSuperior MUST exist. For example, if the | The object named in newSuperior MUST exist. For example, if the | |||
client attempted to add "CN=JS,DC=Example,DC=NET", the | client attempted to add <CN=JS,DC=Example,DC=NET>, the | |||
"DC=Example,DC=NET" entry did not exist, and the "DC=NET" entry did | <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did | |||
exist, then the server would return the noSuchObject result code with | exist, then the server would return the noSuchObject result code with | |||
the matchedDN field containing "DC=NET". | the matchedDN field containing <DC=NET>. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 28 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
If the deleteoldrdn parameter is TRUE, the values forming the old RDN | If the deleteoldrdn field is TRUE, the attribute values forming the | |||
are deleted from the entry. If the deleteoldrdn parameter is FALSE, | old RDN but not the new RDN are deleted from the entry. If the | |||
the values forming the old RDN will be retained as non-distinguished | deleteoldrdn field is FALSE, the attribute values forming the old RDN | |||
attribute values of the entry. The server MUST fail the operation and | will be retained as non-distinguished attribute values of the entry. | |||
return an error in the result code if the setting of the deleteoldrdn | The server MUST fail the operation and return an error in the result | |||
parameter would cause a schema inconsistency in the entry. | code if the setting of the deleteoldrdn field would cause a schema | |||
inconsistency in the entry. | ||||
Note that X.500 restricts the ModifyDN operation to only affect | Note that X.500 restricts the ModifyDN operation to only affect | |||
entries that are contained within a single server. If the LDAP server | entries that are contained within a single server. If the LDAP server | |||
is mapped onto DAP, then this restriction will apply, and the | is mapped onto DAP, then this restriction will apply, and the | |||
affectsMultipleDSAs result code will be returned if this error | affectsMultipleDSAs result code will be returned if this error | |||
occurred. In general, clients MUST NOT expect to be able to perform | occurred. In general, clients MUST NOT expect to be able to perform | |||
arbitrary movements of entries and subtrees between servers or | arbitrary movements of entries and subtrees between servers or | |||
between naming contexts. | between naming contexts. | |||
4.10. Compare Operation | 4.10. Compare Operation | |||
The Compare Operation allows a client to compare an assertion | The Compare Operation allows a client to compare an assertion value | |||
provided with an entry in the Directory. The Compare Request is | with the values of a particular attribute in a particular entry in | |||
defined as follows: | the Directory. The Compare Request is defined as follows: | |||
CompareRequest ::= [APPLICATION 14] SEQUENCE { | CompareRequest ::= [APPLICATION 14] SEQUENCE { | |||
entry LDAPDN, | entry LDAPDN, | |||
ava AttributeValueAssertion } | ava AttributeValueAssertion } | |||
Parameters of the Compare Request are: | Fields of the Compare Request are: | |||
- entry: the name of the entry to be compared. Note that the server | - entry: the name of the entry to be compared. The server SHALL NOT | |||
SHALL NOT dereference any aliases in locating the entry to be | dereference any aliases in locating the entry to be compared. | |||
compared. | ||||
- ava: the assertion with which an attribute in the entry is to be | - ava: holds the attribute description and assertion value with | |||
compared. | which an attribute in the entry is to be compared. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 29 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
Upon receipt of a Compare Request, a server will attempt to perform | Upon receipt of a Compare Request, a server will attempt to perform | |||
the requested comparison using the EQUALITY matching rule for the | the requested comparison and return the result in the Compare | |||
attribute type and return the result in the Compare Response, defined | Response, defined as follows: | |||
as follows: | ||||
CompareResponse ::= [APPLICATION 15] LDAPResult | CompareResponse ::= [APPLICATION 15] LDAPResult | |||
If the operation succeeds (e.g. the attribute or subtype is present | ||||
and access controls allow comparison), the resultCode field will be | ||||
compareTrue if the assertion value in the ava field is equivalent to | ||||
any value of the attribute or subtype (according to the attribute's | ||||
EQUALITY matching rule). Otherwise compareFalse is returned in the | ||||
resultCode field. | ||||
In the event that the attribute or subtype is not present in the | In the event that the attribute or subtype is not present in the | |||
entry, the resultCode field is set to noSuchAttribute. If the | entry, the resultCode field is set to noSuchAttribute. If the | |||
attribute is unknown, the resultCode is set to | attribute is unknown, the resultCode is set to | |||
undefinedAttributeType. Note that errors and the result of comparison | undefinedAttributeType. Note that errors and the result of comparison | |||
are all returned in the same construct. | are all returned in the same construct. | |||
Note that some directory systems may establish access controls which | Note that some directory systems may establish access controls which | |||
permit the values of certain attributes (such as userPassword) to be | permit the values of certain attributes (such as userPassword) to be | |||
compared but not interrogated by other means. | compared but not interrogated by other means. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 29 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.11. Abandon Operation | 4.11. Abandon Operation | |||
The function of the Abandon Operation is to allow a client to request | The function of the Abandon Operation is to allow a client to request | |||
that the server abandon an outstanding operation. The Abandon Request | that the server abandon an outstanding operation. The Abandon Request | |||
is defined as follows: | is defined as follows: | |||
AbandonRequest ::= [APPLICATION 16] MessageID | AbandonRequest ::= [APPLICATION 16] MessageID | |||
The MessageID MUST be that of an operation which was requested | The MessageID is that of an operation which was requested earlier in | |||
earlier in this LDAP association. The abandon request itself has its | this LDAP association. The abandon request itself has its own message | |||
own message id. This is distinct from the id of the earlier operation | id. This is distinct from the id of the earlier operation being | |||
being abandoned. | abandoned. | |||
There is no response defined in the Abandon operation. Upon receipt | There is no response defined in the Abandon operation. Upon receipt | |||
of an AbandonRequest, the server MAY abandon the operation identified | of an AbandonRequest, the server MAY abandon the operation identified | |||
by the MessageID. Operation responses are not sent for successfully | by the MessageID. Operation responses are not sent for successfully | |||
abandoned operations, thus the application of the Abandon operation | abandoned operations, thus the application of the Abandon operation | |||
is limited to uses where the client does not require an indication of | is limited to uses where the client does not require an indication of | |||
its outcome. | its outcome. | |||
Abandon and Unbind operations cannot be abandoned. The ability to | Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. | |||
abandon other (particularly update) operations is at the discretion | The ability to abandon other (particularly update) operations is at | |||
of the server. | the discretion of the server. | |||
In the event that a server receives an Abandon Request on a Search | In the event that a server receives an Abandon Request on a Search | |||
Operation in the midst of transmitting responses to the search, that | Operation in the midst of transmitting responses to the search, that | |||
server MUST cease transmitting entry responses to the abandoned | server MUST cease transmitting entry responses to the abandoned | |||
request immediately, and MUST NOT send the SearchResponseDone. Of | request immediately, and MUST NOT send the SearchResponseDone. Of | |||
course, the server MUST ensure that only properly encoded LDAPMessage | course, the server MUST ensure that only properly encoded LDAPMessage | |||
PDUs are transmitted. | PDUs are transmitted. | |||
Clients MUST NOT send abandon requests for the same operation | Sermersheim Internet-Draft - Expires Jul 2004 Page 30 | |||
Lightweight Directory Access Protocol Version 3 | ||||
Clients should not send abandon requests for the same operation | ||||
multiple times, and MUST also be prepared to receive results from | multiple times, and MUST also be prepared to receive results from | |||
operations it has abandoned (since these may have been in transit | operations it has abandoned (since these may have been in transit | |||
when the abandon was requested, or are not able to be abandoned). | when the abandon was requested, or are not able to be abandoned). | |||
Servers MUST discard abandon requests for message IDs they do not | Servers MUST discard abandon requests for message IDs they do not | |||
recognize, for operations which cannot be abandoned, and for | recognize, for operations which cannot be abandoned, and for | |||
operations which have already been abandoned. | operations which have already been abandoned. | |||
4.12. Extended Operation | 4.12. Extended Operation | |||
skipping to change at line 1680 | skipping to change at line 1703 | |||
services not already available in the protocol. For example, to add | services not already available in the protocol. For example, to add | |||
operations to install transport layer security (see Section 4.13). | operations to install transport layer security (see Section 4.13). | |||
The extended operation allows clients to make requests and receive | The extended operation allows clients to make requests and receive | |||
responses with predefined syntaxes and semantics. These may be | responses with predefined syntaxes and semantics. These may be | |||
defined in RFCs or be private to particular implementations. | defined in RFCs or be private to particular implementations. | |||
Each extended operation consists of an extended request and an | Each extended operation consists of an extended request and an | |||
extended response. | extended response. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 30 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | |||
requestName [0] LDAPOID, | requestName [0] LDAPOID, | |||
requestValue [1] OCTET STRING OPTIONAL } | requestValue [1] OCTET STRING OPTIONAL } | |||
The requestName is a dotted-decimal representation of the unique | The requestName is a dotted-decimal representation of the unique | |||
OBJECT IDENTIFIER corresponding to the request. The requestValue is | OBJECT IDENTIFIER corresponding to the request. The requestValue is | |||
information in a form defined by that request, encapsulated inside an | information in a form defined by that request, encapsulated inside an | |||
OCTET STRING. | OCTET STRING. | |||
The server will respond to this with an LDAPMessage containing the | The server will respond to this with an LDAPMessage containing an | |||
ExtendedResponse. | ExtendedResponse. | |||
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { | ExtendedResponse ::= [APPLICATION 24] SEQUENCE { | |||
COMPONENTS OF LDAPResult, | COMPONENTS OF LDAPResult, | |||
responseName [10] LDAPOID OPTIONAL, | responseName [10] LDAPOID OPTIONAL, | |||
responseValue [11] OCTET STRING OPTIONAL } | responseValue [11] OCTET STRING OPTIONAL } | |||
The responseName is typically not required to be present as the | The responseName is typically not required to be present as the | |||
syntax and semantics of the response (including the format of the | syntax and semantics of the response (including the format of the | |||
responseValue) is implicitly known and associated with the request by | responseValue) is implicitly known and associated with the request by | |||
the messageID. | the messageID. | |||
If the requestName is not recognized by the server, the server MUST | If the requestName is not recognized by the server, the server MUST | |||
NOT provide a responseName nor a responseValue and MUST return a | NOT provide a responseName nor a responseValue and MUST return a | |||
resultCode of protocolError. | resultCode of protocolError. | |||
The requestValue and responseValue fields contain any information | The requestValue and responseValue fields contain any information | |||
associated with the operation. The format of these fields is defined | associated with the operation. The format of these fields is defined | |||
by the specification of the extended operation. Implementations MUST | by the specification of the extended operation. Implementations MUST | |||
be prepared to handle arbitrary contents of these fields, including | be prepared to handle arbitrary contents of these fields, including | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 31 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
zero bytes. Values that are defined in terms of ASN.1 and BER encoded | zero bytes. Values that are defined in terms of ASN.1 and BER encoded | |||
according to Section 5.1, also follow the extensibility rules in | according to Section 5.1, also follow the extensibility rules in | |||
Section 4. | Section 4. | |||
It is RECOMMENDED that servers list the requestName of extended | It is RECOMMENDED that servers list the requestName of extended | |||
operations they support in the supportedExtension attribute [Models] | operations they support in the 'supportedExtension' attribute of the | |||
of the root DSE. | root DSE [Models]. | |||
Extended operations may be specified in other documents. The | Extended operations may be specified in other documents. The | |||
specification of an extended operation consists of: | specification of an extended operation consists of: | |||
- the OBJECT IDENTIFIER assigned to the requestName (and possibly | - the OBJECT IDENTIFIER assigned to the requestName (and possibly | |||
responseName), | responseName), | |||
- the format of the contents of the requestValue and responseValue | - the format of the contents of the requestValue and responseValue | |||
(if any), | (if any), and | |||
- the semantics of the operation, | - the semantics of the operation. | |||
4.13. StartTLS Operation | 4.13. StartTLS Operation | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 31 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
The Start Transport Layer Security (StartTLS) operation provides the | The Start Transport Layer Security (StartTLS) operation provides the | |||
ability to establish Transport Layer Security ([TLS]) on an LDAP | ability to establish Transport Layer Security ([TLS]) on an LDAP | |||
connection. The StartTLS operation is defined using the extended | connection. The StartTLS operation is defined using the extended | |||
operation mechanism described in Section 4.12. | operation mechanism described in Section 4.12. | |||
4.13.1. StartTLS Request | 4.13.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 PDU to the server. The StartTLS request is defined in terms | |||
of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", | of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037", | |||
and the requestValue field is always absent. | and the requestValue field is always absent. | |||
The client MUST NOT send any PDUs on this connection following this | The client MUST NOT send any PDUs on this connection following this | |||
request until it receives a StartTLS extended response. | request until it receives a StartTLS extended response and completes | |||
TLS negotiations. | ||||
4.13.2. StartTLS Response | 4.13.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 StartTLS | MUST return a StartTLS response PDU to the requestor. The | |||
response responseName is also "1.3.6.1.4.1.1466.20037", and the | responseName is also "1.3.6.1.4.1.1466.20037", and the responseValue | |||
response field is absent. | field is absent. | |||
The server MUST set the resultCode field to either success or one of | The server provides a resultCode field to either success or one of | |||
the other values outlined in Section 4.13.2.2. | the other values outlined in Section 4.13.2.2. | |||
4.13.2.1. "Success" Response | 4.13.2.1. "Success" Response | |||
If the StartTLS Response contains a result code of success, this | If the StartTLS Response contains a resultCode of success, this | |||
indicates that the server is willing and able to negotiate TLS. Refer | indicates that the server is willing and able to negotiate TLS. Refer | |||
to Section 5.3 of [AuthMeth] for details. | to Section 4 of [AuthMeth] for details. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 32 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
4.13.2.2. Response other than "success" | 4.13.2.2. Response other than "success" | |||
If the ExtendedResponse contains a result code other than success, | If the ExtendedResponse contains a result code other than success, | |||
this indicates that the server is unwilling or unable to negotiate | this indicates that the server is unwilling or unable to negotiate | |||
TLS. The following result codes have these meanings for this | TLS. The following result codes have these meanings for this | |||
operation: | operation: | |||
- operationsError: operations sequencing incorrect; e.g. TLS is | - operationsError: operations sequencing incorrect; e.g. TLS is | |||
already established. | already established. | |||
- protocolError: TLS is not supported or incorrect PDU structure. | - protocolError: TLS is not supported or incorrect PDU structure. | |||
- unavailable: Some major problem with TLS, or the server is | - unavailable: Some major problem with TLS, or the server is | |||
shutting down. | shutting down. | |||
The server MUST return operationsError if the client violates any of | The server MUST return operationsError if the client violates any of | |||
the StartTLS extended operation sequencing requirements described in | the StartTLS extended operation sequencing requirements described in | |||
Section 5.3 of [AuthMeth]. | Section 4 of [AuthMeth]. | |||
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 MUST set the resultCode field to protocolError. | configuration), it MUST return the protocolError resultCode. The | |||
The client's current association is unaffected if the server does not | client's current association is unaffected if the server does not | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 32 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
support TLS. The client may proceed with any LDAP operation, or it | support TLS. The client may proceed with any LDAP operation, or it | |||
may close the connection. | may close the connection. | |||
The server MUST return unavailable if it supports TLS but cannot | The server MUST return unavailable if it supports TLS but cannot | |||
establish a TLS connection for some reason, e.g. the certificate | establish a TLS connection for some reason, e.g. the certificate | |||
server not responding, it cannot contact its TLS implementation, or | server not responding, it cannot contact its TLS implementation, or | |||
if the server is in process of shutting down. The client may retry | if the server is in process of shutting down. The client may retry | |||
the StartTLS operation, or it may proceed with any other LDAP | the StartTLS operation, or it may proceed with any other LDAP | |||
operation, or it may close the LDAP connection. | operation, or it may close the LDAP connection. | |||
4.13.3. Closing a TLS Connection | 4.13.3. Closing a TLS Connection | |||
Two forms of TLS connection closure -- graceful and abrupt -- are | Two forms of TLS connection closure -- graceful and abrupt -- are | |||
supported. | supported. These do not involve LDAP PDUs, but are preformed at the | |||
underlying layers. | ||||
4.13.3.1. Graceful Closure | 4.13.3.1. Graceful Closure | |||
Either the client or server MAY terminate the TLS connection and | Either the client or server MAY terminate the TLS connection and | |||
leave the LDAP connection intact by sending and receiving a TLS | leave the LDAP connection intact by sending and receiving a TLS | |||
closure alert. | closure alert. | |||
The initiating protocol peer sends the TLS closure alert. If it | The initiating protocol peer sends the TLS closure alert. If it | |||
wishes to leave the LDAP connection intact, it then MUST cease to | wishes to leave the LDAP connection intact, it then MUST cease to | |||
send further PDUs and MUST ignore any received PDUs until it receives | send further PDUs and MUST ignore any received PDUs until it receives | |||
a TLS closure alert from the other peer. | a TLS closure alert from the other peer. | |||
Once the initiating protocol peer receives a TLS closure alert from | Once the initiating protocol peer receives a TLS closure alert from | |||
the other peer it MAY send and receive LDAP PDUs. | the other peer it MAY send and receive LDAP PDUs. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 33 | ||||
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 underlying LDAP connection intact. In this case, | choose to allow the underlying LDAP connection to remain intact. In | |||
it MUST immediately transmit a TLS closure alert. Following this, it | this case, it MUST immediately transmit a TLS closure alert. | |||
MAY send and receive LDAP PDUs. | Following this, it MAY send and receive LDAP PDUs. | |||
Protocol peers MAY drop the underlying LDAP connection after sending | Protocol peers MAY drop the underlying LDAP connection after sending | |||
or receiving a TLS closure alert. | or receiving a TLS closure alert. | |||
After the TLS connection has been closed, the server MUST NOT send | After the TLS connection has been closed, the server MUST NOT send | |||
responses to any request message received before the TLS closure. | responses to any request message received before the TLS closure. | |||
Thus, clients wishing to receive responses to messages sent while the | Thus, clients wishing to receive responses to messages sent while the | |||
TLS connection is intact MUST wait for those message responses before | TLS connection is intact MUST wait for those message responses before | |||
sending the TLS closure alert. | sending the TLS closure alert. | |||
4.13.3.2. Abrupt Closure | 4.13.3.2. Abrupt Closure | |||
Either the client or server MAY abruptly close the TLS connection by | Either the client or server MAY abruptly close the TLS connection by | |||
dropping the underlying transfer protocol connection. In this | dropping the underlying transfer protocol connection. In this | |||
circumstance, a server MAY send the client a Notice of Disconnection | circumstance, a server MAY send the client a Notice of Disconnection | |||
before dropping the underlying LDAP connection. | before dropping the underlying LDAP connection. Outstanding | |||
operations are handled as specified in Section 5.2. | ||||
5. Protocol Element Encodings and Transfer | 5. Protocol Element Encodings and Transfer | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 33 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
One underlying service, LDAP over TCP, is defined here. This service | One underlying service, LDAP over TCP, is defined here. This service | |||
is generally applicable to applications providing or consuming X.500- | is generally applicable to applications providing or consuming X.500- | |||
based directory services on the Internet. | based directory services on the Internet. | |||
Implementations of LDAP over TCP MUST implement the mapping as | Implementations of LDAP over TCP MUST implement the mapping as | |||
described in Section 5.2.1 | described in Section 5.2.1 | |||
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: | |||
(1) Only the definite form of length encoding is used. | - Only the definite form of length encoding is used. | |||
(2) OCTET STRING values are encoded in the primitive form only. | - OCTET STRING values are encoded in the primitive form only. | |||
(3) If the value of a BOOLEAN type is true, the encoding of the | - If the value of a BOOLEAN type is true, the encoding of the value | |||
value octet is set to hex "FF". | octet is set to hex "FF". | |||
(4) If a value of a type is its default value, it is absent. Only | - If a value of a type is its default value, it is absent. Only some | |||
some BOOLEAN and INTEGER types have default values in this | BOOLEAN and INTEGER types have default values in this protocol | |||
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. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 34 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
These restrictions do not apply to ASN.1 types encapsulated inside of | These restrictions do not apply to ASN.1 types encapsulated inside of | |||
OCTET STRING values, such as attribute values, unless otherwise | OCTET STRING values, such as attribute values, unless otherwise | |||
stated. | stated. | |||
5.2. Transfer Protocols | 5.2. Transfer Protocols | |||
This protocol is designed to run over connection-oriented, reliable | This protocol is designed to run over connection-oriented, reliable | |||
transports, with all 8 bits in an octet being significant in the data | transports, with all 8 bits in an octet being significant in the data | |||
stream. | stream. Protocol operations are tied to a connection, thus if the | |||
connection is closed or dropped, the operation is aborted. When this | ||||
happens, any outstanding operations on the server are, when possible, | ||||
abandoned, and when not possible, completed without transmission of | ||||
the response. Also, if the connection is closed or dropped, the | ||||
client MUST NOT assume that any outstanding requests which modified | ||||
the Directory have succeeded or failed. | ||||
5.2.1. Transmission Control Protocol (TCP) | 5.2.1. Transmission Control Protocol (TCP) | |||
The encoded LDAPMessage PDUs are mapped directly onto the [TCP] | The encoded LDAPMessage PDUs are mapped directly onto the [TCP] | |||
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 assigned port, 389. Servers may | provide a protocol listener on the Internet Assigned Numbers | |||
Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may | ||||
instead provide a listener on a different port number. Clients MUST | 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. | |||
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] | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 34 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
mechanism. SASL allows for integrity and privacy services to be | mechanism. SASL allows for integrity and privacy services to be | |||
negotiated. | negotiated. | |||
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. | |||
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. | |||
skipping to change at line 1924 | skipping to change at line 1953 | |||
that have authenticated anonymously [AuthMeth]. | that have authenticated anonymously [AuthMeth]. | |||
Requirements of authentication methods, SASL mechanisms, and TLS are | Requirements of authentication methods, SASL mechanisms, and TLS are | |||
described in [AuthMeth]. | 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 bind request nor the resultCode, diagnosticMessage, or | fields of the bind request nor the resultCode, diagnosticMessage, or | |||
referral fields of the bind response nor of any information contained | referral fields of the bind response nor of any information contained | |||
in controls attached to bind request or responses. Thus information | in controls attached to bind request or responses. Thus information | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 35 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
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 an identity | Server implementors should plan for the possibility of an identity | |||
associated with an LDAP connection being deleted, renamed, or | associated with an LDAP connection being deleted, renamed, or | |||
modified, and take appropriate actions to prevent insecure side | modified, and take appropriate actions to prevent insecure side | |||
effects. Likewise, server implementors should plan for the | effects. Likewise, server implementors should plan for the | |||
possibility of an associated identity's credentials becoming invalid, | possibility of an associated identity's credentials becoming invalid, | |||
or an identities privileges being changed. The way in which these | or an identity's privileges being changed. The ways in which these | |||
issues are addressed are application | issues are addressed are application and/or implementation specific. | |||
and/or implementation specific. | ||||
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. | |||
Protocol servers may return referrals which redirect protocol clients | Servers may return referrals or search result references which | |||
to peer servers. It is possible for a rogue application to inject | redirect clients to peer servers. It is possible for a rogue | |||
such referrals into the data stream in an attempt to redirect a | application to inject such referrals into the data stream in an | |||
client to a rogue server. Protocol clients are advised to be aware of | attempt to redirect a client to a rogue server. Clients are advised | |||
this, and possibly reject referrals when confidentiality measures are | to be aware of this, and possibly reject referrals when | |||
not in place. Protocol clients are advised to reject referrals from | confidentiality measures are not in place. Clients are advised to | |||
the StartTLS operation. | reject referrals from the StartTLS operation. | |||
Protocol peers MUST be prepared to handle invalid and arbitrary | Protocol peers MUST be prepared to handle invalid and arbitrary | |||
length protocol encodings. A number of LDAP security advisories are | length protocol encodings. A number of LDAP security advisories are | |||
available through [CERT]. | available through [CERT]. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 35 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
7. Acknowledgements | 7. Acknowledgements | |||
This document updates RFC 2251 by Mark Wahl, Tim Howes, and Steve | This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve | |||
Kille. It also updates RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and | Kille. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, | |||
Mark Wahl. Their work along with the input of individuals of the IETF | and Mark Wahl. Their work along with the input of individuals of the | |||
ASID, LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully | IETF ASID, LDAPEXT, LDUP, LDAPBIS, and other Working Groups is | |||
acknowledged. | gratefully acknowledged. | |||
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", RFC 2234, November 1997. | |||
[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). | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 36 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, | [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, | |||
"Information technology - ASN.1 encoding rules: | "Information technology - ASN.1 encoding rules: | |||
Specification of Basic Encoding Rules (BER), Canonical | Specification of Basic Encoding Rules (BER), Canonical | |||
Encoding Rules (CER) and Distinguished Encoding Rules | Encoding Rules (CER) and Distinguished Encoding Rules | |||
(DER)", 2002. | (DER)", 2002. | |||
[IP] Postel, J., "Internet Protocol", STD5 and RFC 791, | [IP] Postel, J., "Internet Protocol", STD5 and RFC 791, | |||
September 1981 | September 1981 | |||
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - | [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - | |||
skipping to change at line 2013 | skipping to change at line 2045 | |||
[LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf- | [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf- | |||
ldapbis-url-xx.txt, (a work in progress). | ldapbis-url-xx.txt, (a work in progress). | |||
[Models] Zeilenga, K., "LDAP: Directory Information Models", draft- | [Models] Zeilenga, K., "LDAP: Directory Information Models", draft- | |||
ietf-ldapbis-models-xx.txt (a work in progress). | ietf-ldapbis-models-xx.txt (a work in progress). | |||
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", | [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", | |||
draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). | draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 36 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[SASL] Melnikov, A., "Simple Authentication and Security Layer", | [SASL] Melnikov, A., "Simple Authentication and Security Layer", | |||
draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). | draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). | |||
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and | [SASLPrep] Zeilenga, K., "Stringprep profile for user names and | |||
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in | passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in | |||
progress). | progress). | |||
[StringPrep] Hoffman P. and M. Blanchet, "Preparation of | [StringPrep] Hoffman P. and M. Blanchet, "Preparation of | |||
Internationalized Strings ('stringprep')", draft-hoffman- | Internationalized Strings ('stringprep')", draft-hoffman- | |||
rfc3454bis-xx.txt, a work in progress. | rfc3454bis-xx.txt, a work in progress. | |||
skipping to change at line 2037 | skipping to change at line 2066 | |||
[Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching | [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching | |||
Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in | Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in | |||
progress). | progress). | |||
[TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC | [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC | |||
793, September 1981 | 793, September 1981 | |||
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", | [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", | |||
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. | draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 37 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version | [Unicode] The Unicode Consortium, "The Unicode Standard, Version | |||
3.2.0" is defined by "The Unicode Standard, Version 3.0" | 3.2.0" is defined by "The Unicode Standard, Version 3.0" | |||
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), | |||
as amended by the "Unicode Standard Annex #27: Unicode | as amended by the "Unicode Standard Annex #27: Unicode | |||
3.1" (http://www.unicode.org/reports/tr27/) and by the | 3.1" (http://www.unicode.org/reports/tr27/) and by the | |||
"Unicode Standard Annex #28: Unicode 3.2" | "Unicode Standard Annex #28: Unicode 3.2" | |||
(http://www.unicode.org/reports/tr28/). | (http://www.unicode.org/reports/tr28/). | |||
[URI] Berners-Lee, T., Fielding, R., and L. Masinter Uniform | [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifiers (URI): Generic Syntax", RFC 2396, | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |||
August 1998. | August 1998. | |||
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode | [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO | |||
and ISO 10646", STD63 and RFC3629. | 10646", STD63 and RFC3629, November 2003. | |||
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, | [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, | |||
Models and Service", 1993. | Models and Service", 1993. | |||
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. | [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. | |||
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service | [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service | |||
Definition", 1993. | Definition", 1993. | |||
9. Informative References | 9. Informative References | |||
[CERT] the CERT(R) Center, (http://www.cert.org) | [CERT] The CERT(R) Center, http://www.cert.org | |||
10. IANA Considerations | [PortReg] IANA, "Port Numbers", | |||
http://www.iana.org/assignments/port-numbers | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 37 | 10. IANA Considerations | |||
Lightweight Directory Access Protocol Version 3 | ||||
It is requested that the Internet Assigned Numbers Authority (IANA) | It is requested that the Internet Assigned Numbers Authority (IANA) | |||
update the occurrence of "RFC XXXX" in Appendix B with this RFC | update the LDAP result code registry to indicate that this document | |||
number at publication. | provides the definitive technical specification for result codes 0- | |||
36, 48-54, 64-70, 80-90. | ||||
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 Start TLS | ||||
(1.3.6.1.4.1.1466.20037) extended operation. | ||||
It is requested that the IANA update the occurrence of "RFC XXXX" in | ||||
Appendix B with this RFC number at publication. | ||||
11. Editor's Address | 11. Editor's Address | |||
Jim Sermersheim | Jim Sermersheim | |||
Novell, Inc. | Novell, Inc. | |||
1800 South Novell Place | 1800 South Novell Place | |||
Provo, Utah 84606, USA | Provo, Utah 84606, USA | |||
jimse@novell.com | jimse@novell.com | |||
+1 801 861-3088 | +1 801 861-3088 | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 38 | Sermersheim Internet-Draft - Expires Jul 2004 Page 38 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Appendix A - LDAP Result Codes | Appendix A - LDAP Result Codes | |||
This normative appendix details additional considerations regarding | This normative appendix details additional considerations regarding | |||
LDAP result codes and provides a brief, general description of each | LDAP result codes and provides a brief, general description of each | |||
LDAP result code enumerated in Section 4.1.10. | LDAP result code enumerated in Section 4.1.9. | |||
Additional result codes MAY be defined for use with extensions | Additional result codes MAY be defined for use with extensions | |||
[LDAPIANA]. Client implementations SHALL treat any result code which | [LDAPIANA]. Client implementations SHALL treat any result code which | |||
they do not recognize as an unknown error condition. | they do not recognize as an unknown error condition. | |||
A.1 Non-Error Result Codes | A.1 Non-Error Result Codes | |||
These result codes (called "non-error" result codes) do not indicate | These result codes (called "non-error" result codes) do not indicate | |||
an error condition: | an error condition: | |||
success (0), | success (0), | |||
compareTrue (6), | compareTrue (6), | |||
compareFalse (7), | compareFalse (7), | |||
referral (10), and | referral (10), and | |||
saslBindInProgress (14). | saslBindInProgress (14). | |||
The success, compareTrue, and compare result codes indicate | The success, compareTrue, and compareFalse result codes indicate | |||
successful completion (and, hence, are referred to as "successful" | successful completion (and, hence, are referred to as "successful" | |||
result codes). | result codes). | |||
The referral and saslBindInProgress result codes indicate the client | The referral and saslBindInProgress result codes indicate the client | |||
is required to take additional action to complete the operation | is required to take additional action to complete the operation. | |||
A.2 Result Codes | A.2 Result Codes | |||
Existing LDAP result codes are described as follows: | Existing LDAP result codes are described as follows: | |||
success (0) | success (0) | |||
Indicates the successful completion of an operation. Note: | Indicates the successful completion of an operation. Note: | |||
this code is not used with the compare operation. See | this code is not used with the compare operation. See | |||
compareTrue (5) and compareFalse (6). | compareTrue (5) and compareFalse (6). | |||
operationsError (1) | operationsError (1) | |||
Indicates that the operation is not properly sequenced with | Indicates that the operation is not properly sequenced with | |||
relation to other operations (of same or different type). | relation to other operations (of same or different type). | |||
For example, this code is returned if the client attempts to | For example, this code is returned if the client attempts to | |||
StartTLS [RFC2246] while there are other operations | StartTLS [TLS] while there are other operations outstanding | |||
outstanding or if TLS was already established. | or if TLS was already established. | |||
protocolError (2) | protocolError (2) | |||
Indicates the server received data which has incorrect | Indicates the server received data which has incorrect | |||
structure. | structure. | |||
For bind operation only, this code is also used to indicate | For bind operation only, this code is also used to indicate | |||
that the server does not support the requested protocol | that the server does not support the requested protocol | |||
version. | version. | |||
timeLimitExceeded (3) | Sermersheim Internet-Draft - Expires Jul 2004 Page 39 | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 39 | ||||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
timeLimitExceeded (3) | ||||
Indicates that the time limit specified by the client was | Indicates that the time limit specified by the client was | |||
exceeded before the operation could be completed. | exceeded before the operation could be completed. | |||
sizeLimitExceeded (4) | sizeLimitExceeded (4) | |||
Indicates that the size limit specified by the client was | Indicates that the size limit specified by the client was | |||
exceeded before the operation could be completed. | exceeded before the operation could be completed. | |||
compareFalse (5) | compareFalse (5) | |||
Indicates that the compare operation has successfully | Indicates that the compare operation has successfully | |||
completed and the assertion has evaluated to FALSE. | completed and the assertion has evaluated to FALSE. | |||
skipping to change at line 2170 | skipping to change at line 2210 | |||
strongAuthRequired (8) | strongAuthRequired (8) | |||
Indicates that the server has detected that an established | Indicates that the server has detected that an established | |||
security association between the client and server has | security association between the client and server has | |||
unexpectedly failed or been compromised, or that the server | unexpectedly failed or been compromised, or that the server | |||
now requires the client to authenticate using a strong(er) | now requires the client to authenticate using a strong(er) | |||
mechanism. | mechanism. | |||
referral (10) | referral (10) | |||
Indicates that a referral needs to be chased to complete the | Indicates that a referral needs to be chased to complete the | |||
operation (see Section 4.1.11). | operation (see Section 4.1.10). | |||
adminLimitExceeded (11) | adminLimitExceeded (11) | |||
Indicates that an administrative limit has been exceeded. | Indicates that an administrative limit has been exceeded. | |||
unavailableCriticalExtension (12) | unavailableCriticalExtension (12) | |||
Indicates that the server is unable or unwilling to perform a | Indicates that the server is unable or unwilling to perform a | |||
critical extension (see Section 4.1.12). | critical control (see Section 4.1.11). | |||
confidentialityRequired (13) | confidentialityRequired (13) | |||
Indicates that data confidentiality protections are required. | Indicates that data confidentiality protections are required. | |||
saslBindInProgress (14) | saslBindInProgress (14) | |||
Indicates the server requires the client to send a new bind | Indicates the server requires the client to send a new bind | |||
request, with the same SASL mechanism, to continue the | request, with the same SASL mechanism, to continue the | |||
authentication process (see Section 4.2). | authentication process (see Section 4.2). | |||
noSuchAttribute (16) | noSuchAttribute (16) | |||
Indicates that the named entry does not contain the specified | Indicates that the named entry does not contain the specified | |||
attribute or attribute value. | attribute or attribute value. | |||
undefinedAttributeType (17) | undefinedAttributeType (17) | |||
Indicates that a request field contains an unrecognized | Indicates that a request field contains an unrecognized | |||
attribute description. | attribute description. | |||
inappropriateMatching (18) | Sermersheim Internet-Draft - Expires Jul 2004 Page 40 | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 40 | ||||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Indicates that an attempt was made, e.g. in a filter, to use | inappropriateMatching (18) | |||
a matching rule not defined for the attribute type concerned. | Indicates that an attempt was made, e.g. in an assertion, to | |||
use a matching rule not defined for the attribute type | ||||
concerned. | ||||
constraintViolation (19) | constraintViolation (19) | |||
Indicates that the client supplied an attribute value which | Indicates that the client supplied an attribute value which | |||
does not conform to the constraints placed upon it by the | does not conform to the constraints placed upon it by the | |||
data model. | data model. | |||
For example, this code is returned when multiple values are | For example, this code is returned when multiple values are | |||
supplied to an attribute which has a SINGLE-VALUE constraint. | supplied to an attribute which has a SINGLE-VALUE constraint. | |||
attributeOrValueExists (20) | attributeOrValueExists (20) | |||
skipping to change at line 2253 | skipping to change at line 2293 | |||
provide some form of credentials. | provide some form of credentials. | |||
invalidCredentials (49) | invalidCredentials (49) | |||
Indicates that the provided credentials (e.g. the user's name | Indicates that the provided credentials (e.g. the user's name | |||
and password) are invalid. | and password) are invalid. | |||
insufficientAccessRights (50) | insufficientAccessRights (50) | |||
Indicates that the client does not have sufficient access | Indicates that the client does not have sufficient access | |||
rights to perform the operation. | rights to perform the operation. | |||
busy (51) | Sermersheim Internet-Draft - Expires Jul 2004 Page 41 | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 41 | ||||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
busy (51) | ||||
Indicates that the server is too busy to service the | Indicates that the server is too busy to service the | |||
operation. | operation. | |||
unavailable (52) | unavailable (52) | |||
Indicates that the server is shutting down or a subsystem | Indicates that the server is shutting down or a subsystem | |||
necessary to complete the operation is offline. | necessary to complete the operation is offline. | |||
unwillingToPerform (53) | unwillingToPerform (53) | |||
Indicates that the server is unwilling to perform the | Indicates that the server is unwilling to perform the | |||
operation. | operation. | |||
skipping to change at line 2293 | skipping to change at line 2332 | |||
Indicates that the operation is inappropriately attempting to | Indicates that the operation is inappropriately attempting to | |||
remove a value which forms the entry's relative distinguished | remove a value which forms the entry's relative distinguished | |||
name. | name. | |||
entryAlreadyExists (68) | entryAlreadyExists (68) | |||
Indicates that the request cannot be fulfilled (added, moved, | Indicates that the request cannot be fulfilled (added, moved, | |||
or renamed) as the target entry already exists. | or renamed) as the target entry already exists. | |||
objectClassModsProhibited (69) | objectClassModsProhibited (69) | |||
Indicates that an attempt to modify the object class(es) of | Indicates that an attempt to modify the object class(es) of | |||
an entry's objectClass attribute is prohibited. | an entry's 'objectClass' attribute is prohibited. | |||
For example, this code is returned when a client attempts to | For example, this code is returned when a client attempts to | |||
modify the structural object class of an entry. | modify the structural object class of an entry. | |||
affectsMultipleDSAs (71) | affectsMultipleDSAs (71) | |||
Indicates that the operation cannot be completed as it | Indicates that the operation cannot be completed as it | |||
affects multiple servers (DSAs). | affects multiple servers (DSAs). | |||
other (80) | other (80) | |||
Indicates the server has encountered an internal error. | Indicates the server has encountered an internal error. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 42 | Sermersheim Internet-Draft - Expires Jul 2004 Page 42 | |||
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 (2003). This version of | -- Copyright (C) The Internet Society (2003). 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. | |||
skipping to change at line 2357 | skipping to change at line 2396 | |||
MessageID ::= INTEGER (0 .. maxInt) | MessageID ::= INTEGER (0 .. maxInt) | |||
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- | maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- | |||
LDAPString ::= OCTET STRING -- UTF-8 encoded, | LDAPString ::= OCTET STRING -- UTF-8 encoded, | |||
-- [ISO10646] characters | -- [ISO10646] characters | |||
LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] | LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] | |||
LDAPDN ::= LDAPString | LDAPDN ::= LDAPString -- Constrained to <distinguishedName> | |||
-- [LDAPDN] | ||||
RelativeLDAPDN ::= LDAPString | ||||
AttributeDescription ::= LDAPString | RelativeLDAPDN ::= LDAPString -- Constrained to <name-component> | |||
-- [LDAPDN] | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 43 | Sermersheim Internet-Draft - Expires Jul 2004 Page 43 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
AttributeDescription ::= LDAPString | ||||
-- Constrained to <attributedescription> | -- Constrained to <attributedescription> | |||
-- [Models] | -- [Models] | |||
AttributeValue ::= OCTET STRING | AttributeValue ::= OCTET STRING | |||
AttributeValueAssertion ::= SEQUENCE { | AttributeValueAssertion ::= SEQUENCE { | |||
attributeDesc AttributeDescription, | attributeDesc AttributeDescription, | |||
assertionValue AssertionValue } | assertionValue AssertionValue } | |||
AssertionValue ::= OCTET STRING | AssertionValue ::= OCTET STRING | |||
skipping to change at line 2418 | skipping to change at line 2458 | |||
attributeOrValueExists (20), | attributeOrValueExists (20), | |||
invalidAttributeSyntax (21), | invalidAttributeSyntax (21), | |||
-- 22-31 unused -- | -- 22-31 unused -- | |||
noSuchObject (32), | noSuchObject (32), | |||
aliasProblem (33), | aliasProblem (33), | |||
invalidDNSyntax (34), | invalidDNSyntax (34), | |||
-- 35 reserved for undefined isLeaf -- | -- 35 reserved for undefined isLeaf -- | |||
aliasDereferencingProblem (36), | aliasDereferencingProblem (36), | |||
-- 37-47 unused -- | -- 37-47 unused -- | |||
inappropriateAuthentication (48), | inappropriateAuthentication (48), | |||
invalidCredentials (49), | ||||
insufficientAccessRights (50), | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 44 | Sermersheim Internet-Draft - Expires Jul 2004 Page 44 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
invalidCredentials (49), | ||||
insufficientAccessRights (50), | ||||
busy (51), | busy (51), | |||
unavailable (52), | unavailable (52), | |||
unwillingToPerform (53), | unwillingToPerform (53), | |||
loopDetect (54), | loopDetect (54), | |||
-- 55-63 unused -- | -- 55-63 unused -- | |||
namingViolation (64), | namingViolation (64), | |||
objectClassViolation (65), | objectClassViolation (65), | |||
notAllowedOnNonLeaf (66), | notAllowedOnNonLeaf (66), | |||
notAllowedOnRDN (67), | notAllowedOnRDN (67), | |||
entryAlreadyExists (68), | entryAlreadyExists (68), | |||
objectClassModsProhibited (69), | objectClassModsProhibited (69), | |||
-- 70 reserved for CLDAP -- | -- 70 reserved for CLDAP -- | |||
affectsMultipleDSAs (71), | affectsMultipleDSAs (71), | |||
-- 72-79 unused -- | -- 72-79 unused -- | |||
other (80), | other (80), | |||
... }, | ... }, | |||
-- 81-90 reserved for APIs -- | ||||
matchedDN LDAPDN, | matchedDN LDAPDN, | |||
diagnosticMessage LDAPString, | diagnosticMessage LDAPString, | |||
referral [3] Referral OPTIONAL } | referral [3] Referral OPTIONAL } | |||
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI | Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI | |||
URI ::= LDAPString -- limited to characters permitted in | URI ::= LDAPString -- limited to characters permitted in | |||
-- URIs | -- URIs | |||
Controls ::= SEQUENCE OF control Control | Controls ::= SEQUENCE OF control Control | |||
skipping to change at line 2478 | skipping to change at line 2517 | |||
SaslCredentials ::= SEQUENCE { | SaslCredentials ::= SEQUENCE { | |||
mechanism LDAPString, | mechanism LDAPString, | |||
credentials OCTET STRING OPTIONAL } | credentials OCTET STRING OPTIONAL } | |||
BindResponse ::= [APPLICATION 1] SEQUENCE { | BindResponse ::= [APPLICATION 1] SEQUENCE { | |||
COMPONENTS OF LDAPResult, | COMPONENTS OF LDAPResult, | |||
serverSaslCreds [7] OCTET STRING OPTIONAL } | serverSaslCreds [7] OCTET STRING OPTIONAL } | |||
UnbindRequest ::= [APPLICATION 2] NULL | UnbindRequest ::= [APPLICATION 2] NULL | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 45 | Sermersheim Internet-Draft - Expires Jul 2004 Page 45 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
SearchRequest ::= [APPLICATION 3] SEQUENCE { | SearchRequest ::= [APPLICATION 3] SEQUENCE { | |||
baseObject LDAPDN, | baseObject LDAPDN, | |||
scope ENUMERATED { | scope ENUMERATED { | |||
baseObject (0), | baseObject (0), | |||
singleLevel (1), | singleLevel (1), | |||
wholeSubtree (2) }, | wholeSubtree (2) }, | |||
derefAliases ENUMERATED { | derefAliases ENUMERATED { | |||
neverDerefAliases (0), | neverDerefAliases (0), | |||
derefInSearching (1), | derefInSearching (1), | |||
derefFindingBaseObj (2), | derefFindingBaseObj (2), | |||
derefAlways (3) }, | derefAlways (3) }, | |||
sizeLimit INTEGER (0 .. maxInt), | sizeLimit INTEGER (0 .. maxInt), | |||
timeLimit INTEGER (0 .. maxInt), | timeLimit INTEGER (0 .. maxInt), | |||
typesOnly BOOLEAN, | typesOnly BOOLEAN, | |||
filter Filter, | filter Filter, | |||
attributes AttributeSelection } | attributes AttributeSelection } | |||
AttributeSelection ::= SEQUENCE OF selection LDAPString | AttributeSelection ::= SEQUENCE OF selection LDAPString | |||
-- constrained to <attributeSelection> | ||||
-- in section 4.5.1. | ||||
Filter ::= CHOICE { | Filter ::= CHOICE { | |||
and [0] SET SIZE (1..MAX) OF filter Filter, | and [0] SET SIZE (1..MAX) OF filter Filter, | |||
or [1] SET SIZE (1..MAX) OF filter Filter, | or [1] SET SIZE (1..MAX) OF filter Filter, | |||
not [2] Filter, | not [2] Filter, | |||
equalityMatch [3] AttributeValueAssertion, | equalityMatch [3] AttributeValueAssertion, | |||
substrings [4] SubstringFilter, | substrings [4] SubstringFilter, | |||
greaterOrEqual [5] AttributeValueAssertion, | greaterOrEqual [5] AttributeValueAssertion, | |||
lessOrEqual [6] AttributeValueAssertion, | lessOrEqual [6] AttributeValueAssertion, | |||
present [7] AttributeDescription, | present [7] AttributeDescription, | |||
skipping to change at line 2532 | skipping to change at line 2573 | |||
matchingRule [1] MatchingRuleId OPTIONAL, | matchingRule [1] MatchingRuleId OPTIONAL, | |||
type [2] AttributeDescription OPTIONAL, | type [2] AttributeDescription OPTIONAL, | |||
matchValue [3] AssertionValue, | matchValue [3] AssertionValue, | |||
dnAttributes [4] BOOLEAN DEFAULT FALSE } | dnAttributes [4] BOOLEAN DEFAULT FALSE } | |||
SearchResultEntry ::= [APPLICATION 4] SEQUENCE { | SearchResultEntry ::= [APPLICATION 4] SEQUENCE { | |||
objectName LDAPDN, | objectName LDAPDN, | |||
attributes PartialAttributeList } | attributes PartialAttributeList } | |||
PartialAttributeList ::= SEQUENCE OF | PartialAttributeList ::= SEQUENCE OF | |||
partialAttribute PartialAttribute | ||||
SearchResultReference ::= [APPLICATION 19] SEQUENCE | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 46 | Sermersheim Internet-Draft - Expires Jul 2004 Page 46 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
partialAttribute PartialAttribute | ||||
SearchResultReference ::= [APPLICATION 19] SEQUENCE | ||||
SIZE (1..MAX) OF uri URI | SIZE (1..MAX) OF uri URI | |||
SearchResultDone ::= [APPLICATION 5] LDAPResult | SearchResultDone ::= [APPLICATION 5] LDAPResult | |||
ModifyRequest ::= [APPLICATION 6] SEQUENCE { | ModifyRequest ::= [APPLICATION 6] SEQUENCE { | |||
object LDAPDN, | object LDAPDN, | |||
changes SEQUENCE OF change SEQUENCE { | changes SEQUENCE OF change SEQUENCE { | |||
operation ENUMERATED { | operation ENUMERATED { | |||
add (0), | add (0), | |||
delete (1), | delete (1), | |||
skipping to change at line 2591 | skipping to change at line 2632 | |||
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | ExtendedRequest ::= [APPLICATION 23] SEQUENCE { | |||
requestName [0] LDAPOID, | requestName [0] LDAPOID, | |||
requestValue [1] OCTET STRING OPTIONAL } | requestValue [1] OCTET STRING OPTIONAL } | |||
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { | ExtendedResponse ::= [APPLICATION 24] SEQUENCE { | |||
COMPONENTS OF LDAPResult, | COMPONENTS OF LDAPResult, | |||
responseName [10] LDAPOID OPTIONAL, | responseName [10] LDAPOID OPTIONAL, | |||
responseValue [11] OCTET STRING OPTIONAL } | responseValue [11] OCTET STRING OPTIONAL } | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 47 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
END | END | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 47 | Sermersheim Internet-Draft - Expires Jul 2004 Page 48 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Appendix C - Changes | Appendix C - Changes | |||
This appendix is non-normative. | This appendix is non-normative. | |||
This appendix summarizes substantive changes made to RFC 2251 and RFC | This appendix summarizes substantive changes made to RFC 2251 and RFC | |||
2830. | 2830. | |||
C.1 Changes made to made to RFC 2251: | C.1 Changes made to made to RFC 2251: | |||
skipping to change at line 2628 | skipping to change at line 2672 | |||
- Removed notes giving history between LDAP v1, v2 and v3. Instead, | - Removed notes giving history between LDAP v1, v2 and v3. Instead, | |||
added sufficient language so that this document can stand on its | added sufficient language so that this document can stand on its | |||
own. | own. | |||
C.1.3 Section 4 | C.1.3 Section 4 | |||
- Clarified where the extensibility features of ASN.1 apply to the | - Clarified where the extensibility features of ASN.1 apply to the | |||
protocol. This change also affected various ASN.1 types. | protocol. This change also affected various ASN.1 types. | |||
- Removed the requirement that servers which implement version 3 or | - Removed the requirement that servers which implement version 3 or | |||
later MUST provide the supportedLDAPVersion attribute. This | later MUST provide the 'supportedLDAPVersion' attribute. This | |||
statement provided no interoperability advantages. | statement provided no interoperability advantages. | |||
C.1.4 Section 4.1.1 | C.1.4 Section 4.1.1 | |||
- There was a mandatory requirement for the server to return a | - There was a mandatory requirement for the server to return a | |||
Notice of Disconnection and drop the connection when a PDU is | Notice of Disconnection and drop the connection when a PDU is | |||
malformed in a certain way. This has been clarified such that the | malformed in a certain way. This has been clarified such that the | |||
server SHOULD return the Notice of Disconnection, and MUST drop | server SHOULD return the Notice of Disconnection, and MUST drop | |||
the connection. | the connection. | |||
C.1.5 Section 4.1.1.1 | C.1.5 Section 4.1.1.1 | |||
- Clarified that the messageID of requests MUST be non-zero. | - Clarified that the messageID of requests MUST be non-zero. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 48 | Sermersheim Internet-Draft - Expires Jul 2004 Page 49 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Clarified when it is and isn't appropriate to return an already | - Clarified when it is and isn't appropriate to return an already | |||
used message id. RFC 2251 accidentally imposed synchronous server | used message id. RFC 2251 accidentally imposed synchronous server | |||
behavior in its wording of this. | behavior in its wording of this. | |||
C.1.6 Section 4.1.2 | C.1.6 Section 4.1.2 | |||
- Stated that LDAPOID is constrained to <numericoid> from [Models]. | - Stated that LDAPOID is constrained to <numericoid> from [Models]. | |||
skipping to change at line 2694 | skipping to change at line 2738 | |||
C.1.12 Section 4.1.11 | C.1.12 Section 4.1.11 | |||
- Defined referrals in terms of URIs rather than URLs. | - Defined referrals in terms of URIs rather than URLs. | |||
- Removed the requirement that all referral URIs MUST be equally | - Removed the requirement that all referral URIs MUST be equally | |||
capable of progressing the operation. The statement was ambiguous | capable of progressing the operation. The statement was ambiguous | |||
and provided no instructions on how to carry it out. | and provided no instructions on how to carry it out. | |||
- Added the requirement that clients MUST NOT loop between servers. | - Added the requirement that clients MUST NOT loop between servers. | |||
- Clarified the instructions for using LDAPURLs in referrals, and in | - Clarified the instructions for using LDAPURLs in referrals, and in | |||
doing so added a recommendation that the scope part be present. | doing so added a recommendation that the scope part be present. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 49 | Sermersheim Internet-Draft - Expires Jul 2004 Page 50 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
C.1.13 Section 4.1.12 | C.1.13 Section 4.1.12 | |||
- 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. | |||
- Noted that the criticality field is only applied to request | ||||
messages (except unbindRequest). | ||||
- Added language regarding combinations of controls on a message. | - Added language regarding combinations of controls on a message. | |||
- 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.14 Section 4.2 | C.1.14 Section 4.2 | |||
- Mandated that servers return protocolError when the version is not | - Mandated that servers return protocolError when the version is not | |||
supported. | supported. | |||
- Clarified behavior when the simple authentication is used, the | - Clarified behavior when the simple authentication is used, the | |||
name is empty and the password is non-empty. | name is empty and the password is non-empty. | |||
- Required servers to not dereference aliases for bind. This was | - Required servers to not dereference aliases for bind. 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. | |||
- Required that textual passwords be transferred as UTF-8 encoded | - Required that textual passwords be transferred as UTF-8 encoded | |||
Unicode, and added recommendations on string preparation. This was | Unicode, and added recommendations on string preparation. This was | |||
to help ensure interoperability of passwords being sent from | to help ensure interoperability of passwords being sent from | |||
different clients. | different clients. | |||
C.1.15 Section 4.2.1 | C.1.15 Section 4.2.1 | |||
- This section was largely reorganized for readability and language | - This section was largely reorganized for readability and language | |||
was added to clarify the authentication state of failed and | was added to clarify the authentication state of failed and | |||
abandoned bind operations. | abandoned bind operations. | |||
skipping to change at line 2744 | skipping to change at line 2790 | |||
them. LDAP should not require any special handling. And if an LDAP | them. LDAP should not require any special handling. And if an LDAP | |||
client had used such a mechanism, it would have the option of | client had used such a mechanism, it would have the option of | |||
using another mechanism. | using another mechanism. | |||
- Dropped MUST imperative in paragraph 3 to align with [Keywords]. | - Dropped MUST imperative in paragraph 3 to align with [Keywords]. | |||
C.1.16 Section 4.2.3 | C.1.16 Section 4.2.3 | |||
- 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. | |||
- Prohibited the server from specifying serverSaslCreds when not | ||||
appropriate. | ||||
Sermersheim Internet-Draft - Expires Jun 2004 Page 50 | Sermersheim Internet-Draft - Expires Jul 2004 Page 51 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
- Prohibited the server from specifying serverSaslCreds when not | ||||
appropriate. | ||||
C.1.17 Section 4.3 | C.1.17 Section 4.3 | |||
- Required both peers to cease transmission and close the connection | - Required both peers to cease transmission and close the connection | |||
for the unbind operation. | for the unbind operation. | |||
C.1.18 Section 4.4 | C.1.18 Section 4.4 | |||
- Added instructions for future specifications of Unsolicited | - Added instructions for future specifications of Unsolicited | |||
Notifications. | Notifications. | |||
C.1.19 Section 4.5.1 | C.1.19 Section 4.5.1 | |||
- SearchRequest attributes is now defined as an AttributeSelection | - SearchRequest attributes is now defined as an AttributeSelection | |||
type rather than AttributeDescriptionList. | type rather than AttributeDescriptionList. | |||
- The Filter choices 'and' and 'or', and the SubstringFilter | - The Filter choices 'and' and 'or', and the SubstringFilter | |||
substrings types are now defined with a lower bound of 1. | substrings types are now defined 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. | are now AssertionValue rather than LDAPString. Also, added | |||
imperatives stating that 'initial' (if present) must be listed | ||||
first, and 'final' (if present) must be listed last. | ||||
- Clarified the semantics of the derefAliases choices. | - Clarified the semantics of the derefAliases choices. | |||
- Added instructions for equalityMatch, substrings, greaterOrEqual, | - Added instructions for equalityMatch, substrings, greaterOrEqual, | |||
lessOrEqual, and approxMatch. | lessOrEqual, and approxMatch. | |||
C.1.20 Section 4.5.2 | C.1.20 Section 4.5.2 | |||
- 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. | |||
skipping to change at line 2789 | skipping to change at line 2838 | |||
C.1.21 Section 4.5.3 | C.1.21 Section 4.5.3 | |||
- Made changes similar to those made to Section 4.1.11. | - Made changes similar to those made to Section 4.1.11. | |||
C.1.22 Section 4.5.3.1 | C.1.22 Section 4.5.3.1 | |||
- 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.23 Section 4.6 | C.1.23 Section 4.6 | |||
- Removed restriction that required an equality match filter in | - Removed restriction that required an EQUALITY matching rule in | |||
order to perform value delete modifications. It is sufficiently | order to perform value delete modifications. It is sufficiently | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 52 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
documented that in absence of an equality matching rule, octet | documented that in absence of an equality matching rule, octet | |||
equality is used. | equality is used. | |||
- Replaced AttributeTypeAndValues with Attribute as they are | - Replaced AttributeTypeAndValues with Attribute as they are | |||
equivalent. | equivalent. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 51 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- Clarified what type of modification changes might temporarily | - Clarified what type of modification changes might temporarily | |||
violate schema. | violate schema. | |||
C.1.24 Section 4.9 | C.1.24 Section 4.9 | |||
- Required servers to not dereference aliases for modify DN. This | - Required servers to not dereference aliases for modify DN. This | |||
was added for consistency with other operations and to help ensure | was added for consistency with other operations and to help ensure | |||
data consistency. | data consistency. | |||
- Allow modify DN to fail when moving between naming contexts. | - Allow modify DN to fail when moving between naming contexts. | |||
C.1.25 Section 4.10 | C.1.25 Section 4.10 | |||
- Clarified the semantics of Compare when the attribute is not | - Clarified the semantics of Compare when the attribute is not | |||
present and when it is unknown. | present and when it is unknown. | |||
- 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. | |||
C.1.26 Section 4.11 | C.1.26 Section 4.11 | |||
- Explained that since abandon returns no response, clients hould | - 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. | |||
C.1.27 Section 4.12 | C.1.27 Section 4.12 | |||
- 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 | |||
skipping to change at line 2841 | skipping to change at line 2890 | |||
C.1.28 Section 5.2 | C.1.28 Section 5.2 | |||
- Moved referral-specific instructions into referral-related | - Moved referral-specific instructions into referral-related | |||
sections. | sections. | |||
C.1.29 Section 7 | C.1.29 Section 7 | |||
- Reworded notes regarding SASL not protecting certain aspects of | - Reworded notes regarding SASL not protecting certain aspects of | |||
the LDAP bind PDU. | the LDAP bind PDU. | |||
Sermersheim Internet-Draft - Expires Jul 2004 Page 53 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- 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 scenario where an identity is changed | |||
(deleted, privileges or credentials modified, etc.). | (deleted, privileges or credentials modified, etc.). | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 52 | ||||
Lightweight Directory Access Protocol Version 3 | ||||
- 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. | |||
- Added a note regarding malformed and long encodings. | - Added a note regarding malformed and long encodings. | |||
C.1.30 Appendix A | C.1.30 Appendix A | |||
- Added "EXTESIBILITY IMPLIED" to ASN.1 definition. | - Added "EXTESIBILITY IMPLIED" to ASN.1 definition. | |||
- Removed AttributeType. It is not used. | - Removed AttributeType. It is not used. | |||
C.2 Changes made to made to RFC 2830: | C.2 Changes made to 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. | |||
C.2.1 Section 2.3 | C.2.1 Section 2.3 | |||
- 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 | ||||
returned. Some result codes are required in certain scenarios, but | ||||
any other may be returned if appropriate. | ||||
C.2.1 Section 4.13.3.1 | C.2.1 Section 4.13.3.1 | |||
- Reworded most of this section and added the requirement that after | - Reworded most of this section and added the requirement that after | |||
the TLS connection has been closed, the server MUST NOT send | the TLS connection has been closed, the server MUST NOT send | |||
responses to any request message received before the TLS closure. | responses to any request message received before the TLS closure. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 53 | Sermersheim Internet-Draft - Expires Jul 2004 Page 54 | |||
Lightweight Directory Access Protocol Version 3 | Lightweight Directory Access Protocol Version 3 | |||
Intellectual Property Rights | Intellectual Property Rights | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to | intellectual property or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; neither does it represent that it | might or might not be available; neither does it represent that it | |||
has made any effort to identify any such rights. Information on the | has made any effort to identify any such rights. Information on the | |||
skipping to change at line 2928 | skipping to change at line 2980 | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Sermersheim Internet-Draft - Expires Jun 2004 Page 54 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |