tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4511


Lightweight Directory Access Protocol (LDAP): The Protocol

Part 3 of 3, p. 42 to 68
Prev RFC Part


prevText      Top      Up      ToC       Page 42 
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

   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

   - 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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       Page 48 
9.  Informative References

   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
                 #17, Character Encoding Model", UTR17,
                 <>, August

   [Glossary]    The Unicode Consortium, "Unicode Glossary",

   [PortReg]     IANA, "Port Numbers",

   [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: 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
             Identifies the LDAP ASN.1 module

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.


        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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

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

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

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      Up      ToC       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

Top      Up      ToC       Page 62 
C.1.11.  Section 4.1.12 (Controls)

   - Specified how control values defined in terms of ASN.1 are to be
   - 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

C.1.12.  Section 4.2 (Bind Operation)

   - Mandated that servers return protocolError when the version is not
   - 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      Up      ToC       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
   - Prohibited the server from specifying serverSaslCreds when not

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

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
   - 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      Up      ToC       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

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
   - 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      Up      ToC       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

C.1.27.  Section 5.2 (Transfer Protocols)

   - Moved referral-specific instructions into referral-related

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
   - 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      Up      ToC       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
   - 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      Up      ToC       Page 67 
Editor's Address

   Jim Sermersheim
   Novell, Inc.
   1800 South Novell Place
   Provo, Utah 84606, USA

   Phone: +1 801 861-3088

Top      Up      ToC       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).