--- /dev/null
+
+
+
+
+
+
+Network Working Group W. Yeong
+Request for Comments: 1777 Performance Systems International
+Obsoletes: 1487 T. Howes
+Category: Standards Track University of Michigan
+ S. Kille
+ ISODE Consortium
+ March 1995
+
+
+ Lightweight Directory Access Protocol
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The protocol described in this document is designed to provide access
+ to the X.500 Directory while not incurring the resource requirements
+ of the Directory Access Protocol (DAP). This protocol is specifically
+ targeted at simple management applications and browser applications
+ that provide simple read/write interactive access to the X.500
+ Directory, and is intended to be a complement to the DAP itself.
+
+ Key aspects of LDAP are:
+
+ - Protocol elements are carried directly over TCP or other transport,
+ bypassing much of the session/presentation overhead.
+
+ - Many protocol data elements are encoding as ordinary strings (e.g.,
+ Distinguished Names).
+
+ - A lightweight BER encoding is used to encode all protocol elements.
+
+1. History
+
+ The tremendous interest in X.500 [1,2] technology in the Internet has
+ lead to efforts to reduce the high "cost of entry" associated with
+ use of the technology, such as the Directory Assistance Service [3]
+ and DIXIE [4]. While efforts such as these have met with success,
+ they have been solutions based on particular implementations and as
+ such have limited applicability. This document continues the efforts
+ to define Directory protocol alternatives but departs from previous
+ efforts in that it consciously avoids dependence on particular
+
+
+
+Yeong, Howes & Kille [Page 1]
+\f
+RFC 1777 LDAP March 1995
+
+
+ implementations.
+
+2. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, this
+ is accomplished by a client transmitting a protocol request
+ describing the operation to be performed to a server, which is then
+ responsible for performing the necessary operations on the Directory.
+ Upon completion of the necessary operations, the server returns a
+ response containing any results or errors to the requesting client.
+ In keeping with the goal of easing the costs associated with use of
+ the Directory, it is an objective of this protocol to minimize the
+ complexity of clients so as to facilitate widespread deployment of
+ applications capable of utilizing the Directory.
+
+ Note that, although servers are required to return responses whenever
+ such responses are defined in the protocol, there is no requirement
+ for synchronous behavior on the part of either client or server
+ implementations: requests and responses for multiple operations may
+ be exchanged by client and servers in any order, as long as clients
+ eventually receive a response for every request that requires one.
+
+ Consistent with the model of servers performing protocol operations
+ on behalf of clients, it is also to be noted that protocol servers
+ are expected to handle referrals without resorting to the return of
+ such referrals to the client. This protocol makes no provisions for
+ the return of referrals to clients, as the model is one of servers
+ ensuring the performance of all necessary operations in the
+ Directory, with only final results or errors being returned by
+ servers to clients.
+
+ Note that this protocol can be mapped to a strict subset of the
+ directory abstract service, so it can be cleanly provided by the DAP.
+
+3. Mapping Onto Transport Services
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, with all 8 bits in an octet being significant in the data
+ stream. Specifications for two underlying services are defined here,
+ though others are also possible.
+
+3.1. Transmission Control Protocol (TCP)
+
+ The LDAPMessage PDUs are mapped directly onto the TCP bytestream.
+ Server implementations running over the TCP should provide a protocol
+ listener on port 389.
+
+
+
+
+Yeong, Howes & Kille [Page 2]
+\f
+RFC 1777 LDAP March 1995
+
+
+3.2. Connection Oriented Transport Service (COTS)
+
+ The connection is established. No special use of T-Connect is made.
+ Each LDAPMessage PDU is mapped directly onto T-Data.
+
+4. Elements of Protocol
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+ LDAPMessage ::=
+ SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResponse SearchResponse,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modifyRDNRequest ModifyRDNRequest,
+ modifyRDNResponse ModifyRDNResponse,
+ compareDNRequest CompareRequest,
+ compareDNResponse CompareResponse,
+ abandonRequest AbandonRequest
+ }
+ }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time the
+ only common field is a message ID, which is required to have a value
+ different from the values of any other requests outstanding in the
+ LDAP session of which this message is a part.
+
+ The message ID value must be echoed in all LDAPMessage envelopes
+ encapsulting responses corresponding to the request contained in the
+ LDAPMessage in which the message ID value was originally used.
+
+ In addition to the LDAPMessage defined above, the following
+ definitions are also used in defining protocol operations:
+
+
+
+Yeong, Howes & Kille [Page 3]
+\f
+RFC 1777 LDAP March 1995
+
+
+ LDAPString ::= OCTET STRING
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as OCTET STRING types, the legal
+ character set in such strings is limited to the IA5 character set.
+
+ LDAPDN ::= LDAPString
+
+ RelativeLDAPDN ::= LDAPString
+
+ An LDAPDN and a RelativeLDAPDN are respectively defined to be the
+ representation of a Distinguished Name and a Relative Distinguished
+ Name after encoding according to the specification in [5], such that
+
+ <distinguished-name> ::= <name>
+
+ <relative-distinguished-name> ::= <name-component>
+
+ where <name> and <name-component> are as defined in [5].
+
+ AttributeValueAssertion ::=
+ SEQUENCE {
+ attributeType AttributeType,
+ attributeValue AttributeValue
+ }
+
+ The AttributeValueAssertion type definition is similar to the one in
+ the X.500 Directory standards.
+
+ AttributeType ::= LDAPString
+
+ AttributeValue ::= OCTET STRING
+
+ An AttributeType value takes on as its value the textual string
+ associated with that AttributeType in the X.500 Directory standards.
+ For example, the AttributeType 'organizationName' with object
+ identifier 2.5.4.10 is represented as an AttributeType in this
+ protocol by the string "organizationName". In the event that a
+ protocol implementation encounters an Attribute Type with which it
+ cannot associate a textual string, an ASCII string encoding of the
+ object identifier associated with the Attribute Type may be
+ subsitituted. For example, the organizationName AttributeType may be
+ represented by the ASCII string "2.5.4.10" if a protocol
+ implementation is unable to associate the string "organizationName"
+ with it.
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 4]
+\f
+RFC 1777 LDAP March 1995
+
+
+ A field of type AttributeValue takes on as its value an octet string
+ encoding of a Directory AttributeValue type. The definition of these
+ string encodings for different Directory AttributeValue types may be
+ found in companions to this document that define the encodings of
+ various attribute syntaxes such as [6].
+
+ LDAPResult ::=
+ SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ isLeaf (35),
+ aliasDereferencingProblem (36),
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ other (80)
+ },
+ matchedDN LDAPDN,
+ errorMessage LDAPString
+ }
+
+
+
+
+Yeong, Howes & Kille [Page 5]
+\f
+RFC 1777 LDAP March 1995
+
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. In response
+ to various requests, servers will return responses containing fields
+ of type LDAPResult to indicate the final status of a protocol
+ operation request. The errorMessage field of this construct may, at
+ the servers option, be used to return an ASCII string containing a
+ textual, human-readable error diagnostic. As this error diagnostic is
+ not standardized, implementations should not rely on the values
+ returned. If the server chooses not to return a textual diagnostic,
+ the errorMessage field of the LDAPResult type should contain a zero
+ length string.
+
+ For resultCodes of noSuchObject, aliasProblem, invalidDNSyntax,
+ isLeaf, and aliasDereferencingProblem, the matchedDN field is set to
+ the name of the lowest entry (object or alias) in the DIT that was
+ matched and is a truncated form of the name provided or, if an alias
+ has been dereferenced, of the resulting name. The matchedDN field
+ should be set to NULL DN (a zero length string) in all other cases.
+
+4.1. Bind Operation
+
+ The function of the Bind Operation is to initiate a protocol session
+ between a client and a server, and to allow the authentication of the
+ client to the server. The Bind Operation must be the first operation
+ request received by a server from a client in a protocol session.
+ The Bind Request is defined as follows:
+
+ BindRequest ::=
+ [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication CHOICE {
+ simple [0] OCTET STRING,
+ krbv42LDAP [1] OCTET STRING,
+ krbv42DSA [2] OCTET STRING
+ }
+ }
+
+ Parameters of the Bind Request are:
+
+ - version: A version number indicating the version of the protocol to
+ be used in this protocol session. This document describes version
+ 2 of the LDAP protocol. Note that there is no version negotiation,
+ and the client should just set this parameter to the version it
+ desires.
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 6]
+\f
+RFC 1777 LDAP March 1995
+
+
+ - name: The name of the Directory object that the client wishes to
+ bind as. This field may take on a null value (a zero length
+ string) for the purposes of anonymous binds.
+
+ - authentication: information used to authenticate the name, if any,
+ provided in the Bind Request. The "simple" authentication option
+ provides minimal authentication facilities, with the contents of
+ the authentication field consisting only of a cleartext password.
+ This option should also be used when unauthenticated or anonymous
+ binds are to be performed, with the field containing a zero length
+ string in such cases. Kerberos version 4 [7] authentication to the
+ LDAP server and the DSA is accomplished by using the "krbv42LDAP"
+ and "krbv42DSA" authentication options, respectively. Note that
+ though they are referred to as separate entities here, there is no
+ requirement these two entities be distinct (i.e., a DSA could speak
+ LDAP directly). Two separate authentication options are provided
+ to support all implementations. Each octet string should contain
+ the kerberos ticket (e.g., as returned by krb_mk_req()) for the
+ appropriate service. The suggested service name for authentication
+ to the LDAP server is "ldapserver". The suggested service name for
+ authentication to the DSA is "x500dsa". In both cases, the
+ suggested instance name for the service is the name of the host on
+ which the service is running. Of course, the actual service names
+ and instances will depend on what is entered in the local kerberos
+ principle database.
+
+ The Bind Operation requires a response, the Bind Response, which is
+ defined as:
+
+ BindResponse ::= [APPLICATION 1] LDAPResult
+
+ A Bind Response consists simply of an indication from the server of
+ the status of the client's request for the initiation of a protocol
+ session.
+
+ Upon receipt of a Bind Request, a protocol server will authenticate
+ the requesting client if necessary, and attempt to set up a protocol
+ session with that client. The server will then return a Bind Response
+ to the client indicating the status of the session setup request.
+
+4.2. Unbind Operation
+
+ The function of the Unbind Operation is to terminate a protocol
+ session. The Unbind Operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+
+
+
+
+Yeong, Howes & Kille [Page 7]
+\f
+RFC 1777 LDAP March 1995
+
+
+ The Unbind Operation has no response defined. Upon transmission of an
+ UnbindRequest, a protocol client may assume that the protocol session
+ is terminated. Upon receipt of an UnbindRequest, a protocol server
+ may assume that the requesting client has terminated the session and
+ that all outstanding requests may be discarded.
+
+4.3. Search Operation
+
+ The Search Operation allows a client to request that a search be
+ performed on its behalf by a server. The Search Request is defined as
+ follows:
+
+ 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),
+ attrsOnly BOOLEAN,
+ filter Filter,
+ attributes SEQUENCE OF AttributeType
+ }
+
+ Filter ::=
+ CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeType,
+ approxMatch [8] AttributeValueAssertion
+ }
+
+ SubstringFilter
+ SEQUENCE {
+
+
+
+Yeong, Howes & Kille [Page 8]
+\f
+RFC 1777 LDAP March 1995
+
+
+ type AttributeType,
+ SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString
+ }
+ }
+
+ Parameters of the Search Request are:
+
+ - baseObject: An LDAPDN that is the base object entry relative to
+ which the search is to be performed.
+
+ - scope: An indicator of the scope of the search to be performed. The
+ semantics of the possible values of this field are identical to the
+ semantics of the scope field in the Directory Search Operation.
+
+ - derefAliases: An indicator as to how alias objects should be
+ handled in searching. The semantics of the possible values of
+ this field are, in order of increasing value:
+
+ neverDerefAliases: do not dereference aliases in searching
+ or in locating the base object of the search;
+
+ derefInSearching: dereference aliases in subordinates of
+ the base object in searching, but not in locating the
+ base object of the search;
+
+ derefFindingBaseObject: dereference aliases in locating
+ the base object of the search, but not when searching
+ subordinates of the base object;
+
+ derefAlways: dereference aliases both in searching and in
+ locating the base object of the search.
+
+ - sizelimit: A sizelimit that restricts the maximum number of entries
+ to be returned as a result of the search. A value of 0 in this
+ field indicates that no sizelimit restrictions are in effect for
+ the search.
+
+ - timelimit: A timelimit that restricts the maximum time (in seconds)
+ allowed for a search. A value of 0 in this field indicates that no
+ timelimit restrictions are in effect for the search.
+
+ - attrsOnly: An indicator as to whether search results should contain
+ both attribute types and values, or just attribute types. Setting
+ this field to TRUE causes only attribute types (no values) to be
+ returned. Setting this field to FALSE causes both attribute types
+
+
+
+Yeong, Howes & Kille [Page 9]
+\f
+RFC 1777 LDAP March 1995
+
+
+ and values to be returned.
+
+ - filter: A filter that defines the conditions that must be fulfilled
+ in order for the search to match a given entry.
+
+ - attributes: A list of the attributes from each entry found as a
+ result of the search to be returned. An empty list signifies that
+ all attributes from each entry found in the search are to be
+ returned.
+
+ The results of the search attempted by the server upon receipt of a
+ Search Request are returned in Search Responses, defined as follows:
+
+ Search Response ::=
+ CHOICE {
+ entry [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes SEQUENCE OF SEQUENCE {
+ AttributeType,
+ SET OF AttributeValue
+ }
+ },
+ resultCode [APPLICATION 5] LDAPResult
+ }
+
+ Upon receipt of a Search Request, a server will perform the necessary
+ search of the DIT.
+
+ The server will return to the client a sequence of responses
+ comprised of:
+
+ - Zero or more Search Responses each consisting of an entry found
+ during the search; with the response sequence terminated by
+
+ - A single Search Response containing an indication of success, or
+ detailing any errors that have occurred.
+
+ Each entry returned will contain all attributes, complete with
+ associated values if necessary, as specified in the 'attributes'
+ field of the Search Request.
+
+ Note that an X.500 "list" operation can be emulated by a one-level
+ LDAP search operation with a filter checking for the existence of the
+ objectClass attribute, and that an X.500 "read" operation can be
+ emulated by a base object LDAP search operation with the same filter.
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 10]
+\f
+RFC 1777 LDAP March 1995
+
+
+4.4. Modify Operation
+
+ The Modify Operation allows a client to request that a modification
+ of the DIB be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ModifyRequest ::=
+ [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2)
+ },
+ modification SEQUENCE {
+ type AttributeType,
+ values SET OF
+ AttributeValue
+ }
+ }
+ }
+
+ Parameters of the Modify Request are:
+
+ - object: The object to be modified. The value of this field should
+ name the object to be modified after all aliases have been
+ dereferenced. The server will not perform any alias dereferencing
+ in determining the object to be modified.
+
+ - A list of modifications to be performed on the entry to be modified.
+ The entire list of entry modifications should be performed
+ in the order they are listed, as a single atomic operation. While
+ individual modifications may violate the Directory schema, the
+ resulting entry after the entire list of modifications is performed
+ must conform to the requirements of the Directory schema. The
+ values that may be taken on by the 'operation' field in each
+ modification construct have the following semantics respectively:
+
+ add: add values listed to the given attribute, creating
+ the attribute if necessary;
+
+ delete: delete values listed from the given attribute,
+
+ removing the entire attribute if no values are listed, or
+ if all current values of the attribute are listed for
+ deletion;
+
+
+
+
+Yeong, Howes & Kille [Page 11]
+\f
+RFC 1777 LDAP March 1995
+
+
+ replace: replace existing values of the given attribute
+ with the new values listed, creating the attribute if
+ necessary.
+
+ The result of the modify attempted by the server upon receipt of a
+ Modify Request is returned in a Modify Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ Upon receipt of a Modify Request, a server will perform the necessary
+ modifications to the DIB.
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIB modification,
+ or the reason that the modification failed. Note that due to the
+ requirement for atomicity in applying the list of modifications in
+ the Modify Request, the client may expect that no modifications of
+ the DIB have been performed if the Modify Response received indicates
+ any sort of error, and that all requested modifications have been
+ performed if the Modify Response indicates successful completion of
+ the Modify Operation.
+
+4.5. Add Operation
+
+ The Add Operation allows a client to request the addition of an entry
+ into the Directory. The Add Request is defined as follows:
+
+ AddRequest ::=
+ [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attrs SEQUENCE OF SEQUENCE {
+ type AttributeType,
+ values SET OF AttributeValue
+ }
+ }
+
+ Parameters of the Add Request are:
+
+ - entry: the Distinguished Name of the entry to be added. Note that
+ all components of the name except for the last RDN component must
+ exist for the add to succeed.
+
+ - attrs: the list of attributes that make up the content of the entry
+ being added.
+
+ The result of the add attempted by the server upon receipt of a Add
+ Request is returned in the Add Response, defined as follows:
+
+
+
+
+Yeong, Howes & Kille [Page 12]
+\f
+RFC 1777 LDAP March 1995
+
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ Upon receipt of an Add Request, a server will attempt to perform the
+ add requested. The result of the add attempt will be returned to the
+ client in the Add Response.
+
+4.6. Delete Operation
+
+ The Delete Operation allows a client to request the removal of an
+ entry from the Directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ The Delete Request consists only of the Distinguished Name of the
+ entry to be deleted. The result of the delete attempted by the
+ server upon receipt of a Delete Request is returned in the Delete
+ Response, defined as follows:
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested. The result of the delete attempt will be
+ returned to the client in the Delete Response. Note that only leaf
+ objects may be deleted with this operation.
+
+4.7. Modify RDN Operation
+
+ The Modify RDN Operation allows a client to change the last component
+ of the name of an entry in the Directory. The Modify RDN Request is
+ defined as follows:
+
+ ModifyRDNRequest ::=
+ [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN
+ }
+
+ Parameters of the Modify RDN Request are:
+
+ - entry: the name of the entry to be changed.
+
+ - newrdn: the RDN that will form the last component of the new name.
+
+ - deleteoldrdn: a boolean parameter that controls whether the old RDN
+ attribute values should be retained as attributes of the entry or
+ deleted from the entry.
+
+
+
+
+Yeong, Howes & Kille [Page 13]
+\f
+RFC 1777 LDAP March 1995
+
+
+ The result of the name change attempted by the server upon receipt of
+ a Modify RDN Request is returned in the Modify RDN Response, defined
+ as follows:
+
+ ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
+
+ Upon receipt of a Modify RDN Request, a server will attempt to
+ perform the name change. The result of the name change attempt will
+ be returned to the client in the Modify RDN Response. The attributes
+ that make up the old RDN are deleted from the entry, or kept,
+ depending on the setting of the deleteoldrdn parameter.
+
+4.8. Compare Operation
+
+ The Compare Operation allows a client to compare an assertion
+ provided with an entry in the Directory. The Compare Request is
+ defined as follows:
+
+ CompareRequest ::=
+ [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion
+ }
+
+ Parameters of the Compare Request are:
+
+ - entry: the name of the entry to be compared with.
+
+ - ava: the assertion with which the entry is to be compared.
+
+ The result of the compare attempted by the server upon receipt of a
+ Compare Request is returned in the Compare Response, defined as
+ follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison. The result of the comparison will be
+ returned to the client in the Compare Response. Note that errors and
+ the result of comparison are all returned in the same construct.
+
+6.9. Abandon Operation
+
+ The function of the Abandon Operation is to allow a client to request
+ that the server abandon an outstanding operation. The Abandon
+ Request is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+
+
+Yeong, Howes & Kille [Page 14]
+\f
+RFC 1777 LDAP March 1995
+
+
+ There is no response defined in the Abandon Operation. Upon
+ transmission of an Abandon Operation, a client may expect that the
+ operation identityfied by the Message ID in the Abandon Request has
+ been abandoned. In the event that a server receives an Abandon
+ Request on a Search Operation in the midst of transmitting responses
+ to that search, that server should cease transmitting responses to
+ the abandoned search immediately.
+
+5. Protocol Element Encodings
+
+ The protocol elements of LDAP are encoded for exchange using the
+ Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the
+ high overhead involved in using certain elements of the BER, the
+ following additional restrictions are placed on BER-encodings of LDAP
+ protocol elements:
+
+ (1) Only the definite form of length encoding will be used.
+
+ (2) Bitstrings and octet strings and all character string types
+ will be encoded in the primitive form only.
+
+6. Security Considerations
+
+ This version of the protocol provides facilities only for simple
+ authentication using a cleartext password, and for kerberos version 4
+ authentication. Future versions of LDAP will likely include support
+ for other authentication methods.
+
+7. Bibliography
+
+ [1] The Directory: Overview of Concepts, Models and Service. CCITT
+ Recommendation X.500, 1988.
+
+ [2] Information Processing Systems -- Open Systems Interconnection --
+ The Directory: Overview of Concepts, Models and Service. ISO/IEC
+ JTC 1/SC21; International Standard 9594-1, 1988
+
+ [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
+ Systems International, Inc., February 1991.
+
+ [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol
+ Specification, RFC 1249, University of Michigan, August 1991.
+
+ [5] Kille, S., "A String Representation of Distinguished Names", RFC
+ 1779, ISODE Consortium, March 1995.
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 15]
+\f
+RFC 1777 LDAP March 1995
+
+
+ [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight
+ Directory Access Protocol", RFC 1488, University of Michigan,
+ ISODE Consortium, Performance Systems International, NeXor Ltd.,
+ July 1993.
+
+ [7] Kerberos Authentication and Authorization System. S.P. Miller,
+ B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena
+ Documentation Section E.2.1, December 1987.
+
+ [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
+ 1/SC21; International Standard 9594-2, 1988.
+
+ [10] The Directory: Abstract Service Definition. CCITT Recommendation
+ X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
+
+ [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT
+ Recommendation X.208, 1988.
+
+ [12] Specification of Basic Encoding Rules for Abstract Syntax
+ Notation One (ASN.1). CCITT Recommendation X.209, 1988.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 16]
+\f
+RFC 1777 LDAP March 1995
+
+
+10. Authors' Addresses
+
+ Wengyik Yeong
+ PSI Inc.
+ 510 Huntmar Park Drive
+ Herndon, VA 22070
+ USA
+
+ Phone: +1 703-450-8001
+ EMail: yeongw@psilink.com
+
+
+ Tim Howes
+ University of Michigan
+ ITD Research Systems
+ 535 W William St.
+ Ann Arbor, MI 48103-4943
+ USA
+
+ Phone: +1 313 747-4454
+ EMail: tim@umich.edu
+
+
+ Steve Kille
+ ISODE Consortium
+ PO Box 505
+ London
+ SW11 1DX
+ UK
+
+ Phone: +44-71-223-4062
+ EMail: S.Kille@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 17]
+\f
+RFC 1777 LDAP March 1995
+
+
+Appendix A - Complete ASN.1 Definition
+
+Lightweight-Directory-Access-Protocol DEFINITIONS IMPLICIT TAGS ::=
+
+BEGIN
+
+LDAPMessage ::=
+ SEQUENCE {
+ messageID MessageID,
+ -- unique id in request,
+ -- to be echoed in response(s)
+ protocolOp CHOICE {
+ searchRequest SearchRequest,
+ searchResponse SearchResponse,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modifyDNRequest ModifyDNRequest,
+ modifyDNResponse ModifyDNResponse,
+ compareDNRequest CompareRequest,
+ compareDNResponse CompareResponse,
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ abandonRequest AbandonRequest,
+ unbindRequest UnbindRequest
+ }
+ }
+
+BindRequest ::=
+ [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ -- current version is 2
+ name LDAPDN,
+ -- null name implies an anonymous bind
+ authentication CHOICE {
+ simple [0] OCTET STRING,
+ -- a zero length octet string
+ -- implies an unauthenticated
+ -- bind.
+ krbv42LDAP [1] OCTET STRING,
+ krbv42DSA [2] OCTET STRING
+ -- values as returned by
+ -- krb_mk_req()
+ -- Other values in later versions
+ -- of this protocol.
+
+
+
+Yeong, Howes & Kille [Page 18]
+\f
+RFC 1777 LDAP March 1995
+
+
+ }
+ }
+
+BindResponse ::= [APPLICATION 1] LDAPResult
+
+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),
+ alwaysDerefAliases (3)
+ },
+ sizeLimit INTEGER (0 .. maxInt),
+ -- value of 0 implies no sizelimit
+ timeLimit INTEGER (0 .. maxInt),
+ -- value of 0 implies no timelimit
+ attrsOnly BOOLEAN,
+ -- TRUE, if only attributes (without values)
+ -- to be returned.
+ filter Filter,
+ attributes SEQUENCE OF AttributeType
+ }
+
+SearchResponse ::=
+ CHOICE {
+ entry [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes SEQUENCE OF SEQUENCE {
+ AttributeType,
+ SET OF
+ AttributeValue
+ }
+ },
+ resultCode [APPLICATION 5] LDAPResult
+ }
+
+ModifyRequest ::=
+ [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+
+
+
+Yeong, Howes & Kille [Page 19]
+\f
+RFC 1777 LDAP March 1995
+
+
+ modifications SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2)
+ },
+ modification SEQUENCE {
+ type AttributeType,
+ values SET OF
+ AttributeValue
+ }
+ }
+ }
+
+
+ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+AddRequest ::=
+ [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attrs SEQUENCE OF SEQUENCE {
+ type AttributeType,
+ values SET OF AttributeValue
+ }
+ }
+
+AddResponse ::= [APPLICATION 9] LDAPResult
+
+DelRequest ::= [APPLICATION 10] LDAPDN
+
+DelResponse ::= [APPLICATION 11] LDAPResult
+
+ModifyRDNRequest ::=
+ [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN -- old RDN always deleted
+ }
+
+ModifyRDNResponse ::= [APPLICATION 13] LDAPResult
+
+CompareRequest ::=
+ [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion
+ }
+
+CompareResponse ::= [APPLICATION 15] LDAPResult
+
+
+
+
+Yeong, Howes & Kille [Page 20]
+\f
+RFC 1777 LDAP March 1995
+
+
+AbandonRequest ::= [APPLICATION 16] MessageID
+
+MessageID ::= INTEGER (0 .. maxInt)
+
+LDAPDN ::= LDAPString
+
+RelativeLDAPDN ::= LDAPString
+
+Filter ::=
+ CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeType,
+ approxMatch [8] AttributeValueAssertion
+ }
+
+LDAPResult ::=
+ SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ isLeaf (35),
+ aliasDereferencingProblem (36),
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+
+
+
+Yeong, Howes & Kille [Page 21]
+\f
+RFC 1777 LDAP March 1995
+
+
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ other (80)
+ },
+ matchedDN LDAPDN,
+ errorMessage LDAPString
+ }
+
+AttributeType ::= LDAPString
+ -- text name of the attribute, or dotted
+ -- OID representation
+
+AttributeValue ::= OCTET STRING
+
+AttributeValueAssertion ::=
+ SEQUENCE {
+ attributeType AttributeType,
+ attributeValue AttributeValue
+ }
+
+SubstringFilter ::=
+ SEQUENCE {
+ type AttributeType,
+ SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString
+ }
+ }
+
+LDAPString ::= OCTET STRING
+
+maxInt INTEGER ::= 65535
+END
+
+
+
+
+
+
+
+
+
+
+Yeong, Howes & Kille [Page 22]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 1779 ISODE Consortium
+Obsoletes: 1485 March 1995
+Category: Standards Track
+
+
+ A String Representation of Distinguished Names
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The OSI Directory uses distinguished names as the primary keys to
+ entries in the directory. Distinguished Names are encoded in ASN.1.
+ When a distinguished name is communicated between to users not using
+ a directory protocol (e.g., in a mail message), there is a need to
+ have a user-oriented string representation of distinguished name.
+ This specification defines a string format for representing names,
+ which is designed to give a clean representation of commonly used
+ names, whilst being able to represent any distinguished name.
+
+Table of Contents
+
+ 1. Why a notation is needed ................................... 2
+ 2. A notation for Distinguished Name .......................... 2
+ 2.1 Goals ................................................ 2
+ 2.2 Informal definition .................................. 2
+ 2.3 Formal definition .................................... 4
+ 3. Examples ................................................... 6
+ 4. Acknowledgements ........................................... 7
+ 5. References ................................................. 7
+ 6. Security Considerations .................................... 8
+ 7. Author's Address ........................................... 8
+
+
+
+
+
+
+
+
+
+
+
+
+Kille [Page 1]
+\f
+RFC 1779 DN Representation March 1995
+
+
+1. Why a notation is needed
+
+ Many OSI Applications make use of Distinguished Names (DN) as defined
+ in the OSI Directory, commonly known as X.500 [1]. This
+ specification assumes familiarity with X.500, and the concept of
+ Distinguished Name. It is important to have a common format to be
+ able to unambiguously represent a distinguished name. This might be
+ done to represent a directory name on a business card or in an email
+ message. There is a need for a format to support human to human
+ communication, which must be string based (not ASN.1) and user
+ oriented. This notation is targeted towards a general user oriented
+ system, and in particular to represent the names of humans. Other
+ syntaxes may be more appropriate for other uses of the directory.
+ For example, the OSF Syntax may be more appropriate for some system
+ oriented uses. (The OSF Syntax uses "/" as a separator, and forms
+ names in a manner intended to resemble UNIX filenames).
+
+2. A notation for Distinguished Name
+
+2.1 Goals
+
+ The following goals are laid out:
+
+ o To provide an unambiguous representation of a distinguished name
+
+ o To be an intuitive format for the majority of names
+
+ o To be fully general, and able to represent any distinguished name
+
+ o To be amenable to a number of different layouts to achieve an
+ attractive representation.
+
+ o To give a clear representation of the contents of the
+ distinguished name
+
+2.2 Informal definition
+
+ This notation is designed to be convenient for common forms of name.
+ Some examples are given. The author's directory distinguished name
+ would be written:
+
+ CN=Steve Kille,
+ O=ISODE Consortium, C=GB
+
+
+
+
+
+
+
+
+Kille [Page 2]
+\f
+RFC 1779 DN Representation March 1995
+
+
+ This may be folded, perhaps to display in multi-column format. For
+ example:
+
+ CN=Steve Kille,
+ O=ISODE Consortium,
+ C=GB
+
+ Another name might be:
+
+ CN=Christian Huitema, O=INRIA, C=FR
+
+ Semicolon (";") may be used as an alternate separator. The
+ separators may be mixed, but this usage is discouraged.
+
+ CN=Christian Huitema; O=INRIA; C=FR
+
+ In running text, this would be written as <CN=Christian Huitema;
+ O=INRIA; C=FR>. Another example, shows how different attribute types
+ are handled:
+
+ CN=James Hacker,
+ L=Basingstoke,
+ O=Widget Inc,
+ C=GB
+
+ Here is an example of a multi-valued Relative Distinguished Name,
+ where the namespace is flat within an organisation, and department is
+ used to disambiguate certain names:
+
+ OU=Sales + CN=J. Smith, O=Widget Inc., C=US
+
+ The final examples show both methods quoting of a comma in an
+ Organisation name:
+
+ CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
+
+ CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille [Page 3]
+\f
+RFC 1779 DN Representation March 1995
+
+
+2.3 Formal definition
+
+ A formal definition can now be given. The structure is specified in
+ a BNF grammar in Figure 1. This BNF uses the grammar defined in RFC
+ 822, with the terminals enclosed in <> [2]. This definition is in an
+ abstract character set, and so may be written in any character set
+ supporting the explicitly defined special characters. The quoting
+ mechanism is used for the following cases:
+
+ o Strings containing ",", "+", "=" or """ , <CR>, "<",
+ ">", "#", or ";".
+
+ o Strings with leading or trailing spaces
+
+ o Strings containing consecutive spaces
+
+ There is an escape mechanism from the normal user oriented form, so
+ that this syntax may be used to print any valid distinguished name.
+ This is ugly. It is expected to be used only in pathological cases.
+ There are two parts to this mechanism:
+
+ 1. Attributes types are represented in a (big-endian) dotted
+ notation. (e.g., OID.2.6.53).
+
+ 2. Attribute values are represented in hexadecimal (e.g. #0A56CF).
+ Each pair of hex digits defines an octet, which is the ASN.1 Basic
+ Encoding Rules value of the Attribute Value.
+
+ The keyword specification is optional in the BNF, but mandatory for
+ this specification. This is so that the same BNF may be used for the
+ related specification on User Friendly Naming [5]. When this
+ specification is followed, the attribute type keywords must always be
+ present.
+
+ A list of valid keywords for well known attribute types used in
+ naming is given in Table 1. Keywords may contain spaces, but shall
+ not have leading or trailing spaces. This is a list of keywords
+ which must be supported. These are chosen because they appear in
+ common forms of name, and can do so in a place which does not
+ correspond to the default schema used. A register of valid keywords
+ is maintained by the IANA.
+
+
+
+
+
+
+
+
+
+
+Kille [Page 4]
+\f
+RFC 1779 DN Representation March 1995
+
+
+ <name> ::= <name-component> ( <spaced-separator> )
+ | <name-component> <spaced-separator> <name>
+
+ <spaced-separator> ::= <optional-space>
+ <separator>
+ <optional-space>
+
+ <separator> ::= "," | ";"
+
+ <optional-space> ::= ( <CR> ) *( " " )
+
+ <name-component> ::= <attribute>
+ | <attribute> <optional-space> "+"
+ <optional-space> <name-component>
+
+ <attribute> ::= <string>
+ | <key> <optional-space> "=" <optional-space> <string>
+
+ <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
+ <keychar> ::= letters, numbers, and space
+
+ <oid> ::= <digitstring> | <digitstring> "." <oid>
+ <digitstring> ::= 1*<digit>
+ <digit> ::= digits 0-9
+
+ <string> ::= *( <stringchar> | <pair> )
+ | '"' *( <stringchar> | <special> | <pair> ) '"'
+ | "#" <hex>
+
+
+ <special> ::= "," | "=" | <CR> | "+" | "<" | ">"
+ | "#" | ";"
+
+ <pair> ::= "\" ( <special> | "\" | '"')
+ <stringchar> ::= any character except <special> or "\" or '"'
+
+
+ <hex> ::= 2*<hexchar>
+ <hexchar> ::= 0-9, a-f, A-F
+
+
+
+ Figure 1: BNF Grammar for Distinguished Name
+
+
+
+
+
+
+
+
+Kille [Page 5]
+\f
+RFC 1779 DN Representation March 1995
+
+
+ Key Attribute (X.520 keys)
+ ------------------------------
+ CN CommonName
+ L LocalityName
+ ST StateOrProvinceName
+ O OrganizationName
+ OU OrganizationalUnitName
+ C CountryName
+ STREET StreetAddress
+
+
+ Table 1: Standardised Keywords
+
+
+ Only string type attributes are considered, but other attribute
+ syntaxes could be supported locally (e.g., by use of the syntexes
+ defined in [3].) It is assumed that the interface will translate
+ from the supplied string into an appropriate Directory String
+ encoding. The "+" notation is used to specify multi-component RDNs.
+ In this case, the types for attributes in the RDN must be explicit.
+
+ The name is presented/input in a little-endian order (most
+ significant component last). When an address is written in a context
+ where there is a need to delimit the entire address (e.g., in free
+ text), it is recommended that the delimiters <> are used. The
+ terminator > is a special in the notation to facilitate this
+ delimitation.
+
+3. Examples
+
+ This section gives a few examples of distinguished names written
+ using this notation:
+
+ CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
+ ST=California, C=US
+
+ CN=FTAM Service, CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ CN=Markus Kuhn, O=University of Erlangen, C=DE
+
+ CN=Steve Kille,
+ O=ISODE Consortium,
+ C=GB
+
+
+
+
+
+
+
+Kille [Page 6]
+\f
+RFC 1779 DN Representation March 1995
+
+
+ CN=Steve Kille ,
+
+ O = ISODE Consortium,
+ C=GB
+
+ CN=Steve Kille, O=ISODE Consortium, C=GB
+
+4. Acknowledgements
+
+ This work was based on research work done at University College
+ London [4], and evolved by the IETF OSI-DS WG.
+
+ Input for this version of the document was received from: Allan
+ Cargille (University of Wisconsin); John Dale (COS); Philip Gladstone
+ (Onsett); John Hawthorne (US Air Force); Roland Hedberg (University
+ of Umea); Kipp Hickman (Mosaic Communications Corp.) Markus Kuhn
+ (University of Erlangen); Elisabeth Roudier (E3X); Mark Wahl (ISODE
+ Consortium).
+
+5. References
+
+ [1] The Directory --- overview of concepts, models and services,
+ 1993. CCITT X.500 Series Recommendations.
+
+ [2] Crocker, D., "Standard of the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [3] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol", RFC 1777, Performance Systems International,
+ University of Michigan, ISODE Consortium, March 1995.
+
+ [4] S.E. Kille. Using the OSI directory to achieve user friendly
+ naming. Research Note RN/20/29, Department of Computer Science,
+ University College London, February 1990.
+
+ [5] Kille, S., "Using the OSI Directory to Achieve User Friendly
+ Naming", RFC 1781, ISODE Consortium, March 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille [Page 7]
+\f
+RFC 1779 DN Representation March 1995
+
+
+6. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+7. Author's Address
+
+ Steve Kille
+ ISODE Consortium
+ The Dome
+ The Square
+ Richmond, Surrey
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille@ISODE.COM
+
+ DN: CN=Steve Kille,
+ O=ISODE Consortium, C=GB
+
+ UFN: S. Kille,
+ ISODE Consortium, GB
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille [Page 8]
+\f
git.samba.org / bbaumbach / samba-autobuild / .git / commitdiff