Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4511

Lightweight Directory Access Protocol (LDAP): The Protocol

Pages: 68
Proposed Standard
Obsoletes:  225128303771
Part 3 of 3 – Pages 42 to 68
First   Prev   None

Top   ToC   RFC4511 - Page 42   prevText

5. Protocol Encoding, Connection, and Transfer

This protocol is designed to run over connection-oriented, reliable transports, where the data stream is divided into octets (8-bit units), with each octet and each bit being significant. One underlying service, LDAP over TCP, is defined in Section 5.2. This service is generally applicable to applications providing or consuming X.500-based directory services on the Internet. This specification was generally written with the TCP mapping in mind. Specifications detailing other mappings may encounter various obstacles. Implementations of LDAP over TCP MUST implement the mapping as described in Section 5.2. This table illustrates the relationship among the different layers involved in an exchange between two protocol peers: +----------------------+ | LDAP message layer | +----------------------+ > LDAP PDUs +----------------------+ < data | SASL layer | +----------------------+ > SASL-protected data +----------------------+ < data | TLS layer | Application +----------------------+ > TLS-protected data ------------+----------------------+ < data Transport | transport connection | +----------------------+

5.1. Protocol Encoding

The protocol elements of LDAP SHALL be encoded for exchange using the Basic Encoding Rules [BER] of [ASN.1] with the following restrictions: - Only the definite form of length encoding is used. - OCTET STRING values are encoded in the primitive form only. - If the value of a BOOLEAN type is true, the encoding of the value octet is set to hex "FF".
Top   ToC   RFC4511 - Page 43
   - If a value of a type is its default value, it is absent.  Only some
     BOOLEAN and INTEGER types have default values in this protocol

   These restrictions are meant to ease the overhead of encoding and
   decoding certain elements in BER.

   These restrictions do not apply to ASN.1 types encapsulated inside of
   OCTET STRING values, such as attribute values, unless otherwise

5.2. Transmission Control Protocol (TCP)

The encoded LDAPMessage PDUs are mapped directly onto the TCP [RFC793] bytestream using the BER-based encoding described in Section 5.1. It is recommended that server implementations running over the TCP provide a protocol listener on the Internet Assigned Numbers Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may instead provide a listener on a different port number. Clients MUST support contacting servers on any valid TCP port.

5.3. Termination of the LDAP session

Termination of the LDAP session is typically initiated by the client sending an UnbindRequest (Section 4.3), or by the server sending a Notice of Disconnection (Section 4.4.1). In these cases, each protocol peer gracefully terminates the LDAP session by ceasing exchanges at the LDAP message layer, tearing down any SASL layer, tearing down any TLS layer, and closing the transport connection. A protocol peer may determine that the continuation of any communication would be pernicious, and in this case, it may abruptly terminate the session by ceasing communication and closing the transport connection. In either case, when the LDAP session is terminated, uncompleted operations are handled as specified in Section 3.1.

6. Security Considerations

This version of the protocol provides facilities for simple authentication using a cleartext password, as well as any SASL [RFC4422] mechanism. Installing SASL and/or TLS layers can provide integrity and other data security services. It is also permitted that the server can return its credentials to the client, if it chooses to do so.
Top   ToC   RFC4511 - Page 44
   Use of cleartext password is strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and may
   result in disclosure of the password to unauthorized parties.

   Servers are encouraged to prevent directory modifications by clients
   that have authenticated anonymously [RFC4513].

   Security considerations for authentication methods, SASL mechanisms,
   and TLS are described in [RFC4513].

   Note that SASL authentication exchanges do not provide data
   confidentiality or integrity protection for the version or name
   fields of the BindRequest or the resultCode, diagnosticMessage, or
   referral fields of the BindResponse, nor for any information
   contained in controls attached to Bind requests or responses.  Thus,
   information contained in these fields SHOULD NOT be relied on unless
   it is otherwise protected (such as by establishing protections at the
   transport layer).

   Implementors should note that various security factors (including
   authentication and authorization information and data security
   services) may change during the course of the LDAP session or even
   during the performance of a particular operation.  For instance,
   credentials could expire, authorization identities or access controls
   could change, or the underlying security layer(s) could be replaced
   or terminated.  Implementations should be robust in the handling of
   changing security factors.

   In some cases, it may be appropriate to continue the operation even
   in light of security factor changes.  For instance, it may be
   appropriate to continue an Abandon operation regardless of the
   change, or to continue an operation when the change upgraded (or
   maintained) the security factor.  In other cases, it may be
   appropriate to fail or alter the processing of the operation.  For
   instance, if confidential protections were removed, it would be
   appropriate either to fail a request to return sensitive data or,
   minimally, to exclude the return of sensitive data.

   Implementations that cache attributes and entries obtained via LDAP
   MUST ensure that access controls are maintained if that information
   is to be provided to multiple clients, since servers may have access
   control policies that prevent the return of entries or attributes in
   Search results except to particular authenticated clients.  For
   example, caches could serve result information only to the client
   whose request caused it to be in the cache.
Top   ToC   RFC4511 - Page 45
   Servers may return referrals or Search result references that
   redirect clients to peer servers.  It is possible for a rogue
   application to inject such referrals into the data stream in an
   attempt to redirect a client to a rogue server.  Clients are advised
   to be aware of this and possibly reject referrals when
   confidentiality measures are not in place.  Clients are advised to
   reject referrals from the StartTLS operation.

   The matchedDN and diagnosticMessage fields, as well as some
   resultCode values (e.g., attributeOrValueExists and
   entryAlreadyExists), could disclose the presence or absence of
   specific data in the directory that is subject to access and other
   administrative controls.  Server implementations should restrict
   access to protected information equally under both normal and error

   Protocol peers MUST be prepared to handle invalid and arbitrary-
   length protocol encodings.  Invalid protocol encodings include: BER
   encoding exceptions, format string and UTF-8 encoding exceptions,
   overflow exceptions, integer value exceptions, and binary mode on/off
   flag exceptions.  The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
   excellent examples of these exceptions and test cases used to
   discover flaws.

   In the event that a protocol peer senses an attack that in its nature
   could cause damage due to further communication at any layer in the
   LDAP session, the protocol peer should abruptly terminate the LDAP
   session as described in Section 5.3.

7. Acknowledgements

This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve Kille. RFC 2251 was a product of the IETF ASID Working Group. It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group. It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga. RFC 3771 was an individual submission to the IETF. This document is a product of the IETF LDAPBIS Working Group. Significant contributors of technical review and content include Kurt Zeilenga, Steven Legg, and Hallvard Furuseth.
Top   ToC   RFC4511 - Page 46

8. Normative References

[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824- 1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation". [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002. [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3454] Hoffman P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, March 2006. [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
Top   ToC   RFC4511 - Page 47
   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Technical Specification Road Map", RFC
                 4510, June 2006.

   [RFC4512]     Zeilenga, K., Lightweight Directory Access Protocol
                 (LDAP): Directory Information Models", RFC 4512, June

   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Authentication Methods and Security
                 Mechanisms", RFC 4513, June 2006.

   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
                 Protocol (LDAP): String Representation of Distinguished
                 Names", RFC 4514, June 2006.

   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
                 Access Protocol (LDAP): Uniform Resource Locator", RFC
                 4516, June 2006.

   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June

   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
                 (IANA) Considerations for the Lightweight Directory
                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
                 3.2.0" is defined by "The Unicode Standard, Version
                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
                 61633-5), as amended by the "Unicode Standard Annex
                 #27: Unicode 3.1"
                 ( and by the
                 "Unicode Standard Annex #28: Unicode 3.2"

   [X.500]       ITU-T Rec. X.500, "The Directory: Overview of Concepts,
                 Models and Service", 1993.

   [X.511]       ITU-T Rec. X.511, "The Directory: Abstract Service
                 Definition", 1993.
Top   ToC   RFC4511 - Page 48

9. Informative References

[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <>, August 2000. [Glossary] The Unicode Consortium, "Unicode Glossary", <>. [PortReg] IANA, "Port Numbers", <>. [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" < c06/ldapv3/>.

10. IANA Considerations

The Internet Assigned Numbers Authority (IANA) has updated the LDAP result code registry to indicate that this document provides the definitive technical specification for result codes 0-36, 48-54, 64- 70, 80-90. It is also noted that one resultCode value (strongAuthRequired) has been renamed (to strongerAuthRequired). The IANA has also updated the LDAP Protocol Mechanism registry to indicate that this document and [RFC4513] provides the definitive technical specification for the StartTLS ( Extended operation. IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the ASN.1 module defined in this document. Subject: Request for LDAP Object Identifier Registration Person & email address to contact for further information: Jim Sermersheim <> Specification: RFC 4511 Author/Change Controller: IESG Comments: Identifies the LDAP ASN.1 module
Top   ToC   RFC4511 - Page 49

Appendix A. LDAP Result Codes

This normative appendix details additional considerations regarding LDAP result codes and provides a brief, general description of each LDAP result code enumerated in Section 4.1.9. Additional result codes MAY be defined for use with extensions [RFC4520]. Client implementations SHALL treat any result code that they do not recognize as an unknown error condition. The descriptions provided here do not fully account for result code substitutions used to prevent unauthorized disclosures (such as substitution of noSuchObject for insufficientAccessRights, or invalidCredentials for insufficientAccessRights).

A.1. Non-Error Result Codes

These result codes (called "non-error" result codes) do not indicate an error condition: success (0), compareFalse (5), compareTrue (6), referral (10), and saslBindInProgress (14). The success, compareTrue, and compareFalse result codes indicate successful completion (and, hence, are referred to as "successful" result codes). The referral and saslBindInProgress result codes indicate the client needs to take additional action to complete the operation.

A.2. Result Codes

Existing LDAP result codes are described as follows: success (0) Indicates the successful completion of an operation. Note: this code is not used with the Compare operation. See compareFalse (5) and compareTrue (6).
Top   ToC   RFC4511 - Page 50
      operationsError (1)
         Indicates that the operation is not properly sequenced with
         relation to other operations (of same or different type).

         For example, this code is returned if the client attempts to
         StartTLS [RFC4346] while there are other uncompleted operations
         or if a TLS layer was already installed.

      protocolError (2)
         Indicates the server received data that is not well-formed.

         For Bind operation only, this code is also used to indicate
         that the server does not support the requested protocol

         For Extended operations only, this code is also used to
         indicate that the server does not support (by design or
         configuration) the Extended operation associated with the

         For request operations specifying multiple controls, this may
         be used to indicate that the server cannot ignore the order
         of the controls as specified, or that the combination of the
         specified controls is invalid or unspecified.

      timeLimitExceeded (3)
         Indicates that the time limit specified by the client was
         exceeded before the operation could be completed.

      sizeLimitExceeded (4)
         Indicates that the size limit specified by the client was
         exceeded before the operation could be completed.

      compareFalse (5)
         Indicates that the Compare operation has successfully
         completed and the assertion has evaluated to FALSE or

      compareTrue (6)
         Indicates that the Compare operation has successfully
         completed and the assertion has evaluated to TRUE.

      authMethodNotSupported (7)
         Indicates that the authentication method or mechanism is not
Top   ToC   RFC4511 - Page 51
      strongerAuthRequired (8)
         Indicates the server requires strong(er) authentication in
         order to complete the operation.

         When used with the Notice of Disconnection operation, this
         code indicates that the server has detected that an
         established security association between the client and
         server has unexpectedly failed or been compromised.

      referral (10)
         Indicates that a referral needs to be chased to complete the
         operation (see Section 4.1.10).

      adminLimitExceeded (11)
         Indicates that an administrative limit has been exceeded.

      unavailableCriticalExtension (12)
         Indicates a critical control is unrecognized (see Section

      confidentialityRequired (13)
         Indicates that data confidentiality protections are required.

      saslBindInProgress (14)
         Indicates the server requires the client to send a new bind
         request, with the same SASL mechanism, to continue the
         authentication process (see Section 4.2).

      noSuchAttribute (16)
         Indicates that the named entry does not contain the specified
         attribute or attribute value.

      undefinedAttributeType (17)
         Indicates that a request field contains an unrecognized
         attribute description.

      inappropriateMatching (18)
         Indicates that an attempt was made (e.g., in an assertion) to
         use a matching rule not defined for the attribute type

      constraintViolation (19)
         Indicates that the client supplied an attribute value that
         does not conform to the constraints placed upon it by the
         data model.

         For example, this code is returned when multiple values are
         supplied to an attribute that has a SINGLE-VALUE constraint.
Top   ToC   RFC4511 - Page 52
      attributeOrValueExists (20)
         Indicates that the client supplied an attribute or value to
         be added to an entry, but the attribute or value already

      invalidAttributeSyntax (21)
         Indicates that a purported attribute value does not conform
         to the syntax of the attribute.

      noSuchObject (32)
         Indicates that the object does not exist in the DIT.

      aliasProblem (33)
         Indicates that an alias problem has occurred.  For example,
         the code may used to indicate an alias has been dereferenced
         that names no object.

      invalidDNSyntax (34)
         Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
         base, target entry, ModifyDN newrdn, etc.) of a request does
         not conform to the required syntax or contains attribute
         values that do not conform to the syntax of the attribute's

      aliasDereferencingProblem (36)
         Indicates that a problem occurred while dereferencing an
         alias.  Typically, an alias was encountered in a situation
         where it was not allowed or where access was denied.

      inappropriateAuthentication (48)
         Indicates the server requires the client that had attempted
         to bind anonymously or without supplying credentials to
         provide some form of credentials.

      invalidCredentials (49)
         Indicates that the provided credentials (e.g., the user's name
         and password) are invalid.

      insufficientAccessRights (50)
         Indicates that the client does not have sufficient access
         rights to perform the operation.

      busy (51)
         Indicates that the server is too busy to service the
Top   ToC   RFC4511 - Page 53
      unavailable (52)
         Indicates that the server is shutting down or a subsystem
         necessary to complete the operation is offline.

      unwillingToPerform (53)
         Indicates that the server is unwilling to perform the

      loopDetect (54)
         Indicates that the server has detected an internal loop (e.g.,
         while dereferencing aliases or chaining an operation).

      namingViolation (64)
         Indicates that the entry's name violates naming restrictions.

      objectClassViolation (65)
         Indicates that the entry violates object class restrictions.

      notAllowedOnNonLeaf (66)
         Indicates that the operation is inappropriately acting upon a
         non-leaf entry.

      notAllowedOnRDN (67)
         Indicates that the operation is inappropriately attempting to
         remove a value that forms the entry's relative distinguished

      entryAlreadyExists (68)
         Indicates that the request cannot be fulfilled (added, moved,
         or renamed) as the target entry already exists.

      objectClassModsProhibited (69)
         Indicates that an attempt to modify the object class(es) of
         an entry's 'objectClass' attribute is prohibited.

         For example, this code is returned when a client attempts to
         modify the structural object class of an entry.

      affectsMultipleDSAs (71)
         Indicates that the operation cannot be performed as it would
         affect multiple servers (DSAs).

      other (80)
         Indicates the server has encountered an internal error.
Top   ToC   RFC4511 - Page 54

Appendix B. Complete ASN.1 Definition

This appendix is normative. Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18} -- Copyright (C) The Internet Society (2006). This version of -- this ASN.1 module is part of RFC 4511; see the RFC itself -- for full legal notices. DEFINITIONS IMPLICIT TAGS EXTENSIBILITY IMPLIED ::= BEGIN LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modDNRequest ModifyDNRequest, modDNResponse ModifyDNResponse, compareRequest CompareRequest, compareResponse CompareResponse, abandonRequest AbandonRequest, extendedReq ExtendedRequest, extendedResp ExtendedResponse, ..., intermediateResponse IntermediateResponse }, controls [0] Controls OPTIONAL } MessageID ::= INTEGER (0 .. maxInt) maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- LDAPString ::= OCTET STRING -- UTF-8 encoded, -- [ISO10646] characters
Top   ToC   RFC4511 - Page 55
        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
                                 -- [RFC4512]

        LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
                              -- [RFC4514]

        RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
                                      -- [RFC4514]

        AttributeDescription ::= LDAPString
                                -- Constrained to <attributedescription>
                                -- [RFC4512]

        AttributeValue ::= OCTET STRING

        AttributeValueAssertion ::= SEQUENCE {
             attributeDesc   AttributeDescription,
             assertionValue  AssertionValue }

        AssertionValue ::= OCTET STRING

        PartialAttribute ::= SEQUENCE {
             type       AttributeDescription,
             vals       SET OF value AttributeValue }

        Attribute ::= PartialAttribute(WITH COMPONENTS {
             vals (SIZE(1..MAX))})

        MatchingRuleId ::= LDAPString

        LDAPResult ::= SEQUENCE {
             resultCode         ENUMERATED {
                  success                      (0),
                  operationsError              (1),
                  protocolError                (2),
                  timeLimitExceeded            (3),
                  sizeLimitExceeded            (4),
                  compareFalse                 (5),
                  compareTrue                  (6),
                  authMethodNotSupported       (7),
                  strongerAuthRequired         (8),
                       -- 9 reserved --
                  referral                     (10),
                  adminLimitExceeded           (11),
                  unavailableCriticalExtension (12),
                  confidentialityRequired      (13),
                  saslBindInProgress           (14),
Top   ToC   RFC4511 - Page 56
                  noSuchAttribute              (16),
                  undefinedAttributeType       (17),
                  inappropriateMatching        (18),
                  constraintViolation          (19),
                  attributeOrValueExists       (20),
                  invalidAttributeSyntax       (21),
                       -- 22-31 unused --
                  noSuchObject                 (32),
                  aliasProblem                 (33),
                  invalidDNSyntax              (34),
                       -- 35 reserved for undefined isLeaf --
                  aliasDereferencingProblem    (36),
                       -- 37-47 unused --
                  inappropriateAuthentication  (48),
                  invalidCredentials           (49),
                  insufficientAccessRights     (50),
                  busy                         (51),
                  unavailable                  (52),
                  unwillingToPerform           (53),
                  loopDetect                   (54),
                       -- 55-63 unused --
                  namingViolation              (64),
                  objectClassViolation         (65),
                  notAllowedOnNonLeaf          (66),
                  notAllowedOnRDN              (67),
                  entryAlreadyExists           (68),
                  objectClassModsProhibited    (69),
                       -- 70 reserved for CLDAP --
                  affectsMultipleDSAs          (71),
                       -- 72-79 unused --
                  other                        (80),
                  ...  },
             matchedDN          LDAPDN,
             diagnosticMessage  LDAPString,
             referral           [3] Referral OPTIONAL }

        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI

        URI ::= LDAPString     -- limited to characters permitted in
                               -- URIs

        Controls ::= SEQUENCE OF control Control

        Control ::= SEQUENCE {
             controlType             LDAPOID,
             criticality             BOOLEAN DEFAULT FALSE,
             controlValue            OCTET STRING OPTIONAL }
Top   ToC   RFC4511 - Page 57
        BindRequest ::= [APPLICATION 0] SEQUENCE {
             version                 INTEGER (1 ..  127),
             name                    LDAPDN,
             authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
             simple                  [0] OCTET STRING,
                                     -- 1 and 2 reserved
             sasl                    [3] SaslCredentials,
             ...  }

        SaslCredentials ::= SEQUENCE {
             mechanism               LDAPString,
             credentials             OCTET STRING OPTIONAL }

        BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

        UnbindRequest ::= [APPLICATION 2] NULL

        SearchRequest ::= [APPLICATION 3] SEQUENCE {
             baseObject      LDAPDN,
             scope           ENUMERATED {
                  baseObject              (0),
                  singleLevel             (1),
                  wholeSubtree            (2),
                  ...  },
             derefAliases    ENUMERATED {
                  neverDerefAliases       (0),
                  derefInSearching        (1),
                  derefFindingBaseObj     (2),
                  derefAlways             (3) },
             sizeLimit       INTEGER (0 ..  maxInt),
             timeLimit       INTEGER (0 ..  maxInt),
             typesOnly       BOOLEAN,
             filter          Filter,
             attributes      AttributeSelection }

        AttributeSelection ::= SEQUENCE OF selector LDAPString
                       -- The LDAPString is constrained to
                       -- <attributeSelector> in Section

        Filter ::= CHOICE {
             and             [0] SET SIZE (1..MAX) OF filter Filter,
             or              [1] SET SIZE (1..MAX) OF filter Filter,
             not             [2] Filter,
             equalityMatch   [3] AttributeValueAssertion,
Top   ToC   RFC4511 - Page 58
             substrings      [4] SubstringFilter,
             greaterOrEqual  [5] AttributeValueAssertion,
             lessOrEqual     [6] AttributeValueAssertion,
             present         [7] AttributeDescription,
             approxMatch     [8] AttributeValueAssertion,
             extensibleMatch [9] MatchingRuleAssertion,
             ...  }

        SubstringFilter ::= SEQUENCE {
             type           AttributeDescription,
             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
                  initial [0] AssertionValue,  -- can occur at most once
                  any     [1] AssertionValue,
                  final   [2] AssertionValue } -- can occur at most once

        MatchingRuleAssertion ::= SEQUENCE {
             matchingRule    [1] MatchingRuleId OPTIONAL,
             type            [2] AttributeDescription OPTIONAL,
             matchValue      [3] AssertionValue,
             dnAttributes    [4] BOOLEAN DEFAULT FALSE }

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
             objectName      LDAPDN,
             attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF
                             partialAttribute PartialAttribute

        SearchResultReference ::= [APPLICATION 19] SEQUENCE
                                  SIZE (1..MAX) OF uri URI

        SearchResultDone ::= [APPLICATION 5] LDAPResult

        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
             object          LDAPDN,
             changes         SEQUENCE OF change SEQUENCE {
                  operation       ENUMERATED {
                       add     (0),
                       delete  (1),
                       replace (2),
                       ...  },
                  modification    PartialAttribute } }

        ModifyResponse ::= [APPLICATION 7] LDAPResult
Top   ToC   RFC4511 - Page 59
        AddRequest ::= [APPLICATION 8] SEQUENCE {
             entry           LDAPDN,
             attributes      AttributeList }

        AttributeList ::= SEQUENCE OF attribute Attribute

        AddResponse ::= [APPLICATION 9] LDAPResult

        DelRequest ::= [APPLICATION 10] LDAPDN

        DelResponse ::= [APPLICATION 11] LDAPResult

        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
             entry           LDAPDN,
             newrdn          RelativeLDAPDN,
             deleteoldrdn    BOOLEAN,
             newSuperior     [0] LDAPDN OPTIONAL }

        ModifyDNResponse ::= [APPLICATION 13] LDAPResult

        CompareRequest ::= [APPLICATION 14] SEQUENCE {
             entry           LDAPDN,
             ava             AttributeValueAssertion }

        CompareResponse ::= [APPLICATION 15] LDAPResult

        AbandonRequest ::= [APPLICATION 16] MessageID

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
             requestName      [0] LDAPOID,
             requestValue     [1] OCTET STRING OPTIONAL }

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
             COMPONENTS OF LDAPResult,
             responseName     [10] LDAPOID OPTIONAL,
             responseValue    [11] OCTET STRING OPTIONAL }

        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
             responseName     [0] LDAPOID OPTIONAL,
             responseValue    [1] OCTET STRING OPTIONAL }

Top   ToC   RFC4511 - Page 60

Appendix C. Changes

This appendix is non-normative. This appendix summarizes substantive changes made to RFC 2251, RFC 2830, and RFC 3771.

C.1. Changes Made to RFC 2251

This section summarizes the substantive changes made to Sections 1, 2, 3.1, and 4, and the remainder of RFC 2251. Readers should consult [RFC4512] and [RFC4513] for summaries of changes to other sections.

C.1.1. Section 1 (Status of this Memo)

- Removed IESG note. Post publication of RFC 2251, mandatory LDAP authentication mechanisms have been standardized which are sufficient to remove this note. See [RFC4513] for authentication mechanisms.

C.1.2. Section 3.1 (Protocol Model) and others

- Removed notes giving history between LDAP v1, v2, and v3. Instead, added sufficient language so that this document can stand on its own.

C.1.3. Section 4 (Elements of Protocol)

- Clarified where the extensibility features of ASN.1 apply to the protocol. This change affected various ASN.1 types by the inclusion of ellipses (...) to certain elements. - Removed the requirement that servers that implement version 3 or later MUST provide the 'supportedLDAPVersion' attribute. This statement provided no interoperability advantages.

C.1.4. Section 4.1.1 (Message Envelope)

- There was a mandatory requirement for the server to return a Notice of Disconnection and drop the transport connection when a PDU is malformed in a certain way. This has been updated such that the server SHOULD return the Notice of Disconnection, and it MUST terminate the LDAP Session.

C.1.5. Section (Message ID)

- Required that the messageID of requests MUST be non-zero as the zero is reserved for Notice of Disconnection.
Top   ToC   RFC4511 - Page 61
   - Specified when it is and isn't appropriate to return an already
     used messageID.  RFC 2251 accidentally imposed synchronous server
     behavior in its wording of this.

C.1.6. Section 4.1.2 (String Types)

- Stated that LDAPOID is constrained to <numericoid> from [RFC4512].

C.1.7. Section (Binary Option) and others

- Removed the Binary Option from the specification. There are numerous interoperability problems associated with this method of alternate attribute type encoding. Work to specify a suitable replacement is ongoing.

C.1.8. Section 4.1.8 (Attribute)

- Combined the definitions of PartialAttribute and Attribute here, and defined Attribute in terms of PartialAttribute.

C.1.9. Section 4.1.10 (Result Message)

- Renamed "errorMessage" to "diagnosticMessage" as it is allowed to be sent for non-error results. - Moved some language into Appendix A, and referred the reader there. - Allowed matchedDN to be present for other result codes than those listed in RFC 2251. - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to clarify that this code may often be returned to indicate that a stronger authentication is needed to perform a given operation.

C.1.10. Section 4.1.11 (Referral)

- Defined referrals in terms of URIs rather than URLs. - Removed the requirement that all referral URIs MUST be equally capable of progressing the operation. The statement was ambiguous and provided no instructions on how to carry it out. - Added the requirement that clients MUST NOT loop between servers. - Clarified the instructions for using LDAPURLs in referrals, and in doing so added a recommendation that the scope part be present. - Removed imperatives which required clients to use URLs in specific ways to progress an operation. These did nothing for interoperability.
Top   ToC   RFC4511 - Page 62

C.1.11. Section 4.1.12 (Controls)

- Specified how control values defined in terms of ASN.1 are to be encoded. - Noted that the criticality field is only applied to request messages (except UnbindRequest), and must be ignored when present on response messages and UnbindRequest. - Specified that non-critical controls may be ignored at the server's discretion. There was confusion in the original wording which led some to believe that recognized controls may not be ignored as long as they were associated with a proper request. - Added language regarding combinations of controls and the ordering of controls on a message. - Specified that when the semantics of the combination of controls is undefined or unknown, it results in a protocolError. - Changed "The server MUST be prepared" to "Implementations MUST be prepared" in paragraph 8 to reflect that both client and server implementations must be able to handle this (as both parse controls).

C.1.12. Section 4.2 (Bind Operation)

- Mandated that servers return protocolError when the version is not supported. - Disambiguated behavior when the simple authentication is used, the name is empty, and the password is non-empty. - Required servers to not dereference aliases for Bind. This was added for consistency with other operations and to help ensure data consistency. - Required that textual passwords be transferred as UTF-8 encoded Unicode, and added recommendations on string preparation. This was to help ensure interoperability of passwords being sent from different clients.

C.1.13. Section 4.2.1 (Sequencing of the Bind Request)

- This section was largely reorganized for readability, and language was added to clarify the authentication state of failed and abandoned Bind operations. - Removed: "If a SASL transfer encryption or integrity mechanism has been negotiated, that mechanism does not support the changing of credentials from one identity to another, then the client MUST instead establish a new connection." If there are dependencies between multiple negotiations of a particular SASL mechanism, the technical specification for that SASL mechanism details how applications are to deal with them. LDAP should not require any special handling. - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
Top   ToC   RFC4511 - Page 63
   - Mandated that clients not send non-Bind operations while a Bind is
     in progress, and suggested that servers not process them if they
     are received.  This is needed to ensure proper sequencing of the
     Bind in relationship to other operations.

C.1.14. Section 4.2.3 (Bind Response)

- Moved most error-related text to Appendix A, and added text regarding certain errors used in conjunction with the Bind operation. - Prohibited the server from specifying serverSaslCreds when not appropriate.

C.1.15. Section 4.3 (Unbind Operation)

- Specified that both peers are to cease transmission and terminate the LDAP session for the Unbind operation.

C.1.16. Section 4.4 (Unsolicited Notification)

- Added instructions for future specifications of Unsolicited Notifications.

C.1.17. Section 4.5.1 (Search Request)

- SearchRequest attributes is now defined as an AttributeSelection type rather than AttributeDescriptionList, and an ABNF is provided. - SearchRequest attributes may contain duplicate attribute descriptions. This was previously prohibited. Now servers are instructed to ignore subsequent names when they are duplicated. This was relaxed in order to allow different short names and also OIDs to be requested for an attribute. - The present search filter now evaluates to Undefined when the specified attribute is not known to the server. It used to evaluate to FALSE, which caused behavior inconsistent with what most would expect, especially when the 'not' operator was used. - The Filter choice SubstringFilter substrings type is now defined with a lower bound of 1. - The SubstringFilter substrings 'initial, 'any', and 'final' types are now AssertionValue rather than LDAPString. Also, added imperatives stating that 'initial' (if present) must be listed first, and 'final' (if present) must be listed last. - Disambiguated the semantics of the derefAliases choices. There was question as to whether derefInSearching applied to the base object in a wholeSubtree Search. - Added instructions for equalityMatch, substrings, greaterOrEqual, lessOrEqual, and approxMatch.
Top   ToC   RFC4511 - Page 64

C.1.18. Section 4.5.2 (Search Result)

- Recommended that servers not use attribute short names when it knows they are ambiguous or may cause interoperability problems. - Removed all mention of ExtendedResponse due to lack of implementation.

C.1.19. Section 4.5.3 (Continuation References in the Search Result)

- Made changes similar to those made to Section 4.1.11.

C.1.20. Section (Example)

- Fixed examples to adhere to changes made to Section 4.5.3.

C.1.21. Section 4.6 (Modify Operation)

- Replaced AttributeTypeAndValues with Attribute as they are equivalent. - Specified the types of modification changes that might temporarily violate schema. Some readers were under the impression that any temporary schema violation was allowed.

C.1.22. Section 4.7 (Add Operation)

- Aligned Add operation with X.511 in that the attributes of the RDN are used in conjunction with the listed attributes to create the entry. Previously, Add required that the distinguished values be present in the listed attributes. - Removed requirement that the objectClass attribute MUST be specified as some DSE types do not require this attribute. Instead, generic wording was added, requiring the added entry to adhere to the data model. - Removed recommendation regarding placement of objects. This is covered in the data model document.

C.1.23. Section 4.9 (Modify DN Operation)

- Required servers to not dereference aliases for Modify DN. This was added for consistency with other operations and to help ensure data consistency. - Allow Modify DN to fail when moving between naming contexts. - Specified what happens when the attributes of the newrdn are not present on the entry.
Top   ToC   RFC4511 - Page 65

C.1.24. Section 4.10 (Compare Operation)

- Specified that compareFalse means that the Compare took place and the result is false. There was confusion that led people to believe that an Undefined match resulted in compareFalse. - Required servers to not dereference aliases for Compare. This was added for consistency with other operations and to help ensure data consistency.

C.1.25. Section 4.11 (Abandon Operation)

- Explained that since Abandon returns no response, clients should not use it if they need to know the outcome. - Specified that Abandon and Unbind cannot be abandoned.

C.1.26. Section 4.12 (Extended Operation)

- Specified how values of Extended operations defined in terms of ASN.1 are to be encoded. - Added instructions on what Extended operation specifications consist of. - Added a recommendation that servers advertise supported Extended operations.

C.1.27. Section 5.2 (Transfer Protocols)

- Moved referral-specific instructions into referral-related sections.

C.1.28. Section 7 (Security Considerations)

- Reworded notes regarding SASL not protecting certain aspects of the LDAP Bind messages. - Noted that Servers are encouraged to prevent directory modifications by clients that have authenticated anonymously [RFC4513]. - Added a note regarding the possibility of changes to security factors (authentication, authorization, and data confidentiality). - Warned against following referrals that may have been injected in the data stream. - Noted that servers should protect information equally, whether in an error condition or not, and mentioned matchedDN, diagnosticMessage, and resultCodes specifically. - Added a note regarding malformed and long encodings.
Top   ToC   RFC4511 - Page 66

C.1.29. Appendix A (Complete ASN.1 Definition)

- Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. - Removed AttributeType. It is not used.

C.2. Changes Made to RFC 2830

This section summarizes the substantive changes made to Sections of RFC 2830. Readers should consult [RFC4513] for summaries of changes to other sections.

C.2.1. Section 2.3 (Response other than "success")

- Removed wording indicating that referrals can be returned from StartTLS. - Removed requirement that only a narrow set of result codes can be returned. Some result codes are required in certain scenarios, but any other may be returned if appropriate. - Removed requirement that the ExtendedResponse.responseName MUST be present. There are circumstances where this is impossible, and requiring this is at odds with language in Section 4.12.

C.2.1. Section 4 (Closing a TLS Connection)

- Reworded most of this section to align with definitions of the LDAP protocol layers. - Removed instructions on abrupt closure as this is covered in other areas of the document (specifically, Section 5.3)

C.3. Changes Made to RFC 3771

- Rewrote to fit into this document. In general, semantics were preserved. Supporting and background language seen as redundant due to its presence in this document was omitted. - Specified that Intermediate responses to a request may be of different types, and one of the response types may be specified to have no response value.
Top   ToC   RFC4511 - Page 67

Editor's Address

Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606, USA Phone: +1 801 861-3088 EMail:
Top   ToC   RFC4511 - Page 68
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).