From a72a455e29fa695d06699cbca449ba84ce5fc43a Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Sun, 6 Aug 2006 18:05:43 +0000 Subject: r17433: remove obsoleted RFCs (This used to be commit 7dffabc744271b0ab98d00c0cc23600d1b536d29) --- source4/ldap_server/devdocs/Index | 10 +- source4/ldap_server/devdocs/rfc1777.txt | 1235 -------------- source4/ldap_server/devdocs/rfc1779.txt | 451 ----- source4/ldap_server/devdocs/rfc2251.txt | 2803 ------------------------------- source4/ldap_server/devdocs/rfc2252.txt | 1795 -------------------- source4/ldap_server/devdocs/rfc2253.txt | 563 ------- source4/ldap_server/devdocs/rfc2254.txt | 451 ----- source4/ldap_server/devdocs/rfc2255.txt | 563 ------- source4/ldap_server/devdocs/rfc2256.txt | 1123 ------------- 9 files changed, 1 insertion(+), 8993 deletions(-) delete mode 100644 source4/ldap_server/devdocs/rfc1777.txt delete mode 100644 source4/ldap_server/devdocs/rfc1779.txt delete mode 100644 source4/ldap_server/devdocs/rfc2251.txt delete mode 100644 source4/ldap_server/devdocs/rfc2252.txt delete mode 100644 source4/ldap_server/devdocs/rfc2253.txt delete mode 100644 source4/ldap_server/devdocs/rfc2254.txt delete mode 100644 source4/ldap_server/devdocs/rfc2255.txt delete mode 100644 source4/ldap_server/devdocs/rfc2256.txt diff --git a/source4/ldap_server/devdocs/Index b/source4/ldap_server/devdocs/Index index 6a83af13ac..3be797ea5b 100644 --- a/source4/ldap_server/devdocs/Index +++ b/source4/ldap_server/devdocs/Index @@ -1,13 +1,4 @@ -RFC 1777 - Lightweight Directory Access Protocol -RFC 1778 - The String Representation of Standard Attribute Syntaxes -RFC 1779 - A String Representation of Distinguished Names RFC 1823 - The LDAP Application Program Interface -RFC 2251 - Lightweight Directory Access Protocol (v3) -RFC 2252 - LDAPv3: Attribute Syntax Definitions -RFC 2253 - LDAPv3: UTF-8 String Representation of Distinguished Names -RFC 2254 - The String Representation of LDAP Search Filters -RFC 2255 - The LDAP URL Format -RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2307 - An Approach for Using LDAP as a Network Information Service RFC 2696 - LDAP Control Extension for Simple Paged Results Manipulation RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification @@ -17,3 +8,4 @@ RFC 3296 - Named Subordinate References in LDAP Directories Expired but used Draft: ldapext-ldapv3-vlv-04: LDAP Extensions for Scrolling View Browsing of Search Results +RFC 4510 diff --git a/source4/ldap_server/devdocs/rfc1777.txt b/source4/ldap_server/devdocs/rfc1777.txt deleted file mode 100644 index f5593e72a2..0000000000 --- a/source4/ldap_server/devdocs/rfc1777.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -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] - -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] - -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] - -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 - - ::= - - ::= - - where and 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/source4/ldap_server/devdocs/rfc1779.txt b/source4/ldap_server/devdocs/rfc1779.txt deleted file mode 100644 index a487e9e788..0000000000 --- a/source4/ldap_server/devdocs/rfc1779.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -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] - -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] - -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 . 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] - -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 """ , , "<", - ">", "#", 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] - -RFC 1779 DN Representation March 1995 - - - ::= ( ) - | - - ::= - - - - ::= "," | ";" - - ::= ( ) *( " " ) - - ::= - | "+" - - - ::= - | "=" - - ::= 1*( ) | "OID." | "oid." - ::= letters, numbers, and space - - ::= | "." - ::= 1* - ::= digits 0-9 - - ::= *( | ) - | '"' *( | | ) '"' - | "#" - - - ::= "," | "=" | | "+" | "<" | ">" - | "#" | ";" - - ::= "\" ( | "\" | '"') - ::= any character except or "\" or '"' - - - ::= 2* - ::= 0-9, a-f, A-F - - - - Figure 1: BNF Grammar for Distinguished Name - - - - - - - - -Kille [Page 5] - -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] - -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] - -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] - diff --git a/source4/ldap_server/devdocs/rfc2251.txt b/source4/ldap_server/devdocs/rfc2251.txt deleted file mode 100644 index 88844cbf38..0000000000 --- a/source4/ldap_server/devdocs/rfc2251.txt +++ /dev/null @@ -1,2803 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2251 Critical Angle Inc. -Category: Standards Track T. Howes - Netscape Communications Corp. - S. Kille - Isode Limited - December 1997 - - - Lightweight Directory Access Protocol (v3) - -1. 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. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - - -Wahl, et. al. Standards Track [Page 1] - -RFC 2251 LDAPv3 December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -Table of Contents - - 1. Status of this Memo .................................... 1 - Copyright Notice ....................................... 1 - IESG Note .............................................. 1 - 2. Abstract ............................................... 3 - 3. Models ................................................. 4 - 3.1. Protocol Model ........................................ 4 - 3.2. Data Model ............................................ 5 - 3.2.1. Attributes of Entries ............................... 5 - 3.2.2. Subschema Entries and Subentries .................... 7 - 3.3. Relationship to X.500 ................................. 8 - 3.4. Server-specific Data Requirements ..................... 8 - 4. Elements of Protocol ................................... 9 - 4.1. Common Elements ....................................... 9 - 4.1.1. Message Envelope .................................... 9 - 4.1.1.1. Message ID ........................................ 11 - 4.1.2. String Types ........................................ 11 - 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 - 4.1.4. Attribute Type ...................................... 12 - 4.1.5. Attribute Description ............................... 13 - 4.1.5.1. Binary Option ..................................... 14 - 4.1.6. Attribute Value ..................................... 14 - 4.1.7. Attribute Value Assertion ........................... 15 - 4.1.8. Attribute ........................................... 15 - 4.1.9. Matching Rule Identifier ............................ 15 - 4.1.10. Result Message ..................................... 16 - 4.1.11. Referral ........................................... 18 - 4.1.12. Controls ........................................... 19 - 4.2. Bind Operation ........................................ 20 - 4.2.1. Sequencing of the Bind Request ...................... 21 - 4.2.2. Authentication and Other Security Services .......... 22 - 4.2.3. Bind Response ....................................... 23 - 4.3. Unbind Operation ...................................... 24 - 4.4. Unsolicited Notification .............................. 24 - 4.4.1. Notice of Disconnection ............................. 24 - 4.5. Search Operation ...................................... 25 - - - -Wahl, et. al. Standards Track [Page 2] - -RFC 2251 LDAPv3 December 1997 - - - 4.5.1. Search Request ...................................... 25 - 4.5.2. Search Result ....................................... 29 - 4.5.3. Continuation References in the Search Result ........ 31 - 4.5.3.1. Example ........................................... 31 - 4.6. Modify Operation ...................................... 32 - 4.7. Add Operation ......................................... 34 - 4.8. Delete Operation ...................................... 35 - 4.9. Modify DN Operation ................................... 36 - 4.10. Compare Operation .................................... 37 - 4.11. Abandon Operation .................................... 38 - 4.12. Extended Operation ................................... 38 - 5. Protocol Element Encodings and Transfer ................ 39 - 5.1. Mapping Onto BER-based Transport Services ............. 39 - 5.2. Transfer Protocols .................................... 40 - 5.2.1. Transmission Control Protocol (TCP) ................. 40 - 6. Implementation Guidelines .............................. 40 - 6.1. Server Implementations ................................ 40 - 6.2. Client Implementations ................................ 40 - 7. Security Considerations ................................ 41 - 8. Acknowledgements ....................................... 41 - 9. Bibliography ........................................... 41 - 10. Authors' Addresses ..................................... 42 - Appendix A - Complete ASN.1 Definition ..................... 44 - Full Copyright Statement ................................... 50 - -2. Abstract - - The protocol described in this document is designed to provide access - to directories supporting the X.500 models, while not incurring the - resource requirements of the X.500 Directory Access Protocol (DAP). - This protocol is specifically targeted at management applications and - browser applications that provide read/write interactive access to - directories. When used with a directory supporting the X.500 - protocols, it is intended to be a complement to the X.500 DAP. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document - are to be interpreted as described in RFC 2119 [10]. - - Key aspects of this version of LDAP are: - - - All protocol elements of LDAPv2 (RFC 1777) are supported. The - protocol is carried directly over TCP or other transport, bypassing - much of the session/presentation overhead of X.500 DAP. - - - Most protocol data elements can be encoded as ordinary strings - (e.g., Distinguished Names). - - - - -Wahl, et. al. Standards Track [Page 3] - -RFC 2251 LDAPv3 December 1997 - - - - Referrals to other servers may be returned. - - - SASL mechanisms may be used with LDAP to provide association - security services. - - - Attribute values and Distinguished Names have been - internationalized through the use of the ISO 10646 character set. - - - The protocol can be extended to support new operations, and - controls may be used to extend existing operations. - - - Schema is published in the directory for use by clients. - -3. Models - - Interest in X.500 [1] directory technologies in the Internet has led - to efforts to reduce the high cost of entry associated with use of - these technologies. This document continues the efforts to define - directory protocol alternatives, updating the LDAP [2] protocol - specification. - -3.1. Protocol Model - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, a - client transmits a protocol request describing the operation to be - performed to a server. The server is then responsible for performing - the necessary operation(s) in the directory. Upon completion of the - operation(s), 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 using 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 clients or servers. - Requests and responses for multiple operations may be exchanged - between a client and server in any order, provided the client - eventually receives a response for every request that requires one. - - In LDAP versions 1 and 2, no provision was made for protocol servers - returning referrals to clients. However, for improved performance - and distribution this version of the protocol permits servers to - return to clients referrals to other servers. This allows servers to - offload the work of contacting other servers to progress operations. - - - -Wahl, et. al. Standards Track [Page 4] - -RFC 2251 LDAPv3 December 1997 - - - Note that the core protocol operations defined in this document can - be mapped to a strict subset of the X.500(1997) directory abstract - service, so it can be cleanly provided by the DAP. However there is - not a one-to-one mapping between LDAP protocol operations and DAP - operations: server implementations acting as a gateway to X.500 - directories may need to make multiple DAP requests. - -3.2. Data Model - - This section provides a brief introduction to the X.500 data model, - as used by LDAP. - - The LDAP protocol assumes there are one or more servers which jointly - provide access to a Directory Information Tree (DIT). The tree is - made up of entries. Entries have names: one or more attribute values - from the entry form its relative distinguished name (RDN), which MUST - be unique among all its siblings. The concatenation of the relative - distinguished names of the sequence of entries from a particular - entry to an immediate subordinate of the root of the tree forms that - entry's Distinguished Name (DN), which is unique in the tree. An - example of a Distinguished Name is - - CN=Steve Kille, O=Isode Limited, C=GB - - Some servers may hold cache or shadow copies of entries, which can be - used to answer search and comparison queries, but will return - referrals or contact other servers if modification operations are - requested. - - Servers which perform caching or shadowing MUST ensure that they do - not violate any access control constraints placed on the data by the - originating server. - - The largest collection of entries, starting at an entry that is - mastered by a particular server, and including all its subordinates - and their subordinates, down to the entries which are mastered by - different servers, is termed a naming context. The root of the DIT - is a DSA-specific Entry (DSE) and not part of any naming context: - each server has different attribute values in the root DSE. (DSA is - an X.500 term for the directory server). - -3.2.1. Attributes of Entries - - Entries consist of a set of attributes. An attribute is a type with - one or more associated values. The attribute type is identified by a - short descriptive name and an OID (object identifier). The attribute - - - - - -Wahl, et. al. Standards Track [Page 5] - -RFC 2251 LDAPv3 December 1997 - - - type governs whether there can be more than one value of an attribute - of that type in an entry, the syntax to which the values must - conform, the kinds of matching which can be performed on values of - that attribute, and other functions. - - An example of an attribute is "mail". There may be one or more values - of this attribute, they must be IA5 (ASCII) strings, and they are - case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). - - Schema is the collection of attribute type definitions, object class - definitions and other information which a server uses to determine - how to match a filter or attribute value assertion (in a compare - operation) against the attributes of an entry, and whether to permit - add and modify operations. The definition of schema for use with - LDAP is given in [5] and [6]. Additional schema elements may be - defined in other documents. - - Each entry MUST have an objectClass attribute. The objectClass - attribute specifies the object classes of an entry, which along with - the system and user schema determine the permitted attributes of an - entry. Values of this attribute may be modified by clients, but the - objectClass attribute cannot be removed. Servers may restrict the - modifications of this attribute to prevent the basic structural class - of the entry from being changed (e.g. one cannot change a person into - a country). When creating an entry or adding an objectClass value to - an entry, all superclasses of the named classes are implicitly added - as well if not already present, and the client must supply values for - any mandatory attributes of new superclasses. - - Some attributes, termed operational attributes, are used by servers - for administering the directory system itself. They are not returned - in search results unless explicitly requested by name. Attributes - which are not operational, such as "mail", will have their schema and - syntax constraints enforced by servers, but servers will generally - not make use of their values. - - Servers MUST NOT permit clients to add attributes to an entry unless - those attributes are permitted by the object class definitions, the - schema controlling that entry (specified in the subschema - see - below), or are operational attributes known to that server and used - for administrative purposes. Note that there is a particular - objectClass 'extensibleObject' defined in [5] which permits all user - attributes to be present in an entry. - - Entries MAY contain, among others, the following operational - attributes, defined in [5]. These attributes are maintained - automatically by the server and are not modifiable by clients: - - - - -Wahl, et. al. Standards Track [Page 6] - -RFC 2251 LDAPv3 December 1997 - - - - creatorsName: the Distinguished Name of the user who added this - entry to the directory. - - - createTimestamp: the time this entry was added to the directory. - - - modifiersName: the Distinguished Name of the user who last modified - this entry. - - - modifyTimestamp: the time this entry was last modified. - - - subschemaSubentry: the Distinguished Name of the subschema entry - (or subentry) which controls the schema for this entry. - -3.2.2. Subschema Entries and Subentries - - Subschema entries are used for administering information about the - directory schema, in particular the object classes and attribute - types supported by directory servers. A single subschema entry - contains all schema definitions used by entries in a particular part - of the directory tree. - - Servers which follow X.500(93) models SHOULD implement subschema - using the X.500 subschema mechanisms, and so these subschemas are not - ordinary entries. LDAP clients SHOULD NOT assume that servers - implement any of the other aspects of X.500 subschema. A server - which masters entries and permits clients to modify these entries - MUST implement and provide access to these subschema entries, so that - its clients may discover the attributes and object classes which are - permitted to be present. It is strongly recommended that all other - servers implement this as well. - - The following four attributes MUST be present in all subschema - entries: - - - cn: this attribute MUST be used to form the RDN of the subschema - entry. - - - objectClass: the attribute MUST have at least the values "top" and - "subschema". - - - objectClasses: each value of this attribute specifies an object - class known to the server. - - - attributeTypes: each value of this attribute specifies an attribute - type known to the server. - - These are defined in [5]. Other attributes MAY be present in - subschema entries, to reflect additional supported capabilities. - - - -Wahl, et. al. Standards Track [Page 7] - -RFC 2251 LDAPv3 December 1997 - - - These include matchingRules, matchingRuleUse, dITStructureRules, - dITContentRules, nameForms and ldapSyntaxes. - - Servers SHOULD provide the attributes createTimestamp and - modifyTimestamp in subschema entries, in order to allow clients to - maintain their caches of schema information. - - Clients MUST only retrieve attributes from a subschema entry by - requesting a base object search of the entry, where the search filter - is "(objectClass=subschema)". (This will allow LDAPv3 servers which - gateway to X.500(93) to detect that subentry information is being - requested.) - -3.3. Relationship to X.500 - - This document defines LDAP in terms of X.500 as an X.500 access - mechanism. An LDAP server MUST act in accordance with the - X.500(1993) series of ITU recommendations when providing the service. - However, it is not required that an LDAP server make use of any X.500 - protocols in providing this service, e.g. LDAP can be mapped onto any - other directory system so long as the X.500 data and service model as - used in LDAP is not violated in the LDAP interface. - -3.4. Server-specific Data Requirements - - An LDAP server MUST provide information about itself and other - information that is specific to each server. This is represented as - a group of attributes located in the root DSE (DSA-Specific Entry), - which is named with the zero-length LDAPDN. These attributes are - retrievable if a client performs a base object search of the root - with filter "(objectClass=*)", however they are subject to access - control restrictions. The root DSE MUST NOT be included if the - client performs a subtree search starting from the root. - - Servers may allow clients to modify these attributes. - - The following attributes of the root DSE are defined in section 5 of - [5]. Additional attributes may be defined in other documents. - - - namingContexts: naming contexts held in the server. Naming contexts - are defined in section 17 of X.501 [6]. - - - subschemaSubentry: subschema entries (or subentries) known by this - server. - - - altServer: alternative servers in case this one is later - unavailable. - - - - -Wahl, et. al. Standards Track [Page 8] - -RFC 2251 LDAPv3 December 1997 - - - - supportedExtension: list of supported extended operations. - - - supportedControl: list of supported controls. - - - supportedSASLMechanisms: list of supported SASL security features. - - - supportedLDAPVersion: LDAP versions implemented by the server. - - If the server does not master entries and does not know the locations - of schema information, the subschemaSubentry attribute is not present - in the root DSE. If the server masters directory entries under one - or more schema rules, there may be any number of values of the - subschemaSubentry attribute in the root DSE. - -4. Elements of Protocol - - The LDAP protocol is described using Abstract Syntax Notation 1 - (ASN.1) [3], and is typically transferred using a subset of ASN.1 - Basic Encoding Rules [11]. In order to support future extensions to - this protocol, clients and servers MUST ignore elements of SEQUENCE - encodings whose tags they do not recognize. - - Note that unlike X.500, each change to the LDAP protocol other than - through the extension mechanisms will have a different version - number. A client will indicate the version it supports as part of - the bind request, described in section 4.2. If a client has not sent - a bind, the server MUST assume that version 3 is supported in the - client (since version 2 required that the client bind first). - - Clients may determine the protocol version a server supports by - reading the supportedLDAPVersion attribute from the root DSE. Servers - which implement version 3 or later versions MUST provide this - attribute. Servers which only implement version 2 may not provide - this attribute. - -4.1. Common Elements - - This section describes the LDAPMessage envelope PDU (Protocol Data - Unit) format, as well as data type definitions which are used in the - protocol operations. - -4.1.1. Message Envelope - - For the purposes of protocol exchanges, all protocol operations are - encapsulated in a common envelope, the LDAPMessage, which is defined - as follows: - - LDAPMessage ::= SEQUENCE { - - - -Wahl, et. al. Standards Track [Page 9] - -RFC 2251 LDAPv3 December 1997 - - - 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 }, - controls [0] Controls OPTIONAL } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - The function of the LDAPMessage is to provide an envelope containing - common fields required in all protocol exchanges. At this time the - only common fields are the message ID and the controls. - - If the server receives a PDU from the client in which the LDAPMessage - SEQUENCE tag cannot be recognized, the messageID cannot be parsed, - the tag of the protocolOp is not recognized as a request, or the - encoding structures or lengths of data fields are found to be - incorrect, then the server MUST return the notice of disconnection - described in section 4.4.1, with resultCode protocolError, and - immediately close the connection. In other cases that the server - cannot parse the request received by the client, the server MUST - return an appropriate response to the request, with the resultCode - set to protocolError. - - If the client receives a PDU from the server which cannot be parsed, - the client may discard the PDU, or may abruptly close the connection. - - The ASN.1 type Controls is defined in section 4.1.12. - - - - -Wahl, et. al. Standards Track [Page 10] - -RFC 2251 LDAPv3 December 1997 - - -4.1.1.1. Message ID - - All LDAPMessage envelopes encapsulating responses contain the - messageID value of the corresponding request LDAPMessage. - - The message ID of a request MUST have a value different from the - values of any other requests outstanding in the LDAP session of which - this message is a part. - - A client MUST NOT send a second request with the same message ID as - an earlier request on the same connection if the client has not - received the final response from the earlier request. Otherwise the - behavior is undefined. Typical clients increment a counter for each - request. - - A client MUST NOT reuse the message id of an abandonRequest or of the - abandoned operation until it has received a response from the server - for another request invoked subsequent to the abandonRequest, as the - abandonRequest itself does not have a response. - -4.1.2. String Types - - The LDAPString is a notational convenience to indicate that, although - strings of LDAPString type encode as OCTET STRING types, the ISO - 10646 [13] character set (a superset of Unicode) is used, encoded - following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm - characters which are the same as ASCII (0x0000 through 0x007F) are - represented as that same ASCII character in a single byte. The other - byte values are used to form a variable-length encoding of an - arbitrary character. - - LDAPString ::= OCTET STRING - - The LDAPOID is a notational convenience to indicate that the - permitted value of this string is a (UTF-8 encoded) dotted-decimal - representation of an OBJECT IDENTIFIER. - - LDAPOID ::= OCTET STRING - - For example, - - 1.3.6.1.4.1.1466.1.2.3 - -4.1.3. Distinguished Name and Relative Distinguished Name - - 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 [4], such that - - - -Wahl, et. al. Standards Track [Page 11] - -RFC 2251 LDAPv3 December 1997 - - - ::= - - ::= - - where and are as defined in [4]. - - LDAPDN ::= LDAPString - - RelativeLDAPDN ::= LDAPString - - Only Attribute Types can be present in a relative distinguished name - component; the options of Attribute Descriptions (next section) MUST - NOT be used in specifying distinguished names. - -4.1.4. Attribute Type - - An AttributeType takes on as its value the textual string associated - with that AttributeType in its specification. - - AttributeType ::= LDAPString - - Each attribute type has a unique OBJECT IDENTIFIER which has been - assigned to it. This identifier may be written as decimal digits - with components separated by periods, e.g. "2.5.4.10". - - A specification may also assign one or more textual names for an - attribute type. These names MUST begin with a letter, and only - contain ASCII letters, digit characters and hyphens. They are case - insensitive. (These ASCII characters are identical to ISO 10646 - characters whose UTF-8 encoding is a single byte between 0x00 and - 0x7F.) - - If the server has a textual name for an attribute type, it MUST use a - textual name for attributes returned in search results. The dotted- - decimal OBJECT IDENTIFIER is only used if there is no textual name - for an attribute type. - - Attribute type textual names are non-unique, as two different - specifications (neither in standards track RFCs) may choose the same - name. - - A server which masters or shadows entries SHOULD list all the - attribute types it supports in the subschema entries, using the - attributeTypes attribute. Servers which support an open-ended set of - attributes SHOULD include at least the attributeTypes value for the - 'objectClass' attribute. Clients MAY retrieve the attributeTypes - value from subschema entries in order to obtain the OBJECT IDENTIFIER - and other information associated with attribute types. - - - -Wahl, et. al. Standards Track [Page 12] - -RFC 2251 LDAPv3 December 1997 - - - Some attribute type names which are used in this version of LDAP are - described in [5]. Servers may implement additional attribute types. - -4.1.5. Attribute Description - - An AttributeDescription is a superset of the definition of the - AttributeType. It has the same ASN.1 definition, but allows - additional options to be specified. They are also case insensitive. - - AttributeDescription ::= LDAPString - - A value of AttributeDescription is based on the following BNF: - - ::= [ ";" ] - - ::=