rfc2251.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,487 行 · 第 1/5 页

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. "[e-mail]" will match "[e-mail]").

   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