+++ /dev/null
-
-INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
-Obsoletes: 2251, 2829, 2830 February 2006
-Intended Category: Standards Track
-
-
-
-
-
-
-
- LDAP: Authentication Methods
- and
- Security Mechanisms
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of
- this document will take place on the IETF LDAP Revision Working
- Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
- editorial comments directly to the author
- <roger_harrison@novell.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- This document describes authentication methods and security
- mechanisms of the Lightweight Directory Access Protocol (LDAP).
-
-
-
-Harrison Expires August 2006 [Page 1]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- This document details establishment of Transport Layer Security
- (TLS) using the StartTLS operation.
-
- This document details the simple Bind authentication method
- including anonymous, unauthenticated, and name/password mechanisms
- and the Simple Authentication and Security Layer (SASL) Bind
- authentication method including the EXTERNAL mechanism.
-
- This document discusses various authentication and authorization
- states through which a session to an LDAP server may pass and the
- actions that trigger these state changes.
-
- This document, together with other documents in the LDAP Technical
- Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
- 2829 and RFC 2830.
-
-Table of Contents
-
- 1. Introduction.....................................................3
- 1.1. Relationship to Other Documents................................5
- 1.2. Conventions....................................................6
- 2. Implementation Requirements......................................7
- 3. StartTLS Operation...............................................7
- 3.1. TLS Establishment Procedures...................................7
- 3.1.1. StartTLS Request Sequencing..................................8
- 3.1.2. Client Certificate...........................................8
- 3.1.3. Server Identity Check........................................8
- 3.1.3.1. Comparison of DNS Names...................................10
- 3.1.3.2. Comparison of IP Addresses................................10
- 3.1.3.3. Comparison of other subjectName types.....................10
- 3.1.4. Discovery of Resultant Security Level.......................10
- 3.1.5. Refresh of Server Capabilities Information..................11
- 3.2. Effect of TLS on Authorization State..........................11
- 3.3. TLS Ciphersuites..............................................11
- 4. Authorization State.............................................12
- 5. Bind Operation..................................................13
- 5.1. Simple Authentication Method..................................13
- 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
- 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
- 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14
- 5.2. SASL Authentication Method....................................15
- 5.2.1. SASL Protocol Profile.......................................15
- 5.2.1.1. SASL Service Name for LDAP................................15
- 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15
- 5.2.1.3. Optional Fields...........................................16
- 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17
- 5.2.1.5. Determination of Supported SASL Mechanisms................17
- 5.2.1.6. Rules for Using SASL Layers...............................17
- 5.2.1.7. Support for Multiple Authentications......................18
- 5.2.1.8. SASL Authorization Identities.............................18
- 5.2.2. SASL Semantics Within LDAP..................................19
-
-Harrison Expires August 2006 [Page 2]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
- 5.2.3.1. Implicit Assertion........................................19
- 5.2.3.2. Explicit Assertion........................................20
- 6. Security Considerations.........................................20
- 6.1. General LDAP Security Considerations..........................20
- 6.2. StartTLS Security Considerations..............................21
- 6.3. Bind Operation Security Considerations........................21
- 6.3.1. Unauthenticated Mechanism Security Considerations...........21
- 6.3.2. Name/Password Mechanism Security Considerations.............22
- 6.3.3. Password-related Security Considerations....................22
- 6.3.4. Hashed Password Security Considerations.....................23
- 6.4.SASL Security Considerations...................................23
- 6.5. Related Security Considerations...............................23
- 7. IANA Considerations.............................................24
- 8. Acknowledgments.................................................24
- 9. Normative References............................................24
- 10. Informative References.........................................25
- Author's Address...................................................26
- Appendix A. Authentication and Authorization Concepts..............26
- A.1. Access Control Policy.........................................26
- A.2. Access Control Factors........................................26
- A.3. Authentication, Credentials, Identity.........................27
- A.4. Authorization Identity........................................27
- Appendix B. Summary of Changes.....................................27
- B.1. Changes Made to RFC 2251......................................28
- B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
- B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
- B.2. Changes Made to RFC 2829......................................28
- B.2.1. Section 4 (Required security mechanisms)....................29
- B.2.2. Section 5.1 (Anonymous authentication procedure)............29
- B.2.3. Section 6 (Password-based authentication)...................29
- B.2.4. Section 6.1 (Digest authentication).........................29
- B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
- B.2.6. Section 6.3 (Other authentication choices with TLS).........29
- B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
- B.2.8. Section 8 (Other mechanisms)................................30
- B.2.9. Section 9 (Authorization identity)..........................30
- B.2.10. Section 10 (TLS Ciphersuites)..............................30
- B.3. Changes Made to RFC 2830: ....................................30
- B.3.1. Section 3.6 (Server Identity Check).........................30
- B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
- B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
- B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
- Appendix C. Changes for draft-ldapbis-authmeth-19..................31
- Intellectual Property Rights.......................................32
- Full Copyright Statement...........................................33
-
-
-1. Introduction
-
-
-Harrison Expires August 2006 [Page 3]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
- powerful protocol for accessing directories. It offers means of
- searching, retrieving and manipulating directory content and ways to
- access a rich set of security functions.
-
- It is vital that these security functions be interoperable among all
- LDAP clients and servers on the Internet; therefore there has to be
- a minimum subset of security functions that is common to all
- implementations that claim LDAP conformance.
-
- Basic threats to an LDAP directory service include (but are not
- limited to):
-
- (1) Unauthorized access to directory data via data-retrieval
- operations.
-
- (2) Unauthorized access to directory data by monitoring access of
- others.
-
- (3) Unauthorized access to reusable client authentication
- information by monitoring access of others.
-
- (4) Unauthorized modification of directory data.
-
- (5) Unauthorized modification of configuration information.
-
- (6) Denial of Service: Use of resources (commonly in excess) in a
- manner intended to deny service to others.
-
- (7) Spoofing: Tricking a user or client into believing that
- information came from the directory when in fact it did not,
- either by modifying data in transit or misdirecting the client's
- transport connection. Tricking a user or client into sending
- privileged information to a hostile entity that appears to be
- the directory server but is not. Tricking a directory server
- into believing that information came from a particular client
- when in fact it came from a hostile entity.
-
- (8) Hijacking: An attacker seizes control of an established protocol
- session.
-
- Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
- (2) and (3) are passive attacks.
-
- Threats (1), (4), (5) and (6) are due to hostile clients. Threats
- (2), (3), (7) and (8) are due to hostile agents on the path between
- client and server or hostile agents posing as a server, e.g., IP
- spoofing.
-
- LDAP offers the following security mechanisms:
-
-
-
-
-
-Harrison Expires August 2006 [Page 4]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- (1) Authentication by means of the Bind operation. The Bind
- operation provides a simple method which supports anonymous,
- unauthenticated, and name/password mechanisms, and the Simple
- Authentication and Security Layer (SASL) method which supports a
- wide variety of authentication mechanisms.
-
- (2) Mechanisms to support vendor-specific access control facilities
- (LDAP does not offer a standard access control facility).
-
- (3) Data integrity service by means of security layers in Transport
- Layer Security (TLS) or SASL mechanisms.
-
- (4) Data confidentiality service by means of security layers in TLS
- or SASL mechanisms.
-
- (5) Server resource usage limitation by means of administrative
- limits configured on the server.
-
- (6) Server authentication by means of the TLS protocol or SASL
- mechanisms.
-
- LDAP may also be protected by means outside the LDAP protocol, e.g.,
- with IP-level security [RFC4301].
-
- Experience has shown that simply allowing implementations to pick
- and choose the security mechanisms that will be implemented is not a
- strategy that leads to interoperability. In the absence of
- mandates, clients will continue to be written that do not support
- any security function supported by the server, or worse, they will
- only support mechanisms that provide inadequate security for most
- circumstances.
-
- It is desirable to allow clients to authenticate using a variety of
- mechanisms including mechanisms where identities are represented as
- distinguished names [X.501][Models] in string form [LDAPDN] or as
- used in different systems (e.g., simple user names [RFC4013]).
- Because some authentication mechanisms transmit credentials in plain
- text form, and/or do not provide data security services and/or are
- subject to passive attacks, it is necessary to ensure secure
- interoperability by identifying a mandatory-to-implement mechanism
- for establishing transport-layer security services.
-
- The set of security mechanisms provided in LDAP and described in
- this document is intended to meet the security needs for a wide
- range of deployment scenarios and still provide a high degree of
- interoperability among various LDAP implementations and deployments.
-
-1.1. Relationship to Other Documents
-
- This document is an integral part of the LDAP Technical
- Specification [Roadmap].
-
-
-
-
-Harrison Expires August 2006 [Page 5]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- This document, together with [Roadmap], [Protocol], and [Models],
- obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
- 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
- summarizes the substantive changes made to RFC 2251 by this document.
-
- This document obsoletes RFC 2829 in its entirety. Appendix B.2
- summarizes the substantive changes made to RFC 2829 by this document.
-
- Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
- remainder of RFC 2830 is obsoleted by this document. Appendix B.3
- summarizes the substantive changes made to RFC 2830 by this document.
-
-
-1.2. Conventions
-
- The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
- "MAY", and "OPTIONAL" in this document are to be interpreted as
- described in RFC 2119 [RFC2119].
-
- The term "user" represents any human or application entity which is
- accessing the directory using a directory client. A directory
- client (or client) is also known as a directory user agent (DUA).
-
- The term "transport connection" refers to the underlying transport
- services used to carry the protocol exchange, as well as
- associations established by these services.
-
- The term "TLS layer" refers to TLS services used in providing
- security services, as well as associations established by these
- services.
-
- The term "SASL layer" refers to SASL services used in providing
- security services, as well as associations established by these
- services.
-
- The term "LDAP message layer" refers to the LDAP Message (PDU)
- services used in providing directory services, as well as
- associations established by these services.
-
- The term "LDAP session" refers to combined services (transport
- connection, TLS layer, SASL layer, LDAP message layer) and their
- associations.
-
- In general, security terms in this document are used consistently
- with the definitions provided in [RFC2828]. In addition, several
- terms and concepts relating to security, authentication, and
- authorization are presented in Appendix A of this document. While
- the formal definition of these terms and concepts is outside the
- scope of this document, an understanding of them is prerequisite to
- understanding much of the material in this document. Readers who
- are unfamiliar with security-related concepts are encouraged to
- review Appendix A before reading the remainder of this document.
-
-
-
-Harrison Expires August 2006 [Page 6]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-2. Implementation Requirements
-
- LDAP server implementations MUST support the anonymous
- authentication mechanism of the simple Bind method (section 5.1.1).
-
- LDAP implementations that support any authentication mechanism other
- than the anonymous authentication mechanism of the simple Bind
- method MUST support the name/password authentication mechanism of
- the simple Bind method (section 5.1.3) and MUST be capable of
- protecting this name/password authentication using TLS as
- established by the StartTLS operation (section 3).
-
- Implementations SHOULD disallow the use of the name/password
- authentication mechanism by default when suitable data security
- services are not in place, and MAY provide other suitable data
- security services for use with this authentication mechanism.
-
- Implementations MAY support additional authentication mechanisms.
- Some of these mechanisms are discussed below.
-
- LDAP server implementations SHOULD support client assertion of
- authorization identity via the SASL EXTERNAL mechanism (section
- 5.2.3).
-
- LDAP server implementations that support no authentication mechanism
- other than the anonymous mechanism of the simple bind method SHOULD
- support use of TLS as established by the the StartTLS operation
- (section 3). (Other servers MUST support TLS per the second
- paragraph of this section.)
-
- Implementations supporting TLS MUST support the
- TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
- latter ciphersuite is recommended to encourage interoperability with
- implementations conforming to earlier LDAP StartTLS specifications.
-
-
-3. StartTLS Operation
-
- The Start Transport Layer Security (StartTLS) operation defined in
- section 4.14 of [Protocol] provides the ability to establish TLS
- [TLS] in an LDAP session.
-
- The goals of using the TLS [TLS] protocol with LDAP are to ensure
- data confidentiality and integrity, and to optionally provide for
- authentication. TLS expressly provides these capabilities, although
- the authentication services of TLS are available to LDAP only in
- combination with the SASL EXTERNAL authentication method (see
- section 5.2.3), and then only if the SASL EXTERNAL implementation
- chooses to make use of the TLS credentials.
-
-
-3.1. TLS Establishment Procedures
-
-
-Harrison Expires August 2006 [Page 7]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- This section describes the overall procedures clients and servers
- must follow for TLS establishment. These procedures take into
- consideration various aspects of the TLS layer including discovery
- of resultant security level and assertion of the client's
- authorization identity.
-
-
-3.1.1. StartTLS Request Sequencing
-
- A client may send the StartTLS extended request at any time after
- establishing an LDAP session, except:
-
- - when TLS is currently established on the session,
- - when a multi-stage SASL negotiation is in progress on the
- session, or
- - when there are outstanding responses for operation requests
- previously issued on the session.
-
- As described in [Protocol] Section 4.14.1, a (detected) violation of
- any of these requirements results in a return of the operationsError
- resultCode.
-
- Client implementers should ensure that they strictly follow these
- operation sequencing requirements to prevent interoperability
- issues. Operational experience has shown that violating these
- requirements causes interoperability issues because there are race
- conditions that prevent servers from detecting some violations of
- these requirements due to factors such as server hardware speed and
- network latencies.
-
- There is no general requirement that the client have or have not
- already performed a Bind operation (section 5) before sending a
- StartTLS operation request, however where a client intends to
- perform both a Bind operation and a StartTLS operation, it SHOULD
- first perform the StartTLS operation so that the Bind request and
- response messages are protected by the data security services
- established by the StartTLS operation.
-
-
-3.1.2. Client Certificate
-
- If an LDAP server requests or demands that a client provide a user
- certificate during TLS negotiation and the client does not present a
- suitable user certificate (e.g., one that can be validated), the
- server may use a local security policy to determine whether to
- successfully complete TLS negotiation.
-
- If a client that has provided a suitable certificate subsequently
- performs a Bind operation using the SASL EXTERNAL authentication
- mechanism (section 5.2.3), information in the certificate may be
- used by the server to identify and authenticate the client.
-
-
-3.1.3. Server Identity Check
-
-Harrison Expires August 2006 [Page 8]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- In order to prevent man-in-the-middle attacks the client MUST verify
- the server's identity (as presented in the server's Certificate
- message). In this section, the client's understanding of the
- server's identity (typically the identity used to establish the
- transport connection) is called the "reference identity".
-
- The client determines the type (e.g., DNS name or IP address) of the
- reference identity and performs a comparison between the reference
- identity and each subjectAltName value of the corresponding type
- until a match is produced. Once a match is produced, the server's
- identity has been verified and the server identity check is
- complete. Different subjectAltName types are matched in different
- ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
- various subjectAltName types.
-
- The client may map the reference identity to a different type prior
- to performing a comparison. Mappings may be performed for all
- available subjectAltName types to which the reference identity can
- be mapped, however the reference identity should only be mapped to
- types for which the mapping is either inherently secure (e.g.,
- extracting the DNS name from a URI to compare with a subjectAltName
- of type dNSName) or for which the mapping is performed in a secure
- manner (e.g., using DNSSec, or using user- (or admin-) configured
- host-to-address/address-to-host lookup tables).
-
- The server's identity may also be verified by comparing the
- reference identity to the Common Name (CN) [Schema] value in the
- leaf RDN of the subjectName field of the server's certificate. This
- comparison is performed using the rules for comparison of DNS names
- in section 3.1.3.1 below, with the exception that no wildcard
- matching is allowed. Although the use of the Common Name value is
- existing practice, it is deprecated and Certification Authorities
- are encouraged to provide subjectAltName values instead. Note that
- the TLS implementation may represent DNs in certificates according
- to X.500 or other conventions. For example, some X.500
- implementations order the RDNs in a DN using a left-to-right (most
- significant to least significant) convention instead of LDAP's
- right-to-left convention.
-
- If the server identity check fails, user-oriented clients SHOULD
- either notify the user (clients may give the user the opportunity to
- continue with the LDAP session in this case) or close the transport
- connection and indicate that the server's identity is suspect.
- Automated clients SHOULD close the transport connection and then
- return or log an error indicating that the server's identity is
- suspect or both.
-
- Beyond the server identity check described in this section, clients
- should be prepared to do further checking to ensure that the server
- is authorized to provide the service it is requested to provide.
- The client may need to make use of local policy information in
- making this determination.
-
-
-Harrison Expires August 2006 [Page 9]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
-3.1.3.1. Comparison of DNS Names
-
- If the reference identity is an internationalized domain name,
- conforming implementations MUST convert it to the ASCII Compatible
- Encoding (ACE) format as specified in section 4 of RFC 3490
- [RFC3490] before comparison with subjectAltName values of type
- dNSName. Specifically, conforming implementations MUST perform the
- conversion operation specified in section 4 of RFC 3490 as follows:
-
- * in step 1, the domain name SHALL be considered a "stored
- string";
- * in step 3, set the flag called "UseSTD3ASCIIRules";
- * in step 4, process each label with the "ToASCII"
- operation; and
- * in step 5, change all label separators to U+002E (full
- stop).
-
- After performing the "to-ASCII" conversion, the DNS labels and names
- MUST be compared for equality according to the rules specified in
- section 3 of RFC3490.
-
- The '*' (ASCII 42) wildcard character is allowed in subjectAltName
- values of type dNSName and then only as the left-most (least
- significant) DNS label in that value. This wildcard matches any
- left-most DNS label in the server name. That is, the subject
- *.example.com matches the server names a.example.com and
- b.example.com but does not match example.com or a.b.example.com.
-
-
-3.1.3.2. Comparison of IP Addresses
-
- When the reference identity is an IP address, the identity MUST be
- converted to the "network byte order" octet string representation
- [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
- octet string will contain exactly four octets. For IP Version 6, as
- specified in RFC 2460, the octet string will contain exactly sixteen
- octets. This octet string is then compared against subjectAltName
- values of type iPAddress. A match occurs if the reference identity
- octet string and value octet strings are identical.
-
-
-3.1.3.3. Comparison of other subjectName types
-
- Client implementations MAY support matching against subjectAltName
- values of other types as described in other documents.
-
-
-3.1.4. Discovery of Resultant Security Level
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 10]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- After a TLS layer is established in an LDAP session, both parties
- are to each independently decide whether or not to continue based on
- local policy and the security level achieved. If either party
- decides that the security level is inadequate for it to continue, it
- SHOULD remove the TLS layer immediately after the TLS
- (re)negotiation has completed (see [Protocol] section 4.14.3 and
- section 3.2 below). Implementations may reevaluate the security
- level at any time and, upon finding it inadequate, should remove the
- TLS layer.
-
-
-3.1.5. Refresh of Server Capabilities Information
-
- After a TLS layer is established in an LDAP session, the client
- SHOULD discard or refresh all information about the server it
- obtained prior to the initiation of the TLS negotiation and not
- obtained through secure mechanisms. This protects against man-in-
- the-middle attacks that may have altered any server capabilities
- information retrieved prior to TLS layer installation.
-
- The server may advertise different capabilities after installing a
- TLS layer. In particular, the value of 'supportedSASLMechanisms'
- may be different after a TLS layer has been installed (specifically,
- the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed
- only after a TLS layer has been installed).
-
-
-3.2. Effect of TLS on Authorization State
-
- The establishment, change, and/or closure of TLS may cause the
- authorization state to move to a new state. This is discussed
- further in Section 4.
-
-
-3.3. TLS Ciphersuites
-
- Several issues should be considered when selecting TLS ciphersuites
- that are appropriate for use in a given circumstance. These issues
- include the following:
-
- - The ciphersuite's ability to provide adequate confidentiality
- protection for passwords and other data sent over the transport
- connection. Client and server implementers should recognize
- that some TLS ciphersuites provide no confidentiality protection
- while other ciphersuites that do provide confidentiality
- protection may be vulnerable to being cracked using brute force
- methods, especially in light of ever-increasing CPU speeds that
- reduce the time needed to successfully mount such attacks.
-
- - Client and server implementers should carefully consider the
- value of the password or data being protected versus the level
- of confidentiality protection provided by the ciphersuite to
- ensure that the level of protection afforded by the ciphersuite
- is appropriate.
-
-Harrison Expires August 2006 [Page 11]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
- middle attacks. Ciphersuites vulnerable to man-in-the-middle
- attacks SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger
- of a man-in-the-middle attack is negligible.
-
- - After a TLS negotiation (either initial or subsequent) is
- completed, both protocol peers should independently verify that
- the security services provided by the negotiated ciphersuite are
- adequate for the intended use of the LDAP session. If not, the
- TLS layer should be closed.
-
-
-4. Authorization State
-
- Every LDAP session has an associated authorization state. This
- state is comprised of numerous factors such as what (if any)
- authorization state has been established, how it was established,
- and what security services are in place. Some factors may be
- determined and/or affected by protocol events (e.g., Bind, StartTLS,
- or TLS closure), and some factors may be determined by external
- events (e.g., time of day or server load).
-
- While it is often convenient to view authorization state in
- simplistic terms (as we often do in this technical specification)
- such as "an anonymous state", it is noted that authorization systems
- in LDAP implementations commonly involve many factors which
- interrelate in complex manners.
-
- Authorization in LDAP is a local matter. One of the key factors in
- making authorization decisions is authorization identity. The Bind
- operation defined in section 4.2 of [Protocol] and discussed further
- in section 5 below allows information to be exchanged between the
- client and server to establish an authorization identity for the
- LDAP session. The Bind operation may also be used to move the LDAP
- session to an anonymous authorization state (see section 5.1.1).
-
- Upon initial establishment of the LDAP session, the session has an
- anonymous authorization identity. Among other things this implies
- that the client need not send a BindRequest in the first PDU of the
- LDAP message layer. The client may send any operation request prior
- to performing a Bind operation, and the server MUST treat it as if
- it had been performed after an anonymous Bind operation (section
- 5.1.1).
-
- Upon receipt of a Bind request, the server immediately moves the
- session to an anonymous authorization state. If the Bind request is
- successful, the session is moved to the requested authentication
- state with its associated authorization state. Otherwise, the
- session remains in an anonymous state.
-
-
-
-
-Harrison Expires August 2006 [Page 12]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- It is noted that other events both internal and external to LDAP may
- result in the authentication and authorization states being moved to
- an anonymous one. For instance, the establishment, change or
- closure of data security services may result in a move to an
- anonymous state, or the user's credential information (e.g.,
- certificate) may have expired. The former is an example of an event
- internal to LDAP whereas the latter is an example of an event
- external to LDAP.
-
-
-5. Bind Operation
-
- The Bind operation ([Protocol] section 4.2) allows authentication
- information to be exchanged between the client and server to
- establish a new authorization state.
-
- The Bind request typically specifies the desired authentication
- identity. Some Bind mechanisms also allow the client to specify the
- authorization identity. If the authorization identity is not
- specified, the server derives it from the authentication identity in
- an implementation-specific manner.
-
- If the authorization identity is specified, the server MUST verify
- that the client's authentication identity is permitted to assume
- (e.g., proxy for) the asserted authorization identity. The server
- MUST reject the Bind operation with an invalidCredentials resultCode
- in the Bind response if the client is not so authorized.
-
-
-5.1. Simple Authentication Method
-
- The simple authentication method of the Bind Operation provides
- three authentication mechanisms:
-
- - An anonymous authentication mechanism (section 5.1.1).
-
- - An unauthenticated authentication mechanism (section 5.1.2).
-
- - A name/password authentication mechanism using credentials
- consisting of a name (in the form of an LDAP distinguished name
- [LDAPDN]) and a password (section 5.1.3).
-
-
-5.1.1. Anonymous Authentication Mechanism of Simple Bind
-
- An LDAP client may use the anonymous authentication mechanism of the
- simple Bind method to explicitly establish an anonymous
- authorization state by sending a Bind request with a name value of
- zero length and specifying the simple authentication choice
- containing a password value of zero length.
-
-
-5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
-
-
-Harrison Expires August 2006 [Page 13]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- An LDAP client may use the unauthenticated authentication mechanism
- of the simple Bind method to establish an anonymous authorization
- state by sending a Bind request with a name value (a distinguished
- name in LDAP string form [LDAPDN] of non-zero length) and specifying
- the simple authentication choice containing a password value of zero
- length.
-
- The distinguished name value provided by the client is intended to
- be used for trace (e.g., logging) purposes only. The value is not
- to be authenticated or otherwise validated (including verification
- that the DN refers to an existing directory object). The value is
- not to be used (directly or indirectly) for authorization purposes.
-
- Unauthenticated Bind operations can have significant security issues
- (see section 6.3.1). In particular, users intending to perform
- Name/Password Authentication may inadvertently provide an empty
- password and thus cause poorly implemented clients to request
- Unauthenticated access. Clients SHOULD be implemented to require
- user selection of the Unauthenticated Authentication Mechanism by
- means other than user input of an empty password. Clients SHOULD
- disallow an empty password input to a Name/Password Authentication
- user interface. Additionally, Servers SHOULD by default fail
- Unauthenticated Bind requests with a resultCode of
- unwillingToPerform.
-
-
-5.1.3. Name/Password Authentication Mechanism of Simple Bind
-
- An LDAP client may use the name/password authentication mechanism of
- the simple Bind method to establish an authenticated authorization
- state by sending a Bind request with a name value (a distinguished
- name in LDAP string form [LDAPDN] of non-zero length) and specifying
- the simple authentication choice containing an OCTET STRING password
- value of non-zero length.
-
- Servers that map the DN sent in the Bind request to a directory
- entry with an associated set of one or more passwords used with this
- mechanism will compare the presented password to that set of
- passwords. The presented password is considered valid if it matches
- any member of this set.
-
- A resultCode of invalidDNSyntax indicates that the DN sent in the
- name value is syntactically invalid. A resultCode of
- invalidCredentials indicates that the DN is syntactically correct
- but not valid for purposes of authentication, or the password is not
- valid for the DN or the server otherwise considers the credentials
- to be invalid. A resultCode of success indicates that the
- credentials are valid and the server is willing to provide service
- to the entity these credentials identify.
-
- Server behavior is undefined for Bind requests specifying the
- name/password authentication mechanism with a zero-length name value
- and a password value of non-zero length.
-
-
-Harrison Expires August 2006 [Page 14]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- The name/password authentication mechanism of the simple Bind method
- is not suitable for authentication in environments without
- confidentiality protection.
-
-
-5.2. SASL Authentication Method
-
- The sasl authentication method of the Bind Operation provides
- facilities for using any SASL mechanism including authentication
- mechanisms and other services (e.g., data security services).
-
-
-5.2.1. SASL Protocol Profile
-
- LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
- includes native anonymous and name/password (plain text)
- authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
- SASL mechanisms are typically not used with LDAP.
-
- Each protocol that utilizes SASL services is required to supply
- certain information profiling the way they are exposed through the
- protocol ([SASL] section 4). This section explains how each of
- these profiling requirements are met by LDAP.
-
-
-5.2.1.1. SASL Service Name for LDAP
-
- The SASL service name for LDAP is "ldap", which has been registered
- with the IANA as a SASL service name.
-
-
-5.2.1.2. SASL Authentication Initiation and Protocol Exchange
-
- SASL authentication is initiated via a BindRequest message
- ([Protocol] section 4.2) with the following parameters:
-
- - The version is 3.
- - The AuthenticationChoice is sasl.
- - The mechanism element of the SaslCredentials sequence contains
- the value of the desired SASL mechanism.
- - The optional credentials field of the SaslCredentials sequence
- MAY be used to provide an initial client response for
- mechanisms that are defined to have the client send data first
- (see [SASL] sections 3 and 5 ).
-
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 15]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- In general, a SASL authentication protocol exchange consists of a
- series of server challenges and client responses, the contents of
- which are specific to and defined by the SASL mechanism. Thus for
- some SASL authentication mechanisms, it may be necessary for the
- client to respond to one or more server challenges by sending
- BindRequest messages multiple times. A challenge is indicated by
- the server sending a BindResponse message with the resultCode set to
- saslBindInProgress. This indicates that the server requires the
- client to send a new BindRequest message with the same SASL
- mechanism to continue the authentication process.
-
- To the LDAP message layer, these challenges and responses are opaque
- binary tokens of arbitrary length. LDAP servers use the
- serverSaslCreds field (an OCTET STRING) in a BindResponse message to
- transmit each challenge. LDAP clients use the credentials field
- (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
- message to transmit each response. Note that unlike some Internet
- protocols where SASL is used, LDAP is not text based and does not
- Base64-transform these challenge and response values.
-
- Clients sending a BindRequest message with the sasl choice selected
- SHOULD send a zero-length value in the name field. Servers
- receiving a BindRequest message with the sasl choice selected SHALL
- ignore any value in the name field.
-
- A client may abort a SASL Bind negotiation by sending a BindRequest
- message with a different value in the mechanism field of
- SaslCredentials or with an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as
- an empty string, the server MUST return a BindResponse with a
- resultCode of authMethodNotSupported. This will allow the client to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
- The server indicates completion of the SASL challenge-response
- exchange by responding with a BindResponse in which the resultCode
- value is not saslBindInProgress.
-
- The serverSaslCreds field in the BindResponse can be used to include
- an optional challenge with a success notification for mechanisms
- which are defined to have the server send additional data along with
- the indication of successful completion.
-
-
-5.2.1.3. Optional Fields
-
- As discussed above, LDAP provides an optional field for carrying an
- initial response in the message initiating the SASL exchange and
- provides an optional field for carrying additional data in the
- message indicating outcome of the authentication exchange. As the
- mechanism-specific content in these fields may be zero-length, SASL
- requires protocol specifications to detail how an empty field is
- distinguished from an absent field.
-
-Harrison Expires August 2006 [Page 16]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- Zero-length initial response data is distinguished from no initial
- response data in the initiating message, a BindRequest PDU, by the
- presence of the SaslCredentials.credentials OCTET STRING (of length
- zero) in that PDU. If the client does not intend to send an
- initial response with the BindRequest initiating the SASL exchange,
- it MUST omit the SaslCredentials.credentials OCTET STRING (rather
- than including an zero-length OCTET STRING).
-
- Zero-length additional data is distinguished from no additional
- response data in the outcome message, a BindResponse PDU, by the
- presence of the serverSaslCreds OCTET STRING (of length zero) in
- that PDU. If a server does not intend to send additional data in
- the BindResponse message indicating outcome of the exchange, the
- server SHALL omit the serverSaslCreds OCTET STRING (rather than
- including a zero-length OCTET STRING).
-
-
-5.2.1.4. Octet Where Negotiated Security Layers Take Effect
-
- SASL layers take effect following the transmission by the server and
- reception by the client of the final BindResponse in the SASL
- exchange with a resultCode of success.
-
- Once a SASL layer providing data integrity or confidentiality
- services takes effect, the layer remains in effect until a new layer
- is installed (i.e. at the first octet following the final
- BindResponse of the Bind operation that caused the new layer to take
- effect). Thus, an established SASL layer is not affected by a
- failed or non-SASL Bind.
-
-
-5.2.1.5. Determination of Supported SASL Mechanisms
-
- Clients may determine the SASL mechanisms a server supports by
- reading the 'supportedSASLMechanisms' attribute from the root DSE
- (DSA-Specific Entry) ([Models] section 5.1). The values of this
- attribute, if any, list the mechanisms the server supports in the
- current LDAP session state. LDAP servers SHOULD allow all clients--
- even those with an anonymous authorization--to retrieve the
- 'supportedSASLMechanisms' attribute of the root DSE both before and
- after the SASL authentication exchange. The purpose of the latter
- is to allow the client to detect possible downgrade attacks (see
- section 6.4 and [SASL] section 6.1.2).
-
- Because SASL mechanisms provide critical security functions, clients
- and servers should be configurable to specify what mechanisms are
- acceptable and allow only those mechanisms to be used. Both clients
- and servers must confirm that the negotiated security level meets
- their requirements before proceeding to use the session.
-
-
-5.2.1.6. Rules for Using SASL Layers
-
-
-Harrison Expires August 2006 [Page 17]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- Upon installing a SASL layer, the client SHOULD discard or refresh
- all information about the server it obtained prior to the initiation
- of the SASL negotiation and not obtained through secure mechanisms.
-
- If a lower level security layer (such as TLS) is installed, any SASL
- layer SHALL be layered on top of such security layers regardless of
- the order of their negotiation. In all other respects, the SASL
- layer and other security layers act independently, e.g., if both a
- TLS layer and a SASL layer are in effect then removing the TLS layer
- does not affect the continuing service of the SASL layer.
-
-
-5.2.1.7. Support for Multiple Authentications
-
- LDAP supports multiple SASL authentications as defined in [SASL]
- section 4.
-
-
-5.2.1.8. SASL Authorization Identities
-
- Some SASL mechanisms allow clients to request a desired
- authorization identity for the LDAP session ([SASL] section 3.4.
- The decision to allow or disallow the current authentication
- identity to have access to the requested authorization identity is a
- matter of local policy. The authorization identity is a string of
- UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
- following ABNF [RFC2234bis] grammar:
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id
- dnAuthzId = "dn:" distinguishedName
-
- ; unspecified authorization id, UTF-8 encoded
- uAuthzId = "u:" userid
- userid = *UTF8 ; syntax unspecified
-
- where the distinguishedName rule is defined in section 3 of [LDAPDN]
- and the UTF8 rule is defined in section 1.4 of [Models].
-
- The dnAuthzId choice is used to assert authorization identities in
- the form of a distinguished name to be matched in accordance with
- the distinguishedNameMatch matching rule [Syntaxes]. There is no
- requirement that the asserted distinguishedName value be that of an
- entry in the directory.
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 18]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- The uAuthzId choice allows clients to assert an authorization
- identity that is not in distinguished name form. The format of
- userid is defined only as a sequence of UTF-8 [RFC3629] encoded
- [Unicode] characters, and any further interpretation is a local
- matter. For example, the userid could identify a user of a specific
- directory service, be a login name or be an email address. A
- uAuthzId SHOULD NOT be assumed to be globally unique. To compare
- uAuthzID values, each uAuthzID value MUST be prepared as a "query"
- string using [RFC4013] and then the two values are compared octet-
- wise.
-
- The above grammar is extensible. The authzId production may be
- extended to support additional forms of identities. Each form is
- distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
- for registration requirements).
-
-
-5.2.2. SASL Semantics Within LDAP
-
- Implementers must take care to maintain the semantics of SASL
- specifications when handling data that has different semantics in
- the LDAP protocol.
-
- For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
- utilizes an authentication identity and a realm which are
- syntactically simple strings and semantically simple username and
- realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
- DNs, and there is no requirement that they be represented or treated
- as such.
-
-
-5.2.3. SASL EXTERNAL Authentication Mechanism
-
- A client can use the SASL EXTERNAL [SASL] mechanism to request the
- LDAP server to authenticate and establish a resulting authorization
- identity using security credentials exchanged by a lower security
- layer (such as by TLS authentication). If the client's
- authentication credentials have not been established at a lower
- security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
- of inappropriateAuthentication. Although this situation has the
- effect of leaving the LDAP session in an anonymous state (section
- 4), the state of any installed security layer is unaffected.
-
- A client may either request that its authorization identity be
- automatically derived from its authentication credentials exchanged
- at a lower security layer or it may explicitly provide a desired
- authorization identity. The former is known as an implicit
- assertion, and the latter as an explicit assertion.
-
-
-5.2.3.1. Implicit Assertion
-
-
-
-
-Harrison Expires August 2006 [Page 19]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- An implicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that does not include the optional credentials field
- (found within the SaslCredentials sequence in the BindRequest). The
- server will derive the client's authorization identity from the
- authentication identity supplied by a security layer (e.g., a public
- key certificate used during TLS layer installation) according to
- local policy. The underlying mechanics of how this is accomplished
- are implementation specific.
-
-
-5.2.3.2. Explicit Assertion
-
- An explicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that includes the credentials field (found within the
- SaslCredentials sequence in the BindRequest). The value of the
- credentials field (an OCTET STRING) is the asserted authorization
- identity and MUST be constructed as documented in section 5.2.1.8.
-
-
-6. Security Considerations
-
- Security issues are discussed throughout this document. The
- unsurprising conclusion is that security is an integral and
- necessary part of LDAP. This section discusses a number of LDAP-
- related security considerations.
-
-
-6.1. General LDAP Security Considerations
-
- LDAP itself provides no security or protection from accessing or
- updating the directory by other means than through the LDAP
- protocol, e.g., from inspection of server database files by database
- administrators.
-
- Sensitive data may be carried in almost any LDAP message and its
- disclosure may be subject to privacy laws or other legal regulation
- in many countries. Implementers should take appropriate measures to
- protect sensitive data from disclosure to unauthorized entities.
-
- A session on which the client has not established data integrity and
- privacy services (e.g., via StartTLS, IPsec or a suitable SASL
- mechanism) is subject to man-in-the-middle attacks to view and
- modify information in transit. Client and server implementers
- SHOULD take measures to protect sensitive data in the LDAP session
- from these attacks by using data protection services as discussed in
- this document. Clients and servers should provide the ability to be
- configured to require these protections. A resultCode of
- confidentialityRequired indicates that the server requires
- establishment of (stronger) data confidentiality protection in order
- to perform the requested operation.
-
-
-
-Harrison Expires August 2006 [Page 20]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- Access control should always be applied when reading sensitive
- information or updating directory information.
-
- Various security factors, including authentication and authorization
- information and data security services may change during the course
- of the LDAP session, or even during the performance of a particular
- operation. Implementations should be robust in the handling of
- changing security factors.
-
-
-6.2. StartTLS Security Considerations
-
- All security gained via use of the StartTLS operation is gained by
- the use of TLS itself. The StartTLS operation, on its own, does not
- provide any additional security.
-
- The level of security provided through the use of TLS depends
- directly on both the quality of the TLS implementation used and the
- style of usage of that implementation. Additionally, a man-in-the-
- middle attacker can remove the StartTLS extended operation from the
- 'supportedExtension' attribute of the root DSE. Both parties SHOULD
- independently ascertain and consent to the security level achieved
- once TLS is established and before beginning use of the TLS-
- protected session. For example, the security level of the TLS layer
- might have been negotiated down to plaintext.
-
- Clients MUST either warn the user when the security level achieved
- does not provide an acceptable level of data confidentiality and/or
- data integrity protection, or be configurable to refuse to proceed
- without an acceptable level of security.
-
- As stated in section 3.1.2, a server may use a local security policy
- to determine whether to successfully complete TLS negotiation.
- Information in the user's certificate that is originated or verified
- by the certification authority should be used by the policy
- administrator when configuring the identification and authorization
- policy.
-
- Server implementers SHOULD allow server administrators to elect
- whether and when data confidentiality and integrity are required, as
- well as elect whether authentication of the client during the TLS
- handshake is required.
-
- Implementers should be aware of and understand TLS security
- considerations as discussed in the TLS specification [TLS].
-
-
-6.3. Bind Operation Security Considerations
-
- This section discusses several security considerations relevant to
- LDAP authentication via the Bind operation.
-
-
-6.3.1. Unauthenticated Mechanism Security Considerations
-
-Harrison Expires August 2006 [Page 21]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- Operational experience shows that clients can (and frequently do)
- misuse the unauthenticated authentication mechanism of the simple
- Bind method (see section 5.1.2). For example, a client program
- might make a decision to grant access to non-directory information
- on the basis of successfully completing a Bind operation. LDAP
- server implementations may return a success response to an
- unauthenticated Bind request. This may erroneously leave the client
- with the impression that the server has successfully authenticated
- the identity represented by the distinguished name when in reality,
- an anonymous authorization state has been established. Clients that
- use the results from a simple Bind operation to make authorization
- decisions should actively detect unauthenticated Bind requests (by
- verifying that the supplied password is not empty) and react
- appropriately.
-
-
-6.3.2. Name/Password Mechanism Security Considerations
-
- The name/password authentication mechanism of the simple Bind method
- discloses the password to the server, which is an inherent security
- risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
- that do not disclose the password to the server.
-
-
-6.3.3. Password-related Security Considerations
-
- LDAP allows multi-valued password attributes. In systems where
- entries are expected to have one and only one password,
- administrative controls should be provided to enforce this behavior.
-
- The use of clear text passwords and other unprotected authentication
- credentials is strongly discouraged over open networks when the
- underlying transport service cannot guarantee confidentiality. LDAP
- implementations SHOULD NOT by default support authentication methods
- using clear text passwords and other unprotected authentication
- credentials unless the data on the session is protected using TLS or
- other data confidentiality and data integrity protection.
-
- The transmission of passwords in the clear--typically for
- authentication or modification--poses a significant security risk.
- This risk can be avoided by using SASL authentication [SASL]
- mechanisms that do not transmit passwords in the clear or by
- negotiating transport or session layer data confidentiality services
- before transmitting password values.
-
- To mitigate the security risks associated with the transfer of
- passwords, a server implementation that supports any password-based
- authentication mechanism that transmits passwords in the clear MUST
- support a policy mechanism that at the time of authentication or
- password modification, requires:
-
- A TLS layer has been successfully installed.
-
-
-Harrison Expires August 2006 [Page 22]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- OR
-
- Some other data confidentiality mechanism that protects the
- password value from eavesdropping has been provided.
-
- OR
-
- The server returns a resultCode of confidentialityRequired for
- the operation (i.e. name/password Bind with password value,
- SASL Bind transmitting a password value in the clear, add or
- modify including a userPassword value, etc.), even if the
- password value is correct.
-
- Server implementations may also want to provide policy mechanisms to
- invalidate or otherwise protect accounts in situations where a
- server detects that a password for an account has been transmitted
- in the clear.
-
-
-6.3.4. Hashed Password Security Considerations
-
- Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
- the password value that may be vulnerable to offline dictionary
- attacks. Implementers should take care to protect such hashed
- password values during transmission using TLS or other
- confidentiality mechanisms.
-
-
-6.4.SASL Security Considerations
-
- Until data integrity service is installed on an LDAP session, an
- attacker can modify the transmitted values of the
- 'supportedSASLMechanisms' attribute response and thus downgrade the
- list of available SASL mechanisms to include only the least secure
- mechanism. To detect this type of attack, the client may retrieve
- the SASL mechanisms the server makes available both before and after
- data integrity service is installed on an LDAP session. If the
- client finds that the integrity-protected list (the list obtained
- after data integrity service was installed) contains a stronger
- mechanism than those in the previously obtained list, the client
- should assume the previously obtained list was modified by an
- attacker. In this circumstance it is recommended that the client
- close the underlying transport connection and then reconnect to
- reestablish the session.
-
-
-6.5. Related Security Considerations
-
- Additional security considerations relating to the various
- authentication methods and mechanisms discussed in this document
- apply and can be found in [SASL], [RFC4013], [StringPrep] and
- [RFC3629].
-
-
-
-Harrison Expires August 2006 [Page 23]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-7. IANA Considerations
-
- It is requested that the IANA update the LDAP Protocol Mechanism
- registry to indicate that this document and [Protocol] provide the
- definitive technical specification for the StartTLS
- (1.3.6.1.4.1.1466.20037) extended operation.
-
-
-8. Acknowledgments
-
- This document combines information originally contained in RFC 2251,
- RFC 2829 and RFC 2830 which are products of the LDAP Extensions
- (LDAPEXT) Working Group.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS)
- working group.
-
-
-9. Normative References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
- [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
- Representation of Distinguished Names", draft-ietf-
- ldapbis-dn-xx.txt, a work in progress.
-
- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
- ietf-ldapbis-bcp64-xx.txt, (a work in progress).
-
- [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
- in PKIX Certificates", draft-hoffman-pkix-stringmatch-
- xx.txt, a work in progress.
-
- [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
- Information Models", draft-ietf-ldapbis-models-xx.txt,
- a work in progress.
-
- [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
- ldapbis-protocol-xx.txt, a work in progress.
-
- [RFC791] Information Sciences Institute, "INTERNET PROTOCOL
- DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
- 791, September 1981.
-
- [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", draft-crocker-abnf-
- rfc2234bis-xx, a work in progress.
-
- [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
- (IPv6)", RFC 2460, December 1998.
-
-Harrison Expires August 2006 [Page 24]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
- "Internationalizing Domain Names In Applications
- (IDNA)", RFC 3490, March 2003.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, STD 63, November 2003.
-
- [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
- Names and Passwords", RFC 4013, February 2005.
-
- [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (editor), "Simple Authentication and
- Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
- xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf-
- ldapbis-user-schema-xx.txt, a work in progress.
-
- [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
- ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
- work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
- 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
- progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version
- 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
- 61633-5), as amended by the "Unicode Standard Annex
- #27: Unicode 3.1"
- (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
-
-10. Informative References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
- [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft-
- zeilenga-sasl-anon-xx.txt, a work in progress.
-
- [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
- Authentication as a SASL Mechanism", draft-ietf-sasl-
- rfc2831bis-xx.txt, a work in progress.
-
-
-Harrison Expires August 2006 [Page 25]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
- sasl-plain-xx.txt, a work in progress.
-
- [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
- 2000.
-
- [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
- 2829, May 2000.
-
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
-Author's Address
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
- USA
- +1 801 861 2642
- roger_harrison@novell.com
-
-
-Appendix A. Authentication and Authorization Concepts
-
- This appendix is non-normative.
-
- This appendix defines basic terms, concepts, and interrelationships
- regarding authentication, authorization, credentials, and identity.
- These concepts are used in describing how various security
- approaches are utilized in client authentication and authorization.
-
-
-A.1. Access Control Policy
-
- An access control policy is a set of rules defining the protection
- of resources, generally in terms of the capabilities of persons or
- other entities accessing those resources. Security objects and
- mechanisms, such as those described here, enable the expression of
- access control policies and their enforcement.
-
-
-A.2. Access Control Factors
-
- A request, when it is being processed by a server, may be associated
- with a wide variety of security-related factors ([Protocol] section
- 4.2). The server uses these factors to determine whether and how to
- process the request. These are called access control factors
- (ACFs). They might include source IP address, encryption strength,
- the type of operation being requested, time of day, etc.. Some
- factors may be specific to the request itself, others may be
- associated with the transport connection via which the request is
- transmitted, others (e.g., time of day) may be "environmental".
-
-
-Harrison Expires August 2006 [Page 26]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- Access control policies are expressed in terms of access control
- factors. For example, "a request having ACFs i,j,k can perform
- operation Y on resource Z." The set of ACFs that a server makes
- available for such expressions is implementation-specific.
-
-A.3. Authentication, Credentials, Identity
-
- Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g., a
- user) who is attempting to establish a new authorization state with
- the other party (typically a server). Authentication is the process
- of generating, transmitting, and verifying these credentials and
- thus the identity they assert. An authentication identity is the
- name presented in a credential.
-
- There are many forms of authentication credentials. The form used
- depends upon the particular authentication mechanism negotiated by
- the parties. X.509 certificates, Kerberos tickets, and simple
- identity and password pairs are all examples of authentication
- credential forms. Note that an authentication mechanism may
- constrain the form of authentication identities used with it.
-
-
-A.4. Authorization Identity
-
- An authorization identity is one kind of access control factor. It
- is the name of the user or other entity that requests that
- operations be performed. Access control policies are often
- expressed in terms of authorization identities; for example, "entity
- X can perform operation Y on resource Z."
-
- The authorization identity of an LDAP session is often semantically
- the same as the authentication identity presented by the client, but
- it may be different. SASL allows clients to specify an
- authorization identity distinct from the authentication identity
- asserted by the client's credentials. This permits agents such as
- proxy servers to authenticate using their own credentials, yet
- request the access privileges of the identity for which they are
- proxying [SASL]. Also, the form of authentication identity supplied
- by a service like TLS may not correspond to the authorization
- identities used to express a server's access control policy,
- requiring a server-specific mapping to be done. The method by which
- a server composes and validates an authorization identity from the
- authentication credentials supplied by a client is implementation
- specific.
-
-
-Appendix B. Summary of Changes
-
- This appendix is non-normative.
-
-
-
-
-
-Harrison Expires August 2006 [Page 27]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- This appendix summarizes substantive changes made to RFC 2251, RFC
- 2829 and RFC 2830. In addition to the specific changes detailed
- below, the reader of this document should be aware that numerous
- general editorial changes have been made to the original content
- from the source documents. These changes include the following:
-
- - The material originally found in RFC 2251 sections 4.2.1 and
- 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC
- 2830 was combined into a single document
-
- - The combined material was substantially reorganized and edited
- to group related subjects, improve the document flow and clarify
- intent.
-
- - Changes were made throughout the text to align with definitions
- of LDAP protocol layers and IETF security terminology.
-
- - Substantial updates and additions were made to security
- considerations from both documents based on current operational
- experience.
-
-
-B.1. Changes Made to RFC 2251
-
- This section summarizes the substantive changes made to sections
- 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional
- substantive changes to section 4.2.1 of RFC 2251 are also documented
- in [Protocol].
-
-
-B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
-
- - Paragraph 1: Removed the sentence, "If at any stage the client
- wishes to abort the bind process it MAY unbind and then drop the
- underlying connection." The Unbind operation still permits this
- behavior, but it is not documented explicitly.
-
- - Clarified that the session is moved to an anonymous state upon
- receipt of the BindRequest PDU and that it is only moved to a
- non-anonymous state if and when the Bind request is successful.
-
-
-B.1.2. Section 4.2.2 (Authentication and Other Security Services)
-
- - RFC 2251 states that anonymous authentication MUST be performed
- using the simple bind method. This specification defines the
- anonymous authentication mechanism of the simple bind method and
- requires all conforming implementations to support it. Other
- authentication mechanisms producing anonymous authentication and
- authorization state may also be implemented and used by
- conforming implementations.
-
-
-B.2. Changes Made to RFC 2829
-
-Harrison Expires August 2006 [Page 28]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- This section summarizes the substantive changes made to RFC 2829.
-
-
-B.2.1. Section 4 (Required security mechanisms)
-
- - The name/password authentication mechanism (see section B.2.5
- below) protected by TLS replaces the SASL DIGEST-MD5 mechanism
- as LDAP's mandatory-to-implement password-based authentication
- mechanism. Implementations are encouraged to continue
- supporting SASL DIGEST-MD5 [RFC2829].
-
-
-B.2.2. Section 5.1 (Anonymous authentication procedure)
-
- - Clarified that anonymous authentication involves a name value of
- zero length and a password value of zero length. The
- unauthenticated authentication mechanism was added to handle
- simple Bind requests involving a name value with a non-zero
- length and a password value of zero length.
-
-
-B.2.3. Section 6 (Password-based authentication)
-
- - See section B.2.1.
-
-
-B.2.4. Section 6.1 (Digest authentication)
-
- - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
- implement, this section is now historical and was not included
- in this document. RFC 2829 section 6.1 continues to document the
- SASL DIGEST-MD5 authentication mechanism.
-
-
-B.2.5. Section 6.2 ("simple" authentication choice with TLS)
-
- - Renamed the "simple" authentication mechanism to the
- name/password authentication mechanism to better describe it.
-
- - The use of TLS was generalized to align with definitions of LDAP
- protocol layers. TLS establishment is now discussed as an
- independent subject and is generalized for use with all
- authentication mechanisms and other security layers.
-
- - Removed the implication that the userPassword attribute is the
- sole location for storage of password values to be used in
- authentication. There is no longer any implied requirement for
- how or where passwords are stored at the server for use in
- authentication.
-
-
-B.2.6. Section 6.3 (Other authentication choices with TLS)
-
-
-Harrison Expires August 2006 [Page 29]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- - See section B.2.5.
-
-
-B.2.7. Section 7.1 (Certificate-based authentication with TLS)
-
- - See section B.2.5.
-
-
-B.2.8. Section 8 (Other mechanisms)
-
- - All SASL authentication mechanisms are explicitly allowed within
- LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
- mechanisms are no longer precluded from use within LDAP.
-
-
-B.2.9. Section 9 (Authorization identity)
-
- - Specified matching rules for dnAuthzID and uAuthzID values. In
- particular, the DN value in the dnAuthzID form must be matched
- using DN matching rules and the uAuthzID value MUST be prepared
- using SASLprep rules before being compared octet-wise.
-
- - Clarified that uAuthzID values should not be assumed to be
- globally unique.
-
-
-B.2.10. Section 10 (TLS Ciphersuites)
-
- - TLS Ciphersuite recommendations are no longer included in this
- specification. Implementations must still support the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
- - Clarified that anonymous authentication involves a name value of
- zero length and a password value of zero length. The
- unauthenticated authentication mechanism was added to handle
- simple Bind requests involving a name value with a non-zero
- length and a password value of zero length.
-
-
-B.3. Changes Made to RFC 2830:
-
- This section summarizes the substantive changes made to sections 3
- and 5 of RFC 2830. Readers should consult [Protocol] for summaries
- of changes to other sections.
-
-
-B.3.1. Section 3.6 (Server Identity Check)
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 30]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- - Substantially updated the server identity check algorithm to
- ensure that it is complete and robust. In particular, the use
- of all relevant values in the subjectAltName and the subjectName
- fields are covered by the algorithm and matching rules are
- specified for each type of value. Mapped (derived) forms of the
- server identity may now be used when the mapping is performed in
- a secure fashion.
-
-
-B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
-
- - Clients are no longer required to always refresh information
- about server capabilities following TLS establishment to allow
- for situations where this information was obtained through a
- secure mechanism.
-
-
-B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
-
- - Establishing a TLS layer on an LDAP session may now cause the
- authorization state of the LDAP session to change.
-
-
-B.3.4. Section 5.1.1 (TLS Closure Effects)
-
- - Closing a TLS layer on an LDAP session changes the
- authentication and authorization state of the LDAP session based
- on local policy. Specifically, this means that implementations
- are not required to to change the authentication and
- authorization states to anonymous upon TLS closure.
-
-
-Appendix C. Changes for draft-ldapbis-authmeth-19
-
- [[Note to RFC Editor: Please remove this appendix upon publication
- of this Internet-Draft as an RFC.]]
-
- This appendix is non-normative.
-
- This appendix summarizes changes made in this revision of the
- document.
-
- General
-
- - This draft has addressed all issues raised for the -18 version.
-
- - Several minor edits for clarity and to remove typos based on
- feedback from WG, IETF and IESG reviews.
-
- Abstract
- - Added statement regarding RFCs obsoleted by this document.
-
- Section 2
-
-
-Harrison Expires August 2006 [Page 31]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- - Changed mandatory-to-implement TLS ciphersuite from
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
- TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
- WG consensus.
-
- Section 5.2.1.5
- - Clarified that 'supportedSASLMechanisms' should be retrievable
- by all clients both before and after SASL negotiation to allow
- detection of mechanism downgrade attacks.
-
- Section 5.2.1.6
- - Changed wording to reflect the fact that SASL layers cannot be
- uninstalled from the session.
-
- Section 5.2.3
- - Removed reference to IPsec as a source of authorization identity.
-
- Section 6.2
- - When TLS layer does not provide an acceptable level of security
- client MUST warn the user or refuse to proceed. (This was
- changed from SHOULD based on IESG recommendation and WG
- consensus.)
-
- - Added a security consideration regarding the proper usage of
- information found in the client certificate.
-
- Section 6.4
- - Added a new section on SASL security considerations that
- discusses SASL mechanism downgrade attacks.
-
- Section 10
- - Replaced references to RFC 2401 with RFC 4301.
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology described
- in this document or the extent to which any license under such
- rights might or might not be available; nor does it represent that
- it has made any independent effort to identify any such rights.
- Information on the procedures with respect to rights in RFC
- documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
-
-
-
-
-Harrison Expires August 2006 [Page 32]
-\f
-Internet-Draft LDAP Authentication Methods February 2006
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on
- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 33]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: BCP OpenLDAP Foundation
-Expires in six months 23 January 2006
-Obsoletes: RFC 3383
-
-
- IANA Considerations for LDAP
- <draft-ietf-ldapbis-bcp64-06.txt>
-
-
-
-Status of Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Best Current Practice
- document. This document is intended to replace RFC 3383.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- (LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send
- editorial comments directly to the document editor
- <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 1]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-Abstract
-
- This document provides procedures for registering extensible elements
- of Lightweight Directory Access Protocol (LDAP). The document also
- provides guidelines to Internet Assigned Numbers Authority (IANA)
- describing conditions under which new values can be assigned.
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an
- extensible protocol. LDAP supports:
-
- - addition of new operations,
- - extension of existing operations, and
- - extensible schema.
-
- This document details procedures for registering values of used to
- unambiguously identify extensible elements of the protocol including:
-
- - LDAP message types;
- - LDAP extended operations and controls;
- - LDAP result codes;
- - LDAP authentication methods;
- - LDAP attribute description options; and
- - Object Identifier descriptors.
-
- These registries are maintained by the Internet Assigned Numbers
- Authority (IANA).
-
- In addition, this document provides guidelines to IANA describing the
- conditions under which new values can be assigned.
-
- This document replaces RFC 3383.
-
-
-2. Terminology and Conventions
-
- This section details terms and conventions used in this document.
-
-
-2.1. Policy Terminology
-
- The terms "IESG Approval", "Standards Action", "IETF Consensus",
- "Specification Required", "First Come First Served", "Expert Review",
- and "Private Use" are used as defined in BCP 26 [RFC2434].
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 2]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-2.2. Requirement Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119]. In
- this case, "the specification" as used by BCP 14 refers to the
- processing of protocols being submitted to the IETF standards
- process.
-
-
-2.3. Common ABNF Productions
-
- A number of syntaxes in this document are described using ABNF
- [ABNF]. These syntaxes rely on the following common productions:
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- LDIGIT = %x31-39 ; "1"-"9"
- DIGIT = %x30 / LDIGIT ; "0"-"9"
- HYPHEN = %x2D ; "-"
- DOT = %x2E ; "."
- number = DIGIT / ( LDIGIT 1*DIGIT )
- keychar = ALPHA / DIGIT / HYPHEN
- leadkeychar = ALPHA
- keystring = leadkeychar *keychar
-
- A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
- Unicode [Unicode] restricted to the <keystring> production.
-
-
-3. IANA Considerations for LDAP
-
- This section details each kind of protocol value which can be
- registered and provides IANA guidelines on how to assign new values.
-
- IANA may reject obviously bogus registrations.
-
- LDAP values specified in RFCs MUST be registered. Other LDAP values,
- except those in private-use name spaces, SHOULD be registered. RFCs
- SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
- values.
-
-
-3.1. Object Identifiers
-
- Numerous LDAP schema and protocol elements are identified by Object
- Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
- elements SHOULD state who delegated the OIDs for its use.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 3]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- For IETF developed elements, specifications SHOULD use OIDs under
- "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
- by others, any properly delegated OID can be used, including those
- under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
- Enterprise Numbers" (1.3.6.1.4.1.x).
-
- Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
- Review with Specification Required. Only one OID per specification
- will be assigned. The specification MAY then assign any number of
- OIDs within this arc without further coordination with IANA.
-
- Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
- IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
- assignment of Internet Private Enterprise Numbers is detailed in RFC
- 2578 [RFC2578].
-
- To avoid interoperability problems between early implementations of a
- "work in progress" and implementations of the published specification
- (e.g., the RFC), experimental OIDs SHOULD be used in "works in
- progress" and early implementations. OIDs under the Internet
- Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
- Practices for IANA assignment of these Internet Experimental numbers
- is detailed in RFC 2578 [RFC2578]
-
-
-3.2 Protocol Mechanisms
-
- LDAP provides a number of Root DSE attributes for discovery of
- protocol mechanisms identified by OIDs, including the
- supportedControl, supportedExtension, and supportedFeatures
- attributes [Models],
-
- A registry of OIDs used for discover of protocol mechanisms is
- provided to allow implementors and others to locate the technical
- specification for these protocol mechanisms. Future specifications
- of additional Root DSE attributes holding values identifying protocol
- mechanisms MAY extend this registry for their values.
-
- Protocol Mechanisms are registered on a First Come First Served
- basis.
-
-
-3.3 LDAP Syntaxes
-
- This registry provides a listing of LDAP syntaxes [Models]. Each
- LDAP syntax is identified by an object identifier (OID). This
- registry is provided to allow implementors and others to locate the
- technical specification describing a particular LDAP Syntax.
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- LDAP Syntaxes are registered on a First Come First Served with
- Specification Required basis.
-
- Note: unlike object classes, attribute types and various other kinds
- of schema elements, descriptors are not used in LDAP to identify LDAP
- Syntaxes.
-
-
-3.4. Object Identifier Descriptors
-
- LDAP allows short descriptive names (or descriptors) to be used
- instead of a numeric Object Identifier to identify select protocol
- extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
- extensions, and other objects.
-
- While the protocol allows the same descriptor to refer to different
- object identifiers in certain cases and the registry supports
- multiple registrations of the same descriptor (each indicating a
- different kind of schema element and different object identifier),
- multiple registrations of the same descriptor are to be avoided. All
- such multiple registration requests require Expert Review.
-
- Descriptors are restricted to strings of UTF-8 encoded Unicode
- characters restricted by the following ABNF:
-
- name = keystring
-
- Descriptors are case-insensitive.
-
- Multiple names may be assigned to a given OID. For purposes of
- registration, an OID is to be represented in numeric OID form (e.g.,
- 1.1.0.23.40) conforming to the ABNF:
-
- numericoid = number 1*( DOT number )
-
- While the protocol places no maximum length restriction upon
- descriptors, they should be short. Descriptors longer than 48
- characters may be viewed as too long to register.
-
- A value ending with a hyphen ("-") reserves all descriptors which
- start with that value. For example, the registration of the option
- "descrFamily-" reserves all options which start with "descrFamily-"
- for some related purpose.
-
- Descriptors beginning with "x-" are for Private Use and cannot be
- registered.
-
- Descriptors beginning with "e-" are reserved for experiments and will
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 5]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- be registered on a First Come First Served basis.
-
- All other descriptors require Expert Review to be registered.
-
- The registrant need not "own" the OID being named.
-
- The OID name space is managed by The ISO/IEC Joint Technical
- Committee 1 - Subcommittee 6.
-
-
-3.5. AttributeDescription Options
-
- An AttributeDescription [Models] can contain zero or more options
- specifying additional semantics. An option SHALL be restricted to a
- string UTF-8 encoded Unicode characters limited by the following
- ABNF:
-
- option = keystring
-
- Options are case-insensitive.
-
- While the protocol places no maximum length restriction upon option
- strings, they should be short. Options longer than 24 characters may
- be viewed as too long to register.
-
- Values ending with a hyphen ("-") reserve all option names which
- start with the name. For example, the registration of the option
- "optionFamily-" reserves all options which start with "optionFamily-"
- for some related purpose.
-
- Options beginning with "x-" are for Private Use and cannot be
- registered.
-
- Options beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other options require Standards Action or Expert Review with
- Specification Required to be registered.
-
-
-3.6. LDAP Message Types
-
- Each protocol message is encapsulated in an LDAPMessage envelope
- [Protocol]. The protocolOp CHOICE indicates the type of message
- encapsulated. Each message type consists of an ASN.1 identifier in
- the form of a keyword and a non-negative choice number. The choice
- number is combined with the class (APPLICATION) and data type
- (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 6]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- encoding. The choice numbers for existing protocol messages are
- implicit in the protocol's ASN.1 defined in [Protocol].
-
- New values will be registered upon Standards Action.
-
- Note: LDAP provides extensible messages which reduces, but does not
- eliminate, the need to add new message types.
-
-
-3.7. LDAP Authentication Method
-
- The LDAP Bind operation supports multiple authentication methods
- [Protocol]. Each authentication choice consists of an ASN.1
- identifier in the form of a keyword and a non-negative integer.
-
- The registrant SHALL classify the authentication method usage using
- one of the following terms:
-
- COMMON - method is appropriate for common use on the
- Internet,
- LIMITED USE - method is appropriate for limited use,
- OBSOLETE - method has been deprecated or otherwise found to
- be inappropriate for any use.
-
- Methods without publicly available specifications SHALL NOT be
- classified as COMMON. New registrations of class OBSOLETE cannot be
- registered.
-
- New authentication method integers in the range 0-1023 require
- Standards Action to be registered. New authentication method
- integers in the range 1024-4095 require Expert Review with
- Specification Required. New authentication method integers in the
- range 4096-16383 will be registered on a First Come First Served
- basis. Keywords associated with integers in the range 0-4095 SHALL
- NOT start with "e-" or "x-". Keywords associated with integers in
- the range 4096-16383 SHALL start with "e-". Values greater than or
- equal to 16384 and keywords starting with "x-" are for Private Use
- and cannot be registered.
-
- Note: LDAP supports Simple Authentication and Security Layers [SASL]
- as an authentication choice. SASL is an extensible
- authentication framework.
-
-
-3.8. LDAP Result Codes
-
- LDAP result messages carry an resultCode enumerated value to indicate
- the outcome of the operation [Protocol]. Each result code consists
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 7]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- of a ASN.1 identifier in the form of a keyword and a non-negative
- integer.
-
- New resultCodes integers in the range 0-1023 require Standards Action
- to be registered. New resultCode integers in the range 1024-4095
- require Expert Review with Specification Required. New resultCode
- integers in the range 4096-16383 will be registered on a First Come
- First Served basis. Keywords associated with integers in the range
- 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
- integers in the range 4096-16383 SHALL start with "e-". Values
- greater than or equal to 16384 and keywords starting with "x-" are
- for Private Use and cannot be registered.
-
-
-3.9. LDAP Search Scope
-
- LDAP SearchRequest messages carry a scope enumerated value to
- indicate the extend of search within the DIT [Protocol] Each search
- value consists of a ASN.1 identifier in the form of a keyword and a
- non-negative integer.
-
- New scope integers in the range 0-1023 require Standards Action to be
- registered. New scope integers in the range 1024-4095 require Expert
- Review with Specification Required. New scope integers in the range
- 4096-16383 will be registered on a First Come First Served basis.
- Keywords associated with integers in the range 0-4095 SHALL NOT start
- with "e-" or "x-". Keywords associated with integers in the range
- 4096-16383 SHALL start with "e-". Values greater than or equal to
- 16384 and keywords starting with "x-" are for Private Use and cannot
- be registered.
-
-
-3.10. LDAP Filter Choice
-
- LDAP filters are used in making assertions against an object
- represented in the directory [Protocol]. The Filter CHOICE indicates
- a type of assertion. Each Filter CHOICE consists of an ASN.1
- identifier in the form of a keyword and a non-negative choice number.
- The choice number is combined with the class (APPLICATION) and data
- type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
- message's encoding.
-
- Note: LDAP provides the extensibleMatching choice which reduces, but
- does not eliminate, the need to add new filter choices.
-
-
-3.11. LDAP ModifyRequest Operation Type
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 8]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- The LDAP ModifyRequest carries a sequence of modification operations
- [Protocol]. Each kind (e.g., add, delete, replace) of operation is
- consists of a ASN.1 identifier in the form of a keyword and a
- non-negative integer.
-
- New operation type integers in the range 0-1023 require Standards
- Action to be registered. New operation type integers in the range
- 1024-4095 require Expert Review with Specification Required. New
- operation type integers in the range 4096-16383 will be registered on
- a First Come First Served basis. Keywords associated with integers
- in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
- associated with integers in the range 4096-16383 SHALL start with
- "e-". Values greater than or equal to 16384 and keywords starting
- with "x-" are for Private Use and cannot be registered.
-
-
-3.12. LDAP authzId Prefixes
-
- Authorization Identities in LDAP are strings conforming to the
- <authzId> production [AuthMeth]. This production is extensible.
- Each new specific authorization form is identified by a prefix string
- conforming to the following ABNF:
-
- prefix = keystring COLON
- COLON = %x3A ; COLON (":" U+003A)
-
- Prefixes are case-insensitive.
-
- While the protocol places no maximum length restriction upon prefix
- strings, they should be short. Prefixes longer than 12 characters
- may be viewed as too long to register.
-
- Prefixes beginning with "x-" are for Private Use and cannot be
- registered.
-
- Prefixes beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other prefixes require Standards Action or Expert Review with
- Specification Required to be registered.
-
-
-3.13. Directory Systems Names
-
- The IANA-maintained "Directory Systems Names" registry [IANADSN] of
- valid keywords for well known attributes was used in the LDAPv2
- string representation of a distinguished name [RFC1779]. LDAPv2 is
- now Historic [RFC3494].
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 9]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Directory systems names are not known to be used in any other
- context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section
- 3.2] (which have a different syntax than directory system names).
-
- New Directory System Names will no longer be accepted. For
- historical purposes, the current list of registered names should
- remain publicly available.
-
-
-4. Registration Procedure
-
- The procedure given here MUST be used by anyone who wishes to use a
- new value of a type described in Section 3 of this document.
-
- The first step is for the requester to fill out the appropriate form.
- Templates are provided in Appendix A.
-
- If the policy is Standards Action, the completed form SHOULD be
- provided to the IESG with the request for Standards Action. Upon
- approval of the Standards Action, the IESG SHALL forward the request
- (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
- all values requiring Standards Action.
-
- If the policy is Expert Review, the requester SHALL post the
- completed form to the <directory@apps.ietf.org> mailing list for
- public review. The review period is two (2) weeks. If a revised
- form is later submitted, the review period is restarted. Anyone may
- subscribe to this list by sending a request to
- <directory-request@apps.ietf.org>. During the review, objections may
- be raised by anyone (including the Expert) on the list. After
- completion of the review, the Expert, based upon public comments,
- SHALL either approve the request and forward it to the IANA OR deny
- the request. In either case, the Expert SHALL promptly notify the
- requester of the action. Actions of the Expert may be appealed
- [RFC2026]. The Expert is appointed by Applications Area Director(s).
- The requester is viewed as the owner of values registered under
- Expert Review.
-
- If the policy is First Come First Served, the requester SHALL submit
- the completed form directly to the IANA: <iana@iana.org>. The
- requester is viewed as the owner of values registered under First
- Come First Served.
-
- Neither the Expert nor IANA will take position on the claims of
- copyright or trademarks issues regarding completed forms.
-
- Prior to submission of the Internet Draft (I-D) to the RFC Editor but
- after IESG review and tentative approval, the document editor SHOULD
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 10]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- revise the I-D to use registered values.
-
-
-5. Registration Maintenance
-
- This section discusses maintenance of registrations.
-
-
-5.1. Lists of Registered Values
-
- IANA makes lists of registered values readily available to the
- Internet community on their web site: <http://www.iana.org/>.
-
-
-5.2. Change Control
-
- The registration owner MAY update the registration subject to the
- same constraints and review as with new registrations. In cases
- where the owner is not unable or unwilling to make necessary updates,
- the IESG MAY assume ownership in order to update the registration.
-
-
-5.3. Comments
-
- For cases where others (anyone other than the owner) have significant
- objections to the claims in a registration and the owner does not
- agree to change the registration, comments MAY be attached to a
- registration upon Expert Review. For registrations owned by the
- IESG, the objections SHOULD be addressed by initiating a request for
- Expert Review.
-
- The form to these requests is ad hoc, but MUST include the specific
- objections to be reviewed and SHOULD contain (directly or by
- reference) materials supporting the objections.
-
-
-6. Security Considerations
-
- The security considerations detailed in BCP 26 [RFC2434] are
- generally applicable to this document. Additional security
- considerations specific to each name space are discussed in Section 3
- where appropriate.
-
- Security considerations for LDAP are discussed in documents
- comprising the technical specification [Roadmap].
-
-
-7. Acknowledgment
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 11]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- This document is a product of the IETF LDAP Revision (LDAPBIS)
- Working Group (WG). This document is a revision of RFC 3383, also a
- product of the LDAPBIS WG.
-
- This document includes text borrowed from "Guidelines for Writing an
- IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
- Harald Alvestrand.
-
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-9. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-9.1. Normative References
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9 (also RFC 2026), October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26 (also RFC
- 2434), October 1998.
-
- [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure
- of Management Information Version 2 (SMIv2)", RFC 2578
- (STD: 58), April 1999.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 12]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-9.2. Informative References
-
- [RFC1779] Kille, S., "A String Representation of Distinguished
- Names", RFC 1779, March 1995.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 13]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- [IANADSN] IANA, "Directory Systems Names",
- http://www.iana.org/assignments/directory-system-names.
-
-
-Appendix A. Registration Templates
-
- This appendix provides registration templates for registering new
- LDAP values. Note that more than one value may be requested by
- extending the template by listing multiple values, or through use of
- tables.
-
-
-A.1. LDAP Object Identifier Registration Template
-
- Subject: Request for LDAP OID Registration
-
- Person & email address to contact for further information:
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.2. LDAP Protocol Mechanism Registration Template
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Usage: (One of Control or Extension or Feature or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 14]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-A.3. LDAP Syntax Registration Template
-
- Subject: Request for LDAP Syntax Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.4. LDAP Descriptor Registration Template
-
- Subject: Request for LDAP Descriptor Registration
-
- Descriptor (short name):
-
- Object Identifier:
-
- Person & email address to contact for further information:
-
- Usage: (One of administrative role, attribute type, matching rule,
- name form, object class, URL extension, or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.5. LDAP Attribute Description Option Registration Template
-
- Subject: Request for LDAP Attribute Description Option Registration
-
- Option Name:
-
- Family of Options: (YES or NO)
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 15]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.6. LDAP Message Type Registration Template
-
- Subject: Request for LDAP Message Type Registration
-
- LDAP Message Name:
-
- Person & email address to contact for further information:
-
- Specification: (Approved I-D)
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.7. LDAP Authentication Method Registration Template
-
- Subject: Request for LDAP Authentication Method Registration
-
- Authentication Method Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.8. LDAP Result Code Registration Template
-
- Subject: Request for LDAP Result Code Registration
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 16]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Result Code Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.8. LDAP Search Scope Registration Template
-
- Subject: Request for LDAP Search Scope Registration
-
- Search Scope Name:
-
- Filter Scope String:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.9. LDAP Filter Choice Registration Template
-
- Subject: Request for LDAP Filter Choice Registration
-
- Filter Choice Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 17]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-A.10. LDAP ModifyRequest Operation Registration Template
-
- Subject: Request for LDAP ModifyRequest Operation Registration
-
- ModifyRequest Operation Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-Appendix B. Changes since RFC 3383
-
- This informative appendix provides a summary of changes made since RFC
- 3383.
-
- - Object Identifier Descriptors practices were updated to require
- all descriptors defined in RFCs to be registered and
- recommending all other descriptors (excepting those in
- private-use name space) be registered. Additionally, all
- requests for multiple registrations of the same descriptor are
- now subject to Expert Review.
-
- - Protocol Mechanisms practices were updated to include values of
- the 'supportedFeatures' attribute type.
-
- - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
- operation, and authzId prefixes registries were added.
- [[Initial values provided in Appendix C. This Appendix is to be
- removed by the RFC Editor before publication as an RFC.]]
-
- - References to RFCs comprising the LDAP technical specifications
- have been updated to latest revisions.
-
- - References to ISO 10646 have been replaced with [Unicode].
-
- - The "Assigned Values" appendix providing initial registry values
- was removed.
-
- - Numerous editorial changes were made.
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 18]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-Appendix C. Initial Values for new registries
-
- This appendix provides initial values for new registries.
-
-
-C.1. LDAP Syntaxes
-
- Object Identifier Syntax Owner Reference
- ----------------------------- -------------------------- ----- ---
- 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
-
-
-C.2. LDAP Search Scopes
-
- Name URLString Value Owner Reference
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 19]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- ---------------- --------- ----- ----- -------------------
- baseObject base 0 IESG [Protocol][LDAPURL]
- singleLevel one 1 IESG [Protocol][LDAPURL]
- wholeSubtree sub 2 IESG [Protocol][LDAPURL]
-
-
-C.3. LDAP Filter Choices
-
- Name Value Owner Reference
- ---------------- ----- ----- ---------
- and 0 IESG [Protocol]
- or 1 IESG [Protocol]
- not 2 IESG [Protocol]
- equalityMatch 3 IESG [Protocol]
- substrings 4 IESG [Protocol]
- greaterOrEqual 5 IESG [Protocol]
- lessOrEqual 6 IESG [Protocol]
- present 7 IESG [Protocol]
- approxMatch 8 IESG [Protocol]
- extensibleMatch 9 IESG [Protocol]
-
-
-C.4. LDAP ModifyRequest Operations
-
- Name Value Owner Reference
- ---------------- ----- ----- ---------
- add 0 IESG [Protocol]
- delete 1 IESG [Protocol]
- replace 2 IESG [Protocol]
-
-
-C.5. LDAP authzId prefixes
-
- Name Prefix Owner Reference
- ---------------- ------ ----- ---------
- dnAuthzId dn: IESG [AuthMeth]
- uAuthzId u: IESG [AuthMeth]
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 20]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 21]
-\f
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-Obsoletes: RFC 2253
-
-
-
- LDAP: String Representation of Distinguished Names
- <draft-ietf-ldapbis-dn-16.txt>
-
-
-
-Status of Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document
- replacing RFC 2253. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF LDAP
- Revision (LDAPBIS) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the document editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 1]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Abstract
-
- The X.500 Directory uses distinguished names (DNs) as primary keys to
- entries in the directory. This document defines the string
- representation used in the Lightweight Directory Access Protocol
- (LDAP) to transfer distinguished names. The string representation is
- designed to give a clean representation of commonly used distinguished
- names, while being able to represent any distinguished name.
-
-
-1. Background and Intended Usage
-
- In X.500-based directory systems [X.500], including those accessed
- using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
- distinguished names (DNs) are used to unambiguously refer to directory
- entries [X.501][Models].
-
- The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
- In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
- directory protocols), DNs are encoded using the Basic Encoding Rules
- (BER) [X.690]. In LDAP, DNs are represented in the string form
- described in this document.
-
- It is important to have a common format to be able to unambiguously
- represent a distinguished name. The primary goal of this
- specification is ease of encoding and decoding. A secondary goal is
- to have names that are human readable. It is not expected that LDAP
- implementations with a human user interface would display these
- strings directly to the user, but would most likely be performing
- translations (such as expressing attribute type names in the local
- national language).
-
- This document defines the string representation of Distinguished Names
- used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
- algorithm for converting a DN from its ASN.1 structured representation
- to a string. Section 3 details how to convert a DN from a string to a
- ASN.1 structured representation.
-
- While other documents may define other algorithms for converting a DN
- from its ASN.1 structured representation to a string, all algorithms
- MUST produce strings which adhere to the requirements of Section 3.
-
- This document does not define a canonical string representation for
- DNs. Comparison of DNs for equality is to be performed in accordance
- with the distinguishedNameMatch matching rule [Syntaxes].
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 2]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- specification, RFC 3377, in its entirety. This document obsoletes RFC
- 2253. Changes since RFC 2253 are summarized in Appendix B.
-
- This specification assumes familiarity with X.500 [X.500] and the
- concept of Distinguished Name [X.501][Models].
-
-
-1.1. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
-
-2. Converting DistinguishedName from ASN.1 to a String
-
- X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
- name. The following is a variant provided for discussion purposes.
-
- DistinguishedName ::= RDNSequence
-
- RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
- RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
- AttributeTypeAndValue
-
- AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
- This section defines the RECOMMENDED algorithm for converting a
- distinguished name from an ASN.1 structured representation to an UTF-8
- [RFC3629] encoded Unicode [Unicode] character string representation.
- Other documents may describe other algorithms for converting a
- distinguished name to a string, but only strings which conform to the
- grammar defined in Section 3 SHALL be produced by LDAP
- implementations.
-
-
-2.1. Converting the RDNSequence
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 3]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- If the RDNSequence is an empty sequence, the result is the empty or
- zero length string.
-
- Otherwise, the output consists of the string encodings of each
- RelativeDistinguishedName in the RDNSequence (according to Section
- 2.2), starting with the last element of the sequence and moving
- backwards toward the first.
-
- The encodings of adjoining RelativeDistinguishedNames are separated by
- a comma (',' U+002C) character.
-
-
-2.2. Converting RelativeDistinguishedName
-
- When converting from an ASN.1 RelativeDistinguishedName to a string,
- the output consists of the string encodings of each
- AttributeTypeAndValue (according to Section 2.3), in any order.
-
- Where there is a multi-valued RDN, the outputs from adjoining
- AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
- character.
-
-
-2.3. Converting AttributeTypeAndValue
-
- The AttributeTypeAndValue is encoded as the string representation of
- the AttributeType, followed by an equals sign ('=' U+003D) character,
- followed by the string representation of the AttributeValue. The
- encoding of the AttributeValue is given in Section 2.4.
-
- If the AttributeType is defined to have a short name (descriptor)
- [Models] and that short name is known to be registered
- [REGISTRY][BCP64bis] as identifying the AttributeType, that short
- name, a <descr>, is used. Otherwise the AttributeType is encoded as
- the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
- The <descr> and <numericoid> is defined in [Models].
-
- Implementations are not expected to dynamically update their knowledge
- of registered short names. However, implementations SHOULD provide a
- mechanism to allow its knowledge of registered short names to be
- updated.
-
-
-2.4. Converting an AttributeValue from ASN.1 to a String
-
- If the AttributeType is of the dotted-decimal form, the AttributeValue
- is represented by an number sign ('#' U+0023) character followed by
- the hexadecimal encoding of each of the octets of the BER encoding of
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- the X.500 AttributeValue. This form is also used when the syntax of
- the AttributeValue does not have a LDAP-specific [Syntaxes, Section
- 3.1] string encoding defined for it or the LDAP-specific string
- encoding is not restricted to UTF-8 encoded Unicode characters. This
- form may also be used in other cases, such as when a reversible string
- representation is desired (see Section 5.2).
-
- Otherwise, if the AttributeValue is of a syntax which has a
- LDAP-specific string encoding, the value is converted first to a UTF-8
- encoded Unicode string according to its syntax specification (see
- [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
- string does not have any of the following characters which need
- escaping, then that string can be used as the string representation of
- the value.
-
- - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
- the beginning of the string;
-
- - a space (' ' U+0020) character occurring at the end of the
- string;
-
- - one of the characters '"', '+', ',', ';', '<', '>', or '\'
- (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
- respectively);
-
- - the null (U+0000) character.
-
- Other characters may be escaped.
-
- Each octet of the character to be escaped is replaced by a backslash
- and two hex digits, which form a single octet in the code of the
- character. Alternatively, if and only if the character to be escaped
- is one of
-
- ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
- (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
- U+003C, U+003D, U+003E, U+005C respectively)
-
- it can be prefixed by a backslash ('\' U+005C).
-
- Examples of the escaping mechanism are shown in Section 4.
-
-
-3. Parsing a String back to a Distinguished Name
-
- The string representation of Distinguished Names is restricted to
- UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
- of this string representation is specified using the following
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 5]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Augmented BNF [RFC2234] grammar:
-
- distinguishedName = [ relativeDistinguishedName
- *( COMMA relativeDistinguishedName ) ]
- relativeDistinguishedName = attributeTypeAndValue
- *( PLUS attributeTypeAndValue )
- attributeTypeAndValue = attributeType EQUALS attributeValue
- attributeType = descr / numericoid
- attributeValue = string / hexstring
-
- ; The following characters are to be escaped when they appear
- ; in the value to be encoded: ESC, one of <escaped>, leading
- ; SHARP or SPACE, trailing SPACE, and NULL.
- string = [ ( leadchar / pair ) [ *( stringchar / pair )
- ( trailchar / pair ) ] ]
-
- leadchar = LUTF1 / UTFMB
- LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- trailchar = TUTF1 / UTFMB
- TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- stringchar = SUTF1 / UTFMB
- SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- pair = ESC ( ESC / special / hexpair )
- special = escaped / SPACE / SHARP / EQUALS
- escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
- hexstring = SHARP 1*hexpair
- hexpair = HEX HEX
-
- where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
- <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
- <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
-
- Each <attributeType>, either a <descr> or a <numericoid>, refers to an
- attribute type of an attribute value assertion (AVA). The
- <attributeType> is followed by a <EQUALS> and an <attributeValue>.
- The <attributeValue> is either in <string> or <hexstring> form.
-
- If in <string> form, a LDAP string representation asserted value can
- be obtained by replacing (left-to-right, non-recursively) each <pair>
- appearing in the <string> as follows:
- replace <ESC><ESC> with <ESC>;
- replace <ESC><special> with <special>;
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 6]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- replace <ESC><hexpair> with the octet indicated by the <hexpair>.
-
- If in <hexstring> form, a BER representation can be obtained from
- converting each <hexpair> of the <hexstring> to the octet indicated by
- the <hexpair>.
-
- One or more attribute values assertions, separated by <PLUS>, for a
- relative distinguished name.
-
- Zero or more relative distinguished names, separated by <COMMA>, for a
- distinguished name.
-
- Implementations MUST recognize AttributeType name strings
- (descriptors) listed in the following table, but MAY recognize other
- name strings.
-
- String X.500 AttributeType
- ------ --------------------------------------------
- CN commonName (2.5.4.3)
- L localityName (2.5.4.7)
- ST stateOrProvinceName (2.5.4.8)
- O organizationName (2.5.4.10)
- OU organizationalUnitName (2.5.4.11)
- C countryName (2.5.4.6)
- STREET streetAddress (2.5.4.9)
- DC domainComponent (0.9.2342.19200300.100.1.25)
- UID userId (0.9.2342.19200300.100.1.1)
-
- Implementations MAY recognize other DN string representations (such as
- that described in RFC 1779). However, as there is no requirement that
- alternative DN string representations to be recognized (and, if so,
- how), implementations SHOULD only generate DN strings in accordance
- with Section 2 of this document.
-
-
-4. Examples
-
- This notation is designed to be convenient for common forms of name.
- This section gives a few examples of distinguished names written using
- this notation. First is a name containing three relative
- distinguished names (RDNs):
-
- UID=jsmith,DC=example,DC=net
-
- Here is an example name containing three RDNs, in which the first RDN
- is multi-valued:
-
- OU=Sales+CN=J. Smith,DC=example,DC=net
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 7]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- This example shows the method of escaping of a special characters
- appearing in a common name:
-
- CN=James \"Jim\" Smith\, III,DC=example,DC=net
-
- The following shows the method for encoding a value which contains a
- carriage return character:
-
- CN=Before\0dAfter,DC=example,DC=net
-
- In this RDN example, the type in the RDN is unrecognized, and the
- value is the BER encoding of an OCTET STRING containing two octets
- 0x48 and 0x69.
-
- 1.3.6.1.4.1.1466.0=#04024869
-
- Finally, this example shows an RDN whose commonName value consisting
- of 5 letters:
-
- Unicode Character Code UTF-8 Escaped
- ------------------------------- ------ ------ --------
- LATIN CAPITAL LETTER L U+004C 0x4C L
- LATIN SMALL LETTER U U+0075 0x75 u
- LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
- LATIN SMALL LETTER I U+0069 0x69 i
- LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
-
- could be encoded in printable ASCII (useful for debugging purposes)
- as:
-
- CN=Lu\C4\8Di\C4\87
-
-
-5. Security Considerations
-
- The following security considerations are specific to the handling of
- distinguished names. LDAP security considerations are discussed in
- [Protocol] and other documents comprising the LDAP Technical
- Specification [Roadmap].
-
-
-5.1. Disclosure
-
- Distinguished Names typically consist of descriptive information about
- the entries they name, which can be people, organizations, devices or
- other real-world objects. This frequently includes some of the
- following kinds of information:
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 8]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- - the common name of the object (i.e. a person's full name)
- - an email or TCP/IP address
- - its physical location (country, locality, city, street address)
- - organizational attributes (such as department name or affiliation)
-
- In some cases, such information can be considered sensitive. In many
- countries, privacy laws exist which prohibit disclosure of certain
- kinds of descriptive information (e.g., email addresses). Hence,
- servers implementors are encouraged to support DIT structural rules
- and name forms [Models] as these provide a mechanism for
- administrators to select appropriate naming attributes for entries.
- Administrators are encouraged to use these mechanisms, access
- controls, and other administrative controls which may be available to
- restrict use of attributes containing sensitive information in naming
- of entries. Additionally, use of authentication and data security
- services in LDAP [AuthMeth][Protocol] should be considered.
-
-
-5.2. Use of Distinguished Names in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
- form. An example of a situation which requires the DER form of a
- distinguished name is the verification of an X.509 certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string <CN=Sam>. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation <CN=Sam>.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a distinguished name to the LDAP format. Instead,
- they SHOULD use the hexadecimal form prefixed by the number sign ('#'
- U+0023) as described in the first paragraph of Section 2.4.
-
-
-6. Acknowledgment
-
- This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
- Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
-
- This document is a product of the IETF LDAPBIS Working Group.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 9]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-7. Document Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 10]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [REGISTRY] IANA, Object Identifier Descriptors Registry,
- <http://www.iana.org/...>.
-
-8.2. Informative References
-
- [ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 11]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Appendix A. Presentation Issues
-
- This appendix is provided for informational purposes only, it is not a
- normative part of this specification.
-
- The string representation described in this document is not intended
- to be presented to humans without translation. However, at times it
- may be desirable to present non-translated DN strings to users. This
- section discusses presentation issues associated with non-translated
- DN strings. Presentation of translated DN strings issues are not
- discussed in this appendix. Transcoding issues are also not discussed
- in this appendix.
-
- This appendix provides guidance for applications presenting DN strings
- to users. This section is not comprehensive, it does not discuss all
- presentation issues which implementors may face.
-
- Not all user interfaces are capable of displaying the full set of
- Unicode characters. Some Unicode characters are not displayable.
-
- It is recommended that human interfaces use the optional hex pair
- escaping mechanism (Section 2.3) to produce a string representation
- suitable for display to the user. For example, an application can
- generate a DN string for display which escapes all non-printable
- characters appearing in the AttributeValue's string representation (as
- demonstrated in the final example of Section 4).
-
- When a DN string is displayed in free form text, it is often necessary
- to distinguish the DN string from surrounding text. While this is
- often done with white space (as demonstrated in Section 4), it is
- noted that DN strings may end with white space. Careful readers of
- Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may
- only appear in the DN string if escaped. These characters are
- intended to be used in free form text to distinguish a DN string from
- surrounding text. For example, <CN=Sam\ > distinguished the string
- representation of the DN comprised of one RDN consisting of the AVA:
- the commonName (CN) value 'Sam ' from the surrounding text. It should
- be noted to the user that the wrapping '<' and '>' characters are not
- part of the DN string.
-
- DN strings can be quite long. It is often desirable to line-wrap
- overly long DN strings in presentations. Line wrapping should be done
- by inserting white space after the RDN separator character or, if
- necessary, after the AVA separator character. It should be noted to
- the user that the inserted white space is not part of the DN string
- and is to be removed before use in LDAP. For example,
-
- The following DN string is long:
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 12]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
- O=OpenLDAP Foundation,ST=California,C=US
- so it has been line-wrapped for readability. The extra white
- space is to be removed before the DN string is used in LDAP.
-
- It is not advised to insert white space otherwise as it may not be
- obvious to the user which white space is part of the DN string and
- which white space was added for readability.
-
- Another alternative is to use the LDAP Data Interchange Format (LDIF)
- [RFC2849]. For example,
-
- # This entry has a long DN...
- dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
- O=OpenLDAP Foundation,ST=California,C=US
- CN: Kurt D. Zeilenga
- SN: Zeilenga
- objectClass: person
-
-
-Appendix B. Changes made since RFC 2253
-
- This appendix is provided for informational purposes only, it is not a
- normative part of this specification.
-
- The following substantive changes were made to RFC 2253:
- - Removed IESG Note. The IESG Note has been addressed.
- - Replaced all references to ISO 10646-1 with [Unicode].
- - Clarified (in Section 1) that this document does not define a
- canonical string representation.
- - Clarified that Section 2 describes the RECOMMENDED encoding
- algorithm and that alternative algorithms are allowed. Some
- encoding options described in RFC 2253 are now treated as
- alternative algorithms in this specification.
- - Revised specification (in Section 2) to allow short names of any
- registered attribute type to appear in string representations of
- DNs instead of being restricted to a "published table". Remove
- "as an example" language. Added statement (in Section 3) allowing
- recognition of additional names but require recognization of those
- names in the published table. The table is now published in
- Section 3.
- - Removed specification of additional requirements for LDAPv2
- implementations which also support LDAPv3 (RFC 2253, Section 4) as
- LDAPv2 is now Historic.
- - Allow recognition of alternative string representations.
- - Updated Section 2.4 to allow hex pair escaping of all characters
- and clarified escaping for when multiple octet UTF-8 encodings are
- present. Indicated that null (U+0000) character is to be escaped.
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 13]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Indicated that equals sign ('=' U+003D) character may be escaped
- as '\='.
- - Rewrote Section 3 to use ABNF as defined in RFC 2234.
- - Updated the Section 3 ABNF. Changes include:
- + allow AttributeType short names of length 1 (e.g., 'L'),
- + use more restrictive <oid> production in AttributeTypes,
- + do not require escaping of equals sign ('=' U+003D) characters,
- + do not require escaping of non-leading number sign ('#' U+0023)
- characters,
- + allow space (' ' U+0020) to escaped as '\ ',
- + require hex escaping of null (U+0000) characters, and
- + removed LDAPv2-only constructs.
- - Updated Section 3 to describe how to parse elements of the
- grammar.
- - Rewrote examples.
- - Added reference to documentations containing general LDAP security
- considerations.
- - Added discussion of presentation issues (Appendix A).
- - Added this appendix.
-
- In addition, numerous editorial changes were made.
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 14]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 15]
-\f
-
+++ /dev/null
-Network Working Group M. Smith, Editor
-Request for Comments: DRAFT Pearl Crescent, LLC
-Obsoletes: RFC 2254 T. Howes
-Expires: 16 May 2005 Opsware, Inc.
- 16 November 2004
-
-
- LDAP: String Representation of Search Filters
- <draft-ietf-ldapbis-filter-09.txt>
-
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she become
- aware will be disclosed, in accordance with RFC 3668.
-
- This document is intended to be published as a Standards Track RFC,
- replacing RFC 2254. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF
- LDAP (v3) Revision (ldapbis) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <mcs@pearlcrescent.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 1]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
-Abstract
-
- LDAP search filters are transmitted in the LDAP protocol using a
- binary representation that is appropriate for use on the network.
- This document defines a human-readable string representation of LDAP
- search filters that is appropriate for use in LDAP URLs [LDAPURL] and
- in other applications.
-
-Table of Contents
-
- Status of this Memo............................................1
- Abstract.......................................................2
- Table of Contents..............................................2
-1. Introduction...................................................2
-2. LDAP Search Filter Definition..................................3
-3. String Search Filter Definition................................4
-4. Examples.......................................................6
-5. Security Considerations........................................7
-6. IANA Considerations............................................7
-7. Normative References...........................................7
-8. Informative References.........................................8
-9. Acknowledgments................................................8
-10. Authors' Addresses.............................................9
-11. Appendix A: Changes Since RFC 2254.............................9
-11.1. Technical Changes...........................................9
-11.2. Editorial Changes...........................................10
-12. Appendix B: Changes Since Previous Document Revision...........11
-12.1. Technical Changes...........................................11
-12.2. Editorial Changes...........................................12
- Intellectual Property Rights...................................12
- Full Copyright.................................................13
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a
- network representation of a search filter transmitted to an LDAP
- server. Some applications may find it useful to have a common way of
- representing these search filters in a human-readable form; LDAP URLs
- are an example of one such application. This document defines a
- human-readable string format for representing the full range of
- possible LDAP version 3 search filters, including extended match
- filters.
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 2]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- This document replaces RFC 2254. Changes to RFC 2254 are summarized
- in Appendix A.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-2. LDAP Search Filter Definition
-
- An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
- follows:
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- initial and final can occur at most once
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue,
- any [1] AssertionValue,
- final [2] AssertionValue } }
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
- AttributeValue ::= OCTET STRING
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 3]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- MatchingRuleId ::= LDAPString
-
- AssertionValue ::= OCTET STRING
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [Unicode] characters
-
- The AttributeDescription, as defined in [Protocol], is a string
- representation of the attribute description that is discussed in
- [Models]. The AttributeValue and AssertionValue OCTET STRING have
- the form defined in [Syntaxes]. The Filter is encoded for
- transmission over a network using the Basic Encoding Rules (BER)
- defined in [X.690], with simplifications described in [Protocol].
-
-3. String Search Filter Definition
-
- The string representation of an LDAP search filter is a string of
- UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
- by the following grammar, following the ABNF notation defined in
- [RFC2234]. The productions used that are not defined here are
- defined in section 1.4 (Common ABNF Productions) of [Models] unless
- otherwise noted. The filter format uses a prefix notation.
-
- filter = LPAREN filtercomp RPAREN
- filtercomp = and / or / not / item
- and = AMPERSAND filterlist
- or = VERTBAR filterlist
- not = EXCLAMATION filter
- filterlist = 1*filter
- item = simple / present / substring / extensible
- simple = attr filtertype assertionvalue
- filtertype = equal / approx / greaterorequal / lessorequal
- equal = EQUALS
- approx = TILDE EQUALS
- greaterorequal = RANGLE EQUALS
- lessorequal = LANGLE EQUALS
- extensible = ( attr [dnattrs]
- [matchingrule] COLON EQUALS assertionvalue )
- / ( [dnattrs]
- matchingrule COLON EQUALS assertionvalue )
- present = attr EQUALS ASTERISK
- substring = attr EQUALS [initial] any [final]
- initial = assertionvalue
- any = ASTERISK *(assertionvalue ASTERISK)
- final = assertionvalue
- attr = attributedescription
- ; The attributedescription rule is defined in
- ; Section 2.5 of [Models].
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- dnattrs = COLON "dn"
- matchingrule = COLON oid
- assertionvalue = valueencoding
- ; The <valueencoding> rule is used to encode an <AssertionValue>
- ; from Section 4.1.6 of [Protocol].
- valueencoding = 0*(normal / escaped)
- normal = UTF1SUBSET / UTFMB
- escaped = ESC HEX HEX
- UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
- ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
- ; RPAREN, ASTERISK, and ESC.
- EXCLAMATION = %x21 ; exclamation mark ("!")
- AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
- ASTERISK = %x2A ; asterisk ("*")
- COLON = %x3A ; colon (":")
- VERTBAR = %x7C ; vertical bar (or pipe) ("|")
- TILDE = %x7E ; tilde ("~")
-
-
- Note that although both the <substring> and <present> productions in
- the grammar above can produce the "attr=*" construct, this construct
- is used only to denote a presence filter.
-
- The <valueencoding> rule ensures that the entire filter string is a
- valid UTF-8 string and provides that the octets that represent the
- ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
- 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
- backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
- representing the value of the encoded octet.
-
- This simple escaping mechanism eliminates filter-parsing ambiguities
- and allows any filter that can be represented in LDAP to be
- represented as a NUL-terminated string. Other octets that are part of
- the <normal> set may be escaped using this mechanism, for example,
- non-printing ASCII characters.
-
- For AssertionValues that contain UTF-8 character data, each octet of
- the character to be escaped is replaced by a backslash and two hex
- digits, which form a single octet in the code of the character. For
- example, the filter checking whether the "cn" attribute contained a
- value with the character "*" anywhere in it would be represented as
- "(cn=*\2a*)".
-
- As indicated by the <valueencoding> rule, implementations MUST escape
- all octets greater than 0x7F that are not part of a valid UTF-8
- encoding sequence when they generate a string representation of a
- search filter. Implementations SHOULD accept as input strings that
- are not valid UTF-8 strings. This is necessary because RFC 2254 did
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- not clearly define the term "string representation" (and in
- particular did not mention that the string representation of an LDAP
- search filter is a string of UTF-8 encoded Unicode characters).
-
-4. Examples
-
- This section gives a few examples of search filters written using
- this notation.
-
- (cn=Babs Jensen)
- (!(cn=Tim Howes))
- (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
- (o=univ*of*mich*)
- (seeAlso=)
-
- The following examples illustrate the use of extensible matching.
-
- (cn:caseExactMatch:=Fred Flintstone)
- (cn:=Betty Rubble)
- (sn:dn:2.4.6.8.10:=Barney Rubble)
- (o:dn:=Ace Industry)
- (:1.2.3:=Wilma Flintstone)
- (:DN:2.4.6.8.10:=Dino)
-
- The first example shows use of the matching rule "caseExactMatch."
-
- The second example demonstrates use of a MatchingRuleAssertion form
- without a matchingRule.
-
- The third example illustrates the use of the ":oid" notation to
- indicate that matching rule identified by the OID "2.4.6.8.10" should
- be used when making comparisons, and that the attributes of an
- entry's distinguished name should be considered part of the entry
- when evaluating the match (indicated by the use of ":dn").
-
- The fourth example denotes an equality match, except that DN
- components should be considered part of the entry when doing the
- match.
-
- The fifth example is a filter that should be applied to any attribute
- supporting the matching rule given (since the <attr> has been
- omitted).
-
- The sixth and final example is also a filter that should be applied
- to any attribute supporting the matching rule given. Attributes
- supporting the matching rule contained in the DN should also be
- considered.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 6]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- The following examples illustrate the use of the escaping mechanism.
-
- (o=Parens R Us \28for all your parenthetical needs\29)
- (cn=*\2A*)
- (filename=C:\5cMyFile)
- (bin=\00\00\00\04)
- (sn=Lu\c4\8di\c4\87)
- (1.3.6.1.4.1.1466.0=\04\02\48\69)
-
- The first example shows the use of the escaping mechanism to
- represent parenthesis characters. The second shows how to represent a
- "*" in an assertion value, preventing it from being interpreted as a
- substring indicator. The third illustrates the escaping of the
- backslash character.
-
- The fourth example shows a filter searching for the four octet value
- 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
- represent arbitrary data, including NUL characters.
-
- The fifth example illustrates the use of the escaping mechanism to
- represent various non-ASCII UTF-8 characters. Specifically, there are
- 5 characters in the <assertionvalue> portion of this example: LATIN
- CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
- LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
- LATIN SMALL LETTER C WITH ACUTE (U+0107).
-
- The sixth and final example demonstrates assertion of a BER encoded
- value.
-
-5. Security Considerations
-
- This memo describes a string representation of LDAP search filters.
- While the representation itself has no known security implications,
- LDAP search filters do. They are interpreted by LDAP servers to
- select entries from which data is retrieved. LDAP servers should
- take care to protect the data they maintain from unauthorized access.
-
- Please refer to the Security Considerations sections of [Protocol]
- and [AuthMeth] for more information.
-
-6. IANA Considerations
-
- This document has no actions for IANA.
-
-7. Normative References
-
-[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 7]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
-[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress.
-
-[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
-[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
-[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 3629, November 2003.
-
-[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
-[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
-[Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
- amended by the "Unicode Standard Annex #27: Unicode 3.1"
- (http://www.unicode.org/reports/tr27/) and by the "Unicode
- Standard Annex #28: Unicode 3.2."
-
-8. Informative References
-
-[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
-[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
- Distinguished Encoding Rules, ITU-T Recommendation X.690,
- 1994.
-
-9. Acknowledgments
-
- This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
- of the IETF ASID Working Group.
-
- Changes included in this revised specification are based upon
- discussions among the authors, discussions within the LDAP (v3)
- Revision Working Group (ldapbis), and discussions within other IETF
- Working Groups. The contributions of individuals in these working
- groups is gratefully acknowledged.
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
-10. Authors' Addresses
-
- Mark Smith, Editor
- Pearl Crescent, LLC
- 447 Marlpool Dr.
- Saline, MI 48176
- USA
- +1 734 944-2856
- mcs@pearlcrescent.com
-
-
- Tim Howes
- Opsware, Inc.
- 599 N. Mathilda Ave.
- Sunnyvale, CA 94085
- USA
- +1 408 744-7509
- howes@opsware.com
-
-11. Appendix A: Changes Since RFC 2254
-
-11.1. Technical Changes
-
- Replaced [ISO 10646] reference with [Unicode].
-
- The following technical changes were made to the contents of the
- "String Search Filter Definition" section:
-
- Added statement that the string representation is a string of UTF-8
- encoded Unicode characters.
-
- Revised all of the ABNF to use common productions from [Models].
-
- Replaced the "value" rule with a new "assertionvalue" rule within the
- "simple", "extensible", and "substring" ("initial", "any", and
- "final") rules. This matches a change made in [Syntaxes].
-
- Added "(" and ")" around the components of the <extensible>
- subproductions for clarity.
-
- Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
- precisely reference productions from the [Models] and [Protocol]
- documents.
-
- "String Search Filter Definition" section: replaced "greater" and
- "less" with "greaterorequal" and "lessorequal" to avoid confusion.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- Introduced the "valueencoding" and associated "normal" and "escaped"
- rules to reduce the dependence on descriptive text. The "normal"
- production restricts filter strings to valid UTF-8 sequences.
-
- Added a statement about expected behavior in light of RFC 2254's lack
- of a clear definition of "string representation."
-
-
-
-11.2. Editorial Changes
-
- Changed document title to include "LDAP:" prefix.
-
- IESG Note: removed note about lack of satisfactory mandatory
- authentication mechanisms.
-
- Header and "Authors' Addresses" sections: added Mark Smith as the
- document editor and updated affiliation and contact information.
-
- "Table of Contents", "IANA Considerations", and "Intellectual
- Property Rights" sections: added.
-
- Copyright: updated per latest IETF guidelines.
-
- "Abstract" section: separated from introductory material.
-
- "Introduction" section: new section; separated from the Abstract.
- Updated second paragraph to indicate that RFC 2254 is replaced by
- this document (instead of RFC 1960). Added reference to the [Roadmap]
- document.
-
- "LDAP Search Filter Definition" section: made corrections to the LDAP
- search filter ABNF so it matches that used in [Protocol].
-
- Clarified the definition of 'value' (now 'assertionvalue') to take
- into account the fact that it is not precisely an AttributeAssertion
- from [Protocol] section 4.1.6 (special handling is required for some
- characters). Added a note that each octet of a character to be
- escaped is replaced by a backslash and two hex digits, which
- represent a single octet.
-
- "Examples" section: added four additional examples: (seeAlso=),
- (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
- (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
- value" with "an assertion value". Corrected the description of this
- example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
- in the first extensible match example with "caseExactMatch" to
- demonstrate use of the descriptive form. Used "DN" (uppercase) in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- the last extensible match example to remind the reader to treat the
- <dnattrs> production as case insensitive. Reworded the description
- of the fourth escaping mechanism example to avoid making assumptions
- about byte order. Added text to the fifth escaping mechanism example
- to spell out what the non-ASCII characters are in Unicode terms.
-
- "Security Considerations" section: added references to [Protocol] and
- [AuthMeth].
-
- "Normative References" section: renamed from "References" per new RFC
- guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added entries for [Unicode], [RFC2119], [AuthMeth],
- [Models], and [Roadmap] and updated the UTF-8 reference. Replaced
- RFC 822 reference with a reference to RFC 2234.
-
- "Informative References" section: (new section) moved [X.690] to this
- section. Added a reference to [LDAPURL].
-
- "Acknowledgments" section: added.
-
- "Appendix A: Changes Since RFC 2254" section: added.
-
- "Appendix B: Changes Since Previous Document Revision" section:
- added.
-
- Surrounded the names of all ABNF productions with "<" and ">" where
- they are used in descriptive text.
-
- Replaced all occurrences of "LDAPv3" with "LDAP."
-
-
-12. Appendix B: Changes Since Previous Document Revision
-
- This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-filter-08.txt. Note that when
- appropriate these changes are also included in Appendix A, but are
- also included here for the benefit of the people who have already
- reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
- removed before this document is published as an RFC.
-
-
-12.1. Technical Changes
-
- Removed the third option from the "extensible" production that
- allowed creation of a MatchingRuleAssertion that only had a
- matchValue (disallowed By [Protocol]). Added "(" and ")" around the
- components of the <extensible> subproductions for clarity.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 11]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
-12.2. Editorial Changes
-
- "Introduction" section: referenced [Roadmap] upon first use of LDAP
- and expanded the paragraph that begins "This document is an integral
- part of the LDAP technical specification..." to match the text used
- in [Protocol].
-
- "LDAP Search Filter Definition" section: reworded the last paragraph
- for clarity.
-
- "Examples" section: Replaced the numeric OID in the first extensible
- match example with "caseExactMatch" to demonstrate use of the
- descriptive form. Used "DN" (uppercase) in the last extensible match
- example to remind the reader to treat the <dnattrs> production as
- case insensitive. Reworded the description of the fourth escaping
- mechanism example to avoid making assumptions about byte order.
- Added text to the fifth escaping mechanism example to spell out what
- the non-ASCII characters are in Unicode terms.
-
- References: added [LDAPURL] and moved [X.690] to "Informative
- References."
-
- "Acknowledgements" section: added the sentence "RFC 2254 was a
- product of the IETF ASID Working Group."
-
- Changed these two sections to unnumbered ones: "Intellectual Property
- Rights" and "Full Copyright."
-
- Surrounded the names of all ABNF productions with "<" and ">" where
- they are used in descriptive text.
-
- Replaced all occurrences of "LDAPv3" with "LDAP."
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 12]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Full Copyright
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-This Internet Draft expires on 16 May 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 13]
\ No newline at end of file
+++ /dev/null
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 21 February 2005
-Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
-
-
-
- LDAP: Directory Information Models
- <draft-ietf-ldapbis-models-14.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-Zeilenga LDAP Models [Page 1]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an Internet
- protocol for accessing distributed directory services which act in
- accordance with X.500 data and service models. This document
- describes the X.500 Directory Information Models, as used in LDAP.
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Introduction 3
- 1.1. Relationship to Other LDAP Specifications
- 1.2. Relationship to X.501 4
- 1.3. Conventions
- 1.4. Common ABNF Productions
- 2. Model of Directory User Information 6
- 2.1. The Directory Information Tree 7
- 2.2. Structure of an Entry
- 2.3. Naming of Entries 8
- 2.4. Object Classes 9
- 2.5. Attribute Descriptions 12
- 2.6. Alias Entries 16
- 3. Directory Administrative and Operational Information 17
- 3.1. Subtrees
- 3.2. Subentries 18
- 3.3. The 'objectClass' attribute
- 3.4. Operational attributes 19
- 4. Directory Schema 22
- 4.1. Schema Definitions 23
- 4.2. Subschema Subentries 32
- 4.3. 'extensibleObject' 35
- 4.4. Subschema Discovery 36
- 5. DSA (Server) Informational Model
- 5.1. Server-specific Data Requirements 37
- 6. Other Considerations 40
- 6.1. Preservation of User Information 41
- 6.2. Short Names
- 6.3. Cache and Shadowing
- 7. Implementation Guidelines 42
- 7.1. Server Guidelines
- 7.2. Client Guidelines
- 8. Security Considerations 43
- 9. IANA Considerations
- 10. Acknowledgments 44
- 11. Editor's Address
- 12. References
-
-
-
-Zeilenga LDAP Models [Page 2]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- 12.1. Normative References 45
- 12.2. Informative References
- Appendix A. Changes
- Intellectual Property Rights 51
- Full Copyright
-
-
-1. Introduction
-
- This document discusses the X.500 Directory Information Models
- [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
- [Roadmap].
-
- The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. The information held in the Directory is
- collectively known as the Directory Information Base (DIB). A
- Directory user, which may be a human or other entity, accesses the
- Directory through a client (or Directory User Agent (DUA)). The
- client, on behalf of the directory user, interacts with one or more
- servers (or Directory System Agents (DSA)). A server holds a fragment
- of the DIB.
-
- The DIB contains two classes of information:
-
- 1) user information (e.g., information provided and administrated
- by users). Section 2 describes the Model of User Information.
-
- 2) administrative and operational information (e.g., information
- used to administer and/or operate the directory). Section 3
- describes the model of Directory Administrative and Operational
- Information.
-
- These two models, referred to as the generic Directory Information
- Models, describe how information is represented in the Directory.
- These generic models provide a framework for other information models.
- Section 4 discusses the subschema information model and subschema
- discovery. Section 5 discusses the DSA (Server) Informational Model.
-
- Other X.500 information models, such as access control distribution
- knowledge, and replication knowledge information models, may be
- adapted for use in LDAP. Specification of how these models apply to
- LDAP is left to future documents.
-
-
-1.1. Relationship to Other LDAP Specifications
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
-
-
-
-Zeilenga LDAP Models [Page 3]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- specification, RFC 3377, in its entirety.
-
- This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
- portions of sections 4 and 6. Appendix A.1 summarizes changes to
- these sections. The remainder of RFC 2251 is obsoleted by the
- [Protocol], [AuthMeth], and [Roadmap] documents.
-
- This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
- summarizes changes to these sections. The remainder of RFC 2252 is
- obsoleted by [Syntaxes].
-
- This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
- Appendix A.3 summarizes changes to these sections. The remainder of
- RFC 2256 is obsoleted by [Schema] and [Syntaxes].
-
- This document obsoletes RFC 3674 in its entirety. Appendix A.4
- summarizes changes since RFC 3674.
-
-
-1.2. Relationship to X.501
-
- This document includes material, with and without adaptation, from
- [X.501] as necessary to describe this protocol. These adaptations
- (and any other differences herein) apply to this protocol, and only
- this protocol.
-
-
-1.3. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Schema definitions are provided using LDAP description formats (as
- defined in Section 4.1). Definitions provided here are formatted
- (line wrapped) for readability. Matching rules and LDAP syntaxes
- referenced in these definitions are specified in [Syntaxes].
-
-
-1.4. Common ABNF Productions
-
- A number of syntaxes in this document are described using Augmented
- Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
- number of syntaxes defined in other documents) rely on the following
- common productions:
-
- keystring = leadkeychar *keychar
- leadkeychar = ALPHA
-
-
-
-Zeilenga LDAP Models [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- keychar = ALPHA / DIGIT / HYPHEN
- number = DIGIT / ( LDIGIT 1*DIGIT )
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- DIGIT = %x30 / LDIGIT ; "0"-"9"
- LDIGIT = %x31-39 ; "1"-"9"
- HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
-
- SP = 1*SPACE ; one or more " "
- WSP = 0*SPACE ; zero or more " "
-
- NULL = %x00 ; null (0)
- SPACE = %x20 ; space (" ")
- DQUOTE = %x22 ; quote (""")
- SHARP = %x23 ; octothorpe (or sharp sign) ("#")
- DOLLAR = %x24 ; dollar sign ("$")
- SQUOTE = %x27 ; single quote ("'")
- LPAREN = %x28 ; left paren ("(")
- RPAREN = %x29 ; right paren (")")
- PLUS = %x2B ; plus sign ("+")
- COMMA = %x2C ; comma (",")
- HYPHEN = %x2D ; hyphen ("-")
- DOT = %x2E ; period (".")
- SEMI = %x3B ; semicolon (";")
- LANGLE = %x3C ; left angle bracket ("<")
- EQUALS = %x3D ; equals sign ("=")
- RANGLE = %x3E ; right angle bracket (">")
- ESC = %x5C ; backslash ("\")
- USCORE = %x5F ; underscore ("_")
- LCURLY = %x7B ; left curly brace "{"
- RCURLY = %x7D ; right curly brace "}"
-
- ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
- UTF8 = UTF1 / UTFMB
- UTFMB = UTF2 / UTF3 / UTF4
- UTF0 = %x80-BF
- UTF1 = %x00-7F
- UTF2 = %xC2-DF UTF0
- UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
- %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
- UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
- %xF4 %x80-8F 2(UTF0)
-
- OCTET = %x00-FF ; Any octet (8-bit data unit)
-
- Object identifiers (OIDs) [X.680] are represented in LDAP using a
- dot-decimal format conforming to the ABNF:
-
-
-
-
-Zeilenga LDAP Models [Page 5]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- numericoid = number 1*( DOT number )
-
- Short names, also known as descriptors, are used as more readable
- aliases for object identifiers. Short names are case insensitive and
- conform to the ABNF:
-
- descr = keystring
-
- Where either an object identifier or a short name may be specified,
- the following production is used:
-
- oid = descr / numericoid
-
- While the <descr> form is generally preferred when the usage is
- restricted to short names referring to object identifiers which
- identify like kinds of objects (e.g., attribute type descriptions,
- matching rule descriptions, object class descriptions), the
- <numericoid> form should be used when the object identifiers may
- identify multiple kinds of objects or when an unambiguous short name
- (descriptor) is not available.
-
- Implementations SHOULD treat short names (descriptors) used in an
- ambiguous manner (as discussed above) as unrecognized.
-
- Short Names (descriptors) are discussed further in Section 6.2.
-
-
-2. Model of Directory User Information
-
- As [X.501] states:
-
- The purpose of the Directory is to hold, and provide access to,
- information about objects of interest (objects) in some 'world'.
- An object can be anything which is identifiable (can be named).
-
- An object class is an identified family of objects, or conceivable
- objects, which share certain characteristics. Every object belongs
- to at least one class. An object class may be a subclass of other
- object classes, in which case the members of the former class, the
- subclass, are also considered to be members of the latter classes,
- the superclasses. There may be subclasses of subclasses, etc., to
- an arbitrary depth.
-
- A directory entry, a named collection of information, is the basic
- unit of information held in the Directory. There are multiple kinds
- of directory entries.
-
- An object entry represents a particular object. An alias entry
-
-
-
-Zeilenga LDAP Models [Page 6]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- provides alternative naming. A subentry holds administrative and/or
- operational information.
-
- The set of entries representing the DIB are organized hierarchically
- in a tree structure known as the Directory Information Tree (DIT).
-
- Section 2.1 describes the Directory Information Tree
- Section 2.2 discusses the structure of entries.
- Section 2.3 discusses naming of entries.
- Section 2.4 discusses object classes.
- Section 2.5 discusses attribute descriptions.
- Section 2.6 discusses alias entries.
-
-
-2.1. The Directory Information Tree
-
- As noted above, the DIB is composed of a set of entries organized
- hierarchically in a tree structure known as the Directory Information
- Tree (DIT). Specifically, a tree where vertices are the entries.
-
- The arcs between vertices define relations between entries. If an arc
- exists from X to Y, then the entry at X is the immediate superior of Y
- and Y is the immediate subordinate of X. An entry's superiors are the
- entry's immediate superior and its superiors. An entry's subordinates
- are all of its immediate subordinates and their subordinates.
-
- Similarly, the superior/subordinate relationship between object
- entries can be used to derive a relation between the objects they
- represent. DIT structure rules can be used to govern relationships
- between objects.
-
- Note: An entry's immediate superior is also known as the entry's
- parent and an entry's immediate subordinate is also known as the
- entry's child. Entries which have the same parent are known as
- siblings.
-
-
-2.2. Structure of an Entry
-
- An entry consists of a set of attributes which hold information about
- the object which the entry represents. Some attributes represent user
- information and are called user attributes. Other attributes
- represent operational and/or administrative information and are called
- operational attributes.
-
- An attribute is an attribute description (a type and zero or more
- options) with one or more associated values. An attribute is often
- referred to by its attribute description. For example, the
-
-
-
-Zeilenga LDAP Models [Page 7]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- 'givenName' attribute is the attribute which consists of the attribute
- description 'givenName' (the 'givenName' attribute type [Schema] and
- zero options) and one or more associated values.
-
- The attribute type governs whether the attribute can have multiple
- values, the syntax and matching rules used to construct and compare
- values of that attribute, and other functions. Options indicate
- subtypes and other functions.
-
- Attribute values conform to the defined syntax of the attribute type.
-
- No two values of an attribute may be equivalent. Two values are
- considered equivalent if and only if they would match according to the
- equality matching rule of the attribute type or, if the attribute type
- is defined with no equality matching rule, two values are equivalent
- if and only if they are identical. (See 2.5.1 for other
- restrictions.)
-
- For example, a 'givenName' attribute can have more than one value,
- they must be Directory Strings, and they are case insensitive. A
- 'givenName' attribute cannot hold both "John" and "JOHN" as these are
- equivalent values per the equality matching rule of the attribute
- type.
-
- Additionally, no attribute is to have a value which is not equivalent
- to itself. For example, the 'givenName' attribute cannot have as a
- value a directory string which includes the REPLACEMENT CHARACTER
- (U+FFFD) code point as matching involving that directory string is
- Undefined per this attribute's equality matching rule.
-
- When an attribute is used for naming of the entry, one and only one
- value of the attribute is used in forming the Relative Distinguished
- Name. This value is known as a distinguished value.
-
-
-2.3. Naming of Entries
-
-2.3.1. Relative Distinguished Names
-
- Each entry is named relative to its immediate superior. This relative
- name, known as its Relative Distinguished Name (RDN) [X.501], is
- composed of an unordered set of one or more attribute value assertions
- (AVA) consisting of an attribute description with zero options and an
- attribute value. These AVAs are chosen to match attribute values
- (each a distinguished value) of the entry.
-
- An entry's relative distinguished name must be unique among all
- immediate subordinates of the entry's immediate superior (i.e., all
-
-
-
-Zeilenga LDAP Models [Page 8]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- siblings).
-
- The following are examples of string representations of RDNs [LDAPDN]:
-
- UID=12345
- OU=Engineering
- CN=Kurt Zeilenga+L=Redwood Shores
-
- The last is an example of a multi-valued RDN. That is, an RDN
- composed of multiple AVAs.
-
-
-2.3.2. Distinguished Names
-
- An entry's fully qualified name, known as its Distinguished Name (DN)
- [X.501], is the concatenation of its RDN and its immediate superior's
- DN. A Distinguished Name unambiguously refers to an entry in the
- tree. The following are examples of string representations of DNs
- [LDAPDN]:
-
- UID=nobody@example.com,DC=example,DC=com
- CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
-
-
-2.3.3. Alias Names
-
- An alias, or alias name, is "an name for an object, provided by the
- use of alias entries" [X.501]. Alias entries are described in Section
- 2.6.
-
-
-2.4. Object Classes
-
- An object class is "an identified family of objects (or conceivable
- objects) which share certain characteristics" [X.501].
-
- As defined in [X.501]:
-
- Object classes are used in the Directory for a number of purposes:
-
- - describing and categorising objects and the entries that
- correspond to these objects;
-
- - where appropriate, controlling the operation of the Directory;
-
- - regulating, in conjunction with DIT structure rule
- specifications, the position of entries in the DIT;
-
-
-
-
-Zeilenga LDAP Models [Page 9]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- - regulating, in conjunction with DIT content rule
- specifications, the attributes that are contained in entries;
-
- - identifying classes of entry that are to be associated with a
- particular policy by the appropriate administrative authority.
-
- An object class (a subclass) may be derived from an object class
- (its direct superclass) which is itself derived from an even more
- generic object class. For structural object classes, this process
- stops at the most generic object class, 'top' (defined in Section
- 2.4.1). An ordered set of superclasses up to the most superior
- object class of an object class is its superclass chain.
-
- An object class may be derived from two or more direct
- superclasses (superclasses not part of the same superclass chain).
- This feature of subclassing is termed multiple inheritance.
-
- Each object class identifies the set of attributes required to be
- present in entries belonging to the class and the set of attributes
- allowed to be present in entries belonging to the class. As an entry
- of a class must meet the requirements of each class it belongs to, it
- can be said that an object class inherits the sets of allowed and
- required attributes from its superclasses. A subclass can identify an
- attribute allowed by its superclass as being required. If an
- attribute is a member of both sets, it is required to be present.
-
- Each object class is defined to be one of three kinds of object
- classes: Abstract, Structural, or Auxiliary.
-
- Each object class is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
-
-2.4.1. Abstract Object Classes
-
- An abstract object class, as the name implies, provides a base of
- characteristics from which other object classes can be defined to
- inherit from. An entry cannot belong to an abstract object class
- unless it belongs to a structural or auxiliary class which inherits
- from that abstract class.
-
- Abstract object classes can not derive from structural nor auxiliary
- object classes.
-
- All structural object classes derive (directly or indirectly) from the
- 'top' abstract object class. Auxiliary object classes do not
- necessarily derive from 'top'.
-
-
-
-
-Zeilenga LDAP Models [Page 10]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The following is the object class definition (see Section 4.1.1) for
- the 'top' object class:
-
- ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
- All entries belong to the 'top' abstract object class.
-
-
-2.4.2. Structural Object Classes
-
- As stated in [X.501]:
-
- An object class defined for use in the structural specification of
- the DIT is termed a structural object class. Structural object
- classes are used in the definition of the structure of the names
- of the objects for compliant entries.
-
- An object or alias entry is characterised by precisely one
- structural object class superclass chain which has a single
- structural object class as the most subordinate object class.
- This structural object class is referred to as the structural
- object class of the entry.
-
- Structural object classes are related to associated entries:
-
- - an entry conforming to a structural object class shall
- represent the real-world object constrained by the object
- class;
-
- - DIT structure rules only refer to structural object classes;
- the structural object class of an entry is used to specify the
- position of the entry in the DIT;
-
- - the structural object class of an entry is used, along with an
- associated DIT content rule, to control the content of an
- entry.
-
- The structural object class of an entry shall not be changed.
-
- Each structural object class is a (direct or indirect) subclass of the
- 'top' abstract object class.
-
- Structural object classes cannot subclass auxiliary object classes.
-
- Each entry is said to belong to its structural object class as well as
- all classes in its structural object class's superclass chain.
-
-
-
-
-
-Zeilenga LDAP Models [Page 11]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.4.3. Auxiliary Object Classes
-
- Auxiliary object classes are used to augment the characteristics of
- entries. They are commonly used to augment the sets of attributes
- required and allowed to be present in an entry. They can be used to
- describe entries or classes of entries.
-
- Auxiliary object classes cannot subclass structural object classes.
-
- An entry can belong to any subset of the set of auxiliary object
- classes allowed by the DIT content rule associated with the structural
- object class of the entry. If no DIT content rule is associated with
- the structural object class of the entry, the entry cannot belong to
- any auxiliary object class.
-
- The set of auxiliary object classes which an entry belongs to can
- change over time.
-
-
-2.5. Attribute Descriptions
-
- An attribute description is composed of an attribute type (see Section
- 2.5.1) and a set of zero or more attribute options (see Section
- 2.5.2).
-
- An attribute description is represented by the ABNF:
-
- attributedescription = attributetype options
- attributetype = oid
- options = *( SEMI option )
- option = 1*keychar
-
- where <attributetype> identifies the attribute type and each <option>
- identifies an attribute option. Both <attributetype> and <option>
- productions are case insensitive. The order in which <option>s appear
- is irrelevant. That is, any two <attributedescription>s which consist
- of the same <attributetype> and same set of <option>s are equivalent.
-
- Examples of valid attribute descriptions:
-
- 2.5.4.0
- cn;lang-de;lang-en
- owner
-
- An attribute description with an unrecognized attribute type is to be
- treated as unrecognized. Servers SHALL treat an attribute description
- with an unrecognized attribute option as unrecognized. Clients MAY
- treat an unrecognized attribute option as a tagging option (see
-
-
-
-Zeilenga LDAP Models [Page 12]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Section 2.5.2.1).
-
- All attributes of an entry must have distinct attribute descriptions.
-
-
-2.5.1. Attribute Types
-
- An attribute type governs whether the attribute can have multiple
- values, the syntax and matching rules used to construct and compare
- values of that attribute, and other functions.
-
- If no equality matching is specified for the attribute type:
- - the attribute (of the type) cannot be used for naming;
- - when adding the attribute (or replacing all values), no two values
- may be equivalent (see 2.2);
- - individual values of a multi-valued attribute are not to be
- independently added or deleted;
- - attribute value assertions (such as matching in search filters and
- comparisons) using values of such a type cannot be performed.
-
- Otherwise, the specified equality matching rule is to be used for the
- purposes of evaluating attribute value assertions concerning the
- attribute type. The specified equality rule is to be transitive and
- commutative.
-
- The attribute type indicates whether the attribute is a user attribute
- or an operational attribute. If operational, the attribute type
- indicates the operational usage and whether the attribute is
- modifiable by users or not. Operational attributes are discussed in
- Section 3.4.
-
- An attribute type (a subtype) may derive from a more generic attribute
- type (a direct supertype). The following restrictions apply to
- subtyping:
- - a subtype must have the same usage as its direct supertype,
- - a subtype's syntax must be the same, or a refinement of, its
- supertype's syntax, and
- - a subtype must be collective [RFC3671] if its supertype is
- collective.
-
- An attribute description consisting of a subtype and no options is
- said to be the direct description subtype of the attribute description
- consisting of the subtype's direct supertype and no options.
-
- Each attribute type is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
-
-
-
-
-Zeilenga LDAP Models [Page 13]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.5.2. Attribute Options
-
- There are multiple kinds of attribute description options. The LDAP
- technical specification details one kind: tagging options.
-
- Not all options can be associated with attributes held in the
- directory. Tagging options can be.
-
- Not all options can be used in conjunction with all attribute types.
- In such cases, the attribute description is to be treated as
- unrecognized.
-
- An attribute description that contains mutually exclusive options
- shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
- "x-foo" and "x-bar" are mutually exclusive, is to be treated as
- unrecognized.
-
- Other kinds of options may be specified in future documents. These
- documents must detail how new kinds of options they define relate to
- tagging options. In particular, these documents must detail whether
- or not new kinds of options can be associated with attributes held in
- the directory, how new kinds of options affect transfer of attribute
- values, and how new kinds of options are treated in attribute
- description hierarchies.
-
- Options are represented as short case insensitive textual strings
- conforming to the <option> production defined in Section 2.5 of this
- document.
-
- Procedures for registering options are detailed in BCP 64 [BCP64bis].
-
-
-2.5.2.1. Tagging Options
-
- Attributes held in the directory can have attribute descriptions with
- any number of tagging options. Tagging options are never mutually
- exclusive.
-
- An attribute description with N tagging options is a direct
- (description) subtype of all attribute descriptions of the same
- attribute type and all but one of the N options. If the attribute
- type has a supertype, then the attribute description is also a direct
- (description) subtype of the attribute description of the supertype
- and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
- (description) subtype of 'cn;lang-de', 'cn;lang-en', and
- 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
- in [Schema]).
-
-
-
-
-Zeilenga LDAP Models [Page 14]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.5.3. Attribute Description Hierarchies
-
- An attribute description can be the direct subtype of zero or more
- other attribute descriptions as indicated by attribute type subtyping
- (as described in Section 2.5.1) or attribute tagging option subtyping
- (as described in Section 2.5.2.1). These subtyping relationships are
- used to form hierarchies of attribute descriptions and attributes.
-
- As adapted from [X.501]:
-
- Attribute hierarchies allow access to the DIB with varying degrees
- of granularity. This is achieved by allowing the value components
- of attributes to be accessed by using either their specific
- attribute description (a direct reference to the attribute) or by
- a more generic attribute description (an indirect reference).
-
- Semantically related attributes may be placed in a hierarchical
- relationship, the more specialized being placed subordinate to the
- more generalized. Searching for, or retrieving attributes and
- their values is made easier by quoting the more generalized
- attribute description; a filter item so specified is evaluated for
- the more specialized descriptions as well as for the quoted
- description.
-
- Where subordinate specialized descriptions are selected to be
- returned as part of a search result these descriptions shall be
- returned if available. Where the more general descriptions are
- selected to be returned as part of a search result both the
- general and the specialized descriptions shall be returned, if
- available. An attribute value shall always be returned as a value
- of its own attribute description.
-
- All of the attribute descriptions in an attribute hierarchy are
- treated as distinct and unrelated descriptions for user
- modification of entry content.
-
- An attribute value stored in an object or alias entry is of
- precisely one attribute description. The description is indicated
- when the value is originally added to the entry.
-
- For the purpose of subschema administration of the entry, a
- specification that an attribute is required is fulfilled if the entry
- contains a value of an attribute description belonging to an attribute
- hierarchy where the attribute type of that description is the same as
- the required attribute's type. That is, a "MUST name" specification
- is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
- 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
- 'name'). Likewise, an entry may contain a value of an attribute
-
-
-
-Zeilenga LDAP Models [Page 15]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- description belonging to an attribute hierarchy where the attribute
- type of that description is either explicitly included in the
- definition of an object class to which the entry belongs or allowed by
- the DIT content rule applicable to that entry. That is, 'name' and
- 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
- 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
- name").
-
- For the purposes of other policy administration, unless stated
- otherwise in the specification of the particular administrative model,
- all of the attribute descriptions in an attribute hierarchy are
- treated as distinct and unrelated descriptions.
-
-
-2.6. Alias Entries
-
- As adapted from [X.501]:
-
- An alias, or an alias name, for an object is an alternative name
- for an object or object entry which is provided by the use of
- alias entries.
-
- Each alias entry contains, within the 'aliasedObjectName'
- attribute (known as the 'aliasedEntryName' attribute in X.500]), a
- name of some object. The distinguished name of the alias entry is
- thus also a name for this object.
-
- NOTE - The name within the 'aliasedObjectName' is said to be
- pointed to by the alias. It does not have to be the
- distinguished name of any entry.
-
- The conversion of an alias name to an object name is termed
- (alias) dereferencing and comprises the systematic replacement of
- alias names, where found within a purported name, by the value of
- the corresponding 'aliasedObjectName' attribute. The process may
- require the examination of more than one alias entry.
-
- Any particular entry in the DIT may have zero or more alias names.
- It therefore follows that several alias entries may point to the
- same entry. An alias entry may point to an entry that is not a
- leaf entry and may point to another alias entry.
-
- An alias entry shall have no subordinates, so that an alias entry
- is always a leaf entry.
-
- Every alias entry shall belong to the 'alias' object class.
-
- An entry with the 'alias' object class must also belong to an object
-
-
-
-Zeilenga LDAP Models [Page 16]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- class (or classes), or be governed by a DIT content rule, which allows
- suitable naming attributes to be present.
-
- Example:
- dn: cn=bar,dc=example,dc=com
- objectClass: top
- objectClass: alias
- objectClass: extensibleObject
- cn: bar
- aliasedObjectName: cn=foo,dc=example,dc=com
-
-
-2.6.1. 'alias' object class
-
- Alias entries belong to the 'alias' object class.
-
- ( 2.5.6.1 NAME 'alias'
- SUP top STRUCTURAL
- MUST aliasedObjectName )
-
-
-2.6.2. 'aliasedObjectName' attribute type
-
- The 'aliasedObjectName' attribute holds the name of the entry an alias
- points to. The 'aliasedObjectName' attribute is known as the
- 'aliasedEntryName' attribute in X.500.
-
- ( 2.5.4.1 NAME 'aliasedObjectName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3. Directory Administrative and Operational Information
-
- This section discusses select aspects of the X.500 Directory
- Administrative and Operational Information model [X.501]. LDAP
- implementations MAY support other aspects of this model.
-
-
-3.1. Subtrees
-
- As defined in [X.501]:
-
- A subtree is a collection of object and alias entries situated at
-
-
-
-Zeilenga LDAP Models [Page 17]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- the vertices of a tree. Subtrees do not contain subentries. The
- prefix sub, in subtree, emphasizes that the base (or root) vertex
- of this tree is usually subordinate to the root of the DIT.
-
- A subtree begins at some vertex and extends to some identifiable
- lower boundary, possibly extending to leaves. A subtree is always
- defined within a context which implicitly bounds the subtree. For
- example, the vertex and lower boundaries of a subtree defining a
- replicated area are bounded by a naming context.
-
-
-3.2. Subentries
-
- A subentry is a "special sort of entry, known by the Directory, used
- to hold information associated with a subtree or subtree refinement"
- [X.501]. Subentries are used in Directory to hold for administrative
- and operational purposes as defined in [X.501]. Their use in LDAP is
- detailed in [RFC3672].
-
- The term "(sub)entry" in this specification indicates that servers
- implementing X.500(93) models are, in accordance with X.500(93) as
- described in [RFC3672], to use a subentry and that other servers are
- to use an object entry belonging to the appropriate auxiliary class
- normally used with the subentry (e.g., 'subschema' for subschema
- subentries) to mimic the subentry. This object entry's RDN SHALL be
- formed from a value of the 'cn' (commonName) attribute [Schema] (as
- all subentries are named with 'cn').
-
-
-3.3. The 'objectClass' attribute
-
- Each entry in the DIT has an 'objectClass' attribute.
-
- ( 2.5.4.0 NAME 'objectClass'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
- (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
-
- The 'objectClass' attribute specifies the object classes of an entry,
- which (among other things) is used in conjunction with the controlling
- schema to determine the permitted attributes of an entry. Values of
- this attribute can be modified by clients, but the 'objectClass'
- attribute cannot be removed.
-
- Servers which follow X.500(93) models SHALL restrict modifications of
- this attribute to prevent the basic structural class of the entry from
-
-
-
-Zeilenga LDAP Models [Page 18]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- being changed. That is, 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 SHALL be implicitly added as
- well if not already present. That is, if the auxiliary class 'x-a' is
- a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
- 'x-b' to be implicitly added (if is not already present).
-
- Servers SHALL restrict modifications of this attribute to prevent
- superclasses of remaining 'objectClass' values from being deleted.
- That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
- class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
- an attempt to delete only 'x-b' from the 'objectClass' attribute is an
- error.
-
-
-3.4. Operational attributes
-
- Some attributes, termed operational attributes, are used or maintained
- by servers for administrative and operational purposes. As stated in
- [X.501]: "There are three varieties of operational attributes:
- Directory operational attributes, DSA-shared operational attributes,
- and DSA-specific operational attributes."
-
- A directory operational attribute is used to represent operational
- and/or administrative information in the Directory Information Model.
- This includes operational attributes maintained by the server (e.g.
- 'createTimestamp') as well as operational attributes which hold values
- administrated by the user (e.g. 'ditContentRules').
-
- A DSA-shared operational attribute is used to represent information of
- the DSA Information Model which is shared between DSAs.
-
- A DSA-specific operational attribute is used to represent information
- of the DSA Information Model which is specific to the DSA (though, in
- some cases, may be derived from information shared between DSAs)
- (e.g., 'namingContexts').
-
- The DSA Information Model operational attributes are detailed in
- [X.501].
-
- Operational attributes are not normally visible. They are not
- returned in search results unless explicitly requested by name.
-
- Not all operational attributes are user modifiable.
-
- Entries may contain, among others, the following operational
-
-
-
-Zeilenga LDAP Models [Page 19]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- attributes:
-
- - 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, and
-
- - modifyTimestamp: the time this entry was last modified.
-
- Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
- 'modifiersName', and 'modifyTimestamp' attributes for all entries of
- the DIT.
-
-
-3.4.1. 'creatorsName'
-
- This attribute appears in entries which were added using the protocol
- (e.g., using the Add operation). The value is the distinguished name
- of the creator.
-
- ( 2.5.18.3 NAME 'creatorsName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3.4.2. 'createTimestamp'
-
- This attribute appears in entries which were added using the protocol
- (e.g., using the Add operation). The value is the time the entry was
- added.
-
- ( 2.5.18.1 NAME 'createTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
- rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
-
-
-
-Zeilenga LDAP Models [Page 20]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- are defined in [Syntaxes].
-
-
-3.4.3. 'modifiersName'
-
- This attribute appears in entries which have been modified using the
- protocol (e.g., using Modify operation). The value is the
- distinguished name of the last modifier.
-
- ( 2.5.18.4 NAME 'modifiersName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3.4.4. 'modifyTimestamp'
-
- This attribute appears in entries which have been modified using the
- protocol (e.g., using the Modify operation). The value is the time
- the entry was last modified.
-
- ( 2.5.18.2 NAME 'modifyTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
- rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
- are defined in [Syntaxes].
-
-
-3.4.5. 'structuralObjectClass'
-
- This attribute indicates the structural object class of the entry.
-
- ( 2.5.21.9 NAME 'structuralObjectClass'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
-
-
-
-Zeilenga LDAP Models [Page 21]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
-
-
-3.4.6. 'governingStructureRule'
-
- This attribute indicates the structure rule governing the entry.
-
- ( 2.5.21.10 NAME 'governingStructureRule'
- EQUALITY integerMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'integerMatch' matching rule and INTEGER
- (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
-
-
-4. Directory Schema
-
- As defined in [X.501]:
-
- The Directory Schema is a set of definitions and constraints
- concerning the structure of the DIT, the possible ways entries are
- named, the information that can be held in an entry, the
- attributes used to represent that information and their
- organization into hierarchies to facilitate search and retrieval
- of the information and the ways in which values of attributes may
- be matched in attribute value and matching rule assertions.
-
- NOTE 1 - The schema enables the Directory system to, for example:
-
- - prevent the creation of subordinate entries of the wrong
- object-class (e.g. a country as a subordinate of a person);
-
- - prevent the addition of attribute-types to an entry
- inappropriate to the object-class (e.g. a serial number to a
- person's entry);
-
- - prevent the addition of an attribute value of a syntax not
- matching that defined for the attribute-type (e.g. a printable
- string to a bit string).
-
- Formally, the Directory Schema comprises a set of:
-
- a) Name Form definitions that define primitive naming relations
- for structural object classes;
-
- b) DIT Structure Rule definitions that define the names that
-
-
-
-Zeilenga LDAP Models [Page 22]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- entries may have and the ways in which the entries may be
- related to one another in the DIT;
-
- c) DIT Content Rule definitions that extend the specification of
- allowable attributes for entries beyond those indicated by the
- structural object classes of the entries;
-
- d) Object Class definitions that define the basic set of mandatory
- and optional attributes that shall be present, and may be
- present, respectively, in an entry of a given class, and which
- indicate the kind of object class that is being defined;
-
- e) Attribute Type definitions that identify the object identifier
- by which an attribute is known, its syntax, associated matching
- rules, whether it is an operational attribute and if so its
- type, whether it is a collective attribute, whether it is
- permitted to have multiple values and whether or not it is
- derived from another attribute type;
-
- f) Matching Rule definitions that define matching rules.
-
- And in LDAP:
-
- g) LDAP Syntax definitions that define encodings used in LDAP.
-
-
-4.1. Schema Definitions
-
- Schema definitions in this section are described using ABNF and rely
- on the common productions specified in Section 1.2 as well as these:
-
- noidlen = numericoid [ LCURLY len RCURLY ]
- len = number
-
- oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
- oidlist = oid *( WSP DOLLAR WSP oid )
-
- extensions = *( SP xstring SP qdstrings )
- xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
-
- qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
- qdescrlist = [ qdescr *( SP qdescr ) ]
- qdescr = SQUOTE descr SQUOTE
-
- qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
- qdstringlist = [ qdstring *( SP qdstring ) ]
- qdstring = SQUOTE dstring SQUOTE
- dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
-
-
-
-Zeilenga LDAP Models [Page 23]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- QQ = ESC %x32 %x37 ; "\27"
- QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
-
- ; Any UTF-8 encoded Unicode character
- ; except %x27 ("'") and %x5C ("\")
- QUTF8 = QUTF1 / UTFMB
-
- ; Any ASCII character except %x27 ("'") and %x5C ("\")
- QUTF1 = %x00-26 / %x28-5B / %x5D-7F
-
- Schema definitions in this section also share a number of common
- terms.
-
- The NAME field provides a set of short names (descriptors) which are
- to be used as aliases for the OID.
-
- The DESC field optionally allows a descriptive string to be provided
- by the directory administrator and/or implementor. While
- specifications may suggest a descriptive string, there is no
- requirement that the suggested (or any) descriptive string be used.
-
- The OBSOLETE field, if present, indicates the element is not active.
-
- Implementors should note that future versions of this document may
- expand these definitions to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
- are followed by <SP> and <qdstrings> tokens.
-
-
-4.1.1. Object Class Definitions
-
- Object Class definitions are written according to the ABNF:
-
- ObjectClassDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "SUP" SP oids ] ; superior object classes
- [ SP kind ] ; kind of class
- [ SP "MUST" SP oids ] ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- extensions WSP RPAREN
-
- kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
-
- where:
- <numericoid> is object identifier assigned to this object class;
-
-
-
-Zeilenga LDAP Models [Page 24]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- NAME <qdescrs> are short names (descriptors) identifying this object
- class;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this object class is not active;
- SUP <oids> specifies the direct superclasses of this object class;
- the kind of object class is indicated by one of ABSTRACT,
- STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
- MUST and MAY specify the sets of required and allowed attribute
- types, respectively; and
- <extensions> describe extensions.
-
-
-4.1.2. Attribute Types
-
- Attribute Type definitions are written according to the ABNF:
-
- AttributeTypeDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "SUP" SP oid ] ; supertype
- [ SP "EQUALITY" SP oid ] ; equality matching rule
- [ SP "ORDERING" SP oid ] ; ordering matching rule
- [ SP "SUBSTR" SP oid ] ; substrings matching rule
- [ SP "SYNTAX" SP noidlen ] ; value syntax
- [ SP "SINGLE-VALUE" ] ; single-value
- [ SP "COLLECTIVE" ] ; collective
- [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
- [ SP "USAGE" SP usage ] ; usage
- extensions WSP RPAREN ; extensions
-
- usage = "userApplications" / ; user
- "directoryOperation" / ; directory operational
- "distributedOperation" / ; DSA-shared operational
- "dSAOperation" ; DSA-specific operational
-
- where:
- <numericoid> is object identifier assigned to this attribute type;
- NAME <qdescrs> are short names (descriptors) identifying this
- attribute type;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this attribute type is not active;
- SUP oid specifies the direct supertype of this type;
- EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
- ordering, and substrings matching rules, respectively;
- SYNTAX identifies value syntax by object identifier and may suggest
- a minimum upper bound;
-
-
-
-Zeilenga LDAP Models [Page 25]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- SINGLE-VALUE indicates attributes of this type are restricted to a
- single value;
- COLLECTIVE indicates this attribute type is collective
- [X.501][RFC3671];
- NO-USER-MODIFICATION indicates this attribute type is not user
- modifiable;
- USAGE indicates the application of this attribute type; and
- <extensions> describe extensions.
-
- Each attribute type description must contain at least one of the SUP
- or SYNTAX fields. If no SYNTAX field is provided, the attribute type
- description takes its value from the supertype.
-
- If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
- fields, if not specified, take their value from the supertype.
-
- Usage of userApplications, the default, indicates that attributes of
- this type represent user information. That is, they are user
- attributes.
-
- A usage of directoryOperation, distributedOperation, or dSAOperation
- indicates that attributes of this type represent operational and/or
- administrative information. That is, they are operational attributes.
-
- directoryOperation usage indicates that the attribute of this type is
- a directory operational attribute. distributedOperation usage
- indicates that the attribute of this DSA-shared usage operational
- attribute. dSAOperation usage indicates that the attribute of this
- type is a DSA-specific operational attribute.
-
- COLLECTIVE requires usage userApplications. Use of collective
- attribute types in LDAP is discussed in [RFC3671].
-
- NO-USER-MODIFICATION requires an operational usage.
-
- Note that the <AttributeTypeDescription> does not list the matching
- rules which can be used with that attribute type in an extensibleMatch
- search filter [Protocol]. This is done using the 'matchingRuleUse'
- attribute described in Section 4.1.4.
-
- This document refines the schema description of X.501 by requiring
- that the SYNTAX field in an <AttributeTypeDescription> be a string
- representation of an object identifier for the LDAP string syntax
- definition with an optional indication of the suggested minimum bound
- of a value of this attribute.
-
- A suggested minimum upper bound on the number of characters in a value
- with a string-based syntax, or the number of bytes in a value for all
-
-
-
-Zeilenga LDAP Models [Page 26]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- other syntaxes, may be indicated by appending this bound count inside
- of curly braces following the syntax's OBJECT IDENTIFIER in an
- Attribute Type Description. This bound is not part of the syntax name
- itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
- implementations should allow a string to be 64 characters long,
- although they may allow longer strings. Note that a single character
- of the Directory String syntax may be encoded in more than one octet
- since UTF-8 [RFC3629] is a variable-length encoding.
-
-
-4.1.3. Matching Rules
-
- Matching rules are used in performance of attribute value assertions,
- such as in performance of a Compare operation. They are also used in
- evaluation of a Search filters, in determining which individual values
- are be added or deleted during performance of a Modify operation, and
- used in comparison of distinguished names.
-
- Each matching rule is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
- Matching rule definitions are written according to the ABNF:
-
- MatchingRuleDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "SYNTAX" SP numericoid ; assertion syntax
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is object identifier assigned to this matching rule;
- NAME <qdescrs> are short names (descriptors) identifying this
- matching rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this matching rule is not active;
- SYNTAX identifies the assertion syntax (the syntax of the assertion
- value) by object identifier; and
- <extensions> describe extensions.
-
-
-4.1.4. Matching Rule Uses
-
- A matching rule use lists the attribute types which are suitable for
- use with an extensibleMatch search filter.
-
- Matching rule use descriptions are written according to the following
-
-
-
-Zeilenga LDAP Models [Page 27]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- ABNF:
-
- MatchingRuleUseDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "APPLIES" SP oids ; attribute types
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier of the matching rule
- associated with this matching rule use description;
- NAME <qdescrs> are short names (descriptors) identifying this
- matching rule use;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this matching rule use is not active;
- APPLIES provides a list of attribute types the matching rule applies
- to; and
- <extensions> describe extensions.
-
-
-4.1.5. LDAP Syntaxes
-
- LDAP Syntaxes of (attribute and assertion) values are described in
- terms of ASN.1 [X.680] and, optionally, have an octet string encoding
- known as the LDAP-specific encoding. Commonly, the LDAP-specific
- encoding is constrained to a string of Unicode [Unicode] characters in
- UTF-8 [RFC3629] form.
-
- Each LDAP syntax is identified by an object identifier (OID).
-
- LDAP syntax definitions are written according to the ABNF:
-
- SyntaxDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "DESC" SP qdstring ] ; description
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier assigned to this LDAP syntax;
- DESC <qdstring> is a short descriptive string; and
- <extensions> describe extensions.
-
-
-4.1.6. DIT Content Rules
-
- A DIT content rule is a "rule governing the content of entries of a
-
-
-
-Zeilenga LDAP Models [Page 28]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- particular structural object class" [X.501].
-
- For DIT entries of a particular structural object class, a DIT content
- rule specifies which auxiliary object classes the entries are allowed
- to belong to and which additional attributes (by type) are required,
- allowed or not allowed to appear in the entries.
-
- The list of precluded attributes cannot include any attribute listed
- as mandatory in the rule, the structural object class, or any of the
- allowed auxiliary object classes.
-
- Each content rule is identified by the object identifier, as well as
- any short names (descriptors), of the structural object class it
- applies to.
-
- An entry may only belong to auxiliary object classes listed in the
- governing content rule.
-
- An entry must contain all attributes required by the object classes
- the entry belongs to as well as all attributes required by the
- governing content rule.
-
- An entry may contain any non-precluded attributes allowed by the
- object classes the entry belongs to as well as all attributes allowed
- by the governing content rule.
-
- An entry cannot include any attribute precluded by the governing
- content rule.
-
- An entry is governed by (if present and active in the subschema) the
- DIT content rule which applies to the structural object class of the
- entry (see Section 2.4.2). If no active rule is present for the
- entry's structural object class, the entry's content is governed by
- the structural object class (and possibly other aspects of user and
- system schema). DIT content rules for superclasses of the structural
- object class of an entry are not applicable to that entry.
-
- DIT content rule descriptions are written according to the ABNF:
-
- DITContentRuleDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "AUX" SP oids ] ; auxiliary object classes
- [ SP "MUST" SP oids ] ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- [ SP "NOT" SP oids ] ; attribute types
-
-
-
-Zeilenga LDAP Models [Page 29]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier of the structural object class
- associated with this DIT content rule;
- NAME <qdescrs> are short names (descriptors) identifying this DIT
- content rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this DIT content rule use is not active;
- AUX specifies a list of auxiliary object classes which entries
- subject to this DIT content rule may belong to;
- MUST, MAY, and NOT specify lists of attribute types which are
- required, allowed, or precluded, respectively, from appearing in
- entries subject to this DIT content rule; and
- <extensions> describe extensions.
-
-
-4.1.7. DIT Structure Rules and Name Forms
-
- It is sometimes desirable to regulate where object and alias entries
- can be placed in the DIT and how they can be named based upon their
- structural object class.
-
-
-4.1.7.1. DIT Structure Rules
-
- A DIT structure rule is a "rule governing the structure of the DIT by
- specifying a permitted superior to subordinate entry relationship. A
- structure rule relates a name form, and therefore a structural object
- class, to superior structure rules. This permits entries of the
- structural object class identified by the name form to exist in the
- DIT as subordinates to entries governed by the indicated superior
- structure rules" [X.501].
-
- DIT structure rule descriptions are written according to the ABNF:
-
- DITStructureRuleDescription = LPAREN WSP
- ruleid ; rule identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "FORM" SP oid ; NameForm
- [ SP "SUP" ruleids ] ; superior rules
- extensions WSP RPAREN ; extensions
-
- ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
- ruleidlist = ruleid *( SP ruleid )
- ruleid = number
-
-
-
-Zeilenga LDAP Models [Page 30]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- where:
- <ruleid> is the rule identifier of this DIT structure rule;
- NAME <qdescrs> are short names (descriptors) identifying this DIT
- structure rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this DIT structure rule use is not active;
- FORM is specifies the name form associated with this DIT structure
- rule;
- SUP identifies superior rules (by rule id); and
- <extensions> describe extensions.
-
- If no superior rules are identified, the DIT structure rule applies
- to an autonomous administrative point (e.g. the root vertex of the
- subtree controlled by the subschema) [X.501].
-
-
-4.1.7.2. Name Forms
-
- A name form "specifies a permissible RDN for entries of a particular
- structural object class. A name form identifies a named object
- class and one or more attribute types to be used for naming (i.e.
- for the RDN). Name forms are primitive pieces of specification
- used in the definition of DIT structure rules" [X.501].
-
- Each name form indicates the structural object class to be named,
- a set of required attribute types, and a set of allowed attribute
- types. A particular attribute type cannot be in both sets.
-
- Entries governed by the form must be named using a value from each
- required attribute type and zero or more values from the allowed
- attribute types.
-
- Each name form is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
- Name form descriptions are written according to the ABNF:
-
- NameFormDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "OC" SP oid ; structural object class
- SP "MUST" SP oids ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- extensions WSP RPAREN ; extensions
-
- where:
-
-
-
-Zeilenga LDAP Models [Page 31]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- <numericoid> is object identifier which identifies this name form;
- NAME <qdescrs> are short names (descriptors) identifying this name
- form;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this name form is not active;
- OC identifies the structural object class this rule applies to,
- MUST and MAY specify the sets of required and allowed, respectively,
- naming attributes for this name form; and
- <extensions> describe extensions.
-
- All attribute types in the required ("MUST") and allowed ("MAY") lists
- shall be different.
-
-
-4.2. Subschema Subentries
-
- Subschema (sub)entries are used for administering information about
- the directory schema. A single subschema (sub)entry contains all
- schema definitions (see Section 4.1) 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 (as detailed in Section 12 of [X.501]),
- and so these are not ordinary object entries but subentries (see
- Section 3.2). LDAP clients SHOULD NOT assume that servers implement
- any of the other aspects of X.500 subschema.
-
- Servers MAY allow subschema modification. Procedures for subschema
- modification are discussed in Section 14.5 of [X.501].
-
- A server which masters entries and permits clients to modify these
- entries SHALL implement and provide access to these subschema
- (sub)entries including providing a 'subschemaSubentry' attribute in
- each modifiable entry. This is so 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 value of the 'subschemaSubentry' attribute is the name of the
- subschema (sub)entry holding the subschema controlling the entry.
-
- ( 2.5.18.10 NAME 'subschemaSubentry'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- NO-USER-MODIFICATION SINGLE-VALUE
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-
-Zeilenga LDAP Models [Page 32]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Subschema is held in (sub)entries belonging to the subschema auxiliary
- object class.
-
- ( 2.5.20.1 NAME 'subschema' AUXILIARY
- MAY ( dITStructureRules $ nameForms $ ditContentRules $
- objectClasses $ attributeTypes $ matchingRules $
- matchingRuleUse ) )
-
- The 'ldapSyntaxes' operational attribute may also be present in
- subschema entries.
-
- Servers MAY provide additional attributes (described in other
- documents) in subschema (sub)entries.
-
- Servers SHOULD provide the attributes 'createTimestamp' and
- 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
- to maintain their caches of schema information.
-
- The following subsections provide attribute type definitions for each
- of schema definition attribute types.
-
-
-4.2.1. 'objectClasses'
-
- This attribute holds definitions of object classes.
-
- ( 2.5.21.6 NAME 'objectClasses'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
- defined in [Syntaxes].
-
-
-4.2.2. 'attributeTypes'
-
- This attribute holds definitions of attribute types.
-
- ( 2.5.21.5 NAME 'attributeTypes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
- defined in [Syntaxes].
-
-
-
-Zeilenga LDAP Models [Page 33]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-4.2.3. 'matchingRules'
-
- This attribute holds definitions of matching rules.
-
- ( 2.5.21.4 NAME 'matchingRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
- defined in [Syntaxes].
-
-
-4.2.4 'matchingRuleUse'
-
- This attribute holds definitions of matching rule uses.
-
- ( 2.5.21.8 NAME 'matchingRuleUse'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
- defined in [Syntaxes].
-
-
-4.2.5. 'ldapSyntaxes'
-
- This attribute holds definitions of LDAP syntaxes.
-
- ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
- in [Syntaxes].
-
-
-4.2.6. 'dITContentRules'
-
- This attribute lists DIT Content Rules which are present in the
- subschema.
-
- ( 2.5.21.2 NAME 'dITContentRules'
-
-
-
-Zeilenga LDAP Models [Page 34]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
- defined in [Syntaxes].
-
-
-4.2.7. 'dITStructureRules'
-
- This attribute lists DIT Structure Rules which are present in the
- subschema.
-
- ( 2.5.21.1 NAME 'dITStructureRules'
- EQUALITY integerFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
- USAGE directoryOperation )
-
- The 'integerFirstComponentMatch' matching rule and the
- DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
- defined in [Syntaxes].
-
-
-4.2.8 'nameForms'
-
- This attribute lists Name Forms which are in force.
-
- ( 2.5.21.7 NAME 'nameForms'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
- in [Syntaxes].
-
-
-4.3. 'extensibleObject' object class
-
- The 'extensibleObject' auxiliary object class allows entries that
- belong to it to hold any user attribute. The set of allowed attribute
- types of this object class is implicitly the set of all attribute
- types of userApplications usage.
-
- ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
- SUP top AUXILIARY )
-
-
-
-
-Zeilenga LDAP Models [Page 35]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The mandatory attributes of the other object classes of this entry are
- still required to be present and any precluded attributes are still
- not allowed to be present.
-
-
-
-4.4. Subschema Discovery
-
- To discover the DN of the subschema (sub)entry holding the subschema
- controlling a particular entry, a client reads that entry's
- 'subschemaSubentry' operational attribute. To read schema attributes
- from the subschema (sub)entry, clients MUST issue a Search operation
- [Protocol] where baseObject is the DN of the subschema (sub)entry,
- scope is baseObject, filter is "(objectClass=subschema)" [Filters],
- and attributes field lists the names of the desired schema attributes
- (as they are operational). Note: the "(objectClass=subschema)" filter
- allows LDAP servers which gateway to X.500 to detect that subentry
- information is being requested.
-
- Clients SHOULD NOT assume a published subschema is complete nor assume
- the server supports all of the schema elements it publishes nor assume
- the server does not support an unpublished element.
-
-
-5. DSA (Server) Informational Model
-
- The LDAP protocol assumes there are one or more servers which jointly
- provide access to a Directory Information Tree (DIT). The server
- holding the original information is called the "master" (for that
- information). Servers which hold copies of the original information
- are referred to as "shadowing" or "caching" servers.
-
- As defined in [X.501]:
-
- context prefix: The sequence of RDNs leading from the Root of the
- DIT to the initial vertex of a naming context; corresponds to
- the distinguished name of that vertex.
-
- and:
-
- naming context: A subtree of entries held in a single master DSA.
-
- That is, a naming context is 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. The context prefix
- is the name of the initial entry.
-
-
-
-
-Zeilenga LDAP Models [Page 36]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The root of the DIT is a DSA-specific Entry (DSE) and not part of any
- naming context (or any subtree); each server has different attribute
- values in the root DSE.
-
-
-5.1. Server-specific Data Requirements
-
- An LDAP server SHALL 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, which is named with the
- DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
- string).
-
- These attributes are retrievable, subject to access control and other
- restrictions, if a client performs a Search operation [Protocol] with
- an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
- [Filters], and with the attributes field listing the names of the
- desired attributes. It is noted that root DSE attributes are
- operational, and like other operational attributes, are not returned
- in search requests unless requested by name.
-
- The root DSE SHALL NOT be included if the client performs a subtree
- search starting from the root.
-
- Servers may allow clients to modify attributes of the root DSE where
- appropriate.
-
- The following attributes of the root DSE are defined in [Syntaxes].
- Additional attributes may be defined in other documents.
-
- - altServer: alternative servers;
-
- - namingContexts: naming contexts;
-
- - supportedControl: recognized LDAP controls;
-
- - supportedExtension: recognized LDAP extended operations;
-
- - supportedFeatures: recognized LDAP features;
-
- - supportedLDAPVersion: LDAP versions supported; and
-
- - supportedSASLMechanisms: recognized Simple Authentication and
- Security Layers (SASL) [SASL] mechanisms.
-
- The values provided for these attributes may depend on
- session-specific and other factors. For example, a server supporting
- the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
-
-
-
-Zeilenga LDAP Models [Page 37]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- client's identity has been established by a lower level. See
- [AuthMeth].
-
- The root DSE may also include a 'subschemaSubentry' attribute. If so,
- it refers to the subschema (sub)entry holding the schema controlling
- the root DSE. Clients SHOULD NOT assume that this subschema
- (sub)entry controls other entries held by the server. General
- subschema discovery procedures are provided in Section 4.4.
-
-
-5.1.1. 'altServer'
-
- The 'altServer' attribute lists URIs referring to alternative servers
- which may be contacted when this server becomes unavailable. URIs for
- servers implementing the LDAP are written according to [LDAPURL].
- Other kinds of URIs may be provided. If the server does not know of
- any other servers which could be used this attribute will be absent.
- Clients may cache this information in case their preferred server
- later becomes unavailable.
-
- ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- USAGE dSAOperation )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
- [Syntaxes].
-
-
-5.1.2. 'namingContexts'
-
- The 'namingContexts' attribute lists the context prefixes of the
- naming contexts the server masters or shadows (in part or in whole).
- If the server is a first-level DSA [X.501], it should list (in
- addition) an empty string (indicating the root of the DIT). If the
- server does not master or shadow any information (e.g. it is an LDAP
- gateway to a public X.500 directory) this attribute will be absent.
- If the server believes it masters or shadows the entire directory, the
- attribute will have a single value, and that value will be the empty
- string (indicating the root of the DIT).
-
- This attribute may be used, for example, to select a suitable entry
- name for subsequent operations with this server.
-
- ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- USAGE dSAOperation )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
-
-
-
-Zeilenga LDAP Models [Page 38]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- defined in [Syntaxes].
-
-
-5.1.3. 'supportedControl'
-
- The 'supportedControl' attribute lists object identifiers identifying
- the request controls [Protocol] the server supports. If the server
- does not support any request controls, this attribute will be absent.
- Object identifiers identifying response controls need not be listed.
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
- defined in [Syntaxes].
-
-
-5.1.4. 'supportedExtension'
-
- The 'supportedExtension' attribute lists object identifiers
- identifying the extended operations [Protocol] which the server
- supports. If the server does not support any extended operations,
- this attribute will be absent.
-
- An extended operation generally consists of an extended request and an
- extended response but may also include other protocol data units (such
- as intermediate responses). The object identifier assigned to the
- extended request is used to identify the extended operation. Other
- object identifiers used in the extended operation need not be listed
- as values of this attribute.
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
- defined in [Syntaxes].
-
-
-5.1.5. 'supportedFeatures'
-
-
-
-
-Zeilenga LDAP Models [Page 39]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The 'supportedFeatures' attribute lists object identifiers identifying
- elective features which the server supports. If the server does not
- support any discoverable elective features, this attribute will be
- absent.
-
- ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
- objectIdentifierMatch matching rule are defined in [Syntaxes].
-
-
-5.1.6. 'supportedLDAPVersion'
-
- The 'supportedLDAPVersion' attribute lists the versions of LDAP which
- the server supports.
-
- ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- USAGE dSAOperation )
-
- The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
- [Syntaxes].
-
-
-5.1.7. 'supportedSASLMechanisms'
-
- The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
- [SASL] which the server recognizes and/or supports [AuthMeth]. The
- contents of this attribute may depend on the current session state.
- If the server does not support any SASL mechanisms this attribute will
- not be present.
-
- ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
- USAGE dSAOperation )
-
- The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
- in [Syntaxes].
-
-
-6. Other Considerations
-
-
-
-
-Zeilenga LDAP Models [Page 40]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-6.1. Preservation of User Information
-
- Syntaxes may be defined which have specific value and/or value form
- (representation) preservation requirements. For example, a syntax
- containing digitally signed data can mandate the server preserve both
- the value and form of value presented to ensure signature is not
- invalidated.
-
- Where such requirements have not been explicitly stated, servers
- SHOULD preserve the value of user information but MAY return the value
- in a different form. And where a server is unable (or unwilling) to
- preserve the value of user information, the server SHALL ensure that
- an equivalent value (per Section 2.3) is returned.
-
-
-6.2. Short Names
-
- Short names, also known as descriptors, are used as more readable
- aliases for object identifiers and are used to identify various schema
- elements. However, it is not expected that LDAP implementations with
- human user interface would display these short names (nor the object
- identifiers they refer to) to the user, but would most likely be
- performing translations (such as expressing the short name in one of
- the local national languages). For example, the short name "st"
- (stateOrProvinceName) might be displayed to a German-speaking user as
- "Land".
-
- The same short name might have different meaning in different
- subschemas and, within a particular subschema, the same short name
- might refer to different object identifiers each identifying a
- different kind of schema element.
-
- Implementations MUST be prepared that the same short name might be
- used in a subschema to refer to the different kinds of schema
- elements. That is, there might be an object class 'x-fubar' and an
- attribute type 'x-fubar' in a subschema.
-
- Implementations MUST be prepared that the same short name might be
- used in the different subschemas to refer to the different schema
- elements. That is, there might be two matching rules 'x-fubar', each
- in different subschemas.
-
- Procedures for registering short names (descriptors) are detailed in
- BCP 64 [BCP64bis].
-
-
-6.3. Cache and Shadowing
-
-
-
-
-Zeilenga LDAP Models [Page 41]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- 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 that perform shadowing or caching MUST ensure that
- they do not violate any access control constraints placed on the data
- by the originating server.
-
-
-7. Implementation Guidelines
-
-7.1 Server Guidelines
-
- Servers MUST recognize all names of attribute types and object classes
- defined in this document but, unless stated otherwise, need not
- support the associated functionality. Servers SHOULD recognize all
- the names of attribute types and object classes defined in Section 3
- and 4, respectively, of [Schema].
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints.
-
- Servers MAY support DIT Content Rules. Servers MAY support DIT
- Structure Rules and Name Forms.
-
- Servers MAY support alias entries.
-
- Servers MAY support the 'extensibleObject' object class.
-
- Servers MAY support subentries. If so, they MUST do so in accordance
- with [RFC3672]. Servers which do not support subentries SHOULD use
- object entries to mimic subentries as detailed in Section 3.2.
-
- Servers MAY implement additional schema elements. Servers SHOULD
- provide definitions of all schema elements they support in subschema
- (sub)entries.
-
-
-7.2 Client Guidelines
-
- In the absence of prior agreements with servers, clients SHOULD NOT
- assume that servers support any particular schema elements beyond
- those referenced in Section 7.1. The client can retrieve subschema
- information as described in Section 4.4.
-
- Clients MUST NOT display nor attempt to decode as ASN.1, a value if
- its syntax is not known. Clients MUST NOT assume the LDAP-specific
- string encoding is restricted to a UTF-8 encoded string of Unicode
- characters or any particular subset of Unicode (such as a printable
-
-
-
-Zeilenga LDAP Models [Page 42]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- subset) unless such restriction is explicitly stated. Clients SHOULD
- NOT send attribute values in a request that are not valid according to
- the syntax defined for the attributes.
-
-
-8. Security Considerations
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
- General security considerations for accessing directory information
- with LDAP are discussed in [Protocol] and [AuthMeth].
-
-
-9. IANA Considerations
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
- template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see comment
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors (short names) should be added to
- the registry.
-
- NAME Type OID
- ------------------------ ---- -----------------
- governingStructureRule A 2.5.21.10
- structuralObjectClass A 2.5.21.9
-
- The following descriptors (short names) should be updated to
- refer to this RFC.
-
- NAME Type OID
- ------------------------ ---- -----------------
- alias O 2.5.6.1
- aliasedObjectName A 2.5.4.1
- altServer A 1.3.6.1.4.1.1466.101.120.6
-
-
-
-Zeilenga LDAP Models [Page 43]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- attributeTypes A 2.5.21.5
- createTimestamp A 2.5.18.1
- creatorsName A 2.5.18.3
- dITContentRules A 2.5.21.2
- dITStructureRules A 2.5.21.1
- extensibleObject O 1.3.6.1.4.1.1466.101.120.111
- ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
- matchingRuleUse A 2.5.21.8
- matchingRules A 2.5.21.4
- modifiersName A 2.5.18.4
- modifyTimestamp A 2.5.18.2
- nameForms A 2.5.21.7
- namingContexts A 1.3.6.1.4.1.1466.101.120.5
- objectClass A 2.5.4.0
- objectClasses A 2.5.21.6
- subschema O 2.5.20.1
- subschemaSubentry A 2.5.18.10
- supportedControl A 1.3.6.1.4.1.1466.101.120.13
- supportedExtension A 1.3.6.1.4.1.1466.101.120.7
- supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
- supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
- supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
- top O 2.5.6.0
-
-
-10. Acknowledgments
-
- This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
- S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
- RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
- Indexing of Directories (ASID) Working Group. This document is also
- based in part on "The Directory: Models" [X.501], a product of the
- International Telephone Union (ITU). Additional text was borrowed
- from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS) Working
- Group.
-
-
-11. Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-12. References
-
-
-
-Zeilenga LDAP Models [Page 44]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-12.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
- December 2003.
-
- [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
- 3672, December 2003.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
-
-
-
-Zeilenga LDAP Models [Page 45]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-12.2. Informative References
-
- None.
-
-
-Appendix A. Changes
-
- This appendix is non-normative.
-
- This document amounts to nearly a complete rewrite of portions of RFC
- 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
- overall clarity of technical specification. This appendix provides a
- summary of substantive changes made to the portions of these documents
- incorporated into this document. Readers should consult [Roadmap],
- [Protocol], [Syntaxes], and [Schema] for summaries of remaining
-
-
-
-Zeilenga LDAP Models [Page 46]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- portions of these documents.
-
-
-A.1 Changes to RFC 2251
-
- This document incorporates from RFC 2251 sections 3.2 and 3.4,
- portions of Section 4 and 6 as summarized below.
-
-
-A.1.1 Section 3.2 of RFC 2251
-
- Section 3.2 of RFC 2251 provided a brief introduction to the X.500
- data model, as used by LDAP. The previous specification relied on
- [X.501] but lacked clarity in how X.500 models are adapted for use by
- LDAP. This document describes the X.500 data models, as used by LDAP
- in greater detail, especially in areas where adaptation is needed.
-
- Section 3.2.1 of RFC 2251 described an attribute as "a type with one
- or more associated values." In LDAP, an attribute is better described
- as an attribute description, a type with zero or more options, and one
- or more associated values.
-
- Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
- objectClasses and attributeTypes attributes, yet X.500(93) treats
- these attributes as optional. While generally all implementations
- that support X.500(93) subschema mechanisms will provide both of these
- attributes, it is not absolutely required for interoperability that
- all servers do. The mandate was removed for consistency with
- X.500(93). The subschema discovery mechanism was also clarified to
- indicate that subschema controlling an entry is obtained by reading
- the (sub)entry referred to by that entry's 'subschemaSubentry'
- attribute.
-
-
-A.1.2 Section 3.4 of RFC 2251
-
- Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
- This material, with changes, was incorporated in Section 5.1 of this
- document.
-
- Changes:
-
- - Clarify that attributes of the root DSE are subject to "other
- restrictions" in addition to access controls.
-
- - Clarify that only recognized extended requests need to be enumerated
- 'supportedExtension'.
-
-
-
-
-Zeilenga LDAP Models [Page 47]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- - Clarify that only recognized request controls need to be enumerated
- 'supportedControl'.
-
- - Clarify that root DSE attributes are operational and, like other
- operational attributes, will not be returned in search requests
- unless requested by name.
-
- - Clarify that not all root DSE attributes are user modifiable.
-
- - Remove inconsistent text regarding handling of the
- 'subschemaSubentry' attribute within the root DSE. The previous
- specification stated that the 'subschemaSubentry' attribute held in
- the root DSE referred to "subschema entries (or subentries) known by
- this server." This is inconsistent with the attribute intended use
- as well as its formal definition as a single valued attribute
- [X.501]. It is also noted that a simple (possibly incomplete) list
- of subschema (sub)entries is not terrible useful. This document (in
- section 5.1) specifies that the 'subschemaSubentry' attribute of the
- root DSE refers to the subschema controlling the root DSE. It is
- noted that the general subschema discovery mechanism remains
- available (see Section 4.4 of this document).
-
-
-A.1.2 Section 4 of RFC 2251
-
- Portions of Section 4 of RFC 2251 detailing aspects of the information
- model used by LDAP were incorporated in this document, including:
-
- - Restriction of distinguished values to attributes whose descriptions
- have no options (from Section 4.1.3);
-
- - Data model aspects of Attribute Types (from Section 4.1.4),
- Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
- Matching Rule Identifier (from 4.1.9); and
-
- - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
-
-
-Clarifications to these portions include:
-
- - Subtyping and AttributeDescriptions with options.
-
-
-
-
-
-A.1.3 Section 6 of RFC 2251
-
-
-
-
-Zeilenga LDAP Models [Page 48]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
- where incorporated into this document.
-
-
-A.2 Changes to RFC 2252
-
- This document incorporates Sections 4, 5 and 7 from RFC 2252.
-
-
-A.2.1 Section 4 of RFC 2252
-
- The specification was updated to use Augmented BNF [RFC2234]. The
- string representation of an OBJECT IDENTIFIER was tighten to
- disallow leading zeros as described in RFC 2252 text.
-
- The <descr> syntax was changed to disallow semicolon (U+003B)
- characters to appear to be consistent its natural language
- specification "descr is the syntactic representation of an object
- descriptor, which consists of letters and digits, starting with a
- letter." In a related change, the statement "an
- AttributeDescription can be used as the value in a NAME part of an
- AttributeTypeDescription" was deleted. RFC 2252 provided no
- specification of the semantics of attribute options appearing in
- NAME fields.
-
- RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
- over the <numericoid> form. However, <descr> form can be ambiguous.
- To address this issue, the imperative was replaced with a statement
- (in Section 1.4) that while the <descr> form is generally preferred,
- <numericoid> should be used where an unambiguous <descr> is not
- available. Additionally, an expanded discussion of descriptor
- issues is discussed in Section 6.2 (Short Names).
-
- The ABNF for a quoted string (qdstring) was updated to reflect
- support for the escaping mechanism described in 4.3 of RFC 2252.
-
-
-A.2.2 Section 5 of RFC 2252
-
- Definitions of operational attributes provided in Section 5 of RFC
- 2252 where incorporated into this document.
-
- The 'namingContexts' description was clarified. A first-level DSA
- should publish, in addition to other values, "" indicating the root
- of the DIT.
-
- The 'altServer' description was clarified. It may hold any URI.
-
-
-
-
-Zeilenga LDAP Models [Page 49]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The 'supportedExtension' description was clarified. A server need
- only list the OBJECT IDENTIFIERs associated with the extended
- requests of the extended operations it recognizes.
-
- The 'supportedControl' description was clarified. A server need
- only list the OBJECT IDENTIFIERs associated with the request
- controls it recognizes.
-
- Descriptions for the 'structuralObjectClass' and
- 'governingStructureRule' operational attribute types were added.
-
-
-A.2.3 Section 7 of RFC 2252
-
- Section 7 of RFC 2252 provides definitions of the 'subschema' and
- 'extensibleObject' object classes. These definitions where
- integrated into Section 4.2 and Section 4.3 of this document,
- respectively. Section 7 of RFC 2252 also contained the object class
- implementation requirement. This was incorporated into Section 7 of
- this document.
-
- The specification of 'extensibleObject' was clarified of how it
- interacts with precluded attributes.
-
-
-A.3 Changes to RFC 2256
-
- This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
- 2256.
-
- Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
- attribute type. This was integrated into Section 2.4.1 of this
- document. The statement "One of the values is either 'top' or
- 'alias'" was replaced with statement that one of the values is 'top'
- as entries belonging to 'alias' also belong to 'top'.
-
- Section 5.2 of RFC 2256 provided the definition of the
- 'aliasedObjectName' attribute type. This was integrated into
- Section 2.6.2 of this document.
-
- Section 7.1 of RFC 2256 provided the definition of the 'top' object
- class. This was integrated into Section 2.4.1 of this document.
-
- Section 7.2 of RFC 2256 provided the definition of the 'alias'
- object class. This was integrated into Section 2.6.1 of this
- document.
-
-
-
-
-
-Zeilenga LDAP Models [Page 50]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-A.4 Changes to RFC 3674
-
- This document made no substantive change to the 'supportedFeatures'
- technical specification provided in RFC 3674.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-Zeilenga LDAP Models [Page 51]
-\f
+++ /dev/null
-
-
-Internet-Draft Editor: J. Sermersheim
-Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
-Obsoletes: RFCs 2251, 2830, 3771
-
-
- LDAP: The Protocol
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she becomes aware will be disclosed, in accordance with
- Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire in February 2005.
-
- Technical discussion of this document will take place on the IETF
- LDAP Revision Working Group (LDAPbis) mailing list <ietf-
- ldapbis@openldap.org>. Please send editorial comments directly to the
- editor <jimse@novell.com>.
-
-
-Abstract
-
- This document describes the protocol elements, along with their
- semantics and encodings, of the Lightweight Directory Access Protocol
- (LDAP). LDAP provides access to distributed directory services that
- act in accordance with X.500 data and service models. These protocol
- elements are based on those described in the X.500 Directory Access
- Protocol (DAP).
-
-
-Table of Contents
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 1 \f
- Lightweight Directory Access Protocol Version 3
-
- 1. Introduction....................................................3
- 1.1. Relationship to Other LDAP Specifications.....................3
- 2. Conventions.....................................................3
- 3. Protocol Model..................................................4
- 3.1 Operation and LDAP Message Layer Relationship..................5
- 4. Elements of Protocol............................................5
- 4.1. Common Elements...............................................5
- 4.1.1. Message Envelope............................................5
- 4.1.2. String Types................................................7
- 4.1.3. Distinguished Name and Relative Distinguished Name..........7
- 4.1.4. Attribute Descriptions......................................8
- 4.1.5. Attribute Value.............................................8
- 4.1.6. Attribute Value Assertion...................................8
- 4.1.7. Attribute and PartialAttribute..............................9
- 4.1.8. Matching Rule Identifier....................................9
- 4.1.9. Result Message..............................................9
- 4.1.10. Referral..................................................11
- 4.1.11. Controls..................................................13
- 4.2. Bind Operation...............................................14
- 4.3. Unbind Operation.............................................17
- 4.4. Unsolicited Notification.....................................17
- 4.5. Search Operation.............................................18
- 4.6. Modify Operation.............................................29
- 4.7. Add Operation................................................31
- 4.8. Delete Operation.............................................31
- 4.9. Modify DN Operation..........................................32
- 4.10. Compare Operation...........................................33
- 4.11. Abandon Operation...........................................34
- 4.12. Extended Operation..........................................35
- 4.13. IntermediateResponse Message................................36
- 4.14. StartTLS Operation..........................................37
- 5. Protocol Encoding, Connection, and Transfer....................39
- 5.1. Protocol Encoding............................................39
- 5.2. Transmission Control Protocol (TCP)..........................40
- 5.3. Termination of the LDAP session..............................40
- 6. Security Considerations........................................40
- 7. Acknowledgements...............................................42
- 8. Normative References...........................................42
- 9. Informative References.........................................44
- 10. IANA Considerations...........................................44
- 11. Editor's Address..............................................45
- Appendix A - LDAP Result Codes....................................46
- A.1 Non-Error Result Codes........................................46
- A.2 Result Codes..................................................46
- Appendix B - Complete ASN.1 Definition............................51
- Appendix C - Changes..............................................57
- C.1 Changes made to RFC 2251:.....................................57
- C.2 Changes made to RFC 2830:.....................................62
- C.3 Changes made to RFC 3771:.....................................63
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 2 \f
- Lightweight Directory Access Protocol Version 3
-
-1. Introduction
-
- The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. A directory user, which may be a human
- or other entity, accesses the Directory through a client (or
- Directory User Agent (DUA)). The client, on behalf of the directory
- user, interacts with one or more servers (or Directory System Agents
- (DSA)). Clients interact with servers using a directory access
- protocol.
-
- This document details the protocol elements of the Lightweight
- Directory Access Protocol (LDAP), along with their semantics.
- Following the description of protocol elements, it describes the way
- in which the protocol elements are encoded and transferred.
-
-
-1.1. Relationship to Other LDAP Specifications
-
- This document is an integral part of the LDAP Technical Specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
- This document, together with [Roadmap], [AuthMeth], and [Models],
- obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
- [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
- [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
- 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
- are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
- this document. Appendix C.1 summarizes substantive changes in the
- remainder.
-
- This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
- RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
- substantive changes to the remaining sections.
-
- This document also obsoletes RFC 3771 in entirety.
-
-
-2. Conventions
-
- 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 [Keyword].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 3 \f
- Lightweight Directory Access Protocol Version 3
-
- The term "transport connection" refers to the underlying transport
- services used to carry the protocol exchange, as well as associations
- established by these services.
-
- The term "TLS layer" refers to TLS services used in providing
- security services, as well as associations established by these
- services.
-
- The term "SASL layer" refers to SASL services used in providing
- security services, as well as associations established by these
- services.
-
- The term "LDAP message layer" refers to the LDAP Message Protocol
- Data Unit (PDU) services used in providing directory services, as
- well as associations established by these services.
-
- The term "LDAP session" refers to combined services (transport
- connection, TLS layer, SASL layer, LDAP message layer) and their
- associations.
-
- See the table in Section 5 for an illustration of these four terms.
-
-
-3. 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 an
- operation, the server typically returns a response containing
- appropriate data to the requesting client.
-
- Protocol operations are generally independent of one another. Each
- operation is processed as an atomic action, leaving the directory in
- a consistent state.
-
- 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 generally may be
- exchanged between a client and server in any order. If required,
- synchronous behavior may be controlled by client applications.
-
- The core protocol operations defined in this document can be mapped
- to a subset of the X.500 (1993) Directory Abstract Service [X.511].
- However there is not a one-to-one mapping between LDAP operations and
- X.500 Directory Access Protocol (DAP) operations. Server
- implementations acting as a gateway to X.500 directories may need to
- make multiple DAP requests to service a single LDAP request.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 4 \f
- Lightweight Directory Access Protocol Version 3
-
-
-3.1. Operation and LDAP Message Layer Relationship
-
- Protocol operations are exchanged at the LDAP message layer. When the
- transport connection is closed, any uncompleted operations at the
- LDAP message layer, when possible, are abandoned, and when not
- possible, are completed without transmission of the response. Also,
- when the transport connection is closed, the client MUST NOT assume
- that any uncompleted update operations have succeeded or failed.
-
-
-4. Elements of Protocol
-
- The protocol is described using Abstract Syntax Notation One
- ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
- Rules ([BER]). Section 5 specifies how the protocol elements are
- encoded and transferred.
-
- In order to support future extensions to this protocol, extensibility
- is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
- and enumerated types are extensible). In addition, ellipses (...)
- have been supplied in ASN.1 types that are explicitly extensible as
- discussed in [LDAPIANA]. Because of the implied extensibility,
- clients and servers MUST (unless otherwise specified) ignore trailing
- SEQUENCE components whose tags they do not recognize.
-
- Changes to the protocol other than through the extension mechanisms
- described here require a different version number. A client indicates
- the version it is using as part of the BindRequest, described in
- Section 4.2. If a client has not sent a Bind, the server MUST assume
- the client is using version 3 or later.
-
- Clients may attempt to determine the protocol versions a server
- supports by reading the 'supportedLDAPVersion' attribute from the
- root DSE (DSA-Specific Entry) [Models].
-
-
-4.1. Common Elements
-
- This section describes the LDAPMessage envelope Protocol Data Unit
- (PDU) 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:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 5 \f
- Lightweight Directory Access Protocol Version 3
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- The ASN.1 type Controls is defined in Section 4.1.11.
-
- 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 messageID and the controls.
-
- If the server receives an LDAPMessage 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 SHOULD return the Notice of Disconnection
- described in Section 4.4.1, with the resultCode set to protocolError,
- and MUST immediately terminate the LDAP session as described in
- Section 5.3.
-
- In other cases where the client or server cannot parse an LDAP PDU,
- it SHOULD abruptly terminate the LDAP session (Section 5.3) where
- further communication (including providing notice) would be
- pernicious. Otherwise, server implementations MUST return an
- appropriate response to the request, with the resultCode set to
- protocolError.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 6 \f
- Lightweight Directory Access Protocol Version 3
-
-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 non-zero value different from
- the messageID of any other request in progress in the same LDAP
- session. The zero value is reserved for the unsolicited notification
- message.
-
- Typical clients increment a counter for each request.
-
- A client MUST NOT send a request with the same message ID as an
- earlier request in the same LDAP session unless it can be determined
- that the server is no longer servicing the earlier request (e.g.
- after the final response is received, or a subsequent Bind
- completes). Otherwise the behavior is undefined. For this purpose,
- note that Abandon and successfully abandoned operations do not send
- responses.
-
-
-4.1.2. String Types
-
- The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as ASN.1 OCTET STRING types, the
- [ISO10646] character set (a superset of [Unicode]) is used, encoded
- following the [UTF-8] algorithm. Note that Unicode characters U+0000
- through U+007F are the same as ASCII 0 through 127, respectively, and
- have the same single octet UTF-8 encoding. Other Unicode characters
- have a multiple octet UTF-8 encoding.
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- 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. Although an LDAPOID is
- encoded as an OCTET STRING, values are limited to the definition of
- <numericoid> given in Section 1.4 of [Models].
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- For example,
-
- 1.3.6.1.4.1.1466.1.2.3
-
-
-4.1.3. Distinguished Name and Relative Distinguished Name
-
- An LDAPDN is defined to be the representation of a Distinguished Name
- (DN) after encoding according to the specification in [LDAPDN].
-
- LDAPDN ::= LDAPString
- -- Constrained to <distinguishedName> [LDAPDN]
-
-Sermersheim Internet-Draft - Expires April 2006 Page 7 \f
- Lightweight Directory Access Protocol Version 3
-
-
- A RelativeLDAPDN is defined to be the representation of a Relative
- Distinguished Name (RDN) after encoding according to the
- specification in [LDAPDN].
-
- RelativeLDAPDN ::= LDAPString
- -- Constrained to <name-component> [LDAPDN]
-
-
-4.1.4. Attribute Descriptions
-
- The definition and encoding rules for attribute descriptions are
- defined in Section 2.5 of [Models]. Briefly, an attribute description
- is an attribute type and zero or more options.
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
-
-4.1.5. Attribute Value
-
- A field of type AttributeValue is an OCTET STRING containing an
- encoded attribute value. The attribute value is encoded according to
- the LDAP-specific encoding definition of its corresponding syntax.
- The LDAP-specific encoding definitions for different syntaxes and
- attribute types may be found in other documents and in particular
- [Syntaxes].
-
- AttributeValue ::= OCTET STRING
-
- Note that there is no defined limit on the size of this encoding;
- thus protocol values may include multi-megabyte attribute values
- (e.g. photographs).
-
- Attribute values may be defined which have arbitrary and non-
- printable syntax. Implementations MUST NOT display nor attempt to
- decode an attribute value if its syntax is not known. The
- implementation may attempt to discover the subschema of the source
- entry, and retrieve the descriptions of 'attributeTypes' from it
- [Models].
-
- Clients MUST only send attribute values in a request that are valid
- according to the syntax defined for the attributes.
-
-
-4.1.6. Attribute Value Assertion
-
- The AttributeValueAssertion (AVA) type definition is similar to the
- one in the X.500 Directory standards. It contains an attribute
- description and a matching rule ([Models] Section 4.1.3) assertion
- value suitable for that type. Elements of this type are typically
- used to assert that the value in assertionValue matches a value of an
- attribute.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 8 \f
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- The syntax of the AssertionValue depends on the context of the LDAP
- operation being performed. For example, the syntax of the EQUALITY
- matching rule for an attribute is used when performing a Compare
- operation. Often this is the same syntax used for values of the
- attribute type, but in some cases the assertion syntax differs from
- the value syntax. See objectIdentiferFirstComponentMatch in
- [Syntaxes] for an example.
-
-
-4.1.7. Attribute and PartialAttribute
-
- Attributes and partial attributes consist of an attribute description
- and attribute values. A PartialAttribute allows zero values, while
- Attribute requires at least one value.
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- No two of the attribute values may be equivalent as described by
- Section 2.3 of [Models]. The set of attribute values is unordered.
- Implementations MUST NOT rely upon the ordering being repeatable.
-
-
-4.1.8. Matching Rule Identifier
-
- Matching rules are defined in Section 4.1.3 of [Models]. A matching
- rule is identified in the protocol by the printable representation of
- either its <numericoid>, or one of its short name descriptors
- [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
-
- MatchingRuleId ::= LDAPString
-
-
-4.1.9. Result Message
-
- The LDAPResult is the construct used in this protocol to return
- success or failure indications from servers to clients. To various
- requests, servers will return responses containing the elements found
- in LDAPResult to indicate the final status of the protocol operation
- request.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 9 \f
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 10 \f
- Lightweight Directory Access Protocol Version 3
-
- The resultCode enumeration is extensible as defined in Section 3.6 of
- [LDAPIANA]. The meanings of the listed result codes are given in
- Appendix A. If a server detects multiple errors for an operation,
- only one result code is returned. The server should return the result
- code that best indicates the nature of the error encountered. Servers
- may return substituted result codes to prevent unauthorized
- disclosures.
-
- The diagnosticMessage field of this construct may, at the server's
- option, be used to return a string containing a textual, human-
- readable (terminal control and page formatting characters should be
- avoided) diagnostic message. As this diagnostic message is not
- standardized, implementations MUST NOT rely on the values returned.
- Diagnostic messages typically supplement the resultCode with
- additional information. If the server chooses not to return a textual
- diagnostic, the diagnosticMessage field MUST be empty.
-
- For certain result codes (typically, but not restricted to
- noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem), the matchedDN field is set (subject to
- access controls) to the name of the last entry (object or alias) used
- in finding the target (or base) object. This will be a truncated form
- of the provided name or, if an alias was dereferenced while
- attempting to locate the entry, of the resulting name. Otherwise the
- matchedDN field is empty.
-
-
-4.1.10. Referral
-
- The referral result code indicates that the contacted server cannot
- or will not perform the operation and that one or more other servers
- may be able to. Reasons for this include:
-
- - The target entry of the request is not held locally, but the
- server has knowledge of its possible existence elsewhere.
-
- - The operation is restricted on this server -- perhaps due to a
- read-only copy of an entry to be modified.
-
- The referral field is present in an LDAPResult if the resultCode is
- set to referral, and absent with all other result codes. It contains
- one or more references to one or more servers or services that may be
- accessed via LDAP or other protocols. Referrals can be returned in
- response to any operation request (except Unbind and Abandon which do
- not have responses). At least one URI MUST be present in the
- Referral.
-
- During a Search operation, after the baseObject is located, and
- entries are being evaluated, the referral is not returned. Instead,
- continuation references, described in Section 4.5.3, are returned
- when other servers would need to be contacted to complete the
- operation.
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 11 \f
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- If the client wishes to progress the operation, it contacts one of
- the supported services found in the referral. If multiple URIs are
- present, the client assumes that any supported URI may be used to
- progress the operation.
-
- Clients that follow referrals MUST ensure that they do not loop
- between servers. They MUST NOT repeatedly contact the same server for
- the same request with the same parameters. Some clients use a counter
- that is incremented each time referral handling occurs for an
- operation, and these kinds of clients MUST be able to handle at least
- ten nested referrals while progressing the operation.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- Referral values which are LDAP URLs follow these rules:
-
- - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
- be present, with the new target object name.
-
- - It is RECOMMENDED that the <dn> part be present to avoid
- ambiguity.
-
- - If the <dn> part is present, the client uses this name in its next
- request to progress the operation, and if it is not present the
- client uses the same name as in the original request.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in a URL of a referral for a Search
- operation.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - For Search, it is RECOMMENDED that the <scope> part be present to
- avoid ambiguity.
-
- - If the <scope> part is missing, the scope of the original Search
- is used by the client to progress the operation.
-
- - Other aspects of the new request may be the same as or different
- from the request which generated the referral.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 12 \f
- Lightweight Directory Access Protocol Version 3
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-4.1.11. Controls
-
- Controls provide a mechanism whereby the semantics and arguments of
- existing LDAP operations may be extended. One or more controls may be
- attached to a single LDAP message. A control only affects the
- semantics of the message it is attached to.
-
- Controls sent by clients are termed 'request controls' and those sent
- by servers are termed 'response controls'.
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- The controlType field is the dotted-decimal representation of an
- OBJECT IDENTIFIER which uniquely identifies the control. This
- provides unambiguous naming of controls. Often, response control(s)
- solicited by a request control share controlType values with the
- request control.
-
- The criticality field only has meaning in controls attached to
- request messages (except UnbindRequest). For controls attached to
- response messages and the UnbindRequest, the criticality field SHOULD
- be FALSE, and MUST be ignored by the receiving protocol peer. A value
- of TRUE indicates that it is unacceptable to perform the operation
- without applying the semantics of the control. Specifically, the
- criticality field is applied as follows:
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is TRUE, the server MUST NOT perform the operation, and for
- operations that have a response message, MUST return with the
- resultCode set to unavailableCriticalExtension.
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is FALSE, the server MUST ignore the control.
-
- - Regardless of criticality, if a control is applied to an
- operation, it is applied consistently and impartially to the
- entire operation.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 13 \f
- Lightweight Directory Access Protocol Version 3
-
- The controlValue may contain information associated with the
- controlType. Its format is defined by the specification of the
- control. Implementations MUST be prepared to handle arbitrary
- contents of the controlValue octet string, including zero bytes. It
- is absent only if there is no value information which is associated
- with a control of its type. When a controlValue is defined in terms
- of ASN.1, and BER encoded according to Section 5.1, it also follows
- the extensibility rules in Section 4.
-
- Servers list the controlType of request controls they recognize in
- the 'supportedControl' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Controls SHOULD NOT be combined unless the semantics of the
- combination has been specified. The semantics of control
- combinations, if specified, are generally found in the control
- specification most recently published. When a combination of controls
- is encountered whose semantics are invalid, not specified (or not
- known), the message is considered to be not well-formed, thus the
- operation fails with protocolError. Controls with a criticality of
- FALSE may be ignored in order to arrive at a valid combination.
- Additionally, unless order-dependent semantics are given in a
- specification, the order of a combination of controls in the SEQUENCE
- is ignored. Where the order is to be ignored but cannot be ignored by
- the server, the message is considered not well-formed and the
- operation fails with protocolError. Again, controls with a
- criticality of FALSE may be ignored in order to arrive at a valid
- combination.
-
- This document does not specify any controls. Controls may be
- specified in other documents. Documents detailing control extensions
- are to provide for each control:
-
- - the OBJECT IDENTIFIER assigned to the control,
-
- - direction as to what value the sender should provide for the
- criticality field (note: the semantics of the criticality field
- are defined above should not be altered by the control's
- specification),
-
- - whether the controlValue field is present, and if so, the format
- of its contents,
-
- - the semantics of the control, and
-
- - optionally, semantics regarding the combination of the control
- with other controls.
-
-
-4.2. Bind Operation
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 14 \f
- Lightweight Directory Access Protocol Version 3
-
- The function of the Bind operation is to allow authentication
- information to be exchanged between the client and server. The Bind
- operation should be thought of as the "authenticate" operation.
- Operational, authentication, and security-related semantics of this
- operation are given in [AuthMeth].
-
- The Bind request is defined as follows:
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- Fields of the BindRequest are:
-
- - version: A version number indicating the version of the protocol
- to be used at the LDAP message layer. This document describes
- version 3 of the protocol. There is no version negotiation. The
- client sets this field to the version it desires. If the server
- does not support the specified version, it MUST respond with a
- BindResponse where the resultCode is set to protocolError.
-
- - name: If not empty, 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
- ([AuthMeth] Section 5.1) or when using Simple Authentication and
- Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
- Where the server attempts to locate the named object, it SHALL NOT
- perform alias dereferencing.
-
- - authentication: information used in authentication. This type is
- extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
- do not support a choice supplied by a client return a BindResponse
- with the resultCode set to authMethodNotSupported.
-
- Textual passwords (consisting of a character sequence with a known
- character set and encoding) transferred to the server using the
- simple AuthenticationChoice SHALL be transferred as [UTF-8]
- encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
- passwords as "query" strings by applying the [SASLprep] profile of
- the [Stringprep] algorithm. Passwords consisting of other data
- (such as random octets) MUST NOT be altered. The determination of
- whether a password is textual is a local client matter.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 15 \f
- Lightweight Directory Access Protocol Version 3
-
-
-4.2.1. Processing of the Bind Request
-
- Before processing a BindRequest, all uncompleted operations MUST
- either complete or be abandoned. The server may either wait for the
- uncompleted operations to complete, or abandon them. The server then
- proceeds to authenticate the client in either a single-step, or
- multi-step Bind process. Each step requires the server to return a
- BindResponse to indicate the status of authentication.
-
- After sending a BindRequest, clients MUST NOT send further LDAP PDUs
- until receiving the BindResponse. Similarly, servers SHOULD NOT
- process or respond to requests received while processing a
- BindRequest.
-
- If the client did not bind before sending a request and receives an
- operationsError to that request, it may then send a BindRequest. If
- this also fails or the client chooses not to bind on the existing
- LDAP session, it may terminate the LDAP session, re-establish it and
- begin again by first sending a BindRequest. This will aid in
- interoperating with servers implementing other versions of LDAP.
-
- Clients may send multiple Bind requests to change the authentication
- and/or security associations or to complete a multi-stage Bind
- process. Authentication from earlier binds is subsequently ignored.
-
- For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times ([AuthMeth] Section
- 5.2). Clients MUST NOT invoke operations between two Bind requests
- made as part of a multi-stage Bind.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as an
- empty string, the server MUST return a BindResponse with the
- resultCode set to authMethodNotSupported. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
-
-4.2.2. Bind Response
-
- The Bind response is defined as follows.
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- BindResponse consists simply of an indication from the server of the
- status of the client's request for authentication.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 16 \f
- Lightweight Directory Access Protocol Version 3
-
- A successful Bind operation is indicated by a BindResponse with a
- resultCode set to success. Otherwise, an appropriate result code is
- set in the BindResponse. For BindResponse, the protocolError result
- code may be used to indicate that the version number supplied by the
- client is unsupported.
-
- If the client receives a BindResponse where the resultCode is set to
- protocolError, it is to assume that the server does not support this
- version of LDAP. While the client may be able proceed with another
- version of this protocol (this may or may not require closing and re-
- establishing the transport connection), how to proceed with another
- version of this protocol is beyond the scope of this document.
- Clients which are unable or unwilling to proceed SHOULD terminate the
- LDAP session.
-
- The serverSaslCreds field is used as part of a SASL-defined bind
- mechanism to allow the client to authenticate the server to which it
- is communicating, or to perform "challenge-response" authentication.
- If the client bound with the simple choice, or the SASL mechanism
- does not require the server to return information to the client, then
- this field SHALL NOT be included in the BindResponse.
-
-
-4.3. Unbind Operation
-
- The function of the Unbind operation is to terminate an LDAP session.
- The Unbind operation is not the antithesis of the Bind operation as
- the name implies. The naming of these operations are historical. The
- Unbind operation should be thought of as the "quit" operation.
-
- The Unbind operation is defined as follows:
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- The client, upon transmission of the UnbindRequest, and the server,
- upon receipt of the UnbindRequest are to gracefully terminate the
- LDAP session as described in Section 5.3.
-
- Uncompleted operations are handled as specified in Section 3.1.
-
-
-4.4. Unsolicited Notification
-
- An unsolicited notification is an LDAPMessage sent from the server to
- the client which is not in response to any LDAPMessage received by
- the server. It is used to signal an extraordinary condition in the
- server or in the LDAP session between the client and the server. The
- notification is of an advisory nature, and the server will not expect
- any response to be returned from the client.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 17 \f
- Lightweight Directory Access Protocol Version 3
-
- The unsolicited notification is structured as an LDAPMessage in which
- the messageID is zero and protocolOp is set to the extendedResp
- choice using the ExtendedResponse type (See Section 4.12). The
- responseName field of the ExtendedResponse always contains an LDAPOID
- which is unique for this notification.
-
- One unsolicited notification (Notice of Disconnection) is defined in
- this document. The specification of an unsolicited notification
- consists of:
-
- - the OBJECT IDENTIFIER assigned to the notification (to be
- specified in the responseName,
-
- - the format of the contents of the responseValue (if any),
-
- - the circumstances which will cause the notification to be sent,
- and
-
- - the semantics of the message.
-
-
-4.4.1. Notice of Disconnection
-
- This notification may be used by the server to advise the client that
- the server is about to terminate the LDAP session on its own
- initiative. This notification is intended to assist clients in
- distinguishing between an exceptional server condition and a
- transient network failure. Note that this notification is not a
- response to an Unbind requested by the client. Uncompleted operations
- are handled as specified in Section 3.1.
-
- The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
- is absent, and the resultCode is used to indicate the reason for the
- disconnection. When the strongerAuthRequired resultCode is returned
- with this message, it indicates that the server has detected that an
- established security association between the client and server has
- unexpectedly failed or been compromised.
-
- Upon transmission of the Notice of Disconnection, the server
- gracefully terminates the LDAP session as described in Section 5.3.
-
-
-4.5. Search Operation
-
- The Search operation is used to request a server to return, subject
- to access controls and other restrictions, a set of entries matching
- a complex search criterion. This can be used to read attributes from
- a single entry, from entries immediately subordinate to a particular
- entry, or a whole subtree of entries.
-
-
-4.5.1. Search Request
-
- The Search request is defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 18 \f
- Lightweight Directory Access Protocol Version 3
-
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 19 \f
- Lightweight Directory Access Protocol Version 3
-
- Note that an X.500 "list"-like operation can be emulated by the
- client requesting a singleLevel Search operation with a filter
- checking for the presence of the 'objectClass' attribute, and that an
- X.500 "read"-like operation can be emulated by a baseObject Search
- operation with the same filter. A server which provides a gateway to
- X.500 is not required to use the Read or List operations, although it
- may choose to do so, and if it does, it must provide the same
- semantics as the X.500 Search operation.
-
-
-4.5.1.1. SearchRequest.baseObject
-
- The name of the base object entry (or possibly the root) relative to
- which the Search is to be performed.
-
-
-4.5.1.2. SearchRequest.scope
-
- Specifies the scope of the Search to be performed. The semantics (as
- described in [X.511]) of the defined values of this field are:
-
- baseObject: The scope is constrained to the entry named by
- baseObject.
-
- singleLevel: The scope is constrained to the immediate
- subordinates of the entry named by baseObject.
-
- wholeSubtree: the scope is constrained to the entry named by the
- baseObject, and all its subordinates.
-
-
-4.5.1.3. SearchRequest.derefAliases
-
- An indicator as to whether or not alias entries (as defined in
- [Models]) are to be dereferenced during stages of the Search
- operation.
-
- The act of dereferencing an alias includes recursively dereferencing
- aliases which refer to aliases.
-
- Servers MUST detect looping while dereferencing aliases in order to
- prevent denial of service attacks of this nature.
-
- The semantics of the defined values of this field are:
-
- neverDerefAliases: Do not dereference aliases in searching or in
- locating the base object of the Search.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 20 \f
- Lightweight Directory Access Protocol Version 3
-
- derefInSearching: While searching subordinates of the base object,
- dereference any alias within the search scope. Dereferenced
- objects become the vertices of further search scopes where the
- Search operation is also applied. If the search scope is
- wholeSubtree, the Search continues in the subtree(s) of any
- dereferenced object. If the search scope is singleLevel, the
- search is applied to any dereferenced objects, and is not applied
- to their subordinates. Servers SHOULD eliminate duplicate entries
- that arise due to alias dereferencing while searching.
-
- derefFindingBaseObj: 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.
-
-
-4.5.1.4. SearchRequest.sizeLimit
-
- A size limit that restricts the maximum number of entries to be
- returned as a result of the Search. A value of zero in this field
- indicates that no client-requested size limit restrictions are in
- effect for the Search. Servers may also enforce a maximum number of
- entries to return.
-
-
-4.5.1.5. SearchRequest.timeLimit
-
- A time limit that restricts the maximum time (in seconds) allowed for
- a Search. A value of zero in this field indicates that no client-
- requested time limit restrictions are in effect for the Search.
- Servers may also enforce a maximum time limit for the Search.
-
-
-4.5.1.6. SearchRequest.typesOnly
-
- An indicator as to whether Search results are to contain both
- attribute descriptions and values, or just attribute descriptions.
- Setting this field to TRUE causes only attribute descriptions (no
- values) to be returned. Setting this field to FALSE causes both
- attribute descriptions and values to be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 21 \f
- Lightweight Directory Access Protocol Version 3
-
-4.5.1.7. SearchRequest.filter
-
- A filter that defines the conditions that must be fulfilled in order
- for the Search to match a given entry.
-
- The 'and', 'or' and 'not' choices can be used to form combinations of
- filters. At least one filter element MUST be present in an 'and' or
- 'or' choice. The others match against individual attribute values of
- entries in the scope of the Search. (Implementor's note: the 'not'
- filter is an example of a tagged choice in an implicitly-tagged
- module. In BER this is treated as if the tag was explicit.)
-
- A server MUST evaluate filters according to the three-valued logic of
- [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
- either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
- TRUE for a particular entry, then the attributes of that entry are
- returned as part of the Search result (subject to any applicable
- access control restrictions). If the filter evaluates to FALSE or
- Undefined, then the entry is ignored for the Search.
-
- A filter of the "and" choice is TRUE if all the filters in the SET OF
- evaluate to TRUE, FALSE if at least one filter is FALSE, and
- otherwise Undefined. A filter of the "or" choice is FALSE if all of
- the filters in the SET OF evaluate to FALSE, TRUE if at least one
- filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
- is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
- and Undefined if it is Undefined.
-
- A filter item evaluates to Undefined when the server would not be
- able to determine whether the assertion value matches an entry.
- Examples include:
-
- - An attribute description in an equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
- filter is not recognized by the server.
-
- - The attribute type does not define the appropriate matching
- rule.
-
- - A MatchingRuleId in the extensibleMatch is not recognized by
- the server or is not valid for the attribute type.
-
- - The type of filtering requested is not implemented.
-
- - The assertion value is invalid.
-
- For example, if a server did not recognize the attribute type
- shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
- (shoeSize<=12) would each evaluate to Undefined.
-
- Servers MUST NOT return errors if attribute descriptions or matching
- rule ids are not recognized, assertion values are invalid, or the
- assertion syntax is not supported. More details of filter processing
- are given in Clause 7.8 of [X.511].
-
-Sermersheim Internet-Draft - Expires April 2006 Page 22 \f
- Lightweight Directory Access Protocol Version 3
-
-
-
-4.5.1.7.1. SearchRequest.filter.equalityMatch
-
- The matching rule for an equalityMatch filter is defined by the
- EQUALITY matching rule for the attribute type or subtype. The filter
- is TRUE when the EQUALITY rule returns TRUE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.2. SearchRequest.filter.substrings
-
- There SHALL be at most one 'initial', and at most one 'final' in the
- 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
- be the first element of 'substrings'. If 'final' is present, it SHALL
- be the last element of 'substrings'.
-
- The matching rule for an AssertionValue in a substrings filter item
- is defined by the SUBSTR matching rule for the attribute type or
- subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
- applied to the attribute or subtype and the asserted value.
-
- Note that the AssertionValue in a substrings filter item conforms to
- the assertion syntax of the EQUALITY matching rule for the attribute
- type rather than the assertion syntax of the SUBSTR matching rule for
- the attribute type. Conceptually, the entire SubstringFilter is
- converted into an assertion value of the substrings matching rule
- prior to applying the rule.
-
-
-4.5.1.7.3. SearchRequest.filter.greaterOrEqual
-
- The matching rule for a greaterOrEqual filter is defined by the
- ORDERING matching rule for the attribute type or subtype. The filter
- is TRUE when the ORDERING rule returns FALSE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.4. SearchRequest.filter.lessOrEqual
-
- The matching rules for a lessOrEqual filter are defined by the
- ORDERING and EQUALITY matching rules for the attribute type or
- subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
- returns TRUE as applied to the attribute or subtype and the asserted
- value.
-
-
-4.5.1.7.5. SearchRequest.filter.present
-
- A present filter is TRUE when there is an attribute or subtype of the
- specified attribute description present in an entry, FALSE when no
- attribute or subtype of the specified attribute description is
- present in an entry, and Undefined otherwise.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 23 \f
- Lightweight Directory Access Protocol Version 3
-
-
-4.5.1.7.6. SearchRequest.filter.approxMatch
-
- An approxMatch filter is TRUE when there is a value of the attribute
- type or subtype for which some locally-defined approximate matching
- algorithm (e.g. spelling variations, phonetic match, etc.) returns
- TRUE. If a value matches for equality, it also satisfies an
- approximate match. If approximate matching is not supported for the
- attribute, this filter item should be treated as an equalityMatch.
-
-
-4.5.1.7.7. SearchRequest.filter.extensibleMatch
-
- The fields of the extensibleMatch filter item are evaluated as
- follows:
-
- - If the matchingRule field is absent, the type field MUST be
- present, and an equality match is performed for that type.
-
- - If the type field is absent and the matchingRule is present, the
- matchValue is compared against all attributes in an entry which
- support that matchingRule.
-
- - If the type field is present and the matchingRule is present, the
- matchValue is compared against the specified attribute type and
- its subtypes.
-
- - If the dnAttributes field is set to TRUE, the match is
- additionally applied against all the AttributeValueAssertions in
- an entry's distinguished name, and evaluates to TRUE if there is
- at least one attribute or subtype in the distinguished name for
- which the filter item evaluates to TRUE. The dnAttributes field is
- present to alleviate the need for multiple versions of generic
- matching rules (such as word matching), where one applies to
- entries and another applies to entries and DN attributes as well.
-
- The matchingRule used for evaluation determines the syntax for the
- assertion value. Once the matchingRule and attribute(s) have been
- determined, the filter item evaluates to TRUE if it matches at least
- one attribute type or subtype in the entry, FALSE if it does not
- match any attribute type or subtype in the entry, and Undefined if
- the matchingRule is not recognized, the matchingRule is unsuitable
- for use with the specified type, or the assertionValue is invalid.
-
-
-4.5.1.7. SearchRequest.attributes
-
- A selection list of the attributes to be returned from each entry
- which matches the search filter. Attributes which are subtypes of
- listed attributes are implicitly included. LDAPString values of this
- field are constrained to the following Augmented Backus-Naur Form
- ([ABNF]):
-
- attributeSelector = attributedescription / selectorspecial
-
-Sermersheim Internet-Draft - Expires April 2006 Page 24 \f
- Lightweight Directory Access Protocol Version 3
-
-
- selectorspecial = noattrs / alluserattrs
-
- noattrs = %x31.2E.31 ; "1.1"
-
- alluserattrs = %x2A ; asterisk ("*")
-
- The <attributedescription> production is defined in Section 2.5 of
- [Models].
-
- There are three special cases which may appear in the attributes
- selection list:
-
- - an empty list with no attributes,
-
- - a list containing "*" (with zero or more attribute
- descriptions), and
-
- - a list containing only "1.1".
-
- An empty list requests the return of all user attributes.
-
- A list containing "*" requests the return of all user attributes
- in addition to other listed (operational) attributes.
-
- A list containing only the OID "1.1" indicates that no attributes
- are to be returned. If "1.1" is provided with other
- attributeSelector values, the "1.1" attributeSelector is ignored.
- This OID was chosen because it does not (and can not) correspond
- to any attribute in use.
-
- Client implementors should note that even if all user attributes are
- requested, some attributes and/or attribute values of the entry may
- not be included in Search results due to access controls or other
- restrictions. Furthermore, servers will not return operational
- attributes, such as objectClasses or attributeTypes, unless they are
- listed by name. Operational attributes are described in [Models].
-
- Attributes are returned at most once in an entry. If an attribute
- description is named more than once in the list, the subsequent names
- are ignored. If an attribute description in the list is not
- recognized, it is ignored by the server.
-
-
-4.5.2. Search Result
-
- The results of the Search operation are returned as zero or more
- SearchResultEntry and/or SearchResultReference messages, followed by
- a single SearchResultDone message.
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 25 \f
- Lightweight Directory Access Protocol Version 3
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- Each SearchResultEntry represents an entry found during the Search.
- Each SearchResultReference represents an area not yet explored during
- the Search. The SearchResultEntry and SearchResultReference messages
- may come in any order. Following all the SearchResultReference and
- SearchResultEntry responses, the server returns a SearchResultDone
- response, which contains an indication of success, or detailing any
- errors that have occurred.
-
- Each entry returned in a SearchResultEntry will contain all
- appropriate attributes as specified in the attributes field of the
- Search Request, subject to access control and other administrative
- policy. Note that the PartialAttributeList may hold zero elements.
- This may happen when none of the attributes of an entry were
- requested, or could be returned. Note also that the partialAttribute
- vals set may hold zero elements. This may happen when typesOnly is
- requested, access controls prevent the return of values, or other
- reasons.
-
- Some attributes may be constructed by the server and appear in a
- SearchResultEntry attribute list, although they are not stored
- attributes of an entry. Clients SHOULD NOT assume that all attributes
- can be modified, even if permitted by access control.
-
- If the server's schema defines short names [Models] for an attribute
- type then the server SHOULD use one of those names in attribute
- descriptions for that attribute type (in preference to using the
- <numericoid> [Models] format of the attribute type's object
- identifier). The server SHOULD NOT use the short name if that name is
- known by the server to be ambiguous, or otherwise likely to cause
- interoperability problems.
-
-
-4.5.3. Continuation References in the Search Result
-
- If the server was able to locate the entry referred to by the
- baseObject but was unable or unwilling to search one or more non-
- local entries, the server may return one or more
- SearchResultReference messages, each containing a reference to
- another set of servers for continuing the operation. A server MUST
- NOT return any SearchResultReference messages if it has not located
- the baseObject and thus has not searched any entries; in this case it
- would return a SearchResultDone containing either a referral or
- noSuchObject result code (depending on the server's knowledge of the
- entry named in the baseObject).
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 26 \f
- Lightweight Directory Access Protocol Version 3
-
- If a server holds a copy or partial copy of the subordinate naming
- context (Section 5 of [Models]), it may use the search filter to
- determine whether or not to return a SearchResultReference response.
- Otherwise SearchResultReference responses are always returned when in
- scope.
-
- The SearchResultReference is of the same data type as the Referral.
-
- If the client wishes to progress the Search, it issues a new Search
- operation for each SearchResultReference that is returned. If
- multiple URIs are present, the client assumes that any supported URI
- may be used to progress the operation.
-
- Clients that follow search continuation references MUST ensure that
- they do not loop between servers. They MUST NOT repeatedly contact
- the same server for the same request with the same parameters. Some
- clients use a counter that is incremented each time search result
- reference handling occurs for an operation, and these kinds of
- clients MUST be able to handle at least ten nested referrals while
- progressing the operation.
-
- Note that the Abandon operation described in Section 4.11 applies
- only to a particular operation sent at the LDAP message layer between
- a client and server. The client must abandon subsequent Search
- operations it wishes to individually.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- SearchResultReference values which are LDAP URLs follow these rules:
-
- - The <dn> part of the LDAP URL MUST be present, with the new target
- object name. The client uses this name when following the
- reference.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in the LDAP URL.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - If the originating search scope was singleLevel, the <scope> part
- of the LDAP URL will be "base".
-
- - It is RECOMMENDED that the <scope> part be present to avoid
- ambiguity. In the absence of a <scope> part, the scope of the
- original Search request is assumed.
-
- - Other aspects of the new Search request may be the same as or
- different from the Search request which generated the
- SearchResultReference.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 27 \f
- Lightweight Directory Access Protocol Version 3
-
- - The name of an unexplored subtree in a SearchResultReference need
- not be subordinate to the base object.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-
-4.5.3.1. Examples
-
- For example, suppose the contacted server (hosta) holds the entry
- <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
- knows that both LDAP servers (hostb) and (hostc) hold
- <OU=People,DC=Example,DC=NET> (one is the master and the other server
- a shadow), and that LDAP-capable server (hostd) holds the subtree
- <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
- <DC=Example,DC=NET> is requested to the contacted server, it may
- return the following:
-
- SearchResultEntry for DC=Example,DC=NET
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??sub
- ldap://hostc/OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Client implementors should note that when following a
- SearchResultReference, additional SearchResultReference may be
- generated. Continuing the example, if the client contacted the server
- (hostb) and issued the Search request for the subtree
- <OU=People,DC=Example,DC=NET>, the server might respond as follows:
-
- SearchResultEntry for OU=People,DC=Example,DC=NET
- SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
- requested to the contacted server, it may return the following:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 28 \f
- Lightweight Directory Access Protocol Version 3
-
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??base
- ldap://hostc/OU=People,DC=Example,DC=NET??base }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
- SearchResultDone (success)
-
- If the contacted server does not hold the base object for the Search,
- but has knowledge of its possible location, then it may return a
- referral to the client. In this case, if the client requests a
- subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
- SearchResultDone containing a referral.
-
- SearchResultDone (referral) {
- ldap://hostg/DC=Example,DC=ORG??sub }
-
-
-4.6. Modify Operation
-
- The Modify operation allows a client to request that a modification
- of an entry be performed on its behalf by a server. The Modify
- Request is defined as follows:
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- Fields of the Modify Request are:
-
- - object: The value of this field contains the name of the entry to
- be modified. The server SHALL NOT perform any alias dereferencing
- in determining the object to be modified.
-
- - changes: A list of modifications to be performed on the entry. The
- entire list of modifications MUST be performed in the order they
- are listed as a single atomic operation. While individual
- modifications may violate certain aspects of the directory schema
- (such as the object class definition and DIT content rule), the
- resulting entry after the entire list of modifications is
- performed MUST conform to the requirements of the directory model
- and controlling schema [Models].
-
- - operation: Used to specify the type of modification being
- performed. Each operation type acts on the following
- modification. The values of this field have the following
- semantics respectively:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 29 \f
- Lightweight Directory Access Protocol Version 3
-
- add: add values listed to the modification attribute,
- creating the attribute if necessary;
-
- delete: delete values listed from the modification attribute.
- If no values are listed, or if all current values of the
- attribute are listed, the entire attribute is removed;
-
- replace: replace all existing values of the modification
- attribute with the new values listed, creating the attribute
- if it did not already exist. A replace with no value will
- delete the entire attribute if it exists, and is ignored if
- the attribute does not exist.
-
- - modification: A PartialAttribute (which may have an empty SET
- of vals) used to hold the attribute type or attribute type and
- values being modified.
-
- Upon receipt of a Modify Request, the server attempts to perform the
- necessary modifications to the DIT and returns the result in a Modify
- Response, defined as follows:
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIT modification,
- or the reason that the modification failed. 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 DIT 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. Whether the modification was applied or not cannot be
- determined by the client if the Modify Response was not received
- (e.g. the LDAP session was terminated or the Modify operation was
- abandoned).
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. The Modify operation cannot be
- used to remove from an entry any of its distinguished values, i.e.
- those values which form the entry's relative distinguished name. An
- attempt to do so will result in the server returning the
- notAllowedOnRDN result code. The Modify DN operation described in
- Section 4.9 is used to rename an entry.
-
- For attribute types which specify no equality matching, the rules in
- Section 2.5.1 of [Models] are followed.
-
- Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the changes in an LDAP ModifyRequest onto the
- changes of a DAP ModifyEntry operation, and different implementations
- of LDAP-DAP gateways may use different means of representing the
- change. If successful, the final effect of the operations on the
- entry MUST be identical.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 30 \f
- Lightweight Directory Access Protocol Version 3
-
-
-4.7. 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,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- Fields of the Add Request are:
-
- - entry: the name of the entry to be added. The server SHALL NOT
- dereference any aliases in locating the entry to be added.
-
- - attributes: the list of attributes that, along with those from the
- RDN, make up the content of the entry being added. Clients MAY or
- MAY NOT include the RDN attribute(s) in this list. Clients MUST
- NOT supply NO-USER-MODIFICATION attributes such as the
- createTimestamp or creatorsName attributes, since the server
- maintains these automatically.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this applies to the naming attribute in addition to any
- multi-valued attributes being added).
-
- The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The immediate superior (parent) of an
- object or alias entry to be added MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- Upon receipt of an Add Request, a server will attempt to add the
- requested entry. The result of the Add attempt will be returned to
- the client in the Add Response, defined as follows:
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- A response of success indicates that the new entry has been added to
- the Directory.
-
-
-4.8. 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
-
-Sermersheim Internet-Draft - Expires April 2006 Page 31 \f
- Lightweight Directory Access Protocol Version 3
-
-
- The Delete Request consists of the name of the entry to be deleted.
- The server SHALL NOT dereference aliases while resolving the name of
- the target entry to be removed.
-
- Only leaf entries (those with no subordinate entries) can be deleted
- with this operation.
-
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested and return the result in the Delete
- Response defined as follows:
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
-
-4.9. Modify DN Operation
-
- The Modify DN operation allows a client to change the Relative
- Distinguished Name (RDN) of an entry in the Directory, and/or to move
- a subtree of entries to a new location in the Directory. The Modify
- DN Request is defined as follows:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- Fields of the Modify DN Request are:
-
- - entry: the name of the entry to be changed. This entry may or may
- not have subordinate entries.
-
- - newrdn: the new RDN of the entry. The value of the old RDN is
- supplied when moving the entry to a new superior without changing
- its RDN. Attribute values of the new RDN not matching any
- attribute value of the entry are added to the entry and an
- appropriate error is returned if this fails.
-
- - deleteoldrdn: a boolean field that controls whether the old RDN
- attribute values are to be retained as attributes of the entry, or
- deleted from the entry.
-
- - newSuperior: if present, this is the name of an existing object
- entry which becomes the immediate superior (parent) of the
- existing entry.
-
- The server SHALL NOT dereference any aliases in locating the objects
- named in entry or newSuperior.
-
- Upon receipt of a ModifyDNRequest, a server will attempt to perform
- the name change and return the result in the Modify DN Response,
- defined as follows:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 32 \f
- Lightweight Directory Access Protocol Version 3
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- For example, if the entry named in the entry field was <cn=John
- Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
- newSuperior field was absent, then this operation would attempt to
- rename the entry to be <cn=John Cougar Smith,c=US>. If there was
- already an entry with that name, the operation would fail with the
- entryAlreadyExists result code.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this pertains to newrdn and deleteoldrdn).
-
- The object named in newSuperior MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- If the deleteoldrdn field is TRUE, the attribute values forming the
- old RDN but not the new RDN are deleted from the entry. If the
- deleteoldrdn field is FALSE, the attribute values forming the old RDN
- will be retained as non-distinguished attribute values of the entry.
-
- Note that X.500 restricts the ModifyDN operation to only affect
- entries that are contained within a single server. If the LDAP server
- is mapped onto DAP, then this restriction will apply, and the
- affectsMultipleDSAs result code will be returned if this error
- occurred. In general, clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers or
- between naming contexts.
-
-
-4.10. Compare Operation
-
- The Compare operation allows a client to compare an assertion value
- with the values of a particular attribute in a particular entry in
- the Directory. The Compare Request is defined as follows:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- Fields of the Compare Request are:
-
- - entry: the name of the entry to be compared. The server SHALL NOT
- dereference any aliases in locating the entry to be compared.
-
- - ava: holds the attribute value assertion to be compared.
-
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison and return the result in the Compare
- Response, defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 33 \f
- Lightweight Directory Access Protocol Version 3
-
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- The resultCode is set to compareTrue, compareFalse, or an appropriate
- error. compareTrue indicates that the assertion value in the ava
- field matches a value of the attribute or subtype according to the
- attribute's EQUALITY matching rule. compareFalse indicates that the
- assertion value in the ava field and the values of the attribute or
- subtype did not match. Other result codes indicate either that the
- result of the comparison was Undefined (Section 4.5.1), or that some
- error occurred.
-
- Note that some directory systems may establish access controls which
- permit the values of certain attributes (such as userPassword) to be
- compared but not interrogated by other means.
-
-
-4.11. Abandon Operation
-
- The function of the Abandon operation is to allow a client to request
- that the server abandon an uncompleted operation. The Abandon Request
- is defined as follows:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- The MessageID is that of an operation which was requested earlier at
- this LDAP message layer. The Abandon request itself has its own
- MessageID. This is distinct from the MessageID of the earlier
- operation being abandoned.
-
- There is no response defined in the Abandon operation. Upon receipt
- of an AbandonRequest, the server MAY abandon the operation identified
- by the MessageID. Since the client cannot tell the difference between
- a successfully abandoned operation and an uncompleted operation, the
- application of the Abandon operation is limited to uses where the
- client does not require an indication of its outcome.
-
- Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
-
- In the event that a server receives an Abandon Request on a Search
- operation in the midst of transmitting responses to the Search, that
- server MUST cease transmitting entry responses to the abandoned
- request immediately, and MUST NOT send the SearchResultDone. Of
- course, the server MUST ensure that only properly encoded LDAPMessage
- PDUs are transmitted.
-
- The ability to abandon other (particularly update) operations is at
- the discretion of the server.
-
- Clients should not send Abandon requests for the same operation
- multiple times, and MUST also be prepared to receive results from
- operations it has abandoned (since these may have been in transit
- when the Abandon was requested, or are not able to be abandoned).
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 34 \f
- Lightweight Directory Access Protocol Version 3
-
- Servers MUST discard Abandon requests for message IDs they do not
- recognize, for operations which cannot be abandoned, and for
- operations which have already been abandoned.
-
-
-4.12. Extended Operation
-
- The Extended operation allows additional operations to be defined for
- services not already available in the protocol. For example, to Add
- operations to install transport layer security (see Section 4.14).
-
- The Extended operation allows clients to make requests and receive
- responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations.
-
- Each Extended operation consists of an Extended request and an
- Extended response.
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- The requestName is a dotted-decimal representation of the unique
- OBJECT IDENTIFIER corresponding to the request. The requestValue is
- information in a form defined by that request, encapsulated inside an
- OCTET STRING.
-
- The server will respond to this with an LDAPMessage containing an
- ExtendedResponse.
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- The responseName field, when present, contains an LDAPOID which is
- unique for this extended operation or response. This field is
- optional (even when the extension specification specifies an LDAPOID
- to be returned in the field). The field will be absent whenever the
- server is unable or unwilling to determine the appropriate LDAPOID to
- return, for instance when the requestName cannot be parsed or its
- value is not recognized.
-
- Where the requestName is not recognized, the server returns
- protocolError (The server may return protocolError in other cases).
-
- The requestValue and responseValue fields contain information
- associated with the operation. The format of these fields is defined
- by the specification of the Extended operation. Implementations MUST
- be prepared to handle arbitrary contents of these fields, including
- zero bytes. Values that are defined in terms of ASN.1 and BER encoded
- according to Section 5.1, also follow the extensibility rules in
- Section 4.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 35 \f
- Lightweight Directory Access Protocol Version 3
-
- Servers list the requestName of Extended Requests they recognize in
- the 'supportedExtension' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Extended operations may be specified in other documents. The
- specification of an Extended operation consists of:
-
- - the OBJECT IDENTIFIER assigned to the requestName,
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
- that the same OBJECT IDENTIFIER may be used for both the
- requestName and responseName),
-
- - the format of the contents of the requestValue and responseValue
- (if any), and
-
- - the semantics of the operation.
-
-
-4.13. IntermediateResponse Message
-
- While the Search operation provides a mechanism to return multiple
- response messages for a single Search request, other operations, by
- nature, do not provide for multiple response messages.
-
- The IntermediateResponse message provides a general mechanism for
- defining single-request/multiple-response operations in LDAP. This
- message is intended to be used in conjunction with the Extended
- operation to define new single-request/multiple-response operations
- or in conjunction with a control when extending existing LDAP
- operations in a way that requires them to return Intermediate
- response information.
-
- It is intended that the definitions and descriptions of Extended
- operations and controls that make use of the IntermediateResponse
- message will define the circumstances when an IntermediateResponse
- message can be sent by a server and the associated meaning of an
- IntermediateResponse message sent in a particular circumstance.
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: Extended
- operation and request control. IntermediateResponse messages are
- specified in documents describing the manner in which they are
- solicited (i.e. in the Extended operation or request control
- specification that uses them). These specifications include:
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName,
-
- - the format of the contents of the responseValue (if any), and
-
-Sermersheim Internet-Draft - Expires April 2006 Page 36 \f
- Lightweight Directory Access Protocol Version 3
-
-
- - the semantics associated with the IntermediateResponse message.
-
- Extensions that allow the return of multiple types of
- IntermediateResponse messages SHALL identify those types using unique
- responseName values (note that one of these may specify no value).
-
- Sections 4.13.1 and 4.13.2 describe additional requirements on the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-
-4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages of one or more kinds followed by an
- ExtendedResponse message.
-
-
-4.13.2. Usage with LDAP Request Controls
-
- A control's semantics may include the return of zero or more
- IntermediateResponse messages prior to returning the final result
- code for the operation. One or more kinds of IntermediateResponse
- messages may be sent in response to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when:
-
- - two or more controls using IntermediateResponse messages are
- included in a request for any LDAP operation or
-
- - one or more controls using IntermediateResponse messages are
- included in a request with an LDAP Extended operation that uses
- IntermediateResponse messages.
-
-
-4.14. StartTLS Operation
-
- The Start Transport Layer Security (StartTLS) operation's purpose is
- to initiate installation of a TLS layer. The StartTLS operation is
- defined using the Extended operation mechanism described in Section
- 4.12.
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 37 \f
- Lightweight Directory Access Protocol Version 3
-
-4.14.1. StartTLS Request
-
- A client requests TLS establishment by transmitting a StartTLS
- request message to the server. The StartTLS request is defined in
- terms of an ExtendedRequest. The requestName is
- "1.3.6.1.4.1.1466.20037", and the requestValue field is always
- absent.
-
- The client MUST NOT send any LDAP PDUs at this LDAP message layer
- following this request until it receives a StartTLS Extended response
- and, in the case of a successful response, completes TLS
- negotiations.
-
- Detected sequencing problems (particularly those detailed in Section
- 3.1.1 of [AuthMeth]) result in the resultCode being set to
- operationsError.
-
- If the server does not support TLS (whether by design or by current
- configuration), it returns with the resultCode set to protocolError
- as described in Section 4.12.
-
-
-4.14.2. StartTLS Response
-
- When a StartTLS request is received, servers supporting the operation
- MUST return a StartTLS response message to the requestor. The
- responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12).
- The responseValue is always absent.
-
- If the server is willing and able to negotiate TLS, it returns the
- StartTLS response with the resultCode set to success. Upon client
- receipt of a successful StartTLS response, protocol peers may
- commence with TLS negotiation as discussed in Section 3 of
- [AuthMeth].
-
- If the server is otherwise unwilling or unable to perform this
- operation, the server is to return an appropriate result code
- indicating the nature of the problem. For example, if the TLS
- subsystem is not presently available, the server may indicate so by
- returning with the resultCode set to unavailable. In cases where a
- non-success result code is returned, the LDAP session is left without
- a TLS layer.
-
-
-4.14.3. Removal of the TLS Layer
-
- Either the client or server MAY remove the TLS layer and leave the
- LDAP message layer intact by sending and receiving a TLS closure
- alert.
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 38 \f
- Lightweight Directory Access Protocol Version 3
-
- The initiating protocol peer sends the TLS closure alert and MUST
- wait until it receives a TLS closure alert from the other peer before
- sending further LDAP PDUs.
-
- When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the LDAP message layer to remain intact. In this
- case, it MUST immediately transmit a TLS closure alert. Following
- this, it MAY send and receive LDAP PDUs.
-
- Protocol peers MAY terminate the LDAP session after sending or
- receiving a TLS closure alert.
-
-
-5. Protocol Encoding, Connection, and Transfer
-
- This protocol is designed to run over connection-oriented, reliable
- transports, where the data stream is divided into octets (8-bit
- units), with each octet and each bit being significant.
-
- One underlying service, LDAP over TCP, is defined in Section
- 5.2. This service is generally applicable to applications providing
- or consuming X.500-based directory services on the Internet. This
- specification was generally written with the TCP mapping in mind.
- Specifications detailing other mappings may encounter various
- obstacles.
-
- Implementations of LDAP over TCP MUST implement the mapping as
- described in Section 5.2.
-
- This table illustrates the relationship between the different layers
- involved in an exchange between two protocol peers:
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
-
-5.1. Protocol Encoding
-
- The protocol elements of LDAP SHALL be encoded for exchange using the
- Basic Encoding Rules [BER] of [ASN.1] with the following
- restrictions:
-
- - Only the definite form of length encoding is used.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 39 \f
- Lightweight Directory Access Protocol Version 3
-
-
- - OCTET STRING values are encoded in the primitive form only.
-
- - If the value of a BOOLEAN type is true, the encoding of the value
- octet is set to hex "FF".
-
- - If a value of a type is its default value, it is absent. Only some
- BOOLEAN and INTEGER types have default values in this protocol
- definition.
-
- These restrictions are meant to ease the overhead of encoding and
- decoding certain elements in BER.
-
- These restrictions do not apply to ASN.1 types encapsulated inside of
- OCTET STRING values, such as attribute values, unless otherwise
- stated.
-
-
-5.2. Transmission Control Protocol (TCP)
-
- The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
- bytestream using the BER-based encoding described in Section 5.1. It
- is recommended that server implementations running over the TCP
- provide a protocol listener on the Internet Assigned Numbers
- Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
- instead provide a listener on a different port number. Clients MUST
- support contacting servers on any valid TCP port.
-
-
-5.3. Termination of the LDAP session
-
- Termination of the LDAP session is typically initiated by the client
- sending an UnbindRequest (Section 4.3), or by the server sending a
- Notice of Disconnection (Section 4.4.1). In these cases each protocol
- peer gracefully terminates the LDAP session by ceasing exchanges at
- the LDAP message layer, tearing down any SASL layer, tearing down any
- TLS layer, and closing the transport connection.
-
- A protocol peer may determine that the continuation of any
- communication would be pernicious, and in this case may abruptly
- terminate the session by ceasing communication and closing the
- transport connection.
-
- In either case, when the LDAP session is terminated, uncompleted
- operations are handled as specified in Section 3.1.
-
-
-6. Security Considerations
-
- This version of the protocol provides facilities for simple
- authentication using a cleartext password, as well as any [SASL]
- mechanism. Installing SASL and/or TLS layers can provide integrity
- and other data security services.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 40 \f
- Lightweight Directory Access Protocol Version 3
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
- Use of cleartext password is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
- Servers are encouraged to prevent directory modifications by clients
- that have authenticated anonymously [AuthMeth].
-
- Security considerations for authentication methods, SASL mechanisms,
- and TLS are described in [AuthMeth].
-
- It should be noted that SASL authentication exchanges do not provide
- data confidentiality nor integrity protection for the version or name
- fields of the BindRequest nor the resultCode, diagnosticMessage, or
- referral fields of the BindResponse nor of any information contained
- in controls attached to Bind requests or responses. Thus information
- contained in these fields SHOULD NOT be relied on unless otherwise
- protected (such as by establishing protections at the transport
- layer).
-
- Implementors should note that various security factors, including
- authentication and authorization information and data security
- services may change during the course of the LDAP session, or even
- during the performance of a particular operation. For instance,
- credentials could expire, authorization identities or access controls
- could change, or the underlying security layer(s) could be replaced
- or terminated. Implementations should be robust in the handling of
- changing security factors.
- In some cases, it may be appropriate to continue the operation even
- in light of security factor changes. For instance, it may be
- appropriate to continue an Abandon operation regardless of the
- change, or to continue an operation when the change upgraded (or
- maintained) the security factor. In other cases, it may be
- appropriate to fail, or alter the processing of the operation. For
- instance, if confidential protections were removed, it would be
- appropriate to either fail a request to return sensitive data, or
- minimally, to exclude the return of sensitive data.
-
- Implementations which cache attributes and entries obtained via LDAP
- MUST ensure that access controls are maintained if that information
- is to be provided to multiple clients, since servers may have access
- control policies which prevent the return of entries or attributes in
- Search results except to particular authenticated clients. For
- example, caches could serve result information only to the client
- whose request caused it to be in the cache.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 41 \f
- Lightweight Directory Access Protocol Version 3
-
- Servers may return referrals or Search result references which
- redirect clients to peer servers. It is possible for a rogue
- application to inject such referrals into the data stream in an
- attempt to redirect a client to a rogue server. Clients are advised
- to be aware of this, and possibly reject referrals when
- confidentiality measures are not in place. Clients are advised to
- reject referrals from the StartTLS operation.
-
- The matchedDN and diagnosticMessage fields, as well as some
- resultCode values (e.g., attributeOrValueExists and
- entryAlreadyExists), could disclose the presence or absence of
- specific data in the directory which is subject to access and other
- administrative controls. Server implementations should restrict
- access to protected information equally under both normal and error
- conditions.
-
- Protocol peers MUST be prepared to handle invalid and arbitrary
- length protocol encodings. Invalid protocol encodings include: BER
- encoding exceptions, format string and UTF-8 encoding exceptions,
- overflow exceptions, integer value exceptions, and binary mode on/off
- flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
- excellent examples of these exceptions and test cases used to
- discover flaws.
-
- In the event that a protocol peer senses an attack which in its
- nature could cause damage due to further communication at any layer
- in the LDAP session, the protocol peer should abruptly terminate the
- LDAP session as described in Section 5.3.
-
-
-7. Acknowledgements
-
- This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
- Kille. RFC 2251 was a product of the IETF ASID Working Group.
-
- It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
- Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
-
- It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
- RFC 3771 was an individual submission to the IETF.
-
- This document is a product of the IETF LDAPBIS Working Group.
- Significant contributors of technical review and content include Kurt
- Zeilenga, Steven Legg, and Hallvard Furuseth.
-
-
-8. Normative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
- xx.txt, (a work in progress).
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 42 \f
- Lightweight Directory Access Protocol Version 3
-
- [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
- "Information Technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation"
-
- [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
- Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
- xx.txt, (a work in progress).
-
- [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
- "Information technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER)", 2002.
-
- [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
- September 1981
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
- : 1993.
-
- [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
- work in progress).
-
- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
- ldapbis-bcp64-xx.txt, (a work in progress).
-
- [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
- ldapbis-url-xx.txt, (a work in progress).
-
- [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt (a work in progress).
-
- [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
-
- [SASL] Melnikov, A., "Simple Authentication and Security Layer",
- draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
-
- [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
- passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
- progress).
-
- [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", draft-hoffman-
- rfc3454bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
- Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
- progress).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 43 \f
- Lightweight Directory Access Protocol Version 3
-
-
- [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
- 793, September 1981
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
- draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD63 and RFC3629, November 2003.
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
-
-
-9. Informative References
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
- <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
- dapv3/>
-
- [PortReg] IANA, "Port Numbers",
- http://www.iana.org/assignments/port-numbers
-
-
-10. IANA Considerations
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 44 \f
- Lightweight Directory Access Protocol Version 3
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP result code registry to indicate that this document
- provides the definitive technical specification for result codes 0-
- 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
- (strongAuthRequired) has been renamed (to strongerAuthRequired).
-
- It is requested that the IANA update the LDAP Protocol Mechanism
- registry to indicate that this document and [AuthMeth] provides the
- definitive technical specification for the StartTLS
- (1.3.6.1.4.1.1466.20037) Extended operation.
-
- It is requested that the IANA update the occurrence of "RFC XXXX" in
- this section and Appendix B with this RFC number at publication.
-
- It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [LDAPIANA] to identify the ASN.1 module defined in this
- document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Jim Sermersheim <jimse@novell.com>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP ASN.1 module
-
- [[Note to RFC Editor: please replace the occurrence of <IANA-
- ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
- OID.]]
-
-
-11. Editor's Address
-
- Jim Sermersheim
- Novell, Inc.
- 1800 South Novell Place
- Provo, Utah 84606, USA
- jimse@novell.com
- +1 801 861-3088
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 45 \f
- Lightweight Directory Access Protocol Version 3
-
-Appendix A. LDAP Result Codes
-
- This normative appendix details additional considerations regarding
- LDAP result codes and provides a brief, general description of each
- LDAP result code enumerated in Section 4.1.9.
-
- Additional result codes MAY be defined for use with extensions
- [LDAPIANA]. Client implementations SHALL treat any result code which
- they do not recognize as an unknown error condition.
-
- The descriptions provided here do not fully account for result code
- substitutions used to prevent unauthorized disclosures (such as
- substitution of noSuchObject for insufficientAccessRights, or
- invalidCredentials for insufficientAccessRights).
-
-
-A.1. Non-Error Result Codes
-
- These result codes (called "non-error" result codes) do not indicate
- an error condition:
- success (0),
- compareFalse (5),
- compareTrue (6),
- referral (10), and
- saslBindInProgress (14).
-
- The success, compareTrue, and compareFalse result codes indicate
- successful completion (and, hence, are referred to as "successful"
- result codes).
-
- The referral and saslBindInProgress result codes indicate the client
- needs to take additional action to complete the operation.
-
-
-A.2. Result Codes
-
- Existing LDAP result codes are described as follows:
-
- success (0)
- Indicates the successful completion of an operation. Note:
- this code is not used with the Compare operation. See
- compareFalse (5) and compareTrue (6).
-
- operationsError (1)
- Indicates that the operation is not properly sequenced with
- relation to other operations (of same or different type).
-
- For example, this code is returned if the client attempts to
- StartTLS [TLS] while there are other uncompleted operations
- or if a TLS layer was already installed.
-
- protocolError (2)
- Indicates the server received data which is not well-formed.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 46 \f
- Lightweight Directory Access Protocol Version 3
-
- For Bind operation only, this code is also used to indicate
- that the server does not support the requested protocol
- version.
-
- For Extended operations only, this code is also used to
- indicate that the server does not support (by design or
- configuration) the Extended operation associated with the
- requestName.
-
- For request operations specifying multiple controls, this may
- be used to indicate that the server cannot ignore the order
- of the controls as specified, or that the combination of the
- specified controls is invalid or unspecified.
-
- timeLimitExceeded (3)
- Indicates that the time limit specified by the client was
- exceeded before the operation could be completed.
-
- sizeLimitExceeded (4)
- Indicates that the size limit specified by the client was
- exceeded before the operation could be completed.
-
- compareFalse (5)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to FALSE or
- Undefined.
-
- compareTrue (6)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to TRUE.
-
- authMethodNotSupported (7)
- Indicates that the authentication method or mechanism is not
- supported.
-
- strongerAuthRequired (8)
- Indicates the server requires strong(er) authentication in
- order to complete the operation.
-
- When used with the Notice of Disconnection operation, this
- code indicates that the server has detected that an
- established security association between the client and
- server has unexpectedly failed or been compromised.
-
- referral (10)
- Indicates that a referral needs to be chased to complete the
- operation (see Section 4.1.10).
-
- adminLimitExceeded (11)
- Indicates that an administrative limit has been exceeded.
-
- unavailableCriticalExtension (12)
- Indicates a critical control is unrecognized (see Section
- 4.1.11).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 47 \f
- Lightweight Directory Access Protocol Version 3
-
-
- confidentialityRequired (13)
- Indicates that data confidentiality protections are required.
-
- saslBindInProgress (14)
- Indicates the server requires the client to send a new bind
- request, with the same SASL mechanism, to continue the
- authentication process (see Section 4.2).
-
- noSuchAttribute (16)
- Indicates that the named entry does not contain the specified
- attribute or attribute value.
-
- undefinedAttributeType (17)
- Indicates that a request field contains an unrecognized
- attribute description.
-
- inappropriateMatching (18)
- Indicates that an attempt was made (e.g. in an assertion) to
- use a matching rule not defined for the attribute type
- concerned.
-
- constraintViolation (19)
- Indicates that the client supplied an attribute value which
- does not conform to the constraints placed upon it by the
- data model.
-
- For example, this code is returned when multiple values are
- supplied to an attribute which has a SINGLE-VALUE constraint.
-
- attributeOrValueExists (20)
- Indicates that the client supplied an attribute or value to
- be added to an entry, but the attribute or value already
- exists.
-
- invalidAttributeSyntax (21)
- Indicates that a purported attribute value does not conform
- to the syntax of the attribute.
-
- noSuchObject (32)
- Indicates that the object does not exist in the DIT.
-
- aliasProblem (33)
- Indicates that an alias problem has occurred. For example,
- the code may used to indicate an alias has been dereferenced
- which names no object.
-
- invalidDNSyntax (34)
- Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
- base, target entry, ModifyDN newrdn, etc.) of a request does
- not conform to the required syntax or contains attribute
- values which do not conform to the syntax of the attribute's
- type.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 48 \f
- Lightweight Directory Access Protocol Version 3
-
-
- aliasDereferencingProblem (36)
- Indicates that a problem occurred while dereferencing an
- alias. Typically an alias was encountered in a situation
- where it was not allowed or where access was denied.
-
- inappropriateAuthentication (48)
- Indicates the server requires the client which had attempted
- to bind anonymously or without supplying credentials to
- provide some form of credentials.
-
- invalidCredentials (49)
- Indicates that the provided credentials (e.g. the user's name
- and password) are invalid.
-
- insufficientAccessRights (50)
- Indicates that the client does not have sufficient access
- rights to perform the operation.
-
- busy (51)
- Indicates that the server is too busy to service the
- operation.
-
- unavailable (52)
- Indicates that the server is shutting down or a subsystem
- necessary to complete the operation is offline.
-
- unwillingToPerform (53)
- Indicates that the server is unwilling to perform the
- operation.
-
- loopDetect (54)
- Indicates that the server has detected an internal loop (e.g.
- while dereferencing aliases or chaining an operation).
-
- namingViolation (64)
- Indicates that the entry's name violates naming restrictions.
-
- objectClassViolation (65)
- Indicates that the entry violates object class restrictions.
-
- notAllowedOnNonLeaf (66)
- Indicates that the operation is inappropriately acting upon a
- non-leaf entry.
-
- notAllowedOnRDN (67)
- Indicates that the operation is inappropriately attempting to
- remove a value which forms the entry's relative distinguished
- name.
-
- entryAlreadyExists (68)
- Indicates that the request cannot be fulfilled (added, moved,
- or renamed) as the target entry already exists.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 49 \f
- Lightweight Directory Access Protocol Version 3
-
-
- objectClassModsProhibited (69)
- Indicates that an attempt to modify the object class(es) of
- an entry's 'objectClass' attribute is prohibited.
-
- For example, this code is returned when a client attempts to
- modify the structural object class of an entry.
-
- affectsMultipleDSAs (71)
- Indicates that the operation cannot be performed as it would
- affect multiple servers (DSAs).
-
- other (80)
- Indicates the server has encountered an internal error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 50 \f
- Lightweight Directory Access Protocol Version 3
-
-Appendix B. Complete ASN.1 Definition
-
- This appendix is normative.
-
- Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-
- ASSIGNED-DIRECTORY-NUMBER>}
- -- Copyright (C) The Internet Society (2005). This version of
- -- this ASN.1 module is part of RFC XXXX; see the RFC itself
- -- for full legal notices.
- DEFINITIONS
- IMPLICIT TAGS
- EXTENSIBILITY IMPLIED ::=
-
- BEGIN
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
- -- [LDAPDN]
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 51 \f
- Lightweight Directory Access Protocol Version 3
-
- RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
- -- [LDAPDN]
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
- AttributeValue ::= OCTET STRING
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- MatchingRuleId ::= LDAPString
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 52 \f
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 53 \f
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 54 \f
- Lightweight Directory Access Protocol Version 3
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
-Sermersheim Internet-Draft - Expires April 2006 Page 55 \f
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 56 \f
- Lightweight Directory Access Protocol Version 3
-
-Appendix C. Changes
-
- This appendix is non-normative.
-
- This appendix summarizes substantive changes made to RFC 2251, RFC
- 2830, and RFC 3771.
-
-
-C.1. Changes made to RFC 2251:
-
- This section summarizes the substantive changes made to Sections 1,
- 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
- consult [Models] and [AuthMeth] for summaries of changes to other
- sections.
-
-
-C.1.1. Section 1 (Status of this Memo)
-
- - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
- authentication mechanisms have been standardized which are
- sufficient to remove this note. See [AuthMeth] for authentication
- mechanisms.
-
-
-C.1.2. Section 3.1 (Protocol Model) and others
-
- - Removed notes giving history between LDAP v1, v2 and v3. Instead,
- added sufficient language so that this document can stand on its
- own.
-
-
-C.1.3. Section 4 (Elements of Protocol)
-
- - Clarified where the extensibility features of ASN.1 apply to the
- protocol. This change affected various ASN.1 types by the
- inclusion of ellipses (...) to certain elements.
- - Removed the requirement that servers which implement version 3 or
- later MUST provide the 'supportedLDAPVersion' attribute. This
- statement provided no interoperability advantages.
-
-
-C.1.4. Section 4.1.1 (Message Envelope)
-
- - There was a mandatory requirement for the server to return a
- Notice of Disconnection and drop the transport connection when a
- PDU is malformed in a certain way. This has been updated such that
- the server SHOULD return the Notice of Disconnection, and MUST
- terminate the LDAP Session.
-
-
-C.1.5. Section 4.1.1.1 (Message ID)
-
- - Required that the messageID of requests MUST be non-zero as the
- zero is reserved for Notice of Disconnection.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 57 \f
- Lightweight Directory Access Protocol Version 3
-
- - Specified when it is and isn't appropriate to return an already
- used message id. RFC 2251 accidentally imposed synchronous server
- behavior in its wording of this.
-
-
-C.1.6. Section 4.1.2 (String Types)
-
- - Stated that LDAPOID is constrained to <numericoid> from [Models].
-
-
-C.1.7. Section 4.1.5.1 (Binary Option) and others
-
- - Removed the Binary Option from the specification. There are
- numerous interoperability problems associated with this method of
- alternate attribute type encoding. Work to specify a suitable
- replacement is ongoing.
-
-
-C.1.8. Section 4.1.8 (Attribute)
-
- - Combined the definitions of PartialAttribute and Attribute here,
- and defined Attribute in terms of PartialAttribute.
-
-
-C.1.9. Section 4.1.10 (Result Message)
-
- - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
- be sent for non-error results.
- - Moved some language into Appendix A, and refer the reader there.
- - Allowed matchedDN to be present for other result codes than those
- listed in RFC 2251.
- - renamed the code "strongAuthRequired" to "strongerAuthRequired" to
- clarify that this code may often be returned to indicate that a
- stronger authentication is needed to perform a given operation.
-
-
-C.1.10. Section 4.1.11 (Referral)
-
- - Defined referrals in terms of URIs rather than URLs.
- - Removed the requirement that all referral URIs MUST be equally
- capable of progressing the operation. The statement was ambiguous
- and provided no instructions on how to carry it out.
- - Added the requirement that clients MUST NOT loop between servers.
- - Clarified the instructions for using LDAPURLs in referrals, and in
- doing so added a recommendation that the scope part be present.
- - Removed imperatives which required clients to use URLs in specific
- ways to progress an operation. These did nothing for
- interoperability.
-
-
-C.1.11. Section 4.1.12 (Controls)
-
- - Specified how control values defined in terms of ASN.1 are to be
- encoded.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 58 \f
- Lightweight Directory Access Protocol Version 3
-
- - Noted that the criticality field is only applied to request
- messages (except UnbindRequest), and must be ignored when present
- on response messages and UnbindRequest.
- - Specified that non-critical controls may be ignored at the
- server's discretion. There was confusion in the original wording
- which led some to believe that recognized controls may not be
- ignored as long as they were associated with a proper request.
- - Added language regarding combinations of controls and the ordering
- of controls on a message.
- - Specified that when the semantics of the combination of controls
- is undefined or unknown, it results in a protocolError.
- - Changed "The server MUST be prepared" to "Implementations MUST be
- prepared" in the eighth paragraph to reflect that both client and
- server implementations must be able to handle this (as both parse
- controls).
-
-
-C.1.12. Section 4.2 (Bind Operation)
-
- - Mandated that servers return protocolError when the version is not
- supported.
- - Disambiguated behavior when the simple authentication is used, the
- name is empty and the password is non-empty.
- - Required servers to not dereference aliases for Bind. This was
- added for consistency with other operations and to help ensure
- data consistency.
- - Required that textual passwords be transferred as UTF-8 encoded
- Unicode, and added recommendations on string preparation. This was
- to help ensure interoperability of passwords being sent from
- different clients.
-
-
-C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
-
- - This section was largely reorganized for readability and language
- was added to clarify the authentication state of failed and
- abandoned Bind operations.
- - Removed: "If a SASL transfer encryption or integrity mechanism has
- been negotiated, that mechanism does not support the changing of
- credentials from one identity to another, then the client MUST
- instead establish a new connection."
- If there are dependencies between multiple negotiations of a
- particular SASL mechanism, the technical specification for that
- SASL mechanism details how applications are to deal with them.
- LDAP should not require any special handling.
- - Dropped MUST imperative in paragraph 3 to align with [Keywords].
- - Mandated that clients not send non-Bind operations while a Bind is
- in progress, and suggested that servers not process them if they
- are received. This is needed to ensure proper sequencing of the
- Bind in relationship to other operations.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 59 \f
- Lightweight Directory Access Protocol Version 3
-
-C.1.14. Section 4.2.3 (Bind Response)
-
- - Moved most error-related text to Appendix A, and added text
- regarding certain errors used in conjunction with the Bind
- operation.
- - Prohibited the server from specifying serverSaslCreds when not
- appropriate.
-
-
-C.1.15. Section 4.3 (Unbind Operation)
-
- - Specified that both peers are to cease transmission and terminate
- the LDAP session for the Unbind operation.
-
-
-C.1.16. Section 4.4 (Unsolicited Notification)
-
- - Added instructions for future specifications of Unsolicited
- Notifications.
-
-
-C.1.17. Section 4.5.1 (Search Request)
-
- - SearchRequest attributes is now defined as an AttributeSelection
- type rather than AttributeDescriptionList, and an ABNF is
- provided.
- - SearchRequest attributes may contain duplicate attribute
- descriptions. This was previously prohibited. Now servers are
- instructed to ignore subsequent names when they are duplicated.
- This was relaxed in order to allow different short names and also
- OIDs to be requested for an attribute.
- - The present search filter now evaluates to Undefined when the
- specified attribute is not known to the server. It used to
- evaluate to FALSE, which caused behavior inconsistent with what
- most would expect, especially when the not operator was used.
- - The Filter choice SubstringFilter substrings type is now defined
- with a lower bound of 1.
- - The SubstringFilter substrings 'initial, 'any', and 'final' types
- are now AssertionValue rather than LDAPString. Also, added
- imperatives stating that 'initial' (if present) must be listed
- first, and 'final' (if present) must be listed last.
- - Disambiguated the semantics of the derefAliases choices. There was
- question as to whether derefInSearching applied to the base object
- in a wholeSubtree Search.
- - Added instructions for equalityMatch, substrings, greaterOrEqual,
- lessOrEqual, and approxMatch.
-
-
-C.1.18. Section 4.5.2 (Search Result)
-
- - Recommended that servers not use attribute short names when it
- knows they are ambiguous or may cause interoperability problems.
- - Removed all mention of ExtendedResponse due to lack of
- implementation.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 60 \f
- Lightweight Directory Access Protocol Version 3
-
-
-
-C.1.19. Section 4.5.3 (Continuation References in the Search Result)
-
- - Made changes similar to those made to Section 4.1.11.
-
-
-C.1.20. Section 4.5.3.1 (Example)
-
- - Fixed examples to adhere to changes made to Section 4.5.3.
-
-
-C.1.21. Section 4.6 (Modify Operation)
-
- - Replaced AttributeTypeAndValues with Attribute as they are
- equivalent.
- - Specified the types of modification changes which might
- temporarily violate schema. Some readers were under the impression
- that any temporary schema violation was allowed.
-
-
-C.1.22. Section 4.7 (Add Operation)
-
- - Aligned Add operation with X.511 in that the attributes of the RDN
- are used in conjunction with the listed attributes to create the
- entry. Previously, Add required that the distinguished values be
- present in the listed attributes.
- - Removed requirement that the objectClass attribute MUST be
- specified as some DSE types do not require this attribute.
- Instead, generic wording was added, requiring the added entry to
- adhere to the data model.
- - Removed recommendation regarding placement of objects. This is
- covered in the data model document.
-
-
-C.1.23. Section 4.9 (Modify DN Operation)
-
- - Required servers to not dereference aliases for Modify DN. This
- was added for consistency with other operations and to help ensure
- data consistency.
- - Allow Modify DN to fail when moving between naming contexts.
- - Specified what happens when the attributes of the newrdn are not
- present on the entry.
-
-
-C.1.24. Section 4.10 (Compare Operation)
-
- - Specified that compareFalse means that the Compare took place and
- the result is false. There was confusion which lead people to
- believe that an Undefined match resulted in compareFalse.
- - Required servers to not dereference aliases for Compare. This was
- added for consistency with other operations and to help ensure
- data consistency.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 61 \f
- Lightweight Directory Access Protocol Version 3
-
-
-C.1.25. Section 4.11 (Abandon Operation)
-
- - Explained that since Abandon returns no response, clients should
- not use it if they need to know the outcome.
- - Specified that Abandon and Unbind cannot be abandoned.
-
-
-C.1.26. Section 4.12 (Extended Operation)
-
- - Specified how values of Extended operations defined in terms of
- ASN.1 are to be encoded.
- - Added instructions on what Extended operation specifications
- consist of.
- - Added a recommendation that servers advertise supported Extended
- operations.
-
-
-C.1.27. Section 5.2 (Transfer Protocols)
-
- - Moved referral-specific instructions into referral-related
- sections.
-
-
-C.1.28. Section 7 (Security Considerations)
-
- - Reworded notes regarding SASL not protecting certain aspects of
- the LDAP Bind messages.
- - Noted that Servers are encouraged to prevent directory
- modifications by clients that have authenticated anonymously
- [AuthMeth].
- - Added a note regarding the possibility of changes to security
- factors (authentication, authorization, data confidentiality).
- - Warned against following referrals that may have been injected in
- the data stream.
- - Noted that servers should protect information equally, whether in
- an error condition or not, and mentioned specifically; matchedDN,
- diagnosticMessage, and resultCodes.
- - Added a note regarding malformed and long encodings.
-
-
-C.1.29. Appendix A (Complete ASN.1 Definition)
-
- - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
- - Removed AttributeType. It is not used.
-
-
-C.2. Changes made to RFC 2830:
-
- This section summarizes the substantive changes made to Sections of
- RFC 2830. Readers should consult [AuthMeth] for summaries of changes
- to other sections.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 62 \f
- Lightweight Directory Access Protocol Version 3
-
-C.2.1. Section 2.3 (Response other than "success")
-
- - Removed wording indicating that referrals can be returned from
- StartTLS.
- - Removed requirement that only a narrow set of result codes can be
- returned. Some result codes are required in certain scenarios, but
- any other may be returned if appropriate.
- - Removed requirement that the ExtendedResponse.responseName MUST be
- present. There are circumstances where this is impossible, and
- requiring this is at odds with language in Section 4.12.
-
-
-C.2.1. Section 4 (Closing a TLS Connection)
-
- - Reworded most of this section to align with definitions of the
- LDAP protocol layers.
- - Removed instructions on abrupt closure as this is covered in other
- areas of the document (specifically, Section 5.3)
-
-
-C.3. Changes made to RFC 3771:
-
- - Rewrote to fit into this document. In general, semantics were
- preserved. Supporting and background language seen as redundant
- due to its presence in this document was omitted.
- - Specified that Intermediate responses to a request may be of
- different types, and one of the response types may be specified to
- have no response value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 63 \f
- Lightweight Directory Access Protocol Version 3
-
-
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 64
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
-
-
-
- Lightweight Directory Access Protocol (LDAP):
- Technical Specification Road Map
- <draft-ietf-ldapbis-roadmap-07.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 1]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an Internet
- protocol for accessing distributed directory services which act in
- accordance with X.500 data and service models. This document provides
- a roadmap of the LDAP Technical Specification.
-
-
-Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-1. The LDAP Technical Specification
-
- The technical specification detailing version 3 of the Lightweight
- Directory Access Protocol (LDAP), an Internet Protocol, consists of
- this document and the following documents:
-
- LDAP: The Protocol [Protocol],
- LDAP: Directory Information Models [Models],
- LDAP: Authentication Methods and Connection Level Security
- Mechanisms [AuthMeth],
- LDAP: String Representation of Distinguished Names [LDAPDN],
- LDAP: String Representation of Search Filters [Filters],
- LDAP: Uniform Resource Locator [LDAPURL],
- LDAP: Syntaxes and Matching Rules [Syntaxes],
- LDAP: Internationalized String Preparation [LDAPprep], and
- LDAP: User Schema [Schema].
-
- The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
- the protocol specified by this technical specification. The LDAP
- suite, as defined here, should be formally identified in other
- documents by a normative reference to this document.
-
- LDAP is an extensible protocol. Extensions to LDAP may be specified
- in other documents. Nomenclature denoting such combinations of
- LDAP-plus-extension(s) is not defined by this document but may be
- defined in some future document(s). Extensions are expected to be
- truly optional.
-
- IANA (Internet Assigned Numbers Authority) considerations for LDAP
- described in BCP 64 [BCP64bis] apply fully to this revision of the
- LDAP technical specification.
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 2]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-2. Relationship to X.500
-
- This technical specification defines LDAP in terms of [X.500] as an
- X.500 access mechanism. An LDAP server MUST act in accordance with
- X.500(1993) series of International Telecommunication Union - Telecom
- Standardization (ITU-T) 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 models
- [X.501][X.511] as used in LDAP is not violated in the LDAP interface.
-
- This technical specification explicitly incorporates portions of
- X.500(93). Later revisions of X.500 do not automatically apply to
- this technical specification.
-
-
-3. Security Considerations
-
- LDAP security considerations are discussed in each document comprising
- the technical specification.
-
-
-4. Relationship to Obsolete Specifications
-
- This technical specification, as defined in Section 1, obsoletes
- entirely the previously defined LDAP technical specification [RFC3377]
- (which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
- 3377 itself). The technical specification was significantly
- reorganized.
-
- This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
- [Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
- [Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
- all of RFC 3771. [AuthMeth] replaces RFC 2829, RFC 2830, and portions
- of RFC 2251. [Syntaxes] replaces the majority of RFC 2252 and
- portions of RFC 2256. [Schema] replaces the majority of RFC 2256.
- [LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
- replaces RFC 2255.
-
- [LDAPprep] is new to this revision of the LDAP technical
- specification.
-
- Each document of this specification contains appendices summarizing
- changes to all sections of the specifications they replace. Appendix
- A.1 of this document details changes made to RFC 3377. Appendix A.2
- of this document details changes made to Section 3.3 of RFC 2251.
-
- Additionally, portions of this technical specification update and/or
-
-
-
-Zeilenga LDAP: TS Road Map [Page 3]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- replace a number of other documents not listed above. These
- relationships are discussed in the documents detailings these portions
- of this technical specification.
-
-
-5. Acknowledgments
-
- This document is based largely on RFC 3377 by J. Hodges and R.
- Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
- document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
- Kille, a product of the ASID Working Group.
-
- This document is a product of the IETF LDAPBIS Working Group.
-
-
-6. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-7. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
-
-
-Zeilenga LDAP: TS Road Map [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [LDAPprep] Zeilenga, K., "LDAP: Internationalized String
- Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
- in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
-
-7.2. Informative References
-
- None.
-
-
-Appendix A. Changes to Previous Documents
-
- This appendix outlines changes this document makes relative to the
- documents it replaces (in whole or in part).
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 5]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-Appendix A.1. Changes to RFC 3377
-
- This document is nearly a complete rewrite of RFC 3377 as much of the
- material of RFC 3377 is no longer applicable. The changes include
- redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
- the technical specification.
-
-
-Appendix A.2. Changes to Section 3.3 of RFC 2251
-
- The section was modified slightly (the word "document" was replaced
- with "technical specification") to clarify that it applies to the
- entire LDAP technical specification.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 6]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 7]
-\f
-
-
+++ /dev/null
-
-
-
-
-
-
-Internet-Draft Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 23 January 2006
-
-
-
- LDAP: Internationalized String Preparation
- <draft-ietf-ldapbis-strprep-07.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-
-Zeilenga LDAPprep [Page 1]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-Abstract
-
- The previous Lightweight Directory Access Protocol (LDAP) technical
- specifications did not precisely define how character string matching
- is to be performed. This led to a number of usability and
- interoperability problems. This document defines string preparation
- algorithms for character-based matching rules defined for use in LDAP.
-
-
-Conventions and Terms
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
- In the lists of mappings and the prohibited characters, the "U+" is
- left off to make the lists easier to read. The comments for character
- ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
- and do not come from the standard.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
- The term "combining mark", as used in this specification, refers to
- any Unicode [Unicode] code point which has a mark property (Mn, Mc,
- Me). Appendix A provides a definitive list of combining marks.
-
-
-1. Introduction
-
-1.1. Background
-
- A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
- [Syntaxes] defines an algorithm for determining whether a presented
- value matches an attribute value in accordance with the criteria
- defined for the rule. The proposition may be evaluated to True,
- False, or Undefined.
-
- True - the attribute contains a matching value,
-
- False - the attribute contains no matching value,
-
- Undefined - it cannot be determined whether the attribute contains
- a matching value or not.
-
-
-
-Zeilenga LDAPprep [Page 2]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- For instance, the caseIgnoreMatch matching rule may be used to compare
- whether the commonName attribute contains a particular value without
- regard for case and insignificant spaces.
-
-
-1.2. X.500 String Matching Rules
-
- "X.520: Selected attribute types" [X.520] provides (amongst other
- things) value syntaxes and matching rules for comparing values
- commonly used in the Directory. These specifications are inadequate
- for strings composed of Unicode [Unicode] characters.
-
- The caseIgnoreMatch matching rule [X.520], for example, is simply
- defined as being a case insensitive comparison where insignificant
- spaces are ignored. For printableString, there is only one space
- character and case mapping is bijective, hence this definition is
- sufficient. However, for Unicode string types such as
- universalString, this is not sufficient. For example, a case
- insensitive matching implementation which folded lower case characters
- to upper case would yield different different results than an
- implementation which used upper case to lower case folding. Or one
- implementation may view space as referring to only SPACE (U+0020), a
- second implementation may view any character with the space separator
- (Zs) property as a space, and another implementation may view any
- character with the whitespace (WS) category as a space.
-
- The lack of precise specification for character string matching has
- led to significant interoperability problems. When used in
- certificate chain validation, security vulnerabilities can arise. To
- address these problems, this document defines precise algorithms for
- preparing character strings for matching.
-
-
-1.3. Relationship to "stringprep"
-
- The character string preparation algorithms described in this document
- are based upon the "stringprep" approach [RFC3454]. In "stringprep",
- presented and stored values are first prepared for comparison and so
- that a character-by-character comparison yields the "correct" result.
-
- The approach used here is a refinement of the "stringprep" [RFC3454]
- approach. Each algorithm involves two additional preparation steps.
-
- a) prior to applying the Unicode string preparation steps outlined in
- "stringprep", the string is transcoded to Unicode;
-
- b) after applying the Unicode string preparation steps outlined in
- "stringprep", the string is modified to appropriately handle
-
-
-
-Zeilenga LDAPprep [Page 3]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- characters insignificant to the matching rule.
-
- Hence, preparation of character strings for X.500 matching involves
- the following steps:
-
- 1) Transcode
- 2) Map
- 3) Normalize
- 4) Prohibit
- 5) Check Bidi (Bidirectional)
- 6) Insignificant Character Handling
-
- These steps are described in Section 2.
-
- It is noted that while various tables of Unicode characters included
- or referenced by this specification are derived from Unicode [UNICODE]
- data, these tables are to be considered definitive for the purpose of
- implementing this specification.
-
-
-1.4. Relationship to the LDAP Technical Specification
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification [RFC3377] in its entirety.
-
- This document details new LDAP internationalized character string
- preparation algorithms used by [Syntaxes] and possible other technical
- specifications defining LDAP syntaxes and/or matching rules.
-
-
-1.5. Relationship to X.500
-
- LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
- As such, there is a strong desire for alignment between LDAP and X.500
- syntax and semantics. The character string preparation algorithms
- described in this document are based upon "Internationalized String
- Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
- Group 2.
-
-
-2. String Preparation
-
- The following six-step process SHALL be applied to each presented and
- attribute value in preparation for character string matching rule
- evaluation.
-
- 1) Transcode
-
-
-
-Zeilenga LDAPprep [Page 4]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- 2) Map
- 3) Normalize
- 4) Prohibit
- 5) Check bidi
- 6) Insignificant Character Handling
-
- Failure in any step causes the assertion to evaluate to Undefined.
-
- The character repertoire of this process is Unicode 3.2 [Unicode].
-
- Note that this six-step process specification is intended to described
- expected matching behavior. Implementations are free use alternative
- processes so long as the matching rule evaluation behavior provided is
- consistent with the behavior described by this specification.
-
-
-2.1. Transcode
-
- Each non-Unicode string value is transcoded to Unicode.
-
- PrintableString [X.680] value are transcoded directly to Unicode.
-
- UniversalString, UTF8String, and bmpString [X.680] values need not be
- transcoded as they are Unicode-based strings (in the case of
- bmpString, a subset of Unicode).
-
- TeletexString [X.680] values are transcoded to Unicode. As there is
- no standard for mapping TeletexString values to Unicode, the mapping
- is left a local matter.
-
- For these and other reasons, use of TeletexString is NOT RECOMMENDED.
-
- The output is the transcoded string.
-
-
-2.2. Map
-
- SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
- points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
- VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
- mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
- mapped to nothing.
-
- CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
- TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
- (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
-
- All other control code (e.g., Cc) points or code points with a control
-
-
-
-Zeilenga LDAPprep [Page 5]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- function (e.g., Cf) are mapped to nothing. The following is a
- complete list of these code points: U+0000-0008, 000E-001F, 007F-0084,
- 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
- 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
-
- ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
- with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
- Zp) are mapped to SPACE (U+0020). The following is a complete list of
- these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
- 205F, 3000.
-
- For case ignore, numeric, and stored prefix string matching rules,
- characters are case folded per B.2 of [RFC3454].
-
- The output is the mapped string.
-
-
-2.3. Normalize
-
- The input string is be normalized to Unicode Form KC (compatibility
- composed) as described in [UAX15]. The output is the normalized
- string.
-
-
-2.4. Prohibit
-
- All Unassigned code points are prohibited. Unassigned code points are
- listed in Table A.1 of [RFC3454].
-
- Characters which, per Section 5.8 of [Stringprep], change display
- properties or are deprecated are prohibited. These characters are are
- listed in Table C.8 of [RFC3454].
-
- Private Use code points are prohibited. These characters are listed
- in Table C.3 of [RFC3454].
-
- All non-character code points are prohibited. These code points are
- listed in Table C.4 of [RFC3454].
-
- Surrogate codes are prohibited. These characters are listed in Table
- C.5 of [RFC3454].
-
- The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
-
- The step fails if the input string contains any prohibited code point.
- Otherwise, the output is the input string.
-
-
-
-
-
-Zeilenga LDAPprep [Page 6]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-2.5. Check bidi
-
- Bidirectional characters are ignored.
-
-
-2.6. Insignificant Character Handling
-
- In this step, the string is modified to ensure proper handling of
- characters insignificant to the matching rule. This modification
- differs from matching rule to matching rule.
-
- Section 2.6.1 applies to case ignore and exact string matching.
- Section 2.6.2 applies to numericString matching.
- Section 2.6.3 applies to telephoneNumber matching.
-
-
-2.6.1. Insignificant Space Handling
-
- For the purposes of this section, a space is defined to be the SPACE
- (U+0020) code point followed by no combining marks.
-
- NOTE - The previous steps ensure that the string cannot contain any
- code points in the separator class, other than SPACE (U+0020).
-
- If the input string contains at least one non-space character, then
- the string is modified such that the string starts with exactly one
- space character, ends with exactly one SPACE character, and that any
- inner (non-empty) sequence of space characters is replaced with
- exactly two SPACE characters. For instance, the input strings
- "foo<SPACE>bar<SPACE><SPACE>", results in the output
- "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
-
- Otherwise, if the string being prepared is an initial, any, or final
- substring, then the output string is exactly one SPACE character, else
- the output string is exactly two SPACEs.
-
- Appendix B discusses the rationale for the behavior.
-
-
-2.6.2. numericString Insignificant Character Handling
-
- For the purposes of this section, a space is defined to be the SPACE
- (U+0020) code point followed by no combining marks.
-
- All spaces are regarded as insignificant and are to be removed.
-
- For example, removal of spaces from the Form KC string:
- "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
-
-
-
-Zeilenga LDAPprep [Page 7]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- would result in the output string:
- "123456"
- and the Form KC string:
- "<SPACE><SPACE><SPACE>"
- would result in the output string:
- "" (an empty string).
-
-
-2.6.3. telephoneNumber Insignificant Character Handling
-
- For the purposes of this section, a hyphen is defined to be
- HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
- NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
- (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
- combining marks and a space is defined to be the SPACE (U+0020) code
- point followed by no combining marks.
-
- All hyphens and spaces are considered insignificant and are to be
- removed.
-
- For example, removal of hyphens and spaces from the Form KC string:
- "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
- would result in the output string:
- "123456"
- and the Form KC string:
- "<HYPHEN><HYPHEN><HYPHEN>"
- would result in the (empty) output string:
- "".
-
-
-3. Security Considerations
-
- "Preparation for International Strings ('stringprep')" [RFC3454]
- security considerations generally apply to the algorithms described
- here.
-
-
-4. Acknowledgments
-
- The approach used in this document is based upon design principles and
- algorithms described in "Preparation of Internationalized Strings
- ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
- additional guidance was drawn from Unicode Technical Standards,
- Technical Reports, and Notes.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS) Working
- Group.
-
-
-
-
-Zeilenga LDAPprep [Page 8]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-6. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", RFC 3454,
- December 2002.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
- Unicode Normalization Forms, Version 3.2.0".
- <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
- March 2002.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-Zeilenga LDAPprep [Page 9]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-6.2. Informative References
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.520] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Attribute Types", X.520(1993) (also
- ISO/IEC 9594-6:1994).
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
- for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
- work in progress.
-
-
-Appendix A. Combining Marks
-
- This appendix is normative.
-
- This table was derived from Unicode [Unicode] data
- files, it lists all code points with the Mn, Mc, or Me
- properties. This table is to be considered definitive
- for the purposes of implementation of this
- specification.
-
-
- 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
- 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
- 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
- 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
-
-
-
-Zeilenga LDAPprep [Page 10]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
- 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
- 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
- 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
- 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
- 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
- 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
- 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
- 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
- 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
- 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
- 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
- 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
- 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
- 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
- 1D1AA-1D1AD
-
-
-
-Appendix B. Substrings Matching
-
- This appendix is non-normative.
-
- In absence of substrings matching, the insignificant
- space handling for case ignore/exact matching could be
- simplified. Specifically, the handling could be as
- require all sequences of one or more spaces be replaced
- with one space and, if string contains non-space
- characters, removal of all all leading spaces and
- trailing spaces.
-
- In the presence of substrings matching, this simplified
- space handling would lead to unexpected and undesirable
- matching behavior. For instance:
- 1) (CN=foo\20*\20bar) would match the CN value "foobar" but not
- "foo<SPACE>bar" nor "foo<SPACE><SPACE>bar";
- 2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*)
- would not;
- 3) (CN=foo\20*\20bar) would match "foo<SPACE>X<SPACE>bar" but not
- "foo<SPACE><SPACE>bar".
-
- Note to readers not familiar with LDAP substrings matching: the LDAP
- filter [Filters] assertion (CN=A*B*C) says "match any value (of the
- attribute CN) which begins with A, contains B after A, ends with C
- where C is also after B."
-
- The first case illustrates that this simplified space handling would
- cause leading and trailing spaces in substrings of the string to be
-
-
-
-Zeilenga LDAPprep [Page 11]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- regarded as insignificant. However, only leading and trailing (as
- well as multiple consecutive spaces) of the string (as a whole) are
- insignificant.
-
- The second case illustrates that this simplified space handling would
- cause sub-partitioning failures. That is, if a prepared any substring
- matches a partition of the attribute value, then an assertion
- constructed by subdividing that substring into multiple substrings
- should also match.
-
- The third case illustrates that this simplified space handling causes
- another partitioning failure. Though both the initial or final
- strings match different portions of "foo<SPACE>X<SPACE>bar" with
- neither matching the X portion, they don't match a string consisting
- of the two matched portions less the unmatched X portion.
-
- In designing an appropriate approach for space handling for substrings
- matching, one must study key aspects of X.500 case exact/ignore
- matching. X.520 [X.520] says:
- The [substrings] rule returns TRUE if there is a partitioning of
- the attribute value (into portions) such that:
- - the specified substrings (initial, any, final) match different
- portions of the value in the order of the strings sequence;
- - initial, if present, matches the first portion of the value;
- - final, if present, matches the last portion of the value;
- - any, if present, matches some arbitrary portion of the value.
-
- That is, the substrings assertion (CN=foo\20*\20bar) matches the
- attribute value "foo<SPACE><SPACE>bar" as the value can be partitioned
- into the portions "foo<SPACE>" and "<SPACE>bar" meeting the above
- requirements.
-
- X.520 also says:
- [T]he following spaces are regarded as not significant:
- - leading spaces (i.e. those preceding the first character that is
- not a space);
- - trailing spaces (i.e. those following the last character that is
- not a space);
- - multiple consecutive spaces (these are taken as equivalent to a
- single space character).
-
- This statement applies to the assertion values and attribute values
- as whole strings, and not individually to substrings of an assertion
- value. In particular, the statements should be taken to mean that
- if an assertion value and attribute value match without any
- consideration to insignificant characters, then that assertion value
- should also match any attribute value which differs only by inclusion
- or removal of insignificant characters.
-
-
-
-Zeilenga LDAPprep [Page 12]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- Hence, the assertion (CN=foo\20*\20bar) matches
- "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
- only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
- of insignificant spaces.
-
- Astute readers of this text will also note that there are special
- cases where the specified space handling does not ignore spaces
- which could be considered insignificant. For instance, the assertion
- (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
- (insignificant spaces present in value) nor " " (insignificant
- spaces not present in value). However, as these cases have no
- practical application that cannot be met by simple assertions, e.g.
- (cn=\20), and this minor anomaly can only be fully addressed by a
- preparation algorithm to be used in conjunction with
- character-by-character partitioning and matching, the anomaly is
- considered acceptable.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology described
- in this document or the extent to which any license under such
- rights might or might not be available; nor does it represent that
- it has made any independent effort to identify any such rights.
- Information on the procedures with respect to rights in RFC documents
- can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2006).
-
-
-
-Zeilenga LDAPprep [Page 13]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAPprep [Page 14]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT S. Legg
-draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
-Intended Category: Standards Track 23 June 2005
-Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
-
-
- Lightweight Directory Access Protocol (LDAP):
- Syntaxes and Matching Rules
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Status of this Memo
-
- By submitting this Internet-draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- By submitting this Internet-draft, I accept the provisions of Section
- 3 of BCP 78.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this document is unlimited. Technical discussion of
- this document should take place on the IETF LDAP Revision Working
- Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
- send editorial comments directly to the editor
- <steven.legg@eb2bcom.com>.
-
- This Internet-Draft expires on 23 December 2005.
-
-Abstract
-
-
-
-Legg Expires 23 December 2005 [Page 1]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory, and whose values may be transfered in the LDAP
- protocol, has a defined syntax which constrains the structure and
- format of its values. The comparison semantics for values of a
- syntax are not part of the syntax definition but are instead provided
- through separately defined matching rules. Matching rules specify an
- argument, an assertion value, which also has a defined syntax. This
- document defines a base set of syntaxes and matching rules for use in
- defining attributes for LDAP directories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 23 December 2005 [Page 2]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
- 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.3.1. Attribute Type Description . . . . . . . . . . . 7
- 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
- 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
- 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
- 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
- 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
- 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
- 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
- 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
- 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
- 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
- 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
- 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
- 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
- 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
- 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
- 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
- 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
- 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
- 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
- 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
- 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
- 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
- 3.3.24. Object Class Description . . . . . . . . . . . . 19
- 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
- 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
- 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
- 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
- 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
- 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
- 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
- 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
- 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
- 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
- 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
- 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
- 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
- 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
- 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
- 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
-
-
-
-Legg Expires 23 December 2005 [Page 3]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
- 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
- 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
- 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
- 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
- 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
- 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
- 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
- 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
- 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
- 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
- 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
- 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
- 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
- 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
- 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
- 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
- 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
- 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
- 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
- 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
- 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
- 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
- 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
- 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
- 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
- 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
- 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
- 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
- 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
- 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
- Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
- Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
- Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
- Informative References . . . . . . . . . . . . . . . . . . . . . . 52
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
-
-1. Introduction
-
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory [ROADMAP], and whose values may be transfered in the
- LDAP protocol [PROT], has a defined syntax (i.e., data type) which
- constrains the structure and format of its values. The comparison
- semantics for values of a syntax are not part of the syntax
- definition but are instead provided through separately defined
- matching rules. Matching rules specify an argument, an assertion
-
-
-
-Legg Expires 23 December 2005 [Page 4]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- value, which also has a defined syntax. This document defines a base
- set of syntaxes and matching rules for use in defining attributes for
- LDAP directories.
-
- Readers are advised to familiarize themselves with the Directory
- Information Models [MODELS] before reading the rest of this document.
- Section 3 provides definitions for the base set of LDAP syntaxes.
- Section 4 provides definitions for the base set of matching rules for
- LDAP.
-
- This document is a integral part of the LDAP technical specification
- [ROADMAP] which obsoletes the previously defined LDAP technical
- specification [RFC3377] in its entirety.
-
- Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
- The remainder of RFC 2252 is obsoleted by this document. Sections 6
- and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
- remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
- Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
-
- A number of schema elements which were included in the previous
- revision of the LDAP technical specification are not included in this
- revision of LDAP. Public Key Infrastructure schema elements are now
- specified in [LDAP-PKI]. Unless reintroduced in future technical
- specifications, the remainder are to be considered Historic.
-
- The changes with respect to RFC 2252 are described in Appendix B of
- this document.
-
-2. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, RFC 2119
- [KEYWORD].
-
- Syntax definitions are written according to the <SyntaxDescription>
- ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
- are written according to the <MatchingRuleDescription> ABNF rule
- specified in [MODELS], except that the syntax and matching rule
- definitions provided in this document are line-wrapped for
- readability. When such definitions are transfered as attribute
- values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
- matchingRules attributes [MODELS] respectively) then those values
- would not contain line breaks.
-
-3. Syntaxes
-
-
-
-
-Legg Expires 23 December 2005 [Page 5]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Syntax definitions constrain the structure of attribute values stored
- in an LDAP directory, and determine the representation of attribute
- and assertion values transfered in the LDAP protocol.
-
- Syntaxes that are required for directory operation, or that are in
- common use, are specified in this section. Servers SHOULD recognize
- all the syntaxes listed in this document, but are not required to
- otherwise support them, and MAY recognise or support other syntaxes.
- However, the definition of additional arbitrary syntaxes is
- discouraged since it will hinder interoperability. Client and server
- implementations typically do not have the ability to dynamically
- recognize new syntaxes.
-
-3.1. General Considerations
-
- The description of each syntax specifies how attribute or assertion
- values conforming to the syntax are to be represented when transfered
- in the LDAP protocol [PROT]. This representation is referred to as
- the LDAP-specific encoding to distinguish it from other methods of
- encoding attribute values (e.g., the Basic Encoding Rules (BER)
- encoding [BER] used by X.500 [X.500] directories).
-
- The LDAP-specific encoding of a given attribute syntax always
- produces octet-aligned values. To the greatest extent possible,
- encoding rules for LDAP syntaxes should produce character strings
- that can be displayed with little or no translation by clients
- implementing LDAP. However, clients MUST NOT assume that the
- LDAP-specific encoding of a value of an unrecognized syntax is a
- human-readable character string. There are a few cases (e.g., the
- JPEG syntax) when it is not reasonable to produce a human-readable
- representation.
-
- Each LDAP syntax is uniquely identified with an object identifier
- [ASN.1] represented in the dotted-decimal format (short descriptive
- names are not defined for syntaxes). These object identifiers are
- not intended to be displayed to users. The object identifiers for
- the syntaxes defined in this document are summarized in Appendix A.
-
- A suggested minimum upper bound on the number of characters in an
- attribute value with a string-based syntax, or the number of octets
- in a value for all other syntaxes, MAY be indicated by appending the
- bound inside of curly braces following the syntax's OBJECT IDENTIFIER
- in an attribute type definition (see the <noidlen> rule in [MODELS]).
- Such a bound is not considered part of the syntax identifier.
-
- For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
- definition suggests that the directory server will allow a value of
- the attribute to be up to 64 characters long, although it may allow
-
-
-
-Legg Expires 23 December 2005 [Page 6]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- longer character strings. Note that a single character of the
- Directory String syntax can be encoded in more than one octet since
- UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
- string may be more than 64 octets in length.
-
-3.2. Common Definitions
-
- The following ABNF rules are used in a number of the syntax
- definitions in Section 3.3.
-
- PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
- PLUS / COMMA / HYPHEN / DOT / EQUALS /
- SLASH / COLON / QUESTION / SPACE
- PrintableString = 1*PrintableCharacter
- IA5String = *(%x00-7F)
- SLASH = %x2F ; forward slash ("/")
- COLON = %x3A ; colon (":")
- QUESTION = %x3F ; question mark ("?")
-
- The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
- <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
-
-3.3. Syntax Definitions
-
-3.3.1. Attribute Type Description
-
- A value of the Attribute Type Description syntax is the definition of
- an attribute type. The LDAP-specific encoding of a value of this
- syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
-
- For example, the following definition of the createTimestamp
- attribute type from [MODELS] is also a value of the Attribute Type
- Description syntax (note: line breaks have been added for
- readability - they are not part of the value when transfered in
- protocol).
-
- ( 2.5.18.1 NAME 'createTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The LDAP definition for the Attribute Type Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
-
- This syntax corresponds to the AttributeTypeDescription ASN.1 type
-
-
-
-Legg Expires 23 December 2005 [Page 7]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- from [X.501].
-
-3.3.2. Bit String
-
- A value of the Bit String syntax is a sequence of binary digits. The
- LDAP-specific encoding of a value of this syntax is defined by the
- following ABNF:
-
- BitString = SQUOTE *binary-digit SQUOTE "B"
- binary-digit = "0" / "1"
-
- The <SQUOTE> rule is defined in [MODELS].
-
- Example:
- '0101111101'B
-
- The LDAP definition for the Bit String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
-
- This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
-
-3.3.3. Boolean
-
- A value of the Boolean syntax is one of the Boolean values, true or
- false. The LDAP-specific encoding of a value of this syntax is
- defined by the following ABNF:
-
- Boolean = "TRUE" / "FALSE"
-
- The LDAP definition for the Boolean syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
-
- This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
-
-3.3.4. Country String
-
- A value of the Country String syntax is one of the two-character
- codes from ISO 3166 [ISO3166] for representing a country. The
- LDAP-specific encoding of a value of this syntax is defined by the
- following ABNF:
-
- CountryString = 2(PrintableCharacter)
-
- The <PrintableCharacter> rule is defined in Section 3.2.
-
- Examples:
-
-
-
-Legg Expires 23 December 2005 [Page 8]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- US
- AU
-
- The LDAP definition for the Country String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
-
- This syntax corresponds to the following ASN.1 type from [X.520]:
-
- PrintableString (SIZE (2)) -- ISO 3166 codes only
-
-3.3.5. Delivery Method
-
- A value of the Delivery Method syntax is a sequence of items that
- indicate, in preference order, the service(s) by which an entity is
- willing and/or capable of receiving messages. The LDAP-specific
- encoding of a value of this syntax is defined by the following ABNF:
-
- DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
-
- pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
- "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
-
- The <WSP> and <DOLLAR> rules are defined in [MODELS].
-
- Example:
- telephone $ videotex
-
- The LDAP definition for the Delivery Method syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
-
- This syntax corresponds to the following ASN.1 type from [X.520]:
-
- SEQUENCE OF INTEGER {
- any-delivery-method (0),
- mhs-delivery (1),
- physical-delivery (2),
- telex-delivery (3),
- teletex-delivery (4),
- g3-facsimile-delivery (5),
- g4-facsimile-delivery (6),
- ia5-terminal-delivery (7),
- videotex-delivery (8),
- telephone-delivery (9) }
-
-3.3.6. Directory String
-
-
-
-
-Legg Expires 23 December 2005 [Page 9]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- A value of the Directory String syntax is a string of one or more
- arbitrary characters from the Universal Character Set (UCS) [UCS]. A
- zero length character string is not permitted. The LDAP-specific
- encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
- the character string. Such encodings conform to the following ABNF:
-
- DirectoryString = 1*UTF8
-
- The <UTF8> rule is defined in [MODELS].
-
- Example:
- This is a value of Directory String containing #!%#@.
-
- Servers and clients MUST be prepared to receive arbitrary UCS code
- points, including code points outside the range of printable ASCII
- and code points not presently assigned to any character.
-
- Attribute type definitions using the Directory String syntax should
- not restrict the format of Directory String values, e.g., by
- requiring that the character string conforms to specific patterns
- described by ABNF. A new syntax should be defined in such cases.
-
- The LDAP definition for the Directory String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
-
- This syntax corresponds to the DirectoryString parameterized ASN.1
- type from [X.520].
-
- The DirectoryString ASN.1 type allows a choice between the
- TeletexString, PrintableString or UniversalString ASN.1 types from
- [ASN.1]. However, note that the chosen alternative is not indicated
- in the LDAP-specific encoding of a Directory String value.
-
- Implementations which convert Directory String values from the
- LDAP-specific encoding to the BER encoding used by X.500 must choose
- an alternative that permits the particular characters in the string,
- and must convert the characters from the UTF-8 encoding into the
- character encoding of the chosen alternative. When converting
- Directory String values from the BER encoding to the LDAP-specific
- encoding the characters must be converted from the character encoding
- of the chosen alternative into the UTF-8 encoding. These conversions
- SHOULD be done in a manner consistent with the Transcode step of the
- string preparation algorithms [PREP] for LDAP.
-
-3.3.7. DIT Content Rule Description
-
- A value of the DIT Content Rule Description syntax is the definition
-
-
-
-Legg Expires 23 December 2005 [Page 10]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- of a DIT (Directory Information Tree) content rule. The
- LDAP-specific encoding of a value of this syntax is defined by the
- <DITContentRuleDescription> rule in [MODELS].
-
- Example:
- ( 2.5.6.4 DESC 'content rule for organization'
- NOT ( x121Address $ telexNumber ) )
-
- Note: a line break has been added for readability - it is not part
- of the value.
-
- The LDAP definition for the DIT Content Rule Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.16
- DESC 'DIT Content Rule Description' )
-
- This syntax corresponds to the DITContentRuleDescription ASN.1 type
- from [X.501].
-
-3.3.8. DIT Structure Rule Description
-
- A value of the DIT Structure Rule Description syntax is the
- definition of a DIT structure rule. The LDAP-specific encoding of a
- value of this syntax is defined by the <DITStructureRuleDescription>
- rule in [MODELS].
-
- Example:
- ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
-
- The LDAP definition for the DIT Structure Rule Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.17
- DESC 'DIT Structure Rule Description' )
-
- This syntax corresponds to the DITStructureRuleDescription ASN.1 type
- from [X.501].
-
-3.3.9. DN
-
- A value of the DN syntax is the (purported) distinguished name (DN)
- of an entry [MODELS]. The LDAP-specific encoding of a value of this
- syntax is defined by the <distinguishedName> rule from the string
- representation of distinguished names [LDAPDN].
-
- Examples (from [LDAPDN]):
- UID=jsmith,DC=example,DC=net
- OU=Sales+CN=J. Smith,DC=example,DC=net
- CN=John Smith\, III,DC=example,DC=net
-
-
-
-Legg Expires 23 December 2005 [Page 11]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- CN=Before\0dAfter,DC=example,DC=net
- 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
- CN=Lu\C4\8Di\C4\87
-
- The LDAP definition for the DN syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
-
- The DN syntax corresponds to the DistinguishedName ASN.1 type from
- [X.501]. Note that a BER encoded distinguished name (as used by
- X.500) re-encoded into the LDAP-specific encoding is not necessarily
- reversible to the original BER encoding since the chosen string type
- in any DirectoryString components of the distinguished name is not
- indicated in the LDAP-specific encoding of the distinguished name
- (see Section 3.3.6).
-
-3.3.10. Enhanced Guide
-
- A value of the Enhanced Guide syntax suggests criteria, which consist
- of combinations of attribute types and filter operators, to be used
- in constructing filters to search for entries of particular object
- classes. The Enhanced Guide syntax improves upon the Guide syntax by
- allowing the recommended depth of the search to be specified.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- EnhancedGuide = object-class SHARP WSP criteria WSP
- SHARP WSP subset
- object-class = WSP oid WSP
- subset = "baseobject" / "oneLevel" / "wholeSubtree"
-
- criteria = and-term *( BAR and-term )
- and-term = term *( AMPERSAND term )
- term = EXCLAIM term /
- attributetype DOLLAR match-type /
- LPAREN criteria RPAREN /
- true /
- false
- match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
- true = "?true"
- false = "?false"
- BAR = %x7C ; vertical bar ("|")
- AMPERSAND = %x26 ; ampersand ("&")
- EXCLAIM = %x21 ; exclamation mark ("!")
-
- The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
- <DOLLAR> rules are defined in [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 12]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the Enhanced Guide syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
-
-
- Example:
- person#(sn$EQ)#oneLevel
-
- The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
- from [X.520]. The EnhancedGuide type references the Criteria ASN.1
- type, also from [X.520]. The <true> rule above represents an empty
- "and" expression in a value of the Criteria type. The <false> rule
- above represents an empty "or" expression in a value of the Criteria
- type.
-
-3.3.11. Facsimile Telephone Number
-
- A value of the Facsimile Telephone Number syntax is a subscriber
- number of a facsimile device on the public switched telephone
- network. The LDAP-specific encoding of a value of this syntax is
- defined by the following ABNF:
-
- fax-number = telephone-number *( DOLLAR fax-parameter )
- telephone-number = PrintableString
- fax-parameter = "twoDimensional" /
- "fineResolution" /
- "unlimitedLength" /
- "b4Length" /
- "a3Width" /
- "b4Width" /
- "uncompressed"
-
- The <telephone-number> is a string of printable characters that
- complies with the internationally agreed format for representing
- international telephone numbers [E.123]. The <PrintableString> rule
- is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
-
- The LDAP definition for the Facsimile Telephone Number syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
-
- The Facsimile Telephone Number syntax corresponds to the
- FacsimileTelephoneNumber ASN.1 type from [X.520].
-
-3.3.12. Fax
-
- A value of the Fax syntax is an image which is produced using the
- Group 3 facsimile process [FAX] to duplicate an object, such as a
-
-
-
-Legg Expires 23 December 2005 [Page 13]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- memo. The LDAP-specific encoding of a value of this syntax is the
- string of octets for a Group 3 Fax image as defined in [FAX].
-
- The LDAP definition for the Fax syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
-
- The ASN.1 type corresponding to the Fax syntax is defined as follows,
- assuming EXPLICIT TAGS:
-
- Fax ::= CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
-
- The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
-
-3.3.13. Generalized Time
-
- A value of the Generalized Time syntax is a character string
- representing a date and time. The LDAP-specific encoding of a value
- of this syntax is a restriction of the format defined in [ISO8601],
- and is described by the following ABNF:
-
- GeneralizedTime = century year month day hour
- [ minute [ second / leap-second ] ]
- [ fraction ]
- g-time-zone
-
- century = 2(%x30-39) ; "00" to "99"
- year = 2(%x30-39) ; "00" to "99"
- month = ( %x30 %x31-39 ) ; "01" (January) to "09"
- / ( %x31 %x30-32 ) ; "10" to "12"
- day = ( %x30 %x31-39 ) ; "01" to "09"
- / ( %x31-32 %x30-39 ) ; "10" to "29"
- / ( %x33 %x30-31 ) ; "30" to "31"
- hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
- minute = %x30-35 %x30-39 ; "00" to "59"
-
- second = ( %x30-35 %x30-39 ) ; "00" to "59"
- leap-second = ( %x36 %x30 ) ; "60"
-
- fraction = ( DOT / COMMA ) 1*(%x30-39)
- g-time-zone = %x5A ; "Z"
- / g-differential
- g-differential = ( MINUS / PLUS ) hour [ minute ]
- MINUS = %x2D ; minus sign ("-")
-
- The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 14]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The above ABNF allows character strings which do not represent valid
- dates (in the Gregorian calendar) and/or valid times (e.g., February
- 31, 1994). Such character strings SHOULD be considered invalid for
- this syntax.
-
- The time value represents coordinated universal time (equivalent to
- Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
- otherwise the value represents a local time in the time zone
- indicated by <g-differential>. In the latter case, coordinated
- universal time can be calculated by subtracting the differential from
- the local time. The "Z" form of <g-time-zone> SHOULD be used in
- preference to <g-differential>.
-
- If <minute> is omitted then <fraction> represents a fraction of an
- hour, otherwise if <second> and <leap-second> are omitted then
- <fraction> represents a fraction of a minute, otherwise <fraction>
- represents a fraction of a second.
-
- Examples:
- 199412161032Z
- 199412160532-0500
-
- Both example values represent the same coordinated universal time:
- 10:32 AM, December 16, 1994.
-
- The LDAP definition for the Generalized Time syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
-
- This syntax corresponds to the GeneralizedTime ASN.1 type from
- [ASN.1], with the constraint that local time without a differential
- SHALL NOT be used.
-
-3.3.14. Guide
-
- A value of the Guide syntax suggests criteria, which consist of
- combinations of attribute types and filter operators, to be used in
- constructing filters to search for entries of particular object
- classes. The Guide syntax is obsolete and should not be used for
- defining new attribute types.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- Guide = [ object-class SHARP ] criteria
-
- The <object-class> and <criteria> rules are defined in Section
- 3.3.10. The <SHARP> rule is defined in [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 15]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the Guide syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
-
- The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
-
-3.3.15. IA5 String
-
- A value of the IA5 String syntax is a string of zero, one or more
- characters from International Alphabet 5 (IA5) [T.50], the
- international version of the ASCII character set. The LDAP-specific
- encoding of a value of this syntax is the unconverted string of
- characters, which conforms to the <IA5String> rule in Section 3.2.
-
- The LDAP definition for the IA5 String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
-
- This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
-
-3.3.16. Integer
-
- A value of the Integer syntax is a whole number of unlimited
- magnitude. The LDAP-specific encoding of a value of this syntax is
- the optionally signed decimal digit character string representation
- of the number (so, for example, the number 1321 is represented by the
- character string "1321"). The encoding is defined by the following
- ABNF:
-
- Integer = ( HYPHEN LDIGIT *DIGIT ) / number
-
- The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
- [MODELS].
-
- The LDAP definition for the Integer syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
-
- This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
-
-3.3.17. JPEG
-
- A value of the JPEG syntax is an image in the JPEG File Interchange
- Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
- a value of this syntax is the sequence of octets of the JFIF encoding
- of the image.
-
- The LDAP definition for the JPEG syntax is:
-
-
-
-Legg Expires 23 December 2005 [Page 16]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
-
- The JPEG syntax corresponds to the following ASN.1 type:
-
- JPEG ::= OCTET STRING (CONSTRAINED BY
- { -- contents octets are an image in the --
- -- JPEG File Interchange Format -- })
-
-3.3.18. LDAP Syntax Description
-
- A value of the LDAP Syntax Description syntax is the description of
- an LDAP syntax. The LDAP-specific encoding of a value of this syntax
- is defined by the <SyntaxDescription> rule in [MODELS].
-
- The LDAP definition for the LDAP Syntax Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
-
- The above LDAP definition for the LDAP Syntax Description syntax is
- itself a legal value of the LDAP Syntax Description syntax.
-
- The ASN.1 type corresponding to the LDAP Syntax Description syntax is
- defined as follows, assuming EXPLICIT TAGS:
-
- LDAPSyntaxDescription ::= SEQUENCE {
- identifier OBJECT IDENTIFIER,
- description DirectoryString { ub-schema } OPTIONAL }
-
- The DirectoryString parameterized ASN.1 type is defined in [X.520].
-
- The value of ub-schema (an integer) is implementation defined. A
- non-normative definition appears in [X.520].
-
-3.3.19. Matching Rule Description
-
- A value of the Matching Rule Description syntax is the definition of
- a matching rule. The LDAP-specific encoding of a value of this
- syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
-
- Example:
- ( 2.5.13.2 NAME 'caseIgnoreMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- Note: a line break has been added for readability - it is not part of
- the syntax.
-
- The LDAP definition for the Matching Rule Description syntax is:
-
-
-
-
-Legg Expires 23 December 2005 [Page 17]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
-
- This syntax corresponds to the MatchingRuleDescription ASN.1 type
- from [X.501].
-
-3.3.20. Matching Rule Use Description
-
- A value of the Matching Rule Use Description syntax indicates the
- attribute types to which a matching rule may be applied in an
- extensibleMatch search filter [PROT]. The LDAP-specific encoding of
- a value of this syntax is defined by the <MatchingRuleUseDescription>
- rule in [MODELS].
-
- Example:
- ( 2.5.13.16 APPLIES ( givenName $ surname ) )
-
- The LDAP definition for the Matching Rule Use Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.31
- DESC 'Matching Rule Use Description' )
-
- This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
- from [X.501].
-
-3.3.21. Name and Optional UID
-
- A value of the Name and Optional UID syntax is the distinguished name
- [MODELS] of an entity optionally accompanied by a unique identifier
- that serves to differentiate the entity from others with an identical
- distinguished name.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- NameAndOptionalUID = distinguishedName [ SHARP BitString ]
-
- The <BitString> rule is defined in Section 3.3.2. The
- <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
- defined in [MODELS].
-
- Note that although the '#' character may occur in the string
- representation of a distinguished name, no additional escaping of
- this character is performed when a <distinguishedName> is encoded in
- a <NameAndOptionalUID>.
-
- Example:
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
-
-
-
-
-Legg Expires 23 December 2005 [Page 18]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the Name and Optional UID syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
-
- This syntax corresponds to the NameAndOptionalUID ASN.1 type from
- [X.520].
-
-3.3.22. Name Form Description
-
- A value of the Name Form Description syntax is the definition of a
- name form, which regulates how entries may be named. The
- LDAP-specific encoding of a value of this syntax is defined by the
- <NameFormDescription> rule in [MODELS].
-
- Example:
- ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
-
- The LDAP definition for the Name Form Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
-
- This syntax corresponds to the NameFormDescription ASN.1 type from
- [X.501].
-
-3.3.23. Numeric String
-
- A value of the Numeric String syntax is a sequence of one or more
- numerals and spaces. The LDAP-specific encoding of a value of this
- syntax is the unconverted string of characters, which conforms to the
- following ABNF:
-
- NumericString = 1*(DIGIT / SPACE)
-
- The <DIGIT> and <SPACE> rules are defined in [MODELS].
-
- Example:
- 15 079 672 281
-
- The LDAP definition for the Numeric String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
-
- This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
-
-3.3.24. Object Class Description
-
- A value of the Object Class Description syntax is the definition of
- an object class. The LDAP-specific encoding of a value of this
-
-
-
-Legg Expires 23 December 2005 [Page 19]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- syntax is defined by the <ObjectClassDescription> rule in [MODELS].
-
- Example:
- ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
- MAY ( searchGuide $ description ) )
-
- Note: a line break has been added for readability - it is not part of
- the syntax.
-
- The LDAP definition for the Object Class Description syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
-
- This syntax corresponds to the ObjectClassDescription ASN.1 type from
- [X.501].
-
-3.3.25. Octet String
-
- A value of the Octet String syntax is a sequence of zero, one or more
- arbitrary octets. The LDAP-specific encoding of a value of this
- syntax is the unconverted sequence of octets, which conforms to the
- following ABNF:
-
- OctetString = *OCTET
-
- The <OCTET> rule is defined in [MODELS]. Values of this syntax are
- not generally human-readable.
-
- The LDAP definition for the Octet String syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
-
- This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
-
-3.3.26. OID
-
- A value of the OID syntax is an object identifier; a sequence of two
- or more non-negative integers that uniquely identify some object or
- item of specification. Many of the object identifiers used in LDAP
- also have IANA registered names [RFC3383].
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the <oid> rule in [MODELS].
-
- Examples:
- 1.2.3.4
- cn
-
-
-
-
-Legg Expires 23 December 2005 [Page 20]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the OID syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
-
- This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
- [ASN.1].
-
-3.3.27. Other Mailbox
-
- A value of the Other Mailbox syntax identifies an electronic mailbox,
- in a particular named mail system. The LDAP-specific encoding of a
- value of this syntax is defined by the following ABNF:
-
- OtherMailbox = mailbox-type DOLLAR mailbox
- mailbox-type = PrintableString
- mailbox = IA5String
-
- The <mailbox-type> rule represents the type of mail system in which
- the mailbox resides, for example "MCIMail", and <mailbox> is the
- actual mailbox in the mail system described by <mailbox-type>. The
- <PrintableString> and <IA5String> rules are defined in Section 3.2.
- The <DOLLAR> rule is defined in [MODELS].
-
- The LDAP definition for the Other Mailbox syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
-
- The ASN.1 type corresponding to the Other Mailbox syntax is defined
- as follows, assuming EXPLICIT TAGS:
-
- OtherMailbox ::= SEQUENCE {
- mailboxType PrintableString,
- mailbox IA5String
- }
-
-3.3.28. Postal Address
-
- A value of the Postal Address syntax is a sequence of strings of one
- or more arbitrary UCS characters, which form an address in a physical
- mail system.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- PostalAddress = line *( DOLLAR line )
- line = 1*line-char
- line-char = %x00-23
- / (%x5C "24") ; escaped "$"
-
-
-
-Legg Expires 23 December 2005 [Page 21]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- / %x25-5B
- / (%x5C "5C") ; escaped "\"
- / %x5D-7F
- / UTFMB
-
- Each character string (i.e., <line>) of a postal address value is
- encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
- if they occur in the string, are escaped by a "\" character followed
- by the two hexadecimal digit code for the character. The <DOLLAR>
- and <UTFMB> rules are defined in [MODELS].
-
- Many servers limit the postal address to no more than six lines of no
- more than thirty characters each.
-
- Example:
- 1234 Main St.$Anytown, CA 12345$USA
- \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
-
- The LDAP definition for the Postal Address syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
-
- This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
- i.e.,
-
- PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
- DirectoryString { ub-postal-string }
-
- The values of ub-postal-line and ub-postal-string (both integers) are
- implementation defined. Non-normative definitions appear in [X.520].
-
-3.3.29. Printable String
-
- A value of the Printable String syntax is a string of one or more
- latin alphabetic, numeric, and selected punctuation characters as
- specified by the <PrintableCharacter> rule in Section 3.2.
-
- The LDAP-specific encoding of a value of this syntax is the
- unconverted string of characters, which conforms to the
- <PrintableString> rule in Section 3.2.
-
- Example:
- This is a PrintableString.
-
- The LDAP definition for the PrintableString syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
-
-
-
-
-Legg Expires 23 December 2005 [Page 22]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- This syntax corresponds to the PrintableString ASN.1 type from
- [ASN.1].
-
-3.3.30. Substring Assertion
-
- A value of the Substring Assertion syntax is a sequence of zero, one
- or more character substrings used as an argument for substring
- extensible matching of character string attribute values, i.e., as
- the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
- a string of one or more arbitrary characters from the Universal
- Character Set (UCS) [UCS]. A zero length substring is not permitted.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- SubstringAssertion = [ initial ] any [ final ]
-
- initial = substring
- any = ASTERISK *(substring ASTERISK)
- final = substring
- ASTERISK = %x2A ; asterisk ("*")
-
- substring = 1*substring-character
- substring-character = %x00-29
- / (%x5C "2A") ; escaped "*"
- / %x2B-5B
- / (%x5C "5C") ; escaped "\"
- / %x5D-7F
- / UTFMB
-
- Each <substring> of a Substring Assertion value is encoded as a UTF-8
- [UTF8] string, except that "\" and "*" characters, if they occur in
- the substring, are escaped by a "\" character followed by the two
- hexadecimal digit code for the character.
-
- The Substring Assertion syntax is used only as the syntax of
- assertion values in the extensible match. It is not used as an
- attribute syntax, or in the SubstringFilter [PROT].
-
- The LDAP definition for the Substring Assertion syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
-
- This syntax corresponds to the SubstringAssertion ASN.1 type from
- [X.520].
-
-3.3.31. Telephone Number
-
-
-
-
-Legg Expires 23 December 2005 [Page 23]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- A value of the Telephone Number syntax is a string of printable
- characters that complies with the internationally agreed format for
- representing international telephone numbers [E.123].
-
- The LDAP-specific encoding of a value of this syntax is the
- unconverted string of characters, which conforms to the
- <PrintableString> rule in Section 3.2.
-
- Examples:
- +1 512 315 0280
- +1-512-315-0280
- +61 3 9896 7830
-
- The LDAP definition for the Telephone Number syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
-
- The Telephone Number syntax corresponds to the following ASN.1 type
- from [X.520]:
-
- PrintableString (SIZE(1..ub-telephone-number))
-
- The value of ub-telephone-number (an integer) is implementation
- defined. A non-normative definition appears in [X.520].
-
-3.3.32. Teletex Terminal Identifier
-
- A value of this syntax specifies the identifier and (optionally)
- parameters of a teletex terminal.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- teletex-id = ttx-term *(DOLLAR ttx-param)
- ttx-term = PrintableString ; terminal identifier
- ttx-param = ttx-key COLON ttx-value ; parameter
- ttx-key = "graphic" / "control" / "misc" / "page" / "private"
- ttx-value = *ttx-value-octet
-
- ttx-value-octet = %x00-23
- / (%x5C "24") ; escaped "$"
- / %x25-5B
- / (%x5C "5C") ; escaped "\"
- / %x5D-FF
-
- The <PrintableString> and <COLON> rules are defined in Section 3.2.
- The <DOLLAR> rule is defined in [MODELS].
-
-
-
-
-Legg Expires 23 December 2005 [Page 24]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the Teletex Terminal Identifier syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.51
- DESC 'Teletex Terminal Identifier' )
-
- This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
- from [X.520].
-
-3.3.33. Telex Number
-
- A value of the Telex Number syntax specifies the telex number,
- country code and answerback code of a telex terminal.
-
- The LDAP-specific encoding of a value of this syntax is defined by
- the following ABNF:
-
- telex-number = actual-number DOLLAR country-code
- DOLLAR answerback
- actual-number = PrintableString
- country-code = PrintableString
- answerback = PrintableString
-
- The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
- rule is defined in [MODELS].
-
- The LDAP definition for the Telex Number syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
-
- This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
-
-3.3.34. UTC Time
-
- A value of the UTC Time syntax is a character string representing a
- date and time to a precision of one minute or one second. The year
- is given as a two-digit number. The LDAP-specific encoding of a
- value of this syntax follows the format defined in [ASN.1] for the
- UTCTime type and is described by the following ABNF:
-
- UTCTime = year month day hour minute [ second ]
- [ u-time-zone ]
- u-time-zone = %x5A ; "Z"
- / u-differential
- u-differential = ( MINUS / PLUS ) hour minute
-
- The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
- rules are defined in Section 3.3.13. The <PLUS> rule is defined in
- [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 25]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The above ABNF allows character strings which do not represent valid
- dates (in the Gregorian calendar) and/or valid times. Such character
- strings SHOULD be considered invalid for this syntax.
-
- The time value represents coordinated universal time if the "Z" form
- of <u-time-zone> is used, otherwise the value represents a local
- time. In the latter case, if <u-differential> is provided then
- coordinated universal time can be calculated by subtracting the
- differential from the local time. The <u-time-zone> SHOULD be
- present in time values and the "Z" form of <u-time-zone> SHOULD be
- used in preference to <u-differential>.
-
- The LDAP definition for the UTC Time syntax is:
-
- ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
-
- Note: This syntax is deprecated in favor of the Generalized Time
- syntax.
-
- The UTC Time syntax corresponds to the UTCTime ASN.1 type from
- [ASN.1].
-
-4. Matching Rules
-
- Matching rules are used by directory implementations to compare
- attribute values against assertion values when performing Search and
- Compare operations [PROT]. They are also used when comparing a
- purported distinguished name [MODELS] with the name of an entry.
- When modifying entries, matching rules are used to identify values to
- be deleted and to prevent an attribute from containing two equal
- values.
-
- Matching rules that are required for directory operation, or that are
- in common use, are specified in this section.
-
-4.1. General Considerations
-
- A matching rule is applied to attribute values through an
- AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
- conditions under which an AttributeValueAssertion or
- MatchingRuleAssertion evaluates to Undefined are specified elsewhere
- [PROT]. If an assertion is not Undefined then the result of the
- assertion is the result of applying the selected matching rule. A
- matching rule evaluates to TRUE, and in some cases Undefined, as
- specified in the description of the matching rule, otherwise it
- evaluates to FALSE.
-
- Each assertion contains an assertion value. The definition of each
-
-
-
-Legg Expires 23 December 2005 [Page 26]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- matching rule specifies the syntax for the assertion value. The
- syntax of the assertion value is typically, but not necessarily, the
- same as the syntax of the attribute values to which the matching rule
- may be applied. Note that an AssertionValue in a SubstringFilter
- [PROT] conforms to the assertion syntax of the equality matching rule
- for the attribute type rather than the assertion syntax of the
- substrings matching rule for the attribute type. Conceptually, the
- entire SubstringFilter is converted into an assertion value of the
- substrings matching rule prior to applying the rule.
-
- The definition of each matching rule indicates the attribute syntaxes
- to which the rule may be applied, by specifying conditions the
- corresponding ASN.1 type of a candidate attribute syntax must
- satisfy. These conditions are also satisfied if the corresponding
- ASN.1 type is a tagged or constrained derivative of the ASN.1 type
- explicitly mentioned in the rule description (i.e., ASN.1 tags and
- constraints are ignored in checking applicability), or an alternative
- reference notation for the explicitly mentioned type. Each rule
- description lists as examples of applicable attribute syntaxes, the
- complete list of the syntaxes defined in this document to which the
- matching rule applies. A matching rule may be applicable to
- additional syntaxes defined in other documents if those syntaxes
- satisfy the conditions on the corresponding ASN.1 type.
-
- The description of each matching rule indicates whether the rule is
- suitable for use as the equality matching rule (EQUALITY), ordering
- matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
- attribute type definition [MODELS].
-
- Each matching rule is uniquely identified with an object identifier.
- The definition of a matching rule should not be subsequently changed.
- If a change is desirable then a new matching rule with a different
- object identifier should be defined instead.
-
- Servers MAY implement the wordMatch and keywordMatch matching rules,
- but SHOULD implement the other matching rules in Section 4.2.
- Servers MAY implement additional matching rules.
-
- Servers which implement the extensibleMatch filter SHOULD allow the
- matching rules listed in Section 4.2 to be used in the
- extensibleMatch filter and SHOULD allow matching rules to be used
- with all attribute types known to the server, where the assertion
- syntax of the matching rule is the same as the value syntax of the
- attribute.
-
- Servers MUST publish in the matchingRules attribute, the definitions
- of matching rules referenced by values of the attributeTypes and
- matchingRuleUse attributes in the same subschema entry. Other
-
-
-
-Legg Expires 23 December 2005 [Page 27]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- unreferenced matching rules MAY be published in the matchingRules
- attribute.
-
- If the server supports the extensibleMatch filter, then the server
- MAY use the matchingRuleUse attribute to indicate the applicability
- (in an extensibleMatch filter) of selected matching rules to
- nominated attribute types.
-
-4.2. Matching Rule Definitions
-
- Nominated character strings in assertion and attribute values are
- prepared according to the string preparation algorithms [PREP] for
- LDAP when evaluating the following matching rules:
-
- numericStringMatch,
- numericStringSubstringsMatch,
- caseExactMatch,
- caseExactOrderingMatch,
- caseExactSubstringsMatch,
- caseExactIA5Match,
- caseIgnoreIA5Match,
- caseIgnoreIA5SubstringsMatch,
- caseIgnoreListMatch,
- caseIgnoreListSubstringsMatch,
- caseIgnoreMatch,
- caseIgnoreOrderingMatch,
- caseIgnoreSubstringsMatch,
- directoryStringFirstComponentMatch,
- telephoneNumberMatch,
- telephoneNumberSubstringsMatch and
- wordMatch.
-
- The Transcode, Normalize, Prohibit and Check bidi steps are the same
- for each of the matching rules. However, the Map and Insignificant
- Character Handling steps depends on the specific rule, as detailed in
- the description of these matching rules in the sections that follow.
-
-4.2.1. bitStringMatch
-
- The bitStringMatch rule compares an assertion value of the Bit String
- syntax to an attribute value of a syntax (e.g., the Bit String
- syntax) whose corresponding ASN.1 type is BIT STRING.
-
- If the corresponding ASN.1 type of the attribute syntax does not have
- a named bit list [ASN.1] (which is the case for the Bit String
- syntax) then the rule evaluates to TRUE if and only if the attribute
- value has the same number of bits as the assertion value and the bits
- match on a bitwise basis.
-
-
-
-Legg Expires 23 December 2005 [Page 28]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- If the corresponding ASN.1 type does have a named bit list then
- bitStringMatch operates as above except that trailing zero bits in
- the attribute and assertion values are treated as absent.
-
- The LDAP definition for the bitStringMatch rule is:
-
- ( 2.5.13.16 NAME 'bitStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- The bitStringMatch rule is an equality matching rule.
-
-4.2.2. booleanMatch
-
- The booleanMatch rule compares an assertion value of the Boolean
- syntax to an attribute value of a syntax (e.g., the Boolean syntax)
- whose corresponding ASN.1 type is BOOLEAN.
-
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value are both TRUE or both FALSE.
-
- The LDAP definition for the booleanMatch rule is:
-
- ( 2.5.13.13 NAME 'booleanMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
-
- The booleanMatch rule is an equality matching rule.
-
-4.2.3. caseExactIA5Match
-
- The caseExactIA5Match rule compares an assertion value of the IA5
- String syntax to an attribute value of a syntax (e.g the IA5 String
- syntax) whose corresponding ASN.1 type is IA5String.
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseExactIA5Match rule is:
-
- ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-
-
-
-Legg Expires 23 December 2005 [Page 29]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The caseExactIA5Match rule is an equality matching rule.
-
-4.2.4. caseExactMatch
-
- The caseExactMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
- String, Printable String, Country String or Telephone Number syntax)
- whose corresponding ASN.1 type is DirectoryString or one of the
- alternative string types of DirectoryString, e.g., PrintableString
- (the other alternatives do not correspond to any syntax defined in
- this document).
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseExactMatch rule is:
-
- ( 2.5.13.5 NAME 'caseExactMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The caseExactMatch rule is an equality matching rule.
-
-4.2.5. caseExactOrderingMatch
-
- The caseExactOrderingMatch rule compares an assertion value of the
- Directory String syntax to an attribute value of a syntax (e.g., the
- Directory String, Printable String, Country String or Telephone
- Number syntax) whose corresponding ASN.1 type is DirectoryString or
- one of its alternative string types.
-
- The rule evaluates to TRUE if, and only if, in the code point
- collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
- i.e., the attribute value is "less than" the assertion value.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseExactOrderingMatch rule is:
-
-
-
-Legg Expires 23 December 2005 [Page 30]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- ( 2.5.13.6 NAME 'caseExactOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The caseExactOrderingMatch rule is an ordering matching rule.
-
-4.2.6. caseExactSubstringsMatch
-
- The caseExactSubstringsMatch rule compares an assertion value of the
- Substring Assertion syntax to an attribute value of a syntax (e.g.,
- the Directory String, Printable String, Country String or Telephone
- Number syntax) whose corresponding ASN.1 type is DirectoryString or
- one of its alternative string types.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
- attribute value character string. A prepared substring matches a
- portion of the prepared attribute value character string if
- corresponding characters have the same code point.
-
- In preparing the attribute value and assertion value substrings for
- comparison, characters are not case folded in the Map preparation
- step, and only Insignificant Space Handling is applied in the
- Insignificant Character Handling step.
-
- The LDAP definition for the caseExactSubstringsMatch rule is:
-
- ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The caseExactSubstringsMatch rule is a substrings matching rule.
-
-4.2.7. caseIgnoreIA5Match
-
- The caseIgnoreIA5Match rule compares an assertion value of the IA5
- String syntax to an attribute value of a syntax (e.g the IA5 String
- syntax) whose corresponding ASN.1 type is IA5String.
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are case folded in the Map preparation step, and only
-
-
-
-Legg Expires 23 December 2005 [Page 31]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseIgnoreIA5Match rule is:
-
- ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- The caseIgnoreIA5Match rule is an equality matching rule.
-
-4.2.8. caseIgnoreIA5SubstringsMatch
-
- The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
- the Substring Assertion syntax to an attribute value of a syntax (e.g
- the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
- attribute value character string. A prepared substring matches a
- portion of the prepared attribute value character string if
- corresponding characters have the same code point.
-
- In preparing the attribute value and assertion value substrings for
- comparison, characters are case folded in the Map preparation step,
- and only Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
-
-4.2.9. caseIgnoreListMatch
-
- The caseIgnoreListMatch rule compares an assertion value that is a
- sequence of strings to an attribute value of a syntax (e.g., the
- Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
- OF the DirectoryString ASN.1 type.
-
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of strings and corresponding
- strings (by position) match according to the caseIgnoreMatch matching
- rule.
-
-
-
-
-Legg Expires 23 December 2005 [Page 32]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- In [X.520] the assertion syntax for this matching rule is defined to
- be:
-
- SEQUENCE OF DirectoryString {ub-match}
-
- i.e., different from the corresponding type for the Postal Address
- syntax. The choice of the Postal Address syntax for the assertion
- syntax of the caseIgnoreListMatch in LDAP should not be seen as
- limiting the matching rule to only apply to attributes with the
- Postal Address syntax.
-
- The LDAP definition for the caseIgnoreListMatch rule is:
-
- ( 2.5.13.11 NAME 'caseIgnoreListMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- The caseIgnoreListMatch rule is an equality matching rule.
-
-4.2.10. caseIgnoreListSubstringsMatch
-
- The caseIgnoreListSubstringsMatch rule compares an assertion value of
- the Substring Assertion syntax to an attribute value of a syntax
- (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
- SEQUENCE OF the DirectoryString ASN.1 type.
-
- The rule evaluates to TRUE if and only if the assertion value
- matches, per the caseIgnoreSubstringsMatch rule, the character string
- formed by concatenating the strings of the attribute value, except
- that none of the <initial>, <any>, or <final> substrings of the
- assertion value are considered to match a substring of the
- concatenated string which spans more than one of the original strings
- of the attribute value.
-
- Note that, in terms of the LDAP-specific encoding of the Postal
- Address syntax, the concatenated string omits the <DOLLAR> line
- separator and the escaping of "\" and "$" characters.
-
- The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
-
- ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
-
-4.2.11. caseIgnoreMatch
-
- The caseIgnoreMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
-
-
-
-Legg Expires 23 December 2005 [Page 33]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- String, Printable String, Country String or Telephone Number syntax)
- whose corresponding ASN.1 type is DirectoryString or one of its
- alternative string types.
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseIgnoreMatch rule is:
-
- ( 2.5.13.2 NAME 'caseIgnoreMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The caseIgnoreMatch rule is an equality matching rule.
-
-4.2.12. caseIgnoreOrderingMatch
-
- The caseIgnoreOrderingMatch rule compares an assertion value of the
- Directory String syntax to an attribute value of a syntax (e.g., the
- Directory String, Printable String, Country String or Telephone
- Number syntax) whose corresponding ASN.1 type is DirectoryString or
- one of its alternative string types.
-
- The rule evaluates to TRUE if, and only if, in the code point
- collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
- i.e., the attribute value is "less than" the assertion value.
-
- In preparing the attribute value and assertion value for comparison,
- characters are case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseIgnoreOrderingMatch rule is:
-
- ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The caseIgnoreOrderingMatch rule is an ordering matching rule.
-
-4.2.13. caseIgnoreSubstringsMatch
-
-
-
-
-Legg Expires 23 December 2005 [Page 34]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The caseIgnoreSubstringsMatch rule compares an assertion value of the
- Substring Assertion syntax to an attribute value of a syntax (e.g.,
- the Directory String, Printable String, Country String or Telephone
- Number syntax) whose corresponding ASN.1 type is DirectoryString or
- one of its alternative string types.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
- attribute value character string. A prepared substring matches a
- portion of the prepared attribute value character string if
- corresponding characters have the same code point.
-
- In preparing the attribute value and assertion value substrings for
- comparison, characters are case folded in the Map preparation step,
- and only Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
-
- The LDAP definition for the caseIgnoreSubstringsMatch rule is:
-
- ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The caseIgnoreSubstringsMatch rule is a substrings matching rule.
-
-4.2.14. directoryStringFirstComponentMatch
-
- The directoryStringFirstComponentMatch rule compares an assertion
- value of the Directory String syntax to an attribute value of a
- syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
- first component of the DirectoryString ASN.1 type.
-
- Note that the assertion syntax of this matching rule differs from the
- attribute syntax of attributes for which this is the equality
- matching rule.
-
- The rule evaluates to TRUE if and only if the assertion value matches
- the first component of the attribute value using the rules of
- caseIgnoreMatch.
-
- The LDAP definition for the directoryStringFirstComponentMatch
- matching rule is:
-
- ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-
-Legg Expires 23 December 2005 [Page 35]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The directoryStringFirstComponentMatch rule is an equality matching
- rule. When using directoryStringFirstComponentMatch to compare two
- attribute values (of an applicable syntax), an assertion value must
- first be derived from one of the attribute values. An assertion
- value can be derived from an attribute value by taking the first
- component of that attribute value.
-
-4.2.15. distinguishedNameMatch
-
- The distinguishedNameMatch rule compares an assertion value of the DN
- syntax to an attribute value of a syntax (e.g., the DN syntax) whose
- corresponding ASN.1 type is DistinguishedName.
-
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of relative distinguished names
- and corresponding relative distinguished names (by position) are the
- same. A relative distinguished name (RDN) of the assertion value is
- the same as an RDN of the attribute value if and only if they have
- the same number of attribute value assertions and each attribute
- value assertion (AVA) of the first RDN is the same as the AVA of the
- second RDN with the same attribute type. The order of the AVAs is
- not significant. Also note that a particular attribute type may
- appear in at most one AVA in an RDN. Two AVAs with the same
- attribute type are the same if their values are equal according to
- the equality matching rule of the attribute type. If one or more of
- the AVA comparisons evaluate to Undefined and the remaining AVA
- comparisons return TRUE then the distinguishedNameMatch rule
- evaluates to Undefined.
-
- The LDAP definition for the distinguishedNameMatch rule is:
-
- ( 2.5.13.1 NAME 'distinguishedNameMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The distinguishedNameMatch rule is an equality matching rule.
-
-4.2.16. generalizedTimeMatch
-
- The generalizedTimeMatch rule compares an assertion value of the
- Generalized Time syntax to an attribute value of a syntax (e.g the
- Generalized Time syntax) whose corresponding ASN.1 type is
- GeneralizedTime.
-
- The rule evaluates to TRUE if and only if the attribute value
- represents the same universal coordinated time as the assertion
- value. If a time is specified with the minutes or seconds absent
- then the number of minutes or seconds (respectively) is assumed to be
- zero.
-
-
-
-Legg Expires 23 December 2005 [Page 36]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the generalizedTimeMatch rule is:
-
- ( 2.5.13.27 NAME 'generalizedTimeMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- The generalizedTimeMatch rule is an equality matching rule.
-
-4.2.17. generalizedTimeOrderingMatch
-
- The generalizedTimeOrderingMatch rule compares the time ordering of
- an assertion value of the Generalized Time syntax to an attribute
- value of a syntax (e.g the Generalized Time syntax) whose
- corresponding ASN.1 type is GeneralizedTime.
-
- The rule evaluates to TRUE if and only if the attribute value
- represents a universal coordinated time which is earlier than the
- universal coordinated time represented by the assertion value.
-
- The LDAP definition for the generalizedTimeOrderingMatch rule is:
-
- ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- The generalizedTimeOrderingMatch rule is an ordering matching rule.
-
-4.2.18. integerFirstComponentMatch
-
- The integerFirstComponentMatch rule compares an assertion value of
- the Integer syntax to an attribute value of a syntax (e.g the DIT
- Structure Rule Description syntax) whose corresponding ASN.1 type is
- a SEQUENCE with a mandatory first component of the INTEGER ASN.1
- type.
-
- Note that the assertion syntax of this matching rule differs from the
- attribute syntax of attributes for which this is the equality
- matching rule.
-
- The rule evaluates to TRUE if and only if the assertion value and the
- first component of the attribute value are the same integer value.
-
- The LDAP definition for the integerFirstComponentMatch matching rule
- is:
-
- ( 2.5.13.29 NAME 'integerFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- The integerFirstComponentMatch rule is an equality matching rule.
- When using integerFirstComponentMatch to compare two attribute values
-
-
-
-Legg Expires 23 December 2005 [Page 37]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- (of an applicable syntax), an assertion value must first be derived
- from one of the attribute values. An assertion value can be derived
- from an attribute value by taking the first component of that
- attribute value.
-
-4.2.19. integerMatch
-
- The integerMatch rule compares an assertion value of the Integer
- syntax to an attribute value of a syntax (e.g the Integer syntax)
- whose corresponding ASN.1 type is INTEGER.
-
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value are the same integer value.
-
- The LDAP definition for the integerMatch matching rule is:
-
- ( 2.5.13.14 NAME 'integerMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- The integerMatch rule is an equality matching rule.
-
-4.2.20. integerOrderingMatch
-
- The integerOrderingMatch rule compares an assertion value of the
- Integer syntax to an attribute value of a syntax (e.g the Integer
- syntax) whose corresponding ASN.1 type is INTEGER.
-
- The rule evaluates to TRUE if and only if the integer value of the
- attribute value is less than the integer value the assertion value.
-
- The LDAP definition for the integerOrderingMatch matching rule is:
-
- ( 2.5.13.15 NAME 'integerOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- The integerOrderingMatch rule is an ordering matching rule.
-
-4.2.21. keywordMatch
-
- The keywordMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
- String syntax) whose corresponding ASN.1 type is DirectoryString.
-
- The rule evaluates to TRUE if and only if the assertion value
- character string matches any keyword in the attribute value. The
- identification of keywords in the attribute value and the exactness
- of the match are both implementation specific.
-
-
-
-
-Legg Expires 23 December 2005 [Page 38]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The LDAP definition for the keywordMatch rule is:
-
- ( 2.5.13.33 NAME 'keywordMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-4.2.22. numericStringMatch
-
- The numericStringMatch rule compares an assertion value of the
- Numeric String syntax to an attribute value of a syntax (e.g the
- Numeric String syntax) whose corresponding ASN.1 type is
- NumericString.
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- numericString Insignificant Character Handling is applied in the
- Insignificant Character Handling step.
-
- The LDAP definition for the numericStringMatch matching rule is:
-
- ( 2.5.13.8 NAME 'numericStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- The numericStringMatch rule is an equality matching rule.
-
-4.2.23. numericStringOrderingMatch
-
- The numericStringOrderingMatch rule compares an assertion value of
- the Numeric String syntax to an attribute value of a syntax (e.g the
- Numeric String syntax) whose corresponding ASN.1 type is
- NumericString.
-
- The rule evaluates to TRUE if, and only if, in the code point
- collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
- i.e., the attribute value is "less than" the assertion value.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- numericString Insignificant Character Handling is applied in the
- Insignificant Character Handling step.
-
- The rule is identical to the caseIgnoreOrderingMatch rule except that
- all space characters are skipped during comparison (case is
-
-
-
-Legg Expires 23 December 2005 [Page 39]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- irrelevant as characters are numeric).
-
- The LDAP definition for the numericStringOrderingMatch matching rule
- is:
-
- ( 2.5.13.9 NAME 'numericStringOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- The numericStringOrderingMatch rule is an ordering matching rule.
-
-4.2.24. numericStringSubstringsMatch
-
- The numericStringSubstringsMatch rule compares an assertion value of
- the Substring Assertion syntax to an attribute value of a syntax (e.g
- the Numeric String syntax) whose corresponding ASN.1 type is
- NumericString.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
- attribute value character string. A prepared substring matches a
- portion of the prepared attribute value character string if
- corresponding characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- numericString Insignificant Character Handling is applied in the
- Insignificant Character Handling step.
-
- The LDAP definition for the numericStringSubstringsMatch matching
- rule is:
-
- ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The numericStringSubstringsMatch rule is a substrings matching rule.
-
-4.2.25. objectIdentifierFirstComponentMatch
-
- The objectIdentifierFirstComponentMatch rule compares an assertion
- value of the OID syntax to an attribute value of a syntax (e.g the
- Attribute Type Description, DIT Content Rule Description, LDAP Syntax
- Description, Matching Rule Description, Matching Rule Use
- Description, Name Form Description or Object Class Description
- syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
-
-
-
-Legg Expires 23 December 2005 [Page 40]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- first component of the OBJECT IDENTIFIER ASN.1 type.
-
- Note that the assertion syntax of this matching rule differs from the
- attribute syntax of attributes for which this is the equality
- matching rule.
-
- The rule evaluates to TRUE if and only if the assertion value matches
- the first component of the attribute value using the rules of
- objectIdentifierMatch.
-
- The LDAP definition for the objectIdentifierFirstComponentMatch
- matching rule is:
-
- ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- The objectIdentifierFirstComponentMatch rule is an equality matching
- rule. When using objectIdentifierFirstComponentMatch to compare two
- attribute values (of an applicable syntax), an assertion value must
- first be derived from one of the attribute values. An assertion
- value can be derived from an attribute value by taking the first
- component of that attribute value.
-
-4.2.26. objectIdentifierMatch
-
- The objectIdentifierMatch rule compares an assertion value of the OID
- syntax to an attribute value of a syntax (e.g the OID syntax) whose
- corresponding ASN.1 type is OBJECT IDENTIFIER.
-
- The rule evaluates to TRUE if and only if the assertion value and the
- attribute value represent the same object identifier, that is, the
- same sequence of integers, whether represented explicitly in the
- <numericoid> form of <oid> or implicitly in the <descr> form (see
- [MODELS]).
-
- If an LDAP client supplies an assertion value in the <descr> form,
- and the chosen descriptor is not recognized by the server, then the
- objectIdentifierMatch rule evaluates to Undefined.
-
- The LDAP definition for the objectIdentifierMatch matching rule is:
-
- ( 2.5.13.0 NAME 'objectIdentifierMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- The objectIdentifierMatch rule is an equality matching rule.
-
-4.2.27. octetStringMatch
-
-
-
-
-Legg Expires 23 December 2005 [Page 41]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The octetStringMatch rule compares an assertion value of the Octet
- String syntax to an attribute value of a syntax (e.g the Octet String
- or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
- ASN.1 type.
-
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value are the same length and corresponding octets (by
- position) are the same.
-
- The LDAP definition for the octetStringMatch matching rule is:
-
- ( 2.5.13.17 NAME 'octetStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
- The octetStringMatch rule is an equality matching rule.
-
-4.2.28. octetStringOrderingMatch
-
- The octetStringOrderingMatch rule compares an assertion value of the
- Octet String syntax to an attribute value of a syntax (e.g the Octet
- String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
- STRING ASN.1 type.
-
- The rule evaluates to TRUE if and only if the attribute value appears
- earlier in the collation order than the assertion value. The rule
- compares octet strings from the first octet to the last octet, and
- from the most significant bit to the least significant bit within the
- octet. The first occurrence of a different bit determines the
- ordering of the strings. A zero bit precedes a one bit. If the
- strings contain different numbers of octets but the longer string is
- identical to the shorter string up to the length of the shorter
- string then the shorter string precedes the longer string.
-
- The LDAP definition for the octetStringOrderingMatch matching rule
- is:
-
- ( 2.5.13.18 NAME 'octetStringOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
- The octetStringOrderingMatch rule is an ordering matching rule.
-
-4.2.29. telephoneNumberMatch
-
- The telephoneNumberMatch rule compares an assertion value of the
- Telephone Number syntax to an attribute value of a syntax (e.g the
- Telephone Number syntax) whose corresponding ASN.1 type is a
- PrintableString representing a telephone number.
-
-
-
-
-Legg Expires 23 December 2005 [Page 42]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The rule evaluates to TRUE if and only if the prepared attribute
- value character string and the prepared assertion value character
- string have the same number of characters and corresponding
- characters have the same code point.
-
- In preparing the attribute value and assertion value for comparison,
- characters are case folded in the Map preparation step, and only
- telephoneNumber Insignificant Character Handling is applied in the
- Insignificant Character Handling step.
-
- The LDAP definition for the telephoneNumberMatch matching rule is:
-
- ( 2.5.13.20 NAME 'telephoneNumberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumberMatch rule is an equality matching rule.
-
-4.2.30. telephoneNumberSubstringsMatch
-
- The telephoneNumberSubstringsMatch rule compares an assertion value
- of the Substring Assertion syntax to an attribute value of a syntax
- (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
- PrintableString representing a telephone number.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
- attribute value character string. A prepared substring matches a
- portion of the prepared attribute value character string if
- corresponding characters have the same code point.
-
- In preparing the attribute value and assertion value substrings for
- comparison, characters are case folded in the Map preparation step,
- and only telephoneNumber Insignificant Character Handling is applied
- in the Insignificant Character Handling step.
-
- The LDAP definition for the telephoneNumberSubstringsMatch matching
- rule is:
-
- ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- The telephoneNumberSubstringsMatch rule is a substrings matching
- rule.
-
-
-
-
-Legg Expires 23 December 2005 [Page 43]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
-4.2.31. uniqueMemberMatch
-
- The uniqueMemberMatch rule compares an assertion value of the Name
- And Optional UID syntax to an attribute value of a syntax (e.g the
- Name And Optional UID syntax) whose corresponding ASN.1 type is
- NameAndOptionalUID.
-
- The rule evaluates to TRUE if and only if the <distinguishedName>
- components of the assertion value and attribute value match according
- to the distinguishedNameMatch rule and either, the <BitString>
- component is absent from both the attribute value and assertion
- value, or the <BitString> component is present in both the attribute
- value and the assertion value and the <BitString> component of the
- assertion value matches the <BitString> component of the attribute
- value according to the bitStringMatch rule.
-
- Note that this matching rule has been altered from its description in
- X.520 [X.520] in order to make the matching rule commutative. Server
- implementors should consider using the original X.520 semantics
- (where the matching was less exact) for approximate matching of
- attributes with uniqueMemberMatch as the equality matching rule.
-
- The LDAP definition for the uniqueMemberMatch matching rule is:
-
- ( 2.5.13.23 NAME 'uniqueMemberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
- The uniqueMemberMatch rule is an equality matching rule.
-
-4.2.32. wordMatch
-
- The wordMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
- String syntax) whose corresponding ASN.1 type is DirectoryString.
-
- The rule evaluates to TRUE if and only if the assertion value word
- matches, according to the semantics of caseIgnoreMatch, any word in
- the attribute value. The precise definition of a word is
- implementation specific.
-
- The LDAP definition for the wordMatch rule is:
-
- ( 2.5.13.32 NAME 'wordMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-5. Security Considerations
-
- In general, the LDAP-specific encodings for syntaxes defined in this
-
-
-
-Legg Expires 23 December 2005 [Page 44]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- document do not define canonical encodings. That is, a
- transformation from an LDAP-specific encoding into some other
- encoding (e.g., BER) and back into the LDAP-specific encoding will
- not necessarily reproduce exactly the original octets of the
- LDAP-specific encoding. Therefore an LDAP-specific encoding should
- not be used where a canonical encoding is required.
-
- Furthermore, the LDAP-specific encodings do not necessarily enable an
- alternative encoding of values of the Directory String and DN
- syntaxes to be reconstructed, e.g., a transformation from a
- Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
- encoding and back to a DER encoding may not reproduce the original
- DER encoding. Therefore LDAP-specific encodings should not be used
- where reversibility to DER is needed, e.g., for the verification of
- digital signatures. Instead, DER or a DER-reversible encoding should
- be used.
-
- When interpreting security-sensitive fields, and in particular fields
- used to grant or deny access, implementations MUST ensure that any
- matching rule comparisons are done on the underlying abstract value,
- regardless of the particular encoding used.
-
-6. Acknowledgements
-
- This document is primarily a revision of RFC 2252 by M. Wahl, A.
- Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
- ASID Working Group.
-
- This document is based upon input of the IETF LDAPBIS working group.
- The author would like to thank Kathy Dally for editing the early
- drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
- their significant contributions to this revision.
-
-7. IANA Considerations
-
- The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP descriptors registry [BCP64] as indicated by the following
- templates:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
- Person & email address to contact for further information:
- Steven Legg <steven.legg@eb2bcom.com>
- Usage: see comment
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
-
-
-
-Legg Expires 23 December 2005 [Page 45]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The following descriptors (short names) should be updated to refer
- to RFC XXXX.
-
- NAME Type OID
- ------------------------------------------------------------------
- bitStringMatch M 2.5.13.16
- booleanMatch M 2.5.13.13
- caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
- caseExactMatch M 2.5.13.5
- caseExactOrderingMatch M 2.5.13.6
- caseExactSubstringsMatch M 2.5.13.7
- caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
- caseIgnoreListMatch M 2.5.13.11
- caseIgnoreListSubstringsMatch M 2.5.13.12
- caseIgnoreMatch M 2.5.13.2
- caseIgnoreOrderingMatch M 2.5.13.3
- caseIgnoreSubstringsMatch M 2.5.13.4
- directoryStringFirstComponentMatch M 2.5.13.31
- distinguishedNameMatch M 2.5.13.1
- generalizedTimeMatch M 2.5.13.27
- generalizedTimeOrderingMatch M 2.5.13.28
- integerFirstComponentMatch M 2.5.13.29
- integerMatch M 2.5.13.14
- integerOrderingMatch M 2.5.13.15
- keywordMatch M 2.5.13.33
- numericStringMatch M 2.5.13.8
- numericStringOrderingMatch M 2.5.13.9
- numericStringSubstringsMatch M 2.5.13.10
- objectIdentifierFirstComponentMatch M 2.5.13.30
- octetStringMatch M 2.5.13.17
- octetStringOrderingMatch M 2.5.13.18
- telephoneNumberMatch M 2.5.13.20
- telephoneNumberSubstringsMatch M 2.5.13.21
- uniqueMemberMatch M 2.5.13.23
- wordMatch M 2.5.13.32
-
- The descriptor for the object identifier 2.5.13.0 was incorrectly
- registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
- It should be changed to the following with a reference to
- RFC XXXX.
-
- NAME Type OID
- ------------------------------------------------------------------
- objectIdentifierMatch M 2.5.13.0
-
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): caseIgnoreIA5SubstringsMatch
-
-
-
-Legg Expires 23 December 2005 [Page 46]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Object Identifier: 1.3.6.1.4.1.1466.109.114.3
- Person & email address to contact for further information:
- Steven Legg <steven.legg@eb2bcom.com>
- Usage: other (M)
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-Appendix A. Summary of Syntax Object Identifiers
-
- The following list summarizes the object identifiers assigned to the
- syntaxes defined in this document.
-
- Syntax OBJECT IDENTIFIER
- ==============================================================
- Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
- Bit String 1.3.6.1.4.1.1466.115.121.1.6
- Boolean 1.3.6.1.4.1.1466.115.121.1.7
- Country String 1.3.6.1.4.1.1466.115.121.1.11
- Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
- Directory String 1.3.6.1.4.1.1466.115.121.1.15
- DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
- DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
- DN 1.3.6.1.4.1.1466.115.121.1.12
- Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
- Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
- Fax 1.3.6.1.4.1.1466.115.121.1.23
- Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
- Guide 1.3.6.1.4.1.1466.115.121.1.25
- IA5 String 1.3.6.1.4.1.1466.115.121.1.26
- Integer 1.3.6.1.4.1.1466.115.121.1.27
- JPEG 1.3.6.1.4.1.1466.115.121.1.28
- LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
- Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
- Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
- Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
- Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
- Numeric String 1.3.6.1.4.1.1466.115.121.1.36
- Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
- Octet String 1.3.6.1.4.1.1466.115.121.1.40
- OID 1.3.6.1.4.1.1466.115.121.1.38
- Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
- Postal Address 1.3.6.1.4.1.1466.115.121.1.41
- Printable String 1.3.6.1.4.1.1466.115.121.1.44
- Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
- Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
- Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
- Telex Number 1.3.6.1.4.1.1466.115.121.1.52
- UTC Time 1.3.6.1.4.1.1466.115.121.1.53
-
-
-
-Legg Expires 23 December 2005 [Page 47]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
-Appendix B. Changes from RFC 2252
-
- This annex lists the significant differences between this
- specification and RFC 2252.
-
- This annex is provided for informational purposes only. It is not a
- normative part of this specification.
-
- 1. The IESG Note has been removed.
-
- 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
- and revised. Changes to the parts of these sections moved to
- [MODELS] are detailed in [MODELS].
-
- 3. BNF descriptions of syntax formats have been replaced by ABNF
- [ABNF] specifications.
-
- 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
- use of a backslash quoting mechanism to escape separator symbols
- has been removed. The escaping mechanism is now explicitly
- represented in the ABNF for the syntaxes where this provision
- applies.
-
- 5. The description of each of the LDAP syntaxes has been expanded so
- that they are less dependent on knowledge of X.500 for
- interpretation.
-
- 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
- definitions has been made explicit.
-
- 7. The set of characters allowed in a <PrintableString> (formerly
- <printablestring>) has been corrected to align with the
- PrintableString ASN.1 type in [ASN.1]. Specifically, the double
- quote character has been removed and the single quote character
- and equals sign have been added.
-
- 8. Values of the Directory String, Printable String and Telephone
- Number syntaxes are now required to have at least one character.
-
- 9. The <DITContentRuleDescription>, <NameFormDescription> and
- <DITStructureRuleDescription> rules have been moved to [MODELS].
-
- 10. The corresponding ASN.1 type for the Other Mailbox syntax has
- been incorporated from RFC 1274.
-
- 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
- has been invented.
-
-
-
-
-Legg Expires 23 December 2005 [Page 48]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- 12. The Binary syntax has been removed because it was not adequately
- specified, implementations with different incompatible
- interpretations exist, and it was confused with the ;binary
- transfer encoding.
-
- 13. All discussion of transfer options, including the ";binary"
- option, has been removed. All imperatives regarding binary
- transfer of values have been removed.
-
- 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
- Terminal Identifier and Telex Number syntaxes from RFC 2256 have
- been incorporated.
-
- 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
- been extended to accommodate empty "and" and "or" expressions.
-
- 16. An encoding for the <ttx-value> rule in the Teletex Terminal
- Identifier syntax has been defined.
-
- 17. The PKI-related syntaxes (Certificate, Certificate List and
- Certificate Pair) have been removed. They are reintroduced in
- [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
-
- 18. The MHS OR Address syntax has been removed since its
- specification (in RFC 2156) is not at draft standard maturity.
-
- 19. The DL Submit Permission syntax has been removed as it depends on
- the MHS OR Address syntax.
-
- 20. The Presentation Address syntax has been removed since its
- specification (in RFC 1278) is not at draft standard maturity.
-
- 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
- Type, LDAP Schema Description, Master And Shadow Access Points,
- Modify Rights, Protocol Information, Subtree Specification,
- Supplier Information, Supplier Or Consumer and Supplier And
- Consumer syntaxes have been removed. These syntaxes are
- referenced in RFC 2252, but not defined.
-
- 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
- Mail Preference syntax have been removed on the grounds that they
- are out of scope for the core specification.
-
- 23. The description of each of the matching rules has been expanded
- so that they are less dependent on knowledge of X.500 for
- interpretation.
-
- 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
-
-
-
-Legg Expires 23 December 2005 [Page 49]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- been added.
-
- 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
- caseIgnoreSubstringsMatch matching rules have been added to the
- list of matching rules for which the provisions for handling
- leading, trailing and multiple adjoining whitespace characters
- apply (now through string preparation). This is consistent with
- the definitions of these matching rules in X.500. The
- caseIgnoreIA5SubstringsMatch rule has also been added to the
- list.
-
- 26. The specification of the octetStringMatch matching rule from
- RFC 2256 has been added to this document.
-
- 27. The presentationAddressMatch matching rule has been removed as it
- depends on an assertion syntax (Presentation Address) that is not
- at draft standard maturity.
-
- 28. The protocolInformationMatch matching rule has been removed as it
- depends on an undefined assertion syntax (Protocol Information).
-
- 29. The definitive reference for ASN.1 has been changed from X.208 to
- X.680 since X.680 is the version of ASN.1 referred to by X.500.
-
- 30. The specification of the caseIgnoreListSubstringsMatch matching
- rule from RFC 2798 & X.520 has been added.
-
- 31. String preparation algorithms have been applied to the character
- string matching rules.
-
- 32. The specifications of the booleanMatch, caseExactMatch,
- caseExactOrderingMatch, caseExactSubstringsMatch,
- directoryStringFirstComponentMatch, integerOrderingMatch,
- keywordMatch, numericStringOrderingMatch,
- octetStringOrderingMatch and wordMatch matching rules from
- RFC 3698 & X.520 have been added.
-
-Normative References
-
- [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, November 2003.
-
- [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-
-
-Legg Expires 23 December 2005 [Page 50]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
- xx.txt, a work in progress, March 2005.
-
- [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map", draft-ietf-
- ldapbis-roadmap-xx.txt, a work in progress, February 2005.
-
- [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt, a work in progress, February
- 2005.
-
- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
- protocol-xx.txt, a work in progress, May 2005.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress, February 2005.
-
- [PREP] Zeilenga, K., "LDAP: Internationalized String
- Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
- progress, February 2005.
-
- [E.123] Notation for national and international telephone numbers,
- ITU-T Recommendation E.123, 1988.
-
- [FAX] Standardization of Group 3 facsimile apparatus for
- document transmission - Terminal Equipment and Protocols
- for Telematic Services, ITU-T Recommendation T.4, 1993
-
- [T.50] International Reference Alphabet (IRA) (Formerly
- International Alphabet No. 5 or IA5) Information
- Technology - 7-Bit Coded Character Set for Information
- Interchange, ITU-T Recommendation T.50, 1992
-
- [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
- Information Technology - Message Handling Systems (MHS):
- Interpersonal messaging system
-
- [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Models
-
- [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Selected attribute types
-
- [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
-
-
-
-Legg Expires 23 December 2005 [Page 51]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Information technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation
-
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
-
- [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
- Information interchange -- Representation of dates and
- times".
-
- [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1: 1993 (with amendments).
-
- [JPEG] JPEG File Interchange Format (Version 1.02). Eric
- Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
- 1992.
-
-Informative References
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Additional Matching Rules", RFC 3698, February
- 2004.
-
- [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
- April 2005.
-
- [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates", draft-
- zeilenga-ldap-x509-xx.txt, a work in progress, February
- 2005.
-
- [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services
-
-
-
-
-Legg Expires 23 December 2005 [Page 52]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
- Information technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER)
-
-Author's Address
-
- Steven Legg
- eB2Bcom
- Suite3, Woodhouse Corporate Centre
- 935 Station Street
- Box Hill North, Victoria 3129
- AUSTRALIA
-
- Phone: +61 3 9896 7830
- Fax: +61 3 9896 7801
- EMail: steven.legg@eb2bcom.com
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
-
-
-
-Legg Expires 23 December 2005 [Page 53]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 23 December 2005 [Page 54]
-\f
+++ /dev/null
-
-
-
-Network Working Group Mark Smith, Editor
-Request for Comments: DRAFT Pearl Crescent, LLC
-Obsoletes: RFC 2255 Tim Howes
-Expires: 4 July 2005 Opsware, Inc.
-
- 4 January 2005
-
-
- LDAP: Uniform Resource Locator
- <draft-ietf-ldapbis-url-09.txt>
-
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she become
- aware will be disclosed, in accordance with RFC 3668.
-
- This document is intended to be published as a Standards Track RFC,
- replacing RFC 2255. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF
- LDAP (v3) Revision (ldapbis) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <mcs@pearlcrescent.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 1]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
-Abstract
-
- This document describes a format for a Lightweight Directory Access
- Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
- describes an LDAP search operation that is used to retrieve
- information from an LDAP directory, or, in the context of an LDAP
- referral or reference, an LDAP URL describes a service where an LDAP
- operation may be progressed.
-
-Table of Contents
-
- Status of this Memo............................................1
- Abstract.......................................................2
- Table of Contents..............................................2
-1. Introduction...................................................2
-2. URL Definition.................................................3
-2.1. Percent-Encoding............................................5
-3. Defaults for Fields of the LDAP URL............................5
-4. Examples.......................................................6
-5. Security Considerations........................................8
-6. IANA Considerations............................................9
-7. Normative References...........................................9
-8. Informative References.........................................10
-9. Acknowledgements...............................................10
-10. Authors' Addresses.............................................11
-11. Appendix A: Changes Since RFC 2255.............................11
-11.1. Technical Changes...........................................11
-11.2. Editorial Changes...........................................12
-12. Appendix B: Changes Since Previous Document Revision...........14
-12.1. Technical Changes...........................................14
-12.2. Editorial Changes...........................................14
- Intellectual Property Rights...................................14
- Full Copyright.................................................15
-
-1. Introduction
-
- LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
- document specifies the LDAP URL format for version 3 of LDAP and
- clarifies how LDAP URLs are resolved. This document also defines an
- extension mechanism for LDAP URLs. This mechanism may be used to
- provide access to new LDAP extensions.
-
- Note that not all of the parameters of the LDAP search operation
- described in [Protocol] can be expressed using the format defined in
- this document. Note also that URLs may be used to represent reference
- knowledge, including for non-search operations.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 2]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
- This document replaces RFC 2255. See Appendix A for a list of changes
- relative to RFC 2255.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-2. URL Definition
-
- An LDAP URL begins with the protocol prefix "ldap" and is defined by
- the following grammar, following the ABNF notation defined in
- [RFC2234].
-
- ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
- [SLASH dn [QUESTION [attributes]
- [QUESTION [scope] [QUESTION [filter]
- [QUESTION extensions]]]]]
- ; <host> and <port> are defined
- ; in Sections 3.2.2 and 3.2.3
- ; of [RFC2396bis].
- ; <filter> is from Section 3 of
- ; [Filters], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- scheme = "ldap"
-
- dn = distinguishedName ; From Section 3 of [LDAPDN],
- ; subject to the provisions of
- ; the "Percent-Encoding"
- ; section below.
-
- attributes = attrdesc *(COMMA attrdesc)
- attrdesc = selector *(COMMA selector)
- selector = attributeSelector ; From Section 4.5.1 of
- ; [Protocol], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- scope = "base" / "one" / "sub"
- extensions = extension *(COMMA extension)
- extension = [EXCLAMATION] extype [EQUALS exvalue]
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 3]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- extype = oid ; From section 1.4 of [Models].
-
- exvalue = LDAPString ; From section 4.1.2 of
- ; [Protocol], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- EXCLAMATION = %x21 ; exclamation mark ("!")
- SLASH = %x2F ; forward slash ("/")
- COLON = %x3A ; colon (":")
- QUESTION = %x3F ; question mark ("?")
-
-
- The "ldap" prefix indicates an entry or entries accessible from the
- LDAP server running on the given hostname at the given portnumber.
- Note that the <host> may contain literal IPv6 addresses as specified
- in Section 3.2.2 of [RFC2396bis].
-
- The <dn> is an LDAP Distinguished Name using the string format
- described in [LDAPDN]. It identifies the base object of the LDAP
- search or the target of a non-search operation.
-
- The <attributes> construct is used to indicate which attributes
- should be returned from the entry or entries.
-
- The <scope> construct is used to specify the scope of the search to
- perform in the given LDAP server. The allowable scopes are "base"
- for a base object search, "one" for a one-level search, or "sub" for
- a subtree search.
-
- The <filter> is used to specify the search filter to apply to entries
- within the specified scope during the search. It has the format
- specified in [Filters].
-
- The <extensions> construct provides the LDAP URL with an
- extensibility mechanism, allowing the capabilities of the URL to be
- extended in the future. Extensions are a simple comma-separated list
- of type=value pairs, where the =value portion MAY be omitted for
- options not requiring it. Each type=value pair is a separate
- extension. These LDAP URL extensions are not necessarily related to
- any of the LDAP extension mechanisms. Extensions may be supported or
- unsupported by the client resolving the URL. An extension prefixed
- with a '!' character (ASCII 0x21) is critical. An extension not
- prefixed with a '!' character is non-critical.
-
- If an LDAP URL extension is implemented (that is, if the
- implementation understands it and is able to use it), the
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- implementation MUST make use of it. If an extension is not
- implemented and is marked critical, the implementation MUST NOT
- process the URL. If an extension is not implemented and it not
- marked critical, the implementation MUST ignore the extension.
-
- The extension type (<extype>) MAY be specified using the numeric OID
- <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
- (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
- restricted to registered object identifier descriptive names. See
- [LDAPIANA] for registration details and usage guidelines for
- descriptive names.
-
- No LDAP URL extensions are defined in this document. Other documents
- or a future version of this document MAY define one or more
- extensions.
-
-2.1. Percent-Encoding
-
- A generated LDAP URL MUST consist only of the restricted set of
- characters included in one of the following three productions defined
- in [RFC2396bis]:
-
- <reserved>
- <unreserved>
- <pct-encoded>
-
- Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
- input. An octet MUST be encoded using the percent-encoding mechanism
- described in section 2.1 of [RFC2396bis] in any of these situations:
-
- The octet is not in the reserved set defined in section 2.2 of
- [RFC2396bis] or in the unreserved set defined in section 2.3 of
- [RFC2396bis].
-
- It is the single Reserved character '?' and occurs inside a <dn>,
- <filter>, or other element of an LDAP URL.
-
- It is a comma character ',' that occurs inside an <exvalue>.
-
- Note that before the percent-encoding mechanism is applied, the
- extensions component of the LDAP URL may contain one or more null
- (zero) bytes. No other component may.
-
-3. Defaults for Fields of the LDAP URL
-
- Some fields of the LDAP URL are optional, as described above. In the
- absence of any other specification, the following general defaults
- SHOULD be used when a field is absent. Note that other documents MAY
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- specify different defaulting rules; for example, section 4.1.10 of
- [Protocol] specifies a different rule for determining the correct DN
- to use when it is absent in an LDAP URL that is returned as a
- referral.
-
- <host>
- If no <host> is given, the client must have some apriori knowledge
- of an appropriate LDAP server to contact.
-
- <port>
- The default LDAP port is TCP port 389.
-
- <dn>
- If no <dn> is given, the default is the zero-length DN, "".
-
- <attributes>
- If the <attributes> part is omitted, all user attributes of the
- entry or entries should be requested (e.g., by setting the
- attributes field AttributeDescriptionList in the LDAP search
- request to a NULL list, or by using the special <alluserattrs>
- selector "*").
-
- <scope>
- If <scope> is omitted, a <scope> of "base" is assumed.
-
- <filter>
- If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
-
- <extensions>
- If <extensions> is omitted, no extensions are assumed.
-
-
-4. Examples
-
- The following are some example LDAP URLs using the format defined
- above. The first example is an LDAP URL referring to the University
- of Michigan entry, available from an LDAP server of the client's
- choosing:
-
- ldap:///o=University%20of%20Michigan,c=US
-
- The next example is an LDAP URL referring to the University of
- Michigan entry in a particular ldap server:
-
- ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
-
- Both of these URLs correspond to a base object search of the
- "o=University of Michigan,c=US" entry using a filter of
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 6]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- "(objectclass=*)", requesting all attributes.
-
- The next example is an LDAP URL referring to only the postalAddress
- attribute of the University of Michigan entry:
-
- ldap://ldap1.example.net/o=University%20of%20Michigan,
- c=US?postalAddress
-
- The corresponding LDAP search operation is the same as in the
- previous example, except that only the postalAddress attribute is
- requested.
-
- The next example is an LDAP URL referring to the set of entries found
- by querying the given LDAP server on port 6666 and doing a subtree
- search of the University of Michigan for any entry with a common name
- of "Babs Jensen", retrieving all attributes:
-
- ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
- c=US??sub?(cn=Babs%20Jensen)
-
- The next example is an LDAP URL referring to all children of the c=GB
- entry:
-
- LDAP://ldap1.example.com/c=GB?objectClass?ONE
-
- The objectClass attribute is requested to be returned along with the
- entries, and the default filter of "(objectclass=*)" is used.
-
- The next example is an LDAP URL to retrieve the mail attribute for
- the LDAP entry named "o=Question?,c=US" is given below, illustrating
- the use of the percent-encoding mechanism on the reserved character
- '?'.
-
- ldap://ldap2.example.com/o=Question%3f,c=US?mail
-
- The next example (which is broken into two lines for readability)
- illustrates the interaction between the LDAP string representation of
- filters quoting mechanism and URL quoting mechanisms.
-
- ldap://ldap3.example.com/o=Babsco,c=US
- ???(four-octet=%5c00%5c00%5c00%5c04)
-
- The filter in this example uses the LDAP escaping mechanism of \ to
- encode three zero or null bytes in the value. In LDAP, the filter
- would be written as (four-octet=\00\00\00\04). Because the \
- character must be escaped in a URL, the \'s are percent-encoded as
- %5c (or %5C) in the URL encoding.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 7]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- The next example illustrates the interaction between the LDAP string
- representation of DNs quoting mechanism and URL quoting mechanisms.
-
- ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
-
- The DN encoded in the above URL is:
-
- o=An Example\2C Inc.,c=US
-
- That is, the left-most RDN value is:
-
- An Example, Inc.
-
- The following three URLs that are equivalent, assuming that the
- defaulting rules specified in section 4 of this document are used:
-
- ldap://ldap.example.net
- ldap://ldap.example.net/
- ldap://ldap.example.net/?
-
- These three URLs all point to the root DSE on the ldap.example.net
- server.
-
-The final two examples show use of a hypothetical, experimental bind
-name extension (the value associated with the extension is an LDAP DN).
-
- ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
- ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
-
- The two URLs are the same, except that the second one marks the
- e-bindname extension as critical. Notice the use of the
- percent-encoding mechanism to encode the commas within the
- distinguished name value in the e-bindname extension.
-
-
-5. Security Considerations
-
- General URL security considerations discussed in [RFC2396bis] are
- relevant for LDAP URLs.
-
- The use of security mechanisms when processing LDAP URLs requires
- particular care, since clients may encounter many different servers
- via URLs, and since URLs are likely to be processed automatically,
- without user intervention. A client SHOULD have a user-configurable
- policy that controls which servers the client will establish LDAP
- sessions with using which security mechanisms, and SHOULD NOT
- establish LDAP sessions that are inconsistent with this policy. If a
- client chooses to reuse an existing LDAP session when resolving one
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- or more LDAP URLs, it MUST ensure that the session is compatible with
- the URL and that no security policies are violated.
-
- Sending authentication information, no matter the mechanism, may
- violate a user's privacy requirements. In the absence of specific
- policy permitting authentication information to be sent to a server,
- a client should use an anonymous LDAP session. (Note that clients
- conforming to previous LDAP URL specifications, where all LDAP
- sessions are anonymous and unprotected, are consistent with this
- specification; they simply have the default security policy.) Simply
- opening a transport connection to another server may violate some
- users' privacy requirements, so clients should provide the user with
- a way to control URL processing.
-
- Some authentication methods, in particular reusable passwords sent to
- the server, may reveal easily-abused information to the remote server
- or to eavesdroppers in transit, and should not be used in URL
- processing unless explicitly permitted by policy. Confirmation by
- the human user of the use of authentication information is
- appropriate in many circumstances. Use of strong authentication
- methods that do not reveal sensitive information is much preferred.
- If the URL represents a referral for an update operation, strong
- authentication methods SHOULD be used. Please refer to the Security
- Considerations section of [AuthMeth] for more information.
-
- The LDAP URL format allows the specification of an arbitrary LDAP
- search operation to be performed when evaluating the LDAP URL.
- Following an LDAP URL may cause unexpected results, for example, the
- retrieval of large amounts of data, the initiation of a long-lived
- search, etc. The security implications of resolving an LDAP URL are
- the same as those of resolving an LDAP search query.
-
-6. IANA Considerations
-
- This document has no actions for IANA.
-
-7. Normative References
-
-[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
- work in progress.
-
-[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress.
-
-[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
- Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- progress.
-
-[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, BCP 14, March 1997.
-
-[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
-[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
-[RFC2396bis]
- Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
- Resource Identifiers (URI): Generic Syntax",
- draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
-
-[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
-[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 3629, November 2003.
-
-8. Informative References
-
-[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
-
-9. Acknowledgements
-
- The LDAP URL format was originally defined at the University of
- Michigan. This material is based upon work supported by the National
- Science Foundation under Grant No. NCR-9416667. The support of both
- the University of Michigan and the National Science Foundation is
- gratefully acknowledged.
-
- This document is an update to RFC 2255 by Tim Howes and Mark Smith.
- Changes included in this revised specification are based upon
- discussions among the authors, discussions within the LDAP (v3)
- Revision Working Group (ldapbis), and discussions within other IETF
- Working Groups. The contributions of individuals in these working
- groups is gratefully acknowledged. Several people in particular have
- made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
- Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
- thanks for their contributions.
-
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
-10. Authors' Addresses
-
- Mark Smith, Editor
- Pearl Crescent, LLC
- 447 Marlpool Dr.
- Saline, MI 48176
- USA
- +1 734 944-2856
- mcs@pearlcrescent.com
-
- Tim Howes
- Opsware, Inc.
- 599 N. Mathilda Ave.
- Sunnyvale, CA 94085
- USA
- +1 408 744-7509
- howes@opsware.com
-
-11. Appendix A: Changes Since RFC 2255
-
-11.1. Technical Changes
-
- The following technical changes were made to the contents of the "URL
- Definition" section:
-
- Revised all of the ABNF to use common productions from [Models].
-
- Replaced references to [RFC2396] with a reference to [RFC2396bis]
- (this allows literal IPv6 addresses to be used inside the <host>
- portion of the URL, and a note was added to remind the reader of this
- enhancement). Referencing [RFC2396bis] required changes to the ABNF
- and text so that productions that are no longer defined by
- [RFC2396bis] are not used. For example, <hostport> is not defined by
- [RFC2396bis] so it has been replaced with host [COLON port]. Note:
- [RFC2396bis] includes new definitions for the "Reserved" and
- "Unreserved" sets of characters, and the net result is that the
- following two additional characters should be percent-encoded when
- they appear anywhere in the data used to construct an LDAP URL: "["
- and "]" (these two characters were first added to the Reserved set by
- RFC 2732).
-
- Changed the definition of <attrdesc> to refer to <attributeSelector>
- from [Protocol]. This allows use of "*" in the <attrdesc> part of
- the URL. It is believed that existing implementations of RFC 2255
- already support this.
-
- Avoided use of <prose-val> (bracketed-string) productions in the
- <dn>, <host>, <attrdesc>, and <exvalue> rules.
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 11]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- Changed the ABNF for <ldapurl> to group the <dn> component with the
- preceding <SLASH>.
-
- Changed the <extype> rule to be an <oid> from [Models].
-
- Changed the text about extension types so it references [LDAPIANA].
- Reordered rules to more closely follow the order the elements appear
- in the URL.
-
- "Bindname Extension": removed due to lack of known implementations.
-
-
-11.2. Editorial Changes
-
- Changed document title to include "LDAP:" prefix.
-
- IESG Note: removed note about lack of satisfactory mandatory
- authentication mechanisms.
-
- "Status of this Memo" section: updated boilerplate to match current
- I-D guidelines.
-
- "Abstract" section: separated from introductory material.
-
- "Table of Contents" and "IANA Considerations" sections: added.
-
- "Introduction" section: new section; separated from the Abstract.
- Changed the text indicate that RFC 2255 is replaced by this document
- (instead of RFC 1959). Added text to indicate that LDAP URLs are
- used for references and referrals. Fixed typo (replaced the nonsense
- phrase "to perform to retrieve" with "used to retrieve"). Added a
- note to let the reader know that not all of the parameters of the
- LDAP search operation described in [Protocol] can be expressed using
- this format.
-
- "URL Definition" section: removed second copy of <ldapurl> grammar
- and following two paragraphs (editorial error in RFC 2255). Fixed
- line break within '!' sequence. Reformatted the ABNF to improve
- readability by aligning comments and adding some blank lines.
- Replaced "residing in the LDAP server" with "accessible from the LDAP
- server" in the sentence immediately following the ABNF. Removed the
- sentence "Individual attrdesc names are as defined for
- AttributeDescription in [Protocol]." because [Protocol]'s
- <attributeSelector> is now used directly in the ABNF. Reworded last
- paragraph to clarify which characters must be percent-encoded. Added
- text to indicate that LDAP URLs are used for references and
- referrals. Added text that refers to the ABNF from RFC 2234.
- Clarified and strengthened the requirements with respect to
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 12]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- processing of URLs that contain implements and not implemented
- extensions (the approach now closely matches that specified in
- [Protocol] for LDAP controls).
-
- "Defaults for Fields of the LDAP URL" section: added; formed by
- moving text about defaults out of the "URL Definition" section.
- Replaced direct reference to the attribute name "*" with a reference
- to the special <alluserattrs> selector "*" defined in [Protocol].
-
- "URL Processing" section: removed.
-
- "Examples" section: Modified examples to use example.com and
- example.net hostnames. Added missing '?' to the LDAP URL example
- whose filter contains three null bytes. Removed space after one
- comma within a DN. Revised the bindname example to use e-bindname.
- Changed the name of an attribute used in one example from "int" to
- "four-octet" to avoid potential confusion. Added an example that
- demonstrates the interaction between DN escaping and URL
- percent-encoding. Added some examples to show URL equivalence with
- respect to the <dn> portion of the URL. Used uppercase in some
- examples to remind the reader that some tokens are case-insensitive.
-
- "Security Considerations" section: Added a note about connection
- reuse. Added a note about using strong authentication methods for
- updates. Added a reference to [AuthMeth]. Added note that simply
- opening a connection may violate some users' privacy requirements.
- Adopted the working group's revised LDAP terminology specification by
- replacing the word "connection" with "LDAP session" or "LDAP
- connection" as appropriate.
-
- "Acknowledgements" section: added statement about this being an
- update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
- Hallvard Furuseth.
-
- "Normative References" section: renamed from "References" per new RFC
- guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added references to RFC 2234 and RFC 3629. Updated all
- RFC 1738 references to point to the appropriate sections within
- [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
- documents. Removed the reference to the LDAP Attribute Syntaxes
- document and added references to the [AuthMeth], [LDAPIANA], and
- [Roadmap] documents.
-
- "Informative References" section: added.
-
- Header and "Authors' Addresses" sections: added "editor" next to Mark
- Smith's name. Updated affiliation and contact information.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 13]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- Copyright: updated the year.
-
- Throughout the document: surrounded the names of all ABNF productions
- with "<" and ">" where they are used in descriptive text.
-
-
-
-12. Appendix B: Changes Since Previous Document Revision
-
- This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
- these changes are also included in Appendix A, but are also included
- here for the benefit of the people who have already reviewed
- draft-ietf-ldapbis-url-08.txt. This section will be removed before
- this document is published as an RFC.
-
-12.1. Technical Changes
-
- Throughout the document: Replaced references to [RFC2396] and
- [RFC2732] with references to [RFC2396bis]. This required changes to
- the ABNF and text so that productions that are no longer defined by
- [RFC2396bis] are not used. For example, <hostport> is not defined by
- [RFC2396bis] so it has been replaced with host [COLON port]. Note:
- [RFC2396bis] includes new definitions for the "Reserved" and
- "Unreserved" sets of characters, and the net result is that the
- following two additional characters should be percent-encoded when
- they appear anywhere in the data used to construct an LDAP URL: "["
- and "]" (these two characters were first added to the Reserved set by
- RFC 2732).
-
-12.2. Editorial Changes
-
- Throughout the document: Replaced phrases like "Escaping using the %
- method" with "Percent-encoding" to be consistent with the terminology
- used in [RFC2396bis].
-
- "URL Definition" section: For consistency, replaced all occurrences
- of the phrase 'see the "Percent-Encoding" section below' with
- 'subject to the provisions of the "Percent-Encoding" section below.'
-
- Updated the copyright year to 2005.
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 14]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-This Internet Draft expires on 4 July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 15]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Editor: A. Sciberras
-Intended Category: Standard Track eB2Bcom
-Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006
-Obsoletes: RFC 2256
-
- LDAP: Schema for User Applications
- draft-ietf-ldapbis-user-schema-11.txt
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
- Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 3 of BCP 78.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this document is unlimited. Technical discussion of
- this document should take place on the IETF LDAP Revision Working
- Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
- send editorial comments directly to the editor
- <andrew.sciberras@eb2bcom.com>.
-
- This Internet-Draft expires on 30 July 2006.
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 1]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-Abstract
-
- This document is an integral part of the Lightweight Directory Access
- Protocol (LDAP) technical specification [Roadmap]. It provides a
- technical specification of attribute types and object classes
- intended for use by LDAP directory clients for many directory
- services, such as, White Pages. These objects are widely used as a
- basis for the schema in many LDAP directories. This document does
- not cover attributes used for the administration of directory
- servers, nor does it include directory objects defined for specific
- uses in other documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 2]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-Table of Contents
-
- Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
- Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
- Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1 Relationship with other specifications . . . . . . . . . 5
- 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
- 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
-
- 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
- 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
- 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
- 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
- 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
- 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
- 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
- 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
- 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
- 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
- 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
- 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
- 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
- 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
- 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
- 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
- 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
- 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
- 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
- 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
- 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
- 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
- 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
- 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
- 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
-
-
-
-Sciberras Expires 30 July 2006 [Page 3]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- 2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
- 2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19
- 2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20
- 2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21
- 2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
-
- 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
- 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
- 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
- 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
- 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
- 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
- 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
- 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
- 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
- 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
- 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
- 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
-
- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
-
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
-
- 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
-
- 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
- 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
- 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
-
- 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
-
- 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
-
- 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 4]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-1. Introduction
-
- This document provides an overview of attribute types and object
- classes intended for use by Lightweight Directory Access Protocol
- (LDAP) directory clients for many directory services, such as, White
- Pages. Originally specified in the X.500 [X.500] documents, these
- objects are widely used as a basis for the schema in many LDAP
- directories. This document does not cover attributes used for the
- administration of directory servers, nor does it include directory
- objects defined for specific uses in other documents.
-
-1.1 Relationship with other specifications
-
- This document is an integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety. In terms of RFC 2256,
- Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections
- 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The
- remainder of RFC 2256 is obsoleted by this document. Section 2.4 of
- this document supersedes the technical specification for the 'dc'
- attribute type and 'dcObject' object class found in RFC 2247. The
- remainder of RFC 2247 remains in force.
-
- This document updates RFC 2798 by replacing the informative
- description of the 'uid' attribute type, with the definitive
- description provided in Section 2.39 of this document.
-
- A number of schema elements which were included in the previous
- revision of the LDAP Technical Specification are not included in this
- revision of LDAP. PKI-related schema elements are now specified in
- [LDAP-PKI]. Unless reintroduced in future technical specifications,
- the remainder are to be considered Historic.
-
- The descriptions in this document SHALL be considered definitive for
- use in LDAP.
-
-1.2 Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3 General Issues
-
- This document references Syntaxes defined in Section 3 of [Syntaxes]
- and Matching Rules defined in Section 4 of [Syntaxes].
-
- The definitions of Attribute Types and Object Classes are written
-
-
-
-Sciberras Expires 30 July 2006 [Page 5]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
- AttributeTypeDescription and ObjectClassDescription given in
- [Models]. Lines have been folded for readability. When such values
- are transferred as attribute values in the LDAP Protocol the values
- will not contain line breaks.
-
-2. Attribute Types
-
- The Attribute Types contained in this section hold user information.
-
- There is no requirement that servers implement the 'searchGuide' and
- 'teletexTerminalIdentifier' attribute types. In fact, their use is
- greatly discouraged.
-
- An LDAP server implementation SHOULD recognize the rest of the
- attribute types described in this section.
-
-2.1 'businessCategory'
-
- The 'businessCategory' attribute type describes the kinds of business
- performed by an organization. Each kind is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.15 NAME 'businessCategory'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Examples: "banking", "transportation" and "real estate".
-
-2.2 'c'
-
- The 'c' ('countryName' in X.500) attribute type contains a two-letter
- ISO 3166 [ISO3166] country code.
- (Source: X.520 [X.520])
-
- ( 2.5.4.6 NAME 'c'
- SUP name
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
- [Syntaxes].
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 6]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- Examples: "DE", "AU" and "FR".
-
-2.3 'cn'
-
- The 'cn' ('commonName' in X.500) attribute type contains names of an
- object. Each name is one value of this multi-valued attribute. If
- the object corresponds to a person, it is typically the person's full
- name.
- (Source: X.520 [X.520])
-
- ( 2.5.4.3 NAME 'cn'
- SUP name )
-
- Examples: "Martin K Smith", "Marty Smith" and "printer12".
-
-2.4 'dc'
-
- The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
- holding one component, a label, of a DNS domain name [RFC1034]. The
- encoding of IA5String for use in LDAP is simply the characters of the
- ASCII label. The equality matching rule is case insensitive, as is
- today's DNS.
- (Source: RFC 2247 [RFC2247])
-
- ( 0.9.2342.19200300.100.1.25 NAME 'dc'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
- [Syntaxes].
-
- Examples: Valid values include "example" and "com". The value
- "example.com" is invalid, because it contains two label
- components.
-
- Directory applications supporting International Domain Names SHALL
- use the ToASCII method [RFC3490] to produce the domain name component
- label. The special considerations discussed in section 4 of RFC 3490
- [RFC3490] should be taken, depending on whether the domain component
- is used for "stored" or "query" purposes.
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 7]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.5 'description'
-
- The 'description' attribute type contains human-readable descriptive
- phrases about the object. Each description is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.13 NAME 'description'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Examples: "a color printer", "Maintenance is done every Monday, at
- 1pm." and "distribution list for all technical staff".
-
-2.6 'destinationIndicator'
-
- The 'destinationIndicator' attribute type contains country and city
- strings, associated with the object (the addressee), needed to
- provide the Public Telegram Service. The strings are composed in
- accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
- Each string is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
-
- Examples: "AASD" as a destination indicator for Sydney, Australia.
- "GBLD" as a destination indicator for London, United
- Kingdom.
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the F.1 and F.30 CCITT Recommendations. It is
- the application's responsibility to ensure destination indicators
- that it stores in this attribute are appropriately constructed.
-
-2.7 'distinguishedName'
-
- The 'distinguishedName' attribute type is not used as the name of the
- object itself, but it is instead a base type from which some user
-
-
-
-Sciberras Expires 30 July 2006 [Page 8]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- attribute types with a DN syntax can inherit.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
- (Source: X.520 [X.520])
-
- ( 2.5.4.49 NAME 'distinguishedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
-
-2.8 'dnQualifier'
-
- The 'dnQualifier' attribute type contains disambiguating information
- strings to add to the relative distinguished name of an entry. The
- information is intended for use when merging data from multiple
- sources in order to prevent conflicts between entries which would
- otherwise have the same name. Each string is one value of this
- multi-valued attribute. It is recommended that a value of the
- 'dnQualifier' attribute be the same for all entries from a particular
- source.
- (Source: X.520 [X.520])
-
- ( 2.5.4.46 NAME 'dnQualifier'
- EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
-
- Examples: "20050322123345Z" - timestamps can be used to disambiguate
- information.
- "123456A" - serial numbers can be used to disambiguate
- information.
-
-2.9 'enhancedSearchGuide'
-
- The 'enhancedSearchGuide' attribute type contains sets of information
- for use by directory clients in constructing search filters. Each
- set is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 9]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
-
- 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
- [Syntaxes].
-
- Examples: "person#(sn$APPROX)#wholeSubtree" and
- "organizationalUnit#(ou$SUBSTR)#oneLevel".
-
-2.10 'facsimileTelephoneNumber'
-
- The 'facsimileTelephoneNumber' attribute type contains telephone
- numbers (and, optionally, the parameters) for facsimile terminals.
- Each telephone number is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
-
- 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
- Number syntax [Syntaxes].
-
- Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
-
-2.11 'generationQualifier'
-
- The 'generationQualifier' attribute type contains name strings that
- are the part of a person's name which typically is the suffix. Each
- string is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.44 NAME 'generationQualifier'
- SUP name )
-
- Examples: "III", "3rd" and "Jr.".
-
-2.12 'givenName'
-
- The 'givenName' attribute type contains name strings that are the
- part of a person's name which is not their surname. Each string is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.42 NAME 'givenName'
- SUP name )
-
- Examples: "Andrew", "Charles" and "Joanne".
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 10]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.13 'houseIdentifier'
-
- The 'houseIdentifier' attribute type contains identifiers for a
- building within a location. Each identifier is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.51 NAME 'houseIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Examples: "20" to represent the house number 20.
-
-2.14 'initials'
-
- The 'initials' attribute type contains strings of initials of some or
- all of an individual's names, except the surname(s). Each string is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.43 NAME 'initials'
- SUP name )
-
- Examples: "K. A." and "K".
-
-2.15 'internationalISDNNumber'
-
- The 'internationalISDNNumber' attribute type contains Integrated
- Services Digital Network (ISDN) addresses, as defined in the
- International Telecommunication Union (ITU) Recommendation E.164
- [E.164]. Each address is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.25 NAME 'internationalISDNNumber'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [Syntaxes].
-
- Example: "0198 333 333".
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 11]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.16 'l'
-
- The 'l' ('localityName' in X.500) attribute type contains names of a
- locality or place, such as a city, county or other geographic region.
- Each name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.7 NAME 'l'
- SUP name )
-
- Examples: "Geneva", "Paris" and "Edinburgh".
-
-2.17 'member'
-
- The 'member' attribute type contains the Distinguished Names of
- objects that are on a list or in a group. Each name is one value of
- this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.31 NAME 'member'
- SUP distinguishedName )
-
- Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
- "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
- be two members of the financial team (group) at Widget,
- Inc. In which case, both of these distinguished names would
- be present as individual values of the member attribute.
-
-2.18 'name'
-
- The 'name' attribute type is the attribute supertype from which user
- attribute types with the name syntax inherit. Such attribute types
- are typically used for naming. The attribute type is multi-valued.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
- (Source: X.520 [X.520])
-
- ( 2.5.4.41 NAME 'name'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
-
-
-Sciberras Expires 30 July 2006 [Page 12]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.19 'o'
-
- The 'o' ('organizationName' in X.500) attribute type contains the
- names of an organization. Each name is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.10 NAME 'o'
- SUP name )
-
- Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
-
-2.20 'ou'
-
- The 'ou' ('organizationalUnitName' in X.500) attribute type contains
- the names of an organizational unit. Each name is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.11 NAME 'ou'
- SUP name )
-
- Examples: "Finance", "Human Resources" and "Research and
- Development".
-
-2.21 'owner'
-
- The 'owner' attribute type contains the Distinguished Names of
- objects that have an ownership responsibility for the object that is
- owned. Each owner's name is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.32 NAME 'owner'
- SUP distinguishedName )
-
- Example: The mailing list object, whose DN is "cn=All Employees,
- ou=Mailing List,o=Widget\, Inc.", is owned by the Human
- Resources Director.
- Therefore, the value of the 'owner' attribute within the
- mailing list object, would be the DN of the director (role):
- "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
-
-2.22 'physicalDeliveryOfficeName'
-
- The 'physicalDeliveryOfficeName' attribute type contains names that a
- Postal Service uses to identify a post office.
- (Source: X.520 [X.520])
-
-
-
-Sciberras Expires 30 July 2006 [Page 13]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
-
-2.23 'postalAddress'
-
- The 'postalAddress' attribute type contains addresses used by a
- Postal Service to perform services for the object. Each address is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.16 NAME 'postalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [Syntaxes].
-
- Example: "15 Main St.$Ottawa$Canada".
-
-2.24 'postalCode'
-
- The 'postalCode' attribute type contains codes used by a Postal
- Service to identify postal service zones. Each code is one value of
- this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.17 NAME 'postalCode'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Example: "22180", to identify Vienna, VA in the USA.
-
-2.25 'postOfficeBox'
-
- The 'postOfficeBox' attribute type contains postal box identifiers
- that a Postal Service uses when a customer arranges to receive mail
-
-
-
-Sciberras Expires 30 July 2006 [Page 14]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- at a box on premises of the Postal Service. Each postal box
- identifier is a single value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.18 NAME 'postOfficeBox'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Example: "Box 45".
-
-2.26 'preferredDeliveryMethod'
-
- The 'preferredDeliveryMethod' attribute type contains an indication
- of the preferred method of getting a message to the object.
- (Source: X.520 [X.520])
-
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
- [Syntaxes].
-
- Example: If the mhs-delivery Delivery Method is preferred over
- telephone-delivery, which is preferred over all other
- methods, the value would be: "mhs $ telephone".
-
-2.27 'registeredAddress'
-
- The 'registeredAddress' attribute type contains postal addresses
- suitable for reception of telegrams or expedited documents, where it
- is necessary to have the recipient accept delivery. Each address is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.26 NAME 'registeredAddress'
- SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [Syntaxes].
-
- Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 15]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.28 'roleOccupant'
-
- The 'roleOccupant' attribute type contains the Distinguished Names of
- objects (normally people) that fulfill the responsibilities of a role
- object. Each distinguished name is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.33 NAME 'roleOccupant'
- SUP distinguishedName )
-
- Example: The role object, "cn=Human Resources
- Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
- people whose object names are "cn=Mary
- Smith,ou=employee,o=Widget\, Inc." and "cn=James
- Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
- attribute will contain both of these distinguished names,
- since they are the occupants of this role.
-
-2.29 'searchGuide'
-
- The 'searchGuide' attribute type contains sets of information for use
- by clients in constructing search filters. It is superseded by
- 'enhancedSearchGuide', described above in section 2.9. Each set is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
-
- 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
-
- Example: "person#sn$EQ".
-
-2.30 'seeAlso'
-
- The 'seeAlso' attribute type contains Distinguished Names of objects
- that are related to the subject object. Each related object name is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.34 NAME 'seeAlso'
- SUP distinguishedName )
-
- Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
- Inc." is related to the role objects, "cn=Football Team
- Captain,ou=sponsored activities,o=Widget\, Inc." and
- "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
-
-
-
-Sciberras Expires 30 July 2006 [Page 16]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- Since the role objects are related to the person object, the
- 'seeAlso' attribute will contain the distinguished name of
- each role object as separate values.
-
-2.31 'serialNumber'
-
- The 'serialNumber' attribute type contains the serial numbers of
- devices. Each serial number is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.5 NAME 'serialNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
-
- Examples: "WI-3005" and "XF551426".
-
-2.32 'sn'
-
- The 'sn' ('surname' in X.500) attribute type contains name strings
- for the family names of a person. Each string is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.4 NAME 'sn'
- SUP name )
-
- Example: "Smith".
-
-2.33 'st'
-
- The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
- full names of states or provinces. Each name is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.8 NAME 'st'
- SUP name )
-
- Example: "California".
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 17]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.34 'street'
-
- The 'street' ('streetAddress' in X.500) attribute type contains site
- information from a postal address (i.e., the street name, place,
- avenue, and the house number.). Each street is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.9 NAME 'street'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Example: "15 Main St.".
-
-2.35 'telephoneNumber'
-
- The 'telephoneNumber' attribute type contains telephone numbers that
- comply with the ITU Recommendation E.123 [E.123]. Each number is one
- value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.20 NAME 'telephoneNumber'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
- [Syntaxes].
-
- Example: "+1 234 567 8901".
-
-2.36 'teletexTerminalIdentifier'
-
- The withdrawal of Rec. F.200 has resulted in the withdrawal of this
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
-
- 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
- Identifier syntax [Syntaxes].
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 18]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.37 'telexNumber'
-
- The 'telexNumber' attribute type contains sets of strings which are a
- telex number, country code, and answerback code of a telex terminal.
- Each set is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
-
- 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
- [Syntaxes].
-
- Example: "12345$023$ABCDE".
-
-2.38 'title'
-
- The 'title' attribute type contains the title of a person in their
- organizational context. Each title is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.12 NAME 'title'
- SUP name )
- Examples: "Vice President", "Software Engineer" and "CEO".
-
-2.39 'uid'
-
- The 'uid' ('userid' in RFC 1274) attribute type contains computer
- system login names associated with the object. Each name is one
- value of this multi-valued attribute.
- (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
-
- ( 0.9.2342.19200300.100.1.1 NAME 'uid'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
-
- Examples: "s9709015", "admin" and "Administrator".
-
-2.40 'uniqueMember'
-
- The 'uniqueMember' attribute type contains the Distinguished Names of
- an object that is on a list or in a group, where the Relative
- Distinguished Names of the object include a value that distinguishes
-
-
-
-Sciberras Expires 30 July 2006 [Page 19]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- between objects when a distinguished name has been reused. Each
- distinguished name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.50 NAME 'uniqueMember'
- EQUALITY uniqueMemberMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
- 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
- syntax [Syntaxes].
-
- Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
- disbanded, establishing a new battalion with the "same" name
- would have a unique identifier value added, resulting in
- "ou=1st Battalion, o=Defense,c=US#'010101'B".
-
-2.41 'userPassword'
-
- The 'userPassword' attribute contains octet strings that are known
- only to the user and the system to which the user has access. Each
- string is one value of this multi-valued attribute.
-
- The application SHOULD prepare textual strings used as passwords by
- transcoding them to Unicode, applying SASLprep [RFC4013], and
- encoding as UTF-8. The determination of whether a password is
- textual is a local client matter.
- (Source: X.509 [X.509])
-
- ( 2.5.4.35 NAME 'userPassword'
- EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
- 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
- [Syntaxes].
-
- Passwords are stored using an Octet String syntax and are not
- encrypted. Transfer of cleartext passwords is strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the password to
- unauthorized parties.
-
- An example of a need for multiple values in the 'userPassword'
- attribute is an environment where every month the user was expected
- to use a different password generated by some automated system.
- During transitional periods, like the last and first day of the
- periods, it may be necessary to allow two passwords for the two
- consecutive periods to be valid in the system.
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 20]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-2.42 'x121Address'
-
- The 'x121Address' attribute type contains data network addresses as
- defined by ITU Recommendation X.121 [X.121]. Each address is one
- value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.24 NAME 'x121Address'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [Syntaxes].
-
- Example: "36111222333444555".
-
-2.43 'x500UniqueIdentifier'
-
- The 'x500UniqueIdentifier' attribute type contains binary strings
- that are used to distinguish between objects when a distinguished
- name has been reused. Each string is one value of this multi-valued
- attribute.
- In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
- This is a different attribute type from both the 'uid' and
- 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
- attribute type is defined in [RFC1274].
- (Source: X.520 [X.520])
-
- ( 2.5.4.45 NAME 'x500UniqueIdentifier'
- EQUALITY bitStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
- [Syntaxes].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 21]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-3. Object Classes
-
- LDAP servers SHOULD recognize all the Object Classes listed here as
- values of the 'objectClass' attribute (see [Models]).
-
-3.1 'applicationProcess'
-
- The 'applicationProcess' object class definition is the basis of an
- entry which represents an application executing in a computer system.
- (Source: X.521 [X.521])
-
- ( 2.5.6.11 NAME 'applicationProcess'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( seeAlso $
- ou $
- l $
- description ) )
-
-3.2 'country'
-
- The 'country' object class definition is the basis of an entry which
- represents a country.
- (Source: X.521 [X.521])
-
- ( 2.5.6.2 NAME 'country'
- SUP top
- STRUCTURAL
- MUST c
- MAY ( searchGuide $
- description ) )
-
-3.3 'dcObject'
-
- The 'dcObject' object class permits an entry to contains domain
- component information. This object class is defined as auxiliary,
- because it will be used in conjunction with an existing structural
- object class.
- (Source: RFC 2247 [RFC2247])
-
- ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
- SUP top
- AUXILIARY
- MUST dc )
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 22]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-3.4 'device'
-
- The 'device' object class is the basis of an entry which represents
- an appliance, computer or network element.
- (Source: X.521 [X.521])
-
- ( 2.5.6.14 NAME 'device'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( serialNumber $
- seeAlso $
- owner $
- ou $
- o $
- l $
- description ) )
-
-3.5 'groupOfNames'
-
- The 'groupOfNames' object class is the basis of an entry which
- represents a set of named objects including information related to
- the purpose or maintenance of the set.
- (Source: X.521 [X.521])
-
- ( 2.5.6.9 NAME 'groupOfNames'
- SUP top
- STRUCTURAL
- MUST ( member $
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
-
-3.6 'groupOfUniqueNames'
-
- The 'groupOfUniqueNames' object class is the same as the
- 'groupOfNames' object class except that the object names are not
- repeated or reassigned within a set scope.
- (Source: X.521 [X.521])
-
- ( 2.5.6.17 NAME 'groupOfUniqueNames'
- SUP top
- STRUCTURAL
- MUST ( uniqueMember $
-
-
-
-Sciberras Expires 30 July 2006 [Page 23]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
-
-3.7 'locality'
-
- The 'locality' object class is the basis of an entry which represents
- a place in the physical world.
- (Source: X.521 [X.521])
-
- ( 2.5.6.3 NAME 'locality'
- SUP top
- STRUCTURAL
- MAY ( street $
- seeAlso $
- searchGuide $
- st $
- l $
- description ) )
-
-3.8 'organization'
-
- The 'organization' object class is the basis of an entry which
- represents a structured group of people.
- (Source: X.521 [X.521])
-
- ( 2.5.6.4 NAME 'organization'
- SUP top
- STRUCTURAL
- MUST o
- MAY ( userPassword $ searchGuide $ seeAlso $
- businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $ street $ postOfficeBox $
- postalCode $ postalAddress $ physicalDeliveryOfficeName $
- st $ l $ description ) )
-
-3.9 'organizationalPerson'
-
- The 'organizationalPerson' object class is the basis of an entry
- which represents a person in relation to an organization.
- (Source: X.521 [X.521])
-
-
-
-Sciberras Expires 30 July 2006 [Page 24]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- ( 2.5.6.7 NAME 'organizationalPerson'
- SUP person
- STRUCTURAL
- MAY ( title $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $ street $ postOfficeBox $
- postalCode $ postalAddress $ physicalDeliveryOfficeName $
- ou $ st $ l ) )
-
-3.10 'organizationalRole'
-
- The 'organizationalRole' object class is the basis of an entry which
- represents a job, function or position in an organization.
- (Source: X.521 [X.521])
-
- ( 2.5.6.8 NAME 'organizationalRole'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $
- seeAlso $ roleOccupant $ preferredDeliveryMethod $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l $
- description ) )
-
-3.11 'organizationalUnit'
-
- The 'organizationalUnit' object class is the basis of an entry which
- represents a piece of an organization.
- (Source: X.521 [X.521])
-
- ( 2.5.6.5 NAME 'organizationalUnit'
- SUP top
- STRUCTURAL
- MUST ou
- MAY ( businessCategory $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $ l $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $
- registeredAddress $ searchGuide $ seeAlso $ st $ street $
- telephoneNumber $ teletexTerminalIdentifier $
- telexNumber $ userPassword $ x121Address ) )
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 25]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-3.12 'person'
-
- The 'person' object class is the basis of an entry which represents a
- human being.
- (Source: X.521 [X.521])
-
- ( 2.5.6.6 NAME 'person'
- SUP top
- STRUCTURAL
- MUST ( sn $
- cn )
- MAY ( userPassword $
- telephoneNumber $
- seeAlso $ description ) )
-
-3.13 'residentialPerson'
-
- The 'residentialPerson' object class is the basis of an entry which
- includes a person's residence in the representation of the person.
- (Source: X.521 [X.521])
-
- ( 2.5.6.10 NAME 'residentialPerson'
- SUP person
- STRUCTURAL
- MUST l
- MAY ( businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $ preferredDeliveryMethod $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l ) )
-
-3.14 'uidObject'
-
- The 'uidObject' object class permits an entry to contains user
- identification information. This object class is defined as
- auxiliary, because it will be used in conjunction with an existing
- structural object class.
- (Source: RFC 2377 [RFC2377])
-
- ( 1.3.6.1.1.3.1 NAME 'uidObject'
- SUP top
- AUXILIARY
- MUST uid )
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 26]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-4. IANA Considerations
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
- template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
- Person & email address to contact for further information:
- Andrew Sciberras <andrew.sciberras@eb2bcom.com>
- Usage: (A = attribute type, O = Object Class) see comment
- Specification: RFC XXXX [editor's note: The RFC number will be
- the one assigned to this document.]
- Author/Change Controller: IESG
- Comments
- In the LDAP descriptors registry, the following descriptors (short
- names) should be updated to refer to RFC XXXX [editor's note: This
- document]. Names that need to be reserved, rather than assigned to
- an Object Identifier, will contain an Object Identifier value of
- RESERVED.
-
- NAME Type OID
- ------------------------ ---- ----------------------------
- applicationProcess O 2.5.6.11
- businessCategory A 2.5.4.15
- c A 2.5.4.6
- cn A 2.5.4.3
- commonName A 2.5.4.3
- country O 2.5.6.2
- countryName A 2.5.4.6
- DC A 0.9.2342.19200300.100.1.25
- dcObject O 1.3.6.1.4.1.1466.344
- description A 2.5.4.13
- destinationIndicator A 2.5.4.27
- device O 2.5.6.14
- distinguishedName A 2.5.4.49
- dnQualifier A 2.5.4.46
- domainComponent A 0.9.2342.19200300.100.1.25
- enhancedSearchGuide A 2.5.4.47
- facsimileTelephoneNumber A 2.5.4.23
- generationQualifier A 2.5.4.44
- givenName A 2.5.4.42
- GN A RESERVED
- groupOfNames O 2.5.6.9
- groupOfUniqueNames O 2.5.6.17
- houseIdentifier A 2.5.4.51
- initials A 2.5.4.43
-
-
-
-Sciberras Expires 30 July 2006 [Page 27]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- internationalISDNNumber A 2.5.4.25
- L A 2.5.4.7
- locality O 2.5.6.3
- localityName A 2.5.4.7
- member A 2.5.4.31
- name A 2.5.4.41
- o A 2.5.4.10
- organization O 2.5.6.4
- organizationName A 2.5.4.10
- organizationalPerson O 2.5.6.7
- organizationalRole O 2.5.6.8
- organizationalUnit O 2.5.6.5
- organizationalUnitName A 2.5.4.11
- ou A 2.5.4.11
- owner A 2.5.4.32
- person O 2.5.6.6
- physicalDeliveryOfficeName A 2.5.4.19
- postalAddress A 2.5.4.16
- postalCode A 2.5.4.17
- postOfficeBox A 2.5.4.18
- preferredDeliveryMethod A 2.5.4.28
- registeredAddress A 2.5.4.26
- residentialPerson O 2.5.6.10
- roleOccupant A 2.5.4.33
- searchGuide A 2.5.4.14
- seeAlso A 2.5.4.34
- serialNumber A 2.5.4.5
- sn A 2.5.4.4
- st A 2.5.4.8
- street A 2.5.4.9
- surname A 2.5.4.4
- telephoneNumber A 2.5.4.20
- teletexTerminalIdentifier A 2.5.4.22
- telexNumber A 2.5.4.21
- title A 2.5.4.12
- uid A 0.9.2342.19200300.100.1.1
- uidObject O 1.3.6.1.1.3.1
- uniqueMember A 2.5.4.50
- userId A 0.9.2342.19200300.100.1.1
- userPassword A 2.5.4.35
- x121Address A 2.5.4.24
- x500UniqueIdentifier A 2.5.4.45
-
-5. Security Considerations
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
-
-
-
-Sciberras Expires 30 July 2006 [Page 28]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- regarding the publication of information about people.
-
- Transfer of cleartext passwords is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and
- integrity, since this may result in disclosure of the password to
- unauthorized parties.
-
- Multiple attribute values for the 'userPassword' attribute need to be
- used with care. Especially reset/deletion of a password by an admin
- without knowing the old user password gets tricky or impossible if
- multiple values for different applications are present.
-
- Certainly, applications which intend to replace the 'userPassword'
- value(s) with new value(s) should use modify/replaceValues (or
- modify/deleteAttribute+addAttribute). Additionally, server
- implementations are encouraged to provide administrative controls
- which, if enabled, restrict the 'userPassword' attribute to one
- value.
-
- Note that when used for authentication purposes [AuthMeth], the user
- need only prove knowledge of one of the values, not all of the
- values.
-
-
-6. Acknowledgements
-
- The definitions, on which this document is based, have been developed
- by committees for telecommunications and international standards.
-
- This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
- product of the IETF ASID Working Group.
-
- The 'dc' attribute type definition and the 'dcObject' object class
- definition in this document supersede the specification in RFC 2247
- by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
-
- The 'uid' attribute type definition in this document supersedes the
- specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
- and of the uid in RFC 2798 by M. Smith.
-
- The 'uidObject' object class definition in this document supersedes
- the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
- Huber, S. Sataluri and M. Smith.
-
- This document is based upon input of the IETF LDAPBIS working group.
- The author wishes to thank S. Legg and K. Zeilenga for their
- significant contribution to this update. The author would also like
- to thank Kathy Dally who edited early drafts of this document.
-
-
-
-Sciberras Expires 30 July 2006 [Page 29]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-7. References
-
-7.1 Normative
-
- [E.123] Notation for national and international telephone
- numbers, ITU-T Recommendation E.123, 1988
-
- [E.164] The international public telecommunication numbering
- plan, ITU-T Recommendation E.164, 1997
-
- [F.1] Operational Provisions For The International Public
- Telegram Service Transmission System, CCITT
- Recommendation F.1, 1992
-
- [F.31] Telegram Retransmission System, CCITT Recommendation
- F.31, 1988
-
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
-
- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
- models-xx (a work in progress)
-
- [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
- FACILITIES", RFC 1034, January 1987
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997
-
- [RFC3490] Faltstrom P., Hoffman P., Costello A.,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003
-
- [RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
- Names and Passwords", RFC 4013, February 2005.
-
- [RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005
-
- [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx (a work in
- progress)
-
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
- syntaxes-xx (a work in progress)
-
- [X.121] International numbering plan for public data networks,
- ITU-T Recommendation X.121, 1996
-
-
-
-Sciberras Expires 30 July 2006 [Page 30]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- [X.509] The Directory: Authentication Framework, ITU-T
- Recommendation X.509, 1993
-
- [X.520] The Directory: Selected Attribute Types, ITU-T
- Recommendation X.520, 1993
-
- [X.521] The Directory: Selected Object Classes. ITU-T
- Recommendation X.521, 1993
-
-7.2 Informative
-
- [AuthMeth] Harrison R., "LDAP: Authentication Methods and
- Connection Level Security Mechanisms", draft-ietf-
- ldapbis-authmeth-xx (a work in progress)
-
- [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates",
- draft-zeilenga-ldap-x509-xx (a work in progress)
-
- [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
- Schema", RFC 1274, November 1991
-
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
- Sataluri, S., "Using Domains in LDAP/X.500
- Distinguished Names", RFC 2247, January 1998
-
- [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
- "Naming Plan for Internet-Enabled Applications", RFC
- 2377, September 1998.
-
- [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
- Class", RFC 2798, April 2000
-
- [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC
- 9594-1:1994, Information Technology - Open Systems
- Interconnection - The Directory: Overview of concepts,
- models and services.
-
-8. Author's Address
-
- Andrew Sciberras
- eB2Bcom
- Suite 3, Woodhouse Corporate Centre,
- 935 Station Street,
- Box Hill North, Victoria 3129
- AUSTRALIA
-
- Phone: +61 3 9896 7833
-
-
-
-Sciberras Expires 30 July 2006 [Page 31]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- Email: andrew.sciberras@eb2bcom.com
-
-9. Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 32]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- Appendix A Changes Made Since RFC 2256
-
- This appendix lists the changes that have been made from RFC 2256 to
- this I-D.
-
- This appendix is not a normative part of this specification, which
- has been provided for informational purposes only.
-
- 1. Replaced the document title.
-
- 2. Removed the IESG Note.
-
- 3. Dependencies on RFC 1274 have been eliminated.
-
- 4. Added a Security Considerations section and an IANA
- considerations section.
-
- 5. Deleted the conformance requirement for subschema object
- classes in favor of a statement in [Syntaxes].
-
- 6. Added explanation to attribute types and to each object class.
-
- 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
- (moved to [Syntaxes]).
-
- 8. Removed the certificate-related attribute types:
- authorityRevocationList, cACertificate,
- certificateRevocationList, crossCertificatePair,
- deltaRevocationList, supportedAlgorithms, and userCertificate.
-
- Removed the certificate-related Object Classes:
- certificationAuthority, certificationAuthority-V2,
- cRLDistributionPoint, strongAuthenticationUser, and
- userSecurityInformation
-
- LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
-
- 9. Removed the dmdName, knowledgeInformation,
- presentationAddress, protocolInformation, and
- supportedApplicationContext attribute types and the dmd,
- applicationEntity, and dSA object classes.
-
- 10. Deleted the aliasedObjectName and objectClass attribute type
- definitions. Deleted the alias and top object class
- definitions. They are included in [Models].
-
- 11. Added the 'dc' attribute type from RFC 2247.
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 33]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- 12. Numerous edititorial changes.
-
- 13. Removed upper bound after the SYNTAX oid in all attribute
- definitions where it appeared.
-
- 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
-
- changes since 07:
-
- 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
- postalAddress, and registeredAddress attribute types.
-
- 16. Clarified and corrected examples in owner and roleOccupant
- attribute types.
-
- 17. Added RFC 2234 to normative references.
-
- 18. Added RFC 1274 and RFC 2798 to informative references.
-
- 19. Removed the statement about RFC 2026 conformance.
-
- 20. Added the IPR Disclosure and Notice
-
- 21. Updated the Copyright text.
-
- changes since 08:
-
- 22. Included RFC 2377 into Updates header and Informative
- References
-
- 23. Changed Editor information to Andrew Sciberras.
-
- 24. Updated I-D Template information.
-
- 25. References made consistent with other LDAPbis ID's. [ROADMAP]
- -> [RoadMap] and [AUTHMETH] -> [AuthMeth].
-
- 26. Changed Introduction to include an (LDAP) acronym after the
- first usage.
-
- 27. Renamed section 1.1 to "Relationship with other
- specifications" from "Situation".
-
- 28. Included definitions, comments and references for 'dcObject'
- and 'uidObject'.
-
- 29. Replaced PKI schema references to use draft-zeilenga-ldap-
- x509-xx
-
-
-
-Sciberras Expires 30 July 2006 [Page 34]
-\f
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- 30. Spelt out and referenced ABNF on first usage.
-
- 31. Removed Section 2.4 (Source). Replaced the source table with
- explicit references for each definition.
-
- 32. All references to an attribute type or object class are
- enclosed in single quotes.
-
- 33. The layout of attribute type definitions has been changed to
- provide consistency throughout the document:
- > Section Heading
- > Description of Attribute type
- > Multivalued description
- > Source Information
- > Definition
- > Example
- > Additional Comments
-
- Adding this consistent output included the addition of
- examples to some definitions.
-
- 34. References to alternate names for attributes types are
- provided with a reference to where they were originally
- specified.
-
- 35. Clarification of the description of 'distinguishedName' and
- 'name', in regards to these attribute types being supertypes.
-
- 36. Spelt out ISDN on first usage.
-
- 37. Inserted a reference to [Syntaxes] for the
- 'teletexTerminalIdentifier' definition's SYNTAX OID.
-
- 38. Additional names were added to the IANA Considerations. Names
- include 'commonName', 'dcObject', 'domainComponent', 'GN',
- 'localityName', 'organizationName', 'organizationUnitName',
- 'surname', 'uidObject' and 'userid'.
-
- 39. Renamed all instances of supercede to supersede.
-
- 40. Moved [F.1], [F.30] and [SASLprep] from informative to
- normative references.
-
- 41. Changed the 'c' definition to be consistent with X.500.
-
- 42. Added text to 'dc', making the distinction between 'stored'
- and 'query' values when preparing IDN strings.
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 35]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT S. Legg
-draft-legg-ldap-binary-04.txt eB2Bcom
-Intended Category: Standards Track 30 January 2006
-
-
- Lightweight Directory Access Protocol (LDAP):
- The Binary Encoding Option
-
- Copyright (C) The Internet Society (2006).
-
- Status of this Memo
-
- By submitting this Internet-draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Technical discussion of this document should take place on the IETF
- LDAP Revision Working Group (LDAPbis) mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <steven.legg@eb2bcom.com>.
-
- This Internet-Draft expires on 30 July 2006.
-
-Abstract
-
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory has a defined syntax (i.e., data type). A syntax
- definition specifies how attribute values conforming to the syntax
- are normally represented when transferred in LDAP operations. This
- representation is referred to as the LDAP-specific encoding to
- distinguish it from other methods of encoding attribute values. This
-
-
-
-Legg Expires 30 July 2006 [Page 1]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- document defines an attribute option, the binary option, which can be
- used to specify that the associated attribute values are instead
- encoded according to the Basic Encoding Rules (BER) used by X.500
- directories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 30 July 2006 [Page 2]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
- 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
- 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
- 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
- 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
- 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 10.1. Normative References. . . . . . . . . . . . . . . . . . 7
- 10.2. Informative References. . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
-
-1. Introduction
-
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
- which constrains the structure and format of its values.
-
- The description of each syntax [SYNTAX] specifies how attribute or
- assertion values [MODELS] conforming to the syntax are normally
- represented when transferred in LDAP operations [PROT]. This
- representation is referred to as the LDAP-specific encoding to
- distinguish it from other methods of encoding attribute values.
-
- This document defines an attribute option, the binary option, which
- can be used in an attribute description [MODELS] in an LDAP operation
- to specify that the associated attribute values or assertion values
- are, or are requested to be, encoded according to the Basic Encoding
- Rules (BER) [BER] as used by X.500 [X.500] directories, instead of
- the usual LDAP-specific encoding.
-
- The binary option was originally defined in RFC 2251 [RFC2251]. The
- LDAP technical specification [ROADMAP] has obsoleted the previously
- defined LDAP technical specification [RFC3377], which included RFC
- 2251. The binary option was not included in the revised LDAP
- technical specification for a variety of reasons including
- implementation inconsistencies. No attempt is made here to resolve
- the known inconsistencies.
-
- This document reintroduces the binary option for use with certain
- attribute syntaxes, such as certificate syntax [PKI], which
- specifically require it. No attempt has been made to address use of
- the binary option with attributes of syntaxes which do not require
-
-
-
-Legg Expires 30 July 2006 [Page 3]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- its use. Unless addressed in a future specification, this use is to
- be avoided.
-
-
-2. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, RFC 2119
- [BCP14].
-
-3. The binary Option
-
- The binary option is indicated with the attribute option string
- "binary" in an attribute description. Note that, like all attribute
- options, the string representing the binary option is case
- insensitive.
-
- Where the binary option is present in an attribute description the
- associated attribute values or assertion values MUST be BER encoded
- (otherwise the values are encoded according to the LDAP-specific
- encoding [SYNTAX] for the attribute's syntax). Note that it is
- possible for a syntax to be defined such that its LDAP-specific
- encoding is exactly the same as its BER encoding.
-
- In terms of the protocol [PROT], the binary option specifies that the
- contents octets of the associated AttributeValue or AssertionValue
- OCTET STRING are a complete BER encoding of the relevant value.
-
- The binary option is not a tagging option [MODELS] so the presence of
- the binary option does not specify an attribute subtype. An
- attribute description containing the binary option references exactly
- the same attribute as the attribute description without the binary
- option. The supertype/subtype relationships of attributes with
- tagging options are not altered in any way by the presence or absence
- of the binary option.
-
- An attribute description SHALL be treated as unrecognized if it
- contains the binary option and the syntax of the attribute does not
- have an associated ASN.1 type [SYNTAX], or the BER encoding of values
- of that type is not supported.
-
- The presence or absence of the binary option only affects the
- transfer of attribute and assertion values in protocol; servers store
- any particular attribute value in a format of their choosing.
-
-4. Syntaxes Requiring Binary Transfer
-
-
-
-
-Legg Expires 30 July 2006 [Page 4]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- The attribute values of certain attribute syntaxes are defined
- without an LDAP-specific encoding and are required to be transferred
- in the BER encoded form. For the purposes of this document, these
- syntaxes are said to have a binary transfer requirement. The
- Certificate, Certificate List, Certificate Pair and Supported
- Algorithm syntaxes [PKI] are examples of syntaxes with a binary
- transfer requirement. These syntaxes also have an additional
- requirement that the exact BER encoding must be preserved. Note that
- this is a property of the syntaxes themselves, and not a property of
- the binary option. In the absence of this requirement, LDAP clients
- would need to re-encode values using the Distinguished Encoding Rules
- (DER).
-
-5. Attributes Returned in a Search
-
- An LDAP search request [PROT] contains a list of the attributes (the
- requested attributes list) to be returned from each entry matching
- the search filter. An attribute description in the requested
- attributes list also implicitly requests all subtypes of the
- attribute type in the attribute description, whether through
- attribute subtyping or attribute tagging option subtyping [MODELS].
-
- The requested attributes list MAY contain attribute descriptions with
- the binary option, but MUST NOT contain two attribute descriptions
- with the same attribute type and the same tagging options (even if
- only one of them has the binary option). The binary option in an
- attribute description in the requested attributes list implicitly
- applies to all the subtypes of the attribute type in the attribute
- description (however, see Section 7).
-
- Attributes of a syntax with the binary transfer requirement, if
- returned, SHALL be returned in the binary form, i.e., with the binary
- option in the attribute description and the associated attribute
- values BER encoded, regardless of whether the binary option was
- present in the request (for the attribute or for one of its
- supertypes).
-
- Attributes of a syntax without the binary transfer requirement, if
- returned, SHOULD be returned in the form explicitly requested. That
- is, if the attribute description in the requested attributes list
- contains the binary option then the corresponding attribute in the
- result SHOULD be in the binary form. If the attribute description in
- the request does not contain the binary option then the corresponding
- attribute in the result SHOULD NOT be in the binary form. A server
- MAY omit an attribute from the result if it does not support the
- requested encoding.
-
- Regardless of the encoding chosen, a particular attribute value is
-
-
-
-Legg Expires 30 July 2006 [Page 5]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- returned at most once.
-
-6. All User Attributes
-
- If the list of attributes in a search request is empty, or contains
- the special attribute description string "*", then all user
- attributes are requested to be returned.
-
- Attributes of a syntax with the binary transfer requirement, if
- returned, SHALL be returned in the binary form.
-
- Attributes of a syntax without the binary transfer requirement and
- having a defined LDAP-specific encoding SHOULD NOT be returned in the
- binary form.
-
- Attributes of a syntax without the binary transfer requirement and
- without a defined LDAP-specific encoding may be returned in the
- binary form or omitted from the result.
-
-7. Conflicting Requests
-
- A particular attribute could be explicitly requested by an attribute
- description and/or implicitly requested by the attribute descriptions
- of one or more of its supertypes, or by the special attribute
- description string "*". If the binary option is not present in all
- these attribute descriptions, nor absent in all these attribute
- descriptions, then the effect of the request with respect to binary
- transfer is implementation defined.
-
-8. Security Considerations
-
- When interpreting security-sensitive fields, and in particular fields
- used to grant or deny access, implementations MUST ensure that any
- matching rule comparisons are done on the underlying abstract value,
- regardless of the particular encoding used.
-
-9. IANA Considerations
-
- The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP attribute description option registry [BCP64] as indicated
- by the following template:
-
- Subject:
- Request for LDAP Attribute Description Option Registration
- Option Name: binary
- Family of Options: NO
- Person & email address to contact for further information:
- Steven Legg <steven.legg@eb2bcom.com>
-
-
-
-Legg Expires 30 July 2006 [Page 6]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: The existing registration for "binary"
- should be updated to refer to RFC XXXX.
-
-10. References
-
-10.1. Normative References
-
- [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
- [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
- February 2005.
-
- [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress,
- February 2005.
-
- [PROT] Sermersheim, J., "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
- October 2005.
-
- [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
- June 2005.
-
- [PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates",
- draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
- 2005.
-
- [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
- Information Technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER).
-
-10.2. Informative References
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
-
-
-
-Legg Expires 30 July 2006 [Page 7]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
- Information technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services
-
-Author's Address
-
- Dr. Steven Legg
- eB2Bcom
- Suite 3, Woodhouse Corporate Centre
- 935 Station Street
- Box Hill North, Victoria 3129
- AUSTRALIA
-
- Phone: +61 3 9896 7830
- Fax: +61 3 9896 7801
- EMail: steven.legg@eb2bcom.com
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
-
-
-
-Legg Expires 30 July 2006 [Page 8]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 30 July 2006 [Page 9]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Informational OpenLDAP Foundation
-Expires in six months 18 July 2005
-
-
-
- Requesting Attributes by Object Class in the
- Lightweight Directory Access Protocol
- <draft-zeilenga-ldap-adlist-11.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Informational document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) search operation
- provides mechanisms for clients to request all user application
- attributes, all operational attributes, and/or attributes selected by
- their description. This document extends LDAP to support a mechanism
- that LDAP clients may use to request the return of all attributes of
- an object class.
-
-
-1. Background and Intended Use
-
- In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
- search operation [Protocol] support requesting the return of a set of
- attributes. This set is determined by a list of attribute
- descriptions. Two special descriptors are defined to request all user
- attributes ("*") [Protocol] and all operational attributes ("+")
- [RFC3673]. However, there is no convenient mechanism for requesting
- pre-defined sets of attributes such as the set of attributes used to
- represent a particular class of object.
-
- This document extends LDAP to allow an object class identifier to be
- specified in attributes lists, such as in Search requests, to request
- the return all attributes belonging to an object class. The
- COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
- class identifier from an attribute descriptions.
-
- For example, the attribute list of "@country" is equivalent to the
- attribute list of 'c', 'searchGuide', 'description', and
- 'objectClass'. This object class is described in [Schema].
-
- This extension is intended primarily to be used where the user is in
- direct control of the parameters of the LDAP search operation, for
- instance when entering a LDAP URL [LDAPURL] into a web browser. For
- example, <ldap:///dc=example,dc=com?@organization?base>.
-
-2. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
-
-3. Return of all Attributes of an Object Class
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- This extension allows object class identifiers is to be provided in
- the attributes field of the LDAP SearchRequest [Protocol] or other
- request values of the AttributeSelection data type (e.g., attributes
- field in pre/post read controls [ReadEntry]) and/or
- <attributeSelector> production (e.g., attributes of an LDAP URL
- [LDAPURL]). For each object class identified in the attributes field,
- the request is to be treated as if each attribute allowed by that
- class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was
- itself listed.
-
- This extension extends attributeSelector [Protocol] production as
- indicated by the following ABNF [ABNF]:
-
- attributeSelector /= objectclassdescription
- objectclassdescription = ATSIGN oid options
- ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
-
- where <oid> and <options> productions are as defined in [Models].
-
- The <oid> component of an <objectclassdescription> production
- identifies the object class by short name (descr) or object identifier
- (numericoid). If the value of the <oid> component is unrecognized or
- does not refer to an object class, the object class description is be
- treated an an unrecognized attribute description.
-
- The <options> production is included in the grammar for extensibility
- purposes. An object class description with an unrecognized or
- inappropriate option is to be treated as an unrecognized.
-
- While object class description options and attribute description
- options share the same syntax, they are not semantically related.
- This document does not define any object description option.
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
- [Models] attribute in the root DSE. Clients supporting this feature
- SHOULD NOT use the feature unless they have knowledge the server
- supports it.
-
-
-3. Security Considerations
-
- This extension provides a shorthand for requesting all attributes of
- an object class. As these attributes which could have been listed
- individually, introduction of this shorthand is not believed to raise
- additional security considerations.
-
- Implementors of this LDAP extension should be familiar with security
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- considerations applicable to the LDAP search operation [Protocol], as
- well as general LDAP security considerations [Roadmap].
-
-
-4. IANA Considerations
-
- Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
- document is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.5.2
- Description: OC AD Lists
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in this
- specification.
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-6. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
- work in progress.
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-6.2. Informative References
-
- [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
- 3673, December 2003.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
- draft-zeilenga-ldap-readentry-xx.txt, a work in
- progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 6]
-\f
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- The LDAP Assertion Control
- <draft-zeilenga-ldap-assert-05.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the IESG for consideration as a Standard Track
- document. Distribution of this memo is unlimited. Technical
- discussion of this document will take place on the IETF LDAP
- Extensions mailing list <ldapext@ietf.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
-Abstract
-
- This document defines the Lightweight Directory Access Protocol (LDAP)
- Assertion Control which allows a client to specify that a directory
- operation should only be processed if an assertion applied to the
- target entry of the operation is true. It can be used to construct
- "test and set" and "test and clear" and other conditional operations.
-
-
-1. Overview
-
- This document defines the Lightweight Directory Access Protocol (LDAP)
- [Roadmap] assertion control. The assertion control allows the client
- to specify a condition which must be true for the operation to be
- processed normally. Otherwise the operation fails. For instance, the
- control can be used with the Modify operation [Protocol] to perform
- atomic "test and set" and "test and clear" operations.
-
- The control may be attached to any update operation to support
- conditional addition, deletion, modification, and renaming of the
- target object. The asserted condition is evaluated as an integral
- part the operation.
-
- The control may also be used with the search operation. Here the
- assertion is applied to the base object of the search before searching
- for objects matching the search scope and filter.
-
- The control may also be used with the compare operation. Here it
- extends the compare operation to allow a more complex assertion.
-
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-3. The Assertion Control
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- The assertion control is an LDAP Control [Protocol] whose controlType
- is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
- [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
- There is no corresponding response control.
-
- The control is appropriate for both LDAP interrogation and update
- operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
- (rename), and Search. It is inappropriate for Abandon, Bind nor
- Unbind, and Start TLS operations.
-
- When the control is attached to an LDAP request, the processing of the
- request is conditional on the evaluation of the Filter as applied
- against the target of the operation. If the Filter evaluates to TRUE,
- then the request is processed normally. If the Filter evaluates to
- FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
- resultCode is returned and no further processing is performed.
-
- For Add, Compare, and ModifyDN the target is indicated by the entry
- field in the request. For Modify, the target is indicated by the
- object field. For Delete, the target is indicated by the DelRequest
- type. For the Compare operation and all update operations, the
- evaluation of the assertion MUST be performed as an integral part of
- the operation. That is, the evaluation of the assertion and the
- normal processing of the operation SHALL be done as one atomic action.
-
- For search operation, the target is indicated by the baseObject field
- and the evaluation is done after "finding" but before "searching"
- [Protocol]. Hence, no entries or continuations references are
- returned if the assertion fails.
-
- Servers implementing this technical specification SHOULD publish the
- object identifier IANA-ASSIGNED-OID as a value of the
- 'supportedControl' attribute [Models] in their root DSE. A server MAY
- choose to advertise this extension only when the client is authorized
- to use it.
-
- Other documents may specify how this control applies to other LDAP
- operations. In doing so, they must state how the target entry is
- determined.
-
-
-4. Security Considerations
-
- The filter may, like other components of the request, contain
- sensitive information. When so, this information should be
- appropriately protected.
-
- As with any general assertion mechanism, the mechanism can be used to
-
-
-
-Zeilenga LDAP Assertion Control [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- determine directory content. Hence, this mechanism SHOULD be subject
- to appropriate access controls.
-
- Some assertions may be very complex, requiring significant time and
- resources to evaluate. Hence, this mechanism SHOULD be subject to
- appropriate administrative controls.
-
- Security considerations for the base operations [Protocol] extended by
- this control, as well as general LDAP security considerations
- [Roadmap], generally apply to implementation and use of this
- extension.
-
-
-5. IANA Considerations
-
-5.1. Object Identifier
-
- It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [BCP64bis] to identify the LDAP Assertion Control defined
- in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Assertion Control
-
-5.2 LDAP Protocol Mechanism
-
- Registration of this protocol mechanism [BCP64bis] is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: Assertion Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-5.3 LDAP Result Code
-
- Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
- is requested.
-
-
-
-Zeilenga LDAP Assertion Control [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: assertionFailed
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-6. Acknowledgments
-
- The assertion control concept is attributed to Morteza Ansari.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
-
-8.2. Informative References
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 6]
-\f
-
-
+++ /dev/null
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 19 November 2004
-
-
-
- LDAP "Who am I?" Operation
- <draft-zeilenga-ldap-authzid-10.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
- This specification provides a mechanism for Lightweight Directory
-
-
-
-Zeilenga LDAP "Who am I?" [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- Access Protocol (LDAP) clients to obtain the authorization identity
- which the server has associated with the user or application entity.
- This mechanism is specified as an LDAP extended operation called the
- LDAP "Who am I?" operation.
-
-
-Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-1. Background and Intent of Use
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) [RFC3377] operation which clients can use to obtain the primary
- authorization identity in its primary form which the server has
- associated with the user or application entity. The operation is
- called the "Who am I?" operation.
-
- This specification is intended to replace the existing [AUTHRESP]
- mechanism which uses Bind request and response controls to request and
- return the authorization identity. Bind controls are not protected by
- the security layers established by the Bind operation which includes
- them. While it is possible to establish security layers using Start
- TLS [RFC2830] prior to the Bind operation, it is often desirable to
- use security layers established by the Bind operation. An extended
- operation sent after a Bind operation is protected by the security
- layers established by the Bind operation.
-
- There are other cases where it is desirable to request the
- authorization identity which the server associated with the client
- separately from the Bind operation. For example, the "Who am I?"
- operation can be augmented with a Proxied Authorization Control
- [PROXYAUTH] to determine the authorization identity which the server
- associates with the identity asserted in the Proxied Authorization
- Control. The "Who am I?" operation can also be used prior to the Bind
- operation.
-
- Servers often associate multiple authorization identities with the
- client and each authorization identity may be represented by multiple
- authzId [RFC2829] strings. This operation requests and returns the
- authzId the server considers to be primary. In the specification, the
- term "the authorization identity" and "the authzId" are generally to
- be read as "the primary authorization identity" and the "the primary
- authzId", respectively.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
-2. The "Who am I?" Operation
-
- The "Who am I?" operation is defined as an LDAP Extended Operation
- [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
- (OID). This section details the syntax of the operation's whoami
- request and response messages.
-
- whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
-
-
-2.1. The whoami Request
-
- The whoami request is an ExtendedRequest with the requestName field
- containing the whoamiOID OID and an absent requestValue field. For
- example, a whoami request could be encoded as the sequence of octets
- (in hex):
-
- 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
- 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
-
-
-2.2. The whoami Response
-
- The whoami response is an ExtendedResponse where the responseName
- field is absent and the response field, if present, is empty or an
- authzId [RFC2829]. For example, a whoami response returning the
- authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
- would be encoded as the sequence of octets (in hex):
-
- 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
- 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
- 4e 45 54
-
-
-3. Operational Semantics
-
- The "Who am I?" operation provides a mechanism, a whoami Request, for
- the client to request that the server returns the authorization
- identity it currently associates with the client and provides a
- mechanism, a whoami Response, for the server to respond to that
- request.
-
- Servers indicate their support for this extended operation by
- providing whoamiOID object identifier as a value of the
- 'supportedExtension' attribute type in their root DSE. Server SHOULD
- advertise this extension only when the client is willing and able to
- perform this operation.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- If the server is willing and able to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with a success resultCode. If the server is treating
- the client as an anonymous entity, the response field is present but
- empty. Otherwise the server provides the authzId [RFC2829]
- representing the authorization identity it currently associates with
- the client in the response field.
-
- If the server is unwilling or unable to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with an appropriate non-success resultCode (such as
- operationsError, protocolError, confidentialityRequired,
- insufficientAccessRights, busy, unavailable, unwillingToPerform, or
- other) and an absent response field.
-
- As described in [RFC2251] and [RFC2829], an LDAP session has an
- "anonymous" association until the client has been successfully
- authenticated using the Bind operation. Clients MUST NOT invoke the
- "Who Am I?" operation while any Bind operation is in progress,
- including between two Bind requests made as part of a multi-stage Bind
- operation. Where a whoami Request is received in violation of this
- absolute prohibition, the server should return a whoami Response with
- an operationsError resultCode.
-
-
-4. Extending the "Who am I?" operation with controls
-
- Future specifications may extend the "Who am I?" operation using the
- control mechanism [RFC2251]. When extended by controls, the "Who am
- I?" operation requests and returns the authorization identity the
- server associates with the client in a particular context indicated by
- the controls.
-
-
-4.1. Proxied Authorization Control
-
- The Proxied Authorization Control [PROXYAUTH] is used by clients to
- request that the operation it is attached to operates under the
- authorization of an assumed identity. The client provides the
- identity to assume in the Proxied Authorization request control. If
- the client is authorized to assume the requested identity, the server
- executes the operation as if the requested identity had issued the
- operation.
-
- As servers often map the asserted authzId to another identity
- [RFC2829], it is desirable to request the server provide the authzId
- it associates with the assumed identity.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- When a Proxied Authorization Control is be attached to the "Who Am I?"
- operation, the operation requests the return of the authzId the server
- associates with the identity asserted in the Proxied Authorization
- Control. The TBD result code is used to indicate that the server does
- not allow the client to assume the asserted identity. [[Note to RFC
- Editor: TBD is to be replaced with the name/code assigned by IANA for
- [PROXYAUTH] use.]]
-
-
-5. Security Considerations
-
- Identities associated with users may be sensitive information. When
- so, security layers [RFC2829][RFC2830] should be established to
- protect this information. This mechanism is specifically designed to
- allow security layers established by a Bind operation to protect the
- integrity and/or confidentiality of the authorization identity.
-
- Servers may place access control or other restrictions upon the use of
- this operation. As stated in Section 3, the server SHOULD advertise
- this extension when it is willing and able to perform the operation.
-
- As with any other extended operations, general LDAP security
- considerations [RFC3377] apply.
-
-
-6. IANA Considerations
-
- The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am
- I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation, under its IANA-assigned private enterprise allocation
- [PRIVATE], for use in this specification.
-
- Registration of this protocol mechanism [RFC3383] is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.11.3
- Description: Who am I?
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Extended Operation
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-7. Acknowledgment
-
- This document borrows from prior work in this area including
-
-
-
-Zeilenga LDAP "Who am I?" [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
- Smith and Mark Wahl.
-
- The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
- command. The whoami(1) command displays the effective user id.
-
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-9. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
- "Authentication Methods for LDAP", RFC 2829, June 2000.
-
- [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
- Directory Access Protocol (v3): Extension for Transport
- Layer Security", RFC 2830, May 2000.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
- draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
-
-
-9.2. Informative References
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
-
-
-
-Zeilenga LDAP "Who am I?" [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- (also RFC 3383), September 2002.
-
- [AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
- Identity Response and Request Controls",
- draft-weltman-ldapv3-auth-response-xx.txt, a work in
- progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
-
-
-
-Zeilenga LDAP "Who am I?" [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 23 October 2005
-Obsoletes: RFC 1274, RFC 2247
-Updates: RFC 2798
-
-
- COSINE LDAP/X.500 Schema
- <draft-zeilenga-ldap-cosine-01.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAPEXT mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 1]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- This document provides a collection of schema elements for use with
- the Lightweight Directory Access Protocol (LDAP) from the COSINE and
- Internet X.500 pilot projects.
-
- This document obsoletes RFC 1274 and RFC 2247.
-
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Background and Intended Use 3
- 1.1. Relationship with Other Documents
- 1.2. Terminology and Conventions
- 2. COSINE Attribute Types 4
- 2.1. associatedDomain
- 2.2. associatedName
- 2.3. buildingName
- 2.3. co
- 2.5. documentAuthor
- 2.6. documentIdentifier
- 2.7. documentLocation
- 2.8. documentPublisher
- 2.9. documentTitle
- 2.10. documentVersion
- 2.11. drink
- 2.12. homePhone
- 2.13. homePostalAddress
- 2.14. host
- 2.16. info
- 2.17. mail
- 2.18. manager
- 2.19. mobile
- 2.20. organizationalStatus
- 2.21. pager
- 2.22. personalTitle
- 2.23. roomNumber
- 2.24. secretary
- 2.26. uniqueIdentifier
- 2.27. userClass
- 3. COSINE Object Classes 14
- 3.1. account
- 3.2. document
- 3.3. documentSeries
- 3.4. domain
- 3.5. domainRelatedObject
- 3.6. friendlyCountry
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 2]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- 3.7. rFC822LocalPart
- 3.8. room
- 3.9. simpleSecurityObject
- 4. Security Considerations 19
- 5. IANA Considerations 20
- 6. Acknowledgments 21
- 7. Editor's Address
- 8. References
- A. Changes Since RFC 1274 23
- Intellectual Property Rights 24
- Full Copyright
-
-
-1. Background and Intended Use
-
- In the late 1980s, X.500 Directory Services were standardised by the
- CCITT (Commite' Consultatif International de Telegraphique et
- Telephonique), now a part of the ITU (International Telephone Union).
- This lead to Directory Service piloting activities in the early 1990s,
- including the COSINE (Co-operation and Open Systems Interconnection in
- Europe) PARADISE Project pilot [COSINEpilot] in Europe. Motivated by
- needs large scale directory pilots, RFC 1274 was published to
- standardize directory schema and naming architecture for use in the
- COSINE and other Internet X.500 pilots [RFC1274].
-
- In the years that followed, X.500 Directory Services have evolved to
- incorporate new capabilities and even new protocols. In particular,
- the Lightweight Directory Access Protocol (LDAP) [Roadmap] was
- introduced in the early 1990s [RFC1487], with Version 3 of LDAP
- introduced in the late 1990s [RFC2251] and subsequently revised in the
- 2005 [Roadmap].
-
- While much of the material in RFC 1274 has been superceed by
- subsequently published ITU-T Recommendations and IETF RFCs, many of
- the schema elements lack standardized schema descriptions for use in
- modern X.500 and LDAP directory services despite the fact that these
- schema elements are in wide use today. As the old schema descriptions
- cannot be used without adaptation, interoperabilty issues may arise
- due to lack of standardized modern schema descriptions.
-
- This document addresses these issues by offering standardized schema
- descriptions, where needed, for widely-used COSINE schema elements.
-
-1.1. Relationship to Other Documents
-
- This document, together with [Schema] and [Syntaxes], obsoletes RFC
- 1274 in its entirety. [Schema] replaces Sections 9.3.1 (Userid) and
- Section 9.3.21 (Domain Component) of RFC 1274. [Syntaxes] replaces
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 3]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- section 9.4 (Generally useful syntaxes) of RFC 1274.
-
- This document replaces the remainder of RFC 1274. Appendix A.
- discusses changes since RFC 1274, as well as why certain schema
- elements were not brought forward in this revision of the COSINE
- schema. All elements not brought are to be regarded as Historic.
-
- This document, together with [NamingPlan] and [Schema], obsoletes RFC
- 2247 in its entirety. [Schema] replaces Section 4 (Attribute Type
- Definition) and Section 5.1 (The dcObject object class) of RFC 2247.
- This document replaces Section 5.2 (The domain object class) of RFC
- 2247. The remainder of RFC 2247 is replaced by [NamingPlan].
-
- Some of these items were described in RFC 2798 (inetOrgPerson schema).
- This document supersedes these descriptions. This document, together
- with [Schema], replaces section 9.1.3 of RFC 2798.
-
-
-1.2. Terminology and Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- DIT stands for Directory Information Tree.
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent, a server.
- DSE stands for DSA-Specific Entry.
- DUA stands for Directory User Agent, a client.
-
- These terms are discussed in [Models].
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
-
-2. COSINE Attribute Types
-
- This section details COSINE attribute types for use in LDAP.
-
-
-2.1. associatedDomain
-
- The 'associatedDomain' attribute specifies DNS domains [RFC1034] which
- are associated with an object. For example, the entry in the DIT with
- a DN <DC=example,DC=com> might have an associated domain of
- "example.com".
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 4]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [Syntaxes].
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the <domain> production [RFC1034]. It is the
- application responsibility to ensure domains it stores in this
- attribute are appropriately represented.
-
- It is also noted that applications supporting Internationalized Domain
- Names SHALL use the ToASCII method [RFC3490] to produce <label>
- components of the <domain> production.
-
-
-2.2. associatedName
-
- The 'associatedName' attribute specifies names of entries in the
- organizational DIT associated with a DNS domain [RFC1034].
-
- ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.3. buildingName
-
- The 'buildingName' attribute specifies names of the buildings where an
- organization or organizational unit is based. For example, "The White
- House".
-
- ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 5]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.3. co
-
- The 'co' (Friendly Country Name) attribute specifies names of
- countries in human-readable format. For example, "Germany" and
- "Federal Republic of Germany". It is commonly used in conjunction
- with the 'c' (Country Name) [Schema] attribute (whose values are
- restricted to the two-letter codes defined in [ISO3166]).
-
- ( 0.9.2342.19200300.100.1.43 NAME 'co'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.5. documentAuthor
-
- The 'documentAuthor' attribute specifies the distinguished name of
- authors (or editors) of a document. For example,
-
- ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.6. documentIdentifier
-
- The 'documentIdentifier' attribute specifies unique identifiers for a
- document. A document may be identified by more than one unique
- identifier. For example, RFC 3383 and BCP 64 are unique identifers
- which (presently) refer to the same document.
-
- ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 6]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.7. documentLocation
-
- The 'documentLocation' attribute specifies locations of the document
- original.
-
- ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.8. documentPublisher
-
- The 'documentPublisher' attribute is the persons and/or organizations
- that published the document. Documents which are jointly published
- have one value for each publisher.
-
- ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.9. documentTitle
-
- The 'documentTitle' attribute specifies the titles of a document.
- Multiple values are allowed to accomadate both long and short titles,
- or other situations where a document has multiple titles. For
- example, "The Lightweight Directory Access Protocol Technical
- Specification" and "The LDAP Technical Specification".
-
- ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 7]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.10. documentVersion
-
- The 'documentVersion' attribute specifies the version information of a
- document.
-
- ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.11. drink
-
- The 'drink' (favoriteDrink) attribute specifies favorite drinks of an
- object (or person). For instance, "cola" and "beer".
-
- ( 0.9.2342.19200300.100.1.5 NAME 'drink'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.12. homePhone
-
- The 'homePhone' (Home Telephone Number) attribute specifies home
- telephone numbers (e.g., "+1 775 555 1234") associated with a person.
-
- ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.13. homePostalAddress
-
- The 'homePostalAddress' attribute specifies home postal addresses for
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 8]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- an object. Each value should be limited to up to 6 directory strings
- of 30 characters each. (Note: it is not intended that the directory
- service enforce these limits.)
-
-
- ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
- 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.14. host
-
- The 'host' attribute specifies host computers, generally by their
- primary fully-qualified domain name (e.g., my-host.example.com).
-
- ( 0.9.2342.19200300.100.1.9 NAME 'host'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.16. info
-
- The 'info' attribute specifies any general information pertinent to an
- object. This information is not necessarily descriptive of the
- object.
-
- Applications should not attach specific semantics to values of this
- attribute. The 'description' attribute [Schema] is available for
- specifying descriptive information pertinent to an object.
-
- ( 0.9.2342.19200300.100.1.4 NAME 'info'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 9]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.17. mail
-
- The 'mail' (rfc822mailbox) attribute type holds Internet mail
- addresses in Mailbox [RFC2821] form (e.g.: user@example.com).
-
- ( 0.9.2342.19200300.100.1.3 NAME 'mail'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [Syntaxes].
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the <Mailbox> production [RFC2821]. It is the
- application responsibility to ensure domains it stores in this
- attribute are appropriately represented.
-
- Additionally, the directory will compare values per the matching rules
- named in the above attribute type description. As these rules differ
- from rules which normally apply to <Mailbox> comparisons, operational
- issues may arise. For example, the assertion (mail=joe@example.com)
- will match "JOE@example.com" even though the <local-parts> differ.
- Also, where a user has two <Mailbox>es which whose addresses differ
- only by case of the <local-part>, both cannot be listed as values of
- the user's mail attribute (as they are considered by the
- 'caseIgnoreIA5Match' rule to be equal).
-
- It is also noted that applications supporting internationalized domain
- names SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
- components of the <Mailbox> production.
-
-
-2.18. manager
-
- The 'manager' attribute specifies managers, by distinguished name, of
- the person (or entity).
-
- ( 0.9.2342.19200300.100.1.10 NAME 'manager'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.19. mobile
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 10]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
- telephone numbers (e.g., "+1 775 555 6789") associated with a person
- (or entity).
-
- ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.20. organizationalStatus
-
- The 'organizationalStatus' attribute specifies categories by which a
- person is often referred to in an organization. Examples of usage in
- academia might include "undergraduate student", "researcher",
- "professor", "staff", etc.. Multiple values are allowed were the
- person is in multiple categories.
-
- Directory administrators and application designers SHOULD consider
- carefully the distinctions between this and the 'title' and
- 'userClass' attributes.
-
- ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.21. pager
-
- The 'pager' (pagerTelephoneNumber) attribute specifies pager telephone
- numbers (e.g., "+1 775 555 5555") for an object.
-
- ( 0.9.2342.19200300.100.1.42 NAME 'pager'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 11]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- described in [Syntaxes].
-
-
-2.22. personalTitle
-
- The 'personalTitle' attribute specifies personal titles for a person.
- Examples of personal titles are "Frau", "Dr.", "Herr", and
- "Professor".
-
- ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.23. roomNumber
-
- The 'roomNumber' attribute specifies the room number of an object.
- During periods of renumbering or in other circumstances where a room
- has multiple valid room numbers associated with it, multiple values
- may be provided. Note that the 'cn' (commonName) attribute type
- SHOULD be used for naming room objects.
-
- ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.24. secretary
-
- The 'secretary' attribute specifies secretaries and/or administrative
- assistants, by distinguish name, of a person.
-
- ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 12]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.26. uniqueIdentifier
-
- The 'uniqueIdentifier' attribute specifies a unique identifier for an
- object represented in the Directory. The domain within which the
- identifier is unique, and the exact semantics of the identifier, are
- for local definition. For a person, this might be an institution-wide
- payroll number. For an organizational unit, it might be a department
- code.
-
- ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
- Note: X.520 also describes an attribute called 'uniqueIdentifier'
- (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
- [Schema]. The attribute detailed here ought not be confused
- with 'x500UniqueIdentifier'.
-
-
-2.27. userClass
-
- The 'userClass' attribute specifies categories of computer or
- application user. The semantics placed on this attribute are for
- local interpretation. Examples of current usage of this attribute in
- academia are "student", "staff", "faculty", etc.. Note that the
- 'organizationalStatus' attribute type is now often be preferred as it
- makes no distinction between persons as opposed to users.
-
- ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-3. COSINE Object Classes
-
- This section details COSINE object classes for use in LDAP.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 13]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-3.1. account
-
- The 'account' object class is used to define entries representing
- computer accounts. The 'uid' attribute SHOULD be used for naming
- entries of this object class.
-
- ( 0.9.2342.19200300.100.4.5 NAME 'account'
- SUP top STRUCTURAL
- MUST uid
- MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
-
- The 'top' object class is described in [Models]. The 'description',
- 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
- [Schema]. The 'host' attribute type is described in Section 2 of this
- document.
-
- Example:
-
- dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
- objectClass: account
- uid: kdz
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-
-3.2. document
-
- The 'document' object class is used to define entries which represent
- documents.
-
- ( 0.9.2342.19200300.100.4.6 NAME 'document'
- SUP top STRUCTURAL
- MUST documentIdentifier
- MAY ( cn $ description $ seeAlso $ l $ o $ ou $
- documentTitle $ documentVersion $ documentAuthor $
- documentLocation $ documentPublisher ) )
-
- The 'top' object class is described in [Models]. The 'cn',
- 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
- described in [Schema]. The 'documentIdentifier', 'documentTitle',
- 'documentVersion', 'documentAuthor', 'documentLocation', and
- 'documentPublisher' attribute types are described in Section 2 of this
- document.
-
- Example:
-
- dn: documentIdentifier=RFCXXXX,cn=RFC,dc=Example,dc=COM
- objectClass: document
- documentIdentifier: RFC XXXXX
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 14]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- documentTitle: COSINE LDAP/X.500 Schema
- documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
- documentLocation: http://www.rfc-editor.org/rfc/rfcXXXX.txt
- documentPublisher: Internet Engineering Task Force
- description: A collection of schema elements for use in LDAP
- description: Obsoletes RFC 1274
- seeAlso: documentIdentifier=[Roadmap],cn=RFC,dc=Example,dc=COM
- seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
-
-
-3.3. documentSeries
-
- The documentSeries object class is used to define an entry which
- represents a series of documents (e.g., The Request For Comments
- memos).
-
- ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
- SUP top STRUCTURAL
- MUST cn
- MAY ( description $ l $ o $ ou $ seeAlso $
- telephonenumber ) )
-
- The 'top' object class is described in [Models]. The 'description',
- 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
- described in [Schema].
-
- Example:
-
- dn: cn=RFC,dc=Example,dc=COM
- objectClass: documentSeries
- cn: Request for Comments
- cn: RFC
- description: a series of memos about the Internet
-
-
-3.4. domain
-
- The 'domain' object class is used to define entries which represent
- DNS domains for objects which are not organizations, organizational
- units, or other kinds of objects more approproiately defined using an
- object class specific to the kind of object being defined (e.g.,
- 'organization', 'organizationUnit', etc.).
-
- The 'dc' attribute should be used for naming entries of 'domain'
- object class.
-
- ( 0.9.2342.19200300.100.4.13 NAME 'domain'
- SUP top STRUCTURAL
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 15]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- MUST dc
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description $ o $
- associatedName ) )
-
- The 'top' object class and the 'dc', 'userPassword', 'searchGuide
- 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress
- 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
- 'teletexTerminalIdentifier', 'telephoneNumber',
- 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
- 'postOfficeBox', 'postalCode', 'postalAddress',
- 'physicalDeliveryOfficeName', 'st', 'l', 'description', 'o', types are
- described in [Schema]. The 'associatedName' attribute type is
- described in Section 2 of this document.
-
- Example:
- dn: dc=com
- objectClass: domain
- dc: com
- description: the .COM TLD
-
-
-3.5. domainRelatedObject
-
- The 'domainRelatedObject' object class is used to define entries which
- represent DNS domains which are "equivalent" to an X.500 domain: e.g.,
- an organization or organizational unit.
-
- ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
- SUP top AUXILIARY
- MUST associatedDomain )
-
- The 'top' object class is described in [Models]. The
- 'associatedDomain' attribute type is described in Section 2 of this
- document.
-
- Example:
-
- dn: dc=example,dc=com
- objectClass: organization
- objectClass: dcObject
- objectClass: domainRelatedObject
- dc: example
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 16]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- associatedDomain: example.com
- o: Example Organization
-
- The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
- attribute types are described in [Schema].
-
-
-3.5. friendlyCountry
-
- The 'friendlyCountry' object class is used to define entries
- representing countries in the DIT. The object class is used to allow
- friendlier naming of countries than that allowed by the object class
- 'country' [Schema].
-
- ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
- SUP country STRUCTURAL
- MUST co )
-
- The 'country' object class is described in [Schema]. The 'co'
- attribute type is described in Section 2 of this document.
-
- Example:
-
- dn: c=DE
- objectClass: country
- objectClass: friendlyCountry
- c: DE
- co: Deutschland
- co: Germany
- co: Federal Republic of Germany
- co: FRG
-
- The 'c' attribute type is described in [Schema].
-
-
-3.6. rFC822LocalPart
-
- The 'rFC822LocalPart' object class is used to define entries which
- represent the local part of Internet mail addresses [RFC2822]. This
- treats the local part of the address as a 'domain' object.
-
- ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
- SUP domain STRUCTURAL
- MAY ( cn $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
- seeAlso $ sn $ street $ telephoneNumber $
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 17]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- teletexTerminalIdentifier $ telexNumber $ x121Address ) )
-
- The 'domain' object class is described in Section 3.4 of this
- document. The 'cn', 'description', 'destinationIndicator',
- 'facsimileTelephoneNumber', 'internationaliSDNNumber,
- 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
- 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
- 'seeAlso', 'sn, 'street', 'telephoneNumber',
- 'teletexTerminalIdentifier', 'telexNumber' and 'x121Address' attribute
- types are described in [Schema].
-
-
- Example:
-
- dn: dc=kdz,dc=example,dc=com
- objectClass: domain
- objectClass: rFC822LocalPart
- dc: kdz
- associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
- The 'dc' attribute type is described in [Schema].
-
-
-3.7. room
-
- The 'room' object class is used to define entries representing rooms.
- The 'cn' (commonName) attribute SHOULD be used for naming entries of
- this object class.
-
- ( 0.9.2342.19200300.100.4.7 NAME 'room'
- SUP top STRUCTURAL
- MUST cn
- MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
-
- The 'top' object class is described in [Models]. The 'cn',
- 'description', 'seeAlso' and 'telephoneNumber' attribute types are
- described in [Schema]. The 'roomNumber' attribute type is described
- in Section 2 of this document.
-
- dn: cn=conference room,dc=example,dc=com
- objectClass: room
- cn: conference room
- telephoneNumber: +1 755 555 1111
-
-
-3.8. simpleSecurityObject
-
- The 'simpleSecurityObject' object class is used to require an entry to
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 18]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- have an 'userPassword' attribute when the entry's structural object
- class does not require (or allow) the 'userPassword attribute'.
-
- ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
- SUP top AUXILIARY
- MUST userPassword )
-
- The 'top' object class is described in [Models]. The 'userPassword'
- attribute type is described in [Schema].
-
- dn: dc=kdz,dc=Example,dc=COM
- objectClass: account
- objectClass: simpleSecurityObject
- uid: kdz
- userPassword: My Password
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-
-4. Security Considerations
-
- General LDAP security considerations [Roadmap] is applicable to the
- use of this schema. Additional considerations are noted above where
- appropriate.
-
- Directories administrators should ensure that access to sensitive
- information is restricted to authorized entities, but ensure that
- appropriate data security services, including data integrity and data
- confidentiality, are used to protect against eavesdropping.
-
- Simple authentication (e.g., plain text passwords) mechanisms should
- only be used when adequate data security services are in place. LDAP
- offers reasonable strong authentication and data security services
- [AuthMeth].
-
-
-
-5. IANA Considerations
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update upon Standard Action the LDAP descriptors registry [BCP64bis]
- as indicated the following template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comments
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see comments
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 19]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors should be updated to refer to RFC XXXX.
-
- NAME Type OID
- ------------------------ ---- --------------------------
- account O 0.9.2342.19200300.100.4.5
- associatedDomain A 0.9.2342.19200300.100.1.37
- associatedName A 0.9.2342.19200300.100.1.38
- buildingName A 0.9.2342.19200300.100.1.48
- co A 0.9.2342.19200300.100.1.43
- document O 0.9.2342.19200300.100.4.6
- documentAuthor A 0.9.2342.19200300.100.1.14
- documentIdentifier A 0.9.2342.19200300.100.1.11
- documentLocation A 0.9.2342.19200300.100.1.15
- documentPublisher A 0.9.2342.19200300.100.1.56
- documentSeries O 0.9.2342.19200300.100.4.8
- documentTitle A 0.9.2342.19200300.100.1.12
- documentVersion A 0.9.2342.19200300.100.1.13
- domain O 0.9.2342.19200300.100.4.13
- domainRelatedObject O 0.9.2342.19200300.100.4.17
- drink A 0.9.2342.19200300.100.1.5
- favouriteDrink A* 0.9.2342.19200300.100.1.5
- friendlyCountry O 0.9.2342.19200300.100.4.18
- friendlyCountryName A* 0.9.2342.19200300.100.1.43
- homePhone A 0.9.2342.19200300.100.1.20
- homePostalAddress A 0.9.2342.19200300.100.1.39
- homeTelephone A* 0.9.2342.19200300.100.1.20
- host A 0.9.2342.19200300.100.1.9
- info A 0.9.2342.19200300.100.1.4
- mail A 0.9.2342.19200300.100.1.3
- manager A 0.9.2342.19200300.100.1.10
- mobile A 0.9.2342.19200300.100.1.41
- mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
- organizationalStatus A 0.9.2342.19200300.100.1.45
- pager A 0.9.2342.19200300.100.1.42
- pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
- personalTitle A 0.9.2342.19200300.100.1.40
- rFC822LocalPart O 0.9.2342.19200300.100.4.14
- rfc822Mailbox A* 0.9.2342.19200300.100.1.3
- room O 0.9.2342.19200300.100.4.7
- roomNumber A 0.9.2342.19200300.100.1.6
- secretary A 0.9.2342.19200300.100.1.21
- simpleSecurityObject O 0.9.2342.19200300.100.4.19
- singleLevelQuality A 0.9.2342.19200300.100.1.50
- uniqueIdentifier A 0.9.2342.19200300.100.1.44
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 20]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- userClass A 0.9.2342.19200300.100.1.8
-
- where Type A is Attribute and Type O is ObjectClass, and *
- indicates the registration is historic in nature.
-
-
-6. Acknowledgments
-
- This document is based upon RFC 1274 by Paul Barker and Steve Kille,
- as well as RFC 2247 by Steve Kill, Mark Wahl, Al Grimstad, Rick Huber,
- and Sri Satulari.
-
-
-7. Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-8.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts
- and facilities", STD 13 (also RFC 1034), November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
- Sataluri, "Using Domains in LDAP/X.500 Distinguished
- Names", January 1998.
-
- [RFC2821] Klensin, J. (editor), "Simple Mail Transfer Protocol",
- RFC 2822, April 2001.
-
- [RFC3490] Faltstrom, P., P. Hoffman, and A. Costello,
- "Internationalizing Domain Names in Applications
- (INDA)", RFC 3490, March 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 21]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
-
-8.2. Informative References
-
- [COSINEpilot]
-
- [NamingPlan] Zeilenga, K., "The Internet Naming Plan for LDAP/X.500
- Directories", draft-zeilenga-ldap-namingplan-xx.txt, a
- work in progress.
-
- [ISO3166] International Organization for Standardization, "Codes
- for the representation of names of countries", ISO 3166.
-
- [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
- Schema", November 1991.
-
- [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
- 2798, April 2000.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-Appendix A. Changes since RFC 1274
-
- This document represents a substantial rewrite of RFC 1274. The
- following sections summarize the substantive changes.
-
-A.1. LDAP Short Names
-
- A number of COSINE attribute types have short names in LDAP.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 22]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- X.500 Name LDAP Short Name
- ------------- ---------------
- domainComponent dc
- favoriteDrink drink
- friendCountryName co
- homeTelephoneNumber homePhone
- mobileTelephoneNumber mobile
- pagerTelephoneNumber pager
- rfc822Mailbox mail
- userid uid
-
- While the LDAP short names are generally used in LDAP, some
- implementations may (for legacy reasons [Historic]) recognize the
- attribute type by its X.500 name. Hence, the X.500 names have been
- reserved solely for this purpose.
-
- Note: 'uid' and 'dc' are described in [Schema].
-
-
-A.2. pilotObject
-
- The 'pilotObject' object class was not brought forward as its function
- is largely replaced by operational attributes introduced in X.500(93)
- [X.501] and version 3 of LDAP [Models]. For instance, the function
- of the 'lastModifiedBy' and 'lastModifiedTime' attribute types is now
- served by the 'creatorsName', 'createTimestamp', 'modifiersName', and
- 'modifyTimestamp' operational attributes [Models].
-
-
-A.3. pilotPerson
-
- The 'pilotPerson' object class was not brought forward as its function
- is largely replaced by the 'organizationalPerson' [Models] object
- class and its subclasses, such as 'inetOrgPerson' [RFC2798].
-
- Most of the related attribute types (e.g., 'mail', 'manager', etc.)
- were brought forward as they are used in other object classes.
-
-
-A.4. dNSDomain
-
- The 'dNSDomain' object class and related attribute types were not
- brought forward as its use is primarily experimental [RFC1279].
-
-
-A.5. pilotDSA and qualityLabelledData
-
- The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 23]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- related attribute types, were not brought forward as it as its use is
- primarily experimental [QoS].
-
-
-A.6. Attribute syntaxes
-
- RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
- This has been replaced with the IA5String syntax and approrpiate
- matching rules in 'mail' and 'associatedDomain'.
-
- RFC 1274 restricted 'mail' to have non-zero length values. This
- restriction is not reflected in the IA5String syntax used in the
- definitions provided in this specification. However, as values are
- to conform to the <Mailbox> production, the 'mail' should not contain
- zero-length values. Unfornuately, the directory service will not
- enforce this restriction.
-
-
-Appendix B. Changes since RFC 2247
-
- The 'domainNameForm' name form was not brought forward as
- specification of name forms used in LDAP is left to a future
- specification.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 24]
-\f
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 25]
-\f
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Modify-Increment Extension
- <draft-zeilenga-ldap-incr-01.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Experimental document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-Abstract
-
- This document describes an extension to the Lightweight Directory
- Access Protocol (LDAP) Modify operation to support an increment
- capability. This extension is useful in provisioning applications,
- especially when combined with the assertion control and/or the
- pre-read or post-read control extension.
-
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol [Roadmap] does not currently
- provide an operation to increment values of an attribute. A client
- must read the values of the attribute, then modify those values to
- increment them by the desired amount. As the values may be updated by
- other clients between this add and modify, the client must be careful
- to construct the modify request so that it fails in this case, and
- upon failure, re-read the values and construct a new modify request.
-
- This document extends the LDAP Modify Operation [Protocol] to support
- an increment values capability. This feature is intended to be used
- with either the LDAP pre-read or post-read control extension
- [ReadEntry]. This feature may also be used with the LDAP assertion
- control [Assertion] to provide test-and-increment functionality.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. The Modify-Increment Extension
-
- This document extends the LDAP Modify request to support a increment
- values capability. Implementations of this extension SHALL support an
- additional ModifyRequest operation enumeration value increment (IANA-
- ASSIGNED-TYPE) as described herein. Implementations not supporting
- this extension will treat this value as they would an unlisted value,
- e.g., as a protocol error.
-
- The increment (IANA-ASSIGNED-TYPE) operation value specifies that an
- increment values modification is requested. All existing values of
- the modification attribute are to be incremented by the listed value.
- The modification attribute must be appropriate for request, e.g., must
- have INTEGER or other increment-able values, and the modification must
- provide one and only value. If the attribute is not appropriate for
- the request, a constraintViolation or other appropriate error is to be
- returned. If multiple values are provided, a protocolError is to be
- returned.
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
- [RFC3674] attribute in the root DSE. Clients supporting this feature
- SHOULD NOT use the feature unless they have knowledge the server
- supports it.
-
-
- 3. LDIF Support
-
- To represent Modify-Increment requests in LDAP Data Interchange Format
- [RFC2849], the ABNF [RFC2234] production <mod-spec> is extended as
- follows:
-
- mod-spec /= "increment:" FILL AttributeDescription SEP
- attrval-spec "-" SEP
-
- For example,
-
- # Increment uidNumber
- dn: cn=max-assigned uidNumber,dc=example,dc=com
- changetype: modify
- increment: uidNumber
- uidNumber: 1
- -
-
- This LDIF fragment represents a Modify request to increment the
- value(s) of uidNumber by 1.
-
-
-4. Security Considerations
-
- General LDAP security considerations [Roadmap], as well as those
- specific to the LDAP Modify [Protocol], apply to this Modify-Increment
- extension. Beyond these considerations, it is noted that introduction
- of this extension should reduce application complexity (by provide one
- operation what presently requires multiple operation) and, hence, may
- aide in the production of correct and secure implementations.
-
-
-5. IANA Considerations
-
- Registration of the following values [BCP64bis] is requested.
-
-
-5.1. Object Identifier
-
- It is requested that IANA assign an LDAP Object Identifier to identify
- the LDAP Modify-Increment feature as defined in this document.
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Modify-Increment feature
-
-
-
-5.2. LDAP Protocol Mechanism
-
- It is requested that the following LDAP Protocol Mechanism be
- registered.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
-
-5.3. LDAP Protocol Mechanism
-
- It is requested that IANA assign an LDAP ModifyRequest Operation Type
- [BCP64bis] for use in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- ModifyRequest Operation Name: increment
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
-
-6. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-7. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
- December 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
-
-7.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
- draft-zeilenga-ldap-readentry-xx.txt, a work in
- progress.
-
- [Assertion] Zeilenga, K., "LDAP Assertion Control",
- draft-zeilenga-ldap-assert-xx.txt, a work in progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 6]
-\f
-
-
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Read Entry Controls
- <draft-zeilenga-ldap-readentry-04.txt>
-
-
-1. Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
-Abstract
-
- This document specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) to allow the client to read the target entry of
- an update operation. The client may request to read the entry before
- and/or after the modifications are applied. These reads are done as
- an atomic part of the update operation.
-
-
-1. Background and Intent of Use
-
- This document specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) [Roadmap] to allow the client to read the
- target entry of an update operation (e.g., Add, Delete, Modify,
- ModifyDN). The extension utilizes controls [Protocol] attached to
- update requests to request and return copies of the target entry. One
- request control, called the Pre-Read request control, indicates that a
- copy of the entry before application of update is to be returned.
- Another control, called the Post-Read request control, indicates that
- a copy of the entry after application of the update is to be returned.
- Each request control has a corresponding response control used to
- return the entry.
-
- To ensure proper isolation, the controls are processed as an atomic
- part of the update operation.
-
- The functionality offered by these controls is based upon similar
- functionality in the X.500 Directory Access Protocol (DAP) [X.511].
-
- The Pre-Read controls may be used to obtain replaced or deleted values
- of modified attributes or a copy of the entry being deleted.
-
- The Post-Read controls may be used to obtain values of operational
- attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
- [Models] attributes, updated by the server as part of the update
- operation.
-
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent (i.e., a directory server).
- DSE stands for DSA-specific Entry.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-3. Read Entry Controls
-
-3.1. The Pre-Read Controls
-
- The Pre-Read request and response controls are identified by the
- IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
- controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
- 'supportedControl' [Models] in their root DSE.
-
- The Pre-Read request control is an LDAP Control [Protocol] whose
- controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
- BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
- The criticality may be TRUE or FALSE. This control is appropriate for
- the modifyRequest, delRequest, and modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose controlType
- is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
- contains a BER-encoded SearchResultEntry. The criticality may be TRUE
- or FALSE. This control is appropriate for the modifyResponse,
- delResponse, and modDNResponse LDAP messages with a resultCode of
- success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of target entry
- prior to the application of the update. The AttributeSelection
- indicates, as discussed in [Protocol][RFC3673] which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no response control is provided.
-
-
-3.2. The Post-Read Controls
-
- The Post-Read request and response controls are identified by the
- IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
- controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- 'supportedControl' [Models] in their root DSE.
-
- The Post-Read request control is an LDAP Control [Protocol] whose
- controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
- STRING, contains a BER-encoded AttributeSelection [Protocol], as
- extended by [RFC3673]. The criticality may be TRUE or FALSE. This
- control is appropriate for the addRequest, modifyRequest, and
- modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose controlType
- is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
- SearchResultEntry. The criticality may be TRUE or FALSE. This
- control is appropriate for the addResponse, modifyResponse, and
- modDNResponse LDAP messages with a resultCode of success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of target entry
- after the application of the update. The AttributeSelection
- indicates, as discussed in [Protocol][RFC3673], which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no response control is provided.
-
-
-4. Interaction with other controls
-
- The Pre-Read and Post-Read controls may be combined with each other
- and/or with a variety of other controls. When combined with the
- assertion control [Assertion] and/or the manageDsaIT control
- [RFC3296], the semantics of each control included in the combination
- apply. The Pre-Read and Post-Read controls may be combined with other
- controls as detailed in other technical specifications.
-
-
-5. Security Considerations
-
- The controls defined in this document extend update operations to
- support read capabilities. Servers MUST ensure that the client is
- authorized both for reading of the information provided in this
- control in addition to ensuring the client is authorized to perform
- the requested directory update.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Security considerations for the update operations [Protocol] extended
- by this control, as well as general LDAP security considerations
- [Roadmap], generally apply to implementation and use of this extension
-
-
-6. IANA Considerations
-
- Registration of the following protocol values [BCP64bis] is requested.
-
-
-6.1. Object Identifier
-
- It is requested that IANA register an LDAP Object Identifier to
- identify LDAP protocol elements defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Read Entry Controls
-
-
-6.2. LDAP Protocol Mechanisms
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID.1
- Description: LDAP Pre-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
- in 2
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID.2
- Description: LDAP Post-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Comments: none
-
-
-7. Acknowledgment
-
- The LDAP Pre-Read and Post-Read controls are modeled after similar
- capabilities offered in the DAP [X.511].
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
- 3673, December 2003.
-
- [Assertion] Zeilenga, K., "LDAP Assertion Control",
- draft-zeilenga-ldap-assert-xx.txt, a work in progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [X.690] International Telecommunication Union -
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
-
-8.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
- Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
- progress.
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
-
-10. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 8]
-\f
-
-
+++ /dev/null
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Absolute True and False Filters
- <draft-zeilenga-ldap-t-f-10.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
-Abstract
-
- This document extends the Lightweight Directory Access Protocol (LDAP)
- to support absolute True and False filters based upon similar
- capabilities found in X.500 directory systems. The document also
- extends the String Representation of LDAP Search Filters to support
- these filters.
-
-
-1. Background
-
- The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
- True and False assertions. An 'and' filter with zero elements always
- evaluates to True. An 'or' filter with zero elements always evaluates
- to False. These filters are commonly used when requesting DSA-
- specific Entries (DSEs) which do not necessarily have 'objectClass'
- attributes. That is, where "(objectClass=*)" may evaluate to False.
-
- While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
- elements in 'and' and 'or' filter sets, the LDAPv2 string
- representation [RFC1960][RFC3494] could not represent empty 'and' and
- 'or' filter sets. Due to this, absolute True or False filters were
- (unfortunately) eliminated from LDAPv3 [Roadmap].
-
- This documents extends LDAPv3 to support absolute True and False
- assertions by allowing empty 'and' and 'or' in Search filters
- [Protocol] and extends the filter string representation [Filters] to
- allow empty filter lists.
-
- It is noted that certain search operations, such as those used to
- retrieve subschema information [Models], require use of particular
- filters. This document does not change these requirements.
-
- This feature is intended to allow a more direct mapping between DAP
- and LDAP (as needed to implement DAP-to-LDAP gateways).
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. Absolute True and False Filters
-
- Implementations of this extension SHALL allow 'and' and 'or' choices
- with zero filter elements.
-
- An 'and' filter consisting of an empty set of filters SHALL evaluate
- to True. This filter is represented by the string "(&)".
-
-
-
-Zeilenga LDAP True & False Filters [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- An 'or' filter consisting of an empty set of filters SHALL evaluate to
- False. This filter is represented by the string "(|)".
-
- Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674]
- attribute in the root DSE.
-
- Clients supporting this feature SHOULD NOT use the feature unless they
- have knowledge the server supports it.
-
-
-3. Security Considerations
-
- The (re)introduction of absolute True and False filters is not
- believed to raise any new security considerations.
-
- Implementors of this (or any) LDAPv3 extension should be familiar with
- general LDAPv3 security considerations [Roadmap].
-
-
-4. IANA Considerations
-
- Registration of this feature is requested [BCP64bis].
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.5.3
- Description: True/False filters
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in this
- specification.
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-6. References
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
- December 2003.
-
-
-6.2. Informative References
-
- [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol", RFC 1777, March 1995.
-
- [RFC1960] Howes, T., "A String Representation of LDAP Search
- Filters", RFC 1960, June 1996.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
-
-
-Zeilenga LDAP True & False Filters [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Zeilenga LDAP True & False Filters [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 6]
-\f
-
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 28 October 2005
-
-
-
- LDAP Turn Operation
- <draft-zeilenga-ldap-turn-03.txt>
-
-
-1. Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor for publication as an
- Experimental document. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF LDAP
- Extensions mailing list <ldapext@ietf.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-
-Zeilenga LDAP Turn Op [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) extended operation to reverse (or "turn") the roles of client
- and server for subsequent protocol exchanges in the session, or to
- enable each peer to act as both client and server with respect to the
- other.
-
-
-1. Background and Intent of Use
-
- The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol]
- is a client-server protocol which typically operates over reliable
- octet-stream transports such as the Transport Control Protocol (TCP).
- Generally, the client initiates the stream by connecting to the
- server's listener at some well-known address.
-
- There are cases where it is desirable for the server to initiate the
- stream. While it certainly is possible to write a technical
- specification detailing how to implement server-initiated LDAP
- sessions, this would require the design of new authentication and
- other security mechanisms to support server-initiated LDAP sessions.
-
- Instead, this document introduces an operation, the Turn operation,
- which may be used to reverse the client-servers roles of the protocol
- peers. This allows the initiating protocol peer to become server
- (after the reversal).
-
- As an additional feature, the Turn operation may be used to allow both
- peers to act in both roles. This is useful where both peers are
- directory servers that desire to request, as LDAP clients, operations
- be performed by the other. This may be useful in replicated and/or
- distributed environments.
-
- This operation is intended to be used between protocol peers which
- have established a mutual agreement, by means outside of the protocol,
- which requires reversal of client-server roles, or allows both peers
- to act both as client and server.
-
-
-1.1 Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
-
-2. Turn Operation
-
-
-
-
-Zeilenga LDAP Turn Op [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- The Turn operation is defined as a LDAP Extended Operation [Protocol,
- Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
- the Turn Operation is to request that the client-server roles be
- reversed, or, optionally to request that both protocol peers to be
- able to act both as client and server in respect to the other.
-
-
-2.1. Turn Request
-
- The Turn request is an ExtendedRequest with the requestName field
- containing the IANA-ASSIGNED-OID and a requestValue field is a
- BER-encoded turnValue:
-
- turnValue ::= SEQUENCE {
- mutual BOOLEAN DEFAULT FALSE,
- identifier LDAPString
- }
-
- A TRUE mutual field value indicates a request to allow both peers to
- act both as client and server. A FALSE mutual field value indicates a
- request to reserve the client and server roles.
-
- The value of the identifier field is a locally-defined policy
- identifier (typically associated with a mutual agreement for which
- this turn is be executed as part of).
-
-
-2.2. Turn Response
-
- A Turn response is an ExtendedResponse where the responseName and
- responseValue fields are absent. A resultCode of success is returned
- if and only if the responder is willing and able to turn the session
- as requested. Otherwise, a different resultCode is returned.
-
-
-3. Authentication
-
- This extension's authentication model assumes separate authentication
- of the peers in each of their roles. A separate Bind exchange is
- expected between the peers in their new roles to establish identities
- in these roles.
-
- Upon completion of the Turn, the responding peer in its new client
- role has an anonymous association at the initiating peer in its new
- server role. If the turn was mutual, the authentication association
- of the initiating peer in its pre-existing client role is left intact
- at the responding peer in its pre-existing server role. If the turn
- was not mutual, this association is void.
-
-
-
-Zeilenga LDAP Turn Op [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- The responding peer may establish its identity in its client role by
- requesting and successfully completing a Bind operation.
-
- The remainder of this section discuss some authentication scenarios.
- In the protocol exchange illustrations, A refers to the initiating
- peer (the original client) and B refers to the responding peer (the
- original server).
-
-3.1. Use with TLS and Simple Authentication
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- A->B: Bind(Simple(DN/Password)) Request
- B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS (Transport Layer Security) [TLS] is started and
- the initiating peer (the original client) establishes its identity
- with the responding peer prior to the Turn using the the DN/password
- mechanism of the Simple method of the Bind operation. After the turn,
- the responding peer in its new client role establishes its identity
- with the initiating peer in its new server role.
-
-
-3.2. Use with TLS and SASL EXTERNAL
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(SASL(EXTERNAL)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS is started prior with each peer providing a
- valid certificate and the initiating peer (the original client)
- establishes its identity through the use of the EXTERNAL mechanism of
- the SASL (Simple Authentication and Security Layer) [SASL] method of
- the Bind operation prior to the Turn. After the turn, the responding
- peer in its new client role establishes its identity with the
- initiating peer in its new server role.
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-3.3. Use of mutual authentication and SASL EXTERNAL
-
- A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5
- [DIGEST-MD5], support mutual authentication. The initiating peer, it
- its new server role, may use the identity of the responding peer
- established by a prior authentication exchange, as its source for
- "external" identity in subsequent EXTERNAL exchange.
-
- A->B: Bind(SASL(GSSAPI)) Request
- <intermediate messages>
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, a GSSAPI mutual-authentication exchange is completed
- between the initiating peer (the original client) and the the
- responding server (the original server) prior to the turn. After the
- turn, the responding peer in its new client role requests the
- initiating peer utilize an "external" identity to establish its LDAP
- authorization identity.
-
-
-4. TLS and SASL security layers
-
- As described in [Protocol], LDAP supports both Transport Layer
- Security (TLS) [TLS] and Simple Authentication and Security Layer
- (SASL) [SASL] security frameworks. The following table illustrates
- the relationship between the LDAP message layer, SASL layer, TLS
- layer, and transport connection within an LDAP session.
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
- This extension does not alter this relationship, nor does it remove
- the general restriction against multiple TLS layers, nor does it
- remove the general restriction against multiple SASL layers.
-
-
-
-Zeilenga LDAP Turn Op [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- As specified in [Protocol], the StartTLS operation is used to initiate
- negotiation of a TLS layer. If a TLS is already installed, the
- StartTLS operation must fail. Upon establishment of the TLS layer,
- regardless of which peer issued the request to start TLS, the peer
- which initiated the LDAP session (the original client) performs the
- "server identity check" as described in Section 3.1.5 of [AuthMeth]
- treating itself as the "client" and its peer as the "server".
-
- As specified in [SASL], newly negotiated SASL security layer replace
- the installed SASL security layer. Though the client/server roles in
- LDAP, and hence SASL, may be reversed in subsequent exchanges, only
- one SASL security layer may be installed at any instance.
-
-
-5. Security Considerations
-
- Implementors should be aware that the reversing of client/server roles
- and/or allowing both peers to act as client and server likely
- introduces security considerations not foreseen by the authors of this
- document. In particular, the security implications of the design
- choices made in the authentication and data security models for this
- extension (discussed in sections 3 and 4, respectively) are not fully
- studied. It is hoped that experimentation with this extension will
- lead to better understanding of the security implications of these
- models and other aspects of this extension, and that appropriate
- considerations will be documented in a future document. The following
- security considerations are apparent at this time.
-
- Implementors should take special care to process LDAP, SASL, TLS, and
- other events the appropriate roles for the peers. It is noted that
- while the Turn reverses the client/server roles with LDAP, and in SASL
- authentication exchanges, it does not reverse the roles within the TLS
- layer or the transport connection.
-
- The responding server (the original server) should restrict use of
- this operation to authorized clients. Client knowledge of a valid
- identifier should not be the sole factor in determining authorization
- to turn.
-
- Where the peers except to establish TLS, TLS should be started prior
- to the Turn and any request to authenticate via the Bind operation.
-
- LDAP security considerations [Protocol][AuthMeth] generally apply to
- this extension.
-
-
-6. IANA Considerations
-
-
-
-
-Zeilenga LDAP Turn Op [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- Registration of the following values [BCP64bis] is requested.
-
-
-6.1. Object Identifier
-
- It is requested that IANA assign an LDAP Object Identifier to identify
- the LDAP Turn Operation as defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Turn Operation
-
-
-6.2. LDAP Protocol Mechanism
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: LDAP Turn Operation
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Extended Operation
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments: none
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-8.1. Normative References
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
- [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
- 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
- progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(2002) (also ISO/IEC
- 8825-1:2002).
-
-
-8.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [GSSAPI] Linn, J., "Generic Security Service
- Application Program Interface, Version 2, Update 1", RFC
- 2743, January 2000.
-
- [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
- Authentication as a SASL Mechanism",
- draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 9]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 July 2005
-
-
-
- The LDAP entryUUID operational attribute
- <draft-zeilenga-ldap-uuid-06.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 1]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- This document describes the LDAP/X.500 'entryUUID' operational
- attribute and associated matching rules and syntax. The attribute
- holds a server-assigned Universally Unique Identifier (UUID) for the
- object. Directory clients may use this attribute to distinguish
- objects identified by a distinguished name or to locate an object
- after renaming.
-
-
-1. Background and Intended Use
-
- In X.500 Directory Services [X.501], such as those accessible using
- the Lightweight Directory Access Protocol (LDAP) [Roadmap], an object
- is identified by its distinguished name (DN). However, DNs are not
- stable identifiers. That is, a new object may be identified by a DN
- which previously identified another (now renamed or deleted) object.
-
- A Universally Unique Identifier (UUID) is "an identifier unique across
- both space and time, with respect to the space of all UUIDs"
- [UUIDURN]. UUIDs are used in a wide range of systems.
-
- This document describes the 'entryUUID' operational attribute which
- holds the UUID assigned to the object by the server. Clients may use
- this attribute to distinguish objects identified by a particular
- distinguished name or to locate a particular object after renaming.
-
- This document defines the UUID syntax, the 'uuidMatch' and
- 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
- type.
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. UUID Schema Elements
-
-2.1 UUID Syntax
-
- A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet
- (128-bit) value which identifies an object. The ASN.1 [X.680] type
- UUID is defined to represent UUIDs as follows:
-
- UUID ::= OCTET STRING (SIZE(16))
- -- constrained to an UUID [UUIDURN]
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 2]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- In LDAP, UUID values are encoded using the [ASCII] character string
- representation described in [UUIDURN]. For example,
- "597ae2f6-16a6-1027-98f4-d28b5365dc14".
-
- The following is a LDAP syntax description suitable for publication in
- subschema subentries.
-
- ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
-
-
-2.2 'uuidMatch' Matching Rule
-
- The 'uuidMatch' matching rule compares an asserted UUID with a stored
- UUID for equality. Its semantics are same as the 'octetStringMatch'
- [X.520][Syntaxes] matching rule. The rule differs from
- 'octetStringMatch' in that the assertion value is encoded using the
- UUID string representation instead of the normal OCTET STRING string
- representation.
-
- The following is a LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-2.3 'uuidOrderingMatch' Matching Rule
-
- The 'uuidOrderingMatch' matching rule compares an asserted UUID
- with a stored UUID for ordering. Its semantics are the same as the
- 'octetStringOrderingMatch' [X.520][Syntaxes] matching rule. The
- rule differs from 'octetStringOrderingMatch' in that the assertion
- value is encoded using the UUID string representation instead of
- the normal OCTET STRING string representation.
-
- The following is a LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
- It is noted that not all UUID variants have a defined ordering and,
- even where so, servers are not obligated to assign UUIDs in any
- particular order. This matching rule is provided for completeness.
-
-
-2.4. 'entryUUID' attribute
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- The 'entryUUID' operational attribute provides the Universally Unique
- Identifier (UUID) assigned to the entry.
-
- The following is a LDAP attribute type description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
- DESC 'UUID of the entry'
- EQUALITY uuidMatch
- ORDERING uuidOrderingMatch
- SYNTAX IANA-ASSIGNED-OID.1
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- Servers SHALL generate and assign a new UUID to each entry upon its
- addition to the directory and provide that UUID as the value of the
- 'entryUUID' operational attribute. An entry's UUID is immutable.
-
- UUID are to be generated in accordance with Section 4 of [UUIDURN].
- In particular, servers MUST ensure that each generated UUID is unique
- in space and time.
-
-
-3. Security Considerations
-
- An entry's relative distinguish name (RDN) is composed from attribute
- values of the entry, values which are commonly descriptive of the
- object the entry represents. While deployers are encouraged to use
- naming attributes whose values are widely disclosable [LDAPDN],
- entries are often named using information which cannot be disclosed to
- all parties. As UUIDs do not contain any descriptive information of
- the object they identify, UUIDs may be used to identify a particular
- entry without disclosure of its contents.
-
- General UUID security considerations [UUIDURN] apply.
-
- General LDAP security considerations [RFC3377] apply.
-
-
-4. IANA Considerations
-
- It is requested that IANA register upon Standards Action the LDAP
- values specified in this document.
-
-
-4.1. Object Identifier Registration
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 4]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID schema elements
-
-
-4.2. UUID Syntax Registration
-
- Subject: Request for LDAP Syntax Registration
- Object Identifier: IANA-ASSIGNED-OID.1
- Description: UUID
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID syntax
-
-
-4.3. 'uuidMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidMatch
- Object Identifier: IANA-ASSIGNED-OID.2
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Matching Rule
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-4.3. 'uuidOrderingMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidOrderingMatch
- Object Identifier: IANA-ASSIGNED-OID.3
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Matching Rule
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-5.4. 'entryUUID' Descriptor Registration
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 5]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- It is requested that IANA register upon Standards Action the LDAP
- 'entryUUID' descriptor.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): entryUUID
- Object Identifier: IANA-ASSIGNED-OID.4
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-6. Acknowledgments
-
- This document is based upon discussions in the LDAP Update and
- Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
- provided review.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace",
- a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.520] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Attribute Types", X.520(1993) (also
- ISO/IEC 9594-6:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-8.2. Informative References
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
-\f
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 July 2005
-Obsoletes: RFC 2252, RFC 2256, RFC 2587
-
-
- Lightweight Directory Access Protocol (LDAP) schema
- definitions for X.509 Certificates
- <draft-zeilenga-ldap-x509-02.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- This document is intended to be published in conjunction to the
- revised LDAP TS [Roadmap]. Together, this document and the revised
- LDAP TS obsoletes RFC 2252 and RFC 2256 in their entirety.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 1]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- for more information.
-
-
-Abstract
-
- This document describes schema for representing X.509 certificates,
- X.521 security information, and related elements in directories
- accessible using the Lightweight Directory Access Protocol (LDAP).
- The LDAP definitions for these X.509 and X.521 schema elements
- replaces those provided in RFC 2252 and RFC 2256.
-
-
-1. Background and Intended Use
-
- This document provides LDAP [Roadmap] schema definitions [Models] for
- a subset of elements specified in X.509 [X.509] and X.521 [X.521],
- including attribute types for certificates, cross certificate pairs,
- and certificate revocation lists; matching rules to be used with these
- attribute types; and related object classes. LDAP syntax definitions
- are also provided for associated assertion and attribute values.
-
- As the semantics of these elements are as defined in X.509 and X.521,
- knowledge of X.509 and X.521 is necessary to make use of the LDAP
- schema definitions provided herein.
-
- This document, together with [Roadmap], obsoletes RFC 2252 and RFC
- 2256 in their entirety. The changes (in this document) made since RFC
- 2252 and RFC 2256 include:
- - addition of pkiUser, pkiCA, and deltaCRL classes;
- - update of attribute types to include equality matching rules in
- accordance with their X.500 specifications;
- - addition of certificate, certificate pair, certificate list, and
- algorithm identifer matching rules; and
- - addition of LDAP syntax for assertion syntaxes for these matching
- rules.
-
- This document obsoletes RFC 2587. The X.509 schema descriptions for
- LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 2]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-2. Syntaxes
-
- This section describes various syntaxes used in LDAP to transfer
- certificates and related data types.
-
-
-2.1. Certificate
-
- ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
-
- A value of this syntax is an X.509 Certificate [X.509, clause 7].
-
- Due to changes made to the definition of a Certificate made through
- time, no LDAP-specific encoding is defined for this syntax. Values of
- this syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
- [X.690] and MUST only be transferred using the ;binary transfer option
- [Binary]. That is, by requesting and returning values using attribute
- descriptions such as "userCertificate;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.2. CertificateList
-
- ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
-
- A value of this syntax is an X.509 CertificateList [X.509, clause
- 7.3].
-
- Due to changes made to the definition of a CertificateList made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [Binary]. That
- is, by requesting and returning values using attribute descriptions
- such as "certificateRevocationList;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.3. CertificatePair
-
- ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
-
- A value of this syntax is an X.509 CertificatePair [X.509, clause
- 11.2.3].
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 3]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- Due to changes made to the definition of an X.509 CertificatePair made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [Binary]. That
- is, by requesting and returning values using attribute descriptions
- such as "crossCertificatePair;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-2.4 SupportedAlgorithm
-
- ( 1.3.6.1.4.1.1466.115.121.1.49
- DESC 'X.509 Supported Algorithm' )
-
- A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
- 11.2.7].
-
- Due to changes made to the definition of an X.509 SupportedAlgorithm
- made through time, no LDAP-specific encoding is defined for this
- syntax. Values of this syntax SHOULD be encoded using DER [X.690] and
- MUST only be transferred using the ;binary transfer option [Binary].
- That is, by requesting and returning values using attribute
- descriptions such as "supportedAlgorithms;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.5. CertificateExactAssertion
-
- ( IANA-ASSIGNED-OID.1 DESC 'X.509 Certificate Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateExactAssertion [X.509,
- clause 11.3.1]. Values of this syntax MUST be encoded using the
- Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 provides
- an equivalent Augmented Backus-Naur Form (ABNF) [ABNF] grammar for
- this syntax.
-
-
-2.6. CertificateAssertion
-
- ( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' )
-
- A value of this syntax is an X.509 CertificateAssertion [X.509, clause
- 11.3.2]. Values of this syntax MUST be encoded using GSER [RFC3641].
- Appendix A.2 provides an equivalent ABNF [ABNF] grammar for this
- syntax.
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 4]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-2.7. CertificatePairExactAssertion
-
- ( IANA-ASSIGNED-OID.3
- DESC 'X.509 Certificate Pair Exact Assertion' )
-
- A value of this syntax is an X.509 CertificatePairExactAssertion
- [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [ABNF]
- grammar for this syntax.
-
-
-2.8. CertificatePairAssertion
-
- ( IANA-ASSIGNED-OID.4 DESC 'X.509 Certificate Pair Assertion' )
-
- A value of this syntax is an X.509 CertificatePairAssertion [X.509,
- clause 11.3.4]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.4 provides an equivalent ABNF [ABNF] grammar
- for this syntax.
-
-
-2.9. CertificateListExactAssertion
-
- ( IANA-ASSIGNED-OID.5
- DESC 'X.509 Certificate List Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateListExactAssertion
- [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
- this syntax.
-
-
-2.10. CertificateListAssertion
-
- ( IANA-ASSIGNED-OID.6 DESC 'X.509 Certificate List Assertion' )
-
- A value of this syntax is an X.509 CertificateListAssertion [X.509,
- clause 11.3.6]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.6 provides an equivalent ABNF [ABNF] grammar
- for this syntax.
-
-
-2.11 AlgorithmIdentifier
-
- ( IANA-ASSIGNED-OID.7 DESC 'X.509 Algorithm Identifier' )
-
- A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
- 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 5]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- Appendix A.7 provides an equivalent ABNF [ABNF] grammar for this
- syntax.
-
-
-3. Matching Rules
-
- This section introduces a set of certificate and related matching
- rules for use in LDAP. These rules are intended to act in accordance
- with their X.500 counterparts.
-
-
-3.1. certificateExactMatch
-
- The certificateExactMatch matching rule compares the presented
- certificate exact assertion value with an attribute value of the
- certificate syntax as described in clause 11.3.1 of [X.509].
-
- ( 2.5.13.34 NAME 'certificateExactMatch'
- DESC 'X.509 Certificate Exact Match'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-3.2. certificateMatch
-
- The certificateMatch matching rule compares the presented certificate
- assertion value with an attribute value of the certificate syntax as
- described in clause 11.3.2 of [X.509].
-
- ( 2.5.13.35 NAME 'certificateMatch'
- DESC 'X.509 Certificate Match'
- SYNTAX IANA-ASSIGNED-OID.2 )
-
-
-3.3. certificatePairExactMatch
-
- The certificatePairExactMatch matching rule compares the presented
- certificate pair exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.3 of [X.509].
-
- ( 2.5.13.36 NAME 'certificatePairExactMatch'
- DESC 'X.509 Certificate Pair Exact Match'
- SYNTAX IANA-ASSIGNED-OID.3 )
-
-
-3.4. certificatePairMatch
-
- The certificatePairMatch matching rule compares the presented
- certificate pair assertion value with an attribute value of the
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 6]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- certificate pair syntax as described in clause 11.3.4 of [X.509].
-
- ( 2.5.13.37 NAME 'certificatePairMatch'
- DESC 'X.509 Certificate Pair Match'
- SYNTAX IANA-ASSIGNED-OID.4 )
-
-
-3.5. certificateListExactMatch
-
- The certificateListExactMatch matching rule compares the presented
- certificate list exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.5 of [X.509].
-
- ( 2.5.13.38 NAME 'certificateListExactMatch'
- DESC 'X.509 Certificate List Exact Match'
- SYNTAX IANA-ASSIGNED-OID.5 )
-
-
-3.6. certificateListMatch
-
- The certificateListMatch matching rule compares the presented
- certificate list assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.6 of [X.509].
-
- ( 2.5.13.39 NAME 'certificateListMatch'
- DESC 'X.509 Certificate List Match'
- SYNTAX IANA-ASSIGNED-OID.6 )
-
-
-3.7. algorithmIdentifierMatch
-
- The algorithmIdentifierMatch mating rule compares a presented
- algorithm identifier with an attribute value of supported algorithm as
- described in clause 11.3.7 of [X.509].
-
- ( 2.5.13.40 NAME 'algorithmIdentifier'
- DESC 'X.509 Algorithm Identifier Match'
- SYNTAX IANA-ASSIGNED-OID.7 )
-
-
-4. Attribute Types
-
- This section details a set of certificate and related attribute types
- for use in LDAP.
-
-
-4.1. userCertificate
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 7]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- The userCertificate attribute holds the X.509 certificates issued to
- the user by one or more certificate authorities, as discussed in
- clause 11.2.1 of [X.509].
-
- ( 2.5.4.36 NAME 'userCertificate'
- DESC 'X.509 user certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "userCertificate;binary".
-
-
-4.2. cACertificate
-
- The cACertificate attribute holds the X.509 certificates issued to the
- certificate authority (CA), as discussed in clause 11.2.2 of [X.509].
-
- ( 2.5.4.37 NAME 'cACertificate'
- DESC 'X.509 CA certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "cACertificate;binary".
-
-
-4.3. crossCertificatePair
-
- The crossCertificatePair attribute holds an X.509 certificate pair, as
- discussed in clause 11.2.3 of [X.509].
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- DESC 'X.509 cross certificate pair'
- EQUALITY certificatePairExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "crossCertificatePair;binary".
-
-
-4.4. certificateRevocationList
-
- The certificateRevocationList attribute holds certificate lists, as
- discussed in 11.2.4 of [X.509].
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 8]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- ( 2.5.4.39 NAME 'certificateRevocationList'
- DESC 'X.509 certificate revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "certificateRevocationList;binary".
-
-
-4.5. authorityRevocationList
-
- The authorityRevocationList attribute holds certificate lists, as
- discussed in 11.2.5 of [X.509].
-
- ( 2.5.4.38 NAME 'authorityRevocationList'
- DESC 'X.509 authority revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "authorityRevocationList;binary".
-
-
-4.6. deltaRevocationList
-
- The deltaRevocationList attribute holds certificate lists, as
- discussed in 11.2.6 of [X.509].
-
- ( 2.5.4.53 NAME 'deltaRevocationList'
- DESC 'X.509 delta revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "deltaRevocationList;binary".
-
-
-4.7. supportedAlgorithms
-
- The supportedAlgorithms attribute holds supported algorithms, as
- discussed in 11.2.7 of [X.509].
-
- ( 2.5.4.52 NAME 'supportedAlgorithms'
- DESC 'X.509 supported algorithms'
- EQUALITY algorithmIdentifierMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 9]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "supportedAlgorithms;binary".
-
-
-5. Object Classes
-
- This section details a set of certificate-related object classes for
- use in LDAP.
-
-
-5.1. pkiUser
-
- This object class is used in augment entries for objects that may be
- subject to certificates, as defined in clause 11.1.1 of [X.509].
-
- ( 2.5.6.21 NAME 'pkiUser'
- DESC 'X.509 PKI User'
- SUP top AUXILIARY
- MAY userCertificate )
-
-
-5.2. pkiCA
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 11.1.2 of [X.509]
-
- ( 2.5.6.22 NAME 'pkiCA'
- DESC 'X.509 PKI Certificate Authority'
- SUP top AUXILIARY
- MAY ( cACertificate $ certificateRevocationList $
- authorityRevocationList $ crossCertificatePair ) )
-
-
-5.3. cRLDistributionPoint
-
- This class is used to represent objects which act as CRL distribution
- points, as discussed in clause 11.1.3 of [X.509].
-
- ( 2.5.6.19 NAME 'cRLDistributionPoint'
- DESC 'X.509 CRL distribution point'
- SUP top STRUCTURAL
- MUST cn
- MAY ( certificateRevocationList $
- authorityRevocationList $ deltaRevocationList ) )
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 10]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-5.4 deltaCRL
-
- The deltaCRL object class is used to augment entries to hold delta
- revocation lists, as discussed in clause 11.1.4 of [X.509].
-
- ( 2.5.6.23 NAME 'deltaCRL'
- DESC 'X.509 delta CRL'
- SUP top AUXILIARY
- MAY deltaRevocationList )
-
-
-5.5. strongAuthenticationUser
-
- This object class is used to augment entries for objects participating
- in certificate-based authentication, as defined in clause 6.15 of
- [X.521]. This object class is deprecated in favor of pkiUser.
-
- ( 2.5.6.15 NAME 'strongAuthenticationUser'
- DESC 'X.521 strong authentication user'
- SUP top AUXILIARY
- MUST userCertificate )
-
-
-5.6. userSecurityInformation
-
- This object class is used to augment entries with needed additional
- associated security information, as defined in clause 6.16 of [X.521].
-
- ( 2.5.6.18 NAME 'userSecurityInformation'
- DESC 'X.521 user security information'
- SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-
-5.7. certificationAuthority
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 6.17 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16 NAME 'certificationAuthority'
- DESC 'X.509 certificate authority'
- SUP top AUXILIARY
- MUST ( authorityRevocationList $
- certificateRevocationList $ cACertificate )
- MAY crossCertificatePair )
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 11]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-5.8. certificationAuthority-V2
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 6.18 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
- DESC 'X.509 certificate authority, version 2'
- SUP certificationAuthority AUXILIARY
- MAY deltaRevocationList )
-
-
-6. Security Considerations
-
- General certificate considerations [RFC3280] apply to LDAP-aware
- certificate applications. General LDAP security considerations
- [Roadmap] apply as well.
-
- While elements of certificate information are commonly signed, these
- signatures only protect the integrity of the signed information. In
- the absence of a data integrity protections in LDAP (or lower layer,
- e.g. IPsec), a server is not assured that client certificate request
- (or other request) was unaltered in transit. Likewise, a client
- cannot be assured that the results of the query were unaltered in
- transit. Hence, it is generally recommended implementations make use
- of authentication and data integrity services in LDAP
- [AuthMeth][Protocol].
-
-
-7. IANA Considerations
-
-7.1. Object Identifier Registration
-
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier for use in this technical specification.
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP X.509 Certificate schema elements
- introduced in this document.
-
-
-7.2. Registration of the descriptor
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 12]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- It is requested that IANA update upon Standards Action the LDAP
- Descriptor registry as indicated below.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): see table
- Object Identifier: see table
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see table
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
- algorithmIdentifierMatch R 2.5.13.40
- authorityRevocationList A 2.5.4.38 *
- cACertificate A 2.5.4.37 *
- cRLDistributionPoint O 2.5.6.19 *
- certificateExactMatch R 2.5.13.34
- certificateListExactMatch R 2.5.13.38
- certificateListMatch R 2.5.13.39
- certificateMatch R 2.5.13.35
- certificatePairExactMatch R 2.5.13.36
- certificatePairMatch R 2.5.13.37
- certificateRevocationList A 2.5.4.39 *
- certificationAuthority O 2.5.6.16 *
- certificationAuthority-V2 O 2.5.6.16.2 *
- crossCertificatePair A 2.5.4.40 *
- deltaCRL O 2.5.6.23 *
- deltaRevocationList A 2.5.4.53 *
- pkiCA O 2.5.6.22 *
- pkiUser O 2.5.6.21 *
- strongAuthenticationUser O 2.5.6.15 *
- supportedAlgorithms A 2.5.4.52 *
- userCertificate A 2.5.4.36 *
- userSecurityInformation O 2.5.6.18 *
-
- * Updates previous registration
-
-
-8. Acknowledgments
-
- This document is based upon X.509, a product of the ITU-T. A number
- of LDAP schema definitions were based on those found in RFC 2252 and
- RFC 2256, both products of the IETF ASID WG. The ABNF productions in
- Appendix A were provided by Steven Legg. Additional material was
- borrowed from prior works by David Chadwick and Steven Legg to refine
- the LDAP X.509 schema.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 13]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-9. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-10. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1
- Types", RFC 3641, October 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Binary] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- The Binary Encoding Option",
- draft-legg-ldap-binary-xx.txt, a work in progress.
-
- [X.509] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Authentication Framework", X.509(2000).
-
- [X.521] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Object Classes", X.521(2000).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 14]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(2002) (also ISO/IEC
- 8825-1:2002).
-
-
-11.2. Informative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
- work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
- Mapping between X.400 and RFC 822/MIME", RFC 2156,
- January 1998.
-
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and
- Certificate Revocation List (CRL) Profile", RFC 3280,
- April 2002.
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-
- [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642,
- October 2003.
-
- [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP)
- and X.500 Component Matching Rules", RFC 3687, February
- 2004.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-Appendix A.
-
- This appendix is informative.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 15]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- This appendix provides ABNF [ABNF] grammars for GSER-based [RFC3687]
- LDAP-specific encodings specified in this document. These grammars
- where produced using, and relying on, Common Elements for GSER
- Encodings [RFC3342].
-
-
-A.1. CertificateExactAssertion
-
- CertificateExactAssertion = "{" sp cea-serialNumber ","
- sp cea-issuer sp "}"
-
- cea-serialNumber = id-serialNumber msp CertificateSerialNumber
- cea-issuer = id-issuer msp Name
-
- id-serialNumber =
- %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
- id-issuer = %x69.73.73.75.65.72 ; 'issuer'
-
- Name = id-rdnSequence ":" RDNSequence
- id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
-
- CertificateSerialNumber = INTEGER
-
-
-A.2. CertificateAssertion
-
- CertificateAssertion = "{" [ sp ca-serialNumber ]
- [ sep sp ca-issuer ]
- [ sep sp ca-subjectKeyIdentifier ]
- [ sep sp ca-authorityKeyIdentifier ]
- [ sep sp ca-certificateValid ]
- [ sep sp ca-privateKeyValid ]
- [ sep sp ca-subjectPublicKeyAlgID ]
- [ sep sp ca-keyUsage ]
- [ sep sp ca-subjectAltName ]
- [ sep sp ca-policy ]
- [ sep sp ca-pathToName ]
- [ sep sp ca-subject ]
- [ sep sp ca-nameConstraints ] sp "}"
-
- ca-serialNumber = id-serialNumber msp CertificateSerialNumber
- ca-issuer = id-issuer msp Name
- ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
- SubjectKeyIdentifier
- ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
- ca-certificateValid = certificateValid msp Time
- ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 16]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
- OBJECT-IDENTIFIER
- ca-keyUsage = id-keyUsage msp KeyUsage
- ca-subjectAltName = id-subjectAltName msp AltNameType
- ca-policy = id-policy msp CertPolicySet
- ca-pathToName = id-pathToName msp Name
- ca-subject = id-subject msp Name
- ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
-
- id-subjectKeyIdentifier =
- %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'subjectKeyIdentifier'
- id-authorityKeyIdentifier =
- %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'authorityKeyIdentifier'
- id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
- ; 'certificateValid'
- id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
- ; 'privateKeyValid'
- id-subjectPublicKeyAlgID =
- %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
- ; 'subjectPublicKeyAlgID'
- id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
- id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
- ; 'subjectAltName'
- id-policy = %x70.6F.6C.69.63.79 ; 'policy'
- id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
- id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
- id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
- ; 'nameConstraints'
-
- SubjectKeyIdentifier = KeyIdentifier
-
- KeyIdentifier = OCTET-STRING
-
- AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
- [ sep sp aki-authorityCertIssuer ]
- [ sep sp aki-authorityCertSerialNumber ] sp "}"
-
- aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
- aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
-
- GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
- GeneralName = gn-otherName
- / gn-rfc822Name
- / gn-dNSName
- / gn-x400Address
- / gn-directoryName
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 17]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- / gn-ediPartyName
- / gn-uniformResourceIdentifier
- / gn-iPAddress
- / gn-registeredID
-
- gn-otherName = id-otherName ":" OtherName
- gn-rfc822Name = id-rfc822Name ":" IA5String
- gn-dNSName = id-dNSName ":" IA5String
- gn-x400Address = id-x400Address ":" ORAddress
- gn-directoryName = id-directoryName ":" Name
- gn-ediPartyName = id-ediPartyName ":" EDIPartyName
- gn-iPAddress = id-iPAddress ":" OCTET-STRING
- gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
-
- gn-uniformResourceIdentifier = id-uniformResourceIdentifier
- ":" IA5String
-
- id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
- gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
- ; 'registeredID'
-
- OtherName = "{" sp on-type-id "," sp on-value sp "}"
- on-type-id = id-type-id msp OBJECT-IDENTIFIER
- on-value = id-value msp Value
- ;; <Value> as defined in Section 8 of [RFC3786]
-
- id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
- id-value = %x76.61.6C.75.65 ; 'value'
-
- ORAddress = dquote *SafeIA5Character dquote
- SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
- dquote dquote ; escaped double quote
- dquote = %x22 ; '"' (double quote)
-
- ;; Note: The <ORAddress> rule encodes the x400Address component
- ;; of a GeneralName as a character string between double quotes.
- ;; The character string is first derived according to Section 4.1
- ;; of [RFC2156], and then any embedded double quotes are escaped
- ;; by being repeated. This resulting string is output between
- ;; double quotes.
-
- EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
- nameAssigner = id-nameAssigner msp DirectoryString
- partyName = id-partyName msp DirectoryString
- id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
- ; 'nameAssigner'
- id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 18]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- aki-authorityCertSerialNumber = id-authorityCertSerialNumber
- msp CertificateSerialNumber
-
- id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'keyIdentifier'
- id-authorityCertIssuer =
- %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
- ; 'authorityCertIssuer'
-
- id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
- %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
- ; 'authorityCertSerialNumber'
-
- Time = time-utcTime / time-generalizedTime
- time-utcTime = id-utcTime ":" UTCTime
- time-generalizedTime = id-generalizedTime ":" GeneralizedTime
- id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
- id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
- ; 'generalizedTime'
-
- KeyUsage = BIT-STRING / key-usage-bit-list
- key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
-
- ;; Note: The <key-usage-bit-list> rule encodes the one bits in
- ;; a KeyUsage value as a comma separated list of identifiers.
-
- key-usage = id-digitalSignature
- / id-nonRepudiation
- / id-keyEncipherment
- / id-dataEncipherment
- / id-keyAgreement
- / id-keyCertSign
- / id-cRLSign
- / id-encipherOnly
- / id-decipherOnly
-
- id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
- %x75.72.65 ; 'digitalSignature'
- id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
- ; 'nonRepudiation'
- id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
- ; 'keyEncipherment'
- id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
- %x74 ; "dataEncipherment'
- id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
- ; 'keyAgreement'
- id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
- ; 'keyCertSign'
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 19]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
- id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
- ; 'encipherOnly'
- id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
- ; 'decipherOnly'
-
- AltNameType = ant-builtinNameForm / ant-otherNameForm
-
- ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
- ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
-
- id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
- ; 'builtinNameForm'
- id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
- ; 'otherNameForm'
-
- BuiltinNameForm = id-rfc822Name
- / id-dNSName
- / id-x400Address
- / id-directoryName
- / id-ediPartyName
- / id-uniformResourceIdentifier
- / id-iPAddress
- / id-registeredId
-
- id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
- id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
- id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
- id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
- ; 'directoryName'
- id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
- ; 'ediPartyName'
- id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
- id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
- ; 'registeredId'
-
- id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
- %x72.63.65.49.64.65.6E.74.69.66.69.65.72
- ; 'uniformResourceIdentifier'
-
- CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
- CertPolicyId = OBJECT-IDENTIFIER
-
- NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
- [ sep sp ncs-excludedSubtrees ] sp "}"
-
- ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
- ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 20]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- id-permittedSubtrees =
- %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
- ; 'permittedSubtrees'
- id-excludedSubtrees =
- %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
- ; 'excludedSubtrees'
-
- GeneralSubtrees = "{" sp GeneralSubtree
- *( "," sp GeneralSubtree ) sp "}"
- GeneralSubtree = "{" sp gs-base
- [ "," sp gs-minimum ]
- [ "," sp gs-maximum ] sp "}"
-
- gs-base = id-base msp GeneralName
- gs-minimum = id-minimum msp BaseDistance
- gs-maximum = id-maximum msp BaseDistance
-
- id-base = %x62.61.73.65 ; 'base'
- id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
- id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
-
- BaseDistance = INTEGER-0-MAX
-
-
-A.3. CertificatePairExactAssertion
-
- CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
- [sep sp cpea-issuedBy ] sp "}"
- ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
-
- cpea-issuedTo = id-issuedToThisCAAssertion msp
- CertificateExactAssertion
- cpea-issuedBy = id-issuedByThisCAAssertion msp
- CertificateExactAssertion
-
- id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
- id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
-
-
-A.4. CertificatePairAssertion
-
- CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
- [sep sp cpa-issuedBy ] sp "}"
- ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
-
- cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 21]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
-
-
-A.5. CertificateListExactAssertion
-
- CertificateListExactAssertion = "{" sp clea-issuer ","
- sp clea-thisUpdate
- [ "," sp clea-distributionPoint ] sp "}"
-
- clea-issuer = id-issuer msp Name
- clea-thisUpdate = id-thisUpdate msp Time
- clea-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
- id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
- id-distributionPoint =
- %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
- ; 'distributionPoint'
-
- DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
-
- dpn-fullName = id-fullName ":" GeneralNames
- dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
- RelativeDistinguishedName
-
- id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
- id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
- %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
-
-
-A.6. CertificateListAssertion
-
- CertificateListAssertion = "{" [ sp cla-issuer ]
- [ sep sp cla-minCRLNumber ]
- [ sep sp cla-maxCRLNumber ]
- [ sep sp cla-reasonFlags ]
- [ sep sp cla-dateAndTime ]
- [ sep sp cla-distributionPoint ]
- [ sep sp cla-authorityKeyIdentifier ] sp "}"
-
- cla-issuer = id-issuer msp Name
- cla-minCRLNumber = id-minCRLNumber msp CRLNumber
- cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
- cla-reasonFlags = id-reasonFlags msp ReasonFlags
- cla-dateAndTime = id-dateAndTime msp Time
-
- cla-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 22]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
-
- id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
- ; 'minCRLNumber'
- id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
- ; 'maxCRLNumber'
- id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
- id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
-
- CRLNumber = INTEGER-0-MAX
-
- ReasonFlags = BIT-STRING
- / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
-
- reason-flag = id-unused
- / id-keyCompromise
- / id-cACompromise
- / id-affiliationChanged
- / id-superseded
- / id-cessationOfOperation
- / id-certificateHold
- / id-privilegeWithdrawn
- / id-aACompromise
-
- id-unused = %x75.6E.75.73.65.64 ; 'unused'
- id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'keyCompromise'
- id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'cACompromise'
- id-affiliationChanged =
- %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
- ; 'affiliationChanged'
- id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
- id-cessationOfOperation =
- %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
- ; 'cessationOfOperation'
- id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
- ; 'certificateHold'
- id-privilegeWithdrawn =
- %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
- ; 'privilegeWithdrawn'
- id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'aACompromise'
-
-
-A.7. AlgorithmIdentifier
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 23]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- AlgorithmIdentifier = "{" sp ai-algorithm
- [ "," sp ai-parameters ] sp "}"
-
- ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
- ai-parameters = id-parameters msp Value
- id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
- id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 24]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 25]
-\f
+++ /dev/null
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months Jong Hyuk Choi
- IBM Corporation
-
- 3 February 2004
-
-
-
-
- The LDAP Content Synchronization Operation
- <draft-zeilenga-ldup-sync-05.txt>
-
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDUP Working Group mailing list
- at <ietf-ldup@imc.org>. Please send editorial comments directly to
- the document editor at <Kurt@OpenLDAP.org>.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-Abstract
-
- This specification describes the LDAP (Lightweight Directory Access
- Protocol) Content Synchronization Operation. The operation allows a
- client to maintain a copy of a fragment of directory information tree.
- It supports both polling for changes and listening for changes. The
- operation is defined as an extension of the LDAP Search Operation.
-
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Introduction 3
- 1.1. Background
- 1.2. Intended Usage 4
- 1.3. Overview 5
- 1.4. Conventions
- 2. Elements of the Sync Operation 8
- 2.1. Common ASN.1 Elements 9
- 2.2. Sync Request Control
- 2.3. Sync State Control
- 2.4. Sync Done Control 10
- 2.5. Sync Info Message
- 2.6. Sync Result Codes 11
- 3. Content Synchronization
- 3.1. Synchronization Session
- 3.2. Content Determination 12
- 3.3. refreshOnly Mode 13
- 3.4. refreshAndPersist Mode 16
- 3.5. Search Request Parameters 17
- 3.6. objectName Issues 18
- 3.7. Canceling the Sync Operation 19
- 3.8. Refresh Required
- 3.9. Chattiness Considerations 20
- 3.10. Operation Multiplexing 21
- 4. Meta Information Considerations 22
- 4.1. Entry DN
- 4.2. Operational Attributes
- 4.3. Collective Attributes 23
- 4.4. Access and Other Administrative Controls
- 5. Interaction with Other Controls
- 5.1. ManageDsaIT Control 24
- 5.2. Subentries Control
- 6. Shadowing Considerations
- 7. Security Considerations 25
- 8. IANA Considerations
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- 8.1. Object Identifier 26
- 8.2. LDAP Protocol Mechanism
- 8.3. LDAP Result Codes
- 9. Acknowledgments
- 10. Normative References 27
- 11. Informative References 28
- 12. Authors' Addresses 29
- Appendix A. CSN-based Implementation Considerations
- Intellectual Property Rights 31
- Full Copyright
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
- mechanism, the search operation [RFC2251], which allows a client to
- request directory content matching a complex set of assertions and for
- the server to return this content, subject to access control and other
- restrictions, to the client. However, LDAP does not provide (despite
- the introduction of numerous extensions in this area) an effective and
- efficient mechanism for maintaining synchronized copies of directory
- content. This document introduces a new mechanism specifically
- designed to met the content synchronization requirements of
- sophisticated directory applications.
-
- This document defines the LDAP Content Synchronization Operation, or
- Sync Operation for short, which allows a client to maintain a
- synchronized copy of a fragment of a Directory Information Tree (DIT).
- The Sync Operation is defined as a set of controls and other protocol
- elements which extend the Search Operation.
-
-
-1.1. Background
-
- Over the years, a number of content synchronization approaches have
- been suggested for use in LDAP directory services. These approaches
- are inadequate for one or more of the following reasons:
-
- - fail to ensure a reasonable level of convergence;
- - fail to detect that convergence cannot be achieved (without
- reload);
- - require pre-arranged synchronization agreements;
- - require the server to maintain histories of past changes to DIT
- content and/or meta information;
- - require the server to maintain synchronization state on a per
- client basis; and/or
- - are overly chatty.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Operation provides eventual convergence of synchronized
- content when possible and, when not, notification that a full reload
- is required.
-
- The Sync Operation does not require pre-arranged synchronization
- agreements.
-
- The Sync Operation does not require servers to maintain nor to use any
- history of past changes to the DIT or to meta information. However,
- servers may maintain and use histories (e.g., change logs, tombstones,
- DIT snapshots) to reduce the number of messages generated and to
- reduce their size. As it is not always feasible to maintain and use
- histories, the operation may be implemented using purely (current)
- state-based approaches. The Sync Operation allows use of either the
- state-based approach or the history-based approach in an operation by
- operation basis to balance the size of history and the amount of
- traffic. The Sync Operation also allows the combined use of the
- state-based and the history-based approaches.
-
- The Sync Operation does not require servers to maintain
- synchronization state on a per client basis. However, servers may
- maintain and use per client state information to reduce the number of
- messages generated and the size of such messages.
-
- A synchronization mechanism can be considered overly chatty when
- synchronization traffic is not reasonably bounded. The Sync Operation
- traffic is bounded by the size of updated (or new) entries and the
- number of unchanged entries in the content. The operation is designed
- to avoid full content exchanges even in the case that the history
- information available to the server is insufficient to determine the
- client's state. The operation is also designed to avoid transmission
- of out-of-content history information, as its size is not bounded by
- the content and it is not always feasible to transmit such history
- information due to security reasons.
-
- This document includes a number of non-normative appendices providing
- additional information to server implementors.
-
-
-1.2. Intended Usage
-
- The Sync Operation is intended to be used in applications requiring
- eventually-convergent content synchronization. Upon completion of
- each synchronization stage of the operation, all information to
- construct a synchronized client copy of the content has been provided
- to the client or the client has been notified that a complete content
- reload is necessary. Except for transient inconsistencies due to
- concurrent operation (or other) processing at the server, the client
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- copy is an accurate reflection of the content held by the server.
- Transient inconsistencies will be resolved by subsequent
- synchronization operations.
-
- Possible uses include:
- - White page service applications may use the Sync Operation to
- maintain current copy of a DIT fragment. For example, a mail user
- agent which uses the sync operation to maintain a local copy of an
- enterprise address book.
-
- - Meta-information engines may use the Sync Operation to maintain a
- copy of a DIT fragment.
-
- - Caching proxy services may use the Sync Operation to maintain a
- coherent content cache.
-
- - Lightweight master-slave replication between heterogeneous
- directory servers. For example, the Sync Operation can be used by
- a slave server to maintain a shadow copy of a DIT fragment.
- (Note: The International Telephone Union (ITU) has defined the
- X.500 Directory [X.500] Information Shadowing Protocol (DISP)
- [X.525] which may be used for master-slave replication between
- directory servers. Other experimental LDAP replication protocols
- also exist.)
-
- This protocol is not intended to be used in applications requiring
- transactional data consistency.
-
- As this protocol transfers all visible values of entries belonging to
- the content upon change instead of change deltas, this protocol is not
- appropriate for bandwidth-challenged applications or deployments.
-
-
-1.3. Overview
-
- This section provides an overview of basic ways the Sync Operation can
- be used to maintain a synchronized client copy of a DIT fragment.
-
- - Polling for Changes: refreshOnly mode
- - Listening for Changes: refreshAndPersist mode
-
-
-1.3.1. Polling for Changes (refreshOnly)
-
- To obtain its initial client copy, the client issues a Sync request: a
- search request with the Sync Request Control with mode set to
- refreshOnly. The server, much like it would with a normal search
- operation, returns (subject to access controls and other restrictions)
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- the content matching the search criteria (baseObject, scope, filter,
- attributes). Additionally, with each entry returned, the server
- provides a Sync State Control indicating state add. This control
- contains the Universally Unique Identifier (UUID) [UUID] of the entry
- [EntryUUID]. Unlike the Distinguished Name (DN), which may change
- over time, an entry's UUID is stable. The initial content is followed
- by a SearchResultDone with a Sync Done Control. The Sync Done Control
- provides a syncCookie. The syncCookie represents session state.
-
- To poll for updates to the client copy, the client reissues the Sync
- Operation with the syncCookie previously returned. The server, much
- as it would with a normal search operation, determines which content
- would be returned as if the operation was a normal search operation.
- However, using the syncCookie as an indicator of what content the
- client was sent previously, the server sends copies of entries which
- have changed with a Sync State Control indicating state add. For each
- changed entry, all (modified or unmodified) attributes belonging to
- the content are sent.
-
- The server may perform either or both of the two distinct
- synchronization phases which are distinguished by how to synchronize
- entries deleted from the content: the present and the delete phases.
- When the server uses a single phase for the refresh stage, each phase
- is marked as ended by a SearchResultDone with a Sync Done Control. A
- present phase is identified by a FALSE refreshDeletes value in the
- Sync Done Control. A delete phase is identified by a TRUE
- refreshDeletes value. The present phase may be followed by a delete
- phase. The two phases are delimited by a refreshPresent Sync Info
- Message having a FALSE refreshDone value. In the case that both the
- phases are used, the present phase is used to bring the client copy up
- to the state at which the subsequent delete phase can begin.
-
- In the present phase, the server sends an empty entry (i.e., no
- attributes) with a Sync State Control indicating state present for
- each unchanged entry.
-
- The delete phase may be used when the server can reliably determine
- which entries in the prior client copy are no longer present in the
- content and the number of such entries is less than or equal to the
- number of unchanged entries. In the delete mode, the server sends an
- empty entry with a Sync State Control indicating state delete for each
- entry which is no longer in the content, instead of returning an empty
- entry with state present for each present entry.
-
- The server may send syncIdSet Sync Info Messages containing the set of
- UUIDs of either unchanged present entries or deleted entries, instead
- of sending multiple individual messages. If refreshDeletes of
- syncIdSet is set to FALSE, the UUIDs of unchanged present entries are
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- contained in the syncUUIDs set; if refreshDeletes of syncIdSet is set
- to TRUE, the UUIDs of the entries no longer present in the content are
- contained in the syncUUIDs set. An optional cookie can be included in
- the syncIdSet to represent the state of the content after
- synchronizing the presence or the absence of the entries contained in
- the syncUUIDs set.
-
- The synchronized copy of the DIT fragment is constructed by the
- client.
-
- If refreshDeletes of syncDoneValue is FALSE, the new copy includes all
- changed entries returned by the reissued Sync Operation as well as all
- unchanged entries identified as being present by the reissued Sync
- Operation, but whose content is provided by the previous Sync
- Operation. The unchanged entries not identified as being present are
- deleted from the client content. They had been either deleted, moved,
- or otherwise scoped-out from the content.
-
- If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
- changed entries returned by the reissued Sync Operation as well as all
- other entries of the previous copy except for those which are
- identified as having been deleted from the content.
-
- The client can, at some later time, re-poll for changes to this
- synchronized client copy.
-
-
-1.3.2. Listening for Changes (refreshAndPersist)
-
- Polling for changes can be expensive in terms of server, client, and
- network resources. The refreshAndPersist mode allows for active
- updates of changed entries in the content.
-
- By selecting the refreshAndPersist mode, the client requests the
- server to send updates of entries that are changed after the initial
- refresh content is determined. Instead of sending a SearchResultDone
- Message as in polling, the server sends a Sync Info Message to the
- client indicating that the refresh stage is complete and then enters
- the persist stage. After receipt of this Sync Info Message, the
- client will construct a synchronized copy as described in Section
- 1.3.1.
-
- The server may then send change notifications as the result of the
- original Sync search request which now remains persistent in the
- server. For entries to be added to the returned content, the server
- sends a SearchResultEntry (with attributes) with a Sync State Control
- indicating state add. For entries to be deleted from the content, the
- server sends a SearchResultEntry containing no attributes and a Sync
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- State Control indicating state delete. For entries to be modified in
- the return content, the server sends a SearchResultEntry (with
- attributes) with a Sync State Control indicating state modify. Upon
- modification of an entry, all (modified or unmodified) attributes
- belonging to the content are sent.
-
- Note that renaming an entry of the DIT may cause an add state change
- where the entry is renamed into the content, a delete state change
- where the entry is renamed out of the content, and a modify state
- change where the entry remains in the content. Also note that a
- modification of an entry of the DIT may cause an add, delete, or
- modify state change to the content.
-
- Upon receipt of a change notification, the client updates its copy of
- the content.
-
- If the server desires to update the syncCookie during the persist
- stage, it may include the syncCookie in any Sync State Control or Sync
- Info Message returned.
-
- The operation persists until canceled [CANCEL] by the client or
- terminated by the server. A Sync Done Control shall be attached to
- SearchResultDone Message to provide a new syncCookie.
-
-
-1.4. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.1 of [RFC2251].
-
-
-2. Elements of the Sync Operation
-
- The Sync Operation is defined as an extension to the LDAP Search
- Operation [RFC2251] where the directory user agent (DUA or client)
- submits a SearchRequest Message with a Sync Request Control and the
- directory system agent (DSA or server) responses with zero or more
- SearchResultEntry Messages, each with a Sync State Control; zero or
- more SearchResultReference Messages, each with a Sync State Control;
- zero or more Sync Info Intermediate Response Messages; and a
- SearchResultDone Message with a Sync Done Control.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- To allow clients to discover support for this operation, servers
- implementing this operation SHOULD publish the
- 1.3.6.1.4.1.4203.1.9.1.1 as a value of 'supportedControl' attribute
- [RFC2252] of the root DSA-specific entry (DSE). A server MAY choose
- to advertise this extension only when the client is authorized to use
- it.
-
-
-2.1 Common ASN.1 Elements
-
-2.1.1 syncUUID
-
- The syncUUID data type is an OCTET STRING holding a 128-bit (16-octet)
- Universally Unique Identifier (UUID) [UUID].
-
- syncUUID ::= OCTET STRING (SIZE(16))
- -- constrained to UUID
-
-
-2.1.2 syncCookie
-
- The syncCookie is a notational convenience to indicate that, while the
- syncCookie type is encoded as an OCTET STRING, its value is an opaque
- value containing information about the synchronization session and its
- state. Generally, the session information would include a hash of the
- operation parameters which the server requires not be changed and the
- synchronization state information would include a commit (log)
- sequence number, a change sequence number, or a time stamp. For
- convenience of description, the term no cookie refers either to null
- cookie or to a cookie with pre-initialized synchronization state.
-
- syncCookie ::= OCTET STRING
-
-
-2.2 Sync Request Control
-
- The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING,
- contains a BER-encoded syncRequestValue. The criticality field is
- either TRUE or FALSE.
-
- syncRequestValue ::= SEQUENCE {
- mode ENUMERATED {
- -- 0 unused
- refreshOnly (1),
- -- 2 reserved
- refreshAndPersist (3)
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 9]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- },
- cookie syncCookie OPTIONAL,
- reloadHint BOOLEAN DEFAULT FALSE
- }
-
- The Sync Request Control is only applicable to the SearchRequest
- Message.
-
-
-2.3 Sync State Control
-
- The Sync State Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING,
- contains a BER-encoded syncStateValue. The criticality is FALSE.
-
- syncStateValue ::= SEQUENCE {
- state ENUMERATED {
- present (0),
- add (1),
- modify (2),
- delete (3)
- },
- entryUUID syncUUID,
- cookie syncCookie OPTIONAL
- }
-
- The Sync State Control is only applicable to SearchResultEntry and
- SearchResultReference Messages.
-
-
-2.4 Sync Done Control
-
- The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded
- syncDoneValue. The criticality is FALSE (and hence absent).
-
- syncDoneValue ::= SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE
- }
-
- The Sync Done Control is only applicable to SearchResultDone Message.
-
-
-2.5 Sync Info Message
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 10]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Info Message is an LDAP Intermediate Response Message
- [LDAPIRM] where responseName is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
- syncInfoValue. The criticality is FALSE (and hence absent).
-
- syncInfoValue ::= CHOICE {
- newcookie [0] syncCookie,
- refreshDelete [1] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- refreshPresent [2] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- syncIdSet [3] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE,
- syncUUIDs SET OF syncUUID
- }
- }
-
-
-2.6 Sync Result Codes
-
- The following LDAP resultCode [RFC2251] is defined:
-
- e-syncRefreshRequired (IANA-ASSIGNED-CODE)
-
-
-3. Content Synchronization
-
- The Sync Operation is invoked by the client sending a SearchRequest
- Message with a Sync Request Control.
-
- The absence of a cookie or an initialized synchronization state in a
- cookie indicates a request for initial content while the presence of a
- cookie representing a state of a client copy indicates a request for
- content update. Synchronization Sessions are discussed in Section
- 3.1. Content Determination is discussed in Section 3.2.
-
- The mode is either refreshOnly or refreshAndPersist. The refreshOnly
- and refreshAndPersist modes are discussed in Section 3.3 and Section
- 3.4, respectively. The refreshOnly mode consists only of a refresh
- stage, while the refreshAndPersist mode consists of a refresh stage
- and a subsequent persist stage.
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 11]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-3.1. Synchronization Session
-
- A sequence of Sync Operations where the last cookie returned by the
- server for one operation is provided by the client in the next
- operation are said to belong to the same Synchronization Session.
-
- The client MUST specify the same content controlling parameters (see
- Section 3.5) in each Search Request of the session. The client SHOULD
- also issue each Sync request of a session under the same
- authentication and authorization associations with equivalent
- integrity and protections. If the server does not recognize the
- request cookie or the request is made under different associations or
- non-equivalent protections, the server SHALL return the initial
- content as if no cookie had been provided or return an empty content
- with the e-syncRefreshRequired LDAP result code. The decision between
- the return of the initial content and the return of the empty content
- with the e-syncRefreshRequired result code MAY be based on reloadHint
- in the Sync Request Control from the client. If the server recognizes
- the request cookie as representing empty or initial synchronization
- state of the client copy, the server SHALL return the initial content.
-
- A Synchronization Session may span multiple LDAP sessions between the
- client and the server. The client SHOULD issue each Sync request of a
- session to the same server. (Note: Shadowing considerations are
- discussed in Section 6.)
-
-
-3.2. Content Determination
-
- The content to be provided is determined by parameters of the Search
- Request, as described in [RFC2251], and possibly other controls. The
- same content parameters SHOULD be used in each Sync request of a
- session. If different content is requested and the server is
- unwilling or unable to process the request, the server SHALL return
- the initial content as if no cookie had been provided or return an
- empty content with the e-syncRefreshRequired LDAP result code. The
- decision between the return of the initial content and the return of
- the empty content with the e-syncRefreshRequired result code MAY be
- based on reloadHint in the Sync Request Control from the client.
-
- The content may not necessarily include all entries or references
- which would be returned by a normal search operation nor, for those
- entries included, not all attributes returned by a normal search.
- When the server is unwilling or unable to provide synchronization for
- any attribute for a set of entries, the server MUST treat all filter
- components matching against these attributes as Undefined and MUST NOT
- return these attributes in SearchResultEntry responses.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 12]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Servers SHOULD support synchronization for all non-collective
- user-application attributes for all entries.
-
- The server may also return continuation references to other servers or
- to itself. The latter is allowed as the server may partition the
- entries it holds into separate synchronization contexts.
-
- The client may chase all or some of these continuations, each as a
- separate content synchronization session.
-
-
-3.3. refreshOnly Mode
-
- A Sync request with mode refreshOnly and with no cookie is a poll for
- initial content. A Sync request with mode refreshOnly and with a
- cookie representing a synchronization state is a poll for content
- update.
-
-
-3.3.1. Initial Content Poll
-
- Upon receipt of the request, the server provides the initial content
- using a set of zero or more SearchResultEntry and
- SearchResultReference Messages followed by a SearchResultDone Message.
-
- Each SearchResultEntry Message SHALL include a Sync State Control of
- state add, entryUUID containing the entry's UUID, and no cookie. Each
- SearchResultReference Message SHALL include a Sync State Control of
- state add, entryUUID containing the UUID associated with the reference
- (normally the UUID of the associated named referral [RFC3296] object),
- and no cookie. The SearchResultDone Message SHALL include a Sync Done
- Control having refreshDeletes set to FALSE.
-
- A resultCode value of success indicates the operation successfully
- completed. Otherwise, the result code indicates the nature of
- failure. The server may return e-syncRefreshRequired result code on
- the initial content poll if it is safe to do so when it is unable to
- perform the operation due to various reasons. reloadHint is set to
- FALSE in the SearchRequest Message requesting the initial content
- poll.
-
- If the operation is successful, a cookie representing the
- synchronization state of the current client copy SHOULD be returned
- for use in subsequent Sync Operations.
-
-
-3.3.2. Content Update Poll
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 13]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Upon receipt of the request the server provides the content refresh
- using a set of zero or more SearchResultEntry and
- SearchResultReference Messages followed by a SearchResultDone Message.
-
- The server is REQUIRED to either:
- a) provide the sequence of messages necessary for eventual
- convergence of the client's copy of the content to the server's
- copy,
-
- b) treat the request as an initial content request (e.g., ignore
- the cookie or the synchronization state represented in the
- cookie),
-
- c) indicate that the incremental convergence is not possible by
- returning e-syncRefreshRequired,
-
- d) return a resultCode other than success or
- e-syncRefreshRequired.
-
- A Sync Operation may consist of a single present phase, a single
- delete phase, or a present phase followed by a delete phase.
-
- In each phase, for each entry or reference which has been added to the
- content or been changed since the previous Sync Operation indicated by
- the cookie, the server returns a SearchResultEntry or
- SearchResultReference Message, respectively, each with a Sync State
- Control consisting of state add, entryUUID containing the UUID of the
- entry or reference, and no cookie. Each SearchResultEntry Message
- represents the current state of a changed entry. Each
- SearchResultReference Message represents the current state of a
- changed reference.
-
- In the present phase, for each entry which has not been changed since
- the previous Sync Operation, an empty SearchResultEntry is returned
- whose objectName reflects the entry's current DN, the attributes field
- is empty, and a Sync State Control consisting of state present,
- entryUUID containing the UUID of the entry, and no cookie. For each
- reference which has not been changed since the previous Sync
- Operation, an empty SearchResultReference containing an empty SEQUENCE
- OF LDAPURL is returned with a Sync State Control consisting of state
- present, entryUUID containing the UUID of the entry, and no cookie.
- No messages are sent for entries or references which are no longer in
- the content.
-
- Multiple empty entries with a Sync State Control of state present
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to FALSE. syncUUIDs contain a set of
- UUIDs of the entries and references unchanged since the last Sync
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 14]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Operation. syncUUIDs may be empty. The Sync Info Message of
- syncIdSet may contain cookie to represent the state of the content
- after performing the synchronization of the entries in the set.
-
- In the delete phase, for each entry no longer in the content, the
- server returns a SearchResultEntry whose objectName reflects a past DN
- of the entry or is empty, the attributes field is empty, and a Sync
- State Control consisting of state delete, entryUUID containing the
- UUID of the deleted entry, and no cookie. For each reference no
- longer in the content, a SearchResultReference containing an empty
- SEQUENCE OF LDAPURL is returned with a Sync State Control consisting
- of state delete, entryUUID containing the UUID of the deleted
- reference, and no cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references which has been deleted from the
- content since the last Sync Operation. syncUUIDs may be empty. The
- Sync Info Message of syncIdSet may contain cookie to represent the
- state of the content after performing the synchronization of the
- entries in the set.
-
- When a present phase is followed by a delete phase, the two phases are
- delimited by a Sync Info Message containing syncInfoValue of
- refreshPresent, which may contain cookie representing the state after
- completing the present phase. The refreshPresent contains refreshDone
- which is always FALSE in the refreshOnly mode of Sync Operation
- because it is followed by a delete phase.
-
- If a Sync Operation consists of a single phase, each phase and hence
- the Sync Operation are marked ended by a SearchResultDone Message with
- Sync Done Control which SHOULD contain cookie representing the state
- of the content after completing the Sync Operation. The Sync Done
- Control contains refreshDeletes which is set to FALSE for the present
- phase and set to TRUE for the delete phase.
-
- If a Sync Operation consists of a present phase followed by a delete
- phase, the Sync Operation are marked ended at the end of the delete
- phase by a SearchResultDone Message with Sync Done Control which
- SHOULD contain cookie representing the state of the content after
- completing the Sync Operation. The Sync Done Control contains
- refreshDeletes which is set to TRUE.
-
- The client can specify whether it prefers to receive an initial
- content by supplying reloadHint of TRUE or to receive a
- e-syncRefreshRequired resultCode by supplying reloadHint of FALSE
- (hence absent), in the case that the server determines that it is
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 15]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- impossible or inefficient to achieve the eventual convergence by
- continuing the current incremental synchronization thread.
-
- A resultCode value of success indicates the operation is successfully
- completed. A resultCode value of e-syncRefreshRequired indicates that
- a full or partial refresh is needed. Otherwise, the result code
- indicates the nature of failure. A cookie is provided in the Sync
- Done Control for use in subsequent Sync Operations for incremental
- synchronization.
-
-
-3.4. refreshAndPersist Mode
-
- A Sync request with mode refreshAndPersist asks for initial content or
- content update (during the refresh stage) followed by change
- notifications (during the persist stage).
-
-
-3.4.1. refresh Stage
-
- The content refresh is provided as described in Section 3.3 excepting
- that the successful completion of content refresh is indicated by
- sending a Sync Info Message of refreshDelete or refreshPresent with a
- refreshDone value set to TRUE instead of a SearchResultDone Message
- with resultCode success. A cookie SHOULD be returned in the Sync Info
- Message to represent the state of the content after finishing the
- refresh stage of the Sync Operation.
-
-
-3.4.2. persist Stage
-
- Change notifications are provided during the persist stage.
-
- As updates are made to the DIT the server notifies the client of
- changes to the content. DIT updates may cause entries and references
- to be added to the content, deleted from the content, or modified
- within the content. DIT updates may also cause references to be
- added, deleted, or modified within the content.
-
- Where DIT updates cause an entry to be added to the content, the
- server provides a SearchResultEntry Message which represents the entry
- as it appears in the content. The message SHALL include a Sync State
- Control with state of add, entryUUID containing the entry's UUID, and
- an optional cookie.
-
- Where DIT updates cause a reference to be added to the content, the
- server provides a SearchResultReference Message which represents the
- reference in the content. The message SHALL include a Sync State
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 16]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Control with state of add, entryUUID containing the UUID associated
- with the reference, and an optional cookie.
-
- Where DIT updates cause an entry to be modified within the content,
- the server provides a SearchResultEntry Message which represents the
- entry as it appears in the content. The message SHALL include a Sync
- State Control with state of modify, entryUUID containing the entry's
- UUID, and an optional cookie.
-
- Where DIT updates cause a reference to be modified within the content,
- the server provides a SearchResultEntry Message which represents the
- reference in the content. The message SHALL include a Sync State
- Control with state of modify, entryUUID containing the UUID associated
- with the reference, and an optional cookie.
-
- Where DIT updates cause an entry to be deleted from the content, the
- server provides a SearchResultReference Message with an empty SEQUENCE
- OF LDAPURL. The message SHALL include a Sync State Control with state
- of delete, entryUUID containing the UUID associated with the
- reference, and an optional cookie.
-
- Where DIT updates cause a reference to be deleted from the content,
- the server provides a SearchResultEntry Message with no attributes.
- The message SHALL include a Sync State Control with state of delete,
- entryUUID containing the entry's UUID, and an optional cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references which has been deleted from the
- content. The Sync Info Message of syncIdSet may contain cookie to
- represent the state of the content after performing the
- synchronization of the entries in the set.
-
- With each of these messages, the server may provide a new cookie to be
- used in subsequent Sync Operations. Additionally, the server may also
- return Sync Info Messages of choice newCookie to provide a new cookie.
- The client SHOULD use the newest (last) cookie it received from the
- server in subsequent Sync Operations.
-
-
-3.5. Search Request Parameters
-
- As stated in Section 3.1, the client SHOULD specify the same content
- controlling parameters in each Search Request of the session. All
- fields of the SearchRequest Message are considered content controlling
- parameters except for sizeLimit and timeLimit.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 17]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-3.5.1. baseObject
-
- As with the normal search operation, the refresh and persist stages
- are not isolated from DIT changes. It is possible that the entry
- referred to by the baseObject is deleted, renamed, or moved. It is
- also possible that alias object used in finding the entry referred to
- by the baseObject is changed such that the baseObject refers to a
- different entry.
-
- If the DIT is updated during processing of the Sync Operation in a
- manner that causes the baseObject to no longer refer to any entry or
- in a manner that changes the entry the baseObject refers to, the
- server SHALL return an appropriate non-success result code such as
- noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
- e-syncRefreshRequired.
-
-
-3.5.2. derefAliases
-
- This operation does not support alias dereferencing during searching.
- The client SHALL specify neverDerefAliases or derefFindingBaseObj for
- the SearchRequest derefAliases parameter. The server SHALL treat
- other values (e.g., derefInSearching, derefAlways) as protocol errors.
-
-
-3.5.3. sizeLimit
-
- The sizeLimit applies only to entries (regardless of their state in
- Sync State Control) returned during the refreshOnly operation or the
- refresh stage of the refreshAndPersist operation.
-
-
-3.5.4. timeLimit
-
- For a refreshOnly Sync Operation, the timeLimit applies to the whole
- operation. For a refreshAndPersist operation, the timeLimit applies
- only to the refresh stage including the generation of the Sync Info
- Message with a refreshDone value of TRUE.
-
-
-3.5.5. filter
-
- The client SHOULD avoid filter assertions which apply to the values of
- the attributes likely to be considered by the server as ones holding
- meta-information. See Section 4.
-
-
-3.6. objectName
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 18]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Operation uses entryUUID values provided in the Sync State
- Control as the primary keys to entries. The client MUST use these
- entryUUIDs to correlate synchronization messages.
-
- In some circumstances the DN returned may not reflect the entry's
- current DN. In particular, when the entry is being deleted from the
- content, the server may provide an empty DN if the server does not
- wish to disclose the entry's current DN (or, if deleted from the DIT,
- the entry's last DN).
-
- It should also be noted that the entry's DN may be viewed as meta
- information (see Section 4.1).
-
-
-3.7. Canceling the Sync Operation
-
- Servers MUST implement the LDAP Cancel [CANCEL] Operation and support
- cancellation of outstanding Sync Operations as described here.
-
- To cancel an outstanding Sync Operation, the client issues an LDAP
- Cancel [CANCEL] Operation.
-
- If at any time the server becomes unwilling or unable to continue
- processing a Sync Operation, the server SHALL return a
- SearchResultDone with a non-success resultCode indicating the reason
- for the termination of the operation.
-
- Whether the client or the server initiated the termination, the server
- may provide a cookie in the Sync Done Control for use in subsequent
- Sync Operations.
-
-
-3.8. Refresh Required
-
- In order to achieve the eventually-convergent synchronization, the
- server may terminate the Sync Operation in the refresh or the persist
- stage by returning a e-syncRefreshRequired resultCode to the client.
- If no cookie is provided, a full refresh is needed. If a cookie
- representing a synchronization state is provided in this response, an
- incremental refresh is needed.
-
- To obtain a full refresh, the client then issues a new synchronization
- request with no cookie. To obtain an incremental reload, the client
- issues a new synchronization with the provided cookie.
-
- The server may choose to provide a full copy in the refresh stage
- (e.g., ignore the cookie or the synchronization state represented in
- the cookie) instead of providing an incremental refresh in order to
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 19]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- achieve the eventual convergence.
-
- The decision between the return of the initial content and the return
- of the e-syncRefreshRequired result code may be based on reloadHint in
- the Sync Request Control from the client.
-
- In the case of persist stage Sync, the server returns the resultCode
- of e-syncRefreshRequired to the client to indicate that the client
- needs to issue a new Sync Operation in order to obtain a synchronized
- copy of the content. If no cookie is provided, a full refresh is
- needed. If a cookie representing a synchronization state is provided,
- an incremental refresh is needed.
-
- The server may also return e-syncRefreshRequired if it determines that
- a refresh would be more efficient than sending all the messages
- required for convergence.
-
- It is noted that the client may receive one or more of
- SearchResultEntry, SearchResultReference, and/or Sync Info Messages
- before it receives SearchResultDone Message with the
- e-syncRefreshRequired result code.
-
-
-3.9. Chattiness Considerations
-
- The server MUST ensure that the number of entry messages generated to
- refresh the client content does not exceed the number of entries
- presently in the content. While there is no requirement for servers
- to maintain history information, if the server has sufficient history
- to allow it to reliably determine which entries in the prior client
- copy are no longer present in the content and the number of such
- entries is less than or equal to the number of unchanged entries, the
- server SHOULD generate delete entry messages instead of present entry
- messages (see Section 3.3.2).
-
- When the amount of history information maintained in the server is not
- enough for the clients to perform infrequent refreshOnly Sync
- Operations, it is likely that the server has incomplete history
- information (e.g. due to truncation) by the time those clients connect
- again.
-
- The server SHOULD NOT resort to full reload when the history
- information is not enough to generate delete entry messages. The
- server SHOULD generate either present entry messages only or present
- entry messages followed by delete entry messages to bring the client
- copy to the current state. In the latter case, the present entry
- messages bring the client copy to a state covered by the history
- information maintained in the server.
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 20]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The server SHOULD maintain enough (current or historical) state
- information (such as a context-wide last modify time stamp) to
- determine if no changes were made in the context since the content
- refresh was provided and, and when no changes were made, generate zero
- delete entry messages instead of present messages.
-
- The server SHOULD NOT use the history information when its use does
- not reduce the synchronization traffic or when its use can expose
- sensitive information not allowed to be received by the client.
-
- The server implementor should also consider chattiness issues which
- span multiple Sync Operations of a session. As noted in Section 3.8,
- the server may return e-syncRefreshRequired if it determines that a
- reload would be more efficient than continuing under the current
- operation. If reloadHint in the Sync Request is TRUE, the server may
- initiate a reload without directing the client to request a reload.
-
- The server SHOULD transfer a new cookie frequently to avoid having to
- transfer information already provided to the client. Even where DIT
- changes do not cause content synchronization changes to be
- transferred, it may be advantageous to provide a new cookie using a
- Sync Info Message. However, the server SHOULD avoid overloading the
- client or network with Sync Info Messages.
-
- During persist mode, the server SHOULD coalesce multiple outstanding
- messages updating the same entry. The server MAY delay generation of
- an entry update in anticipation of subsequent changes to that entry
- which could be coalesced. The length of the delay should be long
- enough to allow coalescing of update requests issued back to back but
- short enough that the transient inconsistency induced by the delay is
- corrected in a timely manner.
-
- The server SHOULD use syncIdSet Sync Info Message when there are
- multiple delete or present messages to reduce the amount of
- synchronization traffic.
-
- It is also noted that there may be many clients interested in a
- particular directory change, and servers attempting to service all of
- these at once may cause congestion on the network. The congestion
- issues are magnified when the change requires a large transfer to each
- interested client. Implementors and deployers of servers should take
- steps to prevent and manage network congestion.
-
-
-3.10. Operation Multiplexing
-
- The LDAP protocol model [RFC2251] allows operations to be multiplexed
- over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 21]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- sessions with the same server. Servers SHOULD ensure that responses
- from concurrently processed operations are interleaved fairly.
-
- Clients SHOULD combine Sync Operations whose result set is largely
- overlapping. This avoids having to return multiple messages, once for
- each overlapping session, for changes to entries in the overlap.
-
- Clients SHOULD NOT combine Sync Operations whose result sets are
- largely non-overlapping with each other. This ensures that an event
- requiring a e-syncRefreshRequired response can be limited to as few
- result sets as possible.
-
-
-4. Meta Information Considerations
-
-4.1. Entry DN
-
- As an entry's DN is constructed from its relative DN (RDN) and the
- entry's parent's DN, it is often viewed as meta information.
-
- While renaming or moving to a new superior causes the entry's DN to
- change, that change SHOULD NOT, by itself, cause synchronization
- messages to be sent for that entry. However, if the renaming or the
- moving could cause the entry to be added or deleted from the content,
- appropriate synchronization messages should be generated to indicate
- this to the client.
-
- When a server treats the entry's DN as meta information, the server
- SHALL either
-
- - evaluate all MatchingRuleAssertions [RFC2251] to TRUE if
- matching a value of an attribute of the entry and otherwise
- Undefined, or
- - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
- Undefined.
-
- The latter choice is offered for ease of server implementation.
-
-
-4.2. Operational Attributes
-
- Where values of an operational attribute is determined by values not
- held as part of the entry it appears in, the operational attribute
- SHOULD NOT support synchronization of that operational attribute.
-
- For example, in servers which implement X.501 subschema model [X.501],
- servers should not support synchronization of the subschemaSubentry
- attribute as its value is determined by values held and administrated
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 22]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- in subschema subentries.
-
- As a counter example, servers which implement aliases [RFC2256][X.501]
- can support synchronization of the aliasedObjectName attribute as its
- values are held and administrated as part of the alias entries.
-
- Servers SHOULD support synchronization of the following operational
- attributes: createTimestamp, modifyTimestamp, creatorsName,
- modifiersName [RFC2252]. Servers MAY support synchronization of other
- operational attributes.
-
-
-4.3. Collective Attributes
-
- A collective attribute is "a user attribute whose values are the same
- for each member of an entry collection" [X.501]. Use of collective
- attributes in LDAP is discussed in [RFC3371].
-
- Modification of a collective attribute generally affects the content
- of multiple entries, which are the members of the collection. It is
- inefficient to include values of collective attributes visible in
- entries of the collection, as a single modification of a collective
- attribute requires transmission of multiple SearchResultEntry (one for
- each entry of the collection which the modification affected) to be
- transmitted.
-
- Servers SHOULD NOT synchronize collective attributes appearing in
- entries of any collection. Servers MAY support synchronization of
- collective attributes appearing in collective attribute subentries.
-
-
-4.4. Access and Other Administrative Controls
-
- Entries are commonly subject to access and other administrative
- Controls. While portions of the policy information governing a
- particular entry may be held in the entry, policy information is often
- held elsewhere (in superior entries, in subentries, in the root DSE,
- in configuration files etc.). Because of this, changes to policy
- information make it difficult to ensure eventual convergence during
- incremental synchronization.
-
- Where it is impractical or infeasible to generate content changes
- resulting from a change to policy information, servers may opt to
- return e-syncRefreshRequired or treat the Sync Operation as an initial
- content request (e.g., ignore the cookie or the synchronization state
- represented in the cookie).
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 23]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-5. Interaction with Other Controls
-
- The Sync Operation may be used with:
-
- - ManageDsaIT Control [RFC3296]
- - Subentries Control [RFC3672]
-
- as described below. The Sync Operation may be used with other LDAP
- extensions as detailed in other documents.
-
-
-5.1. ManageDsaIT Control
-
- The ManageDsaIT Control [RFC3296] indicates that the operation acts
- upon the DSA Information Tree and causes referral and other special
- entries to be treated as object entries with respect to the operation.
-
-
-5.2. Subentries Control
-
- The Subentries Control is used with the search operation "to control
- the visibility of entries and subentries which are within scope"
- [RFC3672]. When used with the Sync Operation, the subentries control
- and other factors (search scope, filter, etc.) are used to determine
- whether an entry or subentry appear in the content or not.
-
-
-6. Shadowing Considerations
-
- As noted in [RFC2251], some servers may hold shadow copies of entries
- which can be used to answer search and comparison queries. Such
- servers may also support content synchronization requests. This
- section discusses considerations for implementors and deployers for
- the implementation and deployment of the Sync operation in shadowed
- directories.
-
- While a client may know of multiple servers which are equally capable
- of being used to obtain particular directory content from, a client
- SHOULD NOT assume that each of these server is equally capable of
- continuing a content synchronization session. As stated in Section
- 3.1, the client SHOULD issue each Sync request of a Sync session to
- the same server.
-
- However, through domain naming or IP address redirection or other
- techniques, multiple physical servers can be made to appear as one
- logical server to a client. Only servers which are equally capable in
- regards to their support for the Sync operation and which hold equally
- complete copies of the entries should be made to appear as one logical
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 24]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- server. In particular, each physical server acting as one logical
- server SHOULD be equally capable of continuing a content
- synchronization based upon cookies provided by any of the other
- physical servers without requiring a full reload. Because there is no
- standard LDAP shadowing mechanism, the specification of how to
- independently implement equally capable servers (as well as the
- precise definition of "equally capable") is left to future documents.
-
- It is noted that it may be difficult for the server to reliably
- determine what content was provided to the client by another server,
- especially in the shadowing environments which allow shadowing events
- to be coalesced. Where so, the use of the delete phase discussed in
- Section 3.3.2 may not be applicable.
-
-
-7. Security Considerations
-
- In order to maintain a synchronized copy of the content, a client is
- to delete information from its copy of the content as described above.
- However, the client may maintain knowledge of information disclosed to
- it by the server separate from its copy of the content used for
- synchronization. Management of this knowledge is beyond the scope of
- this document. Servers should be careful not to disclose information
- for content which the client is not authorized to have knowledge of
- and/or about.
-
- While the information provided by a series of refreshOnly Sync
- Operations is similar to that provided by a series of Search
- Operations, persist stage may disclose additional information. A
- client may be able to discern information about the particular
- sequence of update operations which caused content change.
-
- Implementors should take precautions against malicious cookie content,
- including malformed cookies or valid cookies used with different
- security associations and/or protections in attempt to obtain
- unauthorized access to information. Servers may include a digital
- signature in the cookie to detect tampering.
-
- The operation may be the target of direct denial of service attacks.
- Implementors should provide safeguards to ensure the operation is not
- abused. Servers may place access control or other restrictions upon
- the use of this operation.
-
- It is noted that even small updates to the directory may cause
- significant amount of traffic to be generated to clients using this
- operation. A user could abuse its update privileges to mount an
- indirect denial of service to these clients, other clients, and/or
- portions of the network. Servers should provide safeguards to ensure
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 25]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- update operations are not abused.
-
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP security considerations [RFC3377].
-
-
-8. IANA Considerations
-
- Registration of the following values is requested.
-
- The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by OpenLDAP
- Foundation, under its IANA-assigned private enterprise allocation
- [PRIVATE], for use in this specification.
-
-
-8.2. LDAP Protocol Mechanism
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
- Description: LDAP Content Synchronization Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-8.3. LDAP Result Codes
-
- It is requested that IANA register the LDAP Result Code described in
- this document.
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: e-syncRefreshRequired (IANA-ASSIGNED-CODE)
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-9. Acknowledgments
-
- This document borrows significantly from the LDAP Client Update
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 26]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Protocol [LCUP], a product of the IETF LDUP working group. This
- document also benefited from Persistent Search [PSEARCH], Triggered
- Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This
- document also borrows from "Lightweight Directory Access Protocol
- (v3)" [RFC2251].
-
-
-10. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
- December 2003.
-
- [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
- 3672, December 2003.
-
- [CANCEL] Zeilenga, K., "LDAP Cancel Extended Operation",
- draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
- [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
- Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
- progress.
-
- [LDAPIRM] Harrison, R. and Zeilenga, K., "LDAP Intermediate
- Response",
- draft-rharrison-ldap-intermediate-resp-00.txt, a work in
- progress.
-
- [UUID] International Organization for Standardization (ISO),
- "Information technology - Open Systems Interconnection -
- Remote Procedure Call", ISO/IEC 11578:1996
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 27]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
-
-11. Informative References
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
- use with LDAPv3", RFC 2256, December 1997.
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993).
-
- [X.525] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Replication", X.525(1993).
-
- [UUIDinfo] The Open Group, "Universally Unique Identifier" appendix
- of the CAE Specification "DCE 1.1: Remote Procedure
- Calls", Document Number C706,
- <http://www.opengroup.org/products/publications/
- catalog/c706.htm> (appendix available at:
- <http://www.opengroup.org/onlinepubs/9629399/
- apdxa.htm>), August 1997.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 28]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
- Synchronization", draft-armijo-ldap-dirsync-xx.txt, a
- work in progress.
-
- [LCUP] Megginson, R., et. al., "LDAP Client Update Protocol",
- draft-ietf-ldup-lcup-xx.txt, a work in progress.
-
- [PSEARCH] Smith, M., et. al., "Persistent Search: A Simple LDAP
- Change Notification Mechanism",
- draft-ietf-ldapext-psearch-xx.txt, a work in progress.
-
- [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control",
- draft-ietf-ldapext-trigger-xx.txt, a work in progress.
-
-
-12. Authors' Addresses
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
- Jong Hyuk Choi
- IBM Corporation
- <jongchoi@us.ibm.com>
-
-
-
-Appendix A. CSN-based Implementation Considerations
-
- This appendix is provided for informational purposes only, it is not a
- normative part of the LDAP Content Synchronization Operation's
- technical specification.
-
- This appendix discusses LDAP Content Synchronization Operation server
- implementation considerations associated with a Change Sequence Number
- based approaches.
-
- Change Sequence Number based approaches are targeted for use in
- servers which do not maintain history information (e.g., change logs,
- state snapshots, etc.) about changes made to the Directory and hence,
- must rely on current directory state and minimal synchronization state
- information embedded in Sync Cookie. Servers which maintain history
- information should consider other approaches which exploit the history
- information.
-
- A Change Sequence Number is effectively a time stamp which has
- sufficient granularity to ensure that the precedence relationship in
- time of two updates to the same object can be determined. Change
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 29]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Sequence Numbers are not to be confused with Commit Sequence Numbers
- or Commit Log Record Numbers. A Commit Sequence Number allows one to
- determine how two commits (to the same object or different objects)
- relate to each other in time. Change Sequence Number associated with
- different entries may be committed out of order. In the remainder of
- this Appendix, the term CSN refers to a Change Sequence Number.
-
- In these approaches, the server not only maintains a CSN for each
- directory entry (the entry CSN), but also maintains a value which we
- will call the context CSN. The context CSN is the greatest committed
- entry CSN which is not greater than any outstanding (uncommitted)
- entry CSNs for all entries in a directory context. The values of
- context CSN are used in syncCookie values as synchronization state
- indicators.
-
- As search operations are not isolated from individual directory update
- operations and individual update operations cannot be assumed to be
- serialized, one cannot assume that the returned content incorporates
- all relevant changes whose change sequence number is less than or
- equal to the greatest entry CSN in the content. The content
- incorporates all the relevant changes whose change sequence number is
- less than or equal to context CSN before search processing. The
- content may also incorporate any subset of the changes whose change
- sequence number is greater than context CSN before search processing
- but less than or equal to the context CSN after search processing.
- The content does not incorporate any of the changes whose CSN is
- greater than the context CSN after search processing.
-
- A simple server implementation could use value of the context CSN
- before search processing to indicate state. Such an implementation
- would embed this value into each SyncCookie returned. We'll call this
- the cookie CSN. When a refresh was requested, the server would simply
- generate "update" messages for all entries in the content whose CSN is
- greater than the supplied cookie CSN and generate "present" messages
- for all other entries in the content. However, if the current context
- CSN is the same as the cookie CSN, the server should instead generate
- zero "updates" and zero "delete" messages, and indicate refreshDeletes
- of TRUE as the directory has not changed.
-
- The implementation should also consider the impact of changes to meta
- information, such as access controls, which affects content
- determination. One approach is for the server to maintain a context
- wide meta information CSN or meta CSN. This meta CSN would be updated
- whenever meta information affecting content determination was changed.
- If the value of the meta CSN is greater than cookie CSN, the server
- should ignore the cookie and treat the request as an initial request
- for content.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 30]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Additionally, servers may want to consider maintaining some
- per-session history information to reduce the number of messages
- needed to be transferred during incremental refreshes. Specifically,
- a server could record information about entries as they leave the
- scope of a disconnected sync session and later use this information to
- generate delete messages instead of present messages.
-
- When the history information is truncated, the CSN of the latest
- truncated history information entry may be recorded as the truncated
- CSN of the history information. The truncated CSN may be used to
- determine whether a client copy can be covered by the history
- information by comparing it to the synchronization state contained in
- the cookie supplied by the client.
-
- When there are a large number of sessions, it may make sense to
- maintain such history only for the selected clients. Also, servers
- taking this approach need to consider resource consumption issues to
- ensure reasonable server operation and to protect against abuse. It
- may be appropriate to restrict this mode of operation by policy.
-
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to pertain
- to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; neither does it represent that it has made any
- effort to identify any such rights. Information on the IETF's
- procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such proprietary
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-Full Copyright
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 31]
-\f
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 32]
-\f
-
This is an index of RFC contained in this directory:
-rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2247.txt Using Domains in LDAP DNs (PS)
-rfc2251.txt LDAPv3 Protocol (PS)
-rfc2252.txt LDAPv3 Attribute Types (PS)
-rfc2253.txt LDAPv3 Disinguished Name (PS)
-rfc2254.txt LDAPv3 Search Filters (PS)
-rfc2255.txt LDAPv3 URL Format (PS)
-rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
-rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
rfc3088.txt OpenLDAP Root Service (E)
rfc3112.txt LDAP Authentication Password Schema (I)
rfc3296.txt Named Subordinate References in LDAP (PS)
-rfc3377.txt LDAP(v3): Technical Specification (PS)
-rfc3383.txt IANA Considerations for LDAP (BCP)
rfc3663.txt Domain Administrative Data in LDAP (E)
rfc3671.txt Collective Attributes in LDAP (PS)
rfc3672.txt Subentries in LDAP (PS)
rfc3673.txt LDAPv3: All Operational Attributes (PS)
-rfc3674.txt Feature Discovery in LDAP (PS)
rfc3687.txt LDAP Component Matching Rules (PS)
rfc3698.txt LDAP: Additional Matching Rules (PS)
rfc3703.txt LDAP: Schema for Policy Core (PS)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
-rfc3771.txt LDAP: Intermediate Response Message (PS)
rfc3829.txt LDAP Authorization Identity Controls (I)
rfc3866.txt Language Tag and Ranges in LDAP (PS)
rfc3876.txt Returning Matched Values with LDAP (PS)
rfc4370.txt LDAP Proxied Authorization Control (PS)
rfc4373.txt LBURP (I)
rfc4404.txt LDAP Schema for UDDI (I)
+rfc4510.txt LDAP Technical Specification Roadmap (PS)
+rfc4511.txt LDAP: The Protocol (PS)
+rfc4512.txt LDAP: Directory Information Models (PS)
+rfc4513.txt LDAP: Authentication Methods and Security Mechanisms (PS)
+rfc4514.txt LDAP: DN (PS)
+rfc4515.txt LDAP: Search Filters (PS)
+rfc4516.txt LDAP: URL (PS)
+rfc4517.txt LDAP: Syntaxes and Matching Rules (PS)
+rfc4518.txt LDAP: Internationalized String Preparation (PS)
+rfc4519.txt LDAP: User Applications Schema (PS)
+rfc4520.txt IANA Considerations for LDAP (BCP)
+rfc4521.txt Considerations for LDAP Extensions (BCP)
+rfc4522.txt LDAP: Binary Encoding Option (PS)
+rfc4523.txt LDAP: X.509 Certificate Schema (PS)
+rfc4524.txt LDAP: COSINE Schema (PS)
+rfc4525.txt LDAP: Modify-Increment Extension (I)
+rfc4526.txt LDAP: Absolute True and False Filters (PS)
+rfc4527.txt LDAP: Read Entry Controls (PS)
+rfc4528.txt LDAP: Assertion Control (PS)
+rfc4529.txt LDAP: Requesting Attributes by Object Class
+rfc4530.txt LDAP: entryUUID (PS)
+rfc4531.txt LDAP Turn Operation (E)
+rfc4532.txt LDAP Who am I? Operation (PS)
+rfc4533.txt LDAP Content Sync Operation (E)
Legend:
STD Standard
+++ /dev/null
-
-
-
-
-
-
-Network Working Group P. Barker
-Request for Comments: 1274 S. Kille
- University College London
- November 1991
-
-
- The COSINE and Internet X.500 Schema
-
-Status of this Memo
-
- This RFC specifies an IAB standards track protocol for the Internet
- community, and requests discussion and suggestions for improvements.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-Abstract
-
- This document suggests an X.500 Directory Schema, or Naming
- Architecture, for use in the COSINE and Internet X.500 pilots. The
- schema is independent of any specific implementation. As well as
- indicating support for the standard object classes and attributes, a
- large number of generally useful object classes and attributes are
- also defined. An appendix to this document includes a machine
- processable version of the schema.
-
- This document also proposes a mechanism for allowing the schema to
- evolve in line with emerging requirements. Proformas to support this
- process are included.
-
- Corrections and additions to the schema should be sent to na-
- update@cs.ucl.ac.uk list, as described within.
-
-1. Introduction
-
- Directory Services are a fundamental requirement of both human and
- computer communications' systems. Human users need to be able to
- look up various details about other people: for example, telephone
- numbers, facsimile numbers and paper mail addresses. Computing
- systems also need Directory Services for several purposes: for
- example, to support address look-ups for a variety of services, and
- to support user-friendly naming and distribution lists in electronic
- mail systems.
-
- Directory Services have recently been standardised and published as
- the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard
- provides a good basis for the provision of real services, and a
- considerable amount of Directory Service piloting activity is
-
-
-
-Barker & Kille [Page 1]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- currently underway. In the U.S., the PSI White Pages Pilot [4] has
- stimulated use of X.500 on the Internet. In Britain, the U.K.
- Academic Community Directory Pilot [5] is similarly promoting use of
- X.500.
-
-2. Motivation and aims of this document
-
- In a number of areas the X.500 standard only provides a basis for
- services. One such area is the Directory's Schema or Naming
- Architecture. The standard defines a number of useful object
- classes, in X.521, and attribute types, in X.520. These are intended
- to be generally useful across a range of directory applications.
- However, while these standard definitions are a useful starting
- point, they are insufficient as a basis for a large scale pilot
- directory.
-
- While it is possible for directory administrators to define their own
- sets of additional attribute types and object classes, this is
- undesirable for some common attributes and objects. The same objects
- and attribute types would be privately defined many times over. This
- would result in the directory's generality being diminished as remote
- systems would be unable to determine the semantics of these privately
- defined data types.
-
- A number of useful additions to the standard definitions were made in
- this note's forerunner, "The THORN and RARE Naming Architecture" [2].
- These have been heavily used in early X.500 piloting activities.
- Furthermore, both the THORN and Quipu X.500 implementations have made
- use of these definitions.
-
- Since the afore-mentioned note was issued, a number of further
- requirements have come to light as the volume and variety of piloting
- activity has increased. Yet further requirements seem likely as the
- scale of X.500 pilot services increases. Thus, it is argued that it
- is not sufficient to merely reissue an updated version of the
- original note. The schema is a "living document" that needs
- procedures for:
-
- - Allowing submission of requests for new attributes and
- object classes to be added into the schema;
-
- - Allowing groups of object classes and attribute types
- defined elsewhere to be integrated into the schema.
-
- - Checking for the redundancy of any previously defined
- attribute types and object classes.
-
- This document attempts to establish procedures to allow for the
-
-
-
-Barker & Kille [Page 2]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- continual updating of the schema. Two proformas are set out for this
- purpose. In addition, descriptive detail is provided for the
- additional object classes and attribute types defined in the schema.
- These descriptions follow the style used in X.520 and X.521.
- Finally, also following the style adopted in the standards documents,
- appendices will include the entire schema. Plain text versions of
- the document's appendices are intended to be machine processable to
- allow derivation of a system's schema tables. Appendix C lists all
- the schema's object classes and attribute types in their respective
- ASN.1 macro formats.
-
- The scope and intended remit of this coordination activity should be
- clearly understood.
-
- - Esoteric and local, highly experimental requirements should
- continue to be met by private definitions.
-
- - Requirements which have support from more than one site will
- usually be integrated into the schema. Put in other words,
- the tendency will be for the inclusion, as opposed to the
- exclusion, of useful additions to the schema.
-
- - An attempt will be made to avoid duplication of object
- classes and attribute types for essentially similar real
- world objects.
-
-3. What conformance to this schema means
-
- It is not reasonable to require that a DSA which supports this schema
- has specific code to handle each of the defined syntaxes. However,
- the following requirements are made of a system which claims
- conformance to this specification:
-
- 1. A DSA shall be able to store all of the attributes and
- object class values specified. (Note that this implies
- support for all the object classes and attribute types
- required by strong authentication as defined in X.509.)
-
- 2. A DUA shall be able to identify each attribute type and
- object class to the user, with an appropriate representation
- (e.g., a string).
-
- 3. These statement are qualified for large attributes values
- (>1kbyte). A conforming DSA does not have to store such
- attribute values, and a DUA does not have to display such
- values, although it must indicate their presence.
-
- The following are desirable, but not required:
-
-
-
-Barker & Kille [Page 3]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- 1. For a DSA to match correctly on the basis of all attribute
- syntaxes defined
-
- 2. For a DSA to enforce the Object Class schema implied by
- these definitions
-
- 3. For a DUA to correctly display the attribute values
- (syntaxes) defined
-
- 4. For DUAs and DSAs to maintain compatibility with a previous
- version of the schema.
-
-4. Requesting new object classes and attribute types
-
- This section defines procedures for requesting new object classes and
- attribute types to be added to the schema. Proformas for object
- classes and attribute types are specified, and examples given of how
- to use them. A mechanism for making requests for large groups of new
- object classes and attribute types is described in the next section.
-
- As stated earlier, it is anticipated that the schema will evolve
- considerably over time. As X.500 is used to support a widening range
- of applications, there will be requirements for extensions to the
- schema. This document proposes formalising this procedure by
- requiring requests for additions to the schema to be submitted as
- completed proformas. This stipulation will greatly simplify
- subsequent revisions of the schema.
-
- There is one qualification to the above with respect to requests for
- modifications to an existing object class. If a modification to an
- object class merely involves additional, optional attributes, the
- object class will be enhanced as requested. Systems are expected to
- be resilient to such changes to the schema. However, requests to
- modify an object class, such that the mandatory attribute types
- require altering, will not be met. Instead, a new object class will
- be created, and the original object class expired following the
- scheme described in the next main section.
-
- It is anticipated that most requests for modifications to the schema
- will be met without any need for editorial intervention. Sometimes,
- however, some discussion between the submitter of a request and the
- schema's editor may be required. For example, the editor may have to
- judge the relative merits of two very similar requests and, as a
- result, one of the parties may not get quite what they want. In
- cases such as this where the submitter of a request feels aggrieved
- about an editorial decision, the requestor may appeal to a broader
- community by explaining their views to the mailing list osi-
- ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges
-
-
-
-Barker & Kille [Page 4]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- from discussions on the schema on this list. If it proves that this
- list is used almost solely for discussions on schema issues, a
- separate discussion list will be created.
-
- To facilitate the production of the afore-mentioned proformas, tools
- are included in Appendix B which will verify that a proforma has been
- correctly formatted.
-
- Completed proformas should be mailed to na-update@cs.ucl.ac.uk
-
-4.1. Object Class proforma
-
- This section gives an example, completed proforma for a new object
- class, alcoholic drink. A proforma for object class specified in BNF
- is included in Appendix A.
-
- Object Class: Alcoholic Drink
-
- Description: The Alcoholic Drink object class is used to define
- entries representing intoxicating beverages.
-
- ASN1OCMacro: alcoholicDrink OBJECT-CLASS
- SUBCLASS OF drink
- MUST CONTAIN {
- percentAlcohol}
- MAY CONTAIN {
- normalServing,
- hue}
-
- An object class description consists of three fields, separated by
- blank lines. The keywords Object Class, Description and ASN1OCMacro,
- and their suffixed colons, must be included exactly as above.
-
- The Object Class field should be used for a textual description of
- the object class. This will be at most three or four words.
-
- The Description field should contain some explanatory text about the
- intended use of the object class. This can run to a number of lines.
-
- The ASN1OCMacro field should follow the definition of the object
- class macro as specified in X.501. The above example shows the main
- features. There are many more examples which can studied in the
- section defining the Pilot Object Classes.
-
-4.2. Attribute type proforma
-
- This section gives an example completed proforma for a new attribute
- type, hue (one of the attribute types in the alcoholic drink object
-
-
-
-Barker & Kille [Page 5]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- class).
-
- Attribute Type: Hue
-
- Description: The Hue attribute type specifies the hue of
- an object. (Note that a description may run to several
- lines.)
-
- OCMust:
-
- OCMay: alcoholicDrink
-
- ASN1ATMacro:hue ATTRIBUTE
- WITH ATTRIBUTE SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-hue))
-
- ub-hue INTEGER ::= 256
-
- An attribute type description consists of five fields, separated by
- blank lines. The keywords Attribute Type, Description, OCMust, OCMay
- and ASN1ATMacro, and their suffixed colons, must be included exactly
- as above.
-
- The Attribute Type field should be used for a textual description of
- the attribute type. This will be at most three or four words.
-
- The Description field should contain some explanatory text about the
- intended use of the attribute type. This can run to a number of
- lines.
-
- The OCMust field should contain a comma-separated list of object
- classes for which this attribute is mandatory.
-
- The OCMay field should contain a comma-separated list of object
- classes for which this attribute is optional.
-
- The ASN1ATMacro field should follow the definition of the attribute
- macro as specified in X.501. The above example shows some of the
- features. In particular, please note the format for specifying size
- constraints.
-
-5. Integrating groups of object classes and attribute types.
-
- This section describes two mechanisms that may be employed to allow
- the integration of a substantial number of new object classes and
- attribute types into the schema.
-
-
-
-
-Barker & Kille [Page 6]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- The first mechanism allows for the transition of groups of related,
- privately defined object classes and attribute types into the schema.
- An example of when such a transition might be appropriate is when
- some experimental use of the Directory is widely adopted within the
- pilot. Such a transition will be made if the following conditions
- hold:
-
- - The definitions are well structured: i.e., they are not
- scattered over a multiplicity of object identifier subtrees.
-
- - The definitions are in use at a number of sites, and having
- to adopt new object identifiers would be unnecessarily
- disruptive.
-
- A second mechanism allows for the allocation of an object subtree for
- a group of new definitions. A pilotGroups object identifier has been
- defined for this purpose. This method will be suitable for an
- experiment requiring a considerable number of new object identifiers
- to be defined. This approach allows for flexibility during
- experimentation and should simplify both the management and the
- coherence of the pilot's object identifiers.
-
- In both cases, the object classes, attribute types and syntaxes
- should be defined and described in an RFC. It is suggested that such
- documents should follow the style used in this document for object
- class and attribute type definitions. A reference will be given in
- this schema to the document containing the definitions.
-
-6. Removing "old" object classes and attribute types.
-
- It is also important that object classes and attribute types which
- are no longer used or useful are removed from the schema. Some
- object classes and attribute types initially defined as pilot
- extensions may be included as standard definitions in future versions
- of the standard. In such a case, it is important that there should
- be a fairly rapid transition to the standard definitions. Another
- possibility is that newer, more specific definitions obviate the
- original definitions.
-
- Two things are essential. First, it is crucial that "old"
- definitions are retired as gracefully as possible. The intention to
- retire a definition will be sent to the osi-ds@cs.ucl.ac.uk mail
- list. In the absence of objections, the definition will be marked
- for expiry with a given expiry date. The definition will remain in
- the schema until the expiry date. Users of the schema should ensure
- that they make the transition to new, alternative definitions in the
- interim.
-
-
-
-
-Barker & Kille [Page 7]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- Second, users of the schema must have the right to argue for the
- retention of definitions which they regard as necessary, there being
- no other definitions which closely meet their requirements. It is
- clearly impossible to lay down hard and fast rules on this point, as
- no two instances will ever be quite the same. It is intended that
- the refereeing on these matters will be sympathetic! As for requests
- for additions, an aggrieved user can "go to arbitration" by
- initiating a discussion on the osi-ds@cs.ucl.ac.uk mail list.
-
-7. Object Identifiers
-
- Some additional object identifiers are defined for this schema.
- These are also reproduced in Appendix C.
-
- data OBJECT IDENTIFIER ::= {ccitt 9}
- pss OBJECT IDENTIFIER ::= {data 2342}
- ucl OBJECT IDENTIFIER ::= {pss 19200300}
- pilot OBJECT IDENTIFIER ::= {ucl 100}
-
- pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
- pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
- pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
- pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
-
- iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
- caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
- {pilotAttributeSyntax 5}
-
-8. Object Classes
-
-8.1. X.500 standard object classes
-
- A number of generally useful object classes are defined in X.521, and
- these are supported. Refer to that document for descriptions of the
- suggested usage of these object classes. The ASN.1 for these object
- classes is reproduced for completeness in Appendix C.
-
-8.2. X.400 standard object classes
-
- A number of object classes defined in X.400 are supported. Refer to
- X.402 for descriptions of the usage of these object classes. The
- ASN.1 for these object classes is reproduced for completeness in
- Appendix C.
-
-8.3. COSINE/Internet object classes
-
- This section attempts to fuse together the object classes designed
- for use in the COSINE and Internet pilot activities. Descriptions
-
-
-
-Barker & Kille [Page 8]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- are given of the suggested usage of these object classes. The ASN.1
- for these object classes is also reproduced in Appendix C.
-
-8.3.1. Pilot Object
-
- The PilotObject object class is used as a sub-class to allow some
- common, useful attributes to be assigned to entries of all other
- object classes.
-
- pilotObject OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- info,
- photo,
- manager,
- uniqueIdentifier,
- lastModifiedTime,
- lastModifiedBy,
- dITRedirect,
- audio}
- ::= {pilotObjectClass 3}
-
-8.3.2. Pilot Person
-
- The PilotPerson object class is used as a sub-class of person, to
- allow the use of a number of additional attributes to be assigned to
- entries of object class person.
-
- pilotPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- userid,
- textEncodedORAddress,
- rfc822Mailbox,
- favouriteDrink,
- roomNumber,
- userClass,
- homeTelephoneNumber,
- homePostalAddress,
- secretary,
- personalTitle,
- preferredDeliveryMethod,
- businessCategory,
- janetMailbox,
- otherMailbox,
- mobileTelephoneNumber,
- pagerTelephoneNumber,
- organizationalStatus,
-
-
-
-Barker & Kille [Page 9]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mailPreferenceOption,
- personalSignature}
- ::= {pilotObjectClass 4}
-
-8.3.3. Account
-
- The Account object class is used to define entries representing
- computer accounts. The userid attribute should be used for naming
- entries of this object class.
-
- account OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userid}
- MAY CONTAIN {
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- host}
- ::= {pilotObjectClass 5}
-
-8.3.4. Document
-
- The Document object class is used to define entries which represent
- documents.
-
- document OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- documentIdentifier}
- MAY CONTAIN {
- commonName,
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- documentTitle,
- documentVersion,
- documentAuthor,
- documentLocation,
- documentPublisher}
- ::= {pilotObjectClass 6}
-
-
-
-
-
-
-Barker & Kille [Page 10]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-8.3.5. Room
-
- The Room object class is used to define entries representing rooms.
- The commonName attribute should be used for naming pentries of this
- object class.
-
- room OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- roomNumber,
- description,
- seeAlso,
- telephoneNumber}
- ::= {pilotObjectClass 7}
-
-8.3.6. Document Series
-
- The Document Series object class is used to define an entry which
- represents a series of documents (e.g., The Request For Comments
- papers).
-
- documentSeries OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- localityName,
- organizationName,
- organizationalUnitName}
- ::= {pilotObjectClass 9}
-
-8.3.7. Domain
-
- The Domain object class is used to define entries which represent DNS
- or NRS domains. The domainComponent attribute should be used for
- naming entries of this object class. The usage of this object class
- is described in more detail in [3].
-
- domain OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- domainComponent}
- MAY CONTAIN {
-
-
-
-Barker & Kille [Page 11]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- associatedName,
- organizationName,
- organizationalAttributeSet}
- ::= {pilotObjectClass 13}
-
-8.3.8. RFC822 Local Part
-
- The RFC822 Local Part object class is used to define entries which
- represent the local part of RFC822 mail addresses. This treats this
- part of an RFC822 address as a domain. The usage of this object
- class is described in more detail in [3].
-
- rFC822localPart OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- commonName,
- surname,
- description,
- seeAlso,
- telephoneNumber,
- postalAttributeSet,
- telecommunicationAttributeSet}
- ::= {pilotObjectClass 14}
-
-8.3.9. DNS Domain
-
- The DNS Domain (Domain NameServer) object class is used to define
- entries for DNS domains. The usage of this object class is described
- in more detail in [3].
-
- dNSDomain OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- ARecord,
- MDRecord,
- MXRecord,
- NSRecord,
- SOARecord,
- CNAMERecord}
- ::= {pilotObjectClass 15}
-
-8.3.10. Domain Related Object
-
- The Domain Related Object object class is used to define entries
- which represent DNS/NRS domains which are "equivalent" to an X.500
- domain: e.g., an organisation or organisational unit. The usage of
- this object class is described in more detail in [3].
-
-
-
-
-Barker & Kille [Page 12]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- domainRelatedObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- associatedDomain}
- ::= {pilotObjectClass 17}
-
-8.3.11. Friendly Country
-
- The Friendly Country object class is used to define country entries
- in the DIT. The object class is used to allow friendlier naming of
- countries than that allowed by the object class country. The naming
- attribute of object class country, countryName, has to be a 2 letter
- string defined in ISO 3166.
-
- friendlyCountry OBJECT-CLASS
- SUBCLASS OF country
- MUST CONTAIN {
- friendlyCountryName}
- ::= {pilotObjectClass 18}
-
-8.3.12. Simple Security Object
-
- The Simple Security Object object class is used to allow an entry to
- have a userPassword attribute when an entry's principal object
- classes do not allow userPassword as an attribute type.
-
- simpleSecurityObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userPassword }
- ::= {pilotObjectClass 19}
-
-8.3.13. Pilot Organization
-
- The PilotOrganization object class is used as a sub-class of
- organization and organizationalUnit to allow a number of additional
- attributes to be assigned to entries of object classes organization
- and organizationalUnit.
-
- pilotOrganization OBJECT-CLASS
- SUBCLASS OF organization, organizationalUnit
- MAY CONTAIN {
- buildingName}
- ::= {pilotObjectClass 20}
-
-
-
-
-
-
-
-Barker & Kille [Page 13]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-8.3.14. Pilot DSA
-
- The PilotDSA object class is used as a sub-class of the dsa object
- class to allow additional attributes to be assigned to entries for
- DSAs.
-
- pilotDSA OBJECT-CLASS
- SUBCLASS OF dsa
- MUST CONTAIN {
- dSAQuality}
- ::= {pilotObjectClass 21}
-
-8.3.15. Quality Labelled Data
-
- The Quality Labelled Data object class is used to allow the
- assignment of the data quality attributes to subtrees in the DIT.
-
- See [8] for more details.
-
- qualityLabelledData OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- dSAQuality}
- MAY CONTAIN {
- subtreeMinimumQuality,
- subtreeMaximumQuality}
- ::= {pilotObjectClass 22}
-
-9. Attribute Types
-
-9.1. X.500 standard attribute types
-
- A number of generally useful attribute types are defined in X.520,
- and these are supported. Refer to that document for descriptions of
- the suggested usage of these attribute types. The ASN.1 for these
- attribute types is reproduced for completeness in Appendix C.
-
-9.2. X.400 standard attribute types
-
- The standard X.400 attribute types are supported. See X.402 for full
- details. The ASN.1 for these attribute types is reproduced in
- Appendix C.
-
-9.3. COSINE/Internet attribute types
-
- This section describes all the attribute types defined for use in the
- COSINE and Internet pilots. Descriptions are given as to the
- suggested usage of these attribute types. The ASN.1 for these
-
-
-
-Barker & Kille [Page 14]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- attribute types is reproduced in Appendix C.
-
-9.3.1. Userid
-
- The Userid attribute type specifies a computer system login name.
-
- userid ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-identifier))
- ::= {pilotAttributeType 1}
-
-9.3.2. Text Encoded O/R Address
-
- The Text Encoded O/R Address attribute type specifies a text encoding
- of an X.400 O/R address, as specified in RFC 987. The use of this
- attribute is deprecated as the attribute is intended for interim use
- only. This attribute will be the first candidate for the attribute
- expiry mechanisms!
-
- textEncodedORAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-text-encoded-or-address))
- ::= {pilotAttributeType 2}
-
-9.3.3. RFC 822 Mailbox
-
- The RFC822 Mailbox attribute type specifies an electronic mailbox
- attribute following the syntax specified in RFC 822. Note that this
- attribute should not be used for greybook or other non-Internet order
- mailboxes.
-
- rfc822Mailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-rfc822-mailbox))
- ::= {pilotAttributeType 3}
-
-9.3.4. Information
-
- The Information attribute type specifies any general information
- pertinent to an object. It is recommended that specific usage of
- this attribute type is avoided, and that specific requirements are
- met by other (possibly additional) attribute types.
-
- info ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 15]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-information))
- ::= {pilotAttributeType 4}
-
-9.3.5. Favourite Drink
-
- The Favourite Drink attribute type specifies the favourite drink of
- an object (or person).
-
- favouriteDrink ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-favourite-drink))
- ::= {pilotAttributeType 5}
-
-9.3.6. Room Number
-
- The Room Number attribute type specifies the room number of an
- object. Note that the commonName attribute should be used for naming
- room objects.
-
- roomNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-room-number))
- ::= {pilotAttributeType 6}
-
-9.3.7. Photo
-
- The Photo attribute type specifies a "photograph" for an object.
- This should be encoded in G3 fax as explained in recommendation T.4,
- with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as
- defined in X.420.
-
- IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
- information-objects }
-
- photo ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-photo))
- ::= {pilotAttributeType 7}
-
-
-
-
-
-
-
-Barker & Kille [Page 16]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.8. User Class
-
- The User Class attribute type specifies a category of computer user.
- The semantics placed on this attribute are for local interpretation.
- Examples of current usage od this attribute in academia are
- undergraduate student, researcher, lecturer, etc. Note that the
- organizationalStatus attribute may now often be preferred as it makes
- no distinction between computer users and others.
-
- userClass ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-class))
- ::= {pilotAttributeType 8}
-
-9.3.9. Host
-
- The Host attribute type specifies a host computer.
-
- host ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-host))
- ::= {pilotAttributeType 9}
-
-9.3.10. Manager
-
- The Manager attribute type specifies the manager of an object
- represented by an entry.
-
- manager ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 10}
-
-9.3.11. Document Identifier
-
- The Document Identifier attribute type specifies a unique identifier
- for a document.
-
- documentIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-identifier))
- ::= {pilotAttributeType 11}
-
-
-
-
-
-
-Barker & Kille [Page 17]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.12. Document Title
-
- The Document Title attribute type specifies the title of a document.
-
- documentTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-title))
- ::= {pilotAttributeType 12}
-
-9.3.13. Document Version
-
- The Document Version attribute type specifies the version number of a
- document.
-
- documentVersion ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-version))
- ::= {pilotAttributeType 13}
-
-9.3.14. Document Author
-
- The Document Author attribute type specifies the distinguished name
- of the author of a document.
-
- documentAuthor ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 14}
-
-9.3.15. Document Location
-
- The Document Location attribute type specifies the location of the
- document original.
-
- documentLocation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-location))
- ::= {pilotAttributeType 15}
-
-9.3.16. Home Telephone Number
-
- The Home Telephone Number attribute type specifies a home telephone
- number associated with a person. Attribute values should follow the
- agreed format for international telephone numbers: i.e., "+44 71 123
- 4567".
-
-
-
-Barker & Kille [Page 18]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- homeTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 20}
-
-9.3.17. Secretary
-
- The Secretary attribute type specifies the secretary of a person.
- The attribute value for Secretary is a distinguished name.
-
- secretary ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 21}
-
-9.3.18. Other Mailbox
-
- The Other Mailbox attribute type specifies values for electronic
- mailbox types other than X.400 and rfc822.
-
- otherMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- SEQUENCE {
- mailboxType PrintableString, -- e.g. Telemail
- mailbox IA5String -- e.g. X378:Joe
- }
- ::= {pilotAttributeType 22}
-
-9.3.19. Last Modified Time
-
- The Last Modified Time attribute type specifies the last time, in UTC
- time, that an entry was modified. Ideally, this attribute should be
- maintained by the DSA.
-
- lastModifiedTime ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- uTCTimeSyntax
- ::= {pilotAttributeType 23}
-
-9.3.20. Last Modified By
-
- The Last Modified By attribute specifies the distinguished name of
- the last user to modify the associated entry. Ideally, this
- attribute should be maintained by the DSA.
-
- lastModifiedBy ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
-
-
-
-Barker & Kille [Page 19]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 24}
-
-9.3.21. Domain Component
-
- The Domain Component attribute type specifies a DNS/NRS domain. For
- example, "uk" or "ac".
-
- domainComponent ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- SINGLE VALUE
- ::= {pilotAttributeType 25}
-
- 9.3.22. DNS ARecord
-
- The A Record attribute type specifies a type A (Address) DNS resource
- record [6] [7].
-
- aRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 26}
-
-9.3.23. MX Record
-
- The MX Record attribute type specifies a type MX (Mail Exchange) DNS
- resource record [6] [7].
-
- mXRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 28}
-
-9.3.24. NS Record
-
- The NS Record attribute type specifies an NS (Name Server) DNS
- resource record [6] [7].
-
- nSRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 29}
-
-9.3.25. SOA Record
-
- The SOA Record attribute type specifies a type SOA (Start of
- Authority) DNS resorce record [6] [7].
-
-
-
-
-Barker & Kille [Page 20]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- sOARecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 30}
-
-9.3.26. CNAME Record
-
- The CNAME Record attribute type specifies a type CNAME (Canonical
- Name) DNS resource record [6] [7].
-
- cNAMERecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- iA5StringSyntax
- ::= {pilotAttributeType 31}
-
-9.3.27. Associated Domain
-
- The Associated Domain attribute type specifies a DNS or NRS domain
- which is associated with an object in the DIT. For example, the entry
- in the DIT with a distinguished name "C=GB, O=University College
- London" would have an associated domain of "UCL.AC.UK. Note that all
- domains should be represented in rfc822 order. See [3] for more
- details of usage of this attribute.
-
- associatedDomain ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- ::= {pilotAttributeType 37}
-
-9.3.28. Associated Name
-
- The Associated Name attribute type specifies an entry in the
- organisational DIT associated with a DNS/NRS domain. See [3] for
- more details of usage of this attribute.
-
- associatedName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 38}
-
-9.3.29. Home postal address
-
- The Home postal address attribute type specifies a home postal
- address for an object. This should be limited to up to 6 lines of 30
- characters each.
-
- homePostalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 21]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- postalAddress
- MATCHES FOR EQUALITY
- ::= {pilotAttributeType 39}
-
-9.3.30. Personal Title
-
- The Personal Title attribute type specifies a personal title for a
- person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev".
-
- personalTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-personal-title))
- ::= {pilotAttributeType 40}
-
-9.3.31. Mobile Telephone Number
-
- The Mobile Telephone Number attribute type specifies a mobile
- telephone number associated with a person. Attribute values should
- follow the agreed format for international telephone numbers: i.e.,
- "+44 71 123 4567".
-
- mobileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 41}
-
-9.3.32. Pager Telephone Number
-
- The Pager Telephone Number attribute type specifies a pager telephone
- number for an object. Attribute values should follow the agreed
- format for international telephone numbers: i.e., "+44 71 123 4567".
-
- pagerTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 42}
-
-9.3.33. Friendly Country Name
-
- The Friendly Country Name attribute type specifies names of countries
- in human readable format. The standard attribute country name must
- be one of the two-letter codes defined in ISO 3166.
-
- friendlyCountryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- ::= {pilotAttributeType 43}
-
-
-
-Barker & Kille [Page 22]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.34. Unique Identifier
-
- The Unique Identifier attribute type specifies a "unique identifier"
- for an object represented in the Directory. The domain within which
- the identifier is unique, and the exact semantics of the identifier,
- are for local definition. For a person, this might be an
- institution-wide payroll number. For an organisational unit, it
- might be a department code.
-
- uniqueIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-unique-identifier))
- ::= {pilotAttributeType 44}
-
-9.3.35. Organisational Status
-
- The Organisational Status attribute type specifies a category by
- which a person is often referred to in an organisation. Examples of
- usage in academia might include undergraduate student, researcher,
- lecturer, etc.
-
- A Directory administrator should probably consider carefully the
- distinctions between this and the title and userClass attributes.
-
- organizationalStatus ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-organizational-status))
- ::= {pilotAttributeType 45}
-
-9.3.36. Janet Mailbox
-
- The Janet Mailbox attribute type specifies an electronic mailbox
- attribute following the syntax specified in the Grey Book of the
- Coloured Book series. This attribute is intended for the convenience
- of U.K users unfamiliar with rfc822 and little-endian mail addresses.
- Entries using this attribute MUST also include an rfc822Mailbox
- attribute.
-
- janetMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-janet-mailbox))
- ::= {pilotAttributeType 46}
-
-
-
-
-
-
-Barker & Kille [Page 23]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.37. Mail Preference Option
-
- An attribute to allow users to indicate a preference for inclusion of
- their names on mailing lists (electronic or physical). The absence
- of such an attribute should be interpreted as if the attribute was
- present with value "no-list-inclusion". This attribute should be
- interpreted by anyone using the directory to derive mailing lists,
- and its value respected.
-
- mailPreferenceOption ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX ENUMERATED {
- no-list-inclusion(0),
- any-list-inclusion(1), -- may be added to any lists
- professional-list-inclusion(2)
- -- may be added to lists
- -- which the list provider
- -- views as related to the
- -- users professional inter-
- -- ests, perhaps evaluated
- -- from the business of the
- -- organisation or keywords
- -- in the entry.
- }
- ::= {pilotAttributeType 47}
-
-9.3.38. Building Name
-
- The Building Name attribute type specifies the name of the building
- where an organisation or organisational unit is based.
-
- buildingName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-building-name))
- ::= {pilotAttributeType 48}
-
-9.3.39. DSA Quality
-
- The DSA Quality attribute type specifies the purported quality of a
- DSA. It allows a DSA manager to indicate the expected level of
- availability of the DSA. See [8] for details of the syntax.
-
- dSAQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 49}
-
-
-
-
-
-Barker & Kille [Page 24]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.40. Single Level Quality
-
- The Single Level Quality attribute type specifies the purported data
- quality at the level immediately below in the DIT. See [8] for
- details of the syntax.
-
- singleLevelQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 50}
-
-9.3.41. Subtree Minimum Quality
-
- The Subtree Minimum Quality attribute type specifies the purported
- minimum data quality for a DIT subtree. See [8] for more discussion
- and details of the syntax.
-
- subtreeMinimumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 51}
-
-9.3.42. Subtree Maximum Quality
-
- The Subtree Maximum Quality attribute type specifies the purported
- maximum data quality for a DIT subtree. See [8] for more discussion
- and details of the syntax.
-
- subtreeMaximumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 52}
-
-9.3.43. Personal Signature
-
- The Personal Signature attribute type allows for a representation of
- a person's signature. This should be encoded in G3 fax as explained
- in recommendation T.4, with an ASN.1 wrapper to make it compatible
- with an X.400 BodyPart as defined in X.420.
-
- IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
- information-objects }
-
- personalSignature ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
-
-
-
-Barker & Kille [Page 25]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-personal-signature))
- ::= {pilotAttributeType 53}
-
-9.3.44. DIT Redirect
-
- The DIT Redirect attribute type is used to indicate that the object
- described by one entry now has a newer entry in the DIT. The entry
- containing the redirection attribute should be expired after a
- suitable grace period. This attribute may be used when an individual
- changes his/her place of work, and thus acquires a new organisational
- DN.
-
- dITRedirect ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 54}
-
-9.3.45. Audio
-
- The Audio attribute type allows the storing of sounds in the
- Directory. The attribute uses a u-law encoded sound file as used by
- the "play" utility on a Sun 4. This is an interim format.
-
- audio ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- Audio
- (SIZE (1 .. ub-audio))
- ::= {pilotAttributeType 55}
-
-9.3.46. Publisher of Document
-
-
- The Publisher of Document attribute is the person and/or organization
- that published a document.
-
- documentPublisher ATTRIBUTE
- WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
- ::= {pilotAttributeType 56}
-
-9.4. Generally useful syntaxes
-
- caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
-
-
-
-Barker & Kille [Page 26]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- iA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- -- Syntaxes to support the DNS attributes
-
- DNSRecordSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY
-
-
- NRSInformationSyntax ATTRIBUTE-SYNTAX
- NRSInformation
- MATCHES FOR EQUALITY
-
-
- NRSInformation ::= SET {
- [0] Context,
- [1] Address-space-id,
- routes [2] SEQUENCE OF SEQUENCE {
- Route-cost,
- Addressing-info }
- }
-
-
-9.5. Upper bounds on length of attribute values
-
-
- ub-document-identifier INTEGER ::= 256
-
- ub-document-location INTEGER ::= 256
-
- ub-document-title INTEGER ::= 256
-
- ub-document-version INTEGER ::= 256
-
- ub-favourite-drink INTEGER ::= 256
-
- ub-host INTEGER ::= 256
-
- ub-information INTEGER ::= 2048
-
- ub-unique-identifier INTEGER ::= 256
-
- ub-personal-title INTEGER ::= 256
-
- ub-photo INTEGER ::= 250000
-
-
-
-Barker & Kille [Page 27]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ub-rfc822-mailbox INTEGER ::= 256
-
- ub-room-number INTEGER ::= 256
-
- ub-text-or-address INTEGER ::= 256
-
- ub-user-class INTEGER ::= 256
-
- ub-user-identifier INTEGER ::= 256
-
- ub-organizational-status INTEGER ::= 256
-
- ub-janet-mailbox INTEGER ::= 256
-
- ub-building-name INTEGER ::= 256
-
- ub-personal-signature ::= 50000
-
- ub-audio INTEGER ::= 250000
-
-References
-
- [1] CCITT/ISO, "X.500, The Directory - overview of concepts,
- models and services, CCITT /ISO IS 9594.
-
- [2] Kille, S., "The THORN and RARE X.500 Naming Architecture, in
- University College London, Department of Computer Science
- Research Note 89/48, May 1989.
-
- [3] Kille, S., "X.500 and Domains", RFC 1279, University College
- London, November 1991.
-
- [4] Rose, M., "PSI/NYSERNet White Pages Pilot Project: Status
- Report", Technical Report 90-09-10-1, published by NYSERNet
- Inc, 1990.
-
- [5] Craigie, J., "UK Academic Community Directory Service Pilot
- Project, pp. 305-310 in Computer Networks and ISDN Systems
- 17 (1989), published by North Holland.
-
- [6] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [7] Mockapetris, P., "Domain Names - Implementation and
- Specification, RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [8] Kille, S., "Handling QOS (Quality of service) in the
-
-
-
-Barker & Kille [Page 28]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- Directory," publication in process, March 1991.
-
-APPENDIX A - Object Class and Attribute Type proformas
-
- These are specified in BNF. First some useful definitions, common to
- both proformas.
-
- EOL ::= -- the end of line character(s)
-
- BlankLine ::= -- a line consisting solely of an EOL character
-
- String ::= <anychar> | <String> <anychar>
-
- anychar ::= --any character occurring in general text, excluding
- -- the end of line character
-
- lString ::= <lowercase> <otherstring>
-
- lowercase ::= [a-z]
-
- UString ::= <uppercase> <otherstring>
-
- uppercase ::= [A-Z]
-
- otherstring ::= <otherchar> | <otherstring> <otherchar>
-
- otherchar ::= <lowercase> | <uppercase> | <digit>
-
- Integer ::= <digit> | <Integer> <digit>
-
- digit ::= [0-9]
-
-1. Object Class
-
-
- OCProforma ::= <ObjectClassName> <BlankLine> <Description> \
- <BlankLine> <OCMacro>
-
- ObjectClassName ::= "ObjectClass:" <String> <EOL>
-
- Description ::= "Description:" <DescriptiveText> <EOL>
-
- DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
-
- OCMacro ::= "ASN1OCMacro:" <ObjectClassMacro>
-
- -- The definition of ObjectClassMacro is adapted from
- -- that given in X.501
-
-
-
-Barker & Kille [Page 29]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ObjectClassMacro ::= <OCname> "OBJECT-CLASS" <SubclassOf> \
- <MandatoryAttributes> <OptionalAttributes>
-
- OCName ::= <lString>
-
- SubclassOf ::= "SUBCLASS OF" Subclasses | <empty>
-
- Subclasses ::= <Subclass> | <Subclass> "," <Subclasses>
-
- Subclass ::= <OCName>
-
- MandatoryAttributes ::= "MUST CONTAIN {" <Attributes> "}" \
- | <empty>
- OptionalAttributes ::= "MAY CONTAIN {" <Attributes> "}" | <empty>
-
- Attributes ::= <AttributeTerm> | <AttributeTerm> "," <Attributes>
-
- AttributeTerm ::= <Attribute> | <AttributeSet>
-
- Attribute ::= <lString>
-
- AttributeSet ::= <lString>
-
-2. Attribute Type
-
-
- ATProforma ::= <AttributeTypeName> <BlankLine> <Description> \
- <BlankLine> <OCMust> <Blankline> <OCMay> \
- <BlankLine> <ATMacro>
-
- AttributeTypeName ::= "Attribute Type:" <String> <EOL>
-
- Description ::= "Description:" <DescriptiveText> <EOL>
-
- DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
-
- OCMust ::= "OCMust:" <OCList> <EOL>
-
- OCList ::= <OCName> | <OCList> "," <OCName> | <empty>
-
- OCMay ::= "OCMay:" <OCList> <EOL>
-
- ATMacro ::= "ASN1ATMacro:" <AttributeTypeMacro>
-
- -- The definition of AttributeTypeMacro is adapted from that
- -- given in X.501
-
- AttributeTypeMacro ::= <ATname> "ATTRIBUTE" <AttributeSyntax> \
-
-
-
-Barker & Kille [Page 30]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- <Multivalued> | <empty>
-
- ATName ::= <lString>
-
- AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice
-
- SyntaxChoice ::= <Syntax> <Constraint> | <ASN1Type> <MatchTypes>
-
- Syntax ::= <lString>
-
- Constraint ::= "(" ConstraintAlternative ")" | <empty>
-
- ConstraintAlternative ::= StringConstraint | IntegerConstraint
-
- StringConstraint ::= "SIZE" "(" SizeConstraint ")"
-
- SizeConstraint ::= SingleValue | Range
-
- SingleValue ::= <Integer>
-
- Range ::= <Integer> ".." <Integer>
-
- IntegerConstraint ::= Range
-
- ASN1Type ::= <UString>
- -- one of ASN.1's base types: e.g. PrintableString,
- -- NumericString, etc.
-
- MatchTypes ::= "MATCHES FOR" Matches | <empty>
-
- Matches ::= Match | Matches Match
-
- Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING"
-
- Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | <empty>
-
-APPENDIX B - Format checking tools
-
- This section includes the source for format checking tools for the
- two proformas. The tools are written as Bourne shell scripts for
- UNIX systems.
-
-1. Object class format checker
-
-
- sed 's/ *: */:/' |
- awk '
- BEGIN {
-
-
-
-Barker & Kille [Page 31]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- state = "initial"
- }
-
- /^$/ {
- next
- }
-
- /^Object Class:/ {
- n = index($0, ":")
- if (state != "initial")
- {
- print "Already got object class " oc
- print "Got another object class " substr($0, n+1)
- state = "notOK"
- exit 1
- }
- oc = substr($0, n+1)
- state = "gotOC"
- next
- }
-
- /^Description:/ {
- n = index($0, ":")
- if (state != "gotOC")
- {
- print "Got Description: " substr($0, n+1)
- for (i = 0; i < 2 && getline > 0; i++)
- print $0
- print "..."
- if (state == "initial")
- print "Expecting Object Class:"
- else
- print "Expecting ASN1OCMacro:"
- state = "notOK"
- exit 1
- }
- while (getline > 0)
- if (length($0) > 0)
- continue
- else
- break
- state = "gotDesc"
- next
- }
-
- /^ASN1OCMacro:/ {
- n = index($0, ":")
- if (state != "gotDesc")
-
-
-
-Barker & Kille [Page 32]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- {
- print "Got ASN1Macro: " substr($0, n+1)
- for (i = 0; i < 2 && getline > 0; i++)
- print $0
- print "..."
- if (state == "initial")
- print "Expecting Object Class:"
- else
- print "Expecting Description:"
- state = "notOK"
- exit 1
- }
- state = "OK"
- exit 0
- }
-
- {
- print "Parsing has got confused on seeing line: " $0
- state = "notOK"
- exit 1
- }
-
- END {
- if (state == "OK")
- print "Input looks OK"
- }
-
-
-2. Attribute Type format checker
-
-
- sed 's/ *: */:/' |
- awk '
- BEGIN {
- state = "initial"
- }
-
- /^$/ {
- next
- }
-
- /^Attribute Type:/ {
- n = index($0, ":")
- if (state != "initial")
- {
- got = "Attribute Type:"
- exit 1
- }
-
-
-
-Barker & Kille [Page 33]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- state = "gotAT"
- next
- }
-
- /^Description:/ {
- n = index($0, ":")
- if (state != "gotAT")
- {
- got = "Description:"
- exit 1
- }
- while (getline > 0)
- if (length($0) > 0)
- continue
- else
- break
- state = "gotDesc"
- next
- }
-
- /^OCMust:/ {
- n = index($0, ":")
- if (state != "gotDesc")
- {
- got = "OCMust:"
- exit 1
- }
- state = "gotOCMust"
- next
- }
-
- /^OCMay:/ {
- n = index($0, ":")
- if (state != "gotOCMust")
- {
- got = "OCMay:"
- exit 1
- }
- state = "gotOCMay"
- next
- }
-
- /^ASN1ATMacro:/ {
- n = index($0, ":")
- if (state != "gotOCMay")
- {
- got = "ASN1ATMacro:"
- exit 1
-
-
-
-Barker & Kille [Page 34]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- }
- state = "OK"
- exit 0
- }
-
- {
- print "Parsing has got confused on seeing line: " $0
- state = "notOK"
- exit 1
- }
-
- END {
- if (state == "initial")
- print "Expecting Attribute Type:"
- else if (state == "gotAT")
- print "Expecting Description:"
- else if (state == "gotDesc")
- print "Expecting OCMust:"
- else if (state == "gotOCMust")
- print "Expecting OCMay:"
- else if (state == "gotOCMay")
- print "Expecting ASN1ATMacro:"
- if (state != "OK")
- print "Got " got
- else
- print "Input looks OK"
- }
-
-
-APPENDIX C - Summary of all Object Classes and Attribute Types
-
- -- Some Important Object Identifiers
-
- data OBJECT IDENTIFIER ::= {ccitt 9}
- pss OBJECT IDENTIFIER ::= {data 2342}
- ucl OBJECT IDENTIFIER ::= {pss 19200300}
- pilot OBJECT IDENTIFIER ::= {ucl 100}
-
- pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
- pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
- pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
- pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
-
- iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
- caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
- {pilotAttributeSyntax 5}
-
-
-
-
-
-Barker & Kille [Page 35]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Standard Object Classes
-
- top OBJECT-CLASS
- MUST CONTAIN {
- objectClass}
- ::= {objectClass 0}
-
-
- alias OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- aliasedObjectName}
- ::= {objectClass 1}
-
-
- country OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- countryName}
- MAY CONTAIN {
- description,
- searchGuide}
- ::= {objectClass 2}
-
-
- locality OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- description,
- localityName,
- stateOrProvinceName,
- searchGuide,
- seeAlso,
- streetAddress}
- ::= {objectClass 3}
-
-
- organization OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- organizationName}
- MAY CONTAIN {
- organizationalAttributeSet}
- ::= {objectClass 4}
-
-
-
-
-
-
-
-Barker & Kille [Page 36]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationalUnit OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- organizationalUnitName}
- MAY CONTAIN {
- organizationalAttributeSet}
- ::= {objectClass 5}
-
-
- person OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- surname}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- userPassword}
- ::= {objectClass 6}
-
-
- organizationalPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- localeAttributeSet,
- organizationalUnitName,
- postalAttributeSet,
- telecommunicationAttributeSet,
- title}
- ::= {objectClass 7}
-
-
- organizationalRole OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localeAttributeSet,
- organizationalUnitName,
- postalAttributeSet,
- preferredDeliveryMethod,
- roleOccupant,
- seeAlso,
- telecommunicationAttributeSet}
- ::= {objectClass 8}
-
-
-
-
-Barker & Kille [Page 37]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- groupOfNames OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- member}
- MAY CONTAIN {
- description,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- businessCategory}
- ::= {objectClass 9}
-
-
- residentialPerson OBJECT-CLASS
- SUBCLASS OF person
- MUST CONTAIN {
- localityName}
- MAY CONTAIN {
- localeAttributeSet,
- postalAttributeSet,
- preferredDeliveryMethod,
- telecommunicationAttributeSet,
- businessCategory}
- ::= {objectClass 10}
-
-
- applicationProcess OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localityName,
- organizationalUnitName,
- seeAlso}
- ::= {objectClass 11}
-
-
- applicationEntity OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- presentationAddress}
- MAY CONTAIN {
- description,
- localityName,
-
-
-
-Barker & Kille [Page 38]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationName,
- organizationalUnitName,
- seeAlso,
- supportedApplicationContext}
- ::= {objectClass 12}
-
-
- dSA OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- knowledgeInformation}
- ::= {objectClass 13}
-
-
- device OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localityName,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- serialNumber}
- ::= {objectClass 14}
-
-
- strongAuthenticationUser OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userCertificate}
- ::= {objectClass 15}
-
-
- certificationAuthority OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- cACertificate,
- certificateRevocationList,
- authorityRevocationList}
- MAY CONTAIN {
- crossCertificatePair}
- ::= {objectClass 16}
-
-
-
-
-
-
-Barker & Kille [Page 39]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Standard MHS Object Classes
-
- mhsDistributionList OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- mhsDLSubmitPermissions,
- mhsORAddresses}
- MAY CONTAIN {
- description,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- mhsDeliverableContentTypes,
- mhsdeliverableEits,
- mhsDLMembers,
- mhsPreferredDeliveryMethods}
- ::= {mhsObjectClass 0}
-
-
- mhsMessageStore OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- description,
- owner,
- mhsSupportedOptionalAttributes,
- mhsSupportedAutomaticActions,
- mhsSupportedContentTypes}
- ::= {mhsObjectClass 1}
-
-
- mhsMessageTransferAgent OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- description,
- owner,
- mhsDeliverableContentLength}
- ::= {mhsObjectClass 2}
-
-
- mhsOrganizationalUser OBJECT-CLASS
- SUBCLASS OF organizationalPerson
- MUST CONTAIN {
- mhsORAddresses}
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
-
-
-
-Barker & Kille [Page 40]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mhsDeliverableEits,
- mhsMessageStoreName,
- mhsPreferredDeliveryMethods }
- ::= {mhsObjectClass 3}
-
-
- mhsResidentialUser OBJECT-CLASS
- SUBCLASS OF residentialPerson
- MUST CONTAIN {
- mhsORAddresses}
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
- mhsDeliverableEits,
- mhsMessageStoreName,
- mhsPreferredDeliveryMethods }
- ::= {mhsObjectClass 4}
-
-
- mhsUserAgent OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
- mhsDeliverableEits,
- mhsORAddresses,
- owner}
- ::= {mhsObjectClass 5}
-
-
-
-
- -- Pilot Object Classes
-
- pilotObject OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- info,
- photo,
- manager,
- uniqueIdentifier,
- lastModifiedTime,
- lastModifiedBy,
- dITRedirect,
- audio}
- ::= {pilotObjectClass 3}
-
-
-
-
-
-Barker & Kille [Page 41]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- pilotPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- userid,
- textEncodedORAddress,
- rfc822Mailbox,
- favouriteDrink,
- roomNumber,
- userClass,
- homeTelephoneNumber,
- homePostalAddress,
- secretary,
- personalTitle,
- preferredDeliveryMethod,
- businessCategory,
- janetMailbox,
- otherMailbox,
- mobileTelephoneNumber,
- pagerTelephoneNumber,
- organizationalStatus,
- mailPreferenceOption,
- personalSignature}
- ::= {pilotObjectClass 4}
-
-
- account OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userid}
- MAY CONTAIN {
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- host}
- ::= {pilotObjectClass 5}
-
-
- document OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- documentIdentifier}
- MAY CONTAIN {
- commonName,
- description,
- seeAlso,
- localityName,
-
-
-
-Barker & Kille [Page 42]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationName,
- organizationalUnitName,
- documentTitle,
- documentVersion,
- documentAuthor,
- documentLocation,
- documentPublisher}
- ::= {pilotObjectClass 6}
-
-
- room OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- roomNumber,
- description,
- seeAlso,
- telephoneNumber}
- ::= {pilotObjectClass 7}
-
-
- documentSeries OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- localityName,
- organizationName,
- organizationalUnitName}
- ::= {pilotObjectClass 9}
-
-
- domain OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- domainComponent}
- MAY CONTAIN {
- associatedName,
- organizationName,
- organizationalAttributeSet}
- ::= {pilotObjectClass 13}
-
-
-
-
-
-
-Barker & Kille [Page 43]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- rFC822localPart OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- commonName,
- surname,
- description,
- seeAlso,
- telephoneNumber,
- postalAttributeSet,
- telecommunicationAttributeSet}
- ::= {pilotObjectClass 14}
-
-
- dNSDomain OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- ARecord,
- MDRecord,
- MXRecord,
- NSRecord,
- SOARecord,
- CNAMERecord}
- ::= {pilotObjectClass 15}
-
-
- domainRelatedObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- associatedDomain}
- ::= {pilotObjectClass 17}
-
-
- friendlyCountry OBJECT-CLASS
- SUBCLASS OF country
- MUST CONTAIN {
- friendlyCountryName}
- ::= {pilotObjectClass 18}
-
-
- simpleSecurityObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userPassword }
- ::= {pilotObjectClass 19}
-
-
- pilotOrganization OBJECT-CLASS
- SUBCLASS OF organization, organizationalUnit
-
-
-
-Barker & Kille [Page 44]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- MAY CONTAIN {
- buildingName}
- ::= {pilotObjectClass 20}
-
-
- pilotDSA OBJECT-CLASS
- SUBCLASS OF dsa
- MUST CONTAIN {
- dSAQuality}
- ::= {pilotObjectClass 21}
-
-
- qualityLabelledData OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- dSAQuality}
- MAY CONTAIN {
- subtreeMinimumQuality,
- subtreeMaximumQuality}
- ::= {pilotObjectClass 22}
-
-
-
-
- -- Standard Attribute Types
-
- objectClass ObjectClass
- ::= {attributeType 0}
-
-
- aliasedObjectName AliasedObjectName
- ::= {attributeType 1}
-
-
- knowledgeInformation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreString
- ::= {attributeType 2}
-
-
- commonName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-common-name))
- ::= {attributeType 3}
-
-
- surname ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-surname))
-
-
-
-Barker & Kille [Page 45]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 4}
-
-
- serialNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX printableStringSyntax
- (SIZE (1..ub-serial-number))
- ::= {attributeType 5}
-
-
- countryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PrintableString
- (SIZE (1..ub-country-code))
- SINGLE VALUE
- ::= {attributeType 6}
-
-
- localityName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-locality-name))
- ::= {attributeType 7}
-
-
- stateOrProvinceName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-state-name))
- ::= {attributeType 8}
-
-
- streetAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-street-address))
- ::= {attributeType 9}
-
-
- organizationName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-organization-name))
- ::= {attributeType 10}
-
-
- organizationalUnitName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-organizational-unit-name))
- ::= {attributeType 11}
-
-
- title ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
-
-
-
-Barker & Kille [Page 46]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- (SIZE (1..ub-title))
- ::= {attributeType 12}
-
-
- description ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-description))
- ::= {attributeType 13}
-
-
- searchGuide ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX Guide
- ::= {attributeType 14}
-
-
- businessCategory ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-business-category))
- ::= {attributeType 15}
-
-
- postalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PostalAddress
- MATCHES FOR EQUALITY
- ::= {attributeType 16}
-
-
- postalCode ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-postal-code))
- ::= {attributeType 17}
-
-
- postOfficeBox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-post-office-box))
- ::= {attributeType 18}
-
-
- physicalDeliveryOfficeName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-physical-office-name))
- ::= {attributeType 19}
-
-
- telephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax
- (SIZE (1..ub-telephone-number))
-
-
-
-Barker & Kille [Page 47]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 20}
-
-
- telexNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX TelexNumber
- (SIZE (1..ub-telex))
- ::= {attributeType 21}
-
-
- teletexTerminalIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier
- (SIZE (1..ub-teletex-terminal-id))
- ::= {attributeType 22}
-
-
- facsimileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber
- ::= {attributeType 23}
-
-
- x121Address ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX NumericString
- (SIZE (1..ub-x121-address))
- ::= {attributeType 24}
-
-
- internationaliSDNNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX NumericString
- (SIZE (1..ub-isdn-address))
- ::= {attributeType 25}
-
-
- registeredAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PostalAddress
- ::= {attributeType 26}
-
-
- destinationIndicator ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PrintableString
- (SIZE (1..ub-destination-indicator))
- MATCHES FOR EQUALITY SUBSTRINGS
- ::= {attributeType 27}
-
-
- preferredDeliveryMethod ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX deliveryMethod
- ::= {attributeType 28}
-
-
-
-
-Barker & Kille [Page 48]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- presentationAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PresentationAddress
- MATCHES FOR EQUALITY
- ::= {attributeType 29}
-
-
- supportedApplicationContext ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
- ::= {attributeType 30}
-
-
- member ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 31}
-
-
- owner ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 32}
-
-
- roleOccupant ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 33}
-
-
- seeAlso ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 34}
-
-
- userPassword ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX Userpassword
- ::= {attributeType 35}
-
-
- userCertificate ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX UserCertificate
- ::= {attributeType 36}
-
-
- cACertificate ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX cACertificate
- ::= {attributeType 37}
-
-
- authorityRevocationList ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX AuthorityRevocationList
-
-
-
-Barker & Kille [Page 49]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 38}
-
-
- certificateRevocationList ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX CertificateRevocationList
- ::= {attributeType 39}
-
-
- crossCertificatePair ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX CrossCertificatePair
- ::= {attributeType 40}
-
-
-
-
- -- Standard MHS Attribute Types
-
- mhsDeliverableContentLength ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX integer
- ::= {mhsAttributeType 0}
-
-
- mhsDeliverableContentTypes ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 1}
-
-
- mhsDeliverableEits ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 2}
-
-
- mhsDLMembers ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oRName
- ::= {mhsAttributeType 3}
-
-
- mhsDLSubmitPermissions ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX dLSubmitPermission
- ::= {mhsAttributeType 4}
-
-
- mhsMessageStoreName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX dN
- ::= {mhsAttributeType 5}
-
-
-
-
-
-
-Barker & Kille [Page 50]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mhsORAddresses ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oRAddress
- ::= {mhsAttributeType 6}
-
-
- mhsPreferredDeliveryMethods ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX deliveryMethod
- ::= {mhsAttributeType 7}
-
-
- mhsSupportedAutomaticActions ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 8}
-
-
- mhsSupportedContentTypes ATTRIBUTE
-
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 9}
-
-
- mhsSupportedOptionalAttributes ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 10}
-
-
-
-
- -- Pilot Attribute Types
-
- userid ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-identifier))
- ::= {pilotAttributeType 1}
-
-
- textEncodedORAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-text-encoded-or-address))
- ::= {pilotAttributeType 2}
-
-
- rfc822Mailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-rfc822-mailbox))
-
-
-
-Barker & Kille [Page 51]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 3}
-
-
- info ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-information))
- ::= {pilotAttributeType 4}
-
-
- favouriteDrink ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-favourite-drink))
- ::= {pilotAttributeType 5}
-
-
- roomNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-room-number))
- ::= {pilotAttributeType 6}
-
-
- photo ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-photo))
- ::= {pilotAttributeType 7}
-
-
- userClass ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-class))
- ::= {pilotAttributeType 8}
-
-
- host ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-host))
- ::= {pilotAttributeType 9}
-
-
-
-
-
-
-Barker & Kille [Page 52]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- manager ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 10}
-
-
- documentIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-identifier))
- ::= {pilotAttributeType 11}
-
-
- documentTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-title))
- ::= {pilotAttributeType 12}
-
-
- documentVersion ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-version))
- ::= {pilotAttributeType 13}
-
-
- documentAuthor ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 14}
-
-
- documentLocation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-location))
- ::= {pilotAttributeType 15}
-
-
- homeTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 20}
-
-
- secretary ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 53]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- distinguishedNameSyntax
- ::= {pilotAttributeType 21}
-
-
- otherMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- SEQUENCE {
- mailboxType PrintableString, -- e.g. Telemail
- mailbox IA5String -- e.g. X378:Joe
- }
- ::= {pilotAttributeType 22}
-
-
- lastModifiedTime ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- uTCTimeSyntax
- ::= {pilotAttributeType 23}
-
-
- lastModifiedBy ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 24}
-
-
- domainComponent ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- SINGLE VALUE
- ::= {pilotAttributeType 25}
-
-
- aRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 26}
-
-
- mXRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 28}
-
-
- nSRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 29}
-
-
-
-Barker & Kille [Page 54]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- sOARecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 30}
-
-
- cNAMERecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- iA5StringSyntax
- ::= {pilotAttributeType 31}
-
-
- associatedDomain ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- ::= {pilotAttributeType 37}
-
-
- associatedName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 38}
-
-
- homePostalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- postalAddress
- MATCHES FOR EQUALITY
- ::= {pilotAttributeType 39}
-
-
- personalTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-personal-title))
- ::= {pilotAttributeType 40}
-
-
- mobileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 41}
-
-
- pagerTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 42}
-
-
-
-Barker & Kille [Page 55]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- friendlyCountryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- ::= {pilotAttributeType 43}
-
-
- uniqueIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-unique-identifier))
- ::= {pilotAttributeType 44}
-
-
- organizationalStatus ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-organizational-status))
- ::= {pilotAttributeType 45}
-
-
- janetMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-janet-mailbox))
- ::= {pilotAttributeType 46}
-
-
- mailPreferenceOption ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX ENUMERATED {
- no-list-inclusion(0),
- any-list-inclusion(1), -- may be added to any lists
- professional-list-inclusion(2)
- -- may be added to lists
- -- which the list provider
- -- views as related to the
- -- users professional inter-
- -- ests, perhaps evaluated
- -- from the business of the
- -- organisation or keywords
- -- in the entry.
- }
- ::= {pilotAttributeType 47}
-
-
- buildingName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-building-name))
-
-
-
-Barker & Kille [Page 56]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 48}
-
-
- dSAQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 49}
-
-
- singleLevelQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
-
-
- subtreeMinimumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 51}
-
-
- subtreeMaximumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 52}
-
-
- personalSignature ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-personal-signature))
- ::= {pilotAttributeType 53}
-
-
- dITRedirect ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 54}
-
-
- audio ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- Audio
- (SIZE (1 .. ub-audio))
- ::= {pilotAttributeType 55}
-
-
-
-Barker & Kille [Page 57]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- documentPublisher ATTRIBUTE
- WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
- ::= {pilotAttributeType 56}
-
-
-
- -- Generally useful syntaxes
-
-
- caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- iA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- -- Syntaxes to support the DNS attributes
-
- DNSRecordSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY
-
-
- NRSInformationSyntax ATTRIBUTE-SYNTAX
- NRSInformation
- MATCHES FOR EQUALITY
-
-
- NRSInformation ::= SET {
- [0] Context,
- [1] Address-space-id,
- routes [2] SEQUENCE OF SEQUENCE {
- Route-cost,
- Addressing-info }
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 58]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Upper bounds on length of attribute values
-
-
- ub-document-identifier INTEGER ::= 256
-
- ub-document-location INTEGER ::= 256
-
- ub-document-title INTEGER ::= 256
-
- ub-document-version INTEGER ::= 256
-
- ub-favourite-drink INTEGER ::= 256
-
- ub-host INTEGER ::= 256
-
- ub-information INTEGER ::= 2048
-
- ub-unique-identifier INTEGER ::= 256
-
- ub-personal-title INTEGER ::= 256
-
- ub-photo INTEGER ::= 250000
-
- ub-rfc822-mailbox INTEGER ::= 256
-
- ub-room-number INTEGER ::= 256
-
- ub-text-or-address INTEGER ::= 256
-
- ub-user-class INTEGER ::= 256
-
- ub-user-identifier INTEGER ::= 256
-
- ub-organizational-status INTEGER ::= 256
-
- ub-janet-mailbox INTEGER ::= 256
-
- ub-building-name INTEGER ::= 256
-
- ub-personal-signature ::= 50000
-
- ub-audio INTEGER ::= 250000
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 59]
-\f
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-10. Authors' Addresses
-
- Paul Barker
- Department of Computer Science
- University College London
- Gower Street
- London WC1E 6BT
- England
-
- Phone: +44 71-380-7366
- EMail: P.Barker@cs.ucl.ac.uk
-
-
- Steve Kille
- Department of Computer Science
- University College London
- Gower Street
- London WC1E 6BT
- England
-
- Phone: +44 71-380-7294
- EMail: S.Kille@cs.ucl.ac.uk
-
- Or send comments to the discussion group: <osi-ds@cs.ucl.ac.uk>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 60]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- <distinguished-name> ::= <name>
-
- <relative-distinguished-name> ::= <name-component>
-
- where <name> and <name-component> 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]
-\f
-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:
-
- <AttributeDescription> ::= <AttributeType> [ ";" <options> ]
-
- <options> ::= <option> | <option> ";" <options>
-
- <option> ::= <opt-char> <opt-char>*
-
- <opt-char> ::= ASCII-equivalent letters, numbers and hyphen
-
- Examples of valid AttributeDescription:
-
- cn
- userCertificate;binary
-
- One option, "binary", is defined in this document. Additional
- options may be defined in IETF standards-track and experimental RFCs.
- Options beginning with "x-" are reserved for private experiments.
- Any option could be associated with any AttributeType, although not
- all combinations may be supported by a server.
-
- An AttributeDescription with one or more options is treated as a
- subtype of the attribute type without any options. Options present
- in an AttributeDescription are never mutually exclusive.
- Implementations MUST generate the <options> list sorted in ascending
- order, and servers MUST treat any two AttributeDescription with the
- same AttributeType and options as equivalent. A server will treat an
- AttributeDescription with any options it does not implement as an
- unrecognized attribute type.
-
- The data type "AttributeDescriptionList" describes a list of 0 or
- more attribute types. (A list of zero elements has special
- significance in the Search request.)
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
-
-
-
-Wahl, et. al. Standards Track [Page 13]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-4.1.5.1. Binary Option
-
- If the "binary" option is present in an AttributeDescription, it
- overrides any string-based encoding representation defined for that
- attribute in [5]. Instead the attribute is to be transferred as a
- binary value encoded using the Basic Encoding Rules [11]. The syntax
- of the binary value is an ASN.1 data type definition which is
- referenced by the "SYNTAX" part of the attribute type definition.
-
- The presence or absence of the "binary" option only affects the
- transfer of attribute values in protocol; servers store any
- particular attribute in a single format. If a client requests that a
- server return an attribute in the binary format, but the server
- cannot generate that format, the server MUST treat this attribute
- type as an unrecognized attribute type. Similarly, clients MUST NOT
- expect servers to return an attribute in binary format if the client
- requested that attribute by name without the binary option.
-
- This option is intended to be used with attributes whose syntax is a
- complex ASN.1 data type, and the structure of values of that type is
- needed by clients. Examples of this kind of syntax are "Certificate"
- and "CertificateList".
-
-4.1.6. Attribute Value
-
- A field of type AttributeValue takes on as its value either a string
- encoding of a AttributeValue data type, or an OCTET STRING containing
- an encoded binary value, depending on whether the "binary" option is
- present in the companion AttributeDescription to this AttributeValue.
-
- The definition of string encodings for different syntaxes and types
- may be found in other documents, and in particular [5].
-
- AttributeValue ::= OCTET STRING
-
- Note that there is no defined limit on the size of this encoding;
- thus protocol values may include multi-megabyte attributes (e.g.
- photographs).
-
- Attributes may be defined which have arbitrary and non-printable
- syntax. Implementations MUST NEITHER simply display nor attempt to
- decode as ASN.1 a value if its syntax is not known. The
- implementation may attempt to discover the subschema of the source
- entry, and retrieve the values of attributeTypes from it.
-
- Clients MUST NOT send attribute values in a request which are not
- valid according to the syntax defined for the attributes.
-
-
-
-
-Wahl, et. al. Standards Track [Page 14]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-4.1.7. Attribute Value Assertion
-
- The AttributeValueAssertion type definition is similar to the one in
- the X.500 directory standards. It contains an attribute description
- and a matching rule assertion value suitable for that type.
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- If the "binary" option is present in attributeDesc, this signals to
- the server that the assertionValue is a binary encoding of the
- assertion value.
-
- For all the string-valued user attributes described in [5], the
- assertion value syntax is the same as the value syntax. Clients may
- use attribute values as assertion values in compare requests and
- search filters.
-
- Note however that the assertion syntax may be different from the
- value syntax for other attributes or for non-equality matching rules.
- These may have an assertion syntax which contains only part of the
- value. See section 20.2.1.8 of X.501 [6] for examples.
-
-4.1.8. Attribute
-
- An attribute consists of a type and one or more values of that type.
- (Though attributes MUST have at least one value when stored, due to
- access control restrictions the set may be empty when transferred in
- protocol. This is described in section 4.5.2, concerning the
- PartialAttributeList type.)
-
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Each attribute value is distinct in the set (no duplicates). The
- order of attribute values within the vals set is undefined and
- implementation-dependent, and MUST NOT be relied upon.
-
-4.1.9. Matching Rule Identifier
-
- A matching rule is a means of expressing how a server should compare
- an AssertionValue received in a search filter with an abstract data
- value. The matching rule defines the syntax of the assertion value
- and the process to be performed in the server.
-
-
-
-Wahl, et. al. Standards Track [Page 15]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- An X.501(1993) Matching Rule is identified in the LDAP protocol by
- the printable representation of its OBJECT IDENTIFIER, either as one
- of the strings given in [5], or as decimal digits with components
- separated by periods, e.g. "caseIgnoreIA5Match" or
- "1.3.6.1.4.1.453.33.33".
-
- MatchingRuleId ::= LDAPString
-
- Servers which support matching rules for use in the extensibleMatch
- search filter MUST list the matching rules they implement in
- subschema entries, using the matchingRules attributes. The server
- SHOULD also list there, using the matchingRuleUse attribute, the
- attribute types with which each matching rule can be used. More
- information is given in section 4.4 of [5].
-
-4.1.10. Result Message
-
- 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.
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
-
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10), -- new
- adminLimitExceeded (11), -- new
- unavailableCriticalExtension (12), -- new
- confidentialityRequired (13), -- new
- saslBindInProgress (14), -- new
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
-
-
-
-Wahl, et. al. Standards Track [Page 16]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71), -- new
- -- 72-79 unused --
- other (80) },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- errorMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- All the result codes with the exception of success, compareFalse and
- compareTrue are to be treated as meaning the operation could not be
- completed in its entirety.
-
- Most of the result codes are based on problem indications from X.511
- error data types. Result codes from 16 to 21 indicate an
- AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
- codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
- indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
- UpdateProblem.
-
- If a client receives a result code which is not listed above, it is
- to be treated as an unknown error condition.
-
- The errorMessage field of this construct may, at the server's option,
- be used to return a string containing a textual, human-readable
- (terminal control and page formatting characters should be avoided)
- error diagnostic. As this error diagnostic is not standardized,
-
-
-
-
-Wahl, et. al. Standards Track [Page 17]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- implementations MUST NOT rely on the values returned. If the server
- chooses not to return a textual diagnostic, the errorMessage field of
- the LDAPResult type MUST contain a zero length string.
-
- For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem, the matchedDN field is set to the name of
- the lowest entry (object or alias) in the directory that was matched.
- If no aliases were dereferenced while attempting to locate the entry,
- this will be a truncated form of the name provided, or if aliases
- were dereferenced, of the resulting name, as defined in section 12.5
- of X.511 [8]. The matchedDN field is to be set to a zero length
- string with all other result codes.
-
-4.1.11. Referral
-
- The referral error indicates that the contacted server does not hold
- the target entry of the request. The referral field is present in an
- LDAPResult if the LDAPResult.resultCode field value is referral, and
- absent with all other result codes. It contains a reference to
- another server (or set of servers) which may be accessed via LDAP or
- other protocols. Referrals can be returned in response to any
- operation request (except unbind and abandon which do not have
- responses). At least one URL MUST be present in the Referral.
-
- The referral is not returned for a singleLevel or wholeSubtree search
- in which the search scope spans multiple naming contexts, and several
- different servers would need to be contacted to complete the
- operation. Instead, continuation references, described in section
- 4.5.3, are returned.
-
- Referral ::= SEQUENCE OF LDAPURL -- one or more
-
- LDAPURL ::= LDAPString -- limited to characters permitted in URLs
-
- If the client wishes to progress the operation, it MUST follow the
- referral by contacting any one of servers. All the URLs MUST be
- equally capable of being used to progress the operation. (The
- mechanisms for how this is achieved by multiple servers are outside
- the scope of this document.)
-
- URLs for servers implementing the LDAP protocol are written according
- to [9]. If an alias was dereferenced, the <dn> part of the URL MUST
- be present, with the new target object name. If the <dn> part is
- present, the client MUST use this name in its next request to
- progress the operation, and if it is not present the client will use
- the same name as in the original request. Some servers (e.g.
- participating in distributed indexing) may provide a different filter
- in a referral for a search operation. If the filter part of the URL
-
-
-
-Wahl, et. al. Standards Track [Page 18]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- is present in an LDAPURL, the client MUST use this filter in its next
- request to progress this search, and if it is not present the client
- MUST use the same filter as it used for that search. Other aspects
- of the new request may be the same or different as the request which
- generated the referral.
-
- Note that UTF-8 characters appearing in a DN or search filter may not
- be legal for URLs (e.g. spaces) and MUST be escaped using the %
- method in RFC 1738 [7].
-
- Other kinds of URLs may be returned, so long as the operation could
- be performed using that protocol.
-
-4.1.12. Controls
-
- A control is a way to specify extension information. Controls which
- are sent as part of a request apply only to that request and are not
- saved.
-
- Controls ::= SEQUENCE OF Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- The controlType field MUST be a UTF-8 encoded dotted-decimal
- representation of an OBJECT IDENTIFIER which uniquely identifies the
- control. This prevents conflicts between control names.
-
- The criticality field is either TRUE or FALSE.
-
- If the server recognizes the control type and it is appropriate for
- the operation, the server will make use of the control when
- performing the operation.
-
- If the server does not recognize the control type and the criticality
- field is TRUE, the server MUST NOT perform the operation, and MUST
- instead return the resultCode unsupportedCriticalExtension.
-
- If the control is not appropriate for the operation and criticality
- field is TRUE, the server MUST NOT perform the operation, and MUST
- instead return the resultCode unsupportedCriticalExtension.
-
- If the control is unrecognized or inappropriate but the criticality
- field is FALSE, the server MUST ignore the control.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 19]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- The controlValue contains any information associated with the
- control, and its format is defined for the control. The server MUST
- be prepared to handle arbitrary contents of the controlValue octet
- string, including zero bytes. It is absent only if there is no value
- information which is associated with a control of its type.
-
- This document does not define any controls. Controls may be defined
- in other documents. The definition of a control consists of:
-
- - the OBJECT IDENTIFIER assigned to the control,
-
- - whether the control is always noncritical, always critical, or
- critical at the client's option,
-
- - the format of the controlValue contents of the control.
-
- Servers list the controls which they recognize in the
- supportedControl attribute in the root DSE.
-
-4.2. Bind Operation
-
- The function of the Bind Operation is to allow authentication
- information to be exchanged between the client and server.
-
- The Bind Request is defined as follows:
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- 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
- 3 of the LDAP protocol. Note that there is no version negotiation,
- and the client just sets this parameter to the version it desires.
- If the client requests protocol version 2, a server that supports
- the version 2 protocol as described in [2] will not return any v3-
-
-
-
-Wahl, et. al. Standards Track [Page 20]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- specific protocol fields. (Note that not all LDAP servers will
- support protocol version 2, since they may be unable to generate
- the attribute syntaxes associated with version 2.)
-
- - 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, when authentication
- has been performed at a lower layer, or when using SASL credentials
- with a mechanism that includes the LDAPDN in the credentials.
-
- - authentication: information used to authenticate the name, if any,
- provided in the Bind Request.
-
- Upon receipt of a Bind Request, a protocol server will authenticate
- the requesting client, if necessary. The server will then return a
- Bind Response to the client indicating the status of the
- authentication.
-
- Authorization is the use of this authentication information when
- performing operations. Authorization MAY be affected by factors
- outside of the LDAP Bind request, such as lower layer security
- services.
-
-4.2.1. Sequencing of the Bind Request
-
- For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times. If at any stage the
- client wishes to abort the bind process it MAY unbind and then drop
- the underlying connection. Clients MUST NOT invoke operations
- between two Bind requests made as part of a multi-stage bind.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as an
- empty string, the server MUST return a BindResponse with
- authMethodNotSupported as the resultCode. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
- Unlike LDAP v2, the client need not send a Bind Request in the first
- PDU of the connection. The client may request any operations and the
- server MUST treat these as unauthenticated. If the server requires
- that the client bind before browsing or modifying the directory, the
- server MAY reject a request other than binding, unbinding or an
- extended request with the "operationsError" result.
-
-
-
-
-Wahl, et. al. Standards Track [Page 21]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- If the client did not bind before sending a request and receives an
- operationsError, it may then send a Bind Request. If this also fails
- or the client chooses not to bind on the existing connection, it will
- close the connection, reopen it and begin again by first sending a
- PDU with a Bind Request. This will aid in interoperating with
- servers implementing other versions of LDAP.
-
- Clients MAY send multiple bind requests on a connection to change
- their credentials. A subsequent bind process has the effect of
- abandoning all operations outstanding on the connection. (This
- simplifies server implementation.) Authentication from earlier binds
- are subsequently ignored, and so if the bind fails, the connection
- will be treated as anonymous. If a SASL transfer encryption or
- integrity mechanism has been negotiated, and that mechanism does not
- support the changing of credentials from one identity to another,
- then the client MUST instead establish a new connection.
-
-4.2.2. Authentication and Other Security Services
-
- The simple authentication option provides minimal authentication
- facilities, with the contents of the authentication field consisting
- only of a cleartext password. Note that the use of cleartext
- passwords is not recommended over open networks when there is no
- authentication or encryption being performed by a lower layer; see
- the "Security Considerations" section.
-
- If no authentication is to be performed, then the simple
- authentication option MUST be chosen, and the password be of zero
- length. (This is often done by LDAPv2 clients.) Typically the DN is
- also of zero length.
-
- The sasl choice allows for any mechanism defined for use with SASL
- [12]. The mechanism field contains the name of the mechanism. The
- credentials field contains the arbitrary data used for
- authentication, inside an OCTET STRING wrapper. Note that unlike
- some Internet application protocols where SASL is used, LDAP is not
- text-based, thus no base64 transformations are performed on the
- credentials.
-
- If any SASL-based integrity or confidentiality services are enabled,
- they take effect following the transmission by the server and
- reception by the client of the final BindResponse with resultCode
- success.
-
- The client can request that the server use authentication information
- from a lower layer protocol by using the SASL EXTERNAL mechanism.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 22]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-4.2.3. Bind Response
-
- The Bind Response is defined as follows.
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- BindResponse consists simply of an indication from the server of he
- status of the client's request for authentication.
-
- f the bind was successful, the resultCode will be success, therwise
- it will be one of:
-
- - operationsError: server encountered an internal error,
-
- - protocolError: unrecognized version number or incorrect PDU
- structure,
-
- - authMethodNotSupported: unrecognized SASL mechanism name,
-
- - strongAuthRequired: the server requires authentication be
- performed with a SASL mechanism,
-
- - referral: this server cannot accept this bind and the client
- should try another,
-
- - saslBindInProgress: the server requires the client to send a
- new bind request, with the same sasl mechanism, to continue the
- authentication process,
-
- - inappropriateAuthentication: the server requires the client
- which had attempted to bind anonymously or without supplying
- credentials to provide some form of credentials,
-
- - invalidCredentials: the wrong password was supplied or the SASL
- credentials could not be processed,
-
- - unavailable: the server is shutting down.
-
- If the server does not support the client's requested protocol
- version, it MUST set the resultCode to protocolError.
-
- If the client receives a BindResponse response where the resultCode
- was protocolError, it MUST close the connection as the server will be
- unwilling to accept further operations. (This is for compatibility
- with earlier versions of LDAP, in which the bind was always the first
- operation, and there was no negotiation.)
-
-
-
-Wahl, et. al. Standards Track [Page 23]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- The serverSaslCreds are used as part of a SASL-defined bind mechanism
- to allow the client to authenticate the server to which it is
- communicating, or to perform "challenge-response" authentication. If
- the client bound with the password choice, or the SASL mechanism does
- not require the server to return information to the client, then this
- field is not to be included in the result.
-
-4.3. 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
-
- 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, and may close the
- connection.
-
-4.4. Unsolicited Notification
-
- An unsolicited notification is an LDAPMessage sent from the server to
- the client which is not in response to any LDAPMessage received by
- the server. It is used to signal an extraordinary condition in the
- server or in the connection between the client and the server. The
- notification is of an advisory nature, and the server will not expect
- any response to be returned from the client.
-
- The unsolicited notification is structured as an LDAPMessage in which
- the messageID is 0 and protocolOp is of the extendedResp form. The
- responseName field of the ExtendedResponse is present. The LDAPOID
- value MUST be unique for this notification, and not be used in any
- other situation.
-
- One unsolicited notification is defined in this document.
-
-4.4.1. Notice of Disconnection
-
- This notification may be used by the server to advise the client that
- the server is about to close the connection due to an error
- condition. Note that this notification is NOT a response to an
- unbind requested by the client: the server MUST follow the procedures
- of section 4.3. This notification is intended to assist clients in
- distinguishing between an error condition and a transient network
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 24]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- failure. As with a connection close due to network failure, the
- client MUST NOT assume that any outstanding requests which modified
- the directory have succeeded or failed.
-
- The responseName is 1.3.6.1.4.1.1466.20036, the response field is
- absent, and the resultCode is used to indicate the reason for the
- disconnection.
-
- The following resultCode values are to be used in this notification:
-
- - protocolError: The server has received data from the client in
- which
- the LDAPMessage structure could not be parsed.
-
- - strongAuthRequired: The server has detected that an established
- underlying security association protecting communication between
- the client and server has unexpectedly failed or been compromised.
-
- - unavailable: This server will stop accepting new connections and
- operations on all existing connections, and be unavailable for an
- extended period of time. The client may make use of an alternative
- server.
-
- After sending this notice, the server MUST close the connection.
- After receiving this notice, the client MUST NOT transmit any further
- on the connection, and may abruptly close the connection.
-
-4.5. Search Operation
-
- The Search Operation allows a client to request that a search be
- performed on its behalf by a server. This can be used to read
- attributes from a single entry, from entries immediately below a
- particular entry, or a whole subtree of entries.
-
-4.5.1. Search Request
-
- 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),
-
-
-
-Wahl, et. al. Standards Track [Page 25]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
- 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] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- at least one must be present
- substrings SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString } }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- 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 X.511 Search Operation.
-
- - derefAliases: An indicator as to how alias objects (as defined in
- X.501) are to be handled in searching. The semantics of the
- possible values of this field are:
-
- neverDerefAliases: do not dereference aliases in searching
- or in locating the base object of the search;
-
-
-
-Wahl, et. al. Standards Track [Page 26]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- derefInSearching: dereference aliases in subordinates of
- the base object in searching, but not in locating the
- base object of the search;
-
- derefFindingBaseObj: 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 client-requested sizelimit restrictions are
- in effect for the search. Servers may enforce a maximum number of
- entries to return.
-
- - timelimit: A timelimit that restricts the maximum time (in seconds)
- allowed for a search. A value of 0 in this field indicates that no
- client-requested timelimit restrictions are in effect for the
- search.
-
- - typesOnly: An indicator as to whether search results will 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
- 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.
-
- The 'and', 'or' and 'not' choices can be used to form combinations of
- filters. At least one filter element MUST be present in an 'and' or
- 'or' choice. The others match against individual attribute values of
- entries in the scope of the search. (Implementor's note: the 'not'
- filter is an example of a tagged choice in an implicitly-tagged
- module. In BER this is treated as if the tag was explicit.)
-
- A server MUST evaluate filters according to the three-valued logic
- of X.511(93) section 7.8.1. In summary, a filter is evaluated to
- either "TRUE", "FALSE" or "Undefined". If the filter evaluates
- to TRUE for a particular entry, then the attributes of that entry
- are returned as part of the search result (subject to any applicable
- access control restrictions). If the filter evaluates to FALSE or
- Undefined, then the entry is ignored for the search.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 27]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- A filter of the "and" choice is TRUE if all the filters in the SET
- OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
- otherwise Undefined. A filter of the "or" choice is FALSE if all
- of the filters in the SET OF evaluate to FALSE, TRUE if at least
- one filter is TRUE, and Undefined otherwise. A filter of the "not"
- choice is TRUE if the filter being negated is FALSE, FALSE if it is
- TRUE, and Undefined if it is Undefined.
-
- The present match evaluates to TRUE where there is an attribute or
- subtype of the specified attribute description present in an entry,
- and FALSE otherwise (including a presence test with an unrecognized
- attribute description.)
-
- The extensibleMatch is new in this version of LDAP. If the
- matchingRule field is absent, the type field MUST be present, and
- the equality match is performed for that type. If the type field is
- absent and matchingRule is present, the matchValue is compared
- against all attributes in an entry which support that matchingRule,
- and the matchingRule determines the syntax for the assertion value
- (the filter item evaluates to TRUE if it matches with at least
- one attribute in the entry, FALSE if it does not match any attribute
- in the entry, and Undefined if the matchingRule is not recognized
- or the assertionValue cannot be parsed.) If the type field is
- present and matchingRule is present, the matchingRule MUST be one
- permitted for use with that type, otherwise the filter item is
- undefined. If the dnAttributes field is set to TRUE, the match is
- applied against all the attributes in an entry's distinguished name
- as well, and also evaluates to TRUE if there is at least one
- attribute in the distinguished name for which the filter item
- evaluates to TRUE. (Editors note: The dnAttributes field is present
- so that there does not need to be multiple versions of generic
- matching rules such as for word matching, one to apply to entries
- and another to apply to entries and dn attributes as well).
-
- A filter item evaluates to Undefined when the server would not
- be able to determine whether the assertion value matches an
- entry. If an attribute description in an equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
- filter is not recognized by the server, a matching rule id in the
- extensibleMatch is not recognized by the server, the assertion
- value cannot be parsed, or the type of filtering requested is not
- implemented, then the filter is Undefined. Thus for example if a
- server did not recognize the attribute type shoeSize, a filter of
- (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
- (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 28]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- Servers MUST NOT return errors if attribute descriptions or matching
- rule ids are not recognized, or assertion values cannot be parsed.
- More details of filter processing are given in section 7.8 of X.511
- [8].
-
- - attributes: A list of the attributes to be returned from each entry
- which matches the search filter. There are two special values which
- may be used: an empty list with no attributes, and the attribute
- description string "*". Both of these signify that all user
- attributes are to be returned. (The "*" allows the client to
- request all user attributes in addition to specific operational
- attributes).
-
- Attributes MUST be named at most once in the list, and are returned
- at most once in an entry. If there are attribute descriptions in
- the list which are not recognized, they are ignored by the server.
-
- If the client does not want any attributes returned, it can specify
- a list containing only the attribute with OID "1.1". This OID was
- chosen arbitrarily and does not correspond to any attribute in use.
-
- Client implementors should note that even if all user attributes are
- requested, some attributes of the entry may not be included in
- search results due to access control or other restrictions.
- Furthermore, servers will not return operational attributes, such
- as objectClasses or attributeTypes, unless they are listed by name,
- since there may be extremely large number of values for certain
- operational attributes. (A list of operational attributes for use
- in LDAP is given in [5].)
-
- Note that an X.500 "list"-like operation can be emulated by the client
- requesting a one-level LDAP search operation with a filter checking
- for the existence of the objectClass attribute, and that an X.500
- "read"-like operation can be emulated by a base object LDAP search
- operation with the same filter. A server which provides a gateway to
- X.500 is not required to use the Read or List operations, although it
- may choose to do so, and if it does must provide the same semantics
- as the X.500 search operation.
-
-4.5.2. Search Result
-
- The results of the search attempted by the server upon receipt of a
- Search Request are returned in Search Responses, which are LDAP
- messages containing either SearchResultEntry, SearchResultReference,
- ExtendedResponse or SearchResultDone data types.
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
-
-
-
-Wahl, et. al. Standards Track [Page 29]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
- -- implementors should note that the PartialAttributeList may
- -- have zero elements (if none of the attributes of that entry
- -- were requested, or could be returned), and that the vals set
- -- may also have zero elements (if types only was requested, or
- -- all values were excluded from the result.)
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
- -- at least one LDAPURL element must be present
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- Upon receipt of a Search Request, a server will perform the necessary
- search of the DIT.
-
- If the LDAP session is operating over a connection-oriented transport
- such as TCP, the server will return to the client a sequence of
- responses in separate LDAP messages. There may be zero or more
- responses containing SearchResultEntry, one for each entry found
- during the search. There may also be zero or more responses
- containing SearchResultReference, one for each area not explored by
- this server during the search. The SearchResultEntry and
- SearchResultReference PDUs may come in any order. Following all the
- SearchResultReference responses and all SearchResultEntry responses
- to be returned by the server, the server will return a response
- containing the SearchResultDone, which contains an indication of
- success, or detailing any errors that have occurred.
-
- Each entry returned in a SearchResultEntry will contain all
- attributes, complete with associated values if necessary, as
- specified in the attributes field of the Search Request. Return of
- attributes is subject to access control and other administrative
- policy. Some attributes may be returned in binary format (indicated
- by the AttributeDescription in the response having the binary option
- present).
-
- Some attributes may be constructed by the server and appear in a
- SearchResultEntry attribute list, although they are not stored
- attributes of an entry. Clients MUST NOT assume that all attributes
- can be modified, even if permitted by access control.
-
- LDAPMessage responses of the ExtendedResponse form are reserved for
- returning information associated with a control requested by the
- client. These may be defined in future versions of this document.
-
-
-
-Wahl, et. al. Standards Track [Page 30]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-4.5.3. Continuation References in the Search Result
-
- If the server was able to locate the entry referred to by the
- baseObject but was unable to search all the entries in the scope at
- and under the baseObject, the server may return one or more
- SearchResultReference, each containing a reference to another set of
- servers for continuing the operation. A server MUST NOT return any
- SearchResultReference if it has not located the baseObject and
- thus has not searched any entries; in this case it would return a
- SearchResultDone containing a referral resultCode.
-
- In the absence of indexing information provided to a server from
- servers holding subordinate naming contexts, SearchResultReference
- responses are not affected by search filters and are always returned
- when in scope.
-
- The SearchResultReference is of the same data type as the Referral.
- URLs for servers implementing the LDAP protocol are written according
- to [9]. The <dn> part MUST be present in the URL, with the new target
- object name. The client MUST use this name in its next request.
- Some servers (e.g. part of a distributed index exchange system) may
- provide a different filter in the URLs of the SearchResultReference.
- If the filter part of the URL is present in an LDAP URL, the client
- MUST use the new filter in its next request to progress the search,
- and if the filter part is absent the client will use again the same
- filter. Other aspects of the new search request may be the same or
- different as the search which generated the continuation references.
-
- Other kinds of URLs may be returned so long as the operation could be
- performed using that protocol.
-
- The name of an unexplored subtree in a SearchResultReference need not
- be subordinate to the base object.
-
- In order to complete the search, the client MUST issue a new search
- operation for each SearchResultReference that is returned. Note that
- the abandon operation described in section 4.11 applies only to a
- particular operation sent on a connection between a client and server,
- and if the client has multiple outstanding search operations to
- different servers, it MUST abandon each operation individually.
-
-4.5.3.1. Example
-
- For example, suppose the contacted server (hosta) holds the entry
- "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
- either LDAP-capable servers (hostb) or (hostc) hold
- "OU=People,O=MNN,C=WW" (one is the master and the other server a
-
-
-
-
-Wahl, et. al. Standards Track [Page 31]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- shadow), and that LDAP-capable server (hostd) holds the subtree
- "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is
- requested to the contacted server, it may return the following:
-
- SearchResultEntry for O=MNN,C=WW
- SearchResultEntry for CN=Manager,O=MNN,C=WW
- SearchResultReference {
- ldap://hostb/OU=People,O=MNN,C=WW
- ldap://hostc/OU=People,O=MNN,C=WW
- }
- SearchResultReference {
- ldap://hostd/OU=Roles,O=MNN,C=WW
- }
- SearchResultDone (success)
-
- Client implementors should note that when following a
- SearchResultReference, additional SearchResultReference may be
- generated. Continuing the example, if the client contacted the
- server (hostb) and issued the search for the subtree
- "OU=People,O=MNN,C=WW", the server might respond as follows:
-
- SearchResultEntry for OU=People,O=MNN,C=WW
- SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
- }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
- }
- SearchResultDone (success)
-
- If the contacted server does not hold the base object for the search,
- then it will return a referral to the client. For example, if the
- client requests a subtree search of "O=XYZ,C=US" to hosta, the server
- may return only a SearchResultDone containing a referral.
-
- SearchResultDone (referral) {
- ldap://hostg/
- }
-
-4.6. Modify Operation
-
- The Modify Operation allows a client to request that a modification
- of an entry 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 {
-
-
-
-Wahl, et. al. Standards Track [Page 32]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Parameters of the Modify Request are:
-
- - object: The object to be modified. The value of this field contains
- the DN of the entry to be modified. The server will not perform
- any alias dereferencing in determining the object to be modified.
-
- - modification: A list of modifications to be performed on the entry.
- The entire list of entry modifications MUST 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;
-
- replace: replace all existing values of the given attribute
- with the new values listed, creating the attribute if it
- did not already exist. A replace with no value will delete
- the entire attribute if it exists, and is ignored if the
- attribute does not exist.
-
- 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 DIT.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 33]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIT 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 DIT 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. If the connection fails, whether the
- modification occurred or not is indeterminate.
-
- The Modify Operation cannot be used to remove from an entry any of
- its distinguished values, those values which form the entry's
- relative distinguished name. An attempt to do so will result in the
- server returning the error notAllowedOnRDN. The Modify DN Operation
- described in section 4.9 is used to rename an entry.
-
- If an equality match filter has not been defined for an attribute type,
- clients MUST NOT attempt to delete individual values of that attribute
- from an entry using the "delete" form of a modification, and MUST
- instead use the "replace" form.
-
- Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the modifications in an LDAP ModifyRequest onto the
- EntryModifications of a DAP ModifyEntry operation, and different
- implementations of LDAP-DAP gateways may use different means of
- representing the change. If successful, the final effect of the
- operations on the entry MUST be identical.
-
-4.7. 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,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Parameters of the Add Request are:
-
- - entry: the Distinguished Name of the entry to be added. Note that
- the server will not dereference any aliases in locating the entry
- to be added.
-
-
-
-
-Wahl, et. al. Standards Track [Page 34]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- - attributes: the list of attributes that make up the content of the
- entry being added. Clients MUST include distinguished values
- (those forming the entry's own RDN) in this list, the objectClass
- attribute, and values of any mandatory attributes of the listed
- object classes. Clients MUST NOT supply the createTimestamp or
- creatorsName attributes, since these will be generated
- automatically by the server.
-
- The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The parent of the entry to be added
- MUST exist. For example, if the client attempted to add
- "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the
- "C=US" entry did exist, then the server would return the error
- noSuchObject with the matchedDN field containing "C=US". If the
- parent entry exists but is not in a naming context held by the
- server, the server SHOULD return a referral to the server holding the
- parent entry.
-
- Servers implementations SHOULD NOT restrict where entries can be
- located in the directory. Some servers MAY allow the administrator
- to restrict the classes of entries which can be added to the
- directory.
-
- 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, defined as follows:
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- A response of success indicates that the new entry is present in the
- directory.
-
-4.8. 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 of the Distinguished Name of the entry to
- be deleted. Note that the server will not dereference aliases while
- resolving the name of the target entry to be removed, and that only
- leaf entries (those with no subordinate entries) can be deleted with
- this operation.
-
- The result of the delete attempted by the server upon receipt of a
- Delete Request is returned in the Delete Response, defined as
- follows:
-
-
-
-Wahl, et. al. Standards Track [Page 35]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- 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.
-
-4.9. Modify DN Operation
-
- The Modify DN Operation allows a client to change the leftmost (least
- significant) component of the name of an entry in the directory, or
- to move a subtree of entries to a new location in the directory. The
- Modify DN Request is defined as follows:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- Parameters of the Modify DN Request are:
-
- - entry: the Distinguished Name of the entry to be changed. This
- entry may or may not have subordinate entries.
-
- - newrdn: the RDN that will form the leftmost component of the new
- name of the entry.
-
- - deleteoldrdn: a boolean parameter that controls whether the old RDN
- attribute values are to be retained as attributes of the entry, or
- deleted from the entry.
-
- - newSuperior: if present, this is the Distinguished Name of the entry
- which becomes the immediate superior of the existing entry.
-
- The result of the name change attempted by the server upon receipt of
- a Modify DN Request is returned in the Modify DN Response, defined
- as follows:
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- Upon receipt of a ModifyDNRequest, 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 DN Response.
-
- For example, if the entry named in the "entry" parameter was
- "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith",
- and the newSuperior parameter was absent, then this operation would
-
-
-
-
-Wahl, et. al. Standards Track [Page 36]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- attempt to rename the entry to be "cn=John Cougar Smith,c=US". If
- there was already an entry with that name, the operation would fail
- with error code entryAlreadyExists.
-
- If the deleteoldrdn parameter is TRUE, the values forming the old
- RDN are deleted from the entry. If the deleteoldrdn parameter is
- FALSE, the values forming the old RDN will be retained as
- non-distinguished attribute values of the entry. The server may
- not perform the operation and return an error code if the setting of
- the deleteoldrdn parameter would cause a schema inconsistency in the
- entry.
-
- Note that X.500 restricts the ModifyDN operation to only affect
- entries that are contained within a single server. If the LDAP
- server is mapped onto DAP, then this restriction will apply, and the
- resultCode affectsMultipleDSAs will be returned if this error
- occurred. In general clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers.
-
-4.10. 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 an attribute in 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.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 37]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- Note that some directory systems may establish access controls which
- permit the values of certain attributes (such as userPassword) to be
- compared but not read. In a search result, it may be that an
- attribute of that type would be returned, but with an empty set of
- values.
-
-4.11. 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
-
- The MessageID MUST be that of a an operation which was requested
- earlier in this connection.
-
- (The abandon request itself has its own message id. This is distinct
- from the id of the earlier operation being abandoned.)
-
- There is no response defined in the Abandon Operation. Upon
- transmission of an Abandon Operation, a client may expect that the
- operation identified 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 the search, that server MUST cease transmitting entry responses to
- the abandoned request immediately, and MUST NOT send the
- SearchResponseDone. Of course, the server MUST ensure that only
- properly encoded LDAPMessage PDUs are transmitted.
-
- Clients MUST NOT send abandon requests for the same operation
- multiple times, and MUST also be prepared to receive results from
- operations it has abandoned (since these may have been in transit
- when the abandon was requested).
-
- Servers MUST discard abandon requests for message IDs they do not
- recognize, for operations which cannot be abandoned, and for
- operations which have already been abandoned.
-
-4.12. Extended Operation
-
- An extension mechanism has been added in this version of LDAP, in
- order to allow additional operations to be defined for services not
- available elsewhere in this protocol, for instance digitally signed
- operations and results.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 38]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- The extended operation allows clients to make requests and receive
- responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations. Each
- request MUST have a unique OBJECT IDENTIFIER assigned to it.
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- The requestName is a dotted-decimal representation of the OBJECT
- IDENTIFIER corresponding to the request. The requestValue is
- information in a form defined by that request, encapsulated inside an
- OCTET STRING.
-
- The server will respond to this with an LDAPMessage containing the
- ExtendedResponse.
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- If the server does not recognize the request name, it MUST return
- only the response fields from LDAPResult, containing the
- protocolError result code.
-
-5. Protocol Element Encodings and Transfer
-
- One underlying service is defined here. Clients and servers SHOULD
- implement the mapping of LDAP over TCP described in 5.2.1.
-
-5.1. Mapping Onto BER-based Transport Services
-
- The protocol elements of LDAP are encoded for exchange using the
- Basic Encoding Rules (BER) [11] of ASN.1 [3]. 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) OCTET STRING values will be encoded in the primitive form only.
-
- (3) If the value of a BOOLEAN type is true, the encoding MUST have
- its contents octets set to hex "FF".
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 39]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- (4) If a value of a type is its default value, it MUST be absent.
- Only some BOOLEAN and INTEGER types have default values in this
- protocol definition.
-
- These restrictions do not apply to ASN.1 types encapsulated inside of
- OCTET STRING values, such as attribute values, unless otherwise
- noted.
-
-5.2. Transfer Protocols
-
- This protocol is designed to run over connection-oriented, reliable
- transports, with all 8 bits in an octet being significant in the data
- stream.
-
-5.2.1. Transmission Control Protocol (TCP)
-
- The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It
- is recommended that server implementations running over the TCP MAY
- provide a protocol listener on the assigned port, 389. Servers may
- instead provide a listener on a different port number. Clients MUST
- support contacting servers on any valid TCP port.
-
-6. Implementation Guidelines
-
- This document describes an Internet protocol.
-
-6.1. Server Implementations
-
- The server MUST be capable of recognizing all the mandatory attribute
- type names and implement the syntaxes specified in [5]. Servers MAY
- also recognize additional attribute type names.
-
-6.2. Client Implementations
-
- Clients which request referrals MUST ensure that they do not loop
- between servers. They MUST NOT repeatedly contact the same server for
- the same request with the same target entry name, scope and filter.
- Some clients may be using a counter that is incremented each time
- referral handling occurs for an operation, and these kinds of clients
- MUST be able to handle a DIT with at least ten layers of naming
- contexts between the root and a leaf entry.
-
- In the absence of prior agreements with servers, clients SHOULD NOT
- assume that servers support any particular schemas beyond those
- referenced in section 6.1. Different schemas can have different
- attribute types with the same names. The client can retrieve the
- subschema entries referenced by the subschemaSubentry attribute in
- the server's root DSE or in entries held by the server.
-
-
-
-Wahl, et. al. Standards Track [Page 40]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-7. Security Considerations
-
- When used with a connection-oriented transport, this version of the
- protocol provides facilities for the LDAP v2 authentication
- mechanism, simple authentication using a cleartext password, as well
- as any SASL mechanism [12]. SASL allows for integrity and privacy
- services to be negotiated.
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
- Use of cleartext password is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
- When used with SASL, it should be noted that the name field of the
- BindRequest is not protected against modification. Thus if the
- distinguished name of the client (an LDAPDN) is agreed through the
- negotiation of the credentials, it takes precedence over any value in
- the unprotected name field.
-
- Implementations which cache attributes and entries obtained via LDAP
- MUST ensure that access controls are maintained if that information
- is to be provided to multiple clients, since servers may have access
- control policies which prevent the return of entries or attributes in
- search results except to particular authenticated clients. For
- example, caches could serve result information only to the client
- whose request caused it to be cache.
-
-8. Acknowledgements
-
- This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes,
- and Steve Kille. Design ideas included in this document are based on
- those discussed in ASID and other IETF Working Groups. The
- contributions of individuals in these working groups is gratefully
- acknowledged.
-
-9. Bibliography
-
- [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
- and Service", 1993.
-
- [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", 1994.
-
-
-
-
-Wahl, et. al. Standards Track [Page 41]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished
- Names", RFC 2253, December 1997.
-
- [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997.
-
- [6] ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, December 1994.
-
- [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
- 1993.
-
- [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", 1994.
-
- [12] Meyers, J., "Simple Authentication and Security Layer",
- RFC 2222, October 1997.
-
- [13] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
- 1993.
-
- [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
-10. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 W Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372-3160
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 42]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd., MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
- Steve Kille
- Isode Limited
- The Dome, The Square
- Richmond
- TW9 1DT
- UK
-
- Phone: +44-181-332-9091
- EMail: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 43]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-Appendix A - Complete ASN.1 Definition
-
- Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
- IMPLICIT TAGS ::=
-
- BEGIN
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- LDAPString ::= OCTET STRING
-
- LDAPOID ::= OCTET STRING
-
- LDAPDN ::= LDAPString
-
- RelativeLDAPDN ::= LDAPString
-
- AttributeType ::= LDAPString
-
- AttributeDescription ::= LDAPString
-
-
-
-
-Wahl, et. al. Standards Track [Page 44]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
- AttributeValue ::= OCTET STRING
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- MatchingRuleId ::= LDAPString
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10), -- new
- adminLimitExceeded (11), -- new
- unavailableCriticalExtension (12), -- new
- confidentialityRequired (13), -- new
- saslBindInProgress (14), -- new
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
-
-
-
-Wahl, et. al. Standards Track [Page 45]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71), -- new
- -- 72-79 unused --
- other (80) },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- errorMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE OF LDAPURL
-
- LDAPURL ::= LDAPString -- limited to characters permitted in URLs
-
- Controls ::= SEQUENCE OF Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
-
-
-
-Wahl, et. al. Standards Track [Page 46]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
- 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] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- at least one must be present
- substrings SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString } }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
-
-
-
-Wahl, et. al. Standards Track [Page 47]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
-
-
-Wahl, et. al. Standards Track [Page 48]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 49]
-\f
-RFC 2251 LDAPv3 December 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 50]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2252 Critical Angle Inc.
-Category: Standards Track A. Coulbeck
- Isode Inc.
- T. Howes
- Netscape Communications Corp.
- S. Kille
- Isode Limited
- December 1997
-
-
- Lightweight Directory Access Protocol (v3):
- Attribute Syntax Definitions
-
-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
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 1]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- 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.
-
- 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.
-
-2. Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [1] requires that
- the contents of AttributeValue fields in protocol elements be octet
- strings. This document defines a set of syntaxes for LDAPv3, and the
- rules by which attribute values of these syntaxes are represented as
- octet strings for transmission in the LDAP protocol. The syntaxes
- defined in this document are referenced by this and other documents
- that define attribute types. This document also defines the set of
- attribute types which LDAP servers should support.
-
-3. Overview
-
- This document defines the framework for developing schemas for
- directories accessible via the Lightweight Directory Access Protocol.
-
- 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.
-
- Section 4 states the general requirements and notations for attribute
- types, object classes, syntax and matching rule definitions.
-
- Section 5 lists attributes, section 6 syntaxes and section 7 object
- classes.
-
- Additional documents define schemas for representing real-world
- objects as directory entries.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 2]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-4. General Issues
-
- This document describes encodings used in an Internet protocol.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
- Attribute Type and Object Class definitions are written in a string
- representation of the AttributeTypeDescription and
- ObjectClassDescription data types defined in X.501(93) [3].
- Implementors are strongly advised to first read the description of
- how schema is represented in X.500 before reading the rest of this
- document.
-
-4.1. Common Encoding Aspects
-
- For the purposes of defining the encoding rules for attribute
- syntaxes, the following BNF definitions will be used. They are based
- on the BNF styles of RFC 822 [13].
-
- a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
- "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
- "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
- "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
- "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
- "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
-
- d = "0" / "1" / "2" / "3" / "4" /
- "5" / "6" / "7" / "8" / "9"
-
- hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /
- "A" / "B" / "C" / "D" / "E" / "F"
-
- k = a / d / "-" / ";"
-
- p = a / d / """ / "(" / ")" / "+" / "," /
- "-" / "." / "/" / ":" / "?" / " "
-
- letterstring = 1*a
-
- numericstring = 1*d
-
- anhstring = 1*k
-
- keystring = a [ anhstring ]
-
- printablestring = 1*p
-
-
-
-Wahl, et. al. Standards Track [Page 3]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- space = 1*" "
-
- whsp = [ space ]
-
- utf8 = <any sequence of octets formed from the UTF-8 [9]
- transformation of a character from ISO10646 [10]>
-
- dstring = 1*utf8
-
- qdstring = whsp "'" dstring "'" whsp
-
- qdstringlist = [ qdstring *( qdstring ) ]
-
- qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )
-
- In the following BNF for the string representation of OBJECT
- IDENTIFIERs, descr is the syntactic representation of an object
- descriptor, which consists of letters and digits, starting with a
- letter. An OBJECT IDENTIFIER in the numericoid format should not
- have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
- not be generated).
-
- When encoding 'oid' elements in a value, the descr encoding option
- SHOULD be used in preference to the numericoid. An object descriptor
- is a more readable alias for a number OBJECT IDENTIFIER, and these
- (where assigned and known by the implementation) SHOULD be used in
- preference to numeric oids to the greatest extent possible. Examples
- of object descriptors in LDAP are attribute type, object class and
- matching rule names.
-
- oid = descr / numericoid
-
- descr = keystring
-
- numericoid = numericstring *( "." numericstring )
-
- woid = whsp oid whsp
-
- ; set of oids of either form
- oids = woid / ( "(" oidlist ")" )
-
- oidlist = woid *( "$" woid )
-
- ; object descriptors used as schema element names
- qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )
-
- qdescrlist = [ qdescr *( qdescr ) ]
-
-
-
-
-Wahl, et. al. Standards Track [Page 4]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- qdescr = whsp "'" descr "'" whsp
-
-4.2. Attribute Types
-
- The attribute types are described by sample values for the subschema
- "attributeTypes" attribute, which is written in the
- AttributeTypeDescription syntax. While lines have been folded for
- readability, the values transferred in protocol would not contain
- newlines.
-
- The AttributeTypeDescription is encoded according to the following
- BNF, and the productions for oid, qdescrs and qdstring are given in
- section 4.1. Implementors should note that future versions of this
- document may have expanded this BNF to include additional terms.
- Terms which begin with the characters "X-" are reserved for private
- experiments, and MUST be followed by a <qdstrings>.
-
- AttributeTypeDescription = "(" whsp
- numericoid whsp ; AttributeType identifier
- [ "NAME" qdescrs ] ; name used in AttributeType
- [ "DESC" qdstring ] ; description
- [ "OBSOLETE" whsp ]
- [ "SUP" woid ] ; derived from this other
- ; AttributeType
- [ "EQUALITY" woid ; Matching Rule name
- [ "ORDERING" woid ; Matching Rule name
- [ "SUBSTR" woid ] ; Matching Rule name
- [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
- [ "SINGLE-VALUE" whsp ] ; default multi-valued
- [ "COLLECTIVE" whsp ] ; default not collective
- [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
- [ "USAGE" whsp AttributeUsage ]; default userApplications
- whsp ")"
-
- AttributeUsage =
- "userApplications" /
- "directoryOperation" /
- "distributedOperation" / ; DSA-shared
- "dSAOperation" ; DSA-specific, value depends on server
-
- Servers are not required to provide the same or any text in the
- description part of the subschema values they maintain. Servers
- SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
- AttributeTypeDescription.
-
- Servers MUST implement all the attribute types referenced in sections
- 5.1, 5.2 and 5.3.
-
-
-
-
-Wahl, et. al. Standards Track [Page 5]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Servers MAY recognize additional names and attributes not listed in
- this document, and if they do so, MUST publish the definitions of the
- types in the attributeTypes attribute of their subschema entries.
-
- Schema developers MUST NOT create attribute definitions whose names
- conflict with attributes defined for use with LDAP in existing
- standards-track RFCs.
-
- An AttributeDescription can be used as the value in a NAME part of an
- AttributeTypeDescription. Note that these are case insensitive.
-
- Note that the AttributeTypeDescription does not list the matching
- rules which can can be used with that attribute type in an
- extensibleMatch search filter. This is done using the
- matchingRuleUse attribute described in section 4.5.
-
- This document refines the schema description of X.501 by requiring
- that the syntax field in an AttributeTypeDescription be a string
- representation of an OBJECT IDENTIFIER for the LDAP string syntax
- definition, and an optional indication of the maximum length of a
- value of this attribute (defined in section 4.3.2).
-
-4.3. Syntaxes
-
- This section defines general requirements for LDAP attribute value
- syntax encodings. All documents defining attribute syntax encodings
- for use with LDAP are expected to conform to these requirements.
-
- The encoding rules defined for a given attribute syntax must produce
- octet strings. To the greatest extent possible, encoded octet
- strings should be usable in their native encoded form for display
- purposes. In particular, encoding rules for attribute syntaxes
- defining non-binary values should produce strings that can be
- displayed with little or no translation by clients implementing LDAP.
- There are a few cases (e.g. audio) however, when it is not sensible
- to produce a printable representation, and clients MUST NOT assume
- that an unrecognized syntax is a string representation.
-
- In encodings where an arbitrary string, not a Distinguished Name, is
- used as part of a larger production, and other than as part of a
- Distinguished Name, a backslash quoting mechanism is used to escape
- the following separator symbol character (such as "'", "$" or "#") if
- it should occur in that string. The backslash is followed by a pair
- of hexadecimal digits representing the next character. A backslash
- itself in the string which forms part of a larger syntax is always
- transmitted as '\5C' or '\5c'. An example is given in section 6.27.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 6]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Syntaxes are also defined for matching rules whose assertion value
- syntax is different from the attribute value syntax.
-
-4.3.1 Binary Transfer of Values
-
- This encoding format is used if the binary encoding is requested by
- the client for an attribute, or if the attribute syntax name is
- "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
- AttributeValue or AssertionValue field is a BER-encoded instance of
- the attribute value or a matching rule assertion value ASN.1 data
- type as defined for use with X.500. (The first byte inside the OCTET
- STRING wrapper is a tag octet. However, the OCTET STRING is still
- encoded in primitive form.)
-
- All servers MUST implement this form for both generating attribute
- values in search responses, and parsing attribute values in add,
- compare and modify requests, if the attribute type is recognized and
- the attribute syntax name is that of Binary. Clients which request
- that all attributes be returned from entries MUST be prepared to
- receive values in binary (e.g. userCertificate;binary), and SHOULD
- NOT simply display binary or unrecognized values to users.
-
-4.3.2. Syntax Object Identifiers
-
- Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
- dotted-decimal strings. These are not intended to be displayed to
- users.
-
- noidlen = numericoid [ "{" len "}" ]
-
- len = numericstring
-
- The following table lists some of the syntaxes that have been defined
- for LDAP thus far. The H-R column suggests whether a value in that
- syntax would likely be a human readable string. Clients and servers
- need not implement all the syntaxes listed here, and MAY implement
- other syntaxes.
-
- Other documents may define additional syntaxes. However, the
- definition of additional arbitrary syntaxes is strongly deprecated
- since it will hinder interoperability: today's client and server
- implementations generally do not have the ability to dynamically
- recognize new syntaxes. In most cases attributes will be defined
- with the syntax for directory strings.
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 7]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Value being represented H-R OBJECT IDENTIFIER
- =================================================================
- ACI Item N 1.3.6.1.4.1.1466.115.121.1.1
- Access Point Y 1.3.6.1.4.1.1466.115.121.1.2
- Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3
- Audio N 1.3.6.1.4.1.1466.115.121.1.4
- Binary N 1.3.6.1.4.1.1466.115.121.1.5
- Bit String Y 1.3.6.1.4.1.1466.115.121.1.6
- Boolean Y 1.3.6.1.4.1.1466.115.121.1.7
- Certificate N 1.3.6.1.4.1.1466.115.121.1.8
- Certificate List N 1.3.6.1.4.1.1466.115.121.1.9
- Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10
- Country String Y 1.3.6.1.4.1.1466.115.121.1.11
- DN Y 1.3.6.1.4.1.1466.115.121.1.12
- Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13
- Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14
- Directory String Y 1.3.6.1.4.1.1466.115.121.1.15
- DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16
- DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17
- DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18
- DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19
- DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20
- Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21
- Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22
- Fax N 1.3.6.1.4.1.1466.115.121.1.23
- Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24
- Guide Y 1.3.6.1.4.1.1466.115.121.1.25
- IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
- INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
- JPEG N 1.3.6.1.4.1.1466.115.121.1.28
- LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
- LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56
- LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57
- Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
- Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
- Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
- Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
- MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
- Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
- Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
- Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
- Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
- Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
- Octet String Y 1.3.6.1.4.1.1466.115.121.1.40
- OID Y 1.3.6.1.4.1.1466.115.121.1.38
- Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
- Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
- Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
-
-
-
-Wahl, et. al. Standards Track [Page 8]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
- Printable String Y 1.3.6.1.4.1.1466.115.121.1.44
- Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58
- Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45
- Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46
- Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47
- Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
- Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
- Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
- Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
- Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
- UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
-
- A suggested minimum upper bound on the number of characters in value
- with a string-based syntax, or the number of bytes in a value for all
- other syntaxes, may be indicated by appending this bound count inside
- of curly braces following the syntax name's OBJECT IDENTIFIER in an
- Attribute Type Description. This bound is not part of the syntax
- name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
- server implementations should allow a string to be 64 characters
- long, although they may allow longer strings. Note that a single
- character of the Directory String syntax may be encoded in more than
- one byte since UTF-8 is a variable-length encoding.
-
-4.3.3. Syntax Description
-
- The following BNF may be used to associate a short description with a
- syntax OBJECT IDENTIFIER. Implementors should note that future
- versions of this document may expand this definition to include
- additional terms. Terms whose identifier begins with "X-" are
- reserved for private experiments, and MUST be followed by a
- <qdstrings>.
-
- SyntaxDescription = "(" whsp
- numericoid whsp
- [ "DESC" qdstring ]
- whsp ")"
-
-4.4. Object Classes
-
- The format for representation of object classes is defined in X.501
- [3]. In general every entry will contain an abstract class ("top" or
- "alias"), at least one structural object class, and zero or more
- auxiliary object classes. Whether an object class is abstract,
- structural or auxiliary is defined when the object class identifier
- is assigned. An object class definition should not be changed
- without having a new identifier assigned to it.
-
-
-
-
-Wahl, et. al. Standards Track [Page 9]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Object class descriptions are written according to the following BNF.
- Implementors should note that future versions of this document may
- expand this definition to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
- MUST be followed by a <qdstrings> encoding.
-
- ObjectClassDescription = "(" whsp
- numericoid whsp ; ObjectClass identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- [ "SUP" oids ] ; Superior ObjectClasses
- [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
- ; default structural
- [ "MUST" oids ] ; AttributeTypes
- [ "MAY" oids ] ; AttributeTypes
- whsp ")"
-
- These are described as sample values for the subschema
- "objectClasses" attribute for a server which implements the LDAP
- schema. While lines have been folded for readability, the values
- transferred in protocol would not contain newlines.
-
- Servers SHOULD implement all the object classes referenced in section
- 7, except for extensibleObject, which is optional. Servers MAY
- implement additional object classes not listed in this document, and
- if they do so, MUST publish the definitions of the classes in the
- objectClasses attribute of their subschema entries.
-
- Schema developers MUST NOT create object class definitions whose
- names conflict with attributes defined for use with LDAP in existing
- standards-track RFCs.
-
-4.5. Matching Rules
-
- Matching rules are used by servers to compare attribute values
- against assertion values when performing Search and Compare
- operations. They are also used to identify the value to be added or
- deleted when modifying entries, and are used when comparing a
- purported distinguished name with the name of an entry.
-
- Most of the attributes given in this document will have an equality
- matching rule defined.
-
- Matching rule descriptions are written according to the following
- BNF. Implementors should note that future versions of this document
- may have expanded this BNF to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
-
-
-
-Wahl, et. al. Standards Track [Page 10]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- MUST be followed by a <qdstrings> encoding.
-
- MatchingRuleDescription = "(" whsp
- numericoid whsp ; MatchingRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "SYNTAX" numericoid
- whsp ")"
-
- Values of the matchingRuleUse list the attributes which are suitable
- for use with an extensible matching rule.
-
- MatchingRuleUseDescription = "(" whsp
- numericoid whsp ; MatchingRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" ]
- "APPLIES" oids ; AttributeType identifiers
- whsp ")"
-
- Servers which support matching rules and the extensibleMatch SHOULD
- implement all the matching rules in section 8.
-
- Servers MAY implement additional matching rules not listed in this
- document, and if they do so, MUST publish the definitions of the
- matching rules in the matchingRules attribute of their subschema
- entries. If the server supports the extensibleMatch, then the server
- MUST publish the relationship between the matching rules and
- attributes in the matchingRuleUse attribute.
-
- For example, a server which implements a privately-defined matching
- rule for performing sound-alike matches on Directory String-valued
- attributes would include the following in the subschema entry
- (1.2.3.4.5 is an example, the OID of an actual matching rule would be
- different):
-
- matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- If this matching rule could be used with the attributes 2.5.4.41 and
- 2.5.4.15, the following would also be present:
-
- matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 11]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- A client could then make use of this matching rule by sending a
- search operation in which the filter is of the extensibleMatch
- choice, the matchingRule field is "soundAlikeMatch", and the type
- field is "2.5.4.41" or "2.5.4.15".
-
-5. Attribute Types
-
- All LDAP server implementations MUST recognize the attribute types
- defined in this section.
-
- Servers SHOULD also recognize all the attributes from section 5 of
- [12].
-
-5.1. Standard Operational Attributes
-
- Servers MUST maintain values of these attributes in accordance with
- the definitions in X.501(93).
-
-5.1.1. createTimestamp
-
- This attribute SHOULD appear in entries which were created using the
- Add operation.
-
- ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.2. modifyTimestamp
-
- This attribute SHOULD appear in entries which have been modified
- using the Modify operation.
-
- ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.3. creatorsName
-
- This attribute SHOULD appear in entries which were created using the
- Add operation.
-
- ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 12]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.1.4. modifiersName
-
- This attribute SHOULD appear in entries which have been modified
- using the Modify operation.
-
- ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.5. subschemaSubentry
-
- The value of this attribute is the name of a subschema entry (or
- subentry if the server is based on X.500(93)) in which the server
- makes available attributes specifying the schema.
-
- ( 2.5.18.10 NAME 'subschemaSubentry'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
- SINGLE-VALUE USAGE directoryOperation )
-
-5.1.6. attributeTypes
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.5 NAME 'attributeTypes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
-
-5.1.7. objectClasses
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.6 NAME 'objectClasses'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
-
-5.1.8. matchingRules
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.4 NAME 'matchingRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 13]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.1.9. matchingRuleUse
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.8 NAME 'matchingRuleUse'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
-
-5.2. LDAP Operational Attributes
-
- These attributes are only present in the root DSE (see [1] and [3]).
-
- Servers MUST recognize these attribute names, but it is not required
- that a server provide values for these attributes, when the attribute
- corresponds to a feature which the server does not implement.
-
-5.2.1. namingContexts
-
- The values of this attribute correspond to naming contexts which this
- server masters or shadows. If the server does not master any
- information (e.g. it is an LDAP gateway to a public X.500 directory)
- this attribute will be absent. If the server believes it contains
- the entire directory, the attribute will have a single value, and
- that value will be the empty string (indicating the null DN of the
- root). This attribute will allow a client to choose suitable base
- objects for searching when it has contacted a server.
-
- ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
-
-5.2.2. altServer
-
- The values of this attribute are URLs of other servers which may be
- contacted when this server becomes unavailable. If the server does
- not know of any other servers which could be used this attribute will
- be absent. Clients may cache this information in case their preferred
- LDAP server later becomes unavailable.
-
- ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
-
-5.2.3. supportedExtension
-
- The values of this attribute are OBJECT IDENTIFIERs identifying the
- supported extended operations which the server supports.
-
- If the server does not support any extensions this attribute will be
- absent.
-
-
-
-Wahl, et. al. Standards Track [Page 14]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
-
-5.2.4. supportedControl
-
- The values of this attribute are the OBJECT IDENTIFIERs identifying
- controls which the server supports. If the server does not support
- any controls, this attribute will be absent.
-
- ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
-
-5.2.5. supportedSASLMechanisms
-
- The values of this attribute are the names of supported SASL
- mechanisms which the server supports. If the server does not support
- any mechanisms this attribute will be absent.
-
- ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
-
-5.2.6. supportedLDAPVersion
-
- The values of this attribute are the versions of the LDAP protocol
- which the server implements.
-
- ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
-
-5.3. LDAP Subschema Attribute
-
- This attribute is typically located in the subschema entry.
-
-5.3.1. ldapSyntaxes
-
- Servers MAY use this attribute to list the syntaxes which are
- implemented. Each value corresponds to one syntax.
-
- ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
-
-5.4. X.500 Subschema attributes
-
- These attributes are located in the subschema entry. All servers
- SHOULD recognize their name, although typically only X.500 servers
- will implement their functionality.
-
-
-
-
-Wahl, et. al. Standards Track [Page 15]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.4.1. dITStructureRules
-
- ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
-
-5.4.2. nameForms
-
- ( 2.5.21.7 NAME 'nameForms'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
-
-5.4.3. ditContentRules
-
- ( 2.5.21.2 NAME 'dITContentRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
-
-6. Syntaxes
-
- Servers SHOULD recognize all the syntaxes described in this section.
-
-6.1. Attribute Type Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
-
- Values in this syntax are encoded according to the BNF given at the
- start of section 4.2. For example,
-
- ( 2.5.4.0 NAME 'objectClass'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-6.2. Binary
-
- ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
-
- Values in this syntax are encoded as described in section 4.3.1.
-
-6.3. Bit String
-
- ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
-
- Values in this syntax are encoded according to the following BNF:
-
- bitstring = "'" *binary-digit "'B"
-
- binary-digit = "0" / "1"
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 16]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Example:
-
- '0101111101'B
-
-6.4. Boolean
-
- ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
-
- Values in this syntax are encoded according to the following BNF:
-
- boolean = "TRUE" / "FALSE"
-
- Boolean values have an encoding of "TRUE" if they are logically true,
- and have an encoding of "FALSE" otherwise.
-
-6.5. Certificate
-
- ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
-
- Because of the changes from X.509(1988) and X.509(1993) and
- additional changes to the ASN.1 definition to support certificate
- extensions, no string representation is defined, and values in this
- syntax MUST only be transferred using the binary encoding, by
- requesting or returning the attributes with descriptions
- "userCertificate;binary" or "caCertificate;binary". The BNF notation
- in RFC 1778 for "User Certificate" is not recommended to be used.
-
-6.6. Certificate List
-
- ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
-
- Because of the incompatibility of the X.509(1988) and X.509(1993)
- definitions of revocation lists, values in this syntax MUST only be
- transferred using a binary encoding, by requesting or returning the
- attributes with descriptions "certificateRevocationList;binary" or
- "authorityRevocationList;binary". The BNF notation in RFC 1778 for
- "Authority Revocation List" is not recommended to be used.
-
-6.7. Certificate Pair
-
- ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
-
- Because the Certificate is being carried in binary, values in this
- syntax MUST only be transferred using a binary encoding, by
- requesting or returning the attribute description
- "crossCertificatePair;binary". The BNF notation in RFC 1778 for
- "Certificate Pair" is not recommended to be used.
-
-
-
-
-Wahl, et. al. Standards Track [Page 17]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.8. Country String
-
- ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
-
- A value in this syntax is encoded the same as a value of Directory
- String syntax. Note that this syntax is limited to values of exactly
- two printable string characters, as listed in ISO 3166 [14].
-
- CountryString = p p
-
- Example:
- US
-
-6.9. DN
-
- ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
-
- Values in the Distinguished Name syntax are encoded to have the
- representation defined in [5]. Note that this representation is not
- reversible to an ASN.1 encoding used in X.500 for Distinguished
- Names, as the CHOICE of any DirectoryString element in an RDN is no
- longer known.
-
- Examples (from [5]):
- CN=Steve Kille,O=Isode Limited,C=GB
- OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
- CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
- CN=Before\0DAfter,O=Test,C=GB
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
- SN=Lu\C4\8Di\C4\87
-
-6.10. Directory String
-
- ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
-
- A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
- superset of Unicode). Servers and clients MUST be prepared to
- receive encodings of arbitrary Unicode characters, including
- characters not presently assigned to any character set.
-
- For characters in the PrintableString form, the value is encoded as
- the string value itself.
-
- If it is of the TeletexString form, then the characters are
- transliterated to their equivalents in UniversalString, and encoded
- in UTF-8 [9].
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 18]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- If it is of the UniversalString or BMPString forms [10], UTF-8 is
- used to encode them.
-
- Note: the form of DirectoryString is not indicated in protocol unless
- the attribute value is carried in binary. Servers which convert to
- DAP MUST choose an appropriate form. Servers MUST NOT reject values
- merely because they contain legal Unicode characters outside of the
- range of printable ASCII.
-
- Example:
-
- This is a string of DirectoryString containing #!%#@
-
-6.11. DIT Content Rule Description
-
-
- ues in this syntax are encoded according to the following BNF.
- lementors should note that future versions of this document
- have expanded this BNF to include additional terms.
-
- 0
-
- DITContentRuleDescription = "("
- numericoid ; Structural ObjectClass identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" ]
- [ "AUX" oids ] ; Auxiliary ObjectClasses
- [ "MUST" oids ] ; AttributeType identifiers
- [ "MAY" oids ] ; AttributeType identifiers
- [ "NOT" oids ] ; AttributeType identifiers
- ")"
-
- 0 2. Facsimile Telephone Number
-
- 3
-
- ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
-
- Values in this syntax are encoded according to the following BNF:
-
- fax-number = printablestring [ "$" faxparameters ]
-
- faxparameters = faxparm / ( faxparm "$" faxparameters )
-
- faxparm = "twoDimensional" / "fineResolution" /
- "unlimitedLength" /
- "b4Length" / "a3Width" / "b4Width" / "uncompressed"
-
-
-
-Wahl, et. al. Standards Track [Page 19]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- In the above, the first printablestring is the telephone number,
- based on E.123 [15], and the faxparm tokens represent fax parameters.
-
-6.13. Fax
-
- ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
-
- Values in this syntax are encoded as if they were octet strings
- containing Group 3 Fax images as defined in [7].
-
-6.14. Generalized Time
-
- ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
-
- Values in this syntax are encoded as printable strings, represented
- as specified in X.208. Note that the time zone must be specified.
- It is strongly recommended that GMT time be used. For example,
-
- 199412161032Z
-
-6.15. IA5 String
-
- ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
-
- The encoding of a value in this syntax is the string value itself.
-
-6.16. INTEGER
-
- ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
-
- Values in this syntax are encoded as the decimal representation of
- their values, with each decimal digit represented by the its
- character equivalent. So the number 1321 is represented by the
- character string "1321".
-
-6.17. JPEG
-
- ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
-
- Values in this syntax are encoded as strings containing JPEG images
- in the JPEG File Interchange Format (JFIF), as described in [8].
-
-6.18. Matching Rule Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
-
- Values of type matchingRules are encoded as strings according to the
- BNF given in section 4.5.
-
-
-
-Wahl, et. al. Standards Track [Page 20]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.19. Matching Rule Use Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
- )
-
- Values of type matchingRuleUse are encoded as strings according to
- the BNF given in section 4.5.
-
-6.20. MHS OR Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
-
- Values in this syntax are encoded as strings, according to the format
- defined in [11].
-
-6.21. Name And Optional UID
-
- ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
-
- Values in this syntax are encoded according to the following BNF:
-
- NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
-
- Although the '#' character may occur in a string representation of a
- distinguished name, no additional special quoting is done. This
- syntax has been added subsequent to RFC 1778.
-
- Example:
-
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
-
-6.22. Name Form Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
-
- Values in this syntax are encoded according to the following BNF.
- Implementors should note that future versions of this document may
- have expanded this BNF to include additional terms.
-
- NameFormDescription = "(" whsp
- numericoid whsp ; NameForm identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "OC" woid ; Structural ObjectClass
- "MUST" oids ; AttributeTypes
- [ "MAY" oids ] ; AttributeTypes
- whsp ")"
-
-
-
-Wahl, et. al. Standards Track [Page 21]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.23. Numeric String
-
- ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
-
- The encoding of a string in this syntax is the string value itself.
- Example:
-
- 1997
-
-6.24. Object Class Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
-
- Values in this syntax are encoded according to the BNF in section
- 4.4.
-
-6.25. OID
-
- ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
-
- Values in the Object Identifier syntax are encoded according to
- the BNF in section 4.1 for "oid".
-
- Example:
-
- 1.2.3.4
- cn
-
-6.26. Other Mailbox
-
- ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
-
- Values in this syntax are encoded according to the following BNF:
-
- otherMailbox = mailbox-type "$" mailbox
-
- mailbox-type = printablestring
-
- mailbox = <an encoded IA5 String>
-
- In the above, mailbox-type represents the type of mail system in
- which the mailbox resides, for example "MCIMail"; and mailbox is the
- actual mailbox in the mail system defined by mailbox-type.
-
-6.27. Postal Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
-
-
-
-
-Wahl, et. al. Standards Track [Page 22]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Values in this syntax are encoded according to the following BNF:
-
- postal-address = dstring *( "$" dstring )
-
- In the above, each dstring component of a postal address value is
- encoded as a value of type Directory String syntax. Backslashes and
- dollar characters, if they occur in the component, are quoted as
- described in section 4.3. Many servers limit the postal address to
- six lines of up to thirty characters.
-
- Example:
-
- 1234 Main St.$Anytown, CA 12345$USA
- \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
-
-6.28. Presentation Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
-
- Values in this syntax are encoded with the representation described
- in RFC 1278 [6].
-
-6.29. Printable String
-
- ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
-
- The encoding of a value in this syntax is the string value itself.
- PrintableString is limited to the characters in production p of
- section 4.1.
-
- Example:
-
- This is a PrintableString
-
-6.30. Telephone Number
-
- ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
-
- Values in this syntax are encoded as if they were Printable String
- types. Telephone numbers are recommended in X.520 to be in
- international form, as described in E.123 [15].
-
- Example:
-
- +1 512 305 0280
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 23]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.31. UTC Time
-
- ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
-
- Values in this syntax are encoded as if they were printable strings
- with the strings containing a UTCTime value. This is historical; new
- attribute definitions SHOULD use GeneralizedTime instead.
-
-6.32. LDAP Syntax Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
-
- Values in this syntax are encoded according to the BNF in section
- 4.3.3.
-
-6.33. DIT Structure Rule Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
- )
-
- Values with this syntax are encoded according to the following BNF:
-
- DITStructureRuleDescription = "(" whsp
- ruleidentifier whsp ; DITStructureRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "FORM" woid whsp ; NameForm
- [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
- ")"
-
- ruleidentifier = integer
-
- ruleidentifiers = ruleidentifier |
- "(" whsp ruleidentifierlist whsp ")"
-
- ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
-
-7. Object Classes
-
- Servers SHOULD recognize all the names of standard classes from
- section 7 of [12].
-
-7.1. Extensible Object Class
-
- The extensibleObject object class, if present in an entry, permits
- that entry to optionally hold any attribute. The MAY attribute list
- of this class is implicitly the set of all attributes.
-
-
-
-Wahl, et. al. Standards Track [Page 24]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
- SUP top AUXILIARY )
-
- The mandatory attributes of the other object classes of this entry
- are still required to be present.
-
- Note that not all servers will implement this object class, and those
- which do not will reject requests to add entries which contain this
- object class, or modify an entry to add this object class.
-
-7.2. subschema
-
- This object class is used in the subschema entry.
-
- ( 2.5.20.1 NAME 'subschema' AUXILIARY
- MAY ( dITStructureRules $ nameForms $ ditContentRules $
- objectClasses $ attributeTypes $ matchingRules $
- matchingRuleUse ) )
-
- The ldapSyntaxes operational attribute may also be present in
- subschema entries.
-
-8. Matching Rules
-
- Servers which implement the extensibleMatch filter SHOULD allow all
- the matching rules listed in this section to be used in the
- extensibleMatch. In general these servers SHOULD allow matching
- rules to be used with all attribute types known to the server, when
- the assertion syntax of the matching rule is the same as the value
- syntax of the attribute.
-
- Servers MAY implement additional matching rules.
-
-8.1. Matching Rules used in Equality Filters
-
- Servers SHOULD be capable of performing the following matching rules.
-
- For all these rules, the assertion syntax is the same as the value
- syntax.
-
- ( 2.5.13.0 NAME 'objectIdentifierMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- If the client supplies a filter using an objectIdentifierMatch whose
- matchValue oid is in the "descr" form, and the oid is not recognized
- by the server, then the filter is Undefined.
-
- ( 2.5.13.1 NAME 'distinguishedNameMatch'
-
-
-
-Wahl, et. al. Standards Track [Page 25]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- ( 2.5.13.2 NAME 'caseIgnoreMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- ( 2.5.13.8 NAME 'numericStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- ( 2.5.13.11 NAME 'caseIgnoreListMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- ( 2.5.13.14 NAME 'integerMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- ( 2.5.13.16 NAME 'bitStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- ( 2.5.13.20 NAME 'telephoneNumberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- ( 2.5.13.22 NAME 'presentationAddressMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
-
- ( 2.5.13.23 NAME 'uniqueMemberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
- ( 2.5.13.24 NAME 'protocolInformationMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
-
- ( 2.5.13.27 NAME 'generalizedTimeMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- When performing the caseIgnoreMatch, caseIgnoreListMatch,
- telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
- multiple adjoining whitespace characters are treated the same as an
- individual space, and leading and trailing whitespace is ignored.
-
- Clients MUST NOT assume that servers are capable of transliteration
- of Unicode values.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 26]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-8.2. Matching Rules used in Inequality Filters
-
- Servers SHOULD be capable of performing the following matching rules,
- which are used in greaterOrEqual and lessOrEqual filters.
-
- ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The sort ordering for a caseIgnoreOrderingMatch is implementation-
- dependent.
-
-8.3. Syntax and Matching Rules used in Substring Filters
-
- The Substring Assertion syntax is used only as the syntax of
- assertion values in the extensible match. It is not used as the
- syntax of attributes, or in the substring filter.
-
- ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
-
- The Substring Assertion is encoded according to the following BNF:
-
- substring = [initial] any [final]
- initial = value
- any = "*" *(value "*")
- final = value
-
- The <value> production is UTF-8 encoded string. Should the backslash
- or asterix characters be present in a production of <value>, they are
- quoted as described in section 4.3.
-
- Servers SHOULD be capable of performing the following matching rules,
- which are used in substring filters.
-
- ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 27]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-8.4. Matching Rules for Subschema Attributes
-
- Servers which allow subschema entries to be modified by clients MUST
- support the following matching rules, as they are the equality
- matching rules for several of the subschema attributes.
-
- ( 2.5.13.29 NAME 'integerFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- Implementors should note that the assertion syntax of these matching
- rules, an INTEGER or OID, is different from the value syntax of
- attributes for which this is the equality matching rule.
-
- If the client supplies an extensible filter using an
- objectIdentifierFirstComponentMatch whose matchValue is in the
- "descr" form, and the OID is not recognized by the server, then the
- filter is Undefined.
-
-9. Security Considerations
-
-9.1. Disclosure
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
-9.2. Use of Attribute Values in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER or DER form. An example of a situation which requires the
- DER form of a distinguished name is the verification of an X.509
- certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string CN=Sam. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation CN=Sam.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a value to LDAP format. Instead it SHOULD use the
-
-
-
-Wahl, et. al. Standards Track [Page 28]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Binary syntax.
-
-10. Acknowledgements
-
- This document is based substantially on RFC 1778, written by Tim
- Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
-
- Many of the attribute syntax encodings defined in this and related
- documents are adapted from those used in the QUIPU and the IC R3
- X.500 implementations. The contributions of the authors of both these
- implementations in the specification of syntaxes are gratefully
- acknowledged.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 29]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-11. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 West Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372-3160
- EMail: M.Wahl@critical-angle.com
-
- Andy Coulbeck
- Isode Inc.
- 9390 Research Blvd Suite 305
- Austin, TX 78759
- USA
-
- Phone: +1 512 231-8993
- EMail: A.Coulbeck@isode.com
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd, MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
- Steve Kille
- Isode Limited
- The Dome, The Square
- Richmond
- TW9 1DT
- UK
-
- Phone: +44-181-332-9091
- EMail: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 30]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-12. Bibliography
-
- [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] The Directory: Selected Attribute Types. ITU-T Recommendation
- X.520, 1993.
-
- [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
-
- [6] Kille, S., "A String Representation for Presentation Addresses",
- RFC 1278, November 1991.
-
- [7] Terminal Equipment and Protocols for Telematic Services -
- Standardization of Group 3 facsimile apparatus for document
- transmission. CCITT, Recommendation T.4.
-
- [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton,
- C-Cube Microsystems, Milpitas, CA, September 1, 1992.
-
- [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
- [10] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
- 1993 (With amendments).
-
- [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
- and RFC 822", RFC 1327, May 1992.
-
- [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [14] ISO 3166, "Codes for the representation of names of countries".
-
- [15] ITU-T Rec. E.123, Notation for national and international
- telephone numbers, 1988.
-
-
-
-
-Wahl, et. al. Standards Track [Page 31]
-\f
-RFC 2252 LADPv3 Attributes December 1997
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 32]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2253 Critical Angle Inc.
-Obsoletes: 1779 S. Kille
-Category: Standards Track Isode Ltd.
- T. Howes
- Netscape Communications Corp.
- December 1997
-
-
- Lightweight Directory Access Protocol (v3):
- UTF-8 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.
-
-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. Proposed Standard [Page 1]
-\f
-RFC 2253 LADPv3 Distinguished Names 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.
-
-Abstract
-
- The X.500 Directory uses distinguished names as the primary keys to
- entries in the directory. Distinguished Names are encoded in ASN.1
- in the X.500 Directory protocols. In the Lightweight Directory
- Access Protocol, a string representation of distinguished names is
- transferred. This specification defines the string format for
- representing names, which is designed to give a clean representation
- of commonly used distinguished names, while being able to represent
- any distinguished name.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [6].
-
-1. Background
-
- This specification assumes familiarity with X.500 [1], and the
- concept of Distinguished Name. It is important to have a common
- format to be able to unambiguously represent a distinguished name.
- The primary goal of this specification is ease of encoding and
- decoding. A secondary goal is to have names that are human readable.
- It is not expected that LDAP clients with a human user interface
- would display these strings directly to the user, but would most
- likely be performing translations (such as expressing attribute type
- names in one of the local national languages).
-
-2. Converting DistinguishedName from ASN.1 to a String
-
- In X.501 [2] the ASN.1 structure of distinguished name is defined as:
-
- DistinguishedName ::= RDNSequence
-
- RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 2]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
- AttributeTypeAndValue
-
- AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
- The following sections define the algorithm for converting from an
- ASN.1 structured representation to a UTF-8 string representation.
-
-2.1. Converting the RDNSequence
-
- If the RDNSequence is an empty sequence, the result is the empty or
- zero length string.
-
- Otherwise, the output consists of the string encodings of each
- RelativeDistinguishedName in the RDNSequence (according to 2.2),
- starting with the last element of the sequence and moving backwards
- toward the first.
-
- The encodings of adjoining RelativeDistinguishedNames are separated
- by a comma character (',' ASCII 44).
-
-2.2. Converting RelativeDistinguishedName
-
- When converting from an ASN.1 RelativeDistinguishedName to a string,
- the output consists of the string encodings of each
- AttributeTypeAndValue (according to 2.3), in any order.
-
- Where there is a multi-valued RDN, the outputs from adjoining
- AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
- character.
-
-2.3. Converting AttributeTypeAndValue
-
- The AttributeTypeAndValue is encoded as the string representation of
- the AttributeType, followed by an equals character ('=' ASCII 61),
- followed by the string representation of the AttributeValue. The
- encoding of the AttributeValue is given in section 2.4.
-
- If the AttributeType is in a published table of attribute types
- associated with LDAP [4], then the type name string from that table
- is used, otherwise it is encoded as the dotted-decimal encoding of
- the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
- described in [3]. As an example, strings for a few of the attribute
- types frequently seen in RDNs include:
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 3]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- String X.500 AttributeType
- ------------------------------
- CN commonName
- L localityName
- ST stateOrProvinceName
- O organizationName
- OU organizationalUnitName
- C countryName
- STREET streetAddress
- DC domainComponent
- UID userid
-
-2.4. Converting an AttributeValue from ASN.1 to a String
-
- If the AttributeValue is of a type which does not have a string
- representation defined for it, then it is simply encoded as an
- octothorpe character ('#' ASCII 35) followed by the hexadecimal
- representation of each of the bytes of the BER encoding of the X.500
- AttributeValue. This form SHOULD be used if the AttributeType is of
- the dotted-decimal form.
-
- Otherwise, if the AttributeValue is of a type which has a string
- representation, the value is converted first to a UTF-8 string
- according to its syntax specification (see for example section 6 of
- [4]).
-
- If the UTF-8 string does not have any of the following characters
- which need escaping, then that string can be used as the string
- representation of the value.
-
- o a space or "#" character occurring at the beginning of the
- string
-
- o a space character occurring at the end of the string
-
- o one of the characters ",", "+", """, "\", "<", ">" or ";"
-
- Implementations MAY escape other characters.
-
- If a character to be escaped is one of the list shown above, then it
- is prefixed by a backslash ('\' ASCII 92).
-
- Otherwise the character to be escaped is replaced by a backslash and
- two hex digits, which form a single byte in the code of the
- character.
-
- Examples of the escaping mechanism are shown in section 5.
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 4]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-3. Parsing a String back to a Distinguished Name
-
- The structure of the string is specified in a BNF grammar, based on
- the grammar defined in RFC 822 [5]. Server implementations parsing a
- DN string generated by an LDAPv2 client MUST also accept (and ignore)
- the variants given in section 4 of this document.
-
-distinguishedName = [name] ; may be empty string
-
-name = name-component *("," name-component)
-
-name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
-
-attributeTypeAndValue = attributeType "=" attributeValue
-
-attributeType = (ALPHA 1*keychar) / oid
-keychar = ALPHA / DIGIT / "-"
-
-oid = 1*DIGIT *("." 1*DIGIT)
-
-attributeValue = string
-
-string = *( stringchar / pair )
- / "#" hexstring
- / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
-
-quotechar = <any character except "\" or QUOTATION >
-
-special = "," / "=" / "+" / "<" / ">" / "#" / ";"
-
-pair = "\" ( special / "\" / QUOTATION / hexpair )
-stringchar = <any character except one of special, "\" or QUOTATION >
-
-hexstring = 1*hexpair
-hexpair = hexchar hexchar
-
-hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
- / "a" / "b" / "c" / "d" / "e" / "f"
-
-ALPHA = <any ASCII alphabetic character>
- ; (decimal 65-90 and 97-122)
-DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
-QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 5]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-4. Relationship with RFC 1779 and LDAPv2
-
- The syntax given in this document is more restrictive than the syntax
- in RFC 1779. Implementations parsing a string generated by an LDAPv2
- client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
- however, generate any of the RFC 1779 encodings which are not
- described above in section 2.
-
- Implementations MUST allow a semicolon character to be used instead
- of a comma to separate RDNs in a distinguished name, and MUST also
- allow whitespace characters to be present on either side of the comma
- or semicolon. The whitespace characters are ignored, and the
- semicolon replaced with a comma.
-
- Implementations MUST allow an oid in the attribute type to be
- prefixed by one of the character strings "oid." or "OID.".
-
- Implementations MUST allow for space (' ' ASCII 32) characters to be
- present between name-component and ',', between attributeTypeAndValue
- and '+', between attributeType and '=', and between '=' and
- attributeValue. These space characters are ignored when parsing.
-
- Implementations MUST allow a value to be surrounded by quote ('"'
- ASCII 34) characters, which are not part of the value. Inside the
- quoted value, the following characters can occur without any
- escaping:
-
- ",", "=", "+", "<", ">", "#" and ";"
-
-5. Examples
-
- This notation is designed to be convenient for common forms of name.
- This section gives a few examples of distinguished names written
- using this notation. First is a name containing three relative
- distinguished names (RDNs):
-
- CN=Steve Kille,O=Isode Limited,C=GB
-
- Here is an example name containing three RDNs, in which the first RDN
- is multi-valued:
-
- OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
-
- This example shows the method of quoting of a comma in an
- organization name:
-
- CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 6]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- An example name in which a value contains a carriage return
- character:
-
- CN=Before\0DAfter,O=Test,C=GB
-
- An example name in which an RDN was of an unrecognized type. The
- value is the BER encoding of an OCTET STRING containing two bytes
- 0x48 and 0x69.
-
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
-
- Finally, an example of an RDN surname value consisting of 5 letters:
-
- Unicode Letter Description 10646 code UTF-8 Quoted
- =============================== ========== ====== =======
- LATIN CAPITAL LETTER L U0000004C 0x4C L
- LATIN SMALL LETTER U U00000075 0x75 u
- LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
- LATIN SMALL LETTER I U00000069 0x69 i
- LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
-
- Could be written in printable ASCII (useful for debugging purposes):
-
- SN=Lu\C4\8Di\C4\87
-
-6. References
-
- [1] The Directory -- overview of concepts, models and services.
- ITU-T Rec. X.500(1993).
-
- [2] The Directory -- Models. ITU-T Rec. X.501(1993).
-
- [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997.
-
- [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119.
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 7]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-7. Security Considerations
-
-7.1. Disclosure
-
- Distinguished Names typically consist of descriptive information
- about the entries they name, which can be people, organizations,
- devices or other real-world objects. This frequently includes some
- of the following kinds of information:
-
- - the common name of the object (i.e. a person's full name)
- - an email or TCP/IP address
- - its physical location (country, locality, city, street address)
- - organizational attributes (such as department name or affiliation)
-
- Most countries have privacy laws regarding the publication of
- information about people.
-
-7.2. Use of Distinguished Names in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER or DER form. An example of a situation which requires the
- DER form of a distinguished name is the verification of an X.509
- certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string CN=Sam. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation CN=Sam.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a distinguished name to the LDAP format. Instead,
- they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
- as described in the first paragraph of section 2.4.
-
-8. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 W. Braker Lane #502-385
- Austin, TX 78759
- USA
-
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 8]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- Steve Kille
- Isode Ltd.
- The Dome
- The Square
- Richmond, Surrey
- TW9 1DT
- England
-
- Phone: +44-181-332-9091
- EMail: S.Kille@ISODE.COM
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd, MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 9]
-\f
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 2254 Netscape Communications Corp.
-Category: Standards Track December 1997
-
-
- The String Representation of LDAP Search Filters
-
-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.
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 1]
-\f
-RFC 2254 String Representation of LDAP 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.
-
-2. Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [1] defines a
- network representation of a search filter transmitted to an LDAP
- server. Some applications may find it useful to have a common way of
- representing these search filters in a human-readable form. This
- document defines a human-readable string format for representing LDAP
- search filters.
-
- This document replaces RFC 1960, extending the string LDAP filter
- definition to include support for LDAP version 3 extended match
- filters, and including support for representing the full range of
- possible LDAP search filters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 2]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
-3. LDAP Search Filter Definition
-
- An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
- follows:
-
- 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] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion
- }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString
- }
- }
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- attributeValue AttributeValue
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleID OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE
- }
-
- AttributeDescription ::= LDAPString
-
- AttributeValue ::= OCTET STRING
-
- MatchingRuleID ::= LDAPString
-
- AssertionValue ::= OCTET STRING
-
- LDAPString ::= OCTET STRING
-
-
-
-Howes Standards Track [Page 3]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
- where the LDAPString above is limited to the UTF-8 encoding of the
- ISO 10646 character set [4]. The AttributeDescription is a string
- representation of the attribute description and is defined in [1].
- The AttributeValue and AssertionValue OCTET STRING have the form
- defined in [2]. The Filter is encoded for transmission over a
- network using the Basic Encoding Rules defined in [3], with
- simplifications described in [1].
-
-4. String Search Filter Definition
-
- The string representation of an LDAP search filter is defined by the
- following grammar, following the ABNF notation defined in [5]. The
- filter format uses a prefix notation.
-
- filter = "(" filtercomp ")"
- filtercomp = and / or / not / item
- and = "&" filterlist
- or = "|" filterlist
- not = "!" filter
- filterlist = 1*filter
- item = simple / present / substring / extensible
- simple = attr filtertype value
- filtertype = equal / approx / greater / less
- equal = "="
- approx = "~="
- greater = ">="
- less = "<="
- extensible = attr [":dn"] [":" matchingrule] ":=" value
- / [":dn"] ":" matchingrule ":=" value
- present = attr "=*"
- substring = attr "=" [initial] any [final]
- initial = value
- any = "*" *(value "*")
- final = value
- attr = AttributeDescription from Section 4.1.5 of [1]
- matchingrule = MatchingRuleId from Section 4.1.9 of [1]
- value = AttributeValue from Section 4.1.6 of [1]
-
- The attr, matchingrule, and value constructs are as described in the
- corresponding section of [1] given above.
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 4]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
- If a value should contain any of the following characters
-
- Character ASCII value
- ---------------------------
- * 0x2a
- ( 0x28
- ) 0x29
- \ 0x5c
- NUL 0x00
-
- the character must be encoded as the backslash '\' character (ASCII
- 0x5c) followed by the two hexadecimal digits representing the ASCII
- value of the encoded character. The case of the two hexadecimal
- digits is not significant.
-
- This simple escaping mechanism eliminates filter-parsing ambiguities
- and allows any filter that can be represented in LDAP to be
- represented as a NUL-terminated string. Other characters besides the
- ones listed above may be escaped using this mechanism, for example,
- non-printing characters.
-
- For example, the filter checking whether the "cn" attribute contained
- a value with the character "*" anywhere in it would be represented as
- "(cn=*\2a*)".
-
- Note that although both the substring and present productions in the
- grammar above can produce the "attr=*" construct, this construct is
- used only to denote a presence filter.
-
-5. Examples
-
- This section gives a few examples of search filters written using
- this notation.
-
- (cn=Babs Jensen)
- (!(cn=Tim Howes))
- (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
- (o=univ*of*mich*)
-
- The following examples illustrate the use of extensible matching.
-
- (cn:1.2.3.4.5:=Fred Flintstone)
- (sn:dn:2.4.6.8.10:=Barney Rubble)
- (o:dn:=Ace Industry)
- (:dn:2.4.6.8.10:=Dino)
-
-
-
-
-
-
-Howes Standards Track [Page 5]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
- The second example illustrates the use of the ":dn" notation to
- indicate that matching rule "2.4.6.8.10" should be used when making
- comparisons, and that the attributes of an entry's distinguished name
- should be considered part of the entry when evaluating the match.
-
- The third example denotes an equality match, except that DN
- components should be considered part of the entry when doing the
- match.
-
- The fourth example is a filter that should be applied to any
- attribute supporting the matching rule given (since the attr has been
- left off). Attributes supporting the matching rule contained in the
- DN should also be considered.
-
- The following examples illustrate the use of the escaping mechanism.
-
- (o=Parens R Us \28for all your parenthetical needs\29)
- (cn=*\2A*)
- (filename=C:\5cMyFile)
- (bin=\00\00\00\04)
- (sn=Lu\c4\8di\c4\87)
-
- The first example shows the use of the escaping mechanism to
- represent parenthesis characters. The second shows how to represent a
- "*" in a value, preventing it from being interpreted as a substring
- indicator. The third illustrates the escaping of the backslash
- character.
-
- The fourth example shows a filter searching for the four-byte value
- 0x00000004, illustrating the use of the escaping mechanism to
- represent arbitrary data, including NUL characters.
-
- The final example illustrates the use of the escaping mechanism to
- represent various non-ASCII UTF-8 characters.
-
-6. Security Considerations
-
- This memo describes a string representation of LDAP search filters.
- While the representation itself has no known security implications,
- LDAP search filters do. They are interpreted by LDAP servers to
- select entries from which data is retrieved. LDAP servers should
- take care to protect the data they maintain from unauthorized access.
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 6]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
-7. References
-
- [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
- 2252, December 1997.
-
- [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
- Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
-
- [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
- [5] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
-8. Author's Address
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Road
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3419
- EMail: howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 7]
-\f
-RFC 2254 String Representation of LDAP December 1997
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 2255 M. Smith
-Category: Standards Track Netscape Communications Corp.
- December 1997
-
-
- The LDAP URL Format
-
-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.
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 1]
-\f
-RFC 2255 LDAP URL Format 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.
-
-2. Abstract
-
- LDAP is the Lightweight Directory Access Protocol, defined in [1],
- [2] and [3]. This document describes a format for an LDAP Uniform
- Resource Locator. The format describes an LDAP search operation to
- perform to retrieve information from an LDAP directory. This document
- replaces RFC 1959. It updates the LDAP URL format for version 3 of
- LDAP and clarifies how LDAP URLs are resolved. This document also
- defines an extension mechanism for LDAP URLs, so that future
- documents can extend their functionality, for example, to provide
- access to new LDAPv3 extensions as they are defined.
-
- The key words "MUST", "MAY", and "SHOULD" used in this document are
- to be interpreted as described in [6].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 2]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
-3. URL Definition
-
- An LDAP URL begins with the protocol prefix "ldap" and is defined by
- the following grammar.
-
- ldapurl = scheme "://" [hostport] ["/"
- [dn ["?" [attributes] ["?" [scope]
- ["?" [filter] ["?" extensions]]]]]]
- scheme = "ldap"
- attributes = attrdesc *("," attrdesc)
- scope = "base" / "one" / "sub"
- dn = distinguishedName from Section 3 of [1]
- hostport = hostport from Section 5 of RFC 1738 [5]
- attrdesc = AttributeDescription from Section 4.1.5 of [2]
- filter = filter from Section 4 of [4]
- extensions = extension *("," extension)
- extension = ["!"] extype ["=" exvalue]
- extype = token / xtoken
- exvalue = LDAPString from section 4.1.2 of [2]
- token = oid from section 4.1 of [3]
- xtoken = ("X-" / "x-") token
-
- The "ldap" prefix indicates an entry or entries residing in the LDAP
- server running on the given hostname at the given portnumber. The
- default LDAP port is TCP port 389. If no hostport is given, the
- client must have some apriori knowledge of an appropriate LDAP server
- to contact.
-
- The dn is an LDAP Distinguished Name using the string format
- described in [1]. It identifies the base object of the LDAP search.
-
- ldapurl = scheme "://" [hostport] ["/"
- [dn ["?" [attributes] ["?" [scope]
- ["?" [filter] ["?" extensions]]]]]]
- scheme = "ldap"
- attributes = attrdesc *("," attrdesc)
- scope = "base" / "one" / "sub"
- dn = distinguishedName from Section 3 of [1]
- hostport = hostport from Section 5 of RFC 1738 [5]
- attrdesc = AttributeDescription from Section 4.1.5 of [2]
- filter = filter from Section 4 of [4]
- extensions = extension *("," extension)
- extension = ["!"] extype ["=" exvalue]
- extype = token / xtoken
- exvalue = LDAPString from section 4.1.2 of [2]
- token = oid from section 4.1 of [3]
- xtoken = ("X-" / "x-") token
-
-
-
-
-Howes & Smith Standards Track [Page 3]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- The "ldap" prefix indicates an entry or entries residing in the LDAP
- server running on the given hostname at the given portnumber. The
- default LDAP port is TCP port 389. If no hostport is given, the
- client must have some apriori knowledge of an appropriate LDAP server
- to contact.
-
- The dn is an LDAP Distinguished Name using the string format
- described in [1]. It identifies the base object of the LDAP search.
-
- The attributes construct is used to indicate which attributes should
- be returned from the entry or entries. Individual attrdesc names are
- as defined for AttributeDescription in [2]. If the attributes part
- is omitted, all user attributes of the entry or entries should be
- requested (e.g., by setting the attributes field
- AttributeDescriptionList in the LDAP search request to a NULL list,
- or (in LDAPv3) by requesting the special attribute name "*").
-
- The scope construct is used to specify the scope of the search to
- perform in the given LDAP server. The allowable scopes are "base"
- for a base object search, "one" for a one-level search, or "sub" for
- a subtree search. If scope is omitted, a scope of "base" is assumed.
-
- The filter is used to specify the search filter to apply to entries
- within the specified scope during the search. It has the format
- specified in [4]. If filter is omitted, a filter of
- "(objectClass=*)" is assumed.
-
- The extensions construct provides the LDAP URL with an extensibility
- mechanism, allowing the capabilities of the URL to be extended in the
- future. Extensions are a simple comma-separated list of type=value
- pairs, where the =value portion MAY be omitted for options not
- requiring it. Each type=value pair is a separate extension. These
- LDAP URL extensions are not necessarily related to any of the LDAPv3
- extension mechanisms. Extensions may be supported or unsupported by
- the client resolving the URL. An extension prefixed with a '!'
- character (ASCII 33) is critical. An extension not prefixed with a '
- !' character is non-critical.
-
- If an extension is supported by the client, the client MUST obey the
- extension if the extension is critical. The client SHOULD obey
- supported extensions that are non-critical.
-
- If an extension is unsupported by the client, the client MUST NOT
- process the URL if the extension is critical. If an unsupported
- extension is non-critical, the client MUST ignore the extension.
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 4]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- If a critical extension cannot be processed successfully by the
- client, the client MUST NOT process the URL. If a non-critical
- extension cannot be processed successfully by the client, the client
- SHOULD ignore the extension.
-
- Extension types prefixed by "X-" or "x-" are reserved for use in
- bilateral agreements between communicating parties. Other extension
- types MUST be defined in this document, or in other standards-track
- documents.
-
- One LDAP URL extension is defined in this document in the next
- section. Other documents or a future version of this document MAY
- define other extensions.
-
- Note that any URL-illegal characters (e.g., spaces), URL special
- characters (as defined in section 2.2 of RFC 1738) and the reserved
- character '?' (ASCII 63) occurring inside a dn, filter, or other
- element of an LDAP URL MUST be escaped using the % method described
- in RFC 1738 [5]. If a comma character ',' occurs inside an extension
- value, the character MUST also be escaped using the % method.
-
-4. The Bindname Extension
-
- This section defines an LDAP URL extension for representing the
- distinguished name for a client to use when authenticating to an LDAP
- directory during resolution of an LDAP URL. Clients MAY implement
- this extension.
-
- The extension type is "bindname". The extension value is the
- distinguished name of the directory entry to authenticate as, in the
- same form as described for dn in the grammar above. The dn may be the
- NULL string to specify unauthenticated access. The extension may be
- either critical (prefixed with a '!' character) or non-critical (not
- prefixed with a '!' character).
-
- If the bindname extension is critical, the client resolving the URL
- MUST authenticate to the directory using the given distinguished name
- and an appropriate authentication method. Note that for a NULL
- distinguished name, no bind MAY be required to obtain anonymous
- access to the directory. If the extension is non-critical, the client
- MAY bind to the directory using the given distinguished name.
-
-5. URL Processing
-
- This section describes how an LDAP URL SHOULD be resolved by a
- client.
-
-
-
-
-
-Howes & Smith Standards Track [Page 5]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- First, the client obtains a connection to the LDAP server referenced
- in the URL, or an LDAP server of the client's choice if no LDAP
- server is explicitly referenced. This connection MAY be opened
- specifically for the purpose of resolving the URL or the client MAY
- reuse an already open connection. The connection MAY provide
- confidentiality, integrity, or other services, e.g., using TLS. Use
- of security services is at the client's discretion if not specified
- in the URL.
-
- Next, the client authenticates itself to the LDAP server. This step
- is optional, unless the URL contains a critical bindname extension
- with a non-NULL value. If a bindname extension is given, the client
- proceeds according to the section above.
-
- If a bindname extension is not specified, the client MAY bind to the
- directory using a appropriate dn and authentication method of its own
- choosing (including NULL authentication).
-
- Next, the client performs the LDAP search operation specified in the
- URL. Additional fields in the LDAP protocol search request, such as
- sizelimit, timelimit, deref, and anything else not specified or
- defaulted in the URL specification, MAY be set at the client's
- discretion.
-
- Once the search has completed, the client MAY close the connection to
- the LDAP server, or the client MAY keep the connection open for
- future use.
-
-6. Examples
-
- The following are some example LDAP URLs using the format defined
- above. The first example is an LDAP URL referring to the University
- of Michigan entry, available from an LDAP server of the client's
- choosing:
-
- ldap:///o=University%20of%20Michigan,c=US
-
- The next example is an LDAP URL referring to the University of
- Michigan entry in a particular ldap server:
-
- ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
-
- Both of these URLs correspond to a base object search of the
- "o=University of Michigan, c=US" entry using a filter of
- "(objectclass=*)", requesting all attributes.
-
- The next example is an LDAP URL referring to only the postalAddress
- attribute of the University of Michigan entry:
-
-
-
-Howes & Smith Standards Track [Page 6]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
- c=US?postalAddress
-
- The corresponding LDAP search operation is the same as in the
- previous example, except that only the postalAddress attribute is
- requested.
-
- The next example is an LDAP URL referring to the set of entries found
- by querying the given LDAP server on port 6666 and doing a subtree
- search of the University of Michigan for any entry with a common name
- of "Babs Jensen", retrieving all attributes:
-
- ldap://host.com:6666/o=University%20of%20Michigan,
- c=US??sub?(cn=Babs%20Jensen)
-
- The next example is an LDAP URL referring to all children of the c=GB
- entry:
-
- ldap://ldap.itd.umich.edu/c=GB?objectClass?one
-
- The objectClass attribute is requested to be returned along with the
- entries, and the default filter of "(objectclass=*)" is used.
-
- The next example is an LDAP URL to retrieve the mail attribute for
- the LDAP entry named "o=Question?,c=US" is given below, illustrating
- the use of the escaping mechanism on the reserved character '?'.
-
- ldap://ldap.question.com/o=Question%3f,c=US?mail
-
- The next example illustrates the interaction between LDAP and URL
- quoting mechanisms.
-
- ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
-
- The filter in this example uses the LDAP escaping mechanism of \ to
- encode three zero or null bytes in the value. In LDAP, the filter
- would be written as (int=\00\00\00\04). Because the \ character must
- be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
-
- The final example shows the use of the bindname extension to specify
- the dn a client should use for authentication when resolving the URL.
-
- ldap:///??sub??bindname=cn=Manager%2co=Foo
- ldap:///??sub??!bindname=cn=Manager%2co=Foo
-
- The two URLs are the same, except that the second one marks the
- bindname extension as critical. Notice the use of the % encoding
- method to encode the comma in the distinguished name value in the
-
-
-
-Howes & Smith Standards Track [Page 7]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- bindname extension.
-
-7. Security Considerations
-
- General URL security considerations discussed in [5] are relevant for
- LDAP URLs.
-
- The use of security mechanisms when processing LDAP URLs requires
- particular care, since clients may encounter many different servers
- via URLs, and since URLs are likely to be processed automatically,
- without user intervention. A client SHOULD have a user-configurable
- policy about which servers to connect to using which security
- mechanisms, and SHOULD NOT make connections that are inconsistent
- with this policy.
-
- Sending authentication information, no matter the mechanism, may
- violate a user's privacy requirements. In the absence of specific
- policy permitting authentication information to be sent to a server,
- a client should use an anonymous connection. (Note that clients
- conforming to previous LDAP URL specifications, where all connections
- are anonymous and unprotected, are consistent with this
- specification; they simply have the default security policy.)
-
- Some authentication methods, in particular reusable passwords sent to
- the server, may reveal easily-abused information to the remote server
- or to eavesdroppers in transit, and should not be used in URL
- processing unless explicitly permitted by policy. Confirmation by
- the human user of the use of authentication information is
- appropriate in many circumstances. Use of strong authentication
- methods that do not reveal sensitive information is much preferred.
-
- The LDAP URL format allows the specification of an arbitrary LDAP
- search operation to be performed when evaluating the LDAP URL.
- Following an LDAP URL may cause unexpected results, for example, the
- retrieval of large amounts of data, the initiation of a long-lived
- search, etc. The security implications of resolving an LDAP URL are
- the same as those of resolving an LDAP search query.
-
-8. Acknowledgements
-
- The LDAP URL format was originally defined at the University of
- Michigan. This material is based upon work supported by the National
- Science Foundation under Grant No. NCR-9416667. The support of both
- the University of Michigan and the National Science Foundation is
- gratefully acknowledged.
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 8]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
- Several people have made valuable comments on this document. In
- particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
- their contributions.
-
-9. References
-
- [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished Names",
- RFC 2253, December 1997.
-
- [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
- 2252, December 1997.
-
- [4] Howes, T., "A String Representation of LDAP Search Filters", RFC
- 2254, December 1997.
-
- [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
- Locators (URL)," RFC 1738, December 1994.
-
- [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels," RFC 2119, March 1997.
-
-Authors' Addresses
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3419
- EMail: howes@netscape.com
-
-
- Mark Smith
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3477
- EMail: mcs@netscape.com
-
-
-
-
-
-Howes & Smith Standards Track [Page 9]
-\f
-RFC 2255 LDAP URL Format December 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2256 Critical Angle Inc.
-Category: Standards Track December 1997
-
-
- A Summary of the X.500(96) User Schema for use with LDAPv3
-
-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.
-
- 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.
-
-
-
-Wahl Standards Track [Page 1]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- 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.
-
-2. Abstract
-
- This document provides an overview of the attribute types and object
- classes defined by the ISO and ITU-T committees in the X.500
- documents, in particular those intended for use by directory clients.
- This is the most widely used schema for LDAP/X.500 directories, and
- many other schema definitions for white pages objects use it as a
- basis. This document does not cover attributes used for the
- administration of X.500 directory servers, nor does it include
- attributes defined by other ISO/ITU-T documents.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [6].
-
-3. General Issues
-
- This document references syntaxes given in section 6 of this document
- and section 6 of [1]. Matching rules are listed in section 8 of this
- document and section 8 of [1].
-
- The attribute type and object class definitions are written using the
- BNF form of AttributeTypeDescription and ObjectClassDescription given
- in [1]. Lines have been folded for readability.
-
-4. Source
-
- The schema definitions in this document are based on those found in
- X.500 [2],[3],[4],[5], and updates to these documents, specifically:
-
- Sections Source
- ============ ============
- 5.1 - 5.2 X.501(93)
- 5.3 - 5.36 X.520(88)
- 5.37 - 5.41 X.509(93)
- 5.42 - 5.52 X.520(93)
- 5.53 - 5.54 X.509(96)
- 5.55 X.520(96)
- 6.1 RFC 1274
- 6.2 (new syntax)
- 6.3 - 6.6 RFC 1274
- 7.1 - 7.2 X.501(93)
- 7.3 - 7.18 X.521(93)
-
-
-
-Wahl Standards Track [Page 2]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- 7.19 - 7.21 X.509(96)
- 7.22 X.521(96)
-
- Some attribute names are different from those found in X.520(93).
-
- Three new attributes supportedAlgorithms, deltaRevocationList and
- dmdName, and the objectClass dmd, are defined in the X.500(96)
- documents.
-
-5. Attribute Types
-
- An LDAP server implementation SHOULD recognize the attribute types
- described in this section.
-
-5.1. objectClass
-
- The values of the objectClass attribute describe the kind of object
- which an entry represents. The objectClass attribute is present in
- every entry, with at least two values. One of the values is either
- "top" or "alias".
-
- ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-5.2. aliasedObjectName
-
- The aliasedObjectName attribute is used by the directory service if
- the entry containing this attribute is an alias.
-
- ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
-
-5.3. knowledgeInformation
-
- This attribute is no longer used.
-
- ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.4. cn
-
- This is the X.500 commonName attribute, which contains a name of an
- object. If the object corresponds to a person, it is typically the
- person's full name.
-
- ( 2.5.4.3 NAME 'cn' SUP name )
-
-
-
-
-
-Wahl Standards Track [Page 3]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.5. sn
-
- This is the X.500 surname attribute, which contains the family name
- of a person.
-
- ( 2.5.4.4 NAME 'sn' SUP name )
-
-5.6. serialNumber
-
- This attribute contains the serial number of a device.
-
- ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
-
-5.7. c
-
- This attribute contains a two-letter ISO 3166 country code
- (countryName).
-
- ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
-
-5.8. l
-
- This attribute contains the name of a locality, such as a city,
- county or other geographic region (localityName).
-
- ( 2.5.4.7 NAME 'l' SUP name )
-
-5.9. st
-
- This attribute contains the full name of a state or province
- (stateOrProvinceName).
-
- ( 2.5.4.8 NAME 'st' SUP name )
-
-5.10. street
-
- This attribute contains the physical address of the object to which
- the entry corresponds, such as an address for package delivery
- (streetAddress).
-
- ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-
-
-
-
-
-Wahl Standards Track [Page 4]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.11. o
-
- This attribute contains the name of an organization
- (organizationName).
-
- ( 2.5.4.10 NAME 'o' SUP name )
-
-5.12. ou
-
- This attribute contains the name of an organizational unit
- (organizationalUnitName).
-
- ( 2.5.4.11 NAME 'ou' SUP name )
-
-5.13. title
-
- This attribute contains the title, such as "Vice President", of a
- person in their organizational context. The "personalTitle"
- attribute would be used for a person's title independent of their job
- function.
-
- ( 2.5.4.12 NAME 'title' SUP name )
-
-5.14. description
-
- This attribute contains a human-readable description of the object.
-
- ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
-
-5.15. searchGuide
-
- This attribute is for use by X.500 clients in constructing search
- filters. It is obsoleted by enhancedSearchGuide, described below in
- 5.48.
-
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
-
-5.16. businessCategory
-
- This attribute describes the kind of business performed by an
- organization.
-
- ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-
-
-Wahl Standards Track [Page 5]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.17. postalAddress
-
- ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-5.18. postalCode
-
- ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
-
-5.19. postOfficeBox
-
- ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
-
-5.20. physicalDeliveryOfficeName
-
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-5.21. telephoneNumber
-
- ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
-
-5.22. telexNumber
-
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
-
-5.23. teletexTerminalIdentifier
-
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
-
-5.24. facsimileTelephoneNumber
-
- ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
-
-
-
-
-
-
-
-Wahl Standards Track [Page 6]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.25. x121Address
-
- ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
-
-5.26. internationaliSDNNumber
-
- ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
-
-5.27. registeredAddress
-
- This attribute holds a postal address suitable for reception of
- telegrams or expedited documents, where it is necessary to have the
- recipient accept delivery.
-
- ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-5.28. destinationIndicator
-
- This attribute is used for the telegram service.
-
- ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
-
-5.29. preferredDeliveryMethod
-
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
-
-5.30. presentationAddress
-
- This attribute contains an OSI presentation address.
-
- ( 2.5.4.29 NAME 'presentationAddress'
- EQUALITY presentationAddressMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
- SINGLE-VALUE )
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 7]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.31. supportedApplicationContext
-
- This attribute contains the identifiers of OSI application contexts.
-
- ( 2.5.4.30 NAME 'supportedApplicationContext'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-5.32. member
-
- ( 2.5.4.31 NAME 'member' SUP distinguishedName )
-
-5.33. owner
-
- ( 2.5.4.32 NAME 'owner' SUP distinguishedName )
-
-5.34. roleOccupant
-
- ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
-
-5.35. seeAlso
-
- ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
-
-5.36. userPassword
-
- ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
-
- Passwords are stored using an Octet String syntax and are not
- encrypted. Transfer of cleartext passwords are strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the password to
- unauthorized parties.
-
-5.37. userCertificate
-
- This attribute is to be stored and requested in the binary form, as
- 'userCertificate;binary'.
-
- ( 2.5.4.36 NAME 'userCertificate'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
-5.38. cACertificate
-
- This attribute is to be stored and requested in the binary form, as
- 'cACertificate;binary'.
-
-
-
-
-Wahl Standards Track [Page 8]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- ( 2.5.4.37 NAME 'cACertificate'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
-5.39. authorityRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'authorityRevocationList;binary'.
-
- ( 2.5.4.38 NAME 'authorityRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.40. certificateRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'certificateRevocationList;binary'.
-
- ( 2.5.4.39 NAME 'certificateRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.41. crossCertificatePair
-
- This attribute is to be stored and requested in the binary form, as
- 'crossCertificatePair;binary'.
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
-
-5.42. name
-
- The name attribute type is the attribute supertype from which string
- attribute types typically used for naming may be formed. It is
- unlikely that values of this type itself will occur in an entry. LDAP
- server implementations which do not support attribute subtyping need
- not recognize this attribute in requests. Client implementations
- MUST NOT assume that LDAP servers are capable of performing attribute
- subtyping.
-
- ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.43. givenName
-
- The givenName attribute is used to hold the part of a person's name
- which is not their surname nor middle name.
-
- ( 2.5.4.42 NAME 'givenName' SUP name )
-
-
-
-
-Wahl Standards Track [Page 9]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.44. initials
-
- The initials attribute contains the initials of some or all of an
- individuals names, but not the surname(s).
-
- ( 2.5.4.43 NAME 'initials' SUP name )
-
-5.45. generationQualifier
-
- The generationQualifier attribute contains the part of the name which
- typically is the suffix, as in "IIIrd".
-
- ( 2.5.4.44 NAME 'generationQualifier' SUP name )
-
-5.46. x500UniqueIdentifier
-
- The x500UniqueIdentifier attribute is used to distinguish between
- objects when a distinguished name has been reused. This is a
- different attribute type from both the "uid" and "uniqueIdentifier"
- types.
-
- ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
-5.47. dnQualifier
-
- The dnQualifier attribute type specifies disambiguating information
- to add to the relative distinguished name of an entry. It is
- intended for use when merging data from multiple sources in order to
- prevent conflicts between entries which would otherwise have the same
- name. It is recommended that the value of the dnQualifier attribute
- be the same for all entries from a particular source.
-
- ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
-5.48. enhancedSearchGuide
-
- This attribute is for use by X.500 clients in constructing search
- filters.
-
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
-
-
-
-
-
-
-
-Wahl Standards Track [Page 10]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.49. protocolInformation
-
- This attribute is used in conjunction with the presentationAddress
- attribute, to provide additional information to the OSI network
- service.
-
- ( 2.5.4.48 NAME 'protocolInformation'
- EQUALITY protocolInformationMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
-
-5.50. distinguishedName
-
- This attribute type is not used as the name of the object itself, but
- it is instead a base type from which attributes with DN syntax
- inherit.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
-
- ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-5.51. uniqueMember
-
- ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
-5.52. houseIdentifier
-
- This attribute is used to identify a building within a location.
-
- ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.53. supportedAlgorithms
-
- This attribute is to be stored and requested in the binary form, as
- 'supportedAlgorithms;binary'.
-
- ( 2.5.4.52 NAME 'supportedAlgorithms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
-
-
-
-
-
-
-Wahl Standards Track [Page 11]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.54. deltaRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'deltaRevocationList;binary'.
-
- ( 2.5.4.53 NAME 'deltaRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.55. dmdName
-
- The value of this attribute specifies a directory management domain
- (DMD), the administrative authority which operates the directory
- server.
-
- ( 2.5.4.54 NAME 'dmdName' SUP name )
-
-6. Syntaxes
-
- Servers SHOULD recognize the syntaxes defined in this section. Each
- syntax begins with a sample value of the ldapSyntaxes attribute which
- defines the OBJECT IDENTIFIER of the syntax. The descriptions of
- syntax names are not carried in protocol, and are not guaranteed to
- be unique.
-
-6.1. Delivery Method
-
- ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
-
- Values in this syntax are encoded according to the following BNF:
-
- delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
-
- pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
- "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
-
- Example:
-
- telephone
-
-6.2. Enhanced Guide
-
- ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
-
- Values in this syntax are encoded according to the following BNF:
-
- EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
-
- subset = "baseobject" / "oneLevel" / "wholeSubtree"
-
-
-
-Wahl Standards Track [Page 12]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- The criteria production is defined in the Guide syntax below. This
- syntax has been added subsequent to RFC 1778.
-
- Example:
-
- person#(sn)#oneLevel
-
-6.3. Guide
-
- ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
-
- Values in this syntax are encoded according to the following BNF:
-
- guide-value = [ object-class "#" ] criteria
-
- object-class = woid
-
- criteria = criteria-item / criteria-set / ( "!" criteria )
-
- criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
- ( [ "(" ] criteria "|" criteria-set [ ")" ] )
-
- criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
-
- match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
-
- This syntax should not be used for defining new attributes.
-
-6.4. Octet String
-
- ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
-
- Values in this syntax are encoded as octet strings.
-
-
- Example:
-
- secret
-
-6.5. Teletex Terminal Identifier
-
- ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
-
- Values in this syntax are encoded according to the following BNF:
-
- teletex-id = ttx-term 0*("$" ttx-param)
-
- ttx-term = printablestring
-
-
-
-Wahl Standards Track [Page 13]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- ttx-param = ttx-key ":" ttx-value
-
- ttx-key = "graphic" / "control" / "misc" / "page" / "private"
-
- ttx-value = octetstring
-
- In the above, the first printablestring is the encoding of the first
- portion of the teletex terminal identifier to be encoded, and the
- subsequent 0 or more octetstrings are subsequent portions of the
- teletex terminal identifier.
-
-6.6. Telex Number
-
- ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
-
- Values in this syntax are encoded according to the following BNF:
-
- telex-number = actual-number "$" country "$" answerback
-
- actual-number = printablestring
-
- country = printablestring
-
- answerback = printablestring
-
- In the above, actual-number is the syntactic representation of the
- number portion of the TELEX number being encoded, country is the
- TELEX country code, and answerback is the answerback code of a TELEX
- terminal.
-
-6.7. Supported Algorithm
-
- ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )
-
- No printable representation of values of the supportedAlgorithms
- attribute is defined in this document. Clients which wish to store
- and retrieve this attribute MUST use "supportedAlgorithms;binary", in
- which the value is transferred as a binary encoding.
-
-7. Object Classes
-
- LDAP servers MUST recognize the object classes "top" and "subschema".
- LDAP servers SHOULD recognize all the other object classes listed
- here as values of the objectClass attribute.
-
-7.1. top
-
- ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
-
-
-Wahl Standards Track [Page 14]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-7.2. alias
-
- ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
-
-7.3. country
-
- ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
- MAY ( searchGuide $ description ) )
-
-7.4. locality
-
- ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
- MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
-
-7.5. organization
-
- ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-7.6. organizationalUnit
-
- ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-7.7. person
-
- ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
- MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
-
-7.8. organizationalPerson
-
- ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
- MAY ( title $ x121Address $ registeredAddress $
- destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
-
-
-
-Wahl Standards Track [Page 15]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l ) )
-
-7.9. organizationalRole
-
- ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
- MAY ( x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
-
-7.10. groupOfNames
-
- ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
- MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
-
-7.11. residentialPerson
-
- ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l
- MAY ( businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $
- facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l ) )
-
-7.12. applicationProcess
-
- ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
- MAY ( seeAlso $ ou $ l $ description ) )
-
-7.13. applicationEntity
-
- ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
- MUST ( presentationAddress $ cn )
- MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
- description ) )
-
-7.14. dSA
-
- ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
- MAY knowledgeInformation )
-
-
-
-
-Wahl Standards Track [Page 16]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-7.15. device
-
- ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
- MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
-
-7.16. strongAuthenticationUser
-
- ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
- MUST userCertificate )
-
-7.17. certificationAuthority
-
- ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
- MUST ( authorityRevocationList $ certificateRevocationList $
- cACertificate ) MAY crossCertificatePair )
-
-7.18. groupOfUniqueNames
-
- ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
- MUST ( uniqueMember $ cn )
- MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
-
-7.19. userSecurityInformation
-
- ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-7.20. certificationAuthority-V2
-
- ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
- certificationAuthority
- AUXILIARY MAY ( deltaRevocationList ) )
-
-7.21. cRLDistributionPoint
-
- ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
- MUST ( cn ) MAY ( certificateRevocationList $
- authorityRevocationList $
- deltaRevocationList ) )
-
-7.22. dmd
-
- ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName )
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
-
-
-
-Wahl Standards Track [Page 17]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-8. Matching Rules
-
- Servers MAY implement additional matching rules.
-
-8.1. octetStringMatch
-
- Servers which implement the extensibleMatch filter SHOULD allow the
- matching rule listed in this section to be used in the
- extensibleMatch. In general these servers SHOULD allow matching
- rules to be used with all attribute types known to the server, when
- the assertion syntax of the matching rule is the same as the value
- syntax of the attribute.
-
- ( 2.5.13.17 NAME 'octetStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
-9. Security Considerations
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
- Transfer of cleartext passwords are strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
-10. Acknowledgements
-
- The definitions on which this document have been developed by
- committees for telecommunications and international standards. No
- new attribute definitions have been added. The syntax definitions
- are based on the ISODE "QUIPU" implementation of X.500.
-
-11. Bibliography
-
- [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
- "Lightweight X.500 Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [2] The Directory: Models. ITU-T Recommendation X.501, 1996.
-
- [3] The Directory: Authentication Framework. ITU-T Recommendation
- X.509, 1996.
-
-
-
-
-Wahl Standards Track [Page 18]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
- [4] The Directory: Selected Attribute Types. ITU-T Recommendation
- X.520, 1996.
-
- [5] The Directory: Selected Object Classes. ITU-T Recommendation
- X.521, 1996.
-
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-12. Author's Address
-
- Mark Wahl
- Critical Angle Inc.
- 4815 West Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372 3160
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 19]
-\f
-RFC 2256 LDAPv3 Schema December 1997
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 20]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Boeyen
-Request for Comments: 2587 Entrust
-Category: Standards Track T. Howes
- Netscape
- P. Richard
- Xcert
- June 1999
-
-
-
- Internet X.509 Public Key Infrastructure
- LDAPv2 Schema
-
-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 (1999). All Rights Reserved.
-
-1. Abstract
-
- The schema defined in this document is a minimal schema to support
- PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-
- specific components are specified here. LDAP servers, acting as PKIX
- repositories should support the auxiliary object classes defined in
- this specification and integrate this schema specification with the
- generic and other application-specific schemas as appropriate,
- depending on the services to be supplied by that server.
-
- The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
- and 'MAY' in this document are to be interpreted as described in RFC
- 2119.
-
-2. Introduction
-
- This specification is part of a multi-part standard for development
- of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
- mechanism defined for access to a PKI repository. Other mechanisms,
- such as http, are also defined. If an LDAP server, accessed by LDAPv2
- is used to provide a repository, the minimum requirement is that the
- repository support the addition of X.509 certificates to directory
-
-
-
-
-Boeyen, et al. Standards Track [Page 1]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- entries. Certificate Revocation List (CRL)is one mechanism for
- publishing revocation information in a repository. Other mechanisms,
- such as http, are also defined.
-
- This specification defines the attributes and object classes to be
- used by LDAP servers acting as PKIX repositories and to be understood
- by LDAP clients communicating with such repositories to query, add,
- modify and delete PKI information. Some object classes and attributes
- defined in X.509 are duplicated here for completeness. For end
- entities and Certification Authorities (CA), the earlier X.509
- defined object classes mandated inclusion of attributes which are
- optional for PKIX. Also, because of the mandatory attribute
- specification, this would have required dynamic modification of the
- object class attribute should the attributes not always be present in
- entries. For these reasons, alternative object classes are defined in
- this document for use by LDAP servers acting as PKIX repositories.
-
-3. PKIX Repository Objects
-
- The primary PKIX objects to be represented in a repository are:
-
- - End Entities
- - Certification Authorities (CA)
-
- These objects are defined in RFC 2459.
-
-3.1. End Entities
-
- For purposes of PKIX schema definition, the role of end entities as
- subjects of certificates is the major aspect relevant to this
- specification. End entities may be human users, or other types of
- entities to which certificates may be issued. In some cases, the
- entry for the end entity may already exist and the PKI-specific
- information is added to the existing entry. In other cases the entry
- may not exist prior to the issuance of a certificate, in which case
- the entity adding the certificate may also need to create the entry.
- Schema elements used to represent the non PKIX aspects of an entry,
- such as the structural object class used to represent organizational
- persons, may vary, depending on the particular environment and set of
- applications served and are outside the scope of this specification.
-
- The following auxiliary object class MAY be used to represent
- certificate subjects:
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 2]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-pkiUser OBJECT-CLASS ::= {
- SUBCLASS OF { top}
- KIND auxiliary
- MAY CONTAIN {userCertificate}
- ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
-
-userCertificate ATTRIBUTE ::= {
- WITH SYNTAX Certificate
- EQUALITY MATCHING RULE certificateExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
-
- An end entity may obtain one or more certificates from one or more
- Certification Authorities. The userCertificate attribute MUST be
- used to represent these certificates in the directory entry
- representing that user.
-
-3.2. Certification Authorities
-
- As with end entities, Certification Authorities are typically
- represented in directories as auxiliary components of entries
- representing a more generic object, such as organizations,
- organizational units etc. The non PKIX-specific schema elements for
- these entries, such as the structural object class of the object, are
- outside the scope of this specification.
-
- The following auxiliary object class MAY be used to represent
- Certification Authorities:
-
-pkiCA OBJECT-CLASS ::= {
- SUBCLASS OF { top}
- KIND auxiliary
- MAY CONTAIN {cACertificate |
- certificateRevocationList |
- authorityRevocationList |
- crossCertificatePair }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
-
-cACertificate ATTRIBUTE ::= {
- WITH SYNTAX Certificate
- EQUALITY MATCHING RULE certificateExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
-
-crossCertificatePairATTRIBUTE::={
- WITH SYNTAX CertificatePair
- EQUALITY MATCHING RULE certificatePairExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 3]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- The cACertificate attribute of a CA's directory entry shall be used
- to store self-issued certificates (if any) and certificates issued to
- this CA by CAs in the same realm as this CA.
-
- The forward elements of the crossCertificatePair attribute of a CA's
- directory entry shall be used to store all, except self-issued
- certificates issued to this CA. Optionally, the reverse elements of
- the crossCertificatePair attribute, of a CA's directory entry may
- contain a subset of certificates issued by this CA to other CAs.
- When both the forward and the reverse elements are present in a
- single attribute value, issuer name in one certificate shall match
- the subject name in the other and vice versa, and the subject public
- key in one certificate shall be capable of verifying the digital
- signature on the other certificate and vice versa.
-
- When a reverse element is present, the forward element value and the
- reverse element value need not be stored in the same attribute value;
- in other words, they can be stored in either a single attribute value
- or two attribute values.
-
- In the case of V3 certificates, none of the above CA certificates
- shall include a basicConstraints extension with the cA value set to
- FALSE.
-
- The definition of realm is purely a matter of local policy.
-
- certificateRevocationListATTRIBUTE::={
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- certificateRevocationList(39)}
-
- The certificateRevocationList attribute, if present in a particular
- CA's entry, contains CRL(s) as defined in RFC 2459.
-
- authorityRevocationListATTRIBUTE::={
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- authorityRevocationList(38)}
-
- The authorityRevocationList attribute, if present in a particular
- CA's entry, includes revocation information regarding certificates
- issued to other CAs.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 4]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-3.2.1. CRL distribution points
-
- CRL distribution points are an optional mechanism, specified in RFC
- 2459, which MAY be used to distribute revocation information.
-
- A patent statement regarding CRL distribution points can be found at
- the end of this document.
-
- If a CA elects to use CRL distribution points, the following object
- class is used to represent these.
-
- cRLDistributionPoint OBJECT-CLASS::= {
- SUBCLASS OF { top }
- KIND structural
- MUST CONTAIN { commonName }
- MAY CONTAIN { certificateRevocationList |
- authorityRevocationList |
- deltaRevocationList }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
-
- The certificateRevocationList and authorityRevocationList attributes
- are as defined above.
-
- The commonName attribute and deltaRevocationList attributes, defined
- in X.509, are duplicated below.
-
- commonName ATTRIBUTE::={
- SUBTYPE OF name
- WITH SYNTAX DirectoryString
- ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
-
- deltaRevocationList ATTRIBUTE ::= {
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- deltaRevocationList(53) }
-
-3.2.2. Delta CRLs
-
- Delta CRLs are an optional mechanism, specified in RFC 2459, which
- MAY be used to enhance the distribution of revocation information.
-
- If a CA elects to use delta CRLs, the following object class is used
- to represent these.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 5]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- deltaCRL OBJECT-CLASS::= {
- SUBCLASS OF { top }
- KIND auxiliary
- MAY CONTAIN { deltaRevocationList }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
-
-4. Security Considerations
-
- Since the elements of information which are key to the PKI service
- (certificates and CRLs) are both digitally signed pieces of
- information, no additional integrity service is REQUIRED.
-
- Security considerations with respect to retrieval, addition,
- deletion, and modification of the information supported by this
- schema definition are addressed in RFC 2559.
-
-5. References
-
- [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-6 Intellectual Property Rights
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 6]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-7. Authors' Addresses
-
- Sharon Boeyen
- Entrust Technologies Limited
- 750 Heron Road
- Ottawa, Ontario
- Canada K1V 1A7
-
- EMail: sharon.boeyen@entrust.com
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- EMail: howes@netscape.com
-
-
- Patrick Richard
- Xcert Software Inc.
- Suite 1001, 701 W. Georgia Street
- P.O. Box 10145
- Pacific Centre
- Vancouver, B.C.
- Canada V7Y 1C6
-
- EMail: patr@xcert.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 7]
-\f
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2829 Sun Microsystems, Inc.
-Category: Standards Track H. Alvestrand
- EDB Maxware
- J. Hodges
- Oblix, Inc.
- R. Morgan
- University of Washington
- May 2000
-
-
- Authentication Methods for LDAP
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document specifies particular combinations of security
- mechanisms which are required and recommended in LDAP [1]
- implementations.
-
-1. Introduction
-
- LDAP version 3 is a powerful access protocol for directories.
-
- It offers means of searching, fetching and manipulating directory
- content, and ways to access a rich set of security functions.
-
- In order to function for the best of the Internet, it is vital that
- these security functions be interoperable; therefore there has to be
- a minimum subset of security functions that is common to all
- implementations that claim LDAPv3 conformance.
-
- Basic threats to an LDAP directory service include:
-
- (1) Unauthorized access to data via data-fetching operations,
-
-
-
-
-
-Wahl, et al. Standards Track [Page 1]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- (2) Unauthorized access to reusable client authentication
- information by monitoring others' access,
-
- (3) Unauthorized access to data by monitoring others' access,
-
- (4) Unauthorized modification of data,
-
- (5) Unauthorized modification of configuration,
-
- (6) Unauthorized or excessive use of resources (denial of
- service), and
-
- (7) Spoofing of directory: Tricking a client into believing that
- information came from the directory when in fact it did not,
- either by modifying data in transit or misdirecting the
- client's connection.
-
- Threats (1), (4), (5) and (6) are due to hostile clients. Threats
- (2), (3) and (7) are due to hostile agents on the path between client
- and server, or posing as a server.
-
- The LDAP protocol suite can be protected with the following security
- mechanisms:
-
- (1) Client authentication by means of the SASL [2] mechanism
- set, possibly backed by the TLS credentials exchange
- mechanism,
-
- (2) Client authorization by means of access control based on the
- requestor's authenticated identity,
-
- (3) Data integrity protection by means of the TLS protocol or
- data-integrity SASL mechanisms,
-
- (4) Protection against snooping by means of the TLS protocol or
- data-encrypting SASL mechanisms,
-
- (5) Resource limitation by means of administrative limits on
- service controls, and
-
- (6) Server authentication by means of the TLS protocol or SASL
- mechanism.
-
- At the moment, imposition of access controls is done by means outside
- the scope of the LDAP protocol.
-
- In this document, the term "user" represents any application which is
- an LDAP client using the directory to retrieve or store information.
-
-
-
-Wahl, et al. Standards Track [Page 2]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [3].
-
-2. Example deployment scenarios
-
- The following scenarios are typical for LDAP directories on the
- Internet, and have different security requirements. (In the
- following, "sensitive" means data that will cause real damage to the
- owner if revealed; there may be data that is protected but not
- sensitive). This is not intended to be a comprehensive list, other
- scenarios are possible, especially on physically protected networks.
-
- (1) A read-only directory, containing no sensitive data,
- accessible to "anyone", and TCP connection hijacking or IP
- spoofing is not a problem. This directory requires no
- security functions except administrative service limits.
-
- (2) A read-only directory containing no sensitive data; read
- access is granted based on identity. TCP connection
- hijacking is not currently a problem. This scenario requires
- a secure authentication function.
-
- (3) A read-only directory containing no sensitive data; and the
- client needs to ensure that the directory data is
- authenticated by the server and not modified while being
- returned from the server.
-
- (4) A read-write directory, containing no sensitive data; read
- access is available to "anyone", update access to properly
- authorized persons. TCP connection hijacking is not
- currently a problem. This scenario requires a secure
- authentication function.
-
- (5) A directory containing sensitive data. This scenario
- requires session confidentiality protection AND secure
- authentication.
-
-3. Authentication and Authorization: Definitions and Concepts
-
- This section defines basic terms, concepts, and interrelationships
- regarding authentication, authorization, credentials, and identity.
- These concepts are used in describing how various security approaches
- are utilized in client authentication and authorization.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 3]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-3.1. Access Control Policy
-
- An access control policy is a set of rules defining the protection of
- resources, generally in terms of the capabilities of persons or other
- entities accessing those resources. A common expression of an access
- control policy is an access control list. Security objects and
- mechanisms, such as those described here, enable the expression of
- access control policies and their enforcement. Access control
- policies are typically expressed in terms of access control
- attributes as described below.
-
-3.2. Access Control Factors
-
- A request, when it is being processed by a server, may be associated
- with a wide variety of security-related factors (section 4.2 of [1]).
- The server uses these factors to determine whether and how to process
- the request. These are called access control factors (ACFs). They
- might include source IP address, encryption strength, the type of
- operation being requested, time of day, etc. Some factors may be
- specific to the request itself, others may be associated with the
- connection via which the request is transmitted, others (e.g. time of
- day) may be "environmental".
-
- Access control policies are expressed in terms of access control
- factors. E.g., a request having ACFs i,j,k can perform operation Y
- on resource Z. The set of ACFs that a server makes available for such
- expressions is implementation-specific.
-
-3.3. Authentication, Credentials, Identity
-
- Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g. a user)
- who is attempting to establish an association with the other party
- (typically a server). Authentication is the process of generating,
- transmitting, and verifying these credentials and thus the identity
- they assert. An authentication identity is the name presented in a
- credential.
-
- There are many forms of authentication credentials -- the form used
- depends upon the particular authentication mechanism negotiated by
- the parties. For example: X.509 certificates, Kerberos tickets,
- simple identity and password pairs. Note that an authentication
- mechanism may constrain the form of authentication identities used
- with it.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 4]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-3.4. Authorization Identity
-
- An authorization identity is one kind of access control factor. It
- is the name of the user or other entity that requests that operations
- be performed. Access control policies are often expressed in terms
- of authorization identities; e.g., entity X can perform operation Y
- on resource Z.
-
- The authorization identity bound to an association is often exactly
- the same as the authentication identity presented by the client, but
- it may be different. SASL allows clients to specify an authorization
- identity distinct from the authentication identity asserted by the
- client's credentials. This permits agents such as proxy servers to
- authenticate using their own credentials, yet request the access
- privileges of the identity for which they are proxying [2]. Also,
- the form of authentication identity supplied by a service like TLS
- may not correspond to the authorization identities used to express a
- server's access control policy, requiring a server-specific mapping
- to be done. The method by which a server composes and validates an
- authorization identity from the authentication credentials supplied
- by a client is implementation-specific.
-
-4. Required security mechanisms
-
- It is clear that allowing any implementation, faced with the above
- requirements, to pick and choose among the possible alternatives is
- not a strategy that is likely to lead to interoperability. In the
- absence of mandates, clients will be written that do not support any
- security function supported by the server, or worse, support only
- mechanisms like cleartext passwords that provide clearly inadequate
- security.
-
- Active intermediary attacks are the most difficult for an attacker to
- perform, and for an implementation to protect against. Methods that
- protect only against hostile client and passive eavesdropping attacks
- are useful in situations where the cost of protection against active
- intermediary attacks is not justified based on the perceived risk of
- active intermediary attacks.
-
- Given the presence of the Directory, there is a strong desire to see
- mechanisms where identities take the form of a Distinguished Name and
- authentication data can be stored in the directory; this means that
- either this data is useless for faking authentication (like the Unix
- "/etc/passwd" file format used to be), or its content is never passed
- across the wire unprotected - that is, it's either updated outside
- the protocol or it is only updated in sessions well protected against
- snooping. It is also desirable to allow authentication methods to
-
-
-
-
-Wahl, et al. Standards Track [Page 5]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- carry authorization identities based on existing forms of user
- identities for backwards compatibility with non-LDAP-based
- authentication services.
-
- Therefore, the following implementation conformance requirements are
- in place:
-
- (1) For a read-only, public directory, anonymous authentication,
- described in section 5, can be used.
-
- (2) Implementations providing password-based authenticated
- access MUST support authentication using the DIGEST-MD5 SASL
- mechanism [4], as described in section 6.1. This provides
- client authentication with protection against passive
- eavesdropping attacks, but does not provide protection
- against active intermediary attacks.
-
- (3) For a directory needing session protection and
- authentication, the Start TLS extended operation [5], and
- either the simple authentication choice or the SASL EXTERNAL
- mechanism, are to be used together. Implementations SHOULD
- support authentication with a password as described in
- section 6.2, and SHOULD support authentication with a
- certificate as described in section 7.1. Together, these
- can provide integrity and disclosure protection of
- transmitted data, and authentication of client and server,
- including protection against active intermediary attacks.
-
- If TLS is negotiated, the client MUST discard all information about
- the server fetched prior to the TLS negotiation. In particular, the
- value of supportedSASLMechanisms MAY be different after TLS has been
- negotiated (specifically, the EXTERNAL mechanism or the proposed
- PLAIN mechanism are likely to only be listed after a TLS negotiation
- has been performed).
-
- If a SASL security layer is negotiated, the client MUST discard all
- information about the server fetched prior to SASL. In particular,
- if the client is configured to support multiple SASL mechanisms, it
- SHOULD fetch supportedSASLMechanisms both before and after the SASL
- security layer is negotiated and verify that the value has not
- changed after the SASL security layer was negotiated. This detects
- active attacks which remove supported SASL mechanisms from the
- supportedSASLMechanisms list, and allows the client to ensure that it
- is using the best mechanism supported by both client and server
- (additionally, this is a SHOULD to allow for environments where the
- supported SASL mechanisms list is provided to the client through a
- different trusted source, e.g. as part of a digitally signed object).
-
-
-
-
-Wahl, et al. Standards Track [Page 6]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-5. Anonymous authentication
-
- Directory operations which modify entries or access protected
- attributes or entries generally require client authentication.
- Clients which do not intend to perform any of these operations
- typically use anonymous authentication.
-
- LDAP implementations MUST support anonymous authentication, as
- defined in section 5.1.
-
- LDAP implementations MAY support anonymous authentication with TLS,
- as defined in section 5.2.
-
- While there MAY be access control restrictions to prevent access to
- directory entries, an LDAP server SHOULD allow an anonymously-bound
- client to retrieve the supportedSASLMechanisms attribute of the root
- DSE.
-
- An LDAP server MAY use other information about the client provided by
- the lower layers or external means to grant or deny access even to
- anonymously authenticated clients.
-
-5.1. Anonymous authentication procedure
-
- An LDAP client which has not successfully completed a bind operation
- on a connection is anonymously authenticated.
-
- An LDAP client MAY also specify anonymous authentication in a bind
- request by using a zero-length OCTET STRING with the simple
- authentication choice.
-
-5.2. Anonymous authentication and TLS
-
- An LDAP client MAY use the Start TLS operation [5] to negotiate the
- use of TLS security [6]. If the client has not bound beforehand,
- then until the client uses the EXTERNAL SASL mechanism to negotiate
- the recognition of the client's certificate, the client is
- anonymously authenticated.
-
- Recommendations on TLS ciphersuites are given in section 10.
-
- An LDAP server which requests that clients provide their certificate
- during TLS negotiation MAY use a local security policy to determine
- whether to successfully complete TLS negotiation if the client did
- not present a certificate which could be validated.
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 7]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-6. Password-based authentication
-
- LDAP implementations MUST support authentication with a password
- using the DIGEST-MD5 SASL mechanism for password protection, as
- defined in section 6.1.
-
- LDAP implementations SHOULD support authentication with the "simple"
- password choice when the connection is protected against
- eavesdropping using TLS, as defined in section 6.2.
-
-6.1. Digest authentication
-
- An LDAP client MAY determine whether the server supports this
- mechanism by performing a search request on the root DSE, requesting
- the supportedSASLMechanisms attribute, and checking whether the
- string "DIGEST-MD5" is present as a value of this attribute.
-
- In the first stage of authentication, when the client is performing
- an "initial authentication" as defined in section 2.1 of [4], the
- client sends a bind request in which the version number is 3, the
- authentication choice is sasl, the sasl mechanism name is "DIGEST-
- MD5", and the credentials are absent. The client then waits for a
- response from the server to this request.
-
- The server will respond with a bind response in which the resultCode
- is saslBindInProgress, and the serverSaslCreds field is present. The
- contents of this field is a string defined by "digest-challenge" in
- section 2.1.1 of [4]. The server SHOULD include a realm indication
- and MUST indicate support for UTF-8.
-
- The client will send a bind request with a distinct message id, in
- which the version number is 3, the authentication choice is sasl, the
- sasl mechanism name is "DIGEST-MD5", and the credentials contain the
- string defined by "digest-response" in section 2.1.2 of [4]. The
- serv-type is "ldap".
-
- The server will respond with a bind response in which the resultCode
- is either success, or an error indication. If the authentication is
- successful and the server does not support subsequent authentication,
- then the credentials field is absent. If the authentication is
- successful and the server supports subsequent authentication, then
- the credentials field contains the string defined by "response-auth"
- in section 2.1.3 of [4]. Support for subsequent authentication is
- OPTIONAL in clients and servers.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 8]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-6.2. "simple" authentication choice under TLS encryption
-
- A user who has a directory entry containing a userPassword attribute
- MAY authenticate to the directory by performing a simple password
- bind sequence following the negotiation of a TLS ciphersuite
- providing connection confidentiality [6].
-
- The client will use the Start TLS operation [5] to negotiate the use
- of TLS security [6] on the connection to the LDAP server. The client
- need not have bound to the directory beforehand.
-
- For this authentication procedure to be successful, the client and
- server MUST negotiate a ciphersuite which contains a bulk encryption
- algorithm of appropriate strength. Recommendations on cipher suites
- are given in section 10.
-
- Following the successful completion of TLS negotiation, the client
- MUST send an LDAP bind request with the version number of 3, the name
- field containing the name of the user's entry, and the "simple"
- authentication choice, containing a password.
-
- The server will, for each value of the userPassword attribute in the
- named user's entry, compare these for case-sensitive equality with
- the client's presented password. If there is a match, then the
- server will respond with resultCode success, otherwise the server
- will respond with resultCode invalidCredentials.
-
-6.3. Other authentication choices with TLS
-
- It is also possible, following the negotiation of TLS, to perform a
- SASL authentication which does not involve the exchange of plaintext
- reusable passwords. In this case the client and server need not
- negotiate a ciphersuite which provides confidentiality if the only
- service required is data integrity.
-
-7. Certificate-based authentication
-
- LDAP implementations SHOULD support authentication via a client
- certificate in TLS, as defined in section 7.1.
-
-7.1. Certificate-based authentication with TLS
-
- A user who has a public/private key pair in which the public key has
- been signed by a Certification Authority may use this key pair to
- authenticate to the directory server if the user's certificate is
- requested by the server. The user's certificate subject field SHOULD
- be the name of the user's directory entry, and the Certification
- Authority must be sufficiently trusted by the directory server to
-
-
-
-Wahl, et al. Standards Track [Page 9]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- have issued the certificate in order that the server can process the
- certificate. The means by which servers validate certificate paths
- is outside the scope of this document.
-
- A server MAY support mappings for certificates in which the subject
- field name is different from the name of the user's directory entry.
- A server which supports mappings of names MUST be capable of being
- configured to support certificates for which no mapping is required.
-
- The client will use the Start TLS operation [5] to negotiate the use
- of TLS security [6] on the connection to the LDAP server. The client
- need not have bound to the directory beforehand.
-
- In the TLS negotiation, the server MUST request a certificate. The
- client will provide its certificate to the server, and MUST perform a
- private key-based encryption, proving it has the private key
- associated with the certificate.
-
- As deployments will require protection of sensitive data in transit,
- the client and server MUST negotiate a ciphersuite which contains a
- bulk encryption algorithm of appropriate strength. Recommendations
- of cipher suites are given in section 10.
-
- The server MUST verify that the client's certificate is valid. The
- server will normally check that the certificate is issued by a known
- CA, and that none of the certificates on the client's certificate
- chain are invalid or revoked. There are several procedures by which
- the server can perform these checks.
-
- Following the successful completion of TLS negotiation, the client
- will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
-
-8. Other mechanisms
-
- The LDAP "simple" authentication choice is not suitable for
- authentication on the Internet where there is no network or transport
- layer confidentiality.
-
- As LDAP includes native anonymous and plaintext authentication
- methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
- with LDAP. If an authorization identity of a form different from a
- DN is requested by the client, a mechanism that protects the password
- in transit SHOULD be used.
-
- The following SASL-based mechanisms are not considered in this
- document: KERBEROS_V4, GSSAPI and SKEY.
-
-
-
-
-
-Wahl, et al. Standards Track [Page 10]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The "EXTERNAL" SASL mechanism can be used to request the LDAP server
- make use of security credentials exchanged by a lower layer. If a TLS
- session has not been established between the client and server prior
- to making the SASL EXTERNAL Bind request and there is no other
- external source of authentication credentials (e.g. IP-level
- security [8]), or if, during the process of establishing the TLS
- session, the server did not request the client's authentication
- credentials, the SASL EXTERNAL bind MUST fail with a result code of
- inappropriateAuthentication. Any client authentication and
- authorization state of the LDAP association is lost, so the LDAP
- association is in an anonymous state after the failure.
-
-9. Authorization Identity
-
- The authorization identity is carried as part of the SASL credentials
- field in the LDAP Bind request and response.
-
- When the "EXTERNAL" mechanism is being negotiated, if the credentials
- field is present, it contains an authorization identity of the
- authzId form described below.
-
- Other mechanisms define the location of the authorization identity in
- the credentials field.
-
- The authorization identity is a string in the UTF-8 character set,
- corresponding to the following ABNF [7]:
-
- ; Specific predefined authorization (authz) id schemes are
- ; defined below -- new schemes may be defined in the future.
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id.
- dnAuthzId = "dn:" dn
- dn = utf8string ; with syntax defined in RFC 2253
-
- ; unspecified userid, UTF-8 encoded.
- uAuthzId = "u:" userid
- userid = utf8string ; syntax unspecified
-
- A utf8string is defined to be the UTF-8 encoding of one or more ISO
- 10646 characters.
-
- All servers which support the storage of authentication credentials,
- such as passwords or certificates, in the directory MUST support the
- dnAuthzId choice.
-
-
-
-
-
-Wahl, et al. Standards Track [Page 11]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The uAuthzId choice allows for compatibility with client applications
- which wish to authenticate to a local directory but do not know their
- own Distinguished Name or have a directory entry. The format of the
- string is defined as only a sequence of UTF-8 encoded ISO 10646
- characters, and further interpretation is subject to prior agreement
- between the client and server.
-
- For example, the userid could identify a user of a specific directory
- service, or be a login name or the local-part of an RFC 822 email
- address. In general a uAuthzId MUST NOT be assumed to be globally
- unique.
-
- Additional authorization identity schemes MAY be defined in future
- versions of this document.
-
-10. TLS Ciphersuites
-
- The following ciphersuites defined in [6] MUST NOT be used for
- confidentiality protection of passwords or data:
-
- TLS_NULL_WITH_NULL_NULL
- TLS_RSA_WITH_NULL_MD5
- TLS_RSA_WITH_NULL_SHA
-
- The following ciphersuites defined in [6] can be cracked easily (less
- than a week of CPU time on a standard CPU in 1997). The client and
- server SHOULD carefully consider the value of the password or data
- being protected before using these ciphersuites:
-
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
- TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
-
- The following ciphersuites are vulnerable to man-in-the-middle
- attacks, and SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger of a
- man-in-the-middle attack is tolerable:
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 12]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_WITH_RC4_128_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_WITH_DES_CBC_SHA
- TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
-
- A client or server that supports TLS MUST support at least
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
-
-11. SASL service name for LDAP
-
- For use with SASL [2], a protocol must specify a service name to be
- used with various SASL mechanisms, such as GSSAPI. For LDAP, the
- service name is "ldap", which has been registered with the IANA as a
- GSSAPI service name.
-
-12. Security Considerations
-
- Security issues are discussed throughout this memo; the
- (unsurprising) conclusion is that mandatory security is important,
- and that session encryption is required when snooping is a problem.
-
- Servers are encouraged to prevent modifications by anonymous users.
- Servers may also wish to minimize denial of service attacks by timing
- out idle connections, and returning the unwillingToPerform result
- code rather than performing computationally expensive operations
- requested by unauthorized clients.
-
- A connection on which the client has not performed the Start TLS
- operation or negotiated a suitable SASL mechanism for connection
- integrity and encryption services is subject to man-in-the-middle
- attacks to view and modify information in transit.
-
- Additional security considerations relating to the EXTERNAL mechanism
- to negotiate TLS can be found in [2], [5] and [6].
-
-13. Acknowledgements
-
- This document is a product of the LDAPEXT Working Group of the IETF.
- The contributions of its members is greatly appreciated.
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 13]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-14. Bibliography
-
- [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
- 2222, October 1997.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
- Mechanism", RFC 2831, May 2000.
-
- [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
- Protocol (v3): Extension for Transport Layer Security", RFC 2830,
- May 2000.
-
- [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
- 2246, January 1999.
-
- [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
- Protocol", RFC 2401, November 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 14]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-15. Authors' Addresses
-
- Mark Wahl
- Sun Microsystems, Inc.
- 8911 Capital of Texas Hwy #4140
- Austin TX 78759
- USA
-
- EMail: M.Wahl@innosoft.com
-
-
- Harald Tveit Alvestrand
- EDB Maxware
- Pirsenteret
- N-7462 Trondheim, Norway
-
- Phone: +47 73 54 57 97
- EMail: Harald@Alvestrand.no
-
-
- Jeff Hodges
- Oblix, Inc.
- 18922 Forge Drive
- Cupertino, CA 95014
- USA
-
- Phone: +1-408-861-6656
- EMail: JHodges@oblix.com
-
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA 98105
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 15]
-\f
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-16. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 16]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group J. Hodges
-Request for Comments: 2830 Oblix Inc.
-Category: Standards Track R. Morgan
- Univ of Washington
- M. Wahl
- Sun Microsystems, Inc.
- May 2000
-
-
- Lightweight Directory Access Protocol (v3):
- Extension for Transport Layer Security
-
-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 (2000). All Rights Reserved.
-
-Abstract
-
- This document defines the "Start Transport Layer Security (TLS)
- Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
- establishment in an LDAP association and is defined in terms of an
- LDAP extended request.
-
-1. Conventions Used in this Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [ReqsKeywords].
-
-2. The Start TLS Request
-
- This section describes the Start TLS extended request and extended
- response themselves: how to form the request, the form of the
- response, and enumerates the various result codes the client MUST be
- prepared to handle.
-
- The section following this one then describes how to sequence an
- overall Start TLS Operation.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 1]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-2.1. Requesting TLS Establishment
-
- A client may perform a Start TLS operation by transmitting an LDAP
- PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
- Start TLS operation:
-
- 1.3.6.1.4.1.1466.20037
-
- An LDAP ExtendedRequest is defined as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- A Start TLS extended request is formed by setting the requestName
- field to the OID string given above. The requestValue field is
- absent. The client MUST NOT send any PDUs on this connection
- following this request until it receives a Start TLS extended
- response.
-
- When a Start TLS extended request is made, the server MUST return an
- LDAP PDU containing a Start TLS extended response. An LDAP
- ExtendedResponse is defined as follows:
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- A Start TLS extended response MUST contain a responseName field which
- MUST be set to the same string as that in the responseName field
- present in the Start TLS extended request. The response field is
- absent. The server MUST set the resultCode field to either success or
- one of the other values outlined in section 2.3.
-
-2.2. "Success" Response
-
- If the ExtendedResponse contains a resultCode of success, this
- indicates that the server is willing and able to negotiate TLS. Refer
- to section 3, below, for details.
-
-2.3. Response other than "success"
-
- If the ExtendedResponse contains a resultCode other than success,
- this indicates that the server is unwilling or unable to negotiate
- TLS.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 2]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- If the Start TLS extended request was not successful, the resultCode
- will be one of:
-
- operationsError (operations sequencing incorrect; e.g. TLS already
- established)
-
- protocolError (TLS not supported or incorrect PDU structure)
-
- referral (this server doesn't do TLS, try this one)
-
- unavailable (e.g. some major problem with TLS, or server is
- shutting down)
-
- The server MUST return operationsError if the client violates any of
- the Start TLS extended operation sequencing requirements described in
- section 3, below.
-
- If the server does not support TLS (whether by design or by current
- configuration), it MUST set the resultCode to protocolError (see
- section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
- an actual referral value in the LDAP Result if it returns a
- resultCode of referral. The client's current session is unaffected if
- the server does not support TLS. The client MAY proceed with any LDAP
- operation, or it MAY close the connection.
-
- The server MUST return unavailable if it supports TLS but cannot
- establish a TLS connection for some reason, e.g. the certificate
- server not responding, it cannot contact its TLS implementation, or
- if the server is in process of shutting down. The client MAY retry
- the StartTLS operation, or it MAY proceed with any other LDAP
- operation, or it MAY close the connection.
-
-3. Sequencing of the Start TLS Operation
-
- This section describes the overall procedures clients and servers
- MUST follow for TLS establishment. These procedures take into
- consideration various aspects of the overall security of the LDAP
- association including discovery of resultant security level and
- assertion of the client's authorization identity.
-
- Note that the precise effects, on a client's authorization identity,
- of establishing TLS on an LDAP association are described in detail in
- section 5.
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 3]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-3.1. Requesting to Start TLS on an LDAP Association
-
- The client MAY send the Start TLS extended request at any time after
- establishing an LDAP association, except that in the following cases
- the client MUST NOT send a Start TLS extended request:
-
- - if TLS is currently established on the connection, or
- - during a multi-stage SASL negotiation, or
- - if there are any LDAP operations outstanding on the connection.
-
- The result of violating any of these requirements is a resultCode of
- operationsError, as described above in section 2.3.
-
- The client MAY have already performed a Bind operation when it sends
- a Start TLS request, or the client might have not yet bound.
-
- If the client did not establish a TLS connection before sending any
- other requests, and the server requires the client to establish a TLS
- connection before performing a particular request, the server MUST
- reject that request with a confidentialityRequired or
- strongAuthRequired result. The client MAY send a Start TLS extended
- request, or it MAY choose to close the connection.
-
-3.2. Starting TLS
-
- The server will return an extended response with the resultCode of
- success if it is willing and able to negotiate TLS. It will return
- other resultCodes, documented above, if it is unable.
-
- In the successful case, the client, which has ceased to transfer LDAP
- requests on the connection, MUST either begin a TLS negotiation or
- close the connection. The client will send PDUs in the TLS Record
- Protocol directly over the underlying transport connection to the
- server to initiate TLS negotiation [TLS].
-
-3.3. TLS Version Negotiation
-
- Negotiating the version of TLS or SSL to be used is a part of the TLS
- Handshake Protocol, as documented in [TLS]. Please refer to that
- document for details.
-
-3.4. Discovery of Resultant Security Level
-
- After a TLS connection is established on an LDAP association, both
- parties MUST individually decide whether or not to continue based on
- the privacy level achieved. Ascertaining the TLS connection's privacy
- level is implementation dependent, and accomplished by communicating
- with one's respective local TLS implementation.
-
-
-
-Hodges, et al. Standards Track [Page 4]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- If the client or server decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD gracefully
- close the TLS connection immediately after the TLS negotiation has
- completed (see sections 4.1 and 5.2, below).
-
- The client MAY attempt to Start TLS again, or MAY send an unbind
- request, or send any other LDAP request.
-
-3.5. Assertion of Client's Authorization Identity
-
- The client MAY, upon receipt of a Start TLS extended response
- indicating success, assert that a specific authorization identity be
- utilized in determining the client's authorization status. The client
- accomplishes this via an LDAP Bind request specifying a SASL
- mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
-
-3.6. Server Identity Check
-
- The client MUST check its understanding of the server's hostname
- against the server's identity as presented in the server's
- Certificate message, in order to prevent man-in-the-middle attacks.
-
- Matching is performed according to these rules:
-
- - The client MUST use the server hostname it used to open the LDAP
- connection as the value to compare against the server name as
- expressed in the server's certificate. The client MUST NOT use the
- server's canonical DNS name or any other derived form of name.
-
- - If a subjectAltName extension of type dNSName is present in the
- certificate, it SHOULD be used as the source of the server's
- identity.
-
- - Matching is case-insensitive.
-
- - The "*" wildcard character is allowed. If present, it applies only
- to the left-most name component.
-
- E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
- bar.com. If more than one identity of a given type is present in the
- certificate (e.g. more than one dNSName name), a match in any one of
- the set is considered acceptable.
-
- If the hostname does not match the dNSName-based identity in the
- certificate per the above check, user-oriented clients SHOULD either
- notify the user (clients MAY give the user the opportunity to
-
-
-
-
-
-Hodges, et al. Standards Track [Page 5]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- continue with the connection in any case) or terminate the connection
- and indicate that the server's identity is suspect. Automated clients
- SHOULD close the connection, returning and/or logging an error
- indicating that the server's identity is suspect.
-
- Beyond the server identity checks described in this section, clients
- SHOULD be prepared to do further checking to ensure that the server
- is authorized to provide the service it is observed to provide. The
- client MAY need to make use of local policy information.
-
-3.7. Refresh of Server Capabilities Information
-
- The client MUST refresh any cached server capabilities information
- (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon
- TLS session establishment. This is necessary to protect against
- active-intermediary attacks which may have altered any server
- capabilities information retrieved prior to TLS establishment. The
- server MAY advertise different capabilities after TLS establishment.
-
-4. Closing a TLS Connection
-
-4.1. Graceful Closure
-
- Either the client or server MAY terminate the TLS connection on an
- LDAP association by sending a TLS closure alert. This will leave the
- LDAP association intact.
-
- Before closing a TLS connection, the client MUST either wait for any
- outstanding LDAP operations to complete, or explicitly abandon them
- [LDAPv3].
-
- After the initiator of a close has sent a closure alert, it MUST
- discard any TLS messages until it has received an alert from the
- other party. It will cease to send TLS Record Protocol PDUs, and
- following the receipt of the alert, MAY send and receive LDAP PDUs.
-
- The other party, if it receives a closure alert, MUST immediately
- transmit a TLS closure alert. It will subsequently cease to send TLS
- Record Protocol PDUs, and MAY send and receive LDAP PDUs.
-
-4.2. Abrupt Closure
-
- Either the client or server MAY abruptly close the entire LDAP
- association and any TLS connection established on it by dropping the
- underlying TCP connection. A server MAY beforehand send the client a
- Notice of Disconnection [LDAPv3] in this case.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 6]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-5. Effects of TLS on a Client's Authorization Identity
-
- This section describes the effects on a client's authorization
- identity brought about by establishing TLS on an LDAP association.
- The default effects are described first, and next the facilities for
- client assertion of authorization identity are discussed including
- error conditions. Lastly, the effects of closing the TLS connection
- are described.
-
- Authorization identities and related concepts are defined in
- [AuthMeth].
-
-5.1. TLS Connection Establishment Effects
-
-5.1.1. Default Effects
-
- Upon establishment of the TLS connection onto the LDAP association,
- any previously established authentication and authorization
- identities MUST remain in force, including anonymous state. This
- holds even in the case where the server requests client
- authentication via TLS -- e.g. requests the client to supply its
- certificate during TLS negotiation (see [TLS]).
-
-5.1.2. Client Assertion of Authorization Identity
-
- A client MAY either implicitly request that its LDAP authorization
- identity be derived from its authenticated TLS credentials or it MAY
- explicitly provide an authorization identity and assert that it be
- used in combination with its authenticated TLS credentials. The
- former is known as an implicit assertion, and the latter as an
- explicit assertion.
-
-5.1.2.1. Implicit Assertion
-
- An implicit authorization identity assertion is accomplished after
- TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
- the optional credentials octet string (found within the
- SaslCredentials sequence in the Bind Request). The server will derive
- the client's authorization identity from the authentication identity
- supplied in the client's TLS credentials (typically a public key
- certificate) according to local policy. The underlying mechanics of
- how this is accomplished are implementation specific.
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 7]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-5.1.2.2. Explicit Assertion
-
- An explicit authorization identity assertion is accomplished after
- TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
- credentials octet string. This string MUST be constructed as
- documented in section 9 of [AuthMeth].
-
-5.1.2.3. Error Conditions
-
- For either form of assertion, the server MUST verify that the
- client's authentication identity as supplied in its TLS credentials
- is permitted to be mapped to the asserted authorization identity. The
- server MUST reject the Bind operation with an invalidCredentials
- resultCode in the Bind response if the client is not so authorized.
-
- Additionally, with either form of assertion, if a TLS session has not
- been established between the client and server prior to making the
- SASL EXTERNAL Bind request and there is no other external source of
- authentication credentials (e.g. IP-level security [IPSEC]), or if,
- during the process of establishing the TLS session, the server did
- not request the client's authentication credentials, the SASL
- EXTERNAL bind MUST fail with a result code of
- inappropriateAuthentication.
-
- After the above Bind operation failures, any client authentication
- and authorization state of the LDAP association is lost, so the LDAP
- association is in an anonymous state after the failure. TLS
- connection state is unaffected, though a server MAY end the TLS
- connection, via a TLS close_notify message, based on the Bind failure
- (as it MAY at any time).
-
-5.2. TLS Connection Closure Effects
-
- Closure of the TLS connection MUST cause the LDAP association to move
- to an anonymous authentication and authorization state regardless of
- the state established over TLS and regardless of the authentication
- and authorization state prior to TLS connection establishment.
-
-6. Security Considerations
-
- The goals of using the TLS protocol with LDAP are to ensure
- connection confidentiality and integrity, and to optionally provide
- for authentication. TLS expressly provides these capabilities, as
- described in [TLS].
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 8]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- All security gained via use of the Start TLS operation is gained by
- the use of TLS itself. The Start TLS operation, on its own, does not
- provide any additional security.
-
- The use of TLS does not provide or ensure for confidentiality and/or
- non-repudiation of the data housed by an LDAP-based directory server.
- Nor does it secure the data from inspection by the server
- administrators. Once established, TLS only provides for and ensures
- confidentiality and integrity of the operations and data in transit
- over the LDAP association, and only if the implementations on the
- client and server support and negotiate it.
-
- The level of security provided though the use of TLS depends directly
- on both the quality of the TLS implementation used and the style of
- usage of that implementation. Additionally, an active-intermediary
- attacker can remove the Start TLS extended operation from the
- supportedExtension attribute of the root DSE. Therefore, both parties
- SHOULD independently ascertain and consent to the security level
- achieved once TLS is established and before beginning use of the TLS
- connection. For example, the security level of the TLS connection
- might have been negotiated down to plaintext.
-
- Clients SHOULD either warn the user when the security level achieved
- does not provide confidentiality and/or integrity protection, or be
- configurable to refuse to proceed without an acceptable level of
- security.
-
- Client and server implementors SHOULD take measures to ensure proper
- protection of credentials and other confidential data where such
- measures are not otherwise provided by the TLS implementation.
-
- Server implementors SHOULD allow for server administrators to elect
- whether and when connection confidentiality and/or integrity is
- required, as well as elect whether and when client authentication via
- TLS is required.
-
-7. Acknowledgements
-
- The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish
- Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their
- contributions to this document.
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 9]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-8. References
-
- [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, December
- 1997.
-
- [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
- 1.0", RFC 2246, January 1999.
-
-9. Authors' Addresses
-
- Jeff Hodges
- Oblix, Inc.
- 18922 Forge Drive
- Cupertino, CA 95014
- USA
-
- Phone: +1-408-861-6656
- EMail: JHodges@oblix.com
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
- Mark Wahl
- Sun Microsystems, Inc.
- 8911 Capital of Texas Hwy #4140
- Austin TX 78759
- USA
-
- EMail: M.Wahl@innosoft.com
-
-
-
-Hodges, et al. Standards Track [Page 10]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-10. Intellectual Property Rights Notices
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 11]
-\f
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 12]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group J. Hodges
-Request for Comments: 3377 Sun Microsystems Inc.
-Category: Standards Track R. Morgan
- University of Washington
- September 2002
-
-
- Lightweight Directory Access Protocol (v3):
- Technical Specification
-
-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 (2002). All Rights Reserved.
-
-Abstract
-
- This document specifies the set of RFCs comprising the Lightweight
- Directory Access Protocol Version 3 (LDAPv3), and addresses the "IESG
- Note" attached to RFCs 2251 through 2256.
-
-1. Background and Motivation
-
- The specification for the Lightweight Directory Access Protocol
- version 3 (LDAPv3) nominally comprises eight RFCs which were issued
- in two distinct subsets at separate times -- RFCs 2251 through 2256
- first, then RFCs 2829 and 2830 following later.
-
- RFC 2251 through 2256 do not mandate the implementation of any
- satisfactory authentication mechanisms and hence were published with
- an "IESG Note" discouraging implementation and deployment of LDAPv3
- clients or servers implementing update functionality until a Proposed
- Standard for mandatory authentication in LDAPv3 is published.
-
- RFC 2829 was subsequently published in answer to the IESG Note.
-
- The purpose of this document is to explicitly specify the set of RFCs
- comprising LDAPv3, and formally address the IESG Note through
- explicit inclusion of RFC 2829.
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 1]
-\f
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-2. Specification of LDAPv3
-
- The Lightweight Directory Access Protocol version 3 (LDAPv3) is
- specified by this set of nine RFCs:
-
- [RFC2251] Lightweight Directory Access Protocol (v3) [the
- specification of the LDAP on-the-wire protocol]
-
- [RFC2252] Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions
-
- [RFC2253] Lightweight Directory Access Protocol (v3): UTF-8
- String Representation of Distinguished Names
-
- [RFC2254] The String Representation of LDAP Search Filters
-
- [RFC2255] The LDAP URL Format
-
- [RFC2256] A Summary of the X.500(96) User Schema for use with
- LDAPv3
-
- [RFC2829] Authentication Methods for LDAP
-
- [RFC2830] Lightweight Directory Access Protocol (v3): Extension
- for Transport Layer Security
-
- And, this document (RFC3377).
-
- The term "LDAPv3" is often used informally to refer to the protocol
- specified by the above set of RFCs, or subsets thereof. However, the
- LDAPv3 protocol suite, as defined here, should be formally identified
- in other documents by a normative reference to this document.
-
-3. Addressing the "IESG Note" in RFCs 2251 through 2256
-
- The IESG approved publishing RFCs 2251 through 2256 with an attendant
- IESG Note included in each document. The Note begins with:
-
- 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.
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 2]
-\f
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
- The Note ends with this statement:
-
- 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.
-
- [RFC2829] is expressly the "Proposed Standard for mandatory
- authentication in LDAPv3" called for in the Note. Thus, the IESG
- Note in [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2255], and
- [RFC2256] is addressed.
-
-4. Security Considerations
-
- This document does not directly discuss security, although the
- context of the aforementioned IESG Note is security related, as is
- the manner in which it is addressed.
-
- Please refer to the referenced documents, especially [RFC2829],
- [RFC2251], and [RFC2830], for further information concerning LDAPv3
- security.
-
-5. Acknowledgements
-
- The authors thank Patrik Faltstrom, Leslie Daigle, Thomas Narten, and
- Kurt Zeilenga for their contributions to this document.
-
-6. References
-
- [RFC2251] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory
- Access Protocol (v3): UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
-
- [RFC2254] Howes, T., "The String Representation of LDAP Search
- Filters", RFC 2254, December 1997.
-
- [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
-
-
-Hodges & Morgan Standards Track [Page 3]
-\f
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
- [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
-
-7. Intellectual Property Rights Notices
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 4]
-\f
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-8. Authors' Addresses
-
- Jeff Hodges
- Sun Microsystems, Inc.
- 901 San Antonio Road, USCA22-212
- Palo Alto, CA 94303
- USA
-
- Phone: +1-408-276-5467
- EMail: Jeff.Hodges@sun.com
-
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 5]
-\f
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 6]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 3383 OpenLDAP Foundation
-BCP: 64 September 2002
-Category: Best Current Practice
-
-
- Internet Assigned Numbers Authority (IANA) Considerations
- for the Lightweight Directory Access Protocol (LDAP)
-
-Status of this Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document provides procedures for registering extensible elements
- of the Lightweight Directory Access Protocol (LDAP). This document
- also provides guidelines to the Internet Assigned Numbers Authority
- (IANA) describing conditions under which new values can be assigned.
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
- extensible protocol. LDAP supports:
-
- - addition of new operations,
- - extension of existing operations, and
- - extensible schema.
-
- This document details procedures for registering values of used to
- unambiguously identify extensible elements of the protocol including:
-
- - LDAP message types;
- - LDAP extended operations and controls;
- - LDAP result codes;
- - LDAP authentication methods;
- - LDAP attribute description options; and
- - Object Identifier descriptors.
-
- These registries are maintained by the Internet Assigned Numbers
- Authority (IANA).
-
-
-
-
-Zeilenga Best Current Practice [Page 1]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- In addition, this document provides guidelines to IANA describing the
- conditions under which new values can be assigned.
-
-2. Terminology and Conventions
-
- This section details terms and conventions used in this document.
-
-2.1. Policy Terminology
-
- The terms "IESG Approval", "Standards Action", "IETF Consensus",
- "Specification Required", "First Come First Served", "Expert Review",
- and "Private Use" are used as defined in BCP 26 [RFC2434].
-
-2.2. Requirement Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119]. In
- this case, "the specification" as used by BCP 14 refers to the
- processing of protocols being submitted to the IETF standards
- process.
-
-2.3. Common ABNF Productions
-
- A number of syntaxes in this document are described using ABNF
- [RFC2234]. These syntaxes rely on the following common productions:
-
- ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
-
- LDIGIT = %x31-39 ; 1-9
-
- DIGIT = %x30 / LDIGIT ; 0-9
-
- HYPHEN = %x2D ; "-"
-
- DOT = %x2E ; "."
-
- number = DIGIT / ( LDIGIT 1*DIGIT )
-
- keychar = ALPHA / DIGIT / HYPHEN
-
- leadkeychar = ALPHA
-
- keystring = leadkeychar *keychar
-
- A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
- characters from the Universal Character Set (UCS) [ISO10646]
- restricted to the <keystring> production.
-
-
-
-Zeilenga Best Current Practice [Page 2]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3. IANA Considerations for LDAP
-
- This section details each kind of protocol value which can be
- registered and provides IANA guidelines on how to assign new values.
-
- IANA may reject obviously bogus registration requests.
-
-3.1. Object Identifiers
-
- Numerous LDAP schema and protocol elements are identified by Object
- Identifiers. Specifications which assign OIDs to elements SHOULD
- state who delegated the OIDs for its use.
-
- For IETF developed elements, specifications SHOULD use OIDs under
- "Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID
- arc will be assigned upon Expert Review with Specification Required.
- Only one OID per specification will be assigned. The specification
- MAY then assign any number of OIDs within this arc without further
- coordination with IANA.
-
- For elements developed by others, any properly delegated OID can
- be used, including those under "Internet Private Enterprise
- Numbers" (1.3.6.1.4.1.x) assigned by IANA
- <http://www.iana.org/cgi-bin/enterprise.pl>.
-
- To avoid interoperability problems between early implementations of
- "works in progress" and implementations of the published
- specification (e.g., the RFC), experimental OIDs SHOULD be used in
- "works in progress" and early implementations. OIDs under the
- Internet Experimental OID arc (1.3.6.1.3.x) may be used for this
- purpose.
-
- Experimental OIDs are not to used in published specifications (e.g.,
- RFCs).
-
- Practices for IANA assignment of Internet Enterprise and Experimental
- OIDs are detailed in STD 16 [RFC1155].
-
-3.2 Protocol Mechanisms
-
- LDAP provides a number of Root DSE attributes for discovery of
- protocol mechanisms identified by OIDs, including:
-
- - supportedControl [RFC2252] and
- - supportedExtension [RFC2252].
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 3]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- A registry of OIDs used for discover of protocol mechanisms is
- provided to allow implementors and others to locate the technical
- specification for these protocol mechanisms. Future specifications
- of additional Root DSE attributes holding values identifying protocol
- mechanisms MAY extend this registry for their values.
-
- OIDs associated with discoverable protocol mechanisms SHOULD be
- registered. These are be considered on a First Come First Served
- with Specification Required basis.
-
- OIDs associated with Standard Track mechanisms MUST be registered and
- require Standards Action.
-
-3.3. Object Identifier Descriptors
-
- LDAP allows short descriptive names (or descriptors) to be used
- instead of a numeric Object Identifier to identify protocol
- extensions [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255]
- extensions, and other objects. Descriptors are restricted to strings
- of UTF-8 encoded UCS characters restricted by the following ABNF:
-
- name = keystring
-
- Descriptors are case-insensitive.
-
- Multiple names may be assigned to a given OID. For purposes of
- registration, an OID is to be represented in numeric OID form
- conforming to the ABNF:
-
- numericoid = number *( DOT number ) ; e.g., 1.1.0.23.40
-
- While the protocol places no maximum length restriction upon
- descriptors, they should be short. Descriptors longer than 48
- characters may be viewed as too long to register.
-
- A values ending with a hyphen ("-") reserve all descriptors which
- start with the value. For example, the registration of the option
- "descrFamily-" reserves all options which start with "descrFamily-"
- for some related purpose.
-
- Descriptors beginning with "x-" are for Private Use and cannot be
- registered.
-
- Descriptors beginning with "e-" are reserved for experiments and will
- be registered on a First Come First Served basis.
-
- All other descriptors require Expert Review to be registered.
-
-
-
-
-Zeilenga Best Current Practice [Page 4]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- The registrant need not "own" the OID being named.
-
- The OID namespace is managed by The ISO/IEC Joint Technical Committee
- 1 - Subcommittee 6.
-
-3.4. AttributeDescription Options
-
- An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or
- more options specifying additional semantics. An option SHALL be
- restricted to a string UTF-8 encoded UCS characters limited by the
- following ABNF:
-
- option = keystring
-
- Options are case-insensitive.
-
- While the protocol places no maximum length restriction upon option
- strings, they should be short. Options longer than 24 characters may
- be viewed as too long to register.
-
- Values ending with a hyphen ("-") reserve all option names which
- start with the name. For example, the registration of the option
- "optionFamily-" reserves all options which start with "optionFamily-"
- for some related purpose.
-
- Options beginning with "x-" are for Private Use and cannot be
- registered.
-
- Options beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other options require Standards Action or Expert Review with
- Specification Required to be registered.
-
-3.5. LDAP Message Types
-
- Each protocol message is encapsulated in an LDAPMessage envelope
- [RFC2251, Section 4.1.1]. The protocolOp CHOICE indicates the type
- of message encapsulated. Each message type consists of a keyword and
- a non-negative choice number is combined with the class (APPLICATION)
- and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in
- the message's encoding. The choice numbers for existing protocol
- messages are implicit in the protocol's ASN.1 defined in [RFC2251].
-
- New values will be registered upon Standards Action.
-
- Note: LDAP provides extensible messages which reduces, but does not
- eliminate, the need to add new message types.
-
-
-
-Zeilenga Best Current Practice [Page 5]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3.6. LDAP Result Codes
-
- LDAP result messages carry an resultCode enumerated value to indicate
- the outcome of the operation [RFC2251, Section 4.1.10]. Each result
- code consists of a keyword and a non-negative integer.
-
- New resultCodes integers in the range 0-1023 require Standards Action
- to be registered. New resultCode integers in the range 1024-4095
- require Expert Review with Specification Required. New resultCode
- integers in the range 4096-16383 will be registered on a First Come
- First Served basis. Keywords associated with integers in the range
- 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
- integers in the range 4096-16383 SHALL start with "e-". Values
- greater than or equal to 16384 and keywords starting with "x-" are
- for Private Use and cannot be registered.
-
-3.7. LDAP Authentication Method
-
- The LDAP Bind operation supports multiple authentication methods
- [RFC2251, Section 4.2]. Each authentication choice consists of a
- keyword and a non-negative integer.
-
- The registrant SHALL classify the authentication method usage using
- one of the following terms:
-
- COMMON - method is appropriate for common use on the
- Internet,
- LIMITED USE - method is appropriate for limited use,
- OBSOLETE - method has been deprecated or otherwise found to be
- inappropriate for any use.
-
- Methods without publicly available specifications SHALL NOT be
- classified as COMMON. New registrations of class OBSOLETE cannot be
- registered.
-
- New authentication method integers in the range 0-1023 require
- Standards Action to be registered. New authentication method
- integers in the range 1024-4095 require Expert Review with
- Specification Required. New authentication method integers in the
- range 4096-16383 will be registered on a First Come First Served
- basis. Keywords associated with integers in the range 0-4095 SHALL
- NOT start with "e-" or "x-". Keywords associated with integers in
- the range 4096-16383 SHALL start with "e-". Values greater than or
- equal to 16384 and keywords starting with "x-" are for Private Use
- and cannot be registered.
-
- Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE.
- SASL is an extensible LDAP authentication method.
-
-
-
-Zeilenga Best Current Practice [Page 6]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3.8. Directory Systems Names
-
- The IANA-maintained "Directory Systems Names" registry [IANADSN] of
- valid keywords for well known attributes used in the LDAPv2 string
- representation of a distinguished name [RFC1779]. RFC 1779 was
- obsoleted by RFC 2253.
-
- Directory systems names are not known to be used in any other
- context. LDAPv3 uses Object Identifier Descriptors [Section 3.2]
- (which have a different syntax than directory system names).
-
- New Directory System Names will no longer be accepted. For
- historical purposes, the current list of registered names should
- remain publicly available.
-
-4. Registration Procedure
-
- The procedure given here MUST be used by anyone who wishes to use a
- new value of a type described in Section 3 of this document.
-
- The first step is for the requester to fill out the appropriate form.
- Templates are provided in Appendix A.
-
- If the policy is Standards Action, the completed form SHOULD be
- provided to the IESG with the request for Standards Action. Upon
- approval of the Standards Action, the IESG SHALL forward the request
- (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
- all values requiring Standards Action.
-
- If the policy is Expert Review, the requester SHALL post the
- completed form to the <directory@apps.ietf.org> mailing list for
- public review. The review period is two (2) weeks. If a revised
- form is later submitted, the review period is restarted. Anyone
- may subscribe to this list by sending a request to
- <directory-request@apps.ietf.org>. During the review, objections
- may be raised by anyone (including the Expert) on the list. After
- completion of the review, the Expert, based upon public comments,
- SHALL either approve the request and forward it to the IESG OR deny
- the request. In either case, the Expert SHALL promptly notify the
- requester of the action. Actions of the Expert may be appealed
- [RFC2026]. The Expert is appointed by Applications Area Director(s).
- The requester is viewed as the owner of values registered under
- Expert Review.
-
- If the policy is First Come First Served, the requester SHALL submit
- the completed form directly to the IANA: <iana@iana.org>. The
- requester is viewed as the owner of values registered under First
- Come First Served.
-
-
-
-Zeilenga Best Current Practice [Page 7]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- Neither the Expert nor IANA will take position on the claims of
- copyright or trademarks issues regarding completed forms.
-
- Prior to submission of the Internet Draft (I-D) to the RFC Editor but
- after IESG review and tentative approval, the document editor SHOULD
- revise the I-D to use registered values.
-
-5. Registration Maintenance
-
- This section discusses maintenance of registrations.
-
-5.1. Lists of Registered Values
-
- IANA makes lists of registered values readily available to the
- Internet community on their web site: <http://www.iana.org/>.
-
-5.2. Change Control
-
- The registration owner MAY update the registration subject to the
- same constraints and review as with new registrations. In cases
- where the owner is not unable or unwilling to make necessary updates,
- the IESG MAY assert ownership in order to update the registration.
-
-5.3. Comments
-
- For cases where others (anyone other than the owner) have significant
- objections to the claims in a registration and the owner does not
- agree to change the registration, comments MAY be attached to a
- registration upon Expert Review. For registrations owned by the
- IESG, the objections SHOULD be addressed by initiating a request for
- Expert Review.
-
- The form of these requests is ad hoc, but MUST include the specific
- objections to be reviewed and SHOULD contain (directly or by
- reference) materials supporting the objections.
-
-6. Security Considerations
-
- The security considerations detailed in [RFC2434] are generally
- applicable to this document. Additional security considerations
- specific to each namespace are discussed in Section 3 where
- appropriate.
-
- Security considerations for LDAP are discussed in documents
- comprising the technical specification [RFC3377].
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 8]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-7. Acknowledgment
-
- This document is a product of the IETF LDAP Revision (LDAPbis)
- Working Group. Some text was borrowed from "Guidelines for Writing
- an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten
- and Harald Alvestrand.
-
-8. Normative References
-
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
- of Management Information for TCP/IP-based Internets", STD
- 16, RFC 1155, May 1990.
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
- December, 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [IANADSN] IANA, "Directory Systems Names",
- http://www.iana.org/assignments/directory-system-names
-
-
-
-Zeilenga Best Current Practice [Page 9]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1: 1993.
-
-10. Informative References
-
- [RFC1779] Kille, S., "A String Representation of Distinguished
- Names", RFC 1779, March 1995.
-
- [RFC2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 10]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Appendix A. Registration Templates
-
- This appendix provides registration templates for registering new
- LDAP values.
-
-A.1. LDAP Object Identifier Registration Template
-
- Subject: Request for LDAP OID Registration
-
- Person & email address to contact for further information:
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.2. LDAP Protocol Mechanism Registration Template
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Usage: (One of Control or Extension)
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 11]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-A.3. LDAP Descriptor Registration Template
-
- Subject: Request for LDAP Descriptor Registration
-
- Descriptor (short name):
-
- Object Identifier:
-
- Person & email address to contact for further information:
-
- Usage: (One of attribute type, URL extension,
- object class, or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.4. LDAP Attribute Description Option Registration Template
-
- Subject: Request for LDAP Attribute Description Option Registration
-
- Option Name:
-
- Family of Options: (YES or NO)
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 12]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-A.5. LDAP Message Type Registration Template
-
- Subject: Request for LDAP Message Type Registration
-
- LDAP Message Name:
-
- Person & email address to contact for further information:
-
- Specification: (Approved I-D)
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.6. LDAP Result Code Registration Template
-
- Subject: Request for LDAP Result Code Registration
-
- Result Code Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.7. LDAP Authentication Method Registration Template
-
- Subject: Request for LDAP Authentication Method Registration
-
- Authentication Method Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-Zeilenga Best Current Practice [Page 13]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Appendix B. Assigned Values
-
- The following values are currently assigned.
-
-B.1. Object Identifiers
-
- Currently registered "Internet Private Enterprise Numbers" can be
- found at <http://www.iana.org/assignments/enterprise-numbers>.
-
- Currently registered "Internet Directory Numbers" can be found at
- <http://www.iana.org/assignments/smi-numbers>.
-
-B.2. Protocol Mechanisms
-
-Object Identifier Type Description Reference
--------------------------- ---- -------------- ---------
-1.2.840.113556.1.4.473 C Sort Request [RFC2891]
-1.2.840.113556.1.4.474 C Sort Response [RFC2891]
-1.3.6.1.4.1.1466.101.119.1 E Dynamic Refresh [RFC2589]
-1.3.6.1.4.1.1466.20037 E Start TLS [RFC2830]
-1.3.6.1.4.1.4203.1.11.1 E Modify Password [RFC3062]
-2.16.840.1.113730.3.4.2 C ManageDsaIT [RFC3296]
-
-Legend
-------------------------
-C => supportedControl
-E => supportedExtension
-
-B.3. Object Identifier Descriptors
-
-NAME Type OID [REF]
------------------------- ---- -----------------
-account O 0.9.2342.19200300.100.4.5 [RFC1274]
-alias O 2.5.6.1 [RFC2256]
-aliasedEntryName A 2.5.4.1 [X.501]
-aliasedObjectName A 2.5.4.1 [RFC2256]
-altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252]
-applicationEntity O 2.5.6.12 [RFC2256]
-applicationProcess O 2.5.6.11 [RFC2256]
-aRecord A 0.9.2342.19200300.100.1.26 [RFC1274]
-associatedDomain A 0.9.2342.19200300.100.1.37 [RFC1274]
-associatedInternetGateway A 1.3.6.1.4.1.453.7.2.8 [RFC2164]
-associatedName A 0.9.2342.19200300.100.1.38 [RFC1274]
-associatedORAddress A 1.3.6.1.4.1.453.7.2.6 [RFC2164]
-associatedX400Gateway A 1.3.6.1.4.1.453.7.2.3 [RFC2164]
-attributeTypes A 2.5.21.5 [RFC2252]
-audio A 0.9.2342.19200300.100.1.55 [RFC1274]
-authorityRevocationList A 2.5.4.38 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 14]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-bitStringMatch M 2.5.13.16 [RFC2252]
-buildingName A 0.9.2342.19200300.100.1.48 [RFC1274]
-businessCategory A 2.5.4.15 [RFC2256]
-C A 2.5.4.6 [RFC2256]
-cACertificate A 2.5.4.37 [RFC2256]
-calCalAdrURI A 1.2.840.113556.1.4.481 [RFC2739]
-calCalURI A 1.2.840.113556.1.4.478 [RFC2739]
-calCAPURI A 1.2.840.113556.1.4.480 [RFC2739]
-calEntry O 1.2.840.113556.1.5.87 [RFC2739]
-calFBURL A 1.2.840.113556.1.4.479 [RFC2739]
-calOtherCalAdrURIs A 1.2.840.113556.1.4.485 [RFC2739]
-calOtherCalURIs A 1.2.840.113556.1.4.482 [RFC2739]
-calOtherCAPURIs A 1.2.840.113556.1.4.484 [RFC2739]
-calOtherFBURLs A 1.2.840.113556.1.4.483 [RFC2739]
-caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 [RFC2252]
-caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 [RFC2252]
-caseIgnoreListMatch M 2.5.13.11 [RFC2252]
-caseIgnoreMatch M 2.5.13.2 [RFC2252]
-caseIgnoreOrderingMatch M 2.5.13.3 [RFC2252]
-caseIgnoreSubstringsMatch M 2.5.13.4 [RFC2252]
-certificateRevocationList A 2.5.4.39 [RFC2256]
-certificationAuthority O 2.5.6.16 [RFC2256]
-certificationAuthority-V2 O 2.5.6.16.2 [RFC2256]
-CN A 2.5.4.3 [RFC2256]
-cNAMERecord A 0.9.2342.19200300.100.1.31 [RFC1274]
-co A 0.9.2342.19200300.100.1.43 [RFC1274]
-commonName A 2.5.4.3 [RFC2256]
-country O 2.5.6.2 [RFC2256]
-countryName A 2.5.4.6 [RFC2256]
-createTimestamp A 2.5.18.1 [RFC2252]
-creatorsName A 2.5.18.3 [RFC2252]
-cRLDistributionPoint O 2.5.6.19 [RFC2256]
-crossCertificatePair A 2.5.4.40 [RFC2256]
-DC A 0.9.2342.19200300.100.1.25 [RFC2247]
-dcObject O 1.3.6.1.4.1.1466.344 [RFC2247]
-deltaCRL O 2.5.6.23 [RFC2587]
-deltaRevocationList A 2.5.4.53 [RFC2256]
-description A 2.5.4.13 [RFC2256]
-destinationIndicator A 2.5.4.27 [RFC2256]
-device O 2.5.6.14 [RFC2256]
-distinguishedName A 2.5.4.49 [RFC2256]
-distinguishedNameMatch M 2.5.13.1 [RFC2252]
-distinguishedNameTableEntry O 1.3.6.1.4.1.453.7.1.5 [RFC2293]
-distinguishedNameTableKey A 1.3.6.1.4.1.453.7.2.3 [RFC2293]
-dITContentRules A 2.5.21.2 [RFC2252]
-dITRedirect A 0.9.2342.19200300.100.1.54 [RFC1274]
-dITStructureRules A 2.5.21.1 [RFC2252]
-dmd O 2.5.6.20 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 15]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-dmdName A 2.5.4.54 [RFC2256]
-dnQualifier A 2.5.4.46 [RFC2256]
-dNSDomain O 0.9.2342.19200300.100.4.15 [RFC1274]
-document O 0.9.2342.19200300.100.4.6 [RFC1274]
-documentAuthor A 0.9.2342.19200300.100.1.14 [RFC1274]
-documentIdentifier A 0.9.2342.19200300.100.1.11 [RFC1274]
-documentLocation A 0.9.2342.19200300.100.1.15 [RFC1274]
-documentPublisher A 0.9.2342.19200300.100.1.56 [RFC1274]
-documentSeries O 0.9.2342.19200300.100.4.8 [RFC1274]
-documentTitle A 0.9.2342.19200300.100.1.12 [RFC1274]
-documentVersion A 0.9.2342.19200300.100.1.13 [RFC1274]
-domain O 0.9.2342.19200300.100.4.13 [RFC2247]
-domainComponent A 0.9.2342.19200300.100.1.25 [RFC2247]
-domainNameForm N 1.3.6.1.4.1.1466.345 [RFC2247]
-domainRelatedObject O 0.9.2342.19200300.100.4.17 [RFC1274]
-drink A 0.9.2342.19200300.100.1.5 [RFC1274]
-dSA O 2.5.6.13 [RFC2256]
-dSAQuality A 0.9.2342.19200300.100.1.49 [RFC1274]
-dynamicObject O 1.3.6.1.4.1.1466.101.119.2 [RFC2589]
-dynamicSubtrees A 1.3.6.1.4.1.1466.101.119.4 [RFC2589]
-enhancedSearchGuide A 2.5.4.47 [RFC2256]
-entryTtl A 1.3.6.1.4.1.1466.101.119.3 [RFC2589]
-extensibleObject O 1.3.6.1.4.1.1466.101.120.111 [RFC2252]
-facsimileTelephoneNumber A 2.5.4.23 [RFC2256]
-favouriteDrink A 0.9.2342.19200300.100.1.5 [RFC1274]
-friendlyCountry O 0.9.2342.19200300.100.4.18 [RFC1274]
-friendlyCountryName A 0.9.2342.19200300.100.1.43 [RFC1274]
-generalizedTimeMatch M 2.5.13.27 [RFC2252]
-generalizedTimeOrderingMatch M 2.5.13.28 [RFC2252]
-generationQualifier A 2.5.4.44 [RFC2256]
-givenName A 2.5.4.42 [RFC2256]
-GN A 2.5.4.42 [RFC2256]
-groupOfNames O 2.5.6.9 [RFC2256]
-groupOfUniqueNames O 2.5.6.17 [RFC2256]
-homePhone A 0.9.2342.19200300.100.1.20 [RFC1274]
-homePostalAddress A 0.9.2342.19200300.100.1.39 [RFC1274]
-homeTelephone A 0.9.2342.19200300.100.1.20 [RFC1274]
-host A 0.9.2342.19200300.100.1.9 [RFC1274]
-houseIdentifier A 2.5.4.51 [RFC2256]
-info A 0.9.2342.19200300.100.1.4 [RFC1274]
-initials A 2.5.4.43 [RFC2256]
-integerFirstComponentMatch M 2.5.13.29 [RFC2252]
-integerMatch M 2.5.13.14 [RFC2252]
-internationaliSDNNumber A 2.5.4.25 [RFC2256]
-janetMailbox A 0.9.2342.19200300.100.1.46 [RFC1274]
-jpegPhoto A 0.9.2342.19200300.100.1.60 [RFC1488]
-knowledgeInformation A 2.5.4.2 [RFC2256]
-L A 2.5.4.7 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 16]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-labeledURI A 1.3.6.1.4.1.250.1.57 [RFC2079]
-labeledURIObject A 1.3.6.1.4.1.250.3.15 [RFC2079]
-lastModifiedBy A 0.9.2342.19200300.100.1.24 [RFC1274]
-lastModifiedTime A 0.9.2342.19200300.100.1.23 [RFC1274]
-ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 [RFC2252]
-locality O 2.5.6.3 [RFC2256]
-localityName A 2.5.4.7 [RFC2256]
-mail A 0.9.2342.19200300.100.1.3 [RFC2798]
-mailPreferenceOption A 0.9.2342.19200300.100.1.47 [RFC1274]
-manager A 0.9.2342.19200300.100.1.10 [RFC1274]
-matchingRules A 2.5.21.4 [RFC2252]
-matchingRuleUse A 2.5.21.8 [RFC2252]
-mcgamTables A 1.3.6.1.4.1.453.7.2.9 [RFC2164]
-mDRecord A 0.9.2342.19200300.100.1.27 [RFC1274]
-member A 2.5.4.31 [RFC2256]
-mixerGateway O 1.3.6.1.4.1.453.7.1.4 [RFC2164]
-mobile A 0.9.2342.19200300.100.1.41 [RFC1274]
-mobileTelephoneNumber A 0.9.2342.19200300.100.1.41 [RFC1274]
-modifiersName A 2.5.18.4 [RFC2252]
-modifyTimestamp A 2.5.18.2 [RFC2252]
-mXRecord A 0.9.2342.19200300.100.1.28 [RFC1274]
-name A 2.5.4.41 [RFC2256]
-nameForms A 2.5.21.7 [RFC2252]
-namingContexts A 1.3.6.1.4.1.1466.101.120.5 [RFC2252]
-nSRecord A 0.9.2342.19200300.100.1.29 [RFC1274]
-numericStringMatch M 2.5.13.8 [RFC2252]
-numericStringSubstringsMatch M 2.5.13.10 [RFC2252]
-O A 2.5.4.10 [RFC2256]
-objectClass A 2.5.4.0 [RFC2256]
-objectClasses A 2.5.21.6 [RFC2252]
-objectIdentifierFirstComponentMatch M 2.5.13.30 [RFC2252]
-objectIdentifiersMatch M 2.5.13.0 [RFC2252]
-octetStringMatch M 2.5.13.17 [RFC2252]
-omittedORAddressComponent O 1.3.6.1.4.1.453.7.1.3 [RFC2164]
-oRAddressComponentType A 1.3.6.1.4.1.453.7.2.7 [RFC2164]
-organization O 2.5.6.4 [RFC2256]
-organizationalPerson O 2.5.6.7 [RFC2256]
-organizationalRole O 2.5.6.8 [RFC2256]
-organizationalStatus A 0.9.2342.19200300.100.1.45 [RFC1274]
-organizationalUnit O 2.5.6.5 [RFC2256]
-organizationalUnitName A 2.5.4.11 [RFC2256]
-organizationName A 2.5.4.10 [RFC2256]
-otherMailbox A 0.9.2342.19200300.100.1.22 [RFC1274]
-OU A 2.5.4.11 [RFC2256]
-owner A 2.5.4.32 [RFC2256]
-pager A 0.9.2342.19200300.100.1.42 [RFC1274]
-pagerTelephoneNumber A 0.9.2342.19200300.100.1.42 [RFC1274]
-person O 2.5.6.6 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 17]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-personalSignature A 0.9.2342.19200300.100.1.53 [RFC1274]
-personalTitle A 0.9.2342.19200300.100.1.40 [RFC1274]
-photo A 0.9.2342.19200300.100.1.7 [RFC1274]
-physicalDeliveryOfficeName A 2.5.4.19 [RFC2256]
-pilotDSA O 0.9.2342.19200300.100.4.21 [RFC1274]
-pilotObject O 0.9.2342.19200300.100.4.3 [RFC1274]
-pilotOrganization O 0.9.2342.19200300.100.4.20 [RFC1274]
-pilotPerson O 0.9.2342.19200300.100.4.4 [RFC1274]
-pkiCA O 2.5.6.22 [RFC2587]
-pkiUser O 2.5.6.21 [RFC2587]
-postalAddress A 2.5.4.16 [RFC2256]
-postalCode A 2.5.4.17 [RFC2256]
-postOfficeBox A 2.5.4.18 [RFC2256]
-preferredDeliveryMethod A 2.5.4.28 [RFC2256]
-presentationAddress A 2.5.4.29 [RFC2256]
-presentationAddressMatch M 2.5.13.22 [RFC2252]
-protocolInformation A 2.5.4.48 [RFC2256]
-protocolInformationMatch M 2.5.13.24 [RFC2252]
-qualityLabelledData O 0.9.2342.19200300.100.4.22 [RFC1274]
-ref A 2.16.840.1.113730.3.1.34 [RFC3296]
-referral 0 2.16.840.1.113730.3.2.6 [RFC3296]
-registeredAddress A 2.5.4.26 [RFC2256]
-residentialPerson O 2.5.6.10 [RFC2256]
-RFC822LocalPart O 0.9.2342.19200300.100.4.14 [RFC1274]
-RFC822Mailbox A 0.9.2342.19200300.100.1.3 [RFC1274]
-rFC822ToX400Mapping O 1.3.6.1.4.1.453.7.1.1 [RFC2164]
-roleOccupant A 2.5.4.33 [RFC2256]
-room O 0.9.2342.19200300.100.4.7 [RFC1274]
-roomNumber A 0.9.2342.19200300.100.1.6 [RFC1274]
-searchGuide A 2.5.4.14 [RFC2256]
-secretary A 0.9.2342.19200300.100.1.21 [RFC1274]
-seeAlso A 2.5.4.34 [RFC2256]
-serialNumber A 2.5.4.5 [RFC2256]
-simpleSecurityObject O 0.9.2342.19200300.100.4.19 [RFC1274]
-singleLevelQuality A 0.9.2342.19200300.100.1.50 [RFC1274]
-SN A 2.5.4.4 [RFC2256]
-sOARecord A 0.9.2342.19200300.100.1.30 [RFC1274]
-ST A 2.5.4.8 [RFC2256]
-stateOrProvinceName A 2.5.4.8 [RFC2256]
-street A 2.5.4.9 [RFC2256]
-streetAddress A 2.5.4.9 [RFC2256]
-strongAuthenticationUser O 2.5.6.15 [RFC2256]
-subschema O 2.5.20.1 [RFC2252]
-subschemaSubentry A 2.5.18.10 [RFC2252]
-subtree O 1.3.6.1.4.1.453.7.1.1 [RFC2293]
-subtreeMaximumQuality A 0.9.2342.19200300.100.1.52 [RFC1274]
-subtreeMinimumQuality A 0.9.2342.19200300.100.1.51 [RFC1274]
-supportedAlgorithms A 2.5.4.52 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 18]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-supportedApplicationContext A 2.5.4.30 [RFC2256]
-supportedControl A 1.3.6.1.4.1.1466.101.120.13 [RFC2252]
-supportedExtension A 1.3.6.1.4.1.1466.101.120.7 [RFC2252]
-supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 [RFC2252]
-supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 [RFC2252]
-surname A 2.5.4.4 [RFC2256]
-table O 1.3.6.1.4.1.453.7.1.2 [RFC2293]
-tableEntry O 1.3.6.1.4.1.453.7.1.3 [RFC2293]
-telephoneNumber A 2.5.4.20 [RFC2256]
-telephoneNumberMatch M 2.5.13.20 [RFC2252]
-telephoneNumberSubstringsMatch M 2.5.13.21 [RFC2252]
-teletexTerminalIdentifier A 2.5.4.22 [RFC2256]
-telexNumber A 2.5.4.21 [RFC2256]
-textEncodedORAddress A 0.9.2342.19200300.100.1.2 [RFC1274]
-textTableEntry O 1.3.6.1.4.1.453.7.1.4 [RFC2293]
-textTableKey A 1.3.6.1.4.1.453.7.2.1 [RFC2293]
-textTableValue A 1.3.6.1.4.1.453.7.2.2 [RFC2293]
-title A 2.5.4.12 [RFC2256]
-top O 2.5.6.0 [RFC2256]
-uid A 0.9.2342.19200300.100.1.1 [RFC2253]
-uniqueIdentifier A 0.9.2342.19200300.100.1.44 [RFC1274]
-uniqueMember A 2.5.4.50 [RFC2256]
-uniqueMemberMatch M 2.5.13.23 [RFC2252]
-userCertificate A 2.5.4.36 [RFC2256]
-userClass A 0.9.2342.19200300.100.1.8 [RFC1274]
-userId A 0.9.2342.19200300.100.1.1 [RFC1274]
-userPassword A 2.5.4.35 [RFC2256]
-userSecurityInformation O 2.5.6.18 [RFC2256]
-x121Address A 2.5.4.24 [RFC2256]
-x400ToRFC822Mapping O 1.3.6.1.4.1.453.7.1.2 [RFC2164]
-x500UniqueIdentifier A 2.5.4.45 [RFC2256]
-
-Legend
-------------------------
-A => Attribute Type
-C => DIT Content Rule
-E => LDAP URL Extension
-M => Matching Rule
-N => Name Form
-O => Object Class
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 19]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-B.4. Attribute Description Options
-
-Option Owner Reference
----------------- ----- ---------
-binary IESG [RFC2251]
-lang-* IESG [RFC2596]
-
-* family of options
-
-B.5. LDAPMessage types
-
-Name Code Owner Reference
---------------------------- ---- ----- ---------
-bindRequest 0 IESG [RFC2251]
-bindResponse 1 IESG [RFC2251]
-unbindRequest 2 IESG [RFC2251]
-searchRequest 3 IESG [RFC2251]
-searchResEntry 4 IESG [RFC2251]
-searchResDone 5 IESG [RFC2251]
-modifyRequest 6 IESG [RFC2251]
-modifyResponse 7 IESG [RFC2251]
-addRequest 8 IESG [RFC2251]
-addResponse 9 IESG [RFC2251]
-delRequest 10 IESG [RFC2251]
-delResponse 11 IESG [RFC2251]
-modDNRequest 12 IESG [RFC2251]
-modDNResponse 13 IESG [RFC2251]
-compareRequest 14 IESG [RFC2251]
-compareResponse 15 IESG [RFC2251]
-abandonRequest 16 IESG [RFC2251]
-reserved 17-18 IESG
-searchResRef 19 IESG [RFC2251]
-reserved 20-22 IESG
-extendedReq 23 IESG [RFC2251]
-extendedResp 24 IESG [RFC2251]
-
-B.6. resultCode values
-
-Name Code Owner Reference
---------------------------- ---- ----- ---------
-success 0 IESG [RFC2251]
-operationsError 1 IESG [RFC2251]
-protocolError 2 IESG [RFC2251]
-timeLimitExceeded 3 IESG [RFC2251]
-sizeLimitExceeded 4 IESG [RFC2251]
-compareFalse 5 IESG [RFC2251]
-compareTrue 6 IESG [RFC2251]
-authMethodNotSupported 7 IESG [RFC2251]
-
-
-
-Zeilenga Best Current Practice [Page 20]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-strongAuthRequired 8 IESG [RFC2251]
-reserved (partialResults) 9 IESG [RFC2251]
-referral 10 IESG [RFC2251]
-adminLimitExceeded 11 IESG [RFC2251]
-unavailableCriticalExtension 12 IESG [RFC2251]
-confidentialityRequired 13 IESG [RFC2251]
-saslBindInProgress 14 IESG [RFC2251]
-noSuchAttribute 16 IESG [RFC2251]
-undefinedAttributeType 17 IESG [RFC2251]
-inappropriateMatching 18 IESG [RFC2251]
-constraintViolation 19 IESG [RFC2251]
-attributeOrValueExists 20 IESG [RFC2251]
-invalidAttributeSyntax 21 IESG [RFC2251]
-noSuchObject 32 IESG [RFC2251]
-aliasProblem 33 IESG [RFC2251]
-invalidDNSyntax 34 IESG [RFC2251]
-reserved (isLeaf) 35 IESG [RFC2251]
-aliasDereferencingProblem 36 IESG [RFC2251]
-reserved 37-47 IESG
-inappropriateAuthentication 48 IESG [RFC2251]
-invalidCredentials 49 IESG [RFC2251]
-insufficientAccessRights 50 IESG [RFC2251]
-busy 51 IESG [RFC2251]
-unavailable 52 IESG [RFC2251]
-unwillingToPerform 53 IESG [RFC2251]
-loopDetect 54 IESG [RFC2251]
-reserved 55-63 IESG
-namingViolation 64 IESG [RFC2251]
-objectClassViolation 65 IESG [RFC2251]
-notAllowedOnNonLeaf 66 IESG [RFC2251]
-notAllowedOnRDN 67 IESG [RFC2251]
-entryAlreadyExists 68 IESG [RFC2251]
-objectClassModsProhibited 69 IESG [RFC2251]
-reserved (resultsTooLarge) 70 IESG [RFC2251]
-reserved 71-79 IESG
-other 80 IESG [RFC2251]
-reserved (APIs) 81-90 IESG [RFC2251]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 21]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-B.7. Bind Authentication Method
-
-Method Value Owner Usage Reference
------- ----- ----- ----------- -----------------
-simple 0 IESG LIMITED USE [RFC2251,RFC2829]
-krbv42LDAP 1 IESG OBSOLETE* [RFC1777]
-krbv42DSA 2 IESG OBSOLETE* [RFC1777]
-sasl 3 IESG COMMON [RFC2251,RFC2829]
-
-* These LDAPv2-only mechanisms were deprecated in favor of the
-LDAPv3 SASL authentication method, specifically the GSSAPI mechanism.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 22]
-\f
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 23]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 3674 OpenLDAP Foundation
-Category: Standards Track December 2003
-
-
- Feature Discovery in Lightweight Directory Access Protocol (LDAP)
-
-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 (2003). All Rights Reserved.
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an extensible
- protocol with numerous elective features. This document introduces a
- general mechanism for discovery of elective features and extensions
- which cannot be discovered using existing mechanisms.
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
- extensible protocol with numerous elective features. LDAP provides
- mechanisms for a client to discover supported protocol versions,
- controls, extended operations, Simple Authentication and Security
- Layer (SASL) mechanisms, and subschema information. However, these
- mechanisms are not designed to support general feature discovery.
-
- This document describes a simple, general-purpose mechanism which
- clients may use to discover the set of elective features supported by
- a server. For example, this mechanism could be used by a client to
- discover whether or not the server supports requests for all
- operational attributes, e.g., "+" [RFC3673]. As another example,
- this mechanism could be used to discover absolute true, e.g., "(&)"
- and false, e.g., "(|)", search filters [T-F] support.
-
- This document extends the LDAP Protocol Mechanism registry [RFC3383]
- to support registration of values of the supportedFeatures attribute.
- This registry is managed by the Internet Assigned Numbers Authority
- (IANA).
-
-
-
-
-Zeilenga Standards Track [Page 1]
-\f
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
- Schema definitions are provided using LDAP description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped)
- for readability.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-2. Discovery of supported features
-
- Each elective feature whose support may be discovered SHALL be
- identified by an Object Identifier (OID). A server advertises its
- support for a given feature by providing the OID associated with the
- feature as a value of the 'supportedFeatures' attribute held in the
- root DSE. A client may examine the values of this attribute to
- determine if a particular feature is supported by the server. A
- client MUST ignore values it doesn't recognize as they refer to
- elective features it doesn't implement.
-
- Features associated with Standard Track protocol mechanisms MUST be
- registered. Features associated with other protocol mechanisms
- SHOULD be registered. Procedures for registering protocol mechanisms
- are described in BCP 64 [RFC3383]. The word "Feature" should be
- placed in the usage field of the submitted LDAP Protocol Mechanism
- template.
-
- The 'supportedFeatures' attribute type is described as follows:
-
- ( 1.3.6.1.4.1.4203.1.3.5
- NAME 'supportedFeatures'
- DESC 'features supported by the server'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- Servers MUST be capable of recognizing this attribute type by the
- name 'supportedFeatures'. Servers MAY recognize the attribute type
- by other names.
-
-3. Security Considerations
-
- As rogue clients can discover features of a server by other means
- (such as by trial and error), this feature discovery mechanism is not
- believed to introduce any new security risk to LDAP.
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-\f
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
-4. IANA Considerations
-
-4.1. Registration of Features as Protocol Mechanisms
-
- Future specifications detailing LDAP features are to register each
- feature as a LDAP Protocol Mechanism per guidance given in BCP 64
- [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
- template indicates that the value to be registered is associated with
- an LDAP feature.
-
-4.2. Registration of the supportedFeatures descriptor
-
- The IANA has registered the LDAP 'supportedFeatures' descriptor. The
- following registration template is suggested:
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): supportedFeatures
- Object Identifier: 1.3.6.1.4.1.4203.1.3.5
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC 3674
- Author/Change Controller: IESG
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
- assigned private enterprise allocation [PRIVATE] for use in this
- specification.
-
-5. Acknowledgment
-
- This document is based upon input from the IETF LDAPEXT working
- group.
-
-6. Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-Zeilenga Standards Track [Page 3]
-\f
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-7. References
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-7.2. Informative References
-
- [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
- version 3 (LDAPv3): All Operational Attributes", RFC
- 3673, December 2003.
-
- [T-F] Zeilenga, K., "LDAP True/False Filters", Work in
- Progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-Zeilenga Standards Track [Page 4]
-\f
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Harrison
-Request for Comments: 3771 Novell, Inc.
-Updates: 2251 K. Zeilenga
-Category: Standards Track OpenLDAP Foundation
- April 2004
-
-
- The Lightweight Directory Access Protocol (LDAP)
- Intermediate Response Message
-
-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 (2004). All Rights Reserved.
-
-Abstract
-
- This document defines and describes the IntermediateResponse message,
- a general mechanism for defining single-request/multiple-response
- operations in Lightweight Directory Access Protocol (LDAP). The
- IntermediateResponse message is defined in such a way that the
- protocol behavior of existing LDAP operations is maintained. This
- message is intended to be used in conjunction with the LDAP
- ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations or in conjunction with a control
- when extending existing LDAP operations in a way that requires them
- to return intermediate response information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 1]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
- is an extensible protocol. Extended operations ([RFC2251] Section
- 4.12) are defined to allow for the addition of operations to LDAP,
- without requiring revisions of the protocol. Similarly, controls
- ([RFC2251] Section 4.1.12) are defined to extend or modify the
- behavior of existing LDAP operations.
-
- LDAP is a client-request/server-response based protocol. With the
- exception of the search operation, the entire response to an
- operation request is returned in a single protocol data unit (i.e.,
- LDAP message). While this single-request/single-response paradigm is
- sufficient for many operations (including all but one of those
- currently defined by [RFC3377]), both intuition and practical
- experience validate the notion that it is insufficient for others.
-
- For example, the LDAP delete operation could be extended via a
- subtree control to mean that an entire subtree is to be deleted. A
- subtree delete operation needs to return continuation references
- based upon subordinate knowledge information contained in the server
- so that the client can complete the operation. Returning references
- as they are found, instead of with the final result, allows the
- client to perform the operation more efficiently because it does not
- have to wait for the final result to get this continuation reference
- information.
-
- Similarly, an engineer might choose to design the subtree delete
- operation as an extended operation of its own rather than using a
- subtree control in conjunction with the delete operation. Once
- again, the same continuation reference information is needed by the
- client to complete the operation, and sending the continuation
- references as they are found would allow the client to perform the
- operation more efficiently.
-
- Operations that are completed in stages or that progress through
- various states as they are completed might want to send intermediate
- responses to the client, thereby informing it of the status of the
- operation. For example, an LDAP implementation might define an
- extended operation to create a new replica of an administrative area
- on a server, and the operation is completed in three stages: (1)
- begin creation of replica, (2) send replica data to server, (3)
- replica creation complete. Intermediate messages might be sent from
- the server to the client at the beginning of each stage with the
- final response for the extended operation being sent after stage (3)
- is complete.
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 2]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
- As LDAP [RFC3377] is currently defined, there is no general LDAP
- message type that can be used to return intermediate results. A
- single, reusable LDAP message for carrying intermediate response
- information is desired to avoid repeated modification of the
- protocol. Although the ExtendedResponse message is defined in LDAP,
- it is defined to be the one and only response message to an
- ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
- notifications ([RFC2251] Section 4.4), and to return intermediate
- responses for the search operation ([RFC3377] Section 4.5.2, also see
- Section 5 below). The adaptation of ExtendedResponse as a general
- intermediate response mechanism would be problematic. In particular,
- existing APIs would likely have to be redesigned. It is believed
- (based upon operational experience) that the addition of a new
- message to carry intermediate result information is easier to
- implement and is less likely to cause interoperability problems with
- existing deployed implementations.
-
- This document defines and describes the LDAP IntermediateResponse
- message. This message is intended to be used in conjunction with
- ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations or in conjunction with a control
- when extending existing LDAP operations in a way that requires them
- to return intermediate response information.
-
- It is intended that the definitions and descriptions of extended
- operations and controls using the IntermediateResponse message will
- define the circumstances in which an IntermediateResponse message can
- be sent by a server and the associated meaning of the
- IntermediateResponse message sent in a particular circumstance.
- Similarly, it is intended that clients will explicitly solicit
- IntermediateResponse messages by issuing operations that specifically
- call for their return.
-
- The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of
- LDAP Intermediate Response messages.
-
-2. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- The term "request control" is used to describe a control that is
- included in an LDAP request message sent from an LDAP client to an
- LDAP server.
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 3]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-3. The IntermediateResponse Message
-
- This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251]
- Section 4.1.1) to include the field:
-
- intermediateResponse IntermediateResponse
-
- where IntermediateResponse is defined as:
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: extended
- operation and request control.
-
- Although the responseName and responseValue are optional in some
- circumstances, IntermediateResponse messages usually have a
- predefined responseName and a responseValue. The value of the
- responseName (if present), the syntax of the responseValue (if
- present) and the semantics associated with a particular
- IntermediateResponse message MUST be specified in documents
- describing the extended operation or request control that uses them.
- Sections 3.1 and 3.2 describe additional requirements for the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages, of one or more kinds, followed by an
- ExtendedResponse message.
-
- An extended operation that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the extended operation or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the extended operation.
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 4]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-3.2. Usage with LDAP Request Controls
-
- Any LDAP operation may be extended by the addition of one or more
- controls ([RFC2251] Section 4.1.12). A control's semantics may
- include the return of zero or more IntermediateResponse messages
- prior to returning the final result code for the operation. One or
- more kinds of IntermediateResponse messages may be sent in response
- to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when:
-
- a) two or more controls using IntermediateResponse messages are
- included in a request for any LDAP operation or
-
- b) one or more controls using IntermediateResponse messages are
- included in a request with an LDAP extended operation that uses
- IntermediateResponse messages.
-
- A request control that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the request control or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the request control.
-
-4. Advertising Support for IntermediateResponse Messages
-
- Because IntermediateResponse messages are associated with extended
- operations or controls and LDAP provides a means for advertising the
- extended operations and controls supported by a server (using the
- supportedExtension ([RFC2252] Section 5.2.3) and supportedControl
- ([RFC2252] Section 5.2.4) attributes of the root DSE), there is no
- need for a separate means of advertising support for intermediate
- response messages.
-
-5. Use of IntermediateResponse and ExtendedResponse with Search
-
- It is noted that ExtendedResponse messages may be sent in response to
- LDAP search operations with controls ([RFC2251] Section 4.5.2). This
- use of ExtendedResponse messages SHOULD be viewed as deprecated, in
- favor of use of the IntermediateResponse messages.
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 5]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-6. Security Considerations
-
- This document describes an enhancement to LDAP. All security
- considerations of [RFC3377] apply to this document; however, it does
- not introduce any new security considerations to LDAP.
-
- Security considerations specific to each extension using this
- protocol mechanism shall be discussed in the technical specification
- detailing the extension.
-
-7. IANA Considerations
-
- Registration of the following value has been completed [RFC3383].
-
-7.1. LDAP Message Type
-
- The IANA has registered an LDAP Message Type (25) to identify the
- LDAP IntermediateResponse message as defined in section 3 of this
- document.
-
- The following registration template is suggested:
-
- Subject: Request for LDAP Message Type Registration
- Person & email address to contact for further information:
- Roger Harrison <roger_harrison@novell.com>
- Specification: RFC3771
- Author/Change Controller: IESG
- Comments: Identifies the LDAP IntermediateResponse Message
-
-8. Acknowledgments
-
- The authors would like to acknowledge the members of the IETF LDAP
- Extensions (ldapext) working group mail list who responded to the
- suggestion that a multiple-response paradigm might be useful for LDAP
- extended requests. Special thanks to two individuals: David Wilbur
- who first introduced the idea on the working group list, and Thomas
- Salter, who succinctly summarized the group's discussion.
-
-9. References
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 6]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-9.2. Informative References
-
- [ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation",
- Work in Progress, February 2004.
-
-10. Authors' Addresses
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
-
- Phone: +1 801 861 2642
- EMail: roger_harrison@novell.com
-
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 7]
-\f
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 8]
-\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4510 OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006
+ 2256, 2829, 2830, 3377, 3771
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Technical Specification Road Map
+
+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 (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services that act in
+ accordance with X.500 data and service models. This document
+ provides a road map of the LDAP Technical Specification.
+
+1. The LDAP Technical Specification
+
+ The technical specification detailing version 3 of the Lightweight
+ Directory Access Protocol (LDAP), an Internet Protocol, consists of
+ this document and the following documents:
+
+ LDAP: The Protocol [RFC4511]
+ LDAP: Directory Information Models [RFC4512]
+ LDAP: Authentication Methods and Security Mechanisms [RFC4513]
+ LDAP: String Representation of Distinguished Names [RFC4514]
+ LDAP: String Representation of Search Filters [RFC4515]
+ LDAP: Uniform Resource Locator [RFC4516]
+ LDAP: Syntaxes and Matching Rules [RFC4517]
+ LDAP: Internationalized String Preparation [RFC4518]
+ LDAP: Schema for User Applications [RFC4519]
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ The terms "LDAP" and "LDAPv3" are commonly used to refer informally
+ to the protocol specified by this technical specification. The LDAP
+ suite, as defined here, should be formally identified in other
+ documents by a normative reference to this document.
+
+ LDAP is an extensible protocol. Extensions to LDAP may be specified
+ in other documents. Nomenclature denoting such combinations of
+ LDAP-plus-extensions is not defined by this document but may be
+ defined in some future document(s). Extensions are expected to be
+ truly optional. Considerations for the LDAP extensions described in
+ BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP
+ Technical Specification.
+
+ IANA (Internet Assigned Numbers Authority) considerations for LDAP
+ described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision
+ of the LDAP technical specification.
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. Relationship to X.500
+
+ This technical specification 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 International Telecommunication Union -
+ Telecommunication Standardization (ITU-T) 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.
+ For example, LDAP can be mapped onto any other directory system so
+ long as the X.500 data and service models [X.501][X.511], as used in
+ LDAP, are not violated in the LDAP interface.
+
+ This technical specification explicitly incorporates portions of
+ X.500(93). Later revisions of X.500 do not automatically apply to
+ this technical specification.
+
+3. Relationship to Obsolete Specifications
+
+ This technical specification, as defined in Section 1, obsoletes
+ entirely the previously defined LDAP technical specification defined
+ in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and
+ 3377 itself). The technical specification was significantly
+ reorganized.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
+ [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256.
+ [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and
+ all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions
+ of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and
+ portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256.
+ [RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516]
+ replaces RFC 2255.
+
+ [RFC4518] is new to this revision of the LDAP technical
+ specification.
+
+ Each document of this specification contains appendices summarizing
+ changes to all sections of the specifications they replace. Appendix
+ A.1 of this document details changes made to RFC 3377. Appendix A.2
+ of this document details changes made to Section 3.3 of RFC 2251.
+
+ Additionally, portions of this technical specification update and/or
+ replace a number of other documents not listed above. These
+ relationships are discussed in the documents detailing these portions
+ of this technical specification.
+
+4. Security Considerations
+
+ LDAP security considerations are discussed in each document
+ comprising the technical specification.
+
+5. Acknowledgements
+
+ This document is based largely on RFC 3377 by J. Hodges and R.
+ Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
+ document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
+ Kille, a product of the ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+6. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC
+ 4518, June 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP
+ 118, RFC 4521, June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services", X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models", X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+Appendix A. Changes to Previous Documents
+
+ This appendix outlines changes this document makes relative to the
+ documents it replaces (in whole or in part).
+
+A.1. Changes to RFC 3377
+
+ This document is nearly a complete rewrite of RFC 3377 as much of the
+ material of RFC 3377 is no longer applicable. The changes include
+ redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
+ the technical specification.
+
+A.2. Changes to Section 3.3 of RFC 2251
+
+ The section was modified slightly (the word "document" was replaced
+ with "technical specification") to clarify that it applies to the
+ entire LDAP technical specification.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group J. Sermersheim, Ed.
+Request for Comments: 4511 Novell, Inc.
+Obsoletes: 2251, 2830, 3771 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP): The 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes the protocol elements, along with their
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other LDAP Specifications ..................3
+ 2. Conventions .....................................................3
+ 3. Protocol Model ..................................................4
+ 3.1. Operation and LDAP Message Layer Relationship ..............5
+ 4. Elements of Protocol ............................................5
+ 4.1. Common Elements ............................................5
+ 4.1.1. Message Envelope ....................................6
+ 4.1.2. String Types ........................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name ..8
+ 4.1.4. Attribute Descriptions ..............................8
+ 4.1.5. Attribute Value .....................................8
+ 4.1.6. Attribute Value Assertion ...........................9
+ 4.1.7. Attribute and PartialAttribute ......................9
+ 4.1.8. Matching Rule Identifier ...........................10
+ 4.1.9. Result Message .....................................10
+ 4.1.10. Referral ..........................................12
+
+
+
+Sermersheim Standards Track [Page 1]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ 4.1.11. Controls ..........................................14
+ 4.2. Bind Operation ............................................16
+ 4.2.1. Processing of the Bind Request .....................17
+ 4.2.2. Bind Response ......................................18
+ 4.3. Unbind Operation ..........................................18
+ 4.4. Unsolicited Notification ..................................19
+ 4.4.1. Notice of Disconnection ............................19
+ 4.5. Search Operation ..........................................20
+ 4.5.1. Search Request .....................................20
+ 4.5.2. Search Result ......................................27
+ 4.5.3. Continuation References in the Search Result .......28
+ 4.6. Modify Operation ..........................................31
+ 4.7. Add Operation .............................................33
+ 4.8. Delete Operation ..........................................34
+ 4.9. Modify DN Operation .......................................34
+ 4.10. Compare Operation ........................................36
+ 4.11. Abandon Operation ........................................36
+ 4.12. Extended Operation .......................................37
+ 4.13. IntermediateResponse Message .............................39
+ 4.13.1. Usage with LDAP ExtendedRequest and
+ ExtendedResponse ..................................40
+ 4.13.2. Usage with LDAP Request Controls ..................40
+ 4.14. StartTLS Operation .......................................40
+ 4.14.1. StartTLS Request ..................................40
+ 4.14.2. StartTLS Response .................................41
+ 4.14.3. Removal of the TLS Layer ..........................41
+ 5. Protocol Encoding, Connection, and Transfer ....................42
+ 5.1. Protocol Encoding .........................................42
+ 5.2. Transmission Control Protocol (TCP) .......................43
+ 5.3. Termination of the LDAP session ...........................43
+ 6. Security Considerations ........................................43
+ 7. Acknowledgements ...............................................45
+ 8. Normative References ...........................................46
+ 9. Informative References .........................................48
+ 10. IANA Considerations ...........................................48
+ Appendix A. LDAP Result Codes .....................................49
+ A.1. Non-Error Result Codes ....................................49
+ A.2. Result Codes ..............................................49
+ Appendix B. Complete ASN.1 Definition .............................54
+ Appendix C. Changes ...............................................60
+ C.1. Changes Made to RFC 2251 ..................................60
+ C.2. Changes Made to RFC 2830 ..................................66
+ C.3. Changes Made to RFC 3771 ..................................66
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 2]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+1. Introduction
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. A directory user, which may be a human
+ or other entity, accesses the Directory through a client (or
+ Directory User Agent (DUA)). The client, on behalf of the directory
+ user, interacts with one or more servers (or Directory System Agents
+ (DSA)). Clients interact with servers using a directory access
+ protocol.
+
+ This document details the protocol elements of the Lightweight
+ Directory Access Protocol (LDAP), along with their semantics.
+ Following the description of protocol elements, it describes the way
+ in which the protocol elements are encoded and transferred.
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is an integral part of the LDAP Technical Specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document, together with [RFC4510], [RFC4513], and [RFC4512],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by
+ [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted
+ by this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
+
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
+
+ This document also obsoletes RFC 3771 in entirety.
+
+2. Conventions
+
+ 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 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 3]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to Transport Layer Security (TLS)
+ services used in providing security services, as well as associations
+ established by these services.
+
+ The term "SASL layer" refers to Simply Authentication and Security
+ Layer (SASL) services used in providing security services, as well as
+ associations established by these services.
+
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+3. 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 an
+ operation, the server typically returns a response containing
+ appropriate data to the requesting client.
+
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
+ 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 generally may be
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
+
+
+
+
+
+Sermersheim Standards Track [Page 4]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+ However, there is not a one-to-one mapping between LDAP operations
+ and X.500 Directory Access Protocol (DAP) operations. Server
+ implementations acting as a gateway to X.500 directories may need to
+ make multiple DAP requests to service a single LDAP request.
+
+3.1. Operation and LDAP Message Layer Relationship
+
+ Protocol operations are exchanged at the LDAP message layer. When
+ the transport connection is closed, any uncompleted operations at the
+ LDAP message layer are abandoned (when possible) or are completed
+ without transmission of the response (when abandoning them is not
+ possible). Also, when the transport connection is closed, the client
+ MUST NOT assume that any uncompleted update operations have succeeded
+ or failed.
+
+4. Elements of Protocol
+
+ The protocol is described using Abstract Syntax Notation One
+ ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
+ Rules ([BER]). Section 5 specifies how the protocol elements are
+ encoded and transferred.
+
+ In order to support future extensions to this protocol, extensibility
+ is implied where it is allowed per ASN.1 (i.e., sequence, set,
+ choice, and enumerated types are extensible). In addition, ellipses
+ (...) have been supplied in ASN.1 types that are explicitly
+ extensible as discussed in [RFC4520]. Because of the implied
+ extensibility, clients and servers MUST (unless otherwise specified)
+ ignore trailing SEQUENCE components whose tags they do not recognize.
+
+ Changes to the protocol other than through the extension mechanisms
+ described here require a different version number. A client
+ indicates the version it is using as part of the BindRequest,
+ described in Section 4.2. If a client has not sent a Bind, the
+ server MUST assume the client is using version 3 or later.
+
+ Clients may attempt to determine the protocol versions a server
+ supports by reading the 'supportedLDAPVersion' attribute from the
+ root DSE (DSA-Specific Entry) [RFC4512].
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
+ protocol operations.
+
+
+
+
+Sermersheim Standards Track [Page 5]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+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 {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The ASN.1 type Controls is defined in Section 4.1.11.
+
+ 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 messageID and the controls.
+
+ If the server receives an LDAPMessage 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 SHOULD return the Notice of Disconnection
+
+
+
+Sermersheim Standards Track [Page 6]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ described in Section 4.4.1, with the resultCode set to protocolError,
+ and MUST immediately terminate the LDAP session as described in
+ Section 5.3.
+
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ further communication (including providing notice) would be
+ pernicious. Otherwise, server implementations MUST return an
+ appropriate response to the request, with the resultCode set to
+ protocolError.
+
+4.1.1.1. MessageID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The messageID of a request MUST have a non-zero value different from
+ the messageID of any other request in progress in the same LDAP
+ session. The zero value is reserved for the unsolicited notification
+ message.
+
+ Typical clients increment a counter for each request.
+
+ A client MUST NOT send a request with the same messageID as an
+ earlier request in the same LDAP session unless it can be determined
+ that the server is no longer servicing the earlier request (e.g.,
+ after the final response is received, or a subsequent Bind
+ completes). Otherwise, the behavior is undefined. For this purpose,
+ note that Abandon and successfully abandoned operations do not send
+ responses.
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded
+ following the UTF-8 [RFC3629] algorithm. Note that Unicode
+ characters U+0000 through U+007F are the same as ASCII 0 through 127,
+ respectively, and have the same single octet UTF-8 encoding. Other
+ Unicode characters have a multiple octet UTF-8 encoding.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ 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. Although an LDAPOID is
+
+
+
+
+Sermersheim Standards Track [Page 7]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ encoded as an OCTET STRING, values are limited to the definition of
+ <numericoid> given in Section 1.4 of [RFC4512].
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+ -- [RFC4512]
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN is defined to be the representation of a Distinguished Name
+ (DN) after encoding according to the specification in [RFC4514].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to <distinguishedName> [RFC4514]
+
+ A RelativeLDAPDN is defined to be the representation of a Relative
+ Distinguished Name (RDN) after encoding according to the
+ specification in [RFC4514].
+
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [RFC4514]
+
+4.1.4. Attribute Descriptions
+
+ The definition and encoding rules for attribute descriptions are
+ defined in Section 2.5 of [RFC4512]. Briefly, an attribute
+ description is an attribute type and zero or more options.
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [RFC4512]
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value. The attribute value is encoded according to
+ the LDAP-specific encoding definition of its corresponding syntax.
+ The LDAP-specific encoding definitions for different syntaxes and
+ attribute types may be found in other documents and in particular
+ [RFC4517].
+
+ AttributeValue ::= OCTET STRING
+
+
+
+
+
+
+Sermersheim Standards Track [Page 8]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Note that there is no defined limit on the size of this encoding;
+ thus, protocol values may include multi-megabyte attribute values
+ (e.g., photographs).
+
+ Attribute values may be defined that have arbitrary and non-printable
+ syntax. Implementations MUST NOT display or attempt to decode an
+ attribute value if its syntax is not known. The implementation may
+ attempt to discover the subschema of the source entry and to retrieve
+ the descriptions of 'attributeTypes' from it [RFC4512].
+
+ Clients MUST only send attribute values in a request that are valid
+ according to the syntax defined for the attributes.
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion (AVA) type definition is similar to the
+ one in the X.500 Directory standards. It contains an attribute
+ description and a matching rule ([RFC4512], Section 4.1.3) assertion
+ value suitable for that type. Elements of this type are typically
+ used to assert that the value in assertionValue matches a value of an
+ attribute.
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ The syntax of the AssertionValue depends on the context of the LDAP
+ operation being performed. For example, the syntax of the EQUALITY
+ matching rule for an attribute is used when performing a Compare
+ operation. Often this is the same syntax used for values of the
+ attribute type, but in some cases the assertion syntax differs from
+ the value syntax. See objectIdentiferFirstComponentMatch in
+ [RFC4517] for an example.
+
+4.1.7. Attribute and PartialAttribute
+
+ Attributes and partial attributes consist of an attribute description
+ and attribute values. A PartialAttribute allows zero values, while
+ Attribute requires at least one value.
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+
+
+
+
+
+Sermersheim Standards Track [Page 9]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ No two of the attribute values may be equivalent as described by
+ Section 2.2 of [RFC4512]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching
+ rule is identified in the protocol by the printable representation of
+ either its <numericoid> or one of its short name descriptors
+ [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
+
+ MatchingRuleId ::= LDAPString
+
+4.1.9. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. To various
+ requests, servers will return responses containing the elements found
+ in LDAPResult to indicate the final status of the protocol operation
+ request.
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+
+
+
+Sermersheim Standards Track [Page 10]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ The resultCode enumeration is extensible as defined in Section 3.8 of
+ [RFC4520]. The meanings of the listed result codes are given in
+ Appendix A. If a server detects multiple errors for an operation,
+ only one result code is returned. The server should return the
+ result code that best indicates the nature of the error encountered.
+ Servers may return substituted result codes to prevent unauthorized
+ disclosures.
+
+ The diagnosticMessage field of this construct may, at the server's
+ option, be used to return a string containing a textual, human-
+ readable diagnostic message (terminal control and page formatting
+ characters should be avoided). As this diagnostic message is not
+ standardized, implementations MUST NOT rely on the values returned.
+ Diagnostic messages typically supplement the resultCode with
+ additional information. If the server chooses not to return a
+ textual diagnostic, the diagnosticMessage field MUST be empty.
+
+
+
+
+
+Sermersheim Standards Track [Page 11]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax, and
+ aliasDereferencingProblem), the matchedDN field is set (subject to
+ access controls) to the name of the last entry (object or alias) used
+ in finding the target (or base) object. This will be a truncated
+ form of the provided name or, if an alias was dereferenced while
+ attempting to locate the entry, of the resulting name. Otherwise,
+ the matchedDN field is empty.
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the server
+ has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode is
+ set to referral, and it is absent with all other result codes. It
+ contains one or more references to one or more servers or services
+ that may be accessed via LDAP or other protocols. Referrals can be
+ returned in response to any operation request (except Unbind and
+ Abandon, which do not have responses). At least one URI MUST be
+ present in the Referral.
+
+ During a Search operation, after the baseObject is located, and
+ entries are being evaluated, the referral is not returned. Instead,
+ continuation references, described in Section 4.5.3, are returned
+ when other servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ If the client wishes to progress the operation, it contacts one of
+ the supported services found in the referral. If multiple URIs are
+ present, the client assumes that any supported URI may be used to
+ progress the operation.
+
+ Clients that follow referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server
+ for the same request with the same parameters. Some clients use a
+
+
+
+Sermersheim Standards Track [Page 12]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ counter that is incremented each time referral handling occurs for an
+ operation, and these kinds of clients MUST be able to handle at least
+ ten nested referrals while progressing the operation.
+
+ A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+ v6) [RFC793][RFC791] is written as an LDAP URL according to
+ [RFC4516].
+
+ Referral values that are LDAP URLs follow these rules:
+
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
+ present, with the new target object name.
+
+ - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
+
+ - If the <dn> part is present, the client uses this name in its next
+ request to progress the operation, and if it is not present the
+ client uses the same name as in the original request.
+
+ - Some servers (e.g., participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a Search
+ operation.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - For Search, it is RECOMMENDED that the <scope> part be present to
+ avoid ambiguity.
+
+ - If the <scope> part is missing, the scope of the original Search is
+ used by the client to progress the operation.
+
+ - Other aspects of the new request may be the same as or different
+ from the request that generated the referral.
+
+ Other kinds of URIs may be returned. The syntax and semantics of
+ such URIs is left to future specifications. Clients may ignore URIs
+ that they do not support.
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g., spaces) and MUST be escaped using the % method
+ in [RFC3986].
+
+
+
+
+
+
+Sermersheim Standards Track [Page 13]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+4.1.11. Controls
+
+ Controls provide a mechanism whereby the semantics and arguments of
+ existing LDAP operations may be extended. One or more controls may
+ be attached to a single LDAP message. A control only affects the
+ semantics of the message it is attached to.
+
+ Controls sent by clients are termed 'request controls', and those
+ sent by servers are termed 'response controls'.
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field is the dotted-decimal representation of an
+ OBJECT IDENTIFIER that uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
+
+ The criticality field only has meaning in controls attached to
+ request messages (except UnbindRequest). For controls attached to
+ response messages and the UnbindRequest, the criticality field SHOULD
+ be FALSE, and MUST be ignored by the receiving protocol peer. A
+ value of TRUE indicates that it is unacceptable to perform the
+ operation without applying the semantics of the control.
+ Specifically, the criticality field is applied as follows:
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and if the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, it MUST return with the
+ resultCode set to unavailableCriticalExtension.
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and if the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+
+
+Sermersheim Standards Track [Page 14]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The controlValue may contain information associated with the
+ controlType. Its format is defined by the specification of the
+ control. Implementations MUST be prepared to handle arbitrary
+ contents of the controlValue octet string, including zero bytes. It
+ is absent only if there is no value information that is associated
+ with a control of its type. When a controlValue is defined in terms
+ of ASN.1, and BER-encoded according to Section 5.1, it also follows
+ the extensibility rules in Section 4.
+
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
+ [RFC4512]).
+
+ Controls SHOULD NOT be combined unless the semantics of the
+ combination has been specified. The semantics of control
+ combinations, if specified, are generally found in the control
+ specification most recently published. When a combination of
+ controls is encountered whose semantics are invalid, not specified
+ (or not known), the message is considered not well-formed; thus, the
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored
+ by the server, the message is considered not well-formed, and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. Documents detailing control extensions
+ are to provide for each control:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - direction as to what value the sender should provide for the
+ criticality field (note: the semantics of the criticality field are
+ defined above should not be altered by the control's
+ specification),
+
+ - whether the controlValue field is present, and if so, the format of
+ its contents,
+
+ - the semantics of the control, and
+
+ - optionally, semantics regarding the combination of the control with
+ other controls.
+
+
+
+
+Sermersheim Standards Track [Page 15]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+4.2. Bind Operation
+
+ The function of the Bind operation is to allow authentication
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Operational, authentication, and security-related semantics of this
+ operation are given in [RFC4513].
+
+ The Bind request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Fields of the BindRequest are:
+
+ - version: A version number indicating the version of the protocol to
+ be used at the LDAP message layer. This document describes version
+ 3 of the protocol. There is no version negotiation. The client
+ sets this field to the version it desires. If the server does not
+ support the specified version, it MUST respond with a BindResponse
+ where the resultCode is set to protocolError.
+
+ - name: If not empty, 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 ([RFC4513],
+ Section 5.1) or when using SASL [RFC4422] authentication
+ ([RFC4513], Section 5.2). Where the server attempts to locate the
+ named object, it SHALL NOT perform alias dereferencing.
+
+ - authentication: Information used in authentication. This type is
+ extensible as defined in Section 3.7 of [RFC4520]. Servers that do
+ not support a choice supplied by a client return a BindResponse
+ with the resultCode set to authMethodNotSupported.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 16]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) transferred to the server using the
+ simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
+ passwords as "query" strings by applying the SASLprep [RFC4013]
+ profile of the stringprep [RFC3454] algorithm. Passwords
+ consisting of other data (such as random octets) MUST NOT be
+ altered. The determination of whether a password is textual is a
+ local client matter.
+
+4.2.1. Processing of the Bind Request
+
+ Before processing a BindRequest, all uncompleted operations MUST
+ either complete or be abandoned. The server may either wait for the
+ uncompleted operations to complete, or abandon them. The server then
+ proceeds to authenticate the client in either a single-step or
+ multi-step Bind process. Each step requires the server to return a
+ BindResponse to indicate the status of authentication.
+
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
+ If the client did not bind before sending a request and receives an
+ operationsError to that request, it may then send a BindRequest. If
+ this also fails or the client chooses not to bind on the existing
+ LDAP session, it may terminate the LDAP session, re-establish it, and
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind requests to change the authentication
+ and/or security associations or to complete a multi-stage Bind
+ process. Authentication from earlier binds is subsequently ignored.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times ([RFC4513], Section
+ 5.2). Clients MUST NOT invoke operations between two Bind requests
+ made as part of a multi-stage Bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 17]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with the
+ resultCode set to authMethodNotSupported. This will allow the client
+ to abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+4.2.2. Bind Response
+
+ The Bind response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of the
+ status of the client's request for authentication.
+
+ A successful Bind operation is indicated by a BindResponse with a
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For BindResponse, the protocolError result
+ code may be used to indicate that the version number supplied by the
+ client is unsupported.
+
+ If the client receives a BindResponse where the resultCode is set to
+ protocolError, it is to assume that the server does not support this
+ version of LDAP. While the client may be able proceed with another
+ version of this protocol (which may or may not require closing and
+ re-establishing the transport connection), how to proceed with
+ another version of this protocol is beyond the scope of this
+ document. Clients that are unable or unwilling to proceed SHOULD
+ terminate the LDAP session.
+
+ The serverSaslCreds field is used as part of a SASL-defined bind
+ mechanism to allow the client to authenticate the server to which it
+ is communicating, or to perform "challenge-response" authentication.
+ If the client bound with the simple choice, or the SASL mechanism
+ does not require the server to return information to the client, then
+ this field SHALL NOT be included in the BindResponse.
+
+4.3. Unbind Operation
+
+ The function of the Unbind operation is to terminate an LDAP session.
+ The Unbind operation is not the antithesis of the Bind operation as
+ the name implies. The naming of these operations are historical.
+ The Unbind operation should be thought of as the "quit" operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 18]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The Unbind operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The client, upon transmission of the UnbindRequest, and the server,
+ upon receipt of the UnbindRequest, are to gracefully terminate the
+ LDAP session as described in Section 5.3. Uncompleted operations are
+ handled as specified in Section 3.1.
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client that is not in response to any LDAPMessage received by the
+ server. It is used to signal an extraordinary condition in the
+ server or in the LDAP session between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is zero and protocolOp is set to the extendedResp
+ choice using the ExtendedResponse type (See Section 4.12). The
+ responseName field of the ExtendedResponse always contains an LDAPOID
+ that is unique for this notification.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document. The specification of an unsolicited notification
+ consists of:
+
+ - the OBJECT IDENTIFIER assigned to the notification (to be specified
+ in the responseName,
+
+ - the format of the contents of the responseValue (if any),
+
+ - the circumstances which will cause the notification to be sent, and
+
+ - the semantics of the message.
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to terminate the LDAP session on its own
+ initiative. This notification is intended to assist clients in
+ distinguishing between an exceptional server condition and a
+ transient network failure. Note that this notification is not a
+ response to an Unbind requested by the client. Uncompleted
+ operations are handled as specified in Section 3.1.
+
+
+
+
+
+Sermersheim Standards Track [Page 19]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
+ disconnection. When the strongerAuthRequired resultCode is returned
+ with this message, it indicates that the server has detected that an
+ established security association between the client and server has
+ unexpectedly failed or been compromised.
+
+ Upon transmission of the Notice of Disconnection, the server
+ gracefully terminates the LDAP session as described in Section 5.3.
+
+4.5. Search Operation
+
+ The Search operation is used to request a server to return, subject
+ to access controls and other restrictions, a set of entries matching
+ a complex search criterion. This can be used to read attributes from
+ a single entry, from entries immediately subordinate to a particular
+ entry, or from a whole subtree of entries.
+
+4.5.1. Search Request
+
+ 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),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.8
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+
+
+
+Sermersheim Standards Track [Page 20]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a singleLevel Search operation with a filter
+ checking for the presence of the 'objectClass' attribute, and that an
+ X.500 "read"-like operation can be emulated by a baseObject Search
+ operation with the same filter. A server that provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does, it must provide the same
+ semantics as the X.500 Search operation.
+
+4.5.1.1. SearchRequest.baseObject
+
+ The name of the base object entry (or possibly the root) relative to
+ which the Search is to be performed.
+
+4.5.1.2. SearchRequest.scope
+
+ Specifies the scope of the Search to be performed. The semantics (as
+ described in [X.511]) of the defined values of this field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ singleLevel: The scope is constrained to the immediate
+ subordinates of the entry named by baseObject.
+
+
+
+
+Sermersheim Standards Track [Page 21]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ wholeSubtree: The scope is constrained to the entry named by
+ baseObject and to all its subordinates.
+
+4.5.1.3. SearchRequest.derefAliases
+
+ An indicator as to whether or not alias entries (as defined in
+ [RFC4512]) are to be dereferenced during stages of the Search
+ operation.
+
+ The act of dereferencing an alias includes recursively dereferencing
+ aliases that refer to aliases.
+
+ Servers MUST detect looping while dereferencing aliases in order to
+ prevent denial-of-service attacks of this nature.
+
+ The semantics of the defined values of this field are:
+
+ neverDerefAliases: Do not dereference aliases in searching or in
+ locating the base object of the Search.
+
+ derefInSearching: While searching subordinates of the base object,
+ dereference any alias within the search scope. Dereferenced
+ objects become the vertices of further search scopes where the
+ Search operation is also applied. If the search scope is
+ wholeSubtree, the Search continues in the subtree(s) of any
+ dereferenced object. If the search scope is singleLevel, the
+ search is applied to any dereferenced objects and is not applied
+ to their subordinates. Servers SHOULD eliminate duplicate entries
+ that arise due to alias dereferencing while searching.
+
+ derefFindingBaseObj: 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.
+
+4.5.1.4. SearchRequest.sizeLimit
+
+ A size limit that restricts the maximum number of entries to be
+ returned as a result of the Search. A value of zero in this field
+ indicates that no client-requested size limit restrictions are in
+ effect for the Search. Servers may also enforce a maximum number of
+ entries to return.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 22]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+4.5.1.5. SearchRequest.timeLimit
+
+ A time limit that restricts the maximum time (in seconds) allowed for
+ a Search. A value of zero in this field indicates that no client-
+ requested time limit restrictions are in effect for the Search.
+ Servers may also enforce a maximum time limit for the Search.
+
+4.5.1.6. SearchRequest.typesOnly
+
+ An indicator as to whether Search results are to contain both
+ attribute descriptions and values, or just attribute descriptions.
+ Setting this field to TRUE causes only attribute descriptions (and
+ not values) to be returned. Setting this field to FALSE causes both
+ attribute descriptions and values to be returned.
+
+4.5.1.7. SearchRequest.filter
+
+ A filter that defines the conditions that must be fulfilled in order
+ for the Search to match a given entry.
+
+ The 'and', 'or', and 'not' choices can be used to form combinations
+ of filters. At least one filter element MUST be present in an 'and'
+ or 'or' choice. The others match against individual attribute values
+ of entries in the scope of the Search. (Implementor's note: the
+ 'not' filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag were explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic of
+ [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to
+ "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for
+ a particular entry, then the attributes of that entry are returned as
+ part of the Search result (subject to any applicable access control
+ restrictions). If the filter evaluates to FALSE or Undefined, then
+ the entry is ignored for the Search.
+
+ A filter of the "and" choice is TRUE if all the filters in the SET OF
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ Undefined otherwise. A filter of the "or" choice is FALSE if all the
+ filters in the SET OF evaluate to FALSE, TRUE if at least one filter
+ is TRUE, and Undefined otherwise. A filter of the 'not' choice is
+ TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
+ Undefined if it is Undefined.
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry.
+ Examples include:
+
+
+
+
+
+Sermersheim Standards Track [Page 23]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - An attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
+ is not recognized by the server.
+
+ - The attribute type does not define the appropriate matching rule.
+
+ - A MatchingRuleId in the extensibleMatch is not recognized by the
+ server or is not valid for the attribute type.
+
+ - The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+ For example, if a server did not recognize the attribute type
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
+ and (shoeSize<=12) would each evaluate to Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, assertion values are invalid, or the
+ assertion syntax is not supported. More details of filter processing
+ are given in Clause 7.8 of [X.511].
+
+4.5.1.7.1. SearchRequest.filter.equalityMatch
+
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
+
+4.5.1.7.2. SearchRequest.filter.substrings
+
+ There SHALL be at most one 'initial' and at most one 'final' in the
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
+ be the first element of 'substrings'. If 'final' is present, it
+ SHALL be the last element of 'substrings'.
+
+ The matching rule for an AssertionValue in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than to the assertion syntax of the SUBSTR matching rule
+ for the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
+
+
+
+
+Sermersheim Standards Track [Page 24]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual
+
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
+
+4.5.1.7.4. SearchRequest.filter.lessOrEqual
+
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY
+ rule returns TRUE as applied to the attribute or subtype and the
+ asserted value.
+
+4.5.1.7.5. SearchRequest.filter.present
+
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
+
+4.5.1.7.6. SearchRequest.filter.approxMatch
+
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g., spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
+ approximate match. If approximate matching is not supported for the
+ attribute, this filter item should be treated as an equalityMatch.
+
+4.5.1.7.7. SearchRequest.filter.extensibleMatch
+
+ The fields of the extensibleMatch filter item are evaluated as
+ follows:
+
+ - If the matchingRule field is absent, the type field MUST be
+ present, and an equality match is performed for that type.
+
+ - If the type field is absent and the matchingRule is present, the
+ matchValue is compared against all attributes in an entry that
+ support that matchingRule.
+
+ - If the type field is present and the matchingRule is present, the
+ matchValue is compared against the specified attribute type and its
+ subtypes.
+
+
+
+
+
+Sermersheim Standards Track [Page 25]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - If the dnAttributes field is set to TRUE, the match is additionally
+ applied against all the AttributeValueAssertions in an entry's
+ distinguished name, and it evaluates to TRUE if there is at least
+ one attribute or subtype in the distinguished name for which the
+ filter item evaluates to TRUE. The dnAttributes field is present
+ to alleviate the need for multiple versions of generic matching
+ rules (such as word matching), where one applies to entries and
+ another applies to entries and DN attributes as well.
+
+ The matchingRule used for evaluation determines the syntax for the
+ assertion value. Once the matchingRule and attribute(s) have been
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
+
+4.5.1.8. SearchRequest.attributes
+
+ A selection list of the attributes to be returned from each entry
+ that matches the search filter. Attributes that are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ (ABNF) [RFC4234]:
+
+ attributeSelector = attributedescription / selectorspecial
+
+ selectorspecial = noattrs / alluserattrs
+
+ noattrs = %x31.2E.31 ; "1.1"
+
+ alluserattrs = %x2A ; asterisk ("*")
+
+ The <attributedescription> production is defined in Section 2.5 of
+ [RFC4512].
+
+ There are three special cases that may appear in the attributes
+ selection list:
+
+ 1. An empty list with no attributes requests the return of all
+ user attributes.
+
+ 2. A list containing "*" (with zero or more attribute
+ descriptions) requests the return of all user attributes in
+ addition to other listed (operational) attributes.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 26]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ 3. A list containing only the OID "1.1" indicates that no
+ attributes are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is
+ ignored. This OID was chosen because it does not (and can not)
+ correspond to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes and/or attribute values of the entry may
+ not be included in Search results due to access controls or other
+ restrictions. Furthermore, servers will not return operational
+ attributes, such as objectClasses or attributeTypes, unless they are
+ listed by name. Operational attributes are described in [RFC4512].
+
+ Attributes are returned at most once in an entry. If an attribute
+ description is named more than once in the list, the subsequent names
+ are ignored. If an attribute description in the list is not
+ recognized, it is ignored by the server.
+
+4.5.2. Search Result
+
+ The results of the Search operation are returned as zero or more
+ SearchResultEntry and/or SearchResultReference messages, followed by
+ a single SearchResultDone message.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Each SearchResultEntry represents an entry found during the Search.
+ Each SearchResultReference represents an area not yet explored during
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
+ SearchResultEntry responses, the server returns a SearchResultDone
+ response, which contains an indication of success or details any
+ errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ appropriate attributes as specified in the attributes field of the
+ Search Request, subject to access control and other administrative
+ policy. Note that the PartialAttributeList may hold zero elements.
+
+
+
+Sermersheim Standards Track [Page 27]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ This may happen when none of the attributes of an entry were
+ requested or could be returned. Note also that the partialAttribute
+ vals set may hold zero elements. This may happen when typesOnly is
+ requested, access controls prevent the return of values, or other
+ reasons.
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients SHOULD NOT assume that all
+ attributes can be modified, even if this is permitted by access
+ control.
+
+ If the server's schema defines short names [RFC4512] for an attribute
+ type, then the server SHOULD use one of those names in attribute
+ descriptions for that attribute type (in preference to using the
+ <numericoid> [RFC4512] format of the attribute type's object
+ identifier). The server SHOULD NOT use the short name if that name
+ is known by the server to be ambiguous, or if it is otherwise likely
+ to cause interoperability problems.
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable or unwilling to search one or more non-
+ local entries, the server may return one or more
+ SearchResultReference messages, each containing a reference to
+ another set of servers for continuing the operation. A server MUST
+ NOT return any SearchResultReference messages if it has not located
+ the baseObject and thus has not searched any entries. In this case,
+ it would return a SearchResultDone containing either a referral or
+ noSuchObject result code (depending on the server's knowledge of the
+ entry named in the baseObject).
+
+ If a server holds a copy or partial copy of the subordinate naming
+ context (Section 5 of [RFC4512]), it may use the search filter to
+ determine whether or not to return a SearchResultReference response.
+ Otherwise, SearchResultReference responses are always returned when
+ in scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+
+ If the client wishes to progress the Search, it issues a new Search
+ operation for each SearchResultReference that is returned. If
+ multiple URIs are present, the client assumes that any supported URI
+ may be used to progress the operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 28]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Clients that follow search continuation references MUST ensure that
+ they do not loop between servers. They MUST NOT repeatedly contact
+ the same server for the same request with the same parameters. Some
+ clients use a counter that is incremented each time search result
+ reference handling occurs for an operation, and these kinds of
+ clients MUST be able to handle at least ten nested referrals while
+ progressing the operation.
+
+ Note that the Abandon operation described in Section 4.11 applies
+ only to a particular operation sent at the LDAP message layer between
+ a client and server. The client must individually abandon subsequent
+ Search operations it wishes to.
+
+ A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+ v6) [RFC793][RFC791] is written as an LDAP URL according to
+ [RFC4516].
+
+ SearchResultReference values that are LDAP URLs follow these rules:
+
+ - The <dn> part of the LDAP URL MUST be present, with the new target
+ object name. The client uses this name when following the
+ reference.
+
+ - Some servers (e.g., participating in distributed indexing) may
+ provide a different filter in the LDAP URL.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - If the originating search scope was singleLevel, the <scope> part
+ of the LDAP URL will be "base".
+
+ - It is RECOMMENDED that the <scope> part be present to avoid
+ ambiguity. In the absence of a <scope> part, the scope of the
+ original Search request is assumed.
+
+ - Other aspects of the new Search request may be the same as or
+ different from the Search request that generated the
+ SearchResultReference.
+
+ - The name of an unexplored subtree in a SearchResultReference need
+ not be subordinate to the base object.
+
+ Other kinds of URIs may be returned. The syntax and semantics of
+ such URIs is left to future specifications. Clients may ignore URIs
+ that they do not support.
+
+
+
+Sermersheim Standards Track [Page 29]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ UTF-8-encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g., spaces) and MUST be escaped using the % method
+ in [RFC3986].
+
+4.5.3.1. Examples
+
+ For example, suppose the contacted server (hosta) holds the entry
+ <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
+ knows that both LDAP servers (hostb) and (hostc) hold
+ <OU=People,DC=Example,DC=NET> (one is the master and the other server
+ a shadow), and that LDAP-capable server (hostd) holds the subtree
+ <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
+ <DC=Example,DC=NET> is requested to the contacted server, it may
+ return the following:
+
+ SearchResultEntry for DC=Example,DC=NET
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??sub
+ ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the
+ server (hostb) and issued the Search request for the subtree
+ <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+ SearchResultEntry for OU=People,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+ requested to the contacted server, it may return the following:
+
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+ SearchResultDone (success)
+
+
+
+Sermersheim Standards Track [Page 30]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ If the contacted server does not hold the base object for the Search,
+ but has knowledge of its possible location, then it may return a
+ referral to the client. In this case, if the client requests a
+ subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+ SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/DC=Example,DC=ORG??sub }
+
+4.6. Modify Operation
+
+ The Modify operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ Fields of the Modify Request are:
+
+ - object: The value of this field contains the name of the entry to
+ be modified. The server SHALL NOT perform any alias dereferencing
+ in determining the object to be modified.
+
+ - changes: A list of modifications to be performed on the entry. The
+ entire list of modifications MUST be performed in the order they
+ are listed as a single atomic operation. While individual
+ modifications may violate certain aspects of the directory schema
+ (such as the object class definition and Directory Information Tree
+ (DIT) content rule), the resulting entry after the entire list of
+ modifications is performed MUST conform to the requirements of the
+ directory model and controlling schema [RFC4512].
+
+ - operation: Used to specify the type of modification being
+ performed. Each operation type acts on the following
+ modification. The values of this field have the following
+ semantics, respectively:
+
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary.
+
+
+
+
+Sermersheim Standards Track [Page 31]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ delete: delete values listed from the modification attribute.
+ If no values are listed, or if all current values of the
+ attribute are listed, the entire attribute is removed.
+
+ replace: replace all existing values of the modification
+ attribute with the new values listed, creating the attribute
+ if it did not already exist. A replace with no value will
+ delete the entire attribute if it exists, and it is ignored
+ if the attribute does not exist.
+
+ - modification: A PartialAttribute (which may have an empty SET
+ of vals) used to hold the attribute type or attribute type and
+ values being modified.
+
+ Upon receipt of a Modify Request, the server attempts to perform the
+ necessary modifications to the DIT and returns the result in a Modify
+ Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. 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 DIT 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. Whether or not the modification was applied cannot be
+ determined by the client if the Modify Response was not received
+ (e.g., the LDAP session was terminated or the Modify operation was
+ abandoned).
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. The Modify operation cannot
+ be used to remove from an entry any of its distinguished values,
+ i.e., those values which form the entry's relative distinguished
+ name. An attempt to do so will result in the server returning the
+ notAllowedOnRDN result code. The Modify DN operation described in
+ Section 4.9 is used to rename an entry.
+
+ For attribute types that specify no equality matching, the rules in
+ Section 2.5.1 of [RFC4512] are followed.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the changes in an LDAP ModifyRequest onto the
+ changes of a DAP ModifyEntry operation, and different implementations
+
+
+
+
+Sermersheim Standards Track [Page 32]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ of LDAP-DAP gateways may use different means of representing the
+ change. If successful, the final effect of the operations on the
+ entry MUST be identical.
+
+4.7. 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,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ Fields of the Add Request are:
+
+ - entry: the name of the entry to be added. The server SHALL NOT
+ dereference any aliases in locating the entry to be added.
+
+ - attributes: the list of attributes that, along with those from the
+ RDN, make up the content of the entry being added. Clients MAY or
+ MAY NOT include the RDN attribute(s) in this list. Clients MUST
+ NOT supply NO-USER-MODIFICATION attributes such as the
+ createTimestamp or creatorsName attributes, since the server
+ maintains these automatically.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types that
+ specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+ are followed (this applies to the naming attribute in addition to any
+ multi-valued attributes being added).
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The immediate superior (parent) of an
+ object or alias entry to be added MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ Upon receipt of an Add Request, a server will attempt to add the
+ requested entry. The result of the Add attempt will be returned to
+ the client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+
+
+
+
+Sermersheim Standards Track [Page 33]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ A response of success indicates that the new entry has been added to
+ the Directory.
+
+4.8. 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 of the name of the entry to be deleted.
+ The server SHALL NOT dereference aliases while resolving the name of
+ the target entry to be removed.
+
+ Only leaf entries (those with no subordinate entries) can be deleted
+ with this operation.
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested and return the result in the Delete
+ Response defined as follows:
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+4.9. Modify DN Operation
+
+ The Modify DN operation allows a client to change the Relative
+ Distinguished Name (RDN) of an entry in the Directory and/or to move
+ a subtree of entries to a new location in the Directory. The Modify
+ DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Fields of the Modify DN Request are:
+
+ - entry: the name of the entry to be changed. This entry may or may
+ not have subordinate entries.
+
+ - newrdn: the new RDN of the entry. The value of the old RDN is
+ supplied when moving the entry to a new superior without changing
+ its RDN. Attribute values of the new RDN not matching any
+ attribute value of the entry are added to the entry, and an
+ appropriate error is returned if this fails.
+
+
+
+
+
+Sermersheim Standards Track [Page 34]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - deleteoldrdn: a boolean field that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the name of an existing object
+ entry that becomes the immediate superior (parent) of the
+ existing entry.
+
+ The server SHALL NOT dereference any aliases in locating the objects
+ named in entry or newSuperior.
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change and return the result in the Modify DN Response,
+ defined as follows:
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ For example, if the entry named in the entry field was <cn=John
+ Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+ newSuperior field was absent, then this operation would attempt to
+ rename the entry as <cn=John Cougar Smith,c=US>. If there was
+ already an entry with that name, the operation would fail with the
+ entryAlreadyExists result code.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types that
+ specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+ are followed (this pertains to newrdn and deleteoldrdn).
+
+ The object named in newSuperior MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ If the deleteoldrdn field is TRUE, the attribute values forming the
+ old RDN (but not the new RDN) are deleted from the entry. If the
+ deleteoldrdn field is FALSE, the attribute values forming the old RDN
+ will be retained as non-distinguished attribute values of the entry.
+
+ Note that X.500 restricts the ModifyDN operation to affect only
+ entries that are contained within a single server. If the LDAP
+ server is mapped onto DAP, then this restriction will apply, and the
+ affectsMultipleDSAs result code will be returned if this error
+ occurred. In general, clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers or
+ between naming contexts.
+
+
+
+
+Sermersheim Standards Track [Page 35]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+4.10. Compare Operation
+
+ The Compare operation allows a client to compare an assertion value
+ with the values of a particular attribute in a particular entry in
+ the Directory. The Compare Request is defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Fields of the Compare Request are:
+
+ - entry: the name of the entry to be compared. The server SHALL NOT
+ dereference any aliases in locating the entry to be compared.
+
+ - ava: holds the attribute value assertion to be compared.
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison and return the result in the Compare
+ Response, defined as follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ The resultCode is set to compareTrue, compareFalse, or an appropriate
+ error. compareTrue indicates that the assertion value in the ava
+ field matches a value of the attribute or subtype according to the
+ attribute's EQUALITY matching rule. compareFalse indicates that the
+ assertion value in the ava field and the values of the attribute or
+ subtype did not match. Other result codes indicate either that the
+ result of the comparison was Undefined (Section 4.5.1.7), or that
+ some error occurred.
+
+ Note that some directory systems may establish access controls that
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not interrogated by other means.
+
+4.11. Abandon Operation
+
+ The function of the Abandon operation is to allow a client to request
+ that the server abandon an uncompleted operation. The Abandon
+ Request is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID is that of an operation that was requested earlier at
+ this LDAP message layer. The Abandon request itself has its own
+ MessageID. This is distinct from the MessageID of the earlier
+ operation being abandoned.
+
+
+
+Sermersheim Standards Track [Page 36]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ There is no response defined in the Abandon operation. Upon receipt
+ of an AbandonRequest, the server MAY abandon the operation identified
+ by the MessageID. Since the client cannot tell the difference
+ between a successfully abandoned operation and an uncompleted
+ operation, the application of the Abandon operation is limited to
+ uses where the client does not require an indication of its outcome.
+
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+ In the event that a server receives an Abandon Request on a Search
+ operation in the midst of transmitting responses to the Search, that
+ server MUST cease transmitting entry responses to the abandoned
+ request immediately, and it MUST NOT send the SearchResultDone. Of
+ course, the server MUST ensure that only properly encoded LDAPMessage
+ PDUs are transmitted.
+
+ The ability to abandon other (particularly update) operations is at
+ the discretion of the server.
+
+ Clients should not send Abandon requests for the same operation
+ multiple times, and they MUST also be prepared to receive results
+ from operations they have abandoned (since these might have been in
+ transit when the Abandon was requested or might not be able to be
+ abandoned).
+
+ Servers MUST discard Abandon requests for messageIDs they do not
+ recognize, for operations that cannot be abandoned, and for
+ operations that have already been abandoned.
+
+4.12. Extended Operation
+
+ The Extended operation allows additional operations to be defined for
+ services not already available in the protocol; for example, to Add
+ operations to install transport layer security (see Section 4.14).
+
+ The Extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations.
+
+ Each Extended operation consists of an Extended request and an
+ Extended response.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+
+
+
+
+
+Sermersheim Standards Track [Page 37]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The requestName is a dotted-decimal representation of the unique
+ OBJECT IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing an
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ The responseName field, when present, contains an LDAPOID that is
+ unique for this extended operation or response. This field is
+ optional (even when the extension specification defines an LDAPOID
+ for use in this field). The field will be absent whenever the server
+ is unable or unwilling to determine the appropriate LDAPOID to
+ return, for instance, when the requestName cannot be parsed or its
+ value is not recognized.
+
+ Where the requestName is not recognized, the server returns
+ protocolError. (The server may return protocolError in other cases.)
+
+ The requestValue and responseValue fields contain information
+ associated with the operation. The format of these fields is defined
+ by the specification of the Extended operation. Implementations MUST
+ be prepared to handle arbitrary contents of these fields, including
+ zero bytes. Values that are defined in terms of ASN.1 and BER-
+ encoded according to Section 5.1 also follow the extensibility rules
+ in Section 4.
+
+ Servers list the requestName of Extended Requests they recognize in
+ the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+ [RFC4512]).
+
+ Extended operations may be specified in other documents. The
+ specification of an Extended operation consists of:
+
+ - the OBJECT IDENTIFIER assigned to the requestName,
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+ that the same OBJECT IDENTIFIER may be used for both the
+ requestName and responseName),
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 38]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - the format of the contents of the requestValue and responseValue
+ (if any), and
+
+ - the semantics of the operation.
+
+4.13. IntermediateResponse Message
+
+ While the Search operation provides a mechanism to return multiple
+ response messages for a single Search request, other operations, by
+ nature, do not provide for multiple response messages.
+
+ The IntermediateResponse message provides a general mechanism for
+ defining single-request/multiple-response operations in LDAP. This
+ message is intended to be used in conjunction with the Extended
+ operation to define new single-request/multiple-response operations
+ or in conjunction with a control when extending existing LDAP
+ operations in a way that requires them to return Intermediate
+ response information.
+
+ It is intended that the definitions and descriptions of Extended
+ operations and controls that make use of the IntermediateResponse
+ message will define the circumstances when an IntermediateResponse
+ message can be sent by a server and the associated meaning of an
+ IntermediateResponse message sent in a particular circumstance.
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ IntermediateResponse messages SHALL NOT be returned to the client
+ unless the client issues a request that specifically solicits their
+ return. This document defines two forms of solicitation: Extended
+ operation and request control. IntermediateResponse messages are
+ specified in documents describing the manner in which they are
+ solicited (i.e., in the Extended operation or request control
+ specification that uses them). These specifications include:
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+ - the format of the contents of the responseValue (if any), and
+
+ - the semantics associated with the IntermediateResponse message.
+
+ Extensions that allow the return of multiple types of
+ IntermediateResponse messages SHALL identify those types using unique
+ responseName values (note that one of these may specify no value).
+
+
+
+
+
+Sermersheim Standards Track [Page 39]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Sections 4.13.1 and 4.13.2 describe additional requirements on the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
+
+ A single-request/multiple-response operation may be defined using a
+ single ExtendedRequest message to solicit zero or more
+ IntermediateResponse messages of one or more kinds, followed by an
+ ExtendedResponse message.
+
+4.13.2. Usage with LDAP Request Controls
+
+ A control's semantics may include the return of zero or more
+ IntermediateResponse messages prior to returning the final result
+ code for the operation. One or more kinds of IntermediateResponse
+ messages may be sent in response to a request control.
+
+ All IntermediateResponse messages associated with request controls
+ SHALL include a responseName. This requirement ensures that the
+ client can correctly identify the source of IntermediateResponse
+ messages when:
+
+ - two or more controls using IntermediateResponse messages are
+ included in a request for any LDAP operation or
+
+ - one or more controls using IntermediateResponse messages are
+ included in a request with an LDAP Extended operation that uses
+ IntermediateResponse messages.
+
+4.14. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation's purpose is
+ to initiate installation of a TLS layer. The StartTLS operation is
+ defined using the Extended operation mechanism described in Section
+ 4.12.
+
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ request message to the server. The StartTLS request is defined in
+ terms of an ExtendedRequest. The requestName is
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+ absent.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 40]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer
+ following this request until it receives a StartTLS Extended response
+ and, in the case of a successful response, completes TLS
+ negotiations.
+
+ Detected sequencing problems (particularly those detailed in Section
+ 3.1.1 of [RFC4513]) result in the resultCode being set to
+ operationsError.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it returns with the resultCode set to protocolError
+ as described in Section 4.12.
+
+4.14.2. StartTLS Response
+
+ When a StartTLS request is received, servers supporting the operation
+ MUST return a StartTLS response message to the requestor. The
+ responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section
+ 4.12). The responseValue is always absent.
+
+ If the server is willing and able to negotiate TLS, it returns the
+ StartTLS response with the resultCode set to success. Upon client
+ receipt of a successful StartTLS response, protocol peers may
+ commence with TLS negotiation as discussed in Section 3 of [RFC4513].
+
+ If the server is otherwise unwilling or unable to perform this
+ operation, the server is to return an appropriate result code
+ indicating the nature of the problem. For example, if the TLS
+ subsystem is not presently available, the server may indicate this by
+ returning with the resultCode set to unavailable. In cases where a
+ non-success result code is returned, the LDAP session is left without
+ a TLS layer.
+
+4.14.3. Removal of the TLS Layer
+
+ Either the client or server MAY remove the TLS layer and leave the
+ LDAP message layer intact by sending and receiving a TLS closure
+ alert.
+
+ The initiating protocol peer sends the TLS closure alert and MUST
+ wait until it receives a TLS closure alert from the other peer before
+ sending further LDAP PDUs.
+
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the LDAP message layer to remain intact. In this
+ case, it MUST immediately transmit a TLS closure alert. Following
+ this, it MAY send and receive LDAP PDUs.
+
+
+
+
+Sermersheim Standards Track [Page 41]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Protocol peers MAY terminate the LDAP session after sending or
+ receiving a TLS closure alert.
+
+5. Protocol Encoding, Connection, and Transfer
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, where the data stream is divided into octets (8-bit
+ units), with each octet and each bit being significant.
+
+ One underlying service, LDAP over TCP, is defined in Section 5.2.
+ This service is generally applicable to applications providing or
+ consuming X.500-based directory services on the Internet. This
+ specification was generally written with the TCP mapping in mind.
+ Specifications detailing other mappings may encounter various
+ obstacles.
+
+ Implementations of LDAP over TCP MUST implement the mapping as
+ described in Section 5.2.
+
+ This table illustrates the relationship among the different layers
+ involved in an exchange between two protocol peers:
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+5.1. Protocol Encoding
+
+ The protocol elements of LDAP SHALL be encoded for exchange using the
+ Basic Encoding Rules [BER] of [ASN.1] with the following
+ restrictions:
+
+ - Only the definite form of length encoding is used.
+
+ - OCTET STRING values are encoded in the primitive form only.
+
+ - If the value of a BOOLEAN type is true, the encoding of the value
+ octet is set to hex "FF".
+
+
+
+
+Sermersheim Standards Track [Page 42]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - If a value of a type is its default value, it is absent. Only some
+ BOOLEAN and INTEGER types have default values in this protocol
+ definition.
+
+ These restrictions are meant to ease the overhead of encoding and
+ decoding certain elements in BER.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ stated.
+
+5.2. Transmission Control Protocol (TCP)
+
+ The encoded LDAPMessage PDUs are mapped directly onto the TCP
+ [RFC793] bytestream using the BER-based encoding described in Section
+ 5.1. It is recommended that server implementations running over the
+ TCP provide a protocol listener on the Internet Assigned Numbers
+ Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+5.3. Termination of the LDAP session
+
+ Termination of the LDAP session is typically initiated by the client
+ sending an UnbindRequest (Section 4.3), or by the server sending a
+ Notice of Disconnection (Section 4.4.1). In these cases, each
+ protocol peer gracefully terminates the LDAP session by ceasing
+ exchanges at the LDAP message layer, tearing down any SASL layer,
+ tearing down any TLS layer, and closing the transport connection.
+
+ A protocol peer may determine that the continuation of any
+ communication would be pernicious, and in this case, it may abruptly
+ terminate the session by ceasing communication and closing the
+ transport connection.
+
+ In either case, when the LDAP session is terminated, uncompleted
+ operations are handled as specified in Section 3.1.
+
+6. Security Considerations
+
+ This version of the protocol provides facilities for simple
+ authentication using a cleartext password, as well as any SASL
+ [RFC4422] mechanism. Installing SASL and/or TLS layers can provide
+ integrity and other data security services.
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+
+
+
+Sermersheim Standards Track [Page 43]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ Servers are encouraged to prevent directory modifications by clients
+ that have authenticated anonymously [RFC4513].
+
+ Security considerations for authentication methods, SASL mechanisms,
+ and TLS are described in [RFC4513].
+
+ Note that SASL authentication exchanges do not provide data
+ confidentiality or integrity protection for the version or name
+ fields of the BindRequest or the resultCode, diagnosticMessage, or
+ referral fields of the BindResponse, nor for any information
+ contained in controls attached to Bind requests or responses. Thus,
+ information contained in these fields SHOULD NOT be relied on unless
+ it is otherwise protected (such as by establishing protections at the
+ transport layer).
+
+ Implementors should note that various security factors (including
+ authentication and authorization information and data security
+ services) may change during the course of the LDAP session or even
+ during the performance of a particular operation. For instance,
+ credentials could expire, authorization identities or access controls
+ could change, or the underlying security layer(s) could be replaced
+ or terminated. Implementations should be robust in the handling of
+ changing security factors.
+
+ In some cases, it may be appropriate to continue the operation even
+ in light of security factor changes. For instance, it may be
+ appropriate to continue an Abandon operation regardless of the
+ change, or to continue an operation when the change upgraded (or
+ maintained) the security factor. In other cases, it may be
+ appropriate to fail or alter the processing of the operation. For
+ instance, if confidential protections were removed, it would be
+ appropriate either to fail a request to return sensitive data or,
+ minimally, to exclude the return of sensitive data.
+
+ Implementations that cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies that prevent the return of entries or attributes in
+ Search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be in the cache.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 44]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ Servers may return referrals or Search result references that
+ redirect clients to peer servers. It is possible for a rogue
+ application to inject such referrals into the data stream in an
+ attempt to redirect a client to a rogue server. Clients are advised
+ to be aware of this and possibly reject referrals when
+ confidentiality measures are not in place. Clients are advised to
+ reject referrals from the StartTLS operation.
+
+ The matchedDN and diagnosticMessage fields, as well as some
+ resultCode values (e.g., attributeOrValueExists and
+ entryAlreadyExists), could disclose the presence or absence of
+ specific data in the directory that is subject to access and other
+ administrative controls. Server implementations should restrict
+ access to protected information equally under both normal and error
+ conditions.
+
+ Protocol peers MUST be prepared to handle invalid and arbitrary-
+ length protocol encodings. Invalid protocol encodings include: BER
+ encoding exceptions, format string and UTF-8 encoding exceptions,
+ overflow exceptions, integer value exceptions, and binary mode on/off
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+ excellent examples of these exceptions and test cases used to
+ discover flaws.
+
+ In the event that a protocol peer senses an attack that in its nature
+ could cause damage due to further communication at any layer in the
+ LDAP session, the protocol peer should abruptly terminate the LDAP
+ session as described in Section 5.3.
+
+7. Acknowledgements
+
+ This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+ Kille. RFC 2251 was a product of the IETF ASID Working Group.
+
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+ It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga.
+ RFC 3771 was an individual submission to the IETF.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+ Significant contributors of technical review and content include Kurt
+ Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 45]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+8. Normative References
+
+ [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
+ 1:2002 "Information Technology - Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation".
+
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1 : 1993.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3454] Hoffman P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", RFC 3454,
+ December 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", RFC 4346, March 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+
+
+Sermersheim Standards Track [Page 46]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 47]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+9. Informative References
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [PortReg] IANA, "Port Numbers",
+ <http://www.iana.org/assignments/port-numbers>.
+
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/
+ c06/ldapv3/>.
+
+10. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ result code registry to indicate that this document provides the
+ definitive technical specification for result codes 0-36, 48-54, 64-
+ 70, 80-90. It is also noted that one resultCode value
+ (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+ The IANA has also updated the LDAP Protocol Mechanism registry to
+ indicate that this document and [RFC4513] provides the definitive
+ technical specification for the StartTLS (1.3.6.1.4.1.1466.20037)
+ Extended operation.
+
+ IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the
+ ASN.1 module defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim <jimse@novell.com>
+ Specification: RFC 4511
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP ASN.1 module
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 48]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix A. LDAP Result Codes
+
+ This normative appendix details additional considerations regarding
+ LDAP result codes and provides a brief, general description of each
+ LDAP result code enumerated in Section 4.1.9.
+
+ Additional result codes MAY be defined for use with extensions
+ [RFC4520]. Client implementations SHALL treat any result code that
+ they do not recognize as an unknown error condition.
+
+ The descriptions provided here do not fully account for result code
+ substitutions used to prevent unauthorized disclosures (such as
+ substitution of noSuchObject for insufficientAccessRights, or
+ invalidCredentials for insufficientAccessRights).
+
+A.1. Non-Error Result Codes
+
+ These result codes (called "non-error" result codes) do not indicate
+ an error condition:
+
+ success (0),
+ compareFalse (5),
+ compareTrue (6),
+ referral (10), and
+ saslBindInProgress (14).
+
+ The success, compareTrue, and compareFalse result codes indicate
+ successful completion (and, hence, are referred to as "successful"
+ result codes).
+
+ The referral and saslBindInProgress result codes indicate the client
+ needs to take additional action to complete the operation.
+
+A.2. Result Codes
+
+ Existing LDAP result codes are described as follows:
+
+ success (0)
+ Indicates the successful completion of an operation. Note:
+ this code is not used with the Compare operation. See
+ compareFalse (5) and compareTrue (6).
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 49]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ operationsError (1)
+ Indicates that the operation is not properly sequenced with
+ relation to other operations (of same or different type).
+
+ For example, this code is returned if the client attempts to
+ StartTLS [RFC4346] while there are other uncompleted operations
+ or if a TLS layer was already installed.
+
+ protocolError (2)
+ Indicates the server received data that is not well-formed.
+
+ For Bind operation only, this code is also used to indicate
+ that the server does not support the requested protocol
+ version.
+
+ For Extended operations only, this code is also used to
+ indicate that the server does not support (by design or
+ configuration) the Extended operation associated with the
+ requestName.
+
+ For request operations specifying multiple controls, this may
+ be used to indicate that the server cannot ignore the order
+ of the controls as specified, or that the combination of the
+ specified controls is invalid or unspecified.
+
+ timeLimitExceeded (3)
+ Indicates that the time limit specified by the client was
+ exceeded before the operation could be completed.
+
+ sizeLimitExceeded (4)
+ Indicates that the size limit specified by the client was
+ exceeded before the operation could be completed.
+
+ compareFalse (5)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to FALSE or
+ Undefined.
+
+ compareTrue (6)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to TRUE.
+
+ authMethodNotSupported (7)
+ Indicates that the authentication method or mechanism is not
+ supported.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 50]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ strongerAuthRequired (8)
+ Indicates the server requires strong(er) authentication in
+ order to complete the operation.
+
+ When used with the Notice of Disconnection operation, this
+ code indicates that the server has detected that an
+ established security association between the client and
+ server has unexpectedly failed or been compromised.
+
+ referral (10)
+ Indicates that a referral needs to be chased to complete the
+ operation (see Section 4.1.10).
+
+ adminLimitExceeded (11)
+ Indicates that an administrative limit has been exceeded.
+
+ unavailableCriticalExtension (12)
+ Indicates a critical control is unrecognized (see Section
+ 4.1.11).
+
+ confidentialityRequired (13)
+ Indicates that data confidentiality protections are required.
+
+ saslBindInProgress (14)
+ Indicates the server requires the client to send a new bind
+ request, with the same SASL mechanism, to continue the
+ authentication process (see Section 4.2).
+
+ noSuchAttribute (16)
+ Indicates that the named entry does not contain the specified
+ attribute or attribute value.
+
+ undefinedAttributeType (17)
+ Indicates that a request field contains an unrecognized
+ attribute description.
+
+ inappropriateMatching (18)
+ Indicates that an attempt was made (e.g., in an assertion) to
+ use a matching rule not defined for the attribute type
+ concerned.
+
+ constraintViolation (19)
+ Indicates that the client supplied an attribute value that
+ does not conform to the constraints placed upon it by the
+ data model.
+
+ For example, this code is returned when multiple values are
+ supplied to an attribute that has a SINGLE-VALUE constraint.
+
+
+
+Sermersheim Standards Track [Page 51]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ attributeOrValueExists (20)
+ Indicates that the client supplied an attribute or value to
+ be added to an entry, but the attribute or value already
+ exists.
+
+ invalidAttributeSyntax (21)
+ Indicates that a purported attribute value does not conform
+ to the syntax of the attribute.
+
+ noSuchObject (32)
+ Indicates that the object does not exist in the DIT.
+
+ aliasProblem (33)
+ Indicates that an alias problem has occurred. For example,
+ the code may used to indicate an alias has been dereferenced
+ that names no object.
+
+ invalidDNSyntax (34)
+ Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
+ base, target entry, ModifyDN newrdn, etc.) of a request does
+ not conform to the required syntax or contains attribute
+ values that do not conform to the syntax of the attribute's
+ type.
+
+ aliasDereferencingProblem (36)
+ Indicates that a problem occurred while dereferencing an
+ alias. Typically, an alias was encountered in a situation
+ where it was not allowed or where access was denied.
+
+ inappropriateAuthentication (48)
+ Indicates the server requires the client that had attempted
+ to bind anonymously or without supplying credentials to
+ provide some form of credentials.
+
+ invalidCredentials (49)
+ Indicates that the provided credentials (e.g., the user's name
+ and password) are invalid.
+
+ insufficientAccessRights (50)
+ Indicates that the client does not have sufficient access
+ rights to perform the operation.
+
+ busy (51)
+ Indicates that the server is too busy to service the
+ operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 52]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ unavailable (52)
+ Indicates that the server is shutting down or a subsystem
+ necessary to complete the operation is offline.
+
+ unwillingToPerform (53)
+ Indicates that the server is unwilling to perform the
+ operation.
+
+ loopDetect (54)
+ Indicates that the server has detected an internal loop (e.g.,
+ while dereferencing aliases or chaining an operation).
+
+ namingViolation (64)
+ Indicates that the entry's name violates naming restrictions.
+
+ objectClassViolation (65)
+ Indicates that the entry violates object class restrictions.
+
+ notAllowedOnNonLeaf (66)
+ Indicates that the operation is inappropriately acting upon a
+ non-leaf entry.
+
+ notAllowedOnRDN (67)
+ Indicates that the operation is inappropriately attempting to
+ remove a value that forms the entry's relative distinguished
+ name.
+
+ entryAlreadyExists (68)
+ Indicates that the request cannot be fulfilled (added, moved,
+ or renamed) as the target entry already exists.
+
+ objectClassModsProhibited (69)
+ Indicates that an attempt to modify the object class(es) of
+ an entry's 'objectClass' attribute is prohibited.
+
+ For example, this code is returned when a client attempts to
+ modify the structural object class of an entry.
+
+ affectsMultipleDSAs (71)
+ Indicates that the operation cannot be performed as it would
+ affect multiple servers (DSAs).
+
+ other (80)
+ Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 53]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix B. Complete ASN.1 Definition
+
+ This appendix is normative.
+
+ Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
+ -- Copyright (C) The Internet Society (2006). This version of
+ -- this ASN.1 module is part of RFC 4511; see the RFC itself
+ -- for full legal notices.
+ DEFINITIONS
+ IMPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::=
+
+ BEGIN
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+
+
+
+Sermersheim Standards Track [Page 54]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+ -- [RFC4512]
+
+ LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+ -- [RFC4514]
+
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+ -- [RFC4514]
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [RFC4512]
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ MatchingRuleId ::= LDAPString
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+
+
+
+Sermersheim Standards Track [Page 55]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+
+
+
+Sermersheim Standards Track [Page 56]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.8
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+
+
+
+Sermersheim Standards Track [Page 57]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+
+
+
+
+
+Sermersheim Standards Track [Page 58]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 59]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix C. Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2830, and RFC 3771.
+
+C.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to Sections 1,
+ 2, 3.1, and 4, and the remainder of RFC 2251. Readers should
+ consult [RFC4512] and [RFC4513] for summaries of changes to other
+ sections.
+
+C.1.1. Section 1 (Status of this Memo)
+
+ - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
+ authentication mechanisms have been standardized which are
+ sufficient to remove this note. See [RFC4513] for authentication
+ mechanisms.
+
+C.1.2. Section 3.1 (Protocol Model) and others
+
+ - Removed notes giving history between LDAP v1, v2, and v3. Instead,
+ added sufficient language so that this document can stand on its
+ own.
+
+C.1.3. Section 4 (Elements of Protocol)
+
+ - Clarified where the extensibility features of ASN.1 apply to the
+ protocol. This change affected various ASN.1 types by the
+ inclusion of ellipses (...) to certain elements.
+ - Removed the requirement that servers that implement version 3 or
+ later MUST provide the 'supportedLDAPVersion' attribute. This
+ statement provided no interoperability advantages.
+
+C.1.4. Section 4.1.1 (Message Envelope)
+
+ - There was a mandatory requirement for the server to return a
+ Notice of Disconnection and drop the transport connection when a
+ PDU is malformed in a certain way. This has been updated such that
+ the server SHOULD return the Notice of Disconnection, and it MUST
+ terminate the LDAP Session.
+
+C.1.5. Section 4.1.1.1 (Message ID)
+
+ - Required that the messageID of requests MUST be non-zero as the
+ zero is reserved for Notice of Disconnection.
+
+
+
+Sermersheim Standards Track [Page 60]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - Specified when it is and isn't appropriate to return an already
+ used messageID. RFC 2251 accidentally imposed synchronous server
+ behavior in its wording of this.
+
+C.1.6. Section 4.1.2 (String Types)
+
+ - Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
+
+C.1.7. Section 4.1.5.1 (Binary Option) and others
+
+ - Removed the Binary Option from the specification. There are
+ numerous interoperability problems associated with this method of
+ alternate attribute type encoding. Work to specify a suitable
+ replacement is ongoing.
+
+C.1.8. Section 4.1.8 (Attribute)
+
+ - Combined the definitions of PartialAttribute and Attribute here,
+ and defined Attribute in terms of PartialAttribute.
+
+C.1.9. Section 4.1.10 (Result Message)
+
+ - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+ be sent for non-error results.
+ - Moved some language into Appendix A, and referred the reader there.
+ - Allowed matchedDN to be present for other result codes than those
+ listed in RFC 2251.
+ - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+ clarify that this code may often be returned to indicate that a
+ stronger authentication is needed to perform a given operation.
+
+C.1.10. Section 4.1.11 (Referral)
+
+ - Defined referrals in terms of URIs rather than URLs.
+ - Removed the requirement that all referral URIs MUST be equally
+ capable of progressing the operation. The statement was ambiguous
+ and provided no instructions on how to carry it out.
+ - Added the requirement that clients MUST NOT loop between servers.
+ - Clarified the instructions for using LDAPURLs in referrals, and in
+ doing so added a recommendation that the scope part be present.
+ - Removed imperatives which required clients to use URLs in specific
+ ways to progress an operation. These did nothing for
+ interoperability.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 61]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.11. Section 4.1.12 (Controls)
+
+ - Specified how control values defined in terms of ASN.1 are to be
+ encoded.
+ - Noted that the criticality field is only applied to request
+ messages (except UnbindRequest), and must be ignored when present
+ on response messages and UnbindRequest.
+ - Specified that non-critical controls may be ignored at the
+ server's discretion. There was confusion in the original wording
+ which led some to believe that recognized controls may not be
+ ignored as long as they were associated with a proper request.
+ - Added language regarding combinations of controls and the ordering
+ of controls on a message.
+ - Specified that when the semantics of the combination of controls
+ is undefined or unknown, it results in a protocolError.
+ - Changed "The server MUST be prepared" to "Implementations MUST be
+ prepared" in paragraph 8 to reflect that both client and server
+ implementations must be able to handle this (as both parse
+ controls).
+
+C.1.12. Section 4.2 (Bind Operation)
+
+ - Mandated that servers return protocolError when the version is not
+ supported.
+ - Disambiguated behavior when the simple authentication is used, the
+ name is empty, and the password is non-empty.
+ - Required servers to not dereference aliases for Bind. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+ - Required that textual passwords be transferred as UTF-8 encoded
+ Unicode, and added recommendations on string preparation. This was
+ to help ensure interoperability of passwords being sent from
+ different clients.
+
+C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - This section was largely reorganized for readability, and language
+ was added to clarify the authentication state of failed and
+ abandoned Bind operations.
+ - Removed: "If a SASL transfer encryption or integrity mechanism has
+ been negotiated, that mechanism does not support the changing of
+ credentials from one identity to another, then the client MUST
+ instead establish a new connection."
+ If there are dependencies between multiple negotiations of a
+ particular SASL mechanism, the technical specification for that
+ SASL mechanism details how applications are to deal with them.
+ LDAP should not require any special handling.
+ - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
+
+
+
+Sermersheim Standards Track [Page 62]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+ - Mandated that clients not send non-Bind operations while a Bind is
+ in progress, and suggested that servers not process them if they
+ are received. This is needed to ensure proper sequencing of the
+ Bind in relationship to other operations.
+
+C.1.14. Section 4.2.3 (Bind Response)
+
+ - Moved most error-related text to Appendix A, and added text
+ regarding certain errors used in conjunction with the Bind
+ operation.
+ - Prohibited the server from specifying serverSaslCreds when not
+ appropriate.
+
+C.1.15. Section 4.3 (Unbind Operation)
+
+ - Specified that both peers are to cease transmission and terminate
+ the LDAP session for the Unbind operation.
+
+C.1.16. Section 4.4 (Unsolicited Notification)
+
+ - Added instructions for future specifications of Unsolicited
+ Notifications.
+
+C.1.17. Section 4.5.1 (Search Request)
+
+ - SearchRequest attributes is now defined as an AttributeSelection
+ type rather than AttributeDescriptionList, and an ABNF is
+ provided.
+ - SearchRequest attributes may contain duplicate attribute
+ descriptions. This was previously prohibited. Now servers are
+ instructed to ignore subsequent names when they are duplicated.
+ This was relaxed in order to allow different short names and also
+ OIDs to be requested for an attribute.
+ - The present search filter now evaluates to Undefined when the
+ specified attribute is not known to the server. It used to
+ evaluate to FALSE, which caused behavior inconsistent with what
+ most would expect, especially when the 'not' operator was used.
+ - The Filter choice SubstringFilter substrings type is now defined
+ with a lower bound of 1.
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types
+ are now AssertionValue rather than LDAPString. Also, added
+ imperatives stating that 'initial' (if present) must be listed
+ first, and 'final' (if present) must be listed last.
+ - Disambiguated the semantics of the derefAliases choices. There was
+ question as to whether derefInSearching applied to the base object
+ in a wholeSubtree Search.
+ - Added instructions for equalityMatch, substrings, greaterOrEqual,
+ lessOrEqual, and approxMatch.
+
+
+
+Sermersheim Standards Track [Page 63]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+
+C.1.18. Section 4.5.2 (Search Result)
+
+ - Recommended that servers not use attribute short names when it
+ knows they are ambiguous or may cause interoperability problems.
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
+
+C.1.19. Section 4.5.3 (Continuation References in the Search Result)
+
+ - Made changes similar to those made to Section 4.1.11.
+
+C.1.20. Section 4.5.3.1 (Example)
+
+ - Fixed examples to adhere to changes made to Section 4.5.3.
+
+C.1.21. Section 4.6 (Modify Operation)
+
+ - Replaced AttributeTypeAndValues with Attribute as they are
+ equivalent.
+ - Specified the types of modification changes that might
+ temporarily violate schema. Some readers were under the impression
+ that any temporary schema violation was allowed.
+
+C.1.22. Section 4.7 (Add Operation)
+
+ - Aligned Add operation with X.511 in that the attributes of the RDN
+ are used in conjunction with the listed attributes to create the
+ entry. Previously, Add required that the distinguished values be
+ present in the listed attributes.
+ - Removed requirement that the objectClass attribute MUST be
+ specified as some DSE types do not require this attribute.
+ Instead, generic wording was added, requiring the added entry to
+ adhere to the data model.
+ - Removed recommendation regarding placement of objects. This is
+ covered in the data model document.
+
+C.1.23. Section 4.9 (Modify DN Operation)
+
+ - Required servers to not dereference aliases for Modify DN. This
+ was added for consistency with other operations and to help ensure
+ data consistency.
+ - Allow Modify DN to fail when moving between naming contexts.
+ - Specified what happens when the attributes of the newrdn are not
+ present on the entry.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 64]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.24. Section 4.10 (Compare Operation)
+
+ - Specified that compareFalse means that the Compare took place and
+ the result is false. There was confusion that led people to
+ believe that an Undefined match resulted in compareFalse.
+ - Required servers to not dereference aliases for Compare. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+
+C.1.25. Section 4.11 (Abandon Operation)
+
+ - Explained that since Abandon returns no response, clients should
+ not use it if they need to know the outcome.
+ - Specified that Abandon and Unbind cannot be abandoned.
+
+C.1.26. Section 4.12 (Extended Operation)
+
+ - Specified how values of Extended operations defined in terms of
+ ASN.1 are to be encoded.
+ - Added instructions on what Extended operation specifications
+ consist of.
+ - Added a recommendation that servers advertise supported Extended
+ operations.
+
+C.1.27. Section 5.2 (Transfer Protocols)
+
+ - Moved referral-specific instructions into referral-related
+ sections.
+
+C.1.28. Section 7 (Security Considerations)
+
+ - Reworded notes regarding SASL not protecting certain aspects of
+ the LDAP Bind messages.
+ - Noted that Servers are encouraged to prevent directory
+ modifications by clients that have authenticated anonymously
+ [RFC4513].
+ - Added a note regarding the possibility of changes to security
+ factors (authentication, authorization, and data confidentiality).
+ - Warned against following referrals that may have been injected in
+ the data stream.
+ - Noted that servers should protect information equally, whether in
+ an error condition or not, and mentioned matchedDN,
+ diagnosticMessage, and resultCodes specifically.
+ - Added a note regarding malformed and long encodings.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 65]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.29. Appendix A (Complete ASN.1 Definition)
+
+ - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+ - Removed AttributeType. It is not used.
+
+C.2. Changes Made to RFC 2830
+
+ This section summarizes the substantive changes made to Sections of
+ RFC 2830. Readers should consult [RFC4513] for summaries of changes
+ to other sections.
+
+C.2.1. Section 2.3 (Response other than "success")
+
+ - Removed wording indicating that referrals can be returned from
+ StartTLS.
+ - Removed requirement that only a narrow set of result codes can be
+ returned. Some result codes are required in certain scenarios, but
+ any other may be returned if appropriate.
+ - Removed requirement that the ExtendedResponse.responseName MUST be
+ present. There are circumstances where this is impossible, and
+ requiring this is at odds with language in Section 4.12.
+
+C.2.1. Section 4 (Closing a TLS Connection)
+
+ - Reworded most of this section to align with definitions of the
+ LDAP protocol layers.
+ - Removed instructions on abrupt closure as this is covered in other
+ areas of the document (specifically, Section 5.3)
+
+C.3. Changes Made to RFC 3771
+
+ - Rewrote to fit into this document. In general, semantics were
+ preserved. Supporting and background language seen as redundant
+ due to its presence in this document was omitted.
+
+ - Specified that Intermediate responses to a request may be of
+ different types, and one of the response types may be specified to
+ have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 66]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+Editor's Address
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+
+ Phone: +1 801 861-3088
+ EMail: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 67]
+\f
+RFC 4511 LDAPv3 June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 68]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4512 OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2256, 3674 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Directory Information Models
+
+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 (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services that act in
+ accordance with X.500 data and service models. This document
+ describes the X.500 Directory Information Models, as used in LDAP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other LDAP Specifications ..................3
+ 1.2. Relationship to X.501 ......................................4
+ 1.3. Conventions ................................................4
+ 1.4. Common ABNF Productions ....................................4
+ 2. Model of Directory User Information .............................6
+ 2.1. The Directory Information Tree .............................7
+ 2.2. Structure of an Entry ......................................7
+ 2.3. Naming of Entries ..........................................8
+ 2.4. Object Classes .............................................9
+ 2.5. Attribute Descriptions ....................................12
+ 2.6. Alias Entries .............................................16
+ 3. Directory Administrative and Operational Information ...........17
+ 3.1. Subtrees ..................................................17
+ 3.2. Subentries ................................................18
+ 3.3. The 'objectClass' attribute ...............................18
+ 3.4. Operational Attributes ....................................19
+ 4. Directory Schema ...............................................22
+ 4.1. Schema Definitions ........................................23
+ 4.2. Subschema Subentries ......................................32
+ 4.3. 'extensibleObject' object class ...........................35
+ 4.4. Subschema Discovery .......................................35
+ 5. DSA (Server) Informational Model ...............................36
+ 5.1. Server-Specific Data Requirements .........................36
+ 6. Other Considerations ...........................................40
+ 6.1. Preservation of User Information ..........................40
+ 6.2. Short Names ...............................................41
+ 6.3. Cache and Shadowing .......................................41
+ 7. Implementation Guidelines ......................................42
+ 7.1. Server Guidelines .........................................42
+ 7.2. Client Guidelines .........................................42
+ 8. Security Considerations ........................................43
+ 9. IANA Considerations ............................................43
+ 10. Acknowledgements ..............................................44
+ 11. Normative References ..........................................45
+ Appendix A. Changes ...............................................47
+ A.1. Changes to RFC 2251 .......................................47
+ A.2. Changes to RFC 2252 .......................................49
+ A.3. Changes to RFC 2256 .......................................50
+ A.4. Changes to RFC 3674 .......................................51
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+1. Introduction
+
+ This document discusses the X.500 Directory Information Models
+ [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+ [RFC4510].
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. The information held in the Directory
+ is collectively known as the Directory Information Base (DIB). A
+ Directory user, which may be a human or other entity, accesses the
+ Directory through a client (or Directory User Agent (DUA)). The
+ client, on behalf of the directory user, interacts with one or more
+ servers (or Directory System Agents (DSA)). A server holds a
+ fragment of the DIB.
+
+ The DIB contains two classes of information:
+
+ 1) user information (e.g., information provided and administrated
+ by users). Section 2 describes the Model of User Information.
+
+ 2) administrative and operational information (e.g., information
+ used to administer and/or operate the directory). Section 3
+ describes the model of Directory Administrative and Operational
+ Information.
+
+ These two models, referred to as the generic Directory Information
+ Models, describe how information is represented in the Directory.
+ These generic models provide a framework for other information
+ models. Section 4 discusses the subschema information model and
+ subschema discovery. Section 5 discusses the DSA (Server)
+ Informational Model.
+
+ Other X.500 information models (such as access control distribution
+ knowledge and replication knowledge information models) may be
+ adapted for use in LDAP. Specification of how these models apply to
+ LDAP is left to future documents.
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is a integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
+ portions of Sections 4 and 6. Appendix A.1 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [RFC4511], [RFC4513], and [RFC4510] documents.
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
+ summarizes changes to these sections. The remainder of RFC 2252 is
+ obsoleted by [RFC4517].
+
+ This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
+ Appendix A.3 summarizes changes to these sections. The remainder of
+ RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
+
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
+
+1.2. Relationship to X.501
+
+ This document includes material, with and without adaptation, from
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
+
+1.3. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats (as
+ defined in Section 4.1). Definitions provided here are formatted
+ (line wrapped) for readability. Matching rules and LDAP syntaxes
+ referenced in these definitions are specified in [RFC4517].
+
+1.4. Common ABNF Productions
+
+ A number of syntaxes in this document are described using Augmented
+ Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
+ number of syntaxes defined in other documents) rely on the following
+ common productions:
+
+ keystring = leadkeychar *keychar
+ leadkeychar = ALPHA
+ keychar = ALPHA / DIGIT / HYPHEN
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ LDIGIT = %x31-39 ; "1"-"9"
+ HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+ SP = 1*SPACE ; one or more " "
+ WSP = 0*SPACE ; zero or more " "
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ NULL = %x00 ; null (0)
+ SPACE = %x20 ; space (" ")
+ DQUOTE = %x22 ; quote (""")
+ SHARP = %x23 ; octothorpe (or sharp sign) ("#")
+ DOLLAR = %x24 ; dollar sign ("$")
+ SQUOTE = %x27 ; single quote ("'")
+ LPAREN = %x28 ; left paren ("(")
+ RPAREN = %x29 ; right paren (")")
+ PLUS = %x2B ; plus sign ("+")
+ COMMA = %x2C ; comma (",")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+ SEMI = %x3B ; semicolon (";")
+ LANGLE = %x3C ; left angle bracket ("<")
+ EQUALS = %x3D ; equals sign ("=")
+ RANGLE = %x3E ; right angle bracket (">")
+ ESC = %x5C ; backslash ("\")
+ USCORE = %x5F ; underscore ("_")
+ LCURLY = %x7B ; left curly brace "{"
+ RCURLY = %x7D ; right curly brace "}"
+
+ ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
+ UTF8 = UTF1 / UTFMB
+ UTFMB = UTF2 / UTF3 / UTF4
+ UTF0 = %x80-BF
+ UTF1 = %x00-7F
+ UTF2 = %xC2-DF UTF0
+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+ %xF4 %x80-8F 2(UTF0)
+
+ OCTET = %x00-FF ; Any octet (8-bit data unit)
+
+ Object identifiers (OIDs) [X.680] are represented in LDAP using a
+ dot-decimal format conforming to the ABNF:
+
+ numericoid = number 1*( DOT number )
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
+ conform to the ABNF:
+
+ descr = keystring
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Where either an object identifier or a short name may be specified,
+ the following production is used:
+
+ oid = descr / numericoid
+
+ While the <descr> form is generally preferred when the usage is
+ restricted to short names referring to object identifiers that
+ identify like kinds of objects (e.g., attribute type descriptions,
+ matching rule descriptions, object class descriptions), the
+ <numericoid> form should be used when the object identifiers may
+ identify multiple kinds of objects or when an unambiguous short name
+ (descriptor) is not available.
+
+ Implementations SHOULD treat short names (descriptors) used in an
+ ambiguous manner (as discussed above) as unrecognized.
+
+ Short Names (descriptors) are discussed further in Section 6.2.
+
+2. Model of Directory User Information
+
+ As [X.501] states:
+
+ The purpose of the Directory is to hold, and provide access to,
+ information about objects of interest (objects) in some 'world'.
+ An object can be anything which is identifiable (can be named).
+
+ An object class is an identified family of objects, or conceivable
+ objects, which share certain characteristics. Every object
+ belongs to at least one class. An object class may be a subclass
+ of other object classes, in which case the members of the former
+ class, the subclass, are also considered to be members of the
+ latter classes, the superclasses. There may be subclasses of
+ subclasses, etc., to an arbitrary depth.
+
+ A directory entry, a named collection of information, is the basic
+ unit of information held in the Directory. There are multiple kinds
+ of directory entries.
+
+ An object entry represents a particular object. An alias entry
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
+
+ Section 2.1 describes the Directory Information Tree.
+ Section 2.2 discusses the structure of entries.
+ Section 2.3 discusses naming of entries.
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Section 2.4 discusses object classes.
+ Section 2.5 discusses attribute descriptions.
+ Section 2.6 discusses alias entries.
+
+2.1. The Directory Information Tree
+
+ As noted above, the DIB is composed of a set of entries organized
+ hierarchically in a tree structure known as the Directory Information
+ Tree (DIT); specifically, a tree where vertices are the entries.
+
+ The arcs between vertices define relations between entries. If an
+ arc exists from X to Y, then the entry at X is the immediate superior
+ of Y, and Y is the immediate subordinate of X. An entry's superiors
+ are the entry's immediate superior and its superiors. An entry's
+ subordinates are all of its immediate subordinates and their
+ subordinates.
+
+ Similarly, the superior/subordinate relationship between object
+ entries can be used to derive a relation between the objects they
+ represent. DIT structure rules can be used to govern relationships
+ between objects.
+
+ Note: An entry's immediate superior is also known as the entry's
+ parent, and an entry's immediate subordinate is also known as
+ the entry's child. Entries that have the same parent are known
+ as siblings.
+
+2.2. Structure of an Entry
+
+ An entry consists of a set of attributes that hold information about
+ the object that the entry represents. Some attributes represent user
+ information and are called user attributes. Other attributes
+ represent operational and/or administrative information and are
+ called operational attributes.
+
+ An attribute is an attribute description (a type and zero or more
+ options) with one or more associated values. An attribute is often
+ referred to by its attribute description. For example, the
+ 'givenName' attribute is the attribute that consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [RFC4519] and
+ zero options) and one or more associated values.
+
+ The attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions. Options indicate
+ subtypes and other functions.
+
+ Attribute values conform to the defined syntax of the attribute type.
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ No two values of an attribute may be equivalent. Two values are
+ considered equivalent if and only if they would match according to
+ the equality matching rule of the attribute type. Or, if the
+ attribute type is defined with no equality matching rule, two values
+ are equivalent if and only if they are identical. (See 2.5.1 for
+ other restrictions.)
+
+ For example, a 'givenName' attribute can have more than one value,
+ they must be Directory Strings, and they are case insensitive. A
+ 'givenName' attribute cannot hold both "John" and "JOHN", as these
+ are equivalent values per the equality matching rule of the attribute
+ type.
+
+ Additionally, no attribute is to have a value that is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string that includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point, as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
+
+ When an attribute is used for naming of the entry, one and only one
+ value of the attribute is used in forming the Relative Distinguished
+ Name. This value is known as a distinguished value.
+
+2.3. Naming of Entries
+
+2.3.1. Relative Distinguished Names
+
+ Each entry is named relative to its immediate superior. This
+ relative name, known as its Relative Distinguished Name (RDN)
+ [X.501], is composed of an unordered set of one or more attribute
+ value assertions (AVA) consisting of an attribute description with
+ zero options and an attribute value. These AVAs are chosen to match
+ attribute values (each a distinguished value) of the entry.
+
+ An entry's relative distinguished name must be unique among all
+ immediate subordinates of the entry's immediate superior (i.e., all
+ siblings).
+
+ The following are examples of string representations of RDNs
+ [RFC4514]:
+
+ UID=12345
+ OU=Engineering
+ CN=Kurt Zeilenga+L=Redwood Shores
+
+ The last is an example of a multi-valued RDN; that is, an RDN
+ composed of multiple AVAs.
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+2.3.2. Distinguished Names
+
+ An entry's fully qualified name, known as its Distinguished Name (DN)
+ [X.501], is the concatenation of its RDN and its immediate superior's
+ DN. A Distinguished Name unambiguously refers to an entry in the
+ tree. The following are examples of string representations of DNs
+ [RFC4514]:
+
+ UID=nobody@example.com,DC=example,DC=com
+ CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+2.3.3. Alias Names
+
+ An alias, or alias name, is "an name for an object, provided by the
+ use of alias entries" [X.501]. Alias entries are described in
+ Section 2.6.
+
+2.4. Object Classes
+
+ An object class is "an identified family of objects (or conceivable
+ objects) that share certain characteristics" [X.501].
+
+ As defined in [X.501]:
+
+ Object classes are used in the Directory for a number of purposes:
+
+ - describing and categorizing objects and the entries that
+ correspond to these objects;
+
+ - where appropriate, controlling the operation of the Directory;
+
+ - regulating, in conjunction with DIT structure rule
+ specifications, the position of entries in the DIT;
+
+ - regulating, in conjunction with DIT content rule
+ specifications, the attributes that are contained in entries;
+
+ - identifying classes of entry that are to be associated with a
+ particular policy by the appropriate administrative authority.
+
+ An object class (a subclass) may be derived from an object class
+ (its direct superclass) which is itself derived from an even more
+ generic object class. For structural object classes, this process
+ stops at the most generic object class, 'top' (defined in Section
+ 2.4.1). An ordered set of superclasses up to the most superior
+ object class of an object class is its superclass chain.
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ An object class may be derived from two or more direct
+ superclasses (superclasses not part of the same superclass chain).
+ This feature of subclassing is termed multiple inheritance.
+
+ Each object class identifies the set of attributes required to be
+ present in entries belonging to the class and the set of attributes
+ allowed to be present in entries belonging to the class. As an entry
+ of a class must meet the requirements of each class it belongs to, it
+ can be said that an object class inherits the sets of allowed and
+ required attributes from its superclasses. A subclass can identify
+ an attribute allowed by its superclass as being required. If an
+ attribute is a member of both sets, it is required to be present.
+
+ Each object class is defined to be one of three kinds of object
+ classes: Abstract, Structural, or Auxiliary.
+
+ Each object class is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+2.4.1. Abstract Object Classes
+
+ An abstract object class, as the name implies, provides a base of
+ characteristics from which other object classes can be defined to
+ inherit from. An entry cannot belong to an abstract object class
+ unless it belongs to a structural or auxiliary class that inherits
+ from that abstract class.
+
+ Abstract object classes cannot derive from structural or auxiliary
+ object classes.
+
+ All structural object classes derive (directly or indirectly) from
+ the 'top' abstract object class. Auxiliary object classes do not
+ necessarily derive from 'top'.
+
+ The following is the object class definition (see Section 4.1.1) for
+ the 'top' object class:
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+ All entries belong to the 'top' abstract object class.
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+2.4.2. Structural Object Classes
+
+ As stated in [X.501]:
+
+ An object class defined for use in the structural specification of
+ the DIT is termed a structural object class. Structural object
+ classes are used in the definition of the structure of the names
+ of the objects for compliant entries.
+
+ An object or alias entry is characterized by precisely one
+ structural object class superclass chain which has a single
+ structural object class as the most subordinate object class.
+ This structural object class is referred to as the structural
+ object class of the entry.
+
+ Structural object classes are related to associated entries:
+
+ - an entry conforming to a structural object class shall
+ represent the real-world object constrained by the object
+ class;
+
+ - DIT structure rules only refer to structural object classes;
+ the structural object class of an entry is used to specify the
+ position of the entry in the DIT;
+
+ - the structural object class of an entry is used, along with an
+ associated DIT content rule, to control the content of an
+ entry.
+
+ The structural object class of an entry shall not be changed.
+
+ Each structural object class is a (direct or indirect) subclass of
+ the 'top' abstract object class.
+
+ Structural object classes cannot subclass auxiliary object classes.
+
+ Each entry is said to belong to its structural object class as well
+ as all classes in its structural object class's superclass chain.
+
+2.4.3. Auxiliary Object Classes
+
+ Auxiliary object classes are used to augment the characteristics of
+ entries. They are commonly used to augment the sets of attributes
+ required and allowed to be present in an entry. They can be used to
+ describe entries or classes of entries.
+
+ Auxiliary object classes cannot subclass structural object classes.
+
+
+
+
+Zeilenga Standards Track [Page 11]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ An entry can belong to any subset of the set of auxiliary object
+ classes allowed by the DIT content rule associated with the
+ structural object class of the entry. If no DIT content rule is
+ associated with the structural object class of the entry, the entry
+ cannot belong to any auxiliary object class.
+
+ The set of auxiliary object classes that an entry belongs to can
+ change over time.
+
+2.5. Attribute Descriptions
+
+ An attribute description is composed of an attribute type (see
+ Section 2.5.1) and a set of zero or more attribute options (see
+ Section 2.5.2).
+
+ An attribute description is represented by the ABNF:
+
+ attributedescription = attributetype options
+ attributetype = oid
+ options = *( SEMI option )
+ option = 1*keychar
+
+ where <attributetype> identifies the attribute type and each <option>
+ identifies an attribute option. Both <attributetype> and <option>
+ productions are case insensitive. The order in which <option>s
+ appear is irrelevant. That is, any two <attributedescription>s that
+ consist of the same <attributetype> and same set of <option>s are
+ equivalent.
+
+ Examples of valid attribute descriptions:
+
+ 2.5.4.0
+ cn;lang-de;lang-en
+ owner
+
+ An attribute description with an unrecognized attribute type is to be
+ treated as unrecognized. Servers SHALL treat an attribute
+ description with an unrecognized attribute option as unrecognized.
+ Clients MAY treat an unrecognized attribute option as a tagging
+ option (see Section 2.5.2.1).
+
+ All attributes of an entry must have distinct attribute descriptions.
+
+2.5.1. Attribute Types
+
+ An attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions.
+
+
+
+Zeilenga Standards Track [Page 12]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ If no equality matching is specified for the attribute type:
+
+ - the attribute (of the type) cannot be used for naming;
+ - when adding the attribute (or replacing all values), no two
+ values may be equivalent (see 2.2);
+ - individual values of a multi-valued attribute are not to be
+ independently added or deleted;
+ - attribute value assertions (such as matching in search filters
+ and comparisons) using values of such a type cannot be
+ performed.
+
+ Otherwise, the specified equality matching rule is to be used to
+ evaluate attribute value assertions concerning the attribute type.
+ The specified equality rule is to be transitive and commutative.
+
+ The attribute type indicates whether the attribute is a user
+ attribute or an operational attribute. If operational, the attribute
+ type indicates the operational usage and whether or not the attribute
+ is modifiable by users. Operational attributes are discussed in
+ Section 3.4.
+
+ An attribute type (a subtype) may derive from a more generic
+ attribute type (a direct supertype). The following restrictions
+ apply to subtyping:
+
+ - a subtype must have the same usage as its direct supertype,
+ - a subtype's syntax must be the same, or a refinement of, its
+ supertype's syntax, and
+ - a subtype must be collective [RFC3671] if its supertype is
+ collective.
+
+ An attribute description consisting of a subtype and no options is
+ said to be the direct description subtype of the attribute
+ description consisting of the subtype's direct supertype and no
+ options.
+
+ Each attribute type is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+2.5.2. Attribute Options
+
+ There are multiple kinds of attribute description options. The LDAP
+ technical specification details one kind: tagging options.
+
+ Not all options can be associated with attributes held in the
+ directory. Tagging options can be.
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Not all options can be used in conjunction with all attribute types.
+ In such cases, the attribute description is to be treated as
+ unrecognized.
+
+ An attribute description that contains mutually exclusive options
+ shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
+ "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+ unrecognized.
+
+ Other kinds of options may be specified in future documents. These
+ documents must detail how new kinds of options they define relate to
+ tagging options. In particular, these documents must detail whether
+ or not new kinds of options can be associated with attributes held in
+ the directory, how new kinds of options affect transfer of attribute
+ values, and how new kinds of options are treated in attribute
+ description hierarchies.
+
+ Options are represented as short, case-insensitive textual strings
+ conforming to the <option> production defined in Section 2.5 of this
+ document.
+
+ Procedures for registering options are detailed in BCP 64, RFC 4520
+ [RFC4520].
+
+2.5.2.1. Tagging Options
+
+ Attributes held in the directory can have attribute descriptions with
+ any number of tagging options. Tagging options are never mutually
+ exclusive.
+
+ An attribute description with N tagging options is a direct
+ (description) subtype of all attribute descriptions of the same
+ attribute type and all but one of the N options. If the attribute
+ type has a supertype, then the attribute description is also a direct
+ (description) subtype of the attribute description of the supertype
+ and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
+ (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+ 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
+ in [RFC4519]).
+
+2.5.3. Attribute Description Hierarchies
+
+ An attribute description can be the direct subtype of zero or more
+ other attribute descriptions as indicated by attribute type subtyping
+ (as described in Section 2.5.1) or attribute tagging option subtyping
+ (as described in Section 2.5.2.1). These subtyping relationships are
+ used to form hierarchies of attribute descriptions and attributes.
+
+
+
+
+Zeilenga Standards Track [Page 14]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ As adapted from [X.501]:
+
+ Attribute hierarchies allow access to the DIB with varying degrees
+ of granularity. This is achieved by allowing the value components
+ of attributes to be accessed by using either their specific
+ attribute description (a direct reference to the attribute) or a
+ more generic attribute description (an indirect reference).
+
+ Semantically related attributes may be placed in a hierarchical
+ relationship, the more specialized being placed subordinate to the
+ more generalized. Searching for or retrieving attributes and
+ their values is made easier by quoting the more generalized
+ attribute description; a filter item so specified is evaluated for
+ the more specialized descriptions as well as for the quoted
+ description.
+
+ Where subordinate specialized descriptions are selected to be
+ returned as part of a search result these descriptions shall be
+ returned if available. Where the more general descriptions are
+ selected to be returned as part of a search result both the
+ general and the specialized descriptions shall be returned, if
+ available. An attribute value shall always be returned as a value
+ of its own attribute description.
+
+ All of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions for user
+ modification of entry content.
+
+ An attribute value stored in an object or alias entry is of
+ precisely one attribute description. The description is indicated
+ when the value is originally added to the entry.
+
+ For the purpose of subschema administration of the entry, a
+ specification that an attribute is required is fulfilled if the entry
+ contains a value of an attribute description belonging to an
+ attribute hierarchy where the attribute type of that description is
+ the same as the required attribute's type. That is, a "MUST name"
+ specification is fulfilled by 'name' or 'name;x-tag-option', but is
+ not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
+ subtype of 'name'). Likewise, an entry may contain a value of an
+ attribute description belonging to an attribute hierarchy where the
+ attribute type of that description is either explicitly included in
+ the definition of an object class to which the entry belongs or
+ allowed by the DIT content rule applicable to that entry. That is,
+ 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
+ name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
+ (or by "MUST name").
+
+
+
+
+Zeilenga Standards Track [Page 15]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ For the purposes of other policy administration, unless stated
+ otherwise in the specification of the particular administrative
+ model, all of the attribute descriptions in an attribute hierarchy
+ are treated as distinct and unrelated descriptions.
+
+2.6. Alias Entries
+
+ As adapted from [X.501]:
+
+ An alias, or an alias name, for an object is an alternative name
+ for an object or object entry which is provided by the use of
+ alias entries.
+
+ Each alias entry contains, within the 'aliasedObjectName'
+ attribute (known as the 'aliasedEntryName' attribute in X.500), a
+ name of some object. The distinguished name of the alias entry is
+ thus also a name for this object.
+
+ NOTE - The name within the 'aliasedObjectName' is said to be
+ pointed to by the alias. It does not have to be the
+ distinguished name of any entry.
+
+ The conversion of an alias name to an object name is termed
+ (alias) dereferencing and comprises the systematic replacement of
+ alias names, where found within a purported name, by the value of
+ the corresponding 'aliasedObjectName' attribute. The process may
+ require the examination of more than one alias entry.
+
+ Any particular entry in the DIT may have zero or more alias names.
+ It therefore follows that several alias entries may point to the
+ same entry. An alias entry may point to an entry that is not a
+ leaf entry and may point to another alias entry.
+
+ An alias entry shall have no subordinates, so that an alias entry
+ is always a leaf entry.
+
+ Every alias entry shall belong to the 'alias' object class.
+
+ An entry with the 'alias' object class must also belong to an object
+ class (or classes), or be governed by a DIT content rule, which
+ allows suitable naming attributes to be present.
+
+ Example:
+
+ dn: cn=bar,dc=example,dc=com
+ objectClass: top
+ objectClass: alias
+ objectClass: extensibleObject
+
+
+
+Zeilenga Standards Track [Page 16]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ cn: bar
+ aliasedObjectName: cn=foo,dc=example,dc=com
+
+2.6.1. 'alias' Object Class
+
+ Alias entries belong to the 'alias' object class.
+
+ ( 2.5.6.1 NAME 'alias'
+ SUP top STRUCTURAL
+ MUST aliasedObjectName )
+
+2.6.2. 'aliasedObjectName' Attribute Type
+
+ The 'aliasedObjectName' attribute holds the name of the entry an
+ alias points to. The 'aliasedObjectName' attribute is known as the
+ 'aliasedEntryName' attribute in X.500.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3. Directory Administrative and Operational Information
+
+ This section discusses select aspects of the X.500 Directory
+ Administrative and Operational Information model [X.501]. LDAP
+ implementations MAY support other aspects of this model.
+
+3.1. Subtrees
+
+ As defined in [X.501]:
+
+ A subtree is a collection of object and alias entries situated at
+ the vertices of a tree. Subtrees do not contain subentries. The
+ prefix sub, in subtree, emphasizes that the base (or root) vertex
+ of this tree is usually subordinate to the root of the DIT.
+
+ A subtree begins at some vertex and extends to some identifiable
+ lower boundary, possibly extending to leaves. A subtree is always
+ defined within a context which implicitly bounds the subtree. For
+ example, the vertex and lower boundaries of a subtree defining a
+ replicated area are bounded by a naming context.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 17]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+3.2. Subentries
+
+ A subentry is a "special sort of entry, known by the Directory, used
+ to hold information associated with a subtree or subtree refinement"
+ [X.501]. Subentries are used in Directory to hold for administrative
+ and operational purposes as defined in [X.501]. Their use in LDAP is
+ detailed in [RFC3672].
+
+ The term "(sub)entry" in this specification indicates that servers
+ implementing X.500(93) models are, in accordance with X.500(93) as
+ described in [RFC3672], to use a subentry and that other servers are
+ to use an object entry belonging to the appropriate auxiliary class
+ normally used with the subentry (e.g., 'subschema' for subschema
+ subentries) to mimic the subentry. This object entry's RDN SHALL be
+ formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
+ all subentries are named with 'cn').
+
+3.3. The 'objectClass' attribute
+
+ Each entry in the DIT has an 'objectClass' attribute.
+
+ ( 2.5.4.0 NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
+
+ The 'objectClass' attribute specifies the object classes of an entry,
+ which (among other things) are used in conjunction with the
+ controlling schema to determine the permitted attributes of an entry.
+ Values of this attribute can be modified by clients, but the
+ 'objectClass' attribute cannot be removed.
+
+ Servers that follow X.500(93) models SHALL restrict modifications of
+ this attribute to prevent the basic structural class of the entry
+ from being changed. That is, 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 SHALL be implicitly added as
+ well if not already present. That is, if the auxiliary class 'x-a'
+ is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
+ causes 'x-b' to be implicitly added (if is not already present).
+
+ Servers SHALL restrict modifications of this attribute to prevent
+ superclasses of remaining 'objectClass' values from being deleted.
+ That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+
+
+
+Zeilenga Standards Track [Page 18]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+ an attempt to delete only 'x-b' from the 'objectClass' attribute is
+ an error.
+
+3.4. Operational Attributes
+
+ Some attributes, termed operational attributes, are used or
+ maintained by servers for administrative and operational purposes.
+ As stated in [X.501]: "There are three varieties of operational
+ attributes: Directory operational attributes, DSA-shared operational
+ attributes, and DSA-specific operational attributes".
+
+ A directory operational attribute is used to represent operational
+ and/or administrative information in the Directory Information Model.
+ This includes operational attributes maintained by the server (e.g.,
+ 'createTimestamp') as well as operational attributes that hold values
+ administrated by the user (e.g., 'ditContentRules').
+
+ A DSA-shared operational attribute is used to represent information
+ of the DSA Information Model that is shared between DSAs.
+
+ A DSA-specific operational attribute is used to represent information
+ of the DSA Information Model that is specific to the DSA (though, in
+ some cases, may be derived from information shared between DSAs;
+ e.g., 'namingContexts').
+
+ The DSA Information Model operational attributes are detailed in
+ [X.501].
+
+ Operational attributes are not normally visible. They are not
+ returned in search results unless explicitly requested by name.
+
+ Not all operational attributes are user modifiable.
+
+ Entries may contain, among others, the following operational
+ attributes:
+
+ - 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, and
+
+ - modifyTimestamp: the time this entry was last modified.
+
+
+
+
+
+Zeilenga Standards Track [Page 19]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' attributes for all entries of
+ the DIT.
+
+3.4.1. 'creatorsName'
+
+ This attribute appears in entries that were added using the protocol
+ (e.g., using the Add operation). The value is the distinguished name
+ of the creator.
+
+ ( 2.5.18.3 NAME 'creatorsName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.2. 'createTimestamp'
+
+ This attribute appears in entries that were added using the protocol
+ (e.g., using the Add operation). The value is the time the entry was
+ added.
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+ matching rules and the GeneralizedTime
+ (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.3. 'modifiersName'
+
+ This attribute appears in entries that have been modified using the
+ protocol (e.g., using the Modify operation). The value is the
+ distinguished name of the last modifier.
+
+ ( 2.5.18.4 NAME 'modifiersName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+
+
+Zeilenga Standards Track [Page 20]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.4. 'modifyTimestamp'
+
+ This attribute appears in entries that have been modified using the
+ protocol (e.g., using the Modify operation). The value is the time
+ the entry was last modified.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+ matching rules and the GeneralizedTime
+ (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.5. 'structuralObjectClass'
+
+ This attribute indicates the structural object class of the entry.
+
+ ( 2.5.21.9 NAME 'structuralObjectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
+
+3.4.6. 'governingStructureRule'
+
+ This attribute indicates the structure rule governing the entry.
+
+ ( 2.5.21.10 NAME 'governingStructureRule'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'integerMatch' matching rule and INTEGER
+ (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 21]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4. Directory Schema
+
+ As defined in [X.501]:
+
+ The Directory Schema is a set of definitions and constraints
+ concerning the structure of the DIT, the possible ways entries are
+ named, the information that can be held in an entry, the
+ attributes used to represent that information and their
+ organization into hierarchies to facilitate search and retrieval
+ of the information and the ways in which values of attributes may
+ be matched in attribute value and matching rule assertions.
+
+ NOTE 1 - The schema enables the Directory system to, for example:
+
+ - prevent the creation of subordinate entries of the wrong
+ object-class (e.g., a country as a subordinate of a person);
+
+ - prevent the addition of attribute-types to an entry
+ inappropriate to the object-class (e.g., a serial number to a
+ person's entry);
+
+ - prevent the addition of an attribute value of a syntax not
+ matching that defined for the attribute-type (e.g., a printable
+ string to a bit string).
+
+ Formally, the Directory Schema comprises a set of:
+
+ a) Name Form definitions that define primitive naming relations
+ for structural object classes;
+
+ b) DIT Structure Rule definitions that define the names that
+ entries may have and the ways in which the entries may be
+ related to one another in the DIT;
+
+ c) DIT Content Rule definitions that extend the specification of
+ allowable attributes for entries beyond those indicated by the
+ structural object classes of the entries;
+
+ d) Object Class definitions that define the basic set of mandatory
+ and optional attributes that shall be present, and may be
+ present, respectively, in an entry of a given class, and which
+ indicate the kind of object class that is being defined;
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 22]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ e) Attribute Type definitions that identify the object identifier
+ by which an attribute is known, its syntax, associated matching
+ rules, whether it is an operational attribute and if so its
+ type, whether it is a collective attribute, whether it is
+ permitted to have multiple values and whether or not it is
+ derived from another attribute type;
+
+ f) Matching Rule definitions that define matching rules.
+
+ And in LDAP:
+
+ g) LDAP Syntax definitions that define encodings used in LDAP.
+
+4.1. Schema Definitions
+
+ Schema definitions in this section are described using ABNF and rely
+ on the common productions specified in Section 1.2 as well as these:
+
+ noidlen = numericoid [ LCURLY len RCURLY ]
+ len = number
+
+ oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+ oidlist = oid *( WSP DOLLAR WSP oid )
+
+ extensions = *( SP xstring SP qdstrings )
+ xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+ qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+ qdescrlist = [ qdescr *( SP qdescr ) ]
+ qdescr = SQUOTE descr SQUOTE
+
+ qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+ qdstringlist = [ qdstring *( SP qdstring ) ]
+ qdstring = SQUOTE dstring SQUOTE
+ dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+ QQ = ESC %x32 %x37 ; "\27"
+ QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+ ; Any UTF-8 encoded Unicode character
+ ; except %x27 ("\'") and %x5C ("\")
+ QUTF8 = QUTF1 / UTFMB
+
+ ; Any ASCII character except %x27 ("\'") and %x5C ("\")
+ QUTF1 = %x00-26 / %x28-5B / %x5D-7F
+
+ Schema definitions in this section also share a number of common
+ terms.
+
+
+
+Zeilenga Standards Track [Page 23]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ The NAME field provides a set of short names (descriptors) that are
+ to be used as aliases for the OID.
+
+ The DESC field optionally allows a descriptive string to be provided
+ by the directory administrator and/or implementor. While
+ specifications may suggest a descriptive string, there is no
+ requirement that the suggested (or any) descriptive string be used.
+
+ The OBSOLETE field, if present, indicates the element is not active.
+
+ Implementors should note that future versions of this document may
+ expand these definitions to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments and
+ are followed by <SP> and <qdstrings> tokens.
+
+4.1.1. Object Class Definitions
+
+ Object Class definitions are written according to the ABNF:
+
+ ObjectClassDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oids ] ; superior object classes
+ [ SP kind ] ; kind of class
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN
+
+ kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+ where:
+ <numericoid> is object identifier assigned to this object class;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ object class;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this object class is not active;
+ SUP <oids> specifies the direct superclasses of this object class;
+ the kind of object class is indicated by one of ABSTRACT,
+ STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
+ MUST and MAY specify the sets of required and allowed attribute
+ types, respectively; and
+ <extensions> describe extensions.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4.1.2. Attribute Types
+
+ Attribute Type definitions are written according to the ABNF:
+
+ AttributeTypeDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oid ] ; supertype
+ [ SP "EQUALITY" SP oid ] ; equality matching rule
+ [ SP "ORDERING" SP oid ] ; ordering matching rule
+ [ SP "SUBSTR" SP oid ] ; substrings matching rule
+ [ SP "SYNTAX" SP noidlen ] ; value syntax
+ [ SP "SINGLE-VALUE" ] ; single-value
+ [ SP "COLLECTIVE" ] ; collective
+ [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+ [ SP "USAGE" SP usage ] ; usage
+ extensions WSP RPAREN ; extensions
+
+ usage = "userApplications" / ; user
+ "directoryOperation" / ; directory operational
+ "distributedOperation" / ; DSA-shared operational
+ "dSAOperation" ; DSA-specific operational
+
+ where:
+ <numericoid> is object identifier assigned to this attribute type;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ attribute type;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this attribute type is not active;
+ SUP oid specifies the direct supertype of this type;
+ EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
+ ordering, and substrings matching rules, respectively;
+ SYNTAX identifies value syntax by object identifier and may suggest
+ a minimum upper bound;
+ SINGLE-VALUE indicates attributes of this type are restricted to a
+ single value;
+ COLLECTIVE indicates this attribute type is collective
+ [X.501][RFC3671];
+ NO-USER-MODIFICATION indicates this attribute type is not user
+ modifiable;
+ USAGE indicates the application of this attribute type; and
+ <extensions> describe extensions.
+
+ Each attribute type description must contain at least one of the SUP
+ or SYNTAX fields. If no SYNTAX field is provided, the attribute type
+ description takes its value from the supertype.
+
+
+
+Zeilenga Standards Track [Page 25]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+ fields, if not specified, take their value from the supertype.
+
+ Usage of userApplications, the default, indicates that attributes of
+ this type represent user information. That is, they are user
+ attributes.
+
+ A usage of directoryOperation, distributedOperation, or dSAOperation
+ indicates that attributes of this type represent operational and/or
+ administrative information. That is, they are operational
+ attributes.
+
+ directoryOperation usage indicates that the attribute of this type is
+ a directory operational attribute. distributedOperation usage
+ indicates that the attribute of this type is a DSA-shared usage
+ operational attribute. dSAOperation usage indicates that the
+ attribute of this type is a DSA-specific operational attribute.
+
+ COLLECTIVE requires usage userApplications. Use of collective
+ attribute types in LDAP is discussed in [RFC3671].
+
+ NO-USER-MODIFICATION requires an operational usage.
+
+ Note that the <AttributeTypeDescription> does not list the matching
+ rules that can be used with that attribute type in an extensibleMatch
+ search filter [RFC4511]. This is done using the 'matchingRuleUse'
+ attribute described in Section 4.1.4.
+
+ This document refines the schema description of X.501 by requiring
+ that the SYNTAX field in an <AttributeTypeDescription> be a string
+ representation of an object identifier for the LDAP string syntax
+ definition, with an optional indication of the suggested minimum
+ bound of a value of this attribute.
+
+ A suggested minimum upper bound on the number of characters in a
+ value with a string-based syntax, or the number of bytes in a value
+ for all other syntaxes, may be indicated by appending this bound
+ count inside of curly braces following the syntax's OBJECT IDENTIFIER
+ in an Attribute Type Description. This bound is not part of the
+ syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
+ that server implementations should allow a string to be 64 characters
+ long, although they may allow longer strings. Note that a single
+ character of the Directory String syntax may be encoded in more than
+ one octet since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 26]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4.1.3. Matching Rules
+
+ Matching rules are used in performance of attribute value assertions,
+ such as in performance of a Compare operation. They are also used in
+ evaluating search filters, determining which individual values are to
+ be added or deleted during performance of a Modify operation, and in
+ comparing distinguished names.
+
+ Each matching rule is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Matching rule definitions are written according to the ABNF:
+
+ MatchingRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "SYNTAX" SP numericoid ; assertion syntax
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this matching rule;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule is not active;
+ SYNTAX identifies the assertion syntax (the syntax of the assertion
+ value) by object identifier; and
+ <extensions> describe extensions.
+
+4.1.4. Matching Rule Uses
+
+ A matching rule use lists the attribute types that are suitable for
+ use with an extensibleMatch search filter.
+
+ Matching rule use descriptions are written according to the following
+ ABNF:
+
+ MatchingRuleUseDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "APPLIES" SP oids ; attribute types
+ extensions WSP RPAREN ; extensions
+
+
+
+
+
+Zeilenga Standards Track [Page 27]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ where:
+ <numericoid> is the object identifier of the matching rule
+ associated with this matching rule use description;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule use;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule use is not active;
+ APPLIES provides a list of attribute types the matching rule
+ applies to; and
+ <extensions> describe extensions.
+
+4.1.5. LDAP Syntaxes
+
+ LDAP Syntaxes of (attribute and assertion) values are described in
+ terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+ known as the LDAP-specific encoding. Commonly, the LDAP-specific
+ encoding is constrained to a string of Unicode [Unicode] characters
+ in UTF-8 [RFC3629] form.
+
+ Each LDAP syntax is identified by an object identifier (OID).
+
+ LDAP syntax definitions are written according to the ABNF:
+
+ SyntaxDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "DESC" SP qdstring ] ; description
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier assigned to this LDAP syntax;
+ DESC <qdstring> is a short descriptive string; and
+ <extensions> describe extensions.
+
+4.1.6. DIT Content Rules
+
+ A DIT content rule is a "rule governing the content of entries of a
+ particular structural object class" [X.501].
+
+ For DIT entries of a particular structural object class, a DIT
+ content rule specifies which auxiliary object classes the entries are
+ allowed to belong to and which additional attributes (by type) are
+ required, allowed, or not allowed to appear in the entries.
+
+ The list of precluded attributes cannot include any attribute listed
+ as mandatory in the rule, the structural object class, or any of the
+ allowed auxiliary object classes.
+
+
+
+
+
+Zeilenga Standards Track [Page 28]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Each content rule is identified by the object identifier, as well as
+ any short names (descriptors), of the structural object class it
+ applies to.
+
+ An entry may only belong to auxiliary object classes listed in the
+ governing content rule.
+
+ An entry must contain all attributes required by the object classes
+ the entry belongs to as well as all attributes required by the
+ governing content rule.
+
+ An entry may contain any non-precluded attributes allowed by the
+ object classes the entry belongs to as well as all attributes allowed
+ by the governing content rule.
+
+ An entry cannot include any attribute precluded by the governing
+ content rule.
+
+ An entry is governed by (if present and active in the subschema) the
+ DIT content rule that applies to the structural object class of the
+ entry (see Section 2.4.2). If no active rule is present for the
+ entry's structural object class, the entry's content is governed by
+ the structural object class (and possibly other aspects of user and
+ system schema). DIT content rules for superclasses of the structural
+ object class of an entry are not applicable to that entry.
+
+ DIT content rule descriptions are written according to the ABNF:
+
+ DITContentRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "AUX" SP oids ] ; auxiliary object classes
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ [ SP "NOT" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the structural object
+ class associated with this DIT content rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ content rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT content rule use is not active;
+ AUX specifies a list of auxiliary object classes that entries
+ subject to this DIT content rule may belong to;
+
+
+
+Zeilenga Standards Track [Page 29]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ MUST, MAY, and NOT specify lists of attribute types that are
+ required, allowed, or precluded, respectively, from appearing
+ in entries subject to this DIT content rule; and
+ <extensions> describe extensions.
+
+4.1.7. DIT Structure Rules and Name Forms
+
+ It is sometimes desirable to regulate where object and alias entries
+ can be placed in the DIT and how they can be named based upon their
+ structural object class.
+
+4.1.7.1. DIT Structure Rules
+
+ A DIT structure rule is a "rule governing the structure of the DIT by
+ specifying a permitted superior to subordinate entry relationship. A
+ structure rule relates a name form, and therefore a structural object
+ class, to superior structure rules. This permits entries of the
+ structural object class identified by the name form to exist in the
+ DIT as subordinates to entries governed by the indicated superior
+ structure rules" [X.501].
+
+ DIT structure rule descriptions are written according to the ABNF:
+
+ DITStructureRuleDescription = LPAREN WSP
+ ruleid ; rule identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "FORM" SP oid ; NameForm
+ [ SP "SUP" ruleids ] ; superior rules
+ extensions WSP RPAREN ; extensions
+
+ ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+ ruleidlist = ruleid *( SP ruleid )
+ ruleid = number
+
+ where:
+ <ruleid> is the rule identifier of this DIT structure rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ structure rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT structure rule use is not active;
+ FORM is specifies the name form associated with this DIT structure
+ rule;
+ SUP identifies superior rules (by rule id); and
+ <extensions> describe extensions.
+
+
+
+
+
+Zeilenga Standards Track [Page 30]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ If no superior rules are identified, the DIT structure rule applies
+ to an autonomous administrative point (e.g., the root vertex of the
+ subtree controlled by the subschema) [X.501].
+
+4.1.7.2. Name Forms
+
+ A name form "specifies a permissible RDN for entries of a particular
+ structural object class. A name form identifies a named object class
+ and one or more attribute types to be used for naming (i.e., for the
+ RDN). Name forms are primitive pieces of specification used in the
+ definition of DIT structure rules" [X.501].
+
+ Each name form indicates the structural object class to be named, a
+ set of required attribute types, and a set of allowed attribute
+ types. A particular attribute type cannot be in both sets.
+
+ Entries governed by the form must be named using a value from each
+ required attribute type and zero or more values from the allowed
+ attribute types.
+
+ Each name form is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Name form descriptions are written according to the ABNF:
+
+ NameFormDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "OC" SP oid ; structural object class
+ SP "MUST" SP oids ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier that identifies this name form;
+ NAME <qdescrs> are short names (descriptors) identifying this name
+ form;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this name form is not active;
+ OC identifies the structural object class this rule applies to,
+ MUST and MAY specify the sets of required and allowed,
+ respectively, naming attributes for this name form; and
+ <extensions> describe extensions.
+
+ All attribute types in the required ("MUST") and allowed ("MAY")
+ lists shall be different.
+
+
+
+Zeilenga Standards Track [Page 31]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4.2. Subschema Subentries
+
+ Subschema (sub)entries are used for administering information about
+ the directory schema. A single subschema (sub)entry contains all
+ schema definitions (see Section 4.1) used by entries in a particular
+ part of the directory tree.
+
+ Servers that follow X.500(93) models SHOULD implement subschema using
+ the X.500 subschema mechanisms (as detailed in Section 12 of
+ [X.501]), so these are not ordinary object entries but subentries
+ (see Section 3.2). LDAP clients SHOULD NOT assume that servers
+ implement any of the other aspects of X.500 subschema.
+
+ Servers MAY allow subschema modification. Procedures for subschema
+ modification are discussed in Section 14.5 of [X.501].
+
+ A server that masters entries and permits clients to modify these
+ entries SHALL implement and provide access to these subschema
+ (sub)entries including providing a 'subschemaSubentry' attribute in
+ each modifiable entry. This is so clients may discover the
+ attributes and object classes that are permitted to be present. It
+ is strongly RECOMMENDED that all other servers implement this as
+ well.
+
+ The value of the 'subschemaSubentry' attribute is the name of the
+ subschema (sub)entry holding the subschema controlling the entry.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+ Subschema is held in (sub)entries belonging to the subschema
+ auxiliary object class.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The 'ldapSyntaxes' operational attribute may also be present in
+ subschema entries.
+
+
+
+
+
+Zeilenga Standards Track [Page 32]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Servers MAY provide additional attributes (described in other
+ documents) in subschema (sub)entries.
+
+ Servers SHOULD provide the attributes 'createTimestamp' and
+ 'modifyTimestamp' in subschema (sub)entries, in order to allow
+ clients to maintain their caches of schema information.
+
+ The following subsections provide attribute type definitions for each
+ of schema definition attribute types.
+
+4.2.1. 'objectClasses'
+
+ This attribute holds definitions of object classes.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+ defined in [RFC4517].
+
+4.2.2. 'attributeTypes'
+
+ This attribute holds definitions of attribute types.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+ defined in [RFC4517].
+
+4.2.3. 'matchingRules'
+
+ This attribute holds definitions of matching rules.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+ defined in [RFC4517].
+
+
+
+Zeilenga Standards Track [Page 33]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4.2.4 'matchingRuleUse'
+
+ This attribute holds definitions of matching rule uses.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [RFC4517].
+
+4.2.5. 'ldapSyntaxes'
+
+ This attribute holds definitions of LDAP syntaxes.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+ in [RFC4517].
+
+4.2.6. 'dITContentRules'
+
+ This attribute lists DIT Content Rules that are present in the
+ subschema.
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+ defined in [RFC4517].
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 34]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+4.2.7. 'dITStructureRules'
+
+ This attribute lists DIT Structure Rules that are present in the
+ subschema.
+
+ ( 2.5.21.1 NAME 'dITStructureRules'
+ EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+ USAGE directoryOperation )
+
+ The 'integerFirstComponentMatch' matching rule and the
+ DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
+ are defined in [RFC4517].
+
+4.2.8 'nameForms'
+
+ This attribute lists Name Forms that are in force.
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
+ defined in [RFC4517].
+
+4.3. 'extensibleObject' object class
+
+ The 'extensibleObject' auxiliary object class allows entries that
+ belong to it to hold any user attribute. The set of allowed
+ attribute types of this object class is implicitly the set of all
+ attribute types of userApplications usage.
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+ The mandatory attributes of the other object classes of this entry
+ are still required to be present, and any precluded attributes are
+ still not allowed to be present.
+
+4.4. Subschema Discovery
+
+ To discover the DN of the subschema (sub)entry holding the subschema
+ controlling a particular entry, a client reads that entry's
+ 'subschemaSubentry' operational attribute. To read schema attributes
+ from the subschema (sub)entry, clients MUST issue a Search operation
+ [RFC4511] where baseObject is the DN of the subschema (sub)entry,
+
+
+
+Zeilenga Standards Track [Page 35]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
+ and the attributes field lists the names of the desired schema
+ attributes (as they are operational). Note: the
+ "(objectClass=subschema)" filter allows LDAP servers that gateway to
+ X.500 to detect that subentry information is being requested.
+
+ Clients SHOULD NOT assume that a published subschema is complete,
+ that the server supports all of the schema elements it publishes, or
+ that the server does not support an unpublished element.
+
+5. DSA (Server) Informational Model
+
+ The LDAP protocol assumes there are one or more servers that jointly
+ provide access to a Directory Information Tree (DIT). The server
+ holding the original information is called the "master" (for that
+ information). Servers that hold copies of the original information
+ are referred to as "shadowing" or "caching" servers.
+
+
+ As defined in [X.501]:
+
+ context prefix: The sequence of RDNs leading from the Root of the
+ DIT to the initial vertex of a naming context; corresponds to
+ the distinguished name of that vertex.
+
+ naming context: A subtree of entries held in a single master DSA.
+
+ That is, a naming context is 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 that are mastered by different servers. The context prefix
+ is the name of the initial entry.
+
+ The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+ naming context (or any subtree); each server has different attribute
+ values in the root DSE.
+
+5.1. Server-Specific Data Requirements
+
+ An LDAP server SHALL 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, which is named with
+ the DN with zero RDNs (whose [RFC4514] representation is as the
+ zero-length string).
+
+ These attributes are retrievable, subject to access control and other
+ restrictions, if a client performs a Search operation [RFC4511] with
+ an empty baseObject, scope of baseObject, the filter
+
+
+
+Zeilenga Standards Track [Page 36]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ "(objectClass=*)" [RFC4515], and the attributes field listing the
+ names of the desired attributes. It is noted that root DSE
+ attributes are operational and, like other operational attributes,
+ are not returned in search requests unless requested by name.
+
+ The root DSE SHALL NOT be included if the client performs a subtree
+ search starting from the root.
+
+ Servers may allow clients to modify attributes of the root DSE, where
+ appropriate.
+
+ The following attributes of the root DSE are defined below.
+ Additional attributes may be defined in other documents.
+
+ - altServer: alternative servers;
+
+ - namingContexts: naming contexts;
+
+ - supportedControl: recognized LDAP controls;
+
+ - supportedExtension: recognized LDAP extended operations;
+
+ - supportedFeatures: recognized LDAP features;
+
+ - supportedLDAPVersion: LDAP versions supported; and
+
+ - supportedSASLMechanisms: recognized Simple Authentication and
+ Security Layers (SASL) [RFC4422] mechanisms.
+
+ The values provided for these attributes may depend on session-
+ specific and other factors. For example, a server supporting the
+ SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
+ identity has been established by a lower level. See [RFC4513].
+
+ The root DSE may also include a 'subschemaSubentry' attribute. If it
+ does, the attribute refers to the subschema (sub)entry holding the
+ schema controlling the root DSE. Clients SHOULD NOT assume that this
+ subschema (sub)entry controls other entries held by the server.
+ General subschema discovery procedures are provided in Section 4.4.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 37]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+5.1.1. 'altServer'
+
+ The 'altServer' attribute lists URIs referring to alternative servers
+ that may be contacted when this server becomes unavailable. URIs for
+ servers implementing the LDAP are written according to [RFC4516].
+ Other kinds of URIs may be provided. If the server does not know of
+ any other servers that could be used, this attribute will be absent.
+ Clients may cache this information in case their preferred server
+ later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ USAGE dSAOperation )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+ [RFC4517].
+
+5.1.2. 'namingContexts'
+
+ The 'namingContexts' attribute lists the context prefixes of the
+ naming contexts the server masters or shadows (in part or in whole).
+ If the server is a first-level DSA [X.501], it should list (in
+ addition) an empty string (indicating the root of the DIT). If the
+ server does not master or shadow any information (e.g., it is an LDAP
+ gateway to a public X.500 directory) this attribute will be absent.
+ If the server believes it masters or shadows the entire directory,
+ the attribute will have a single value, and that value will be the
+ empty string (indicating the root of the DIT).
+
+ This attribute may be used, for example, to select a suitable entry
+ name for subsequent operations with this server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE dSAOperation )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+ defined in [RFC4517].
+
+5.1.3. 'supportedControl'
+
+ The 'supportedControl' attribute lists object identifiers identifying
+ the request controls [RFC4511] the server supports. If the server
+ does not support any request controls, this attribute will be absent.
+ Object identifiers identifying response controls need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+
+
+Zeilenga Standards Track [Page 38]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [RFC4517].
+
+5.1.4. 'supportedExtension'
+
+ The 'supportedExtension' attribute lists object identifiers
+ identifying the extended operations [RFC4511] that the server
+ supports. If the server does not support any extended operations,
+ this attribute will be absent.
+
+ An extended operation generally consists of an extended request and
+ an extended response but may also include other protocol data units
+ (such as intermediate responses). The object identifier assigned to
+ the extended request is used to identify the extended operation.
+ Other object identifiers used in the extended operation need not be
+ listed as values of this attribute.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [RFC4517].
+
+5.1.5. 'supportedFeatures'
+
+ The 'supportedFeatures' attribute lists object identifiers
+ identifying elective features that the server supports. If the
+ server does not support any discoverable elective features, this
+ attribute will be absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [RFC4517].
+
+
+
+Zeilenga Standards Track [Page 39]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+5.1.6. 'supportedLDAPVersion'
+
+ The 'supportedLDAPVersion' attribute lists the versions of LDAP that
+ the server supports.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ USAGE dSAOperation )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
+ [RFC4517].
+
+5.1.7. 'supportedSASLMechanisms'
+
+ The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+ [RFC4422] that the server recognizes and/or supports [RFC4513]. The
+ contents of this attribute may depend on the current session state.
+ If the server does not support any SASL mechanisms, this attribute
+ will not be present.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE dSAOperation )
+
+ The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ defined in [RFC4517].
+
+6. Other Considerations
+
+6.1. Preservation of User Information
+
+ Syntaxes may be defined that have specific value and/or value form
+ (representation) preservation requirements. For example, a syntax
+ containing digitally signed data can mandate that the server preserve
+ both the value and form of value presented to ensure that the
+ signature is not invalidated.
+
+ Where such requirements have not been explicitly stated, servers
+ SHOULD preserve the value of user information but MAY return the
+ value in a different form. And where a server is unable (or
+ unwilling) to preserve the value of user information, the server
+ SHALL ensure that an equivalent value (per Section 2.3) is returned.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 40]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+6.2. Short Names
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers and are used to identify various
+ schema elements. However, it is not expected that LDAP
+ implementations with human user interface would display these short
+ names (or the object identifiers they refer to) to the user.
+ Instead, they would most likely be performing translations (such as
+ expressing the short name in one of the local national languages).
+ For example, the short name "st" (stateOrProvinceName) might be
+ displayed to a German-speaking user as "Land".
+
+ The same short name might have different meaning in different
+ subschemas, and, within a particular subschema, the same short name
+ might refer to different object identifiers each identifying a
+ different kind of schema element.
+
+ Implementations MUST be prepared that the same short name might be
+ used in a subschema to refer to the different kinds of schema
+ elements. That is, there might be an object class 'x-fubar' and an
+ attribute type 'x-fubar' in a subschema.
+
+ Implementations MUST be prepared that the same short name might be
+ used in the different subschemas to refer to the different schema
+ elements. That is, there might be two matching rules 'x-fubar', each
+ in different subschemas.
+
+ Procedures for registering short names (descriptors) are detailed in
+ BCP 64, RFC 4520 [RFC4520].
+
+6.3. Cache and Shadowing
+
+ 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 that perform shadowing or caching MUST ensure
+ that they do not violate any access control constraints placed on the
+ data by the originating server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 41]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+7. Implementation Guidelines
+
+7.1. Server Guidelines
+
+ Servers MUST recognize all names of attribute types and object
+ classes defined in this document but, unless stated otherwise, need
+ not support the associated functionality. Servers SHOULD recognize
+ all the names of attribute types and object classes defined in
+ Section 3 and 4, respectively, of [RFC4519].
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints.
+
+ Servers MAY support DIT Content Rules. Servers MAY support DIT
+ Structure Rules and Name Forms.
+
+ Servers MAY support alias entries.
+
+ Servers MAY support the 'extensibleObject' object class.
+
+ Servers MAY support subentries. If so, they MUST do so in accordance
+ with [RFC3672]. Servers that do not support subentries SHOULD use
+ object entries to mimic subentries as detailed in Section 3.2.
+
+ Servers MAY implement additional schema elements. Servers SHOULD
+ provide definitions of all schema elements they support in subschema
+ (sub)entries.
+
+7.2. Client Guidelines
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schema elements beyond
+ those referenced in Section 7.1. The client can retrieve subschema
+ information as described in Section 4.4.
+
+ Clients MUST NOT display or attempt to decode a value as ASN.1 if the
+ value's syntax is not known. Clients MUST NOT assume the LDAP-
+ specific string encoding is restricted to a UTF-8 encoded string of
+ Unicode characters or any particular subset of Unicode (such as a
+ printable subset) unless such restriction is explicitly stated.
+ Clients SHOULD NOT send attribute values in a request that are not
+ valid according to the syntax defined for the attributes.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 42]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+8. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations, or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ General security considerations for accessing directory information
+ with LDAP are discussed in [RFC4511] and [RFC4513].
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry as indicated in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC 4512
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) has been added to
+ the registry.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ governingStructureRule A 2.5.21.10
+ structuralObjectClass A 2.5.21.9
+
+ The following descriptors (short names) have been updated to
+ refer to this RFC.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ alias O 2.5.6.1
+ aliasedObjectName A 2.5.4.1
+ altServer A 1.3.6.1.4.1.1466.101.120.6
+ attributeTypes A 2.5.21.5
+ createTimestamp A 2.5.18.1
+ creatorsName A 2.5.18.3
+ dITContentRules A 2.5.21.2
+ dITStructureRules A 2.5.21.1
+ extensibleObject O 1.3.6.1.4.1.1466.101.120.111
+ ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
+
+
+
+Zeilenga Standards Track [Page 43]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ matchingRuleUse A 2.5.21.8
+ matchingRules A 2.5.21.4
+ modifiersName A 2.5.18.4
+ modifyTimestamp A 2.5.18.2
+ nameForms A 2.5.21.7
+ namingContexts A 1.3.6.1.4.1.1466.101.120.5
+ objectClass A 2.5.4.0
+ objectClasses A 2.5.21.6
+ subschema O 2.5.20.1
+ subschemaSubentry A 2.5.18.10
+ supportedControl A 1.3.6.1.4.1.1466.101.120.13
+ supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
+ supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
+ supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
+ top O 2.5.6.0
+
+10. Acknowledgements
+
+ This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+ S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+ RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+ Indexing of Directories (ASID) Working Group. This document is also
+ based in part on "The Directory: Models" [X.501], a product of the
+ International Telephone Union (ITU). Additional text was borrowed
+ from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 44]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+11. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+
+
+Zeilenga Standards Track [Page 45]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 46]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+Appendix A. Changes
+
+ This appendix is non-normative.
+
+ This document amounts to nearly a complete rewrite of portions of RFC
+ 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
+ overall clarity of technical specification. This appendix provides a
+ summary of substantive changes made to the portions of these
+ documents incorporated into this document. Readers should consult
+ [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
+ remaining portions of these documents.
+
+A.1. Changes to RFC 2251
+
+ This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
+ portions of Sections 4 and 6 as summarized below.
+
+A.1.1. Section 3.2 of RFC 2251
+
+ Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+ data model, as used by LDAP. The previous specification relied on
+ [X.501] but lacked clarity in how X.500 models are adapted for use by
+ LDAP. This document describes the X.500 data models, as used by
+ LDAP, in greater detail, especially in areas where adaptation is
+ needed.
+
+ Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+ or more associated values". In LDAP, an attribute is better
+ described as an attribute description, a type with zero or more
+ options, and one or more associated values.
+
+ Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+ objectClasses and attributeTypes attributes, yet X.500(93) treats
+ these attributes as optional. While generally all implementations
+ that support X.500(93) subschema mechanisms will provide both of
+ these attributes, it is not absolutely required for interoperability
+ that all servers do. The mandate was removed for consistency with
+ X.500(93). The subschema discovery mechanism was also clarified to
+ indicate that subschema controlling an entry is obtained by reading
+ the (sub)entry referred to by that entry's 'subschemaSubentry'
+ attribute.
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 47]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+A.1.2. Section 3.4 of RFC 2251
+
+ Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+ This material, with changes, was incorporated in Section 5.1 of this
+ document.
+
+ Changes:
+
+ - Clarify that attributes of the root DSE are subject to "other
+ restrictions" in addition to access controls.
+
+ - Clarify that only recognized extended requests need to be
+ enumerated 'supportedExtension'.
+
+ - Clarify that only recognized request controls need to be enumerated
+ 'supportedControl'.
+
+ - Clarify that root DSE attributes are operational and, like other
+ operational attributes, will not be returned in search requests
+ unless requested by name.
+
+ - Clarify that not all root DSE attributes are user modifiable.
+
+ - Remove inconsistent text regarding handling of the
+ 'subschemaSubentry' attribute within the root DSE. The previous
+ specification stated that the 'subschemaSubentry' attribute held in
+ the root DSE referred to "subschema entries (or subentries) known
+ by this server". This is inconsistent with the attribute's
+ intended use as well as its formal definition as a single valued
+ attribute [X.501]. It is also noted that a simple (possibly
+ incomplete) list of subschema (sub)entries is not terribly useful.
+ This document (in Section 5.1) specifies that the
+ 'subschemaSubentry' attribute of the root DSE refers to the
+ subschema controlling the root DSE. It is noted that the general
+ subschema discovery mechanism remains available (see Section 4.4 of
+ this document).
+
+A.1.3. Section 4 of RFC 2251
+
+ Portions of Section 4 of RFC 2251 detailing aspects of the
+ information model used by LDAP were incorporated in this document,
+ including:
+
+ - Restriction of distinguished values to attributes whose
+ descriptions have no options (from Section 4.1.3);
+
+
+
+
+
+
+Zeilenga Standards Track [Page 48]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ - Data model aspects of Attribute Types (from Section 4.1.4),
+ Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9); and
+
+ - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
+
+ Clarifications to these portions include:
+
+ - Subtyping and AttributeDescriptions with options.
+
+A.1.4. Section 6 of RFC 2251
+
+ The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+ where incorporated into this document.
+
+A.2. Changes to RFC 2252
+
+ This document incorporates Sections 4, 5, and 7 from RFC 2252.
+
+A.2.1. Section 4 of RFC 2252
+
+ The specification was updated to use Augmented BNF [RFC4234]. The
+ string representation of an OBJECT IDENTIFIER was tightened to
+ disallow leading zeros as described in RFC 2252.
+
+ The <descr> syntax was changed to disallow semicolon (U+003B)
+ characters in order to appear to be consistent its natural language
+ specification "descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter". In a related change, the statement "an AttributeDescription
+ can be used as the value in a NAME part of an
+ AttributeTypeDescription" was deleted. RFC 2252 provided no
+ specification of the semantics of attribute options appearing in NAME
+ fields.
+
+ RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+ over the <numericoid> form. However, <descr> form can be ambiguous.
+ To address this issue, the imperative was replaced with a statement
+ (in Section 1.4) that while the <descr> form is generally preferred,
+ <numericoid> should be used where an unambiguous <descr> is not
+ available. Additionally, an expanded discussion of descriptor issues
+ is in Section 6.2 ("Short Names").
+
+ The ABNF for a quoted string (qdstring) was updated to reflect
+ support for the escaping mechanism described in Section 4.3 of RFC
+ 2252.
+
+
+
+
+
+Zeilenga Standards Track [Page 49]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+A.2.2. Section 5 of RFC 2252
+
+ Definitions of operational attributes provided in Section 5 of RFC
+ 2252 where incorporated into this document.
+
+ The 'namingContexts' description was clarified. A first-level DSA
+ should publish, in addition to other values, "" indicating the root
+ of the DIT.
+
+ The 'altServer' description was clarified. It may hold any URI.
+
+ The 'supportedExtension' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the extended
+ requests of the extended operations it recognizes.
+
+ The 'supportedControl' description was clarified. A server need only
+ list the OBJECT IDENTIFIERs associated with the request controls it
+ recognizes.
+
+ Descriptions for the 'structuralObjectClass' and
+ 'governingStructureRule' operational attribute types were added.
+
+ The attribute definition of 'subschemaSubentry' was corrected to list
+ the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
+
+A.2.3. Section 7 of RFC 2252
+
+ Section 7 of RFC 2252 provides definitions of the 'subschema' and
+ 'extensibleObject' object classes. These definitions where
+ integrated into Section 4.2 and Section 4.3 of this document,
+ respectively. Section 7 of RFC 2252 also contained the object class
+ implementation requirement. This was incorporated into Section 7 of
+ this document.
+
+ The specification of 'extensibleObject' was clarified regarding how
+ it interacts with precluded attributes.
+
+A.3. Changes to RFC 2256
+
+ This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+ 2256.
+
+ Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+ attribute type. This was integrated into Section 2.4.1 of this
+ document. The statement "One of the values is either 'top' or
+ 'alias'" was replaced with statement that one of the values is 'top'
+ as entries belonging to 'alias' also belong to 'top'.
+
+
+
+
+Zeilenga Standards Track [Page 50]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+ Section 5.2 of RFC 2256 provided the definition of the
+ 'aliasedObjectName' attribute type. This was integrated into Section
+ 2.6.2 of this document.
+
+ Section 7.1 of RFC 2256 provided the definition of the 'top' object
+ class. This was integrated into Section 2.4.1 of this document.
+
+ Section 7.2 of RFC 2256 provided the definition of the 'alias' object
+ class. This was integrated into Section 2.6.1 of this document.
+
+A.4. Changes to RFC 3674
+
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 51]
+\f
+RFC 4512 LDAP Models June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 52]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Harrison, Ed.
+Request for Comments: 4513 Novell, Inc.
+Obsoletes: 2251, 2829, 2830 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Authentication Methods and Security Mechanisms
+
+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 (2006).
+
+Abstract
+
+ This document describes authentication methods and security
+ mechanisms of the Lightweight Directory Access Protocol (LDAP). This
+ document details establishment of Transport Layer Security (TLS)
+ using the StartTLS operation.
+
+ This document details the simple Bind authentication method including
+ anonymous, unauthenticated, and name/password mechanisms and the
+ Simple Authentication and Security Layer (SASL) Bind authentication
+ method including the EXTERNAL mechanism.
+
+ This document discusses various authentication and authorization
+ states through which a session to an LDAP server may pass and the
+ actions that trigger these state changes.
+
+ This document, together with other documents in the LDAP Technical
+ Specification (see Section 1 of the specification's road map),
+ obsoletes RFC 2251, RFC 2829, and RFC 2830.
+
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 1]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Relationship to Other Documents ............................6
+ 1.2. Conventions ................................................6
+ 2. Implementation Requirements .....................................7
+ 3. StartTLS Operation ..............................................8
+ 3.1. TLS Establishment Procedures ..............................8
+ 3.1.1. StartTLS Request Sequencing .........................8
+ 3.1.2. Client Certificate ..................................9
+ 3.1.3. Server Identity Check ...............................9
+ 3.1.3.1. Comparison of DNS Names ...................10
+ 3.1.3.2. Comparison of IP Addresses ................11
+ 3.1.3.3. Comparison of Other subjectName Types .....11
+ 3.1.4. Discovery of Resultant Security Level ..............11
+ 3.1.5. Refresh of Server Capabilities Information .........11
+ 3.2. Effect of TLS on Authorization State .....................12
+ 3.3. TLS Ciphersuites ..........................................12
+ 4. Authorization State ............................................13
+ 5. Bind Operation .................................................14
+ 5.1. Simple Authentication Method ..............................14
+ 5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
+ 5.1.2. Unauthenticated Authentication Mechanism of
+ Simple Bind ........................................14
+ 5.1.3. Name/Password Authentication Mechanism of
+ Simple Bind ........................................15
+ 5.2. SASL Authentication Method ................................16
+ 5.2.1. SASL Protocol Profile ..............................16
+ 5.2.1.1. SASL Service Name for LDAP ................16
+ 5.2.1.2. SASL Authentication Initiation and
+ Protocol Exchange .........................16
+ 5.2.1.3. Optional Fields ...........................17
+ 5.2.1.4. Octet Where Negotiated Security
+ Layers Take Effect ........................18
+ 5.2.1.5. Determination of Supported SASL
+ Mechanisms ................................18
+ 5.2.1.6. Rules for Using SASL Layers ...............19
+ 5.2.1.7. Support for Multiple Authentications ......19
+ 5.2.1.8. SASL Authorization Identities .............19
+ 5.2.2. SASL Semantics within LDAP .........................20
+ 5.2.3. SASL EXTERNAL Authentication Mechanism .............20
+ 5.2.3.1. Implicit Assertion ........................21
+ 5.2.3.2. Explicit Assertion ........................21
+ 6. Security Considerations ........................................21
+ 6.1. General LDAP Security Considerations ......................21
+ 6.2. StartTLS Security Considerations ..........................22
+ 6.3. Bind Operation Security Considerations ....................23
+ 6.3.1. Unauthenticated Mechanism Security Considerations ..23
+
+
+
+Harrison Standards Track [Page 2]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ 6.3.2. Name/Password Mechanism Security Considerations ....23
+ 6.3.3. Password-Related Security Considerations ...........23
+ 6.3.4. Hashed Password Security Considerations ............24
+ 6.4. SASL Security Considerations ..............................24
+ 6.5. Related Security Considerations ...........................25
+ 7. IANA Considerations ............................................25
+ 8. Acknowledgements ...............................................25
+ 9. Normative References ...........................................26
+ 10. Informative References ........................................27
+ Appendix A. Authentication and Authorization Concepts .............28
+ A.1. Access Control Policy .....................................28
+ A.2. Access Control Factors ....................................28
+ A.3. Authentication, Credentials, Identity .....................28
+ A.4. Authorization Identity ....................................29
+ Appendix B. Summary of Changes ....................................29
+ B.1. Changes Made to RFC 2251 ..................................30
+ B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
+ B.1.2. Section 4.2.2 ("Authentication and Other Security
+ Services") .........................................30
+ B.2. Changes Made to RFC 2829 ..................................30
+ B.2.1. Section 4 ("Required security mechanisms") .........30
+ B.2.2. Section 5.1 ("Anonymous authentication
+ procedure") ........................................31
+ B.2.3. Section 6 ("Password-based authentication") ........31
+ B.2.4. Section 6.1 ("Digest authentication") ..............31
+ B.2.5. Section 6.2 ("'simple' authentication choice under
+ TLS encryption") ...................................31
+ B.2.6. Section 6.3 ("Other authentication choices with
+ TLS") ..............................................31
+ B.2.7. Section 7.1 ("Certificate-based authentication
+ with TLS") .........................................31
+ B.2.8. Section 8 ("Other mechanisms") .....................32
+ B.2.9. Section 9 ("Authorization Identity") ...............32
+ B.2.10. Section 10 ("TLS Ciphersuites") ...................32
+ B.3. Changes Made to RFC 2830 ..................................32
+ B.3.1. Section 3.6 ("Server Identity Check") ..............32
+ B.3.2. Section 3.7 ("Refresh of Server Capabilities
+ Information") ......................................33
+ B.3.3. Section 5 ("Effects of TLS on a Client's
+ Authorization Identity") ...........................33
+ B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 3]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
+ powerful protocol for accessing directories. It offers means of
+ searching, retrieving, and manipulating directory content and ways to
+ access a rich set of security functions.
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be a
+ minimum subset of security functions that is common to all
+ implementations that claim LDAP conformance.
+
+ Basic threats to an LDAP directory service include (but are not
+ limited to):
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations.
+
+ (2) Unauthorized access to directory data by monitoring access of
+ others.
+
+ (3) Unauthorized access to reusable client authentication information
+ by monitoring access of others.
+
+ (4) Unauthorized modification of directory data.
+
+ (5) Unauthorized modification of configuration information.
+
+ (6) Denial of Service: Use of resources (commonly in excess) in a
+ manner intended to deny service to others.
+
+ (7) Spoofing: Tricking a user or client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the client's
+ transport connection. Tricking a user or client into sending
+ privileged information to a hostile entity that appears to be the
+ directory server but is not. Tricking a directory server into
+ believing that information came from a particular client when in
+ fact it came from a hostile entity.
+
+ (8) Hijacking: An attacker seizes control of an established protocol
+ session.
+
+ Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats
+ (2) and (3) are passive attacks.
+
+
+
+
+
+
+Harrison Standards Track [Page 4]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Threats (1), (4), (5), and (6) are due to hostile clients. Threats
+ (2), (3), (7), and (8) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server, e.g., IP
+ spoofing.
+
+ LDAP offers the following security mechanisms:
+
+ (1) Authentication by means of the Bind operation. The Bind
+ operation provides a simple method that supports anonymous,
+ unauthenticated, and name/password mechanisms, and the Simple
+ Authentication and Security Layer (SASL) method, which supports a
+ wide variety of authentication mechanisms.
+
+ (2) Mechanisms to support vendor-specific access control facilities
+ (LDAP does not offer a standard access control facility).
+
+ (3) Data integrity service by means of security layers in Transport
+ Layer Security (TLS) or SASL mechanisms.
+
+ (4) Data confidentiality service by means of security layers in TLS
+ or SASL mechanisms.
+
+ (5) Server resource usage limitation by means of administrative
+ limits configured on the server.
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanisms.
+
+ LDAP may also be protected by means outside the LDAP protocol, e.g.,
+ with IP layer security [RFC4301].
+
+ Experience has shown that simply allowing implementations to pick and
+ choose the security mechanisms that will be implemented is not a
+ strategy that leads to interoperability. In the absence of mandates,
+ clients will continue to be written that do not support any security
+ function supported by the server, or worse, they will only support
+ mechanisms that provide inadequate security for most circumstances.
+
+ It is desirable to allow clients to authenticate using a variety of
+ mechanisms including mechanisms where identities are represented as
+ distinguished names [X.501][RFC4512], in string form [RFC4514], or as
+ used in different systems (e.g., simple user names [RFC4013]).
+ Because some authentication mechanisms transmit credentials in plain
+ text form, and/or do not provide data security services and/or are
+ subject to passive attacks, it is necessary to ensure secure
+ interoperability by identifying a mandatory-to-implement mechanism
+ for establishing transport-layer security services.
+
+
+
+
+Harrison Standards Track [Page 5]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The set of security mechanisms provided in LDAP and described in this
+ document is intended to meet the security needs for a wide range of
+ deployment scenarios and still provide a high degree of
+ interoperability among various LDAP implementations and deployments.
+
+1.1. Relationship to Other Documents
+
+ This document is an integral part of the LDAP Technical Specification
+ [RFC4510].
+
+ This document, together with [RFC4510], [RFC4511], and [RFC4512],
+ obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and
+ 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
+ summarizes the substantive changes made to RFC 2251 by this document.
+
+ This document obsoletes RFC 2829 in its entirety. Appendix B.2
+ summarizes the substantive changes made to RFC 2829 by this document.
+
+ Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The
+ remainder of RFC 2830 is obsoleted by this document. Appendix B.3
+ summarizes the substantive changes made to RFC 2830 by this document.
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
+ "MAY", and "OPTIONAL" in this document are to be interpreted as
+ described in RFC 2119 [RFC2119].
+
+ The term "user" represents any human or application entity that is
+ accessing the directory using a directory client. A directory client
+ (or client) is also known as a directory user agent (DUA).
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message (PDU)
+ services used in providing directory services, as well as
+ associations established by these services.
+
+
+
+
+Harrison Standards Track [Page 6]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix A of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who are
+ unfamiliar with security-related concepts are encouraged to review
+ Appendix A before reading the remainder of this document.
+
+2. Implementation Requirements
+
+ LDAP server implementations MUST support the anonymous authentication
+ mechanism of the simple Bind method (Section 5.1.1).
+
+ LDAP implementations that support any authentication mechanism other
+ than the anonymous authentication mechanism of the simple Bind method
+ MUST support the name/password authentication mechanism of the simple
+ Bind method (Section 5.1.3) and MUST be capable of protecting this
+ name/password authentication using TLS as established by the StartTLS
+ operation (Section 3).
+
+ Implementations SHOULD disallow the use of the name/password
+ authentication mechanism by default when suitable data security
+ services are not in place, and they MAY provide other suitable data
+ security services for use with this authentication mechanism.
+
+ Implementations MAY support additional authentication mechanisms.
+ Some of these mechanisms are discussed below.
+
+ LDAP server implementations SHOULD support client assertion of
+ authorization identity via the SASL EXTERNAL mechanism (Section
+ 5.2.3).
+
+ LDAP server implementations that support no authentication mechanism
+ other than the anonymous mechanism of the simple bind method SHOULD
+ support use of TLS as established by the StartTLS operation (Section
+ 3). (Other servers MUST support TLS per the second paragraph of this
+ section.)
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 7]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Implementations supporting TLS MUST support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
+ latter ciphersuite is recommended to encourage interoperability with
+ implementations conforming to earlier LDAP StartTLS specifications.
+
+3. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ Section 4.14 of [RFC4511] provides the ability to establish TLS
+ [RFC4346] in an LDAP session.
+
+ The goals of using the TLS protocol with LDAP are to ensure data
+ confidentiality and integrity, and to optionally provide for
+ authentication. TLS expressly provides these capabilities, although
+ the authentication services of TLS are available to LDAP only in
+ combination with the SASL EXTERNAL authentication method (see Section
+ 5.2.3), and then only if the SASL EXTERNAL implementation chooses to
+ make use of the TLS credentials.
+
+3.1. TLS Establishment Procedures
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the TLS layer including discovery of
+ resultant security level and assertion of the client's authorization
+ identity.
+
+3.1.1. StartTLS Request Sequencing
+
+ A client may send the StartTLS extended request at any time after
+ establishing an LDAP session, except:
+
+ - when TLS is currently established on the session,
+ - when a multi-stage SASL negotiation is in progress on the
+ session, or
+ - when there are outstanding responses for operation requests
+ previously issued on the session.
+
+ As described in [RFC4511], Section 4.14.1, a (detected) violation of
+ any of these requirements results in a return of the operationsError
+ resultCode.
+
+ Client implementers should ensure that they strictly follow these
+ operation sequencing requirements to prevent interoperability issues.
+ Operational experience has shown that violating these requirements
+
+
+
+
+
+Harrison Standards Track [Page 8]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ causes interoperability issues because there are race conditions that
+ prevent servers from detecting some violations of these requirements
+ due to factors such as server hardware speed and network latencies.
+
+ There is no general requirement that the client have or have not
+ already performed a Bind operation (Section 5) before sending a
+ StartTLS operation request; however, where a client intends to
+ perform both a Bind operation and a StartTLS operation, it SHOULD
+ first perform the StartTLS operation so that the Bind request and
+ response messages are protected by the data security services
+ established by the StartTLS operation.
+
+3.1.2. Client Certificate
+
+ If an LDAP server requests or demands that a client provide a user
+ certificate during TLS negotiation and the client does not present a
+ suitable user certificate (e.g., one that can be validated), the
+ server may use a local security policy to determine whether to
+ successfully complete TLS negotiation.
+
+ If a client that has provided a suitable certificate subsequently
+ performs a Bind operation using the SASL EXTERNAL authentication
+ mechanism (Section 5.2.3), information in the certificate may be used
+ by the server to identify and authenticate the client.
+
+3.1.3. Server Identity Check
+
+ In order to prevent man-in-the-middle attacks, the client MUST verify
+ the server's identity (as presented in the server's Certificate
+ message). In this section, the client's understanding of the
+ server's identity (typically the identity used to establish the
+ transport connection) is called the "reference identity".
+
+ The client determines the type (e.g., DNS name or IP address) of the
+ reference identity and performs a comparison between the reference
+ identity and each subjectAltName value of the corresponding type
+ until a match is produced. Once a match is produced, the server's
+ identity has been verified, and the server identity check is
+ complete. Different subjectAltName types are matched in different
+ ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
+ various subjectAltName types.
+
+ The client may map the reference identity to a different type prior
+ to performing a comparison. Mappings may be performed for all
+ available subjectAltName types to which the reference identity can be
+ mapped; however, the reference identity should only be mapped to
+ types for which the mapping is either inherently secure (e.g.,
+ extracting the DNS name from a URI to compare with a subjectAltName
+
+
+
+Harrison Standards Track [Page 9]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ of type dNSName) or for which the mapping is performed in a secure
+ manner (e.g., using DNSSEC, or using user- or admin-configured host-
+ to-address/address-to-host lookup tables).
+
+ The server's identity may also be verified by comparing the reference
+ identity to the Common Name (CN) [RFC4519] value in the leaf Relative
+ Distinguished Name (RDN) of the subjectName field of the server's
+ certificate. This comparison is performed using the rules for
+ comparison of DNS names in Section 3.1.3.1, below, with the exception
+ that no wildcard matching is allowed. Although the use of the Common
+ Name value is existing practice, it is deprecated, and Certification
+ Authorities are encouraged to provide subjectAltName values instead.
+ Note that the TLS implementation may represent DNs in certificates
+ according to X.500 or other conventions. For example, some X.500
+ implementations order the RDNs in a DN using a left-to-right (most
+ significant to least significant) convention instead of LDAP's
+ right-to-left convention.
+
+ If the server identity check fails, user-oriented clients SHOULD
+ either notify the user (clients may give the user the opportunity to
+ continue with the LDAP session in this case) or close the transport
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the transport connection and then
+ return or log an error indicating that the server's identity is
+ suspect or both.
+
+ Beyond the server identity check described in this section, clients
+ should be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is requested to provide. The
+ client may need to make use of local policy information in making
+ this determination.
+
+3.1.3.1. Comparison of DNS Names
+
+ If the reference identity is an internationalized domain name,
+ conforming implementations MUST convert it to the ASCII Compatible
+ Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
+ before comparison with subjectAltName values of type dNSName.
+ Specifically, conforming implementations MUST perform the conversion
+ operation specified in Section 4 of RFC 3490 as follows:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string";
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+ * in step 4, process each label with the "ToASCII" operation; and
+ * in step 5, change all label separators to U+002E (full stop).
+
+
+
+
+
+Harrison Standards Track [Page 10]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ After performing the "to-ASCII" conversion, the DNS labels and names
+ MUST be compared for equality according to the rules specified in
+ Section 3 of RFC3490.
+
+ The '*' (ASCII 42) wildcard character is allowed in subjectAltName
+ values of type dNSName, and then only as the left-most (least
+ significant) DNS label in that value. This wildcard matches any
+ left-most DNS label in the server name. That is, the subject
+ *.example.com matches the server names a.example.com and
+ b.example.com, but does not match example.com or a.b.example.com.
+
+3.1.3.2. Comparison of IP Addresses
+
+ When the reference identity is an IP address, the identity MUST be
+ converted to the "network byte order" octet string representation
+ [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
+ octet string will contain exactly four octets. For IP Version 6, as
+ specified in RFC 2460, the octet string will contain exactly sixteen
+ octets. This octet string is then compared against subjectAltName
+ values of type iPAddress. A match occurs if the reference identity
+ octet string and value octet strings are identical.
+
+3.1.3.3. Comparison of Other subjectName Types
+
+ Client implementations MAY support matching against subjectAltName
+ values of other types as described in other documents.
+
+3.1.4. Discovery of Resultant Security Level
+
+ After a TLS layer is established in an LDAP session, both parties are
+ to each independently decide whether or not to continue based on
+ local policy and the security level achieved. If either party
+ decides that the security level is inadequate for it to continue, it
+ SHOULD remove the TLS layer immediately after the TLS (re)negotiation
+ has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
+ Implementations may reevaluate the security level at any time and,
+ upon finding it inadequate, should remove the TLS layer.
+
+3.1.5. Refresh of Server Capabilities Information
+
+ After a TLS layer is established in an LDAP session, the client
+ SHOULD discard or refresh all information about the server that it
+ obtained prior to the initiation of the TLS negotiation and that it
+ did not obtain through secure mechanisms. This protects against
+ man-in-the-middle attacks that may have altered any server
+ capabilities information retrieved prior to TLS layer installation.
+
+
+
+
+
+Harrison Standards Track [Page 11]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The server may advertise different capabilities after installing a
+ TLS layer. In particular, the value of 'supportedSASLMechanisms' may
+ be different after a TLS layer has been installed (specifically, the
+ EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
+ after a TLS layer has been installed).
+
+3.2. Effect of TLS on Authorization State
+
+ The establishment, change, and/or closure of TLS may cause the
+ authorization state to move to a new state. This is discussed
+ further in Section 4.
+
+3.3. TLS Ciphersuites
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the transport
+ connection. Client and server implementers should recognize
+ that some TLS ciphersuites provide no confidentiality
+ protection, while other ciphersuites that do provide
+ confidentiality protection may be vulnerable to being cracked
+ using brute force methods, especially in light of ever-
+ increasing CPU speeds that reduce the time needed to
+ successfully mount such attacks.
+
+ - Client and server implementers should carefully consider the
+ value of the password or data being protected versus the level
+ of confidentiality protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
+ - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger
+ of a man-in-the-middle attack is negligible.
+
+ - After a TLS negotiation (either initial or subsequent) is
+ completed, both protocol peers should independently verify that
+ the security services provided by the negotiated ciphersuite are
+ adequate for the intended use of the LDAP session. If they are
+ not, the TLS layer should be closed.
+
+
+
+
+
+
+Harrison Standards Track [Page 12]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+4. Authorization State
+
+ Every LDAP session has an associated authorization state. This state
+ is comprised of numerous factors such as what (if any) authentication
+ state has been established, how it was established, and what security
+ services are in place. Some factors may be determined and/or
+ affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
+ and some factors may be determined by external events (e.g., time of
+ day or server load).
+
+ While it is often convenient to view authorization state in
+ simplistic terms (as we often do in this technical specification)
+ such as "an anonymous state", it is noted that authorization systems
+ in LDAP implementations commonly involve many factors that
+ interrelate in complex manners.
+
+ Authorization in LDAP is a local matter. One of the key factors in
+ making authorization decisions is authorization identity. The Bind
+ operation (defined in Section 4.2 of [RFC4511] and discussed further
+ in Section 5 below) allows information to be exchanged between the
+ client and server to establish an authorization identity for the LDAP
+ session. The Bind operation may also be used to move the LDAP
+ session to an anonymous authorization state (see Section 5.1.1).
+
+ Upon initial establishment of the LDAP session, the session has an
+ anonymous authorization identity. Among other things this implies
+ that the client need not send a BindRequest in the first PDU of the
+ LDAP message layer. The client may send any operation request prior
+ to performing a Bind operation, and the server MUST treat it as if it
+ had been performed after an anonymous Bind operation (Section 5.1.1).
+
+ Upon receipt of a Bind request, the server immediately moves the
+ session to an anonymous authorization state. If the Bind request is
+ successful, the session is moved to the requested authentication
+ state with its associated authorization state. Otherwise, the
+ session remains in an anonymous state.
+
+ It is noted that other events both internal and external to LDAP may
+ result in the authentication and authorization states being moved to
+ an anonymous one. For instance, the establishment, change, or
+ closure of data security services may result in a move to an
+ anonymous state, or the user's credential information (e.g.,
+ certificate) may have expired. The former is an example of an event
+ internal to LDAP, whereas the latter is an example of an event
+ external to LDAP.
+
+
+
+
+
+
+Harrison Standards Track [Page 13]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5. Bind Operation
+
+ The Bind operation ([RFC4511], Section 4.2) allows authentication
+ information to be exchanged between the client and server to
+ establish a new authorization state.
+
+ The Bind request typically specifies the desired authentication
+ identity. Some Bind mechanisms also allow the client to specify the
+ authorization identity. If the authorization identity is not
+ specified, the server derives it from the authentication identity in
+ an implementation-specific manner.
+
+ If the authorization identity is specified, the server MUST verify
+ that the client's authentication identity is permitted to assume
+ (e.g., proxy for) the asserted authorization identity. The server
+ MUST reject the Bind operation with an invalidCredentials resultCode
+ in the Bind response if the client is not so authorized.
+
+5.1. Simple Authentication Method
+
+ The simple authentication method of the Bind Operation provides three
+ authentication mechanisms:
+
+ - An anonymous authentication mechanism (Section 5.1.1).
+
+ - An unauthenticated authentication mechanism (Section 5.1.2).
+
+ - A name/password authentication mechanism using credentials
+ consisting of a name (in the form of an LDAP distinguished name
+ [RFC4514]) and a password (Section 5.1.3).
+
+5.1.1. Anonymous Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the anonymous authentication mechanism of the
+ simple Bind method to explicitly establish an anonymous authorization
+ state by sending a Bind request with a name value of zero length and
+ specifying the simple authentication choice containing a password
+ value of zero length.
+
+5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the unauthenticated authentication mechanism
+ of the simple Bind method to establish an anonymous authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [RFC4514] of non-zero length) and specifying
+ the simple authentication choice containing a password value of zero
+ length.
+
+
+
+
+Harrison Standards Track [Page 14]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The distinguished name value provided by the client is intended to be
+ used for trace (e.g., logging) purposes only. The value is not to be
+ authenticated or otherwise validated (including verification that the
+ DN refers to an existing directory object). The value is not to be
+ used (directly or indirectly) for authorization purposes.
+
+ Unauthenticated Bind operations can have significant security issues
+ (see Section 6.3.1). In particular, users intending to perform
+ Name/Password Authentication may inadvertently provide an empty
+ password and thus cause poorly implemented clients to request
+ Unauthenticated access. Clients SHOULD be implemented to require
+ user selection of the Unauthenticated Authentication Mechanism by
+ means other than user input of an empty password. Clients SHOULD
+ disallow an empty password input to a Name/Password Authentication
+ user interface. Additionally, Servers SHOULD by default fail
+ Unauthenticated Bind requests with a resultCode of
+ unwillingToPerform.
+
+5.1.3. Name/Password Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the name/password authentication mechanism of
+ the simple Bind method to establish an authenticated authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [RFC4514] of non-zero length) and specifying
+ the simple authentication choice containing an OCTET STRING password
+ value of non-zero length.
+
+ Servers that map the DN sent in the Bind request to a directory entry
+ with an associated set of one or more passwords used with this
+ mechanism will compare the presented password to that set of
+ passwords. The presented password is considered valid if it matches
+ any member of this set.
+
+ A resultCode of invalidDNSyntax indicates that the DN sent in the
+ name value is syntactically invalid. A resultCode of
+ invalidCredentials indicates that the DN is syntactically correct but
+ not valid for purposes of authentication, that the password is not
+ valid for the DN, or that the server otherwise considers the
+ credentials invalid. A resultCode of success indicates that the
+ credentials are valid and that the server is willing to provide
+ service to the entity these credentials identify.
+
+ Server behavior is undefined for Bind requests specifying the
+ name/password authentication mechanism with a zero-length name value
+ and a password value of non-zero length.
+
+
+
+
+
+
+Harrison Standards Track [Page 15]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The name/password authentication mechanism of the simple Bind method
+ is not suitable for authentication in environments without
+ confidentiality protection.
+
+5.2. SASL Authentication Method
+
+ The sasl authentication method of the Bind Operation provides
+ facilities for using any SASL mechanism including authentication
+ mechanisms and other services (e.g., data security services).
+
+5.2.1. SASL Protocol Profile
+
+ LDAP allows authentication via any SASL mechanism [RFC4422]. As LDAP
+ includes native anonymous and name/password (plain text)
+ authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
+ SASL mechanisms are typically not used with LDAP.
+
+ Each protocol that utilizes SASL services is required to supply
+ certain information profiling the way they are exposed through the
+ protocol ([RFC4422], Section 4). This section explains how each of
+ these profiling requirements is met by LDAP.
+
+5.2.1.1. SASL Service Name for LDAP
+
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a SASL service name.
+
+5.2.1.2. SASL Authentication Initiation and Protocol Exchange
+
+ SASL authentication is initiated via a BindRequest message
+ ([RFC4511], Section 4.2) with the following parameters:
+
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ MAY be used to provide an initial client response for mechanisms
+ that are defined to have the client send data first (see
+ [RFC4422], Sections 3 and 5).
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+ which are specific to and defined by the SASL mechanism. Thus, for
+ some SASL authentication mechanisms, it may be necessary for the
+ client to respond to one or more server challenges by sending
+ BindRequest messages multiple times. A challenge is indicated by the
+ server sending a BindResponse message with the resultCode set to
+
+
+
+Harrison Standards Track [Page 16]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new BindRequest message with the same SASL mechanism
+ to continue the authentication process.
+
+ To the LDAP message layer, these challenges and responses are opaque
+ binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field (an OCTET STRING) in a BindResponse message to
+ transmit each challenge. LDAP clients use the credentials field (an
+ OCTET STRING) in the SaslCredentials sequence of a BindRequest
+ message to transmit each response. Note that unlike some Internet
+ protocols where SASL is used, LDAP is not text based and does not
+ Base64-transform these challenge and response values.
+
+ Clients sending a BindRequest message with the sasl choice selected
+ SHOULD send a zero-length value in the name field. Servers receiving
+ a BindRequest message with the sasl choice selected SHALL ignore any
+ value in the name field.
+
+ A client may abort a SASL Bind negotiation by sending a BindRequest
+ message with a different value in the mechanism field of
+ SaslCredentials or with an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with a resultCode
+ of authMethodNotSupported. This will allow the client to abort a
+ negotiation if it wishes to try again with the same SASL mechanism.
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a BindResponse in which the resultCode
+ value is not saslBindInProgress.
+
+ The serverSaslCreds field in the BindResponse can be used to include
+ an optional challenge with a success notification for mechanisms that
+ are defined to have the server send additional data along with the
+ indication of successful completion.
+
+5.2.1.3. Optional Fields
+
+ As discussed above, LDAP provides an optional field for carrying an
+ initial response in the message initiating the SASL exchange and
+ provides an optional field for carrying additional data in the
+ message indicating the outcome of the authentication exchange. As
+ the mechanism-specific content in these fields may be zero length,
+ SASL requires protocol specifications to detail how an empty field is
+ distinguished from an absent field.
+
+
+
+
+
+
+Harrison Standards Track [Page 17]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Zero-length initial response data is distinguished from no initial
+ response data in the initiating message, a BindRequest PDU, by the
+ presence of the SaslCredentials.credentials OCTET STRING (of length
+ zero) in that PDU. If the client does not intend to send an initial
+ response with the BindRequest initiating the SASL exchange, it MUST
+ omit the SaslCredentials.credentials OCTET STRING (rather than
+ include an zero-length OCTET STRING).
+
+ Zero-length additional data is distinguished from no additional
+ response data in the outcome message, a BindResponse PDU, by the
+ presence of the serverSaslCreds OCTET STRING (of length zero) in that
+ PDU. If a server does not intend to send additional data in the
+ BindResponse message indicating outcome of the exchange, the server
+ SHALL omit the serverSaslCreds OCTET STRING (rather than including a
+ zero-length OCTET STRING).
+
+5.2.1.4. Octet Where Negotiated Security Layers Take Effect
+
+ SASL layers take effect following the transmission by the server and
+ reception by the client of the final BindResponse in the SASL
+ exchange with a resultCode of success.
+
+ Once a SASL layer providing data integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e., at the first octet following the final
+ BindResponse of the Bind operation that caused the new layer to take
+ effect). Thus, an established SASL layer is not affected by a failed
+ or non-SASL Bind.
+
+5.2.1.5. Determination of Supported SASL Mechanisms
+
+ Clients may determine the SASL mechanisms a server supports by
+ reading the 'supportedSASLMechanisms' attribute from the root DSE
+ (DSA-Specific Entry) ([RFC4512], Section 5.1). The values of this
+ attribute, if any, list the mechanisms the server supports in the
+ current LDAP session state. LDAP servers SHOULD allow all clients --
+ even those with an anonymous authorization -- to retrieve the
+ 'supportedSASLMechanisms' attribute of the root DSE both before and
+ after the SASL authentication exchange. The purpose of the latter is
+ to allow the client to detect possible downgrade attacks (see Section
+ 6.4 and [RFC4422], Section 6.1.2).
+
+ Because SASL mechanisms provide critical security functions, clients
+ and servers should be configurable to specify what mechanisms are
+ acceptable and allow only those mechanisms to be used. Both clients
+ and servers must confirm that the negotiated security level meets
+ their requirements before proceeding to use the session.
+
+
+
+
+Harrison Standards Track [Page 18]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5.2.1.6. Rules for Using SASL Layers
+
+ Upon installing a SASL layer, the client SHOULD discard or refresh
+ all information about the server that it obtained prior to the
+ initiation of the SASL negotiation and that it did not obtain through
+ secure mechanisms.
+
+ If a lower-level security layer (such as TLS) is installed, any SASL
+ layer SHALL be layered on top of such security layers regardless of
+ the order of their negotiation. In all other respects, the SASL
+ layer and other security layers act independently, e.g., if both a
+ TLS layer and a SASL layer are in effect, then removing the TLS layer
+ does not affect the continuing service of the SASL layer.
+
+5.2.1.7. Support for Multiple Authentications
+
+ LDAP supports multiple SASL authentications as defined in [RFC4422],
+ Section 4.
+
+5.2.1.8. SASL Authorization Identities
+
+ Some SASL mechanisms allow clients to request a desired authorization
+ identity for the LDAP session ([RFC4422], Section 3.4). The decision
+ to allow or disallow the current authentication identity to have
+ access to the requested authorization identity is a matter of local
+ policy. The authorization identity is a string of UTF-8 [RFC3629]
+ encoded [Unicode] characters corresponding to the following Augmented
+ Backus-Naur Form (ABNF) [RFC4234] grammar:
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id
+ dnAuthzId = "dn:" distinguishedName
+
+ ; unspecified authorization id, UTF-8 encoded
+ uAuthzId = "u:" userid
+ userid = *UTF8 ; syntax unspecified
+
+ where the distinguishedName rule is defined in Section 3 of [RFC4514]
+ and the UTF8 rule is defined in Section 1.4 of [RFC4512].
+
+ The dnAuthzId choice is used to assert authorization identities in
+ the form of a distinguished name to be matched in accordance with the
+ distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
+ There is no requirement that the asserted distinguishedName value be
+ that of an entry in the directory.
+
+
+
+
+
+Harrison Standards Track [Page 19]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The uAuthzId choice allows clients to assert an authorization
+ identity that is not in distinguished name form. The format of
+ userid is defined only as a sequence of UTF-8 [RFC3629] encoded
+ [Unicode] characters, and any further interpretation is a local
+ matter. For example, the userid could identify a user of a specific
+ directory service, be a login name, or be an email address. A
+ uAuthzId SHOULD NOT be assumed to be globally unique. To compare
+ uAuthzId values, each uAuthzId value MUST be prepared as a "query"
+ string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
+ and then the two values are compared octet-wise.
+
+ The above grammar is extensible. The authzId production may be
+ extended to support additional forms of identities. Each form is
+ distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
+ registration requirements).
+
+5.2.2. SASL Semantics within LDAP
+
+ Implementers must take care to maintain the semantics of SASL
+ specifications when handling data that has different semantics in the
+ LDAP protocol.
+
+ For example, the SASL DIGEST-MD5 authentication mechanism
+ [DIGEST-MD5] utilizes an authentication identity and a realm that are
+ syntactically simple strings and semantically simple username
+ [RFC4013] and realm values. These values are not LDAP DNs, and there
+ is no requirement that they be represented or treated as such.
+
+5.2.3. SASL EXTERNAL Authentication Mechanism
+
+ A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
+ to request the LDAP server to authenticate and establish a resulting
+ authorization identity using security credentials exchanged by a
+ lower security layer (such as by TLS authentication). If the
+ client's authentication credentials have not been established at a
+ lower security layer, the SASL EXTERNAL Bind MUST fail with a
+ resultCode of inappropriateAuthentication. Although this situation
+ has the effect of leaving the LDAP session in an anonymous state
+ (Section 4), the state of any installed security layer is unaffected.
+
+ A client may either request that its authorization identity be
+ automatically derived from its authentication credentials exchanged
+ at a lower security layer, or it may explicitly provide a desired
+ authorization identity. The former is known as an implicit
+ assertion, and the latter as an explicit assertion.
+
+
+
+
+
+
+Harrison Standards Track [Page 20]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5.2.3.1. Implicit Assertion
+
+ An implicit authorization identity assertion is performed by invoking
+ a Bind request of the SASL form using the EXTERNAL mechanism name
+ that does not include the optional credentials field (found within
+ the SaslCredentials sequence in the BindRequest). The server will
+ derive the client's authorization identity from the authentication
+ identity supplied by a security layer (e.g., a public key certificate
+ used during TLS layer installation) according to local policy. The
+ underlying mechanics of how this is accomplished are implementation
+ specific.
+
+5.2.3.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by invoking
+ a Bind request of the SASL form using the EXTERNAL mechanism name
+ that includes the credentials field (found within the SaslCredentials
+ sequence in the BindRequest). The value of the credentials field (an
+ OCTET STRING) is the asserted authorization identity and MUST be
+ constructed as documented in Section 5.2.1.8.
+
+6. Security Considerations
+
+ Security issues are discussed throughout this document. The
+ unsurprising conclusion is that security is an integral and necessary
+ part of LDAP. This section discusses a number of LDAP-related
+ security considerations.
+
+6.1. General LDAP Security Considerations
+
+ LDAP itself provides no security or protection from accessing or
+ updating the directory by means other than through the LDAP protocol,
+ e.g., from inspection of server database files by database
+ administrators.
+
+ Sensitive data may be carried in almost any LDAP message, and its
+ disclosure may be subject to privacy laws or other legal regulation
+ in many countries. Implementers should take appropriate measures to
+ protect sensitive data from disclosure to unauthorized entities.
+
+ A session on which the client has not established data integrity and
+ privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
+ mechanism) is subject to man-in-the-middle attacks to view and modify
+ information in transit. Client and server implementers SHOULD take
+ measures to protect sensitive data in the LDAP session from these
+ attacks by using data protection services as discussed in this
+ document. Clients and servers should provide the ability to be
+ configured to require these protections. A resultCode of
+
+
+
+Harrison Standards Track [Page 21]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ confidentialityRequired indicates that the server requires
+ establishment of (stronger) data confidentiality protection in order
+ to perform the requested operation.
+
+ Access control should always be applied when reading sensitive
+ information or updating directory information.
+
+ Various security factors, including authentication and authorization
+ information and data security services may change during the course
+ of the LDAP session, or even during the performance of a particular
+ operation. Implementations should be robust in the handling of
+ changing security factors.
+
+6.2. StartTLS Security Considerations
+
+ All security gained via use of the StartTLS operation is gained by
+ the use of TLS itself. The StartTLS operation, on its own, does not
+ provide any additional security.
+
+ The level of security provided through the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, a man-in-the-
+ middle attacker can remove the StartTLS extended operation from the
+ 'supportedExtension' attribute of the root DSE. Both parties SHOULD
+ independently ascertain and consent to the security level achieved
+ once TLS is established and before beginning use of the TLS-
+ protected session. For example, the security level of the TLS layer
+ might have been negotiated down to plaintext.
+
+ Clients MUST either warn the user when the security level achieved
+ does not provide an acceptable level of data confidentiality and/or
+ data integrity protection, or be configurable to refuse to proceed
+ without an acceptable level of security.
+
+ As stated in Section 3.1.2, a server may use a local security policy
+ to determine whether to successfully complete TLS negotiation.
+ Information in the user's certificate that is originated or verified
+ by the certification authority should be used by the policy
+ administrator when configuring the identification and authorization
+ policy.
+
+ Server implementers SHOULD allow server administrators to elect
+ whether and when data confidentiality and integrity are required, as
+ well as elect whether authentication of the client during the TLS
+ handshake is required.
+
+ Implementers should be aware of and understand TLS security
+ considerations as discussed in the TLS specification [RFC4346].
+
+
+
+Harrison Standards Track [Page 22]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+6.3. Bind Operation Security Considerations
+
+ This section discusses several security considerations relevant to
+ LDAP authentication via the Bind operation.
+
+6.3.1. Unauthenticated Mechanism Security Considerations
+
+ Operational experience shows that clients can (and frequently do)
+ misuse the unauthenticated authentication mechanism of the simple
+ Bind method (see Section 5.1.2). For example, a client program might
+ make a decision to grant access to non-directory information on the
+ basis of successfully completing a Bind operation. LDAP server
+ implementations may return a success response to an unauthenticated
+ Bind request. This may erroneously leave the client with the
+ impression that the server has successfully authenticated the
+ identity represented by the distinguished name when in reality, an
+ anonymous authorization state has been established. Clients that use
+ the results from a simple Bind operation to make authorization
+ decisions should actively detect unauthenticated Bind requests (by
+ verifying that the supplied password is not empty) and react
+ appropriately.
+
+6.3.2. Name/Password Mechanism Security Considerations
+
+ The name/password authentication mechanism of the simple Bind method
+ discloses the password to the server, which is an inherent security
+ risk. There are other mechanisms, such as SASL DIGEST-MD5
+ [DIGEST-MD5], that do not disclose the password to the server.
+
+6.3.3. Password-Related Security Considerations
+
+ LDAP allows multi-valued password attributes. In systems where
+ entries are expected to have one and only one password,
+ administrative controls should be provided to enforce this behavior.
+
+ The use of clear text passwords and other unprotected authentication
+ credentials is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality. LDAP
+ implementations SHOULD NOT by default support authentication methods
+ using clear text passwords and other unprotected authentication
+ credentials unless the data on the session is protected using TLS or
+ other data confidentiality and data integrity protection.
+
+ The transmission of passwords in the clear -- typically for
+ authentication or modification -- poses a significant security risk.
+ This risk can be avoided by using SASL authentication [RFC4422]
+
+
+
+
+
+Harrison Standards Track [Page 23]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ mechanisms that do not transmit passwords in the clear or by
+ negotiating transport or session layer data confidentiality services
+ before transmitting password values.
+
+ To mitigate the security risks associated with the transfer of
+ passwords, a server implementation that supports any password-based
+ authentication mechanism that transmits passwords in the clear MUST
+ support a policy mechanism that at the time of authentication or
+ password modification, requires that:
+
+ A TLS layer has been successfully installed.
+
+ OR
+
+ Some other data confidentiality mechanism that protects the
+ password value from eavesdropping has been provided.
+
+ OR
+
+ The server returns a resultCode of confidentialityRequired for
+ the operation (i.e., name/password Bind with password value,
+ SASL Bind transmitting a password value in the clear, add or
+ modify including a userPassword value, etc.), even if the
+ password value is correct.
+
+ Server implementations may also want to provide policy mechanisms to
+ invalidate or otherwise protect accounts in situations where a server
+ detects that a password for an account has been transmitted in the
+ clear.
+
+6.3.4. Hashed Password Security Considerations
+
+ Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
+ the password value that may be vulnerable to offline dictionary
+ attacks. Implementers should take care to protect such hashed
+ password values during transmission using TLS or other
+ confidentiality mechanisms.
+
+6.4. SASL Security Considerations
+
+ Until data integrity service is installed on an LDAP session, an
+ attacker can modify the transmitted values of the
+ 'supportedSASLMechanisms' attribute response and thus downgrade the
+ list of available SASL mechanisms to include only the least secure
+ mechanism. To detect this type of attack, the client may retrieve
+ the SASL mechanisms the server makes available both before and after
+ data integrity service is installed on an LDAP session. If the
+ client finds that the integrity-protected list (the list obtained
+
+
+
+Harrison Standards Track [Page 24]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ after data integrity service was installed) contains a stronger
+ mechanism than those in the previously obtained list, the client
+ should assume the previously obtained list was modified by an
+ attacker. In this circumstance it is recommended that the client
+ close the underlying transport connection and then reconnect to
+ reestablish the session.
+
+6.5. Related Security Considerations
+
+ Additional security considerations relating to the various
+ authentication methods and mechanisms discussed in this document
+ apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
+ [RFC3629].
+
+7. IANA Considerations
+
+ The IANA has updated the LDAP Protocol Mechanism registry to indicate
+ that this document and [RFC4511] provide the definitive technical
+ specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
+ operation.
+
+ The IANA has updated the LDAP LDAPMessage types registry to indicate
+ that this document and [RFC4511] provide the definitive technical
+ specification for the bindRequest (0) and bindResponse (1) message
+ types.
+
+ The IANA has updated the LDAP Bind Authentication Method registry to
+ indicate that this document and [RFC4511] provide the definitive
+ technical specification for the simple (0) and sasl (3) bind
+ authentication methods.
+
+ The IANA has updated the LDAP authzid prefixes registry to indicate
+ that this document provides the definitive technical specification
+ for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
+
+8. Acknowledgements
+
+ This document combines information originally contained in RFC 2251,
+ RFC 2829, and RFC 2830. RFC 2251 was a product of the Access,
+ Searching, and Indexing of Directories (ASID) Working Group. RFC
+ 2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
+ Working Group.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ working group.
+
+
+
+
+
+
+Harrison Standards Track [Page 25]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+9. Normative References
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", RFC 4346, March 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+Harrison Standards Track [Page 26]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-
+ 5), as amended by the "Unicode Standard Annex #27:
+ Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
+ by the "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+10. Informative References
+
+ [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", Work in Progress,
+ March 2006.
+
+ [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
+ Progress, March 2005.
+
+ [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
+ 2828, May 2000.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
+ June 2006.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 27]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Appendix A. Authentication and Authorization Concepts
+
+ This appendix is non-normative.
+
+ This appendix defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security approaches
+ are utilized in client authentication and authorization.
+
+A.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection of
+ resources, generally in terms of the capabilities of persons or other
+ entities accessing those resources. Security objects and mechanisms,
+ such as those described here, enable the expression of access control
+ policies and their enforcement.
+
+A.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors. The server uses
+ these factors to determine whether and how to process the request.
+ These are called access control factors (ACFs). They might include
+ source IP address, encryption strength, the type of operation being
+ requested, time of day, etc.. Some factors may be specific to the
+ request itself; others may be associated with the transport
+ connection via which the request is transmitted; and others (e.g.,
+ time of day) may be "environmental".
+
+ Access control policies are expressed in terms of access control
+ factors; for example, "a request having ACFs i,j,k can perform
+ operation Y on resource Z". The set of ACFs that a server makes
+ available for such expressions is implementation specific.
+
+A.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g., a user)
+ who is attempting to establish a new authorization state with the
+ other party (typically a server). Authentication is the process of
+ generating, transmitting, and verifying these credentials and thus
+ the identity they assert. An authentication identity is the name
+ presented in a credential.
+
+ There are many forms of authentication credentials. The form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. X.509 certificates, Kerberos tickets, and simple
+ identity and password pairs are all examples of authentication
+
+
+
+Harrison Standards Track [Page 28]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ credential forms. Note that an authentication mechanism may
+ constrain the form of authentication identities used with it.
+
+A.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that operations
+ be performed. Access control policies are often expressed in terms
+ of authorization identities; for example, "entity X can perform
+ operation Y on resource Z".
+
+ The authorization identity of an LDAP session is often semantically
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an authorization
+ identity distinct from the authentication identity asserted by the
+ client's credentials. This permits agents such as proxy servers to
+ authenticate using their own credentials, yet request the access
+ privileges of the identity for which they are proxying [RFC4422].
+ Also, the form of authentication identity supplied by a service like
+ TLS may not correspond to the authorization identities used to
+ express a server's access control policy, thus requiring a server-
+ specific mapping to be done. The method by which a server composes
+ and validates an authorization identity from the authentication
+ credentials supplied by a client is implementation specific.
+
+Appendix B. Summary of Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2829 and RFC 2830. In addition to the specific changes detailed
+ below, the reader of this document should be aware that numerous
+ general editorial changes have been made to the original content from
+ the source documents. These changes include the following:
+
+ - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
+ RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
+ combined into a single document.
+
+ - The combined material was substantially reorganized and edited to
+ group related subjects, improve the document flow, and clarify
+ intent.
+
+ - Changes were made throughout the text to align with definitions of
+ LDAP protocol layers and IETF security terminology.
+
+
+
+
+
+
+Harrison Standards Track [Page 29]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ - Substantial updates and additions were made to security
+ considerations from both documents based on current operational
+ experience.
+
+B.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to Sections
+ 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive
+ changes to Section 4.2.1 of RFC 2251 are also documented in
+ [RFC4511].
+
+B.1.1. Section 4.2.1 ("Sequencing of the Bind Request")
+
+ - Paragraph 1: Removed the sentence, "If at any stage the client
+ wishes to abort the bind process it MAY unbind and then drop the
+ underlying connection". The Unbind operation still permits this
+ behavior, but it is not documented explicitly.
+
+ - Clarified that the session is moved to an anonymous state upon
+ receipt of the BindRequest PDU and that it is only moved to a non-
+ anonymous state if and when the Bind request is successful.
+
+B.1.2. Section 4.2.2 ("Authentication and Other Security Services")
+
+ - RFC 2251 states that anonymous authentication MUST be performed
+ using the simple bind method. This specification defines the
+ anonymous authentication mechanism of the simple bind method and
+ requires all conforming implementations to support it. Other
+ authentication mechanisms producing anonymous authentication and
+ authorization state may also be implemented and used by conforming
+ implementations.
+
+B.2. Changes Made to RFC 2829
+
+ This section summarizes the substantive changes made to RFC 2829.
+
+B.2.1. Section 4 ("Required security mechanisms")
+
+ - The name/password authentication mechanism (see Section B.2.5
+ below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
+ LDAP's mandatory-to-implement password-based authentication
+ mechanism. Implementations are encouraged to continue supporting
+ SASL DIGEST-MD5 [DIGEST-MD5].
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 30]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.2.2. Section 5.1 ("Anonymous authentication procedure")
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle simple
+ Bind requests involving a name value with a non-zero length and a
+ password value of zero length.
+
+B.2.3. Section 6 ("Password-based authentication")
+
+ - See Section B.2.1.
+
+B.2.4. Section 6.1 ("Digest authentication")
+
+ - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
+ implement, this section is now historical and was not included in
+ this document. RFC 2829, Section 6.1, continues to document the
+ SASL DIGEST-MD5 authentication mechanism.
+
+B.2.5. Section 6.2 ("'simple' authentication choice under TLS
+ encryption")
+
+ - Renamed the "simple" authentication mechanism to the name/password
+ authentication mechanism to better describe it.
+
+ - The use of TLS was generalized to align with definitions of LDAP
+ protocol layers. TLS establishment is now discussed as an
+ independent subject and is generalized for use with all
+ authentication mechanisms and other security layers.
+
+ - Removed the implication that the userPassword attribute is the sole
+ location for storage of password values to be used in
+ authentication. There is no longer any implied requirement for how
+ or where passwords are stored at the server for use in
+ authentication.
+
+B.2.6. Section 6.3 ("Other authentication choices with TLS")
+
+ - See Section B.2.5.
+
+B.2.7. Section 7.1 ("Certificate-based authentication with TLS")
+
+ - See Section B.2.5.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 31]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.2.8. Section 8 ("Other mechanisms")
+
+ - All SASL authentication mechanisms are explicitly allowed within
+ LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
+ mechanisms are no longer precluded from use within LDAP.
+
+B.2.9. Section 9 ("Authorization Identity")
+
+ - Specified matching rules for dnAuthzId and uAuthzId values. In
+ particular, the DN value in the dnAuthzId form must be matched
+ using DN matching rules, and the uAuthzId value MUST be prepared
+ using SASLprep rules before being compared octet-wise.
+
+ - Clarified that uAuthzId values should not be assumed to be globally
+ unique.
+
+B.2.10. Section 10 ("TLS Ciphersuites")
+
+ - TLS ciphersuite recommendations are no longer included in this
+ specification. Implementations must now support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
+ support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle simple
+ Bind requests involving a name value with a non-zero length and a
+ password value of zero length.
+
+B.3. Changes Made to RFC 2830
+
+ This section summarizes the substantive changes made to Sections 3
+ and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of
+ changes to other sections.
+
+B.3.1. Section 3.6 ("Server Identity Check")
+
+ - Substantially updated the server identity check algorithm to ensure
+ that it is complete and robust. In particular, the use of all
+ relevant values in the subjectAltName and the subjectName fields
+ are covered by the algorithm and matching rules are specified for
+ each type of value. Mapped (derived) forms of the server identity
+ may now be used when the mapping is performed in a secure fashion.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 32]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.3.2. Section 3.7 ("Refresh of Server Capabilities Information")
+
+ - Clients are no longer required to always refresh information about
+ server capabilities following TLS establishment. This is to allow
+ for situations where this information was obtained through a secure
+ mechanism.
+
+B.3.3. Section 5 ("Effects of TLS on a Client's Authorization
+ Identity")
+
+ - Establishing a TLS layer on an LDAP session may now cause the
+ authorization state of the LDAP session to change.
+
+B.3.4. Section 5.2 ("TLS Connection Closure Effects")
+
+ - Closing a TLS layer on an LDAP session changes the authentication
+ and authorization state of the LDAP session based on local policy.
+ Specifically, this means that implementations are not required to
+ change the authentication and authorization states to anonymous
+ upon TLS closure.
+
+ - Replaced references to RFC 2401 with RFC 4301.
+
+Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ USA
+
+ Phone: +1 801 861 2642
+ EMail: roger_harrison@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 33]
+\f
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison Standards Track [Page 34]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4514 OpenLDAP Foundation
+Obsoletes: 2253 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The X.500 Directory uses distinguished names (DNs) as primary keys to
+ entries in the directory. This document defines the string
+ representation used in the Lightweight Directory Access Protocol
+ (LDAP) to transfer distinguished names. The string representation is
+ designed to give a clean representation of commonly used
+ distinguished names, while being able to represent any distinguished
+ name.
+
+1. Background and Intended Usage
+
+ In X.500-based directory systems [X.500], including those accessed
+ using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
+ distinguished names (DNs) are used to unambiguously refer to
+ directory entries [X.501][RFC4512].
+
+ The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+ In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+ directory protocols), DNs are encoded using the Basic Encoding Rules
+ (BER) [X.690]. In LDAP, DNs are represented in the string form
+ described in this document.
+
+ It is important to have a common format to be able to unambiguously
+ represent a distinguished name. The primary goal of this
+ specification is ease of encoding and decoding. A secondary goal is
+ to have names that are human readable. It is not expected that LDAP
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ implementations with a human user interface would display these
+ strings directly to the user, but that they would most likely be
+ performing translations (such as expressing attribute type names in
+ the local national language).
+
+ This document defines the string representation of Distinguished
+ Names used in LDAP [RFC4511][RFC4517]. Section 2 details the
+ RECOMMENDED algorithm for converting a DN from its ASN.1 structured
+ representation to a string. Section 3 details how to convert a DN
+ from a string to an ASN.1 structured representation.
+
+ While other documents may define other algorithms for converting a DN
+ from its ASN.1 structured representation to a string, all algorithms
+ MUST produce strings that adhere to the requirements of Section 3.
+
+ This document does not define a canonical string representation for
+ DNs. Comparison of DNs for equality is to be performed in accordance
+ with the distinguishedNameMatch matching rule [RFC4517].
+
+ This document is a integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety. This document obsoletes
+ RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
+
+ This specification assumes familiarity with X.500 [X.500] and the
+ concept of Distinguished Name [X.501][RFC4512].
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+ name. The following is a variant provided for discussion purposes.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ This section defines the RECOMMENDED algorithm for converting a
+ distinguished name from an ASN.1-structured representation to a UTF-8
+ [RFC3629] encoded Unicode [Unicode] character string representation.
+ Other documents may describe other algorithms for converting a
+ distinguished name to a string, but only strings that conform to the
+ grammar defined in Section 3 SHALL be produced by LDAP
+ implementations.
+
+2.1. Converting the RDNSequence
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero-length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to Section
+ 2.2), starting with the last element of the sequence and moving
+ backwards toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated
+ by a comma (',' U+002C) character.
+
+2.2. Converting RelativeDistinguishedName
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to Section 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
+ character.
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals sign ('=' U+003D) character,
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in Section 2.4.
+
+ If the AttributeType is defined to have a short name (descriptor)
+ [RFC4512] and that short name is known to be registered [REGISTRY]
+ [RFC4520] as identifying the AttributeType, that short name, a
+ <descr>, is used. Otherwise the AttributeType is encoded as the
+ dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+ The <descr> and <numericoid> are defined in [RFC4512].
+
+ Implementations are not expected to dynamically update their
+ knowledge of registered short names. However, implementations SHOULD
+ provide a mechanism to allow their knowledge of registered short
+ names to be updated.
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeType is of the dotted-decimal form, the
+ AttributeValue is represented by an number sign ('#' U+0023)
+ character followed by the hexadecimal encoding of each of the octets
+ of the BER encoding of the X.500 AttributeValue. This form is also
+ used when the syntax of the AttributeValue does not have an LDAP-
+ specific ([RFC4517], Section 3.1) string encoding defined for it, or
+ the LDAP-specific string encoding is not restricted to UTF-8-encoded
+ Unicode characters. This form may also be used in other cases, such
+ as when a reversible string representation is desired (see Section
+ 5.2).
+
+ Otherwise, if the AttributeValue is of a syntax that has a LDAP-
+ specific string encoding, the value is converted first to a UTF-8-
+ encoded Unicode string according to its syntax specification (see
+ [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode
+ string does not have any of the following characters that need
+ escaping, then that string can be used as the string representation
+ of the value.
+
+ - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
+ the beginning of the string;
+
+ - a space (' ' U+0020) character occurring at the end of the
+ string;
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ - one of the characters '"', '+', ',', ';', '<', '>', or '\'
+ (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
+ respectively);
+
+ - the null (U+0000) character.
+
+ Other characters may be escaped.
+
+ Each octet of the character to be escaped is replaced by a backslash
+ and two hex digits, which form a single octet in the code of the
+ character. Alternatively, if and only if the character to be escaped
+ is one of
+
+ ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
+ (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+ U+003C, U+003D, U+003E, U+005C, respectively)
+
+ it can be prefixed by a backslash ('\' U+005C).
+
+ Examples of the escaping mechanism are shown in Section 4.
+
+3. Parsing a String Back to a Distinguished Name
+
+ The string representation of Distinguished Names is restricted to
+ UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
+ of this string representation is specified using the following
+ Augmented BNF [RFC4234] grammar:
+
+ distinguishedName = [ relativeDistinguishedName
+ *( COMMA relativeDistinguishedName ) ]
+ relativeDistinguishedName = attributeTypeAndValue
+ *( PLUS attributeTypeAndValue )
+ attributeTypeAndValue = attributeType EQUALS attributeValue
+ attributeType = descr / numericoid
+ attributeValue = string / hexstring
+
+ ; The following characters are to be escaped when they appear
+ ; in the value to be encoded: ESC, one of <escaped>, leading
+ ; SHARP or SPACE, trailing SPACE, and NULL.
+ string = [ ( leadchar / pair ) [ *( stringchar / pair )
+ ( trailchar / pair ) ] ]
+
+ leadchar = LUTF1 / UTFMB
+ LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ trailchar = TUTF1 / UTFMB
+ TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ %x3D / %x3F-5B / %x5D-7F
+
+ stringchar = SUTF1 / UTFMB
+ SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ pair = ESC ( ESC / special / hexpair )
+ special = escaped / SPACE / SHARP / EQUALS
+ escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+ hexstring = SHARP 1*hexpair
+ hexpair = HEX HEX
+
+ where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+ <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+ <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
+
+ Each <attributeType>, either a <descr> or a <numericoid>, refers to
+ an attribute type of an attribute value assertion (AVA). The
+ <attributeType> is followed by an <EQUALS> and an <attributeValue>.
+ The <attributeValue> is either in <string> or <hexstring> form.
+
+ If in <string> form, a LDAP string representation asserted value can
+ be obtained by replacing (left to right, non-recursively) each <pair>
+ appearing in the <string> as follows:
+
+ replace <ESC><ESC> with <ESC>;
+ replace <ESC><special> with <special>;
+ replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+ If in <hexstring> form, a BER representation can be obtained from
+ converting each <hexpair> of the <hexstring> to the octet indicated
+ by the <hexpair>.
+
+ There is one or more attribute value assertions, separated by <PLUS>,
+ for a relative distinguished name.
+
+ There is zero or more relative distinguished names, separated by
+ <COMMA>, for a distinguished name.
+
+ Implementations MUST recognize AttributeType name strings
+ (descriptors) listed in the following table, but MAY recognize other
+ name strings.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ String X.500 AttributeType
+ ------ --------------------------------------------
+ CN commonName (2.5.4.3)
+ L localityName (2.5.4.7)
+ ST stateOrProvinceName (2.5.4.8)
+ O organizationName (2.5.4.10)
+ OU organizationalUnitName (2.5.4.11)
+ C countryName (2.5.4.6)
+ STREET streetAddress (2.5.4.9)
+ DC domainComponent (0.9.2342.19200300.100.1.25)
+ UID userId (0.9.2342.19200300.100.1.1)
+
+ These attribute types are described in [RFC4519].
+
+ Implementations MAY recognize other DN string representations.
+ However, as there is no requirement that alternative DN string
+ representations be recognized (and, if so, how), implementations
+ SHOULD only generate DN strings in accordance with Section 2 of this
+ document.
+
+4. Examples
+
+ This notation is designed to be convenient for common forms of name.
+ This section gives a few examples of distinguished names written
+ using this notation. First is a name containing three relative
+ distinguished names (RDNs):
+
+ UID=jsmith,DC=example,DC=net
+
+ Here is an example of a name containing three RDNs, in which the
+ first RDN is multi-valued:
+
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+
+ This example shows the method of escaping of a special characters
+ appearing in a common name:
+
+ CN=James \"Jim\" Smith\, III,DC=example,DC=net
+
+ The following shows the method for encoding a value that contains a
+ carriage return character:
+
+ CN=Before\0dAfter,DC=example,DC=net
+
+ In this RDN example, the type in the RDN is unrecognized, and the
+ value is the BER encoding of an OCTET STRING containing two octets,
+ 0x48 and 0x69.
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ 1.3.6.1.4.1.1466.0=#04024869
+
+ Finally, this example shows an RDN whose commonName value consists of
+ 5 letters:
+
+ Unicode Character Code UTF-8 Escaped
+ ------------------------------- ------ ------ --------
+ LATIN CAPITAL LETTER L U+004C 0x4C L
+ LATIN SMALL LETTER U U+0075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U+0069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
+
+ This could be encoded in printable ASCII [ASCII] (useful for
+ debugging purposes) as:
+
+ CN=Lu\C4\8Di\C4\87
+
+5. Security Considerations
+
+ The following security considerations are specific to the handling of
+ distinguished names. LDAP security considerations are discussed in
+ [RFC4511] and other documents comprising the LDAP Technical
+ Specification [RFC4510].
+
+5.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information
+ about the entries they name, which can be people, organizations,
+ devices, or other real-world objects. This frequently includes some
+ of the following kinds of information:
+
+ - the common name of the object (i.e., a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or
+ affiliation)
+
+ In some cases, such information can be considered sensitive. In many
+ countries, privacy laws exist that prohibit disclosure of certain
+ kinds of descriptive information (e.g., email addresses). Hence,
+ server implementers are encouraged to support Directory Information
+ Tree (DIT) structural rules and name forms [RFC4512], as these
+ provide a mechanism for administrators to select appropriate naming
+ attributes for entries. Administrators are encouraged to use
+ mechanisms, access controls, and other administrative controls that
+ may be available to restrict use of attributes containing sensitive
+ information in naming of entries. Additionally, use of
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ authentication and data security services in LDAP [RFC4513][RFC4511]
+ should be considered.
+
+5.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
+ form. An example of a situation that requires the DER form of a
+ distinguished name is the verification of an X.509 certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam', would be represented in LDAP as the
+ string <CN=Sam>. Another distinguished name in which the value is
+ still 'Sam', but is of the PrintableString choice, would have the
+ same representation <CN=Sam>.
+
+ Applications that require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the number sign ('#'
+ U+0023) as described in the first paragraph of Section 2.4.
+
+6. Acknowledgements
+
+ This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+ Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+7. References
+
+7.1. Normative References
+
+ [REGISTRY] IANA, Object Identifier Descriptors Registry,
+ <http://www.iana.org/assignments/ldap-parameters>.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+7.2. Informative References
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(1997) (also
+ ISO/IEC 8825-1:1998).
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+Appendix A. Presentation Issues
+
+ This appendix is provided for informational purposes only; it is not
+ a normative part of this specification.
+
+ The string representation described in this document is not intended
+ to be presented to humans without translation. However, at times it
+ may be desirable to present non-translated DN strings to users. This
+ section discusses presentation issues associated with non-translated
+ DN strings. Issues with presentation of translated DN strings are
+ not discussed in this appendix. Transcoding issues are also not
+ discussed in this appendix.
+
+ This appendix provides guidance for applications presenting DN
+ strings to users. This section is not comprehensive; it does not
+ discuss all presentation issues that implementers may face.
+
+ Not all user interfaces are capable of displaying the full set of
+ Unicode characters. Some Unicode characters are not displayable.
+
+ It is recommended that human interfaces use the optional hex pair
+ escaping mechanism (Section 2.3) to produce a string representation
+ suitable for display to the user. For example, an application can
+ generate a DN string for display that escapes all non-printable
+ characters appearing in the AttributeValue's string representation
+ (as demonstrated in the final example of Section 4).
+
+ When a DN string is displayed in free-form text, it is often
+ necessary to distinguish the DN string from surrounding text. While
+ this is often done with whitespace (as demonstrated in Section 4), it
+ is noted that DN strings may end with whitespace. Careful readers of
+ Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
+ may only appear in the DN string if escaped. These characters are
+ intended to be used in free-form text to distinguish a DN string from
+ surrounding text. For example, <CN=Sam\ > distinguishes the string
+ representation of the DN composed of one RDN consisting of the AVA
+ (the commonName (CN) value 'Sam ') from the surrounding text. It
+ should be noted to the user that the wrapping '<' and '>' characters
+ are not part of the DN string.
+
+ DN strings can be quite long. It is often desirable to line-wrap
+ overly long DN strings in presentations. Line wrapping should be
+ done by inserting whitespace after the RDN separator character or, if
+ necessary, after the AVA separator character. It should be noted to
+ the user that the inserted whitespace is not part of the DN string
+ and is to be removed before use in LDAP. For example, the following
+ DN string is long:
+
+
+
+
+Zeilenga Standards Track [Page 12]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+
+ So it has been line-wrapped for readability. The extra whitespace is
+ to be removed before the DN string is used in LDAP.
+
+ Inserting whitespace is not advised because it may not be obvious to
+ the user which whitespace is part of the DN string and which
+ whitespace was added for readability.
+
+ Another alternative is to use the LDAP Data Interchange Format (LDIF)
+ [RFC2849]. For example:
+
+ # This entry has a long DN...
+ dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ CN: Kurt D. Zeilenga
+ SN: Zeilenga
+ objectClass: person
+
+Appendix B. Changes Made since RFC 2253
+
+ This appendix is provided for informational purposes only, it is not
+ a normative part of this specification.
+
+ The following substantive changes were made to RFC 2253:
+
+ - Removed IESG Note. The IESG Note has been addressed.
+ - Replaced all references to ISO 10646-1 with [Unicode].
+ - Clarified (in Section 1) that this document does not define a
+ canonical string representation.
+ - Clarified that Section 2 describes the RECOMMENDED encoding
+ algorithm and that alternative algorithms are allowed. Some
+ encoding options described in RFC 2253 are now treated as
+ alternative algorithms in this specification.
+ - Revised specification (in Section 2) to allow short names of any
+ registered attribute type to appear in string representations of
+ DNs instead of being restricted to a "published table". Removed
+ "as an example" language. Added statement (in Section 3)
+ allowing recognition of additional names but require recognition
+ of those names in the published table. The table now appears in
+ Section 3.
+ - Removed specification of additional requirements for LDAPv2
+ implementations which also support LDAPv3 (RFC 2253, Section 4)
+ as LDAPv2 is now Historic.
+ - Allowed recognition of alternative string representations.
+ - Updated Section 2.4 to allow hex pair escaping of all characters
+ and clarified escaping for when multiple octet UTF-8 encodings
+
+
+
+Zeilenga Standards Track [Page 13]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ are present. Indicated that null (U+0000) character is to be
+ escaped. Indicated that equals sign ('=' U+003D) character may
+ be escaped as '\='.
+ - Rewrote Section 3 to use ABNF as defined in RFC 4234.
+ - Updated the Section 3 ABNF. Changes include:
+ + allowed AttributeType short names of length 1 (e.g., 'L'),
+ + used more restrictive <oid> production in AttributeTypes,
+ + did not require escaping of equals sign ('=' U+003D)
+ characters,
+ + did not require escaping of non-leading number sign ('#'
+ U+0023) characters,
+ + allowed space (' ' U+0020) to be escaped as '\ ',
+ + required hex escaping of null (U+0000) characters, and
+ + removed LDAPv2-only constructs.
+ - Updated Section 3 to describe how to parse elements of the
+ grammar.
+ - Rewrote examples.
+ - Added reference to documentations containing general LDAP
+ security considerations.
+ - Added discussion of presentation issues (Appendix A).
+ - Added this appendix.
+
+ In addition, numerous editorial changes were made.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+\f
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 15]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Smith, Ed.
+Request for Comments: 4515 Pearl Crescent, LLC
+Obsoletes: 2254 T. Howes
+Category: Standards Track Opsware, Inc.
+ June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ String Representation of Search Filters
+
+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 (2006).
+
+Abstract
+
+ Lightweight Directory Access Protocol (LDAP) search filters are
+ transmitted in the LDAP protocol using a binary representation that
+ is appropriate for use on the network. This document defines a
+ human-readable string representation of LDAP search filters that is
+ appropriate for use in LDAP URLs (RFC 4516) and in other
+ applications.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. LDAP Search Filter Definition ...................................2
+ 3. String Search Filter Definition .................................3
+ 4. Examples ........................................................5
+ 5. Security Considerations .........................................7
+ 6. Normative References ............................................7
+ 7. Informative References ..........................................8
+ 8. Acknowledgements ................................................8
+ Appendix A: Changes Since RFC 2254 .................................9
+ A.1. Technical Changes ..........................................9
+ A.2. Editorial Changes ..........................................9
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 1]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
+ network representation of a search filter transmitted to an LDAP
+ server. Some applications may find it useful to have a common way of
+ representing these search filters in a human-readable form; LDAP URLs
+ [RFC4516] are an example of one such application. This document
+ defines a human-readable string format for representing the full
+ range of possible LDAP version 3 search filters, including extended
+ match filters.
+
+ This document is a integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document replaces RFC 2254. Changes to RFC 2254 are summarized
+ in Appendix A.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. LDAP Search Filter Definition
+
+ An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
+ follows:
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- initial and final can occur at most once
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+
+
+
+
+Smith and Howes Standards Track [Page 2]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [RFC4512]
+
+ AttributeValue ::= OCTET STRING
+
+ MatchingRuleId ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [Unicode] characters
+
+ The AttributeDescription, as defined in [RFC4511], is a string
+ representation of the attribute description that is discussed in
+ [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have
+ the form defined in [RFC4517]. The Filter is encoded for
+ transmission over a network using the Basic Encoding Rules (BER)
+ defined in [X.690], with simplifications described in [RFC4511].
+
+3. String Search Filter Definition
+
+ The string representation of an LDAP search filter is a string of
+ UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
+ by the following grammar, following the ABNF notation defined in
+ [RFC4234]. The productions used that are not defined here are
+ defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
+ otherwise noted. The filter format uses a prefix notation.
+
+ filter = LPAREN filtercomp RPAREN
+ filtercomp = and / or / not / item
+ and = AMPERSAND filterlist
+ or = VERTBAR filterlist
+ not = EXCLAMATION filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype assertionvalue
+ filtertype = equal / approx / greaterorequal / lessorequal
+
+
+
+Smith and Howes Standards Track [Page 3]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ equal = EQUALS
+ approx = TILDE EQUALS
+ greaterorequal = RANGLE EQUALS
+ lessorequal = LANGLE EQUALS
+ extensible = ( attr [dnattrs]
+ [matchingrule] COLON EQUALS assertionvalue )
+ / ( [dnattrs]
+ matchingrule COLON EQUALS assertionvalue )
+ present = attr EQUALS ASTERISK
+ substring = attr EQUALS [initial] any [final]
+ initial = assertionvalue
+ any = ASTERISK *(assertionvalue ASTERISK)
+ final = assertionvalue
+ attr = attributedescription
+ ; The attributedescription rule is defined in
+ ; Section 2.5 of [RFC4512].
+ dnattrs = COLON "dn"
+ matchingrule = COLON oid
+ assertionvalue = valueencoding
+ ; The <valueencoding> rule is used to encode an <AssertionValue>
+ ; from Section 4.1.6 of [RFC4511].
+ valueencoding = 0*(normal / escaped)
+ normal = UTF1SUBSET / UTFMB
+ escaped = ESC HEX HEX
+ UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
+ ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+ ; RPAREN, ASTERISK, and ESC.
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
+ ASTERISK = %x2A ; asterisk ("*")
+ COLON = %x3A ; colon (":")
+ VERTBAR = %x7C ; vertical bar (or pipe) ("|")
+ TILDE = %x7E ; tilde ("~")
+
+ Note that although both the <substring> and <present> productions in
+ the grammar above can produce the "attr=*" construct, this construct
+ is used only to denote a presence filter.
+
+ The <valueencoding> rule ensures that the entire filter string is a
+ valid UTF-8 string and provides that the octets that represent the
+ ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+ 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+ backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+ representing the value of the encoded octet.
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 4]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other octets that are part
+ of the <normal> set may be escaped using this mechanism, for example,
+ non-printing ASCII characters.
+
+ For AssertionValues that contain UTF-8 character data, each octet of
+ the character to be escaped is replaced by a backslash and two hex
+ digits, which form a single octet in the code of the character. For
+ example, the filter checking whether the "cn" attribute contained a
+ value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ As indicated by the <valueencoding> rule, implementations MUST escape
+ all octets greater than 0x7F that are not part of a valid UTF-8
+ encoding sequence when they generate a string representation of a
+ search filter. Implementations SHOULD accept as input strings that
+ are not valid UTF-8 strings. This is necessary because RFC 2254 did
+ not clearly define the term "string representation" (and in
+ particular did not mention that the string representation of an LDAP
+ search filter is a string of UTF-8-encoded Unicode characters).
+
+4. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+ (seeAlso=)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:caseExactMatch:=Fred Flintstone)
+ (cn:=Betty Rubble)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:1.2.3:=Wilma Flintstone)
+ (:DN:2.4.6.8.10:=Dino)
+
+ The first example shows use of the matching rule "caseExactMatch."
+
+ The second example demonstrates use of a MatchingRuleAssertion form
+ without a matchingRule.
+
+
+
+
+
+Smith and Howes Standards Track [Page 5]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ The third example illustrates the use of the ":oid" notation to
+ indicate that the matching rule identified by the OID "2.4.6.8.10"
+ should be used when making comparisons, and that the attributes of an
+ entry's distinguished name should be considered part of the entry
+ when evaluating the match (indicated by the use of ":dn").
+
+ The fourth example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fifth example is a filter that should be applied to any attribute
+ supporting the matching rule given (since the <attr> has been
+ omitted).
+
+ The sixth and final example is also a filter that should be applied
+ to any attribute supporting the matching rule given. Attributes
+ supporting the matching rule contained in the DN should also be
+ considered.
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+ (1.3.6.1.4.1.1466.0=\04\02\48\69)
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent
+ a "*" in an assertion value, preventing it from being interpreted as
+ a substring indicator. The third illustrates the escaping of the
+ backslash character.
+
+ The fourth example shows a filter searching for the four-octet value
+ 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The fifth example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters. Specifically, there
+ are 5 characters in the <assertionvalue> portion of this example:
+ LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
+ SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
+ and LATIN SMALL LETTER C WITH ACUTE (U+0107).
+
+ The sixth and final example demonstrates assertion of a BER-encoded
+ value.
+
+
+
+
+Smith and Howes Standards Track [Page 6]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+5. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+ Please refer to the Security Considerations sections of [RFC4511] and
+ [RFC4513] for more information.
+
+6. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2."
+
+
+
+
+Smith and Howes Standards Track [Page 7]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+7. Informative References
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [X.690] Specification of ASN.1 encoding rules: Basic, Canonical,
+ and Distinguished Encoding Rules, ITU-T Recommendation
+ X.690, 1994.
+
+8. Acknowledgements
+
+ This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
+ of the IETF ASID Working Group.
+
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 8]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+Appendix A: Changes Since RFC 2254
+
+A.1. Technical Changes
+
+ Replaced [ISO 10646] reference with [Unicode].
+
+ The following technical changes were made to the contents of the
+ "String Search Filter Definition" section:
+
+ Added statement that the string representation is a string of UTF-8-
+ encoded Unicode characters.
+
+ Revised all of the ABNF to use common productions from [RFC4512].
+
+ Replaced the "value" rule with a new "assertionvalue" rule within the
+ "simple", "extensible", and "substring" ("initial", "any", and
+ "final") rules. This matches a change made in [RFC4517].
+
+ Added "(" and ")" around the components of the <extensible>
+ subproductions for clarity.
+
+ Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
+ precisely reference productions from the [RFC4512] and [RFC4511]
+ documents.
+
+ "String Search Filter Definition" section: replaced "greater" and
+ "less" with "greaterorequal" and "lessorequal" to avoid confusion.
+
+ Introduced the "valueencoding" and associated "normal" and "escaped"
+ rules to reduce the dependence on descriptive text. The "normal"
+ production restricts filter strings to valid UTF-8 sequences.
+
+ Added a statement about expected behavior in light of RFC 2254's lack
+ of a clear definition of "string representation."
+
+A.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ Header and "Authors' Addresses" sections: added Mark Smith as the
+ document editor and updated affiliation and contact information.
+
+ "Table of Contents" and "Intellectual Property" sections: added.
+
+ Copyright: updated per latest IETF guidelines.
+
+
+
+Smith and Howes Standards Track [Page 9]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ "Abstract" section: separated from introductory material.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Updated second paragraph to indicate that RFC 2254 is replaced by
+ this document (instead of RFC 1960). Added reference to the
+ [RFC4510] document.
+
+ "LDAP Search Filter Definition" section: made corrections to the LDAP
+ search filter ABNF so it matches that used in [RFC4511].
+
+ Clarified the definition of 'value' (now 'assertionvalue') to take
+ into account the fact that it is not precisely an AttributeAssertion
+ from [RFC4511] Section 4.1.6 (special handling is required for some
+ characters). Added a note that each octet of a character to be
+ escaped is replaced by a backslash and two hex digits, which
+ represent a single octet.
+
+ "Examples" section: added four additional examples: (seeAlso=),
+ (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
+ (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
+ value" with "an assertion value". Corrected the description of this
+ example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
+ in the first extensible match example with "caseExactMatch" to
+ demonstrate use of the descriptive form. Used "DN" (uppercase) in
+ the last extensible match example to remind the reader to treat the
+ <dnattrs> production as case insensitive. Reworded the description
+ of the fourth escaping mechanism example to avoid making assumptions
+ about byte order. Added text to the fifth escaping mechanism example
+ to spell out what the non-ASCII characters are in Unicode terms.
+
+ "Security Considerations" section: added references to [RFC4511] and
+ [RFC4513].
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [RFC4511] style throughout the
+ document. Added entries for [Unicode], [RFC2119], [RFC4513],
+ [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced
+ RFC 822 reference with a reference to RFC 4234.
+
+ "Informative References" section: (new section) moved [X.690] to this
+ section. Added a reference to [RFC4516].
+
+ "Acknowledgements" section: added.
+
+ "Appendix A: Changes Since RFC 2254" section: added.
+
+ Surrounded the names of all ABNF productions with "<" and ">" where
+ they are used in descriptive text.
+
+
+
+Smith and Howes Standards Track [Page 10]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+ Replaced all occurrences of "LDAPv3" with "LDAP."
+
+Authors' Addresses
+
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+
+ Phone: +1 734 944-2856
+ EMail: mcs@pearlcrescent.com
+
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+
+ Phone: +1 408 744-7509
+ EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 11]
+\f
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 12]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Smith, Ed.
+Request for Comments: 4516 Pearl Crescent, LLC
+Obsoletes: 2255 T. Howes
+Category: Standards Track Opsware, Inc.
+ June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Uniform Resource Locator
+
+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 (2006).
+
+Abstract
+
+ This document describes a format for a Lightweight Directory Access
+ Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
+ describes an LDAP search operation that is used to retrieve
+ information from an LDAP directory, or, in the context of an LDAP
+ referral or reference, an LDAP URL describes a service where an LDAP
+ operation may be progressed.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. URL Definition ..................................................2
+ 2.1. Percent-Encoding ...........................................4
+ 3. Defaults for Fields of the LDAP URL .............................5
+ 4. Examples ........................................................6
+ 5. Security Considerations .........................................8
+ 6. Normative References ............................................9
+ 7. Informative References .........................................10
+ 8. Acknowledgements ...............................................10
+ Appendix A: Changes Since RFC 2255 ................................11
+ A.1. Technical Changes .........................................11
+ A.2. Editorial Changes .........................................11
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 1]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+1. Introduction
+
+ LDAP is the Lightweight Directory Access Protocol [RFC4510]. This
+ document specifies the LDAP URL format for version 3 of LDAP and
+ clarifies how LDAP URLs are resolved. This document also defines an
+ extension mechanism for LDAP URLs. This mechanism may be used to
+ provide access to new LDAP extensions.
+
+ Note that not all the parameters of the LDAP search operation
+ described in [RFC4511] can be expressed using the format defined in
+ this document. Note also that URLs may be used to represent
+ reference knowledge, including that for non-search operations.
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document replaces RFC 2255. See Appendix A for a list of
+ changes relative to RFC 2255.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar, following the ABNF notation defined in
+ [RFC4234].
+
+ ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
+ [SLASH dn [QUESTION [attributes]
+ [QUESTION [scope] [QUESTION [filter]
+ [QUESTION extensions]]]]]
+ ; <host> and <port> are defined
+ ; in Sections 3.2.2 and 3.2.3
+ ; of [RFC3986].
+ ; <filter> is from Section 3 of
+ ; [RFC4515], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scheme = "ldap"
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 2]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ dn = distinguishedName ; From Section 3 of [RFC4514],
+ ; subject to the provisions of
+ ; the "Percent-Encoding"
+ ; section below.
+
+ attributes = attrdesc *(COMMA attrdesc)
+ attrdesc = selector *(COMMA selector)
+ selector = attributeSelector ; From Section 4.5.1 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scope = "base" / "one" / "sub"
+ extensions = extension *(COMMA extension)
+ extension = [EXCLAMATION] extype [EQUALS exvalue]
+ extype = oid ; From section 1.4 of [RFC4512].
+
+ exvalue = LDAPString ; From section 4.1.2 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+ The "ldap" prefix indicates an entry or entries accessible from the
+ LDAP server running on the given hostname at the given portnumber.
+ Note that the <host> may contain literal IPv6 addresses as specified
+ in Section 3.2.2 of [RFC3986].
+
+ The <dn> is an LDAP Distinguished Name using the string format
+ described in [RFC4514]. It identifies the base object of the LDAP
+ search or the target of a non-search operation.
+
+ The <attributes> construct is used to indicate which attributes
+ should be returned from the entry or entries.
+
+ The <scope> construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search.
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 3]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The <filter> is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [RFC4515].
+
+ The <extensions> construct provides the LDAP URL with an
+ extensibility mechanism, allowing the capabilities of the URL to be
+ extended in the future. Extensions are a simple comma-separated list
+ of type=value pairs, where the =value portion MAY be omitted for
+ options not requiring it. Each type=value pair is a separate
+ extension. These LDAP URL extensions are not necessarily related to
+ any of the LDAP extension mechanisms. Extensions may be supported or
+ unsupported by the client resolving the URL. An extension prefixed
+ with a '!' character (ASCII 0x21) is critical. An extension not
+ prefixed with a '!' character is non-critical.
+
+ If an LDAP URL extension is implemented (that is, if the
+ implementation understands it and is able to use it), the
+ implementation MUST make use of it. If an extension is not
+ implemented and is marked critical, the implementation MUST NOT
+ process the URL. If an extension is not implemented and is not
+ marked critical, the implementation MUST ignore the extension.
+
+ The extension type (<extype>) MAY be specified using the numeric OID
+ <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+ (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
+ restricted to registered object identifier descriptive names. See
+ [RFC4520] for registration details and usage guidelines for
+ descriptive names.
+
+ No LDAP URL extensions are defined in this document. Other documents
+ or a future version of this document MAY define one or more
+ extensions.
+
+2.1. Percent-Encoding
+
+ A generated LDAP URL MUST consist only of the restricted set of
+ characters included in one of the following three productions defined
+ in [RFC3986]:
+
+ <reserved>
+ <unreserved>
+ <pct-encoded>
+
+ Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+ input. An octet MUST be encoded using the percent-encoding mechanism
+ described in section 2.1 of [RFC3986] in any of these situations:
+
+
+
+
+
+Smith & Howes Standards Track [Page 4]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The octet is not in the reserved set defined in section 2.2 of
+ [RFC3986] or in the unreserved set defined in section 2.3 of
+ [RFC3986].
+
+ It is the single Reserved character '?' and occurs inside a <dn>,
+ <filter>, or other element of an LDAP URL.
+
+ It is a comma character ',' that occurs inside an <exvalue>.
+
+ Note that before the percent-encoding mechanism is applied, the
+ extensions component of the LDAP URL may contain one or more null
+ (zero) bytes. No other component may.
+
+3. Defaults for Fields of the LDAP URL
+
+ Some fields of the LDAP URL are optional, as described above. In the
+ absence of any other specification, the following general defaults
+ SHOULD be used when a field is absent. Note that other documents MAY
+ specify different defaulting rules; for example, section 4.1.10 of
+ [RFC4511] specifies a different rule for determining the correct DN
+ to use when it is absent in an LDAP URL that is returned as a
+ referral.
+
+ <host>
+ If no <host> is given, the client must have some a priori
+ knowledge of an appropriate LDAP server to contact.
+
+ <port>
+ The default LDAP port is TCP port 389.
+
+ <dn>
+ If no <dn> is given, the default is the zero-length DN, "".
+
+ <attributes>
+ If the <attributes> part is omitted, all user attributes of the
+ entry or entries should be requested (e.g., by setting the
+ attributes field AttributeDescriptionList in the LDAP search
+ request to a NULL list, or by using the special <alluserattrs>
+ selector "*").
+
+ <scope>
+ If <scope> is omitted, a <scope> of "base" is assumed.
+
+ <filter>
+ If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
+
+ <extensions>
+ If <extensions> is omitted, no extensions are assumed.
+
+
+
+Smith & Howes Standards Track [Page 5]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+4. Examples
+
+ The following are some example LDAP URLs that use the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan,c=US" entry using a filter of
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ LDAP://ldap1.example.com/c=GB?objectClass?ONE
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US", illustrating the use of the
+ percent-encoding mechanism on the reserved character '?'.
+
+
+
+
+Smith & Howes Standards Track [Page 6]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+ The next example (which is broken into two lines for readability)
+ illustrates the interaction between the LDAP string representation of
+ the filters-quoting mechanism and the URL-quoting mechanisms.
+
+ ldap://ldap3.example.com/o=Babsco,c=US
+ ???(four-octet=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (four-octet=\00\00\00\04). Because the \
+ character must be escaped in a URL, the \s are percent-encoded as %5c
+ (or %5C) in the URL encoding.
+
+ The next example illustrates the interaction between the LDAP string
+ representation of the DNs-quoting mechanism and URL-quoting
+ mechanisms.
+
+ ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
+
+ The DN encoded in the above URL is:
+
+ o=An Example\2C Inc.,c=US
+
+ That is, the left-most RDN value is:
+
+ An Example, Inc.
+
+ The following three URLs are equivalent, assuming that the defaulting
+ rules specified in Section 3 of this document are used:
+
+ ldap://ldap.example.net
+ ldap://ldap.example.net/
+ ldap://ldap.example.net/?
+
+ These three URLs point to the root DSE on the ldap.example.net
+ server.
+
+ The final two examples show use of a hypothetical, experimental bind
+ name extension (the value associated with the extension is an LDAP
+ DN).
+
+ ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+ ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 7]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The two URLs are the same, except that the second one marks the
+ e-bindname extension as critical. Notice the use of the percent-
+ encoding mechanism to encode the commas within the distinguished name
+ value in the e-bindname extension.
+
+5. Security Considerations
+
+ The general URL security considerations discussed in [RFC3986] are
+ relevant for LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy that controls which servers the client will establish LDAP
+ sessions with and with which security mechanisms, and SHOULD NOT
+ establish LDAP sessions that are inconsistent with this policy. If a
+ client chooses to reuse an existing LDAP session when resolving one
+ or more LDAP URLs, it MUST ensure that the session is compatible with
+ the URL and that no security policies are violated.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous LDAP session. (Note that clients
+ conforming to previous LDAP URL specifications, where all LDAP
+ sessions are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.) Simply
+ opening a transport connection to another server may violate some
+ users' privacy requirements, so clients should provide the user with
+ a way to control URL processing.
+
+ Some authentication methods, in particular, reusable passwords sent
+ to the server, may reveal easily-abused information to the remote
+ server or to eavesdroppers in transit and should not be used in URL
+ processing unless they are explicitly permitted by policy.
+ Confirmation by the human user of the use of authentication
+ information is appropriate in many circumstances. Use of strong
+ authentication methods that do not reveal sensitive information is
+ much preferred. If the URL represents a referral for an update
+ operation, strong authentication methods SHOULD be used. Please
+ refer to the Security Considerations section of [RFC4513] for more
+ information.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data or the initiation of a long-lived
+
+
+
+Smith & Howes Standards Track [Page 8]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ search. The security implications of resolving an LDAP URL are the
+ same as those of resolving an LDAP search query.
+
+6. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Search Filters",
+ RFC 4515, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 9]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+7. Informative References
+
+ [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+8. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+ This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged. Several people in particular have
+ made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
+ Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+ thanks for their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 10]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Appendix A: Changes Since RFC 2255
+
+A.1. Technical Changes
+
+ The following technical changes were made to the contents of the "URL
+ Definition" section:
+
+ Revised all of the ABNF to use common productions from [RFC4512].
+
+ Replaced references to [RFC2396] with a reference to [RFC3986] (this
+ allows literal IPv6 addresses to be used inside the <host> portion of
+ the URL, and a note was added to remind the reader of this
+ enhancement). Referencing [RFC3986] required changes to the ABNF and
+ text so that productions that are no longer defined by [RFC3986] are
+ not used. For example, <hostport> is not defined by [RFC3986] so it
+ has been replaced with host [COLON port]. Note that [RFC3986]
+ includes new definitions for the "Reserved" and "Unreserved" sets of
+ characters, and the net result is that the following two additional
+ characters should be percent-encoded when they appear anywhere in the
+ data used to construct an LDAP URL: "[" and "]" (these two characters
+ were first added to the Reserved set by RFC 2732).
+
+ Changed the definition of <attrdesc> to refer to <attributeSelector>
+ from [RFC4511]. This allows the use of "*" in the <attrdesc> part of
+ the URL. It is believed that existing implementations of RFC 2255
+ already support this.
+
+ Avoided use of <prose-val> (bracketed-string) productions in the
+ <dn>, <host>, <attrdesc>, and <exvalue> rules.
+
+ Changed the ABNF for <ldapurl> to group the <dn> component with the
+ preceding <SLASH>.
+
+ Changed the <extype> rule to be an <oid> from [RFC4512].
+
+ Changed the text about extension types so it references [RFC4520].
+ Reordered rules to more closely follow the order in which the
+ elements appear in the URL.
+
+ "Bindname Extension": removed due to lack of known implementations.
+
+A.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+
+
+
+Smith & Howes Standards Track [Page 11]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "Abstract" section: separated from introductory material.
+
+ "Table of Contents" and "Intellectual Property" sections: added.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Changed the text indicate that RFC 2255 is replaced by this document
+ (instead of RFC 1959). Added text to indicate that LDAP URLs are
+ used for references and referrals. Fixed typo (replaced the nonsense
+ phrase "to perform to retrieve" with "used to retrieve"). Added a
+ note to let the reader know that not all of the parameters of the
+ LDAP search operation described in [RFC4511] can be expressed using
+ this format.
+
+ "URL Definition" section: removed second copy of <ldapurl> grammar
+ and following two paragraphs (editorial error in RFC 2255). Fixed
+ line break within '!' sequence. Reformatted the ABNF to improve
+ readability by aligning comments and adding some blank lines.
+ Replaced "residing in the LDAP server" with "accessible from the LDAP
+ server" in the sentence immediately following the ABNF. Removed the
+ sentence "Individual attrdesc names are as defined for
+ AttributeDescription in [RFC4511]." because [RFC4511]'s
+ <attributeSelector> is now used directly in the ABNF. Reworded last
+ paragraph to clarify which characters must be percent-encoded. Added
+ text to indicate that LDAP URLs are used for references and
+ referrals. Added text that refers to the ABNF from RFC 4234.
+ Clarified and strengthened the requirements with respect to
+ processing of URLs that contain implemented and not implemented
+ extensions (the approach now closely matches that specified in
+ [RFC4511] for LDAP controls).
+
+ "Defaults for Fields of the LDAP URL" section: added; formed by
+ moving text about defaults out of the "URL Definition" section.
+ Replaced direct reference to the attribute name "*" with a reference
+ to the special <alluserattrs> selector "*" defined in [RFC4511].
+
+ "URL Processing" section: removed.
+
+ "Examples" section: Modified examples to use example.com and
+ example.net hostnames. Added missing '?' to the LDAP URL example
+ whose filter contains three null bytes. Removed space after one
+ comma within a DN. Revised the bindname example to use e-bindname.
+ Changed the name of an attribute used in one example from "int" to
+ "four-octet" to avoid potential confusion. Added an example that
+ demonstrates the interaction between DN escaping and URL percent-
+ encoding. Added some examples to show URL equivalence with respect
+
+
+
+Smith & Howes Standards Track [Page 12]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ to the <dn> portion of the URL. Used uppercase in some examples to
+ remind the reader that some tokens are case-insensitive.
+
+ "Security Considerations" section: Added a note about connection
+ reuse. Added a note about using strong authentication methods for
+ updates. Added a reference to [RFC4513]. Added note that simply
+ opening a connection may violate some users' privacy requirements.
+ Adopted the working group's revised LDAP terminology specification by
+ replacing the word "connection" with "LDAP session" or "LDAP
+ connection" as appropriate.
+
+ "Acknowledgements" section: added statement that this document
+ obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
+ Hallvard Furuseth.
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [RFC4511] style throughout the
+ document. Added references to RFC 4234 and RFC 3629. Updated all
+ RFC 1738 references to point to the appropriate sections within
+ [RFC3986]. Updated the LDAP references to refer to LDAPBis WG
+ documents. Removed the reference to the LDAP Attribute Syntaxes
+ document and added references to the [RFC4513], [RFC4520], and
+ [RFC4510] documents.
+
+ "Informative References" section: added.
+
+ Header and "Authors' Addresses" sections: added "editor" next to Mark
+ Smith's name. Updated affiliation and contact information.
+
+ Copyright: updated the year.
+
+ Throughout the document: surrounded the names of all ABNF productions
+ with "<" and ">" where they are used in descriptive text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 13]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Authors' Addresses
+
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+
+ Phone: +1 734 944-2856
+ EMail: mcs@pearlcrescent.com
+
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+
+ Phone: +1 408 744-7509
+ EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 14]
+\f
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 15]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Legg, Ed.
+Request for Comments: 4517 eB2Bcom
+Obsoletes: 2252, 2256 June 2006
+Updates: 3698
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules
+
+
+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 (2006).
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory, whose values may be transferred in the LDAP
+ protocol, has a defined syntax that constrains the structure and
+ format of its values. The comparison semantics for values of a
+ syntax are not part of the syntax definition but are instead provided
+ through separately defined matching rules. Matching rules specify an
+ argument, an assertion value, which also has a defined syntax. This
+ document defines a base set of syntaxes and matching rules for use in
+ defining attributes for LDAP directories.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions .....................................................4
+ 3. Syntaxes ........................................................4
+ 3.1. General Considerations .....................................5
+ 3.2. Common Definitions .........................................5
+ 3.3. Syntax Definitions .........................................6
+ 3.3.1. Attribute Type Description ..........................6
+ 3.3.2. Bit String ..........................................6
+ 3.3.3. Boolean .............................................7
+ 3.3.4. Country String ......................................7
+ 3.3.5. Delivery Method .....................................8
+
+
+
+Legg Standards Track [Page 1]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ 3.3.6. Directory String ....................................8
+ 3.3.7. DIT Content Rule Description ........................9
+ 3.3.8. DIT Structure Rule Description .....................10
+ 3.3.9. DN .................................................10
+ 3.3.10. Enhanced Guide ....................................11
+ 3.3.11. Facsimile Telephone Number ........................12
+ 3.3.12. Fax ...............................................12
+ 3.3.13. Generalized Time ..................................13
+ 3.3.14. Guide .............................................14
+ 3.3.15. IA5 String ........................................15
+ 3.3.16. Integer ...........................................15
+ 3.3.17. JPEG ..............................................15
+ 3.3.18. LDAP Syntax Description ...........................16
+ 3.3.19. Matching Rule Description .........................16
+ 3.3.20. Matching Rule Use Description .....................17
+ 3.3.21. Name and Optional UID .............................17
+ 3.3.22. Name Form Description .............................18
+ 3.3.23. Numeric String ....................................18
+ 3.3.24. Object Class Description ..........................18
+ 3.3.25. Octet String ......................................19
+ 3.3.26. OID ...............................................19
+ 3.3.27. Other Mailbox .....................................20
+ 3.3.28. Postal Address ....................................20
+ 3.3.29. Printable String ..................................21
+ 3.3.30. Substring Assertion ...............................22
+ 3.3.31. Telephone Number ..................................23
+ 3.3.32. Teletex Terminal Identifier .......................23
+ 3.3.33. Telex Number ......................................24
+ 3.3.34. UTC Time ..........................................24
+ 4. Matching Rules .................................................25
+ 4.1. General Considerations ....................................25
+ 4.2. Matching Rule Definitions .................................27
+ 4.2.1. bitStringMatch .....................................27
+ 4.2.2. booleanMatch .......................................28
+ 4.2.3. caseExactIA5Match ..................................28
+ 4.2.4. caseExactMatch .....................................29
+ 4.2.5. caseExactOrderingMatch .............................29
+ 4.2.6. caseExactSubstringsMatch ...........................30
+ 4.2.7. caseIgnoreIA5Match .................................30
+ 4.2.8. caseIgnoreIA5SubstringsMatch .......................31
+ 4.2.9. caseIgnoreListMatch ................................31
+ 4.2.10. caseIgnoreListSubstringsMatch .....................32
+ 4.2.11. caseIgnoreMatch ...................................33
+ 4.2.12. caseIgnoreOrderingMatch ...........................33
+ 4.2.13. caseIgnoreSubstringsMatch .........................34
+ 4.2.14. directoryStringFirstComponentMatch ................34
+ 4.2.15. distinguishedNameMatch ............................35
+ 4.2.16. generalizedTimeMatch ..............................36
+
+
+
+Legg Standards Track [Page 2]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ 4.2.17. generalizedTimeOrderingMatch ......................36
+ 4.2.18. integerFirstComponentMatch ........................36
+ 4.2.19. integerMatch ......................................37
+ 4.2.20. integerOrderingMatch ..............................37
+ 4.2.21. keywordMatch ......................................38
+ 4.2.22. numericStringMatch ................................38
+ 4.2.23. numericStringOrderingMatch ........................39
+ 4.2.24. numericStringSubstringsMatch ......................39
+ 4.2.25. objectIdentifierFirstComponentMatch ...............40
+ 4.2.26. objectIdentifierMatch .............................40
+ 4.2.27. octetStringMatch ..................................41
+ 4.2.28. octetStringOrderingMatch ..........................41
+ 4.2.29. telephoneNumberMatch ..............................42
+ 4.2.30. telephoneNumberSubstringsMatch ....................42
+ 4.2.31. uniqueMemberMatch .................................43
+ 4.2.32. wordMatch .........................................44
+ 5. Security Considerations ........................................44
+ 6. Acknowledgements ...............................................44
+ 7. IANA Considerations ............................................45
+ 8. References .....................................................46
+ 8.1. Normative References ......................................46
+ 8.2. Informative References ....................................48
+ Appendix A. Summary of Syntax Object Identifiers ..................49
+ Appendix B. Changes from RFC 2252 .................................49
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [RFC4510], whose values may be transferred in the
+ LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
+ constrains the structure and format of its values. The comparison
+ semantics for values of a syntax are not part of the syntax
+ definition but are instead provided through separately defined
+ matching rules. Matching rules specify an argument, an assertion
+ value, which also has a defined syntax. This document defines a base
+ set of syntaxes and matching rules for use in defining attributes for
+ LDAP directories.
+
+ Readers are advised to familiarize themselves with the Directory
+ Information Models [RFC4512] before reading the rest of this
+ document. Section 3 provides definitions for the base set of LDAP
+ syntaxes. Section 4 provides definitions for the base set of
+ matching rules for LDAP.
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+
+
+
+Legg Standards Track [Page 3]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The
+ remainder of RFC 2252 is obsoleted by this document. Sections 6 and
+ 8 of RFC 2256 are obsoleted by this document. The remainder of RFC
+ 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11
+ of RFC 3698 is obsoleted by this document.
+
+ A number of schema elements that were included in the previous
+ revision of the LDAP technical specification are not included in this
+ revision of LDAP. Public Key Infrastructure schema elements are now
+ specified in [RFC4523]. Unless reintroduced in future technical
+ specifications, the remainder are to be considered Historic.
+
+ The changes with respect to RFC 2252 are described in Appendix B of
+ this document.
+
+2. Conventions
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+ Syntax definitions are written according to the <SyntaxDescription>
+ ABNF [RFC4234] rule specified in [RFC4512], and matching rule
+ definitions are written according to the <MatchingRuleDescription>
+ ABNF rule specified in [RFC4512], except that the syntax and matching
+ rule definitions provided in this document are line-wrapped for
+ readability. When such definitions are transferred as attribute
+ values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
+ matchingRules attributes [RFC4512], respectively), then those values
+ would not contain line breaks.
+
+3. Syntaxes
+
+ Syntax definitions constrain the structure of attribute values stored
+ in an LDAP directory, and determine the representation of attribute
+ and assertion values transferred in the LDAP protocol.
+
+ Syntaxes that are required for directory operation, or that are in
+ common use, are specified in this section. Servers SHOULD recognize
+ all the syntaxes listed in this document, but are not required to
+ otherwise support them, and MAY recognise or support other syntaxes.
+ However, the definition of additional arbitrary syntaxes is
+ discouraged since it will hinder interoperability. Client and server
+ implementations typically do not have the ability to dynamically
+ recognize new syntaxes.
+
+
+
+
+
+Legg Standards Track [Page 4]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+3.1. General Considerations
+
+ The description of each syntax specifies how attribute or assertion
+ values conforming to the syntax are to be represented when
+ transferred in the LDAP protocol [RFC4511]. This representation is
+ referred to as the LDAP-specific encoding to distinguish it from
+ other methods of encoding attribute values (e.g., the Basic Encoding
+ Rules (BER) encoding [BER] used by X.500 [X.500] directories).
+
+ The LDAP-specific encoding of a given attribute syntax always
+ produces octet-aligned values. To the greatest extent possible,
+ encoding rules for LDAP syntaxes should produce character strings
+ that can be displayed with little or no translation by clients
+ implementing LDAP. However, clients MUST NOT assume that the LDAP-
+ specific encoding of a value of an unrecognized syntax is a human-
+ readable character string. There are a few cases (e.g., the JPEG
+ syntax) when it is not reasonable to produce a human-readable
+ representation.
+
+ Each LDAP syntax is uniquely identified with an object identifier
+ [ASN.1] represented in the dotted-decimal format (short descriptive
+ names are not defined for syntaxes). These object identifiers are
+ not intended to be displayed to users. The object identifiers for
+ the syntaxes defined in this document are summarized in Appendix A.
+
+ A suggested minimum upper bound on the number of characters in an
+ attribute value with a string-based syntax, or the number of octets
+ in a value for all other syntaxes, MAY be indicated by appending the
+ bound inside of curly braces following the syntax's OBJECT IDENTIFIER
+ in an attribute type definition (see the <noidlen> rule in
+ [RFC4512]). Such a bound is not considered part of the syntax
+ identifier.
+
+ For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
+ definition suggests that the directory server will allow a value of
+ the attribute to be up to 64 characters long, although it may allow
+ longer character strings. Note that a single character of the
+ Directory String syntax can be encoded in more than one octet, since
+ UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-
+ character string may be more than 64 octets in length.
+
+3.2. Common Definitions
+
+ The following ABNF rules are used in a number of the syntax
+ definitions in Section 3.3.
+
+ PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
+ PLUS / COMMA / HYPHEN / DOT / EQUALS /
+
+
+
+Legg Standards Track [Page 5]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ SLASH / COLON / QUESTION / SPACE
+ PrintableString = 1*PrintableCharacter
+ IA5String = *(%x00-7F)
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+ The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
+ <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
+ [RFC4512].
+
+3.3. Syntax Definitions
+
+3.3.1. Attribute Type Description
+
+ A value of the Attribute Type Description syntax is the definition of
+ an attribute type. The LDAP-specific encoding of a value of this
+ syntax is defined by the <AttributeTypeDescription> rule in
+ [RFC4512].
+
+ For example, the following definition of the createTimestamp
+ attribute type from [RFC4512] is also a value of the Attribute
+ Type Description syntax. (Note: Line breaks have been added for
+ readability; they are not part of the value when transferred in
+ protocol.)
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The LDAP definition for the Attribute Type Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+ This syntax corresponds to the AttributeTypeDescription ASN.1 type
+ from [X.501].
+
+3.3.2. Bit String
+
+ A value of the Bit String syntax is a sequence of binary digits. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ BitString = SQUOTE *binary-digit SQUOTE "B"
+ binary-digit = "0" / "1"
+
+
+
+Legg Standards Track [Page 6]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The <SQUOTE> rule is defined in [RFC4512].
+
+ Example:
+ '0101111101'B
+
+ The LDAP definition for the Bit String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
+
+3.3.3. Boolean
+
+ A value of the Boolean syntax is one of the Boolean values, true or
+ false. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ Boolean = "TRUE" / "FALSE"
+
+ The LDAP definition for the Boolean syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+ This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
+
+3.3.4. Country String
+
+ A value of the Country String syntax is one of the two-character
+ codes from ISO 3166 [ISO3166] for representing a country. The LDAP-
+ specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ CountryString = 2(PrintableCharacter)
+
+ The <PrintableCharacter> rule is defined in Section 3.2.
+
+ Examples:
+
+ US
+ AU
+
+ The LDAP definition for the Country String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+ PrintableString (SIZE (2)) -- ISO 3166 codes only
+
+
+
+Legg Standards Track [Page 7]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+3.3.5. Delivery Method
+
+ A value of the Delivery Method syntax is a sequence of items that
+ indicate, in preference order, the service(s) by which an entity is
+ willing and/or capable of receiving messages. The LDAP-specific
+ encoding of a value of this syntax is defined by the following ABNF:
+
+ DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
+
+ pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+ "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+ The <WSP> and <DOLLAR> rules are defined in [RFC4512].
+
+ Example:
+ telephone $ videotex
+
+ The LDAP definition for the Delivery Method syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+ SEQUENCE OF INTEGER {
+ any-delivery-method (0),
+ mhs-delivery (1),
+ physical-delivery (2),
+ telex-delivery (3),
+ teletex-delivery (4),
+ g3-facsimile-delivery (5),
+ g4-facsimile-delivery (6),
+ ia5-terminal-delivery (7),
+ videotex-delivery (8),
+ telephone-delivery (9) }
+
+3.3.6. Directory String
+
+ A value of the Directory String syntax is a string of one or more
+ arbitrary characters from the Universal Character Set (UCS) [UCS]. A
+ zero-length character string is not permitted. The LDAP-specific
+ encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
+ the character string. Such encodings conform to the following ABNF:
+
+ DirectoryString = 1*UTF8
+
+ The <UTF8> rule is defined in [RFC4512].
+
+
+
+
+
+Legg Standards Track [Page 8]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Example:
+ This is a value of Directory String containing #!%#@.
+
+ Servers and clients MUST be prepared to receive arbitrary UCS code
+ points, including code points outside the range of printable ASCII
+ and code points not presently assigned to any character.
+
+ Attribute type definitions using the Directory String syntax should
+ not restrict the format of Directory String values, e.g., by
+ requiring that the character string conforms to specific patterns
+ described by ABNF. A new syntax should be defined in such cases.
+
+ The LDAP definition for the Directory String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ This syntax corresponds to the DirectoryString parameterized ASN.1
+ type from [X.520].
+
+ The DirectoryString ASN.1 type allows a choice between the
+ TeletexString, PrintableString, or UniversalString ASN.1 types from
+ [ASN.1]. However, note that the chosen alternative is not indicated
+ in the LDAP-specific encoding of a Directory String value.
+
+ Implementations that convert Directory String values from the LDAP-
+ specific encoding to the BER encoding used by X.500 must choose an
+ alternative that permits the particular characters in the string and
+ must convert the characters from the UTF-8 encoding into the
+ character encoding of the chosen alternative. When converting
+ Directory String values from the BER encoding to the LDAP-specific
+ encoding, the characters must be converted from the character
+ encoding of the chosen alternative into the UTF-8 encoding. These
+ conversions SHOULD be done in a manner consistent with the Transcode
+ step of the string preparation algorithms [RFC4518] for LDAP.
+
+3.3.7. DIT Content Rule Description
+
+ A value of the DIT Content Rule Description syntax is the definition
+ of a DIT (Directory Information Tree) content rule. The LDAP-
+ specific encoding of a value of this syntax is defined by the
+ <DITContentRuleDescription> rule in [RFC4512].
+
+ Example:
+ ( 2.5.6.4 DESC 'content rule for organization'
+ NOT ( x121Address $ telexNumber ) )
+
+ Note: A line break has been added for readability; it is not part
+ of the value.
+
+
+
+Legg Standards Track [Page 9]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The LDAP definition for the DIT Content Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.16
+ DESC 'DIT Content Rule Description' )
+
+ This syntax corresponds to the DITContentRuleDescription ASN.1 type
+ from [X.501].
+
+3.3.8. DIT Structure Rule Description
+
+ A value of the DIT Structure Rule Description syntax is the
+ definition of a DIT structure rule. The LDAP-specific encoding of a
+ value of this syntax is defined by the <DITStructureRuleDescription>
+ rule in [RFC4512].
+
+ Example:
+ ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
+
+ The LDAP definition for the DIT Structure Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.17
+ DESC 'DIT Structure Rule Description' )
+
+ This syntax corresponds to the DITStructureRuleDescription ASN.1 type
+ from [X.501].
+
+3.3.9. DN
+
+ A value of the DN syntax is the (purported) distinguished name (DN)
+ of an entry [RFC4512]. The LDAP-specific encoding of a value of this
+ syntax is defined by the <distinguishedName> rule from the string
+ representation of distinguished names [RFC4514].
+
+ Examples (from [RFC4514]):
+ UID=jsmith,DC=example,DC=net
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+ CN=John Smith\, III,DC=example,DC=net
+ CN=Before\0dAfter,DC=example,DC=net
+ 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
+ CN=Lu\C4\8Di\C4\87
+
+ The LDAP definition for the DN syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+ The DN syntax corresponds to the DistinguishedName ASN.1 type from
+ [X.501]. Note that a BER encoded distinguished name (as used by
+ X.500) re-encoded into the LDAP-specific encoding is not necessarily
+
+
+
+Legg Standards Track [Page 10]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ reversible to the original BER encoding since the chosen string type
+ in any DirectoryString components of the distinguished name is not
+ indicated in the LDAP-specific encoding of the distinguished name
+ (see Section 3.3.6).
+
+3.3.10. Enhanced Guide
+
+ A value of the Enhanced Guide syntax suggests criteria, which consist
+ of combinations of attribute types and filter operators, to be used
+ in constructing filters to search for entries of particular object
+ classes. The Enhanced Guide syntax improves upon the Guide syntax by
+ allowing the recommended depth of the search to be specified.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ EnhancedGuide = object-class SHARP WSP criteria WSP
+ SHARP WSP subset
+ object-class = WSP oid WSP
+ subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+ criteria = and-term *( BAR and-term )
+ and-term = term *( AMPERSAND term )
+ term = EXCLAIM term /
+ attributetype DOLLAR match-type /
+ LPAREN criteria RPAREN /
+ true /
+ false
+ match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+ true = "?true"
+ false = "?false"
+ BAR = %x7C ; vertical bar ("|")
+ AMPERSAND = %x26 ; ampersand ("&")
+ EXCLAIM = %x21 ; exclamation mark ("!")
+
+ The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
+ <DOLLAR> rules are defined in [RFC4512].
+
+ The LDAP definition for the Enhanced Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+ Example:
+ person#(sn$EQ)#oneLevel
+
+ The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
+ from [X.520]. The EnhancedGuide type references the Criteria ASN.1
+ type, also from [X.520]. The <true> rule, above, represents an empty
+
+
+
+Legg Standards Track [Page 11]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ "and" expression in a value of the Criteria type. The <false> rule,
+ above, represents an empty "or" expression in a value of the Criteria
+ type.
+
+3.3.11. Facsimile Telephone Number
+
+ A value of the Facsimile Telephone Number syntax is a subscriber
+ number of a facsimile device on the public switched telephone
+ network. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ fax-number = telephone-number *( DOLLAR fax-parameter )
+ telephone-number = PrintableString
+ fax-parameter = "twoDimensional" /
+ "fineResolution" /
+ "unlimitedLength" /
+ "b4Length" /
+ "a3Width" /
+ "b4Width" /
+ "uncompressed"
+
+ The <telephone-number> is a string of printable characters that
+ complies with the internationally agreed format for representing
+ international telephone numbers [E.123]. The <PrintableString> rule
+ is defined in Section 3.2. The <DOLLAR> rule is defined in
+ [RFC4512].
+
+ The LDAP definition for the Facsimile Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
+
+ The Facsimile Telephone Number syntax corresponds to the
+ FacsimileTelephoneNumber ASN.1 type from [X.520].
+
+3.3.12. Fax
+
+ A value of the Fax syntax is an image that is produced using the
+ Group 3 facsimile process [FAX] to duplicate an object, such as a
+ memo. The LDAP-specific encoding of a value of this syntax is the
+ string of octets for a Group 3 Fax image as defined in [FAX].
+
+ The LDAP definition for the Fax syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+ The ASN.1 type corresponding to the Fax syntax is defined as follows,
+ assuming EXPLICIT TAGS:
+
+
+
+
+Legg Standards Track [Page 12]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Fax ::= CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+
+ The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
+
+3.3.13. Generalized Time
+
+ A value of the Generalized Time syntax is a character string
+ representing a date and time. The LDAP-specific encoding of a value
+ of this syntax is a restriction of the format defined in [ISO8601],
+ and is described by the following ABNF:
+
+ GeneralizedTime = century year month day hour
+ [ minute [ second / leap-second ] ]
+ [ fraction ]
+ g-time-zone
+
+ century = 2(%x30-39) ; "00" to "99"
+ year = 2(%x30-39) ; "00" to "99"
+ month = ( %x30 %x31-39 ) ; "01" (January) to "09"
+ / ( %x31 %x30-32 ) ; "10" to "12"
+ day = ( %x30 %x31-39 ) ; "01" to "09"
+ / ( %x31-32 %x30-39 ) ; "10" to "29"
+ / ( %x33 %x30-31 ) ; "30" to "31"
+ hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+ minute = %x30-35 %x30-39 ; "00" to "59"
+
+ second = ( %x30-35 %x30-39 ) ; "00" to "59"
+ leap-second = ( %x36 %x30 ) ; "60"
+
+ fraction = ( DOT / COMMA ) 1*(%x30-39)
+ g-time-zone = %x5A ; "Z"
+ / g-differential
+ g-differential = ( MINUS / PLUS ) hour [ minute ]
+ MINUS = %x2D ; minus sign ("-")
+
+ The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
+
+ The above ABNF allows character strings that do not represent valid
+ dates (in the Gregorian calendar) and/or valid times (e.g., February
+ 31, 1994). Such character strings SHOULD be considered invalid for
+ this syntax.
+
+ The time value represents coordinated universal time (equivalent to
+ Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
+ otherwise, the value represents a local time in the time zone
+ indicated by <g-differential>. In the latter case, coordinated
+
+
+
+Legg Standards Track [Page 13]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ universal time can be calculated by subtracting the differential from
+ the local time. The "Z" form of <g-time-zone> SHOULD be used in
+ preference to <g-differential>.
+
+ If <minute> is omitted, then <fraction> represents a fraction of an
+ hour; otherwise, if <second> and <leap-second> are omitted, then
+ <fraction> represents a fraction of a minute; otherwise, <fraction>
+ represents a fraction of a second.
+
+ Examples:
+ 199412161032Z
+ 199412160532-0500
+
+ Both example values represent the same coordinated universal time:
+ 10:32 AM, December 16, 1994.
+
+ The LDAP definition for the Generalized Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+ This syntax corresponds to the GeneralizedTime ASN.1 type from
+ [ASN.1], with the constraint that local time without a differential
+ SHALL NOT be used.
+
+3.3.14. Guide
+
+ A value of the Guide syntax suggests criteria, which consist of
+ combinations of attribute types and filter operators, to be used in
+ constructing filters to search for entries of particular object
+ classes. The Guide syntax is obsolete and should not be used for
+ defining new attribute types.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ Guide = [ object-class SHARP ] criteria
+
+ The <object-class> and <criteria> rules are defined in Section
+ 3.3.10. The <SHARP> rule is defined in [RFC4512].
+
+ The LDAP definition for the Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
+
+
+
+
+
+
+Legg Standards Track [Page 14]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+3.3.15. IA5 String
+
+ A value of the IA5 String syntax is a string of zero, one, or more
+ characters from International Alphabet 5 (IA5) [T.50], the
+ international version of the ASCII character set. The LDAP-specific
+ encoding of a value of this syntax is the unconverted string of
+ characters, which conforms to the <IA5String> rule in Section 3.2.
+
+ The LDAP definition for the IA5 String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
+
+3.3.16. Integer
+
+ A value of the Integer syntax is a whole number of unlimited
+ magnitude. The LDAP-specific encoding of a value of this syntax is
+ the optionally signed decimal digit character string representation
+ of the number (for example, the number 1321 is represented by the
+ character string "1321"). The encoding is defined by the following
+ ABNF:
+
+ Integer = ( HYPHEN LDIGIT *DIGIT ) / number
+
+ The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
+ [RFC4512].
+
+ The LDAP definition for the Integer syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+ This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
+
+3.3.17. JPEG
+
+ A value of the JPEG syntax is an image in the JPEG File Interchange
+ Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
+ a value of this syntax is the sequence of octets of the JFIF encoding
+ of the image.
+
+ The LDAP definition for the JPEG syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ The JPEG syntax corresponds to the following ASN.1 type:
+
+
+
+
+
+Legg Standards Track [Page 15]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ JPEG ::= OCTET STRING (CONSTRAINED BY
+ { -- contents octets are an image in the --
+ -- JPEG File Interchange Format -- })
+
+3.3.18. LDAP Syntax Description
+
+ A value of the LDAP Syntax Description syntax is the description of
+ an LDAP syntax. The LDAP-specific encoding of a value of this syntax
+ is defined by the <SyntaxDescription> rule in [RFC4512].
+
+ The LDAP definition for the LDAP Syntax Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+ The above LDAP definition for the LDAP Syntax Description syntax is
+ itself a legal value of the LDAP Syntax Description syntax.
+
+ The ASN.1 type corresponding to the LDAP Syntax Description syntax is
+ defined as follows, assuming EXPLICIT TAGS:
+
+ LDAPSyntaxDescription ::= SEQUENCE {
+ identifier OBJECT IDENTIFIER,
+ description DirectoryString { ub-schema } OPTIONAL }
+
+ The DirectoryString parameterized ASN.1 type is defined in [X.520].
+
+ The value of ub-schema (an integer) is implementation defined. A
+ non-normative definition appears in [X.520].
+
+3.3.19. Matching Rule Description
+
+ A value of the Matching Rule Description syntax is the definition of
+ a matching rule. The LDAP-specific encoding of a value of this
+ syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
+
+ Example:
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Note: A line break has been added for readability; it is not part of
+ the syntax.
+
+ The LDAP definition for the Matching Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+ This syntax corresponds to the MatchingRuleDescription ASN.1 type
+ from [X.501].
+
+
+
+Legg Standards Track [Page 16]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+3.3.20. Matching Rule Use Description
+
+ A value of the Matching Rule Use Description syntax indicates the
+ attribute types to which a matching rule may be applied in an
+ extensibleMatch search filter [RFC4511]. The LDAP-specific encoding
+ of a value of this syntax is defined by the
+ <MatchingRuleUseDescription> rule in [RFC4512].
+
+ Example:
+ ( 2.5.13.16 APPLIES ( givenName $ surname ) )
+
+ The LDAP definition for the Matching Rule Use Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.31
+ DESC 'Matching Rule Use Description' )
+
+ This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
+ from [X.501].
+
+3.3.21. Name and Optional UID
+
+ A value of the Name and Optional UID syntax is the distinguished name
+ [RFC4512] of an entity optionally accompanied by a unique identifier
+ that serves to differentiate the entity from others with an identical
+ distinguished name.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ NameAndOptionalUID = distinguishedName [ SHARP BitString ]
+
+ The <BitString> rule is defined in Section 3.3.2. The
+ <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule
+ is defined in [RFC4512].
+
+ Note that although the '#' character may occur in the string
+ representation of a distinguished name, no additional escaping of
+ this character is performed when a <distinguishedName> is encoded in
+ a <NameAndOptionalUID>.
+
+ Example:
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+ The LDAP definition for the Name and Optional UID syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+
+
+
+
+Legg Standards Track [Page 17]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ This syntax corresponds to the NameAndOptionalUID ASN.1 type from
+ [X.520].
+
+3.3.22. Name Form Description
+
+ A value of the Name Form Description syntax is the definition of a
+ name form, which regulates how entries may be named. The LDAP-
+ specific encoding of a value of this syntax is defined by the
+ <NameFormDescription> rule in [RFC4512].
+
+ Example:
+ ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
+
+ The LDAP definition for the Name Form Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+ This syntax corresponds to the NameFormDescription ASN.1 type from
+ [X.501].
+
+3.3.23. Numeric String
+
+ A value of the Numeric String syntax is a sequence of one or more
+ numerals and spaces. The LDAP-specific encoding of a value of this
+ syntax is the unconverted string of characters, which conforms to the
+ following ABNF:
+
+ NumericString = 1*(DIGIT / SPACE)
+
+ The <DIGIT> and <SPACE> rules are defined in [RFC4512].
+
+ Example:
+ 15 079 672 281
+
+ The LDAP definition for the Numeric String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
+
+3.3.24. Object Class Description
+
+ A value of the Object Class Description syntax is the definition of
+ an object class. The LDAP-specific encoding of a value of this
+ syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
+
+
+
+
+
+
+Legg Standards Track [Page 18]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Example:
+ ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+ MAY ( searchGuide $ description ) )
+
+ Note: A line break has been added for readability; it is not part of
+ the syntax.
+
+ The LDAP definition for the Object Class Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+ This syntax corresponds to the ObjectClassDescription ASN.1 type from
+ [X.501].
+
+3.3.25. Octet String
+
+ A value of the Octet String syntax is a sequence of zero, one, or
+ more arbitrary octets. The LDAP-specific encoding of a value of this
+ syntax is the unconverted sequence of octets, which conforms to the
+ following ABNF:
+
+ OctetString = *OCTET
+
+ The <OCTET> rule is defined in [RFC4512]. Values of this syntax are
+ not generally human-readable.
+
+ The LDAP definition for the Octet String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
+
+3.3.26. OID
+
+ A value of the OID syntax is an object identifier: a sequence of two
+ or more non-negative integers that uniquely identify some object or
+ item of specification. Many of the object identifiers used in LDAP
+ also have IANA registered names [RFC4520].
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the <oid> rule in [RFC4512].
+
+ Examples:
+ 1.2.3.4
+ cn
+
+ The LDAP definition for the OID syntax is:
+
+
+
+
+Legg Standards Track [Page 19]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
+ [ASN.1].
+
+3.3.27. Other Mailbox
+
+ A value of the Other Mailbox syntax identifies an electronic mailbox,
+ in a particular named mail system. The LDAP-specific encoding of a
+ value of this syntax is defined by the following ABNF:
+
+ OtherMailbox = mailbox-type DOLLAR mailbox
+ mailbox-type = PrintableString
+ mailbox = IA5String
+
+ The <mailbox-type> rule represents the type of mail system in which
+ the mailbox resides (for example, "MCIMail"), and <mailbox> is the
+ actual mailbox in the mail system described by <mailbox-type>. The
+ <PrintableString> and <IA5String> rules are defined in Section 3.2.
+ The <DOLLAR> rule is defined in [RFC4512].
+
+ The LDAP definition for the Other Mailbox syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+ The ASN.1 type corresponding to the Other Mailbox syntax is defined
+ as follows, assuming EXPLICIT TAGS:
+
+ OtherMailbox ::= SEQUENCE {
+ mailboxType PrintableString,
+ mailbox IA5String
+ }
+
+3.3.28. Postal Address
+
+ A value of the Postal Address syntax is a sequence of strings of one
+ or more arbitrary UCS characters, which form an address in a physical
+ mail system.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 20]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ PostalAddress = line *( DOLLAR line )
+ line = 1*line-char
+ line-char = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each character string (i.e., <line>) of a postal address value is
+ encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
+ characters, if they occur in the string, are escaped by a "\"
+ character followed by the two hexadecimal digit code for the
+ character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
+
+ Many servers limit the postal address to no more than six lines of no
+ more than thirty characters each.
+
+ Example:
+ 1234 Main St.$Anytown, CA 12345$USA
+ \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+ The LDAP definition for the Postal Address syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+ This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
+ that is
+
+ PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
+ DirectoryString { ub-postal-string }
+
+ The values of ub-postal-line and ub-postal-string (both integers) are
+ implementation defined. Non-normative definitions appear in [X.520].
+
+3.3.29. Printable String
+
+ A value of the Printable String syntax is a string of one or more
+ latin alphabetic, numeric, and selected punctuation characters as
+ specified by the <PrintableCharacter> rule in Section 3.2.
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 3.2.
+
+ Example:
+ This is a PrintableString.
+
+
+
+
+Legg Standards Track [Page 21]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The LDAP definition for the PrintableString syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+ This syntax corresponds to the PrintableString ASN.1 type from
+ [ASN.1].
+
+3.3.30. Substring Assertion
+
+ A value of the Substring Assertion syntax is a sequence of zero, one,
+ or more character substrings used as an argument for substring
+ extensible matching of character string attribute values; i.e., as
+ the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring
+ is a string of one or more arbitrary characters from the Universal
+ Character Set (UCS) [UCS]. A zero-length substring is not permitted.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ SubstringAssertion = [ initial ] any [ final ]
+
+ initial = substring
+ any = ASTERISK *(substring ASTERISK)
+ final = substring
+ ASTERISK = %x2A ; asterisk ("*")
+
+ substring = 1*substring-character
+ substring-character = %x00-29
+ / (%x5C "2A") ; escaped "*"
+ / %x2B-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each <substring> of a Substring Assertion value is encoded as a UTF-8
+ [RFC3629] string, except that "\" and "*" characters, if they occur
+ in the substring, are escaped by a "\" character followed by the two
+ hexadecimal digit code for the character.
+
+ The Substring Assertion syntax is used only as the syntax of
+ assertion values in the extensible match. It is not used as an
+ attribute syntax, or in the SubstringFilter [RFC4511].
+
+ The LDAP definition for the Substring Assertion syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+
+
+
+
+Legg Standards Track [Page 22]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ This syntax corresponds to the SubstringAssertion ASN.1 type from
+ [X.520].
+
+3.3.31. Telephone Number
+
+ A value of the Telephone Number syntax is a string of printable
+ characters that complies with the internationally agreed format for
+ representing international telephone numbers [E.123].
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 3.2.
+
+ Examples:
+ +1 512 315 0280
+ +1-512-315-0280
+ +61 3 9896 7830
+
+ The LDAP definition for the Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+ The Telephone Number syntax corresponds to the following ASN.1 type
+ from [X.520]:
+
+ PrintableString (SIZE(1..ub-telephone-number))
+
+ The value of ub-telephone-number (an integer) is implementation
+ defined. A non-normative definition appears in [X.520].
+
+3.3.32. Teletex Terminal Identifier
+
+ A value of this syntax specifies the identifier and (optionally)
+ parameters of a teletex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ teletex-id = ttx-term *(DOLLAR ttx-param)
+ ttx-term = PrintableString ; terminal identifier
+ ttx-param = ttx-key COLON ttx-value ; parameter
+ ttx-key = "graphic" / "control" / "misc" / "page" / "private"
+ ttx-value = *ttx-value-octet
+
+ ttx-value-octet = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+
+
+
+Legg Standards Track [Page 23]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ / %x5D-FF
+
+ The <PrintableString> and <COLON> rules are defined in Section 3.2.
+ The <DOLLAR> rule is defined in [RFC4512].
+
+ The LDAP definition for the Teletex Terminal Identifier syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51
+ DESC 'Teletex Terminal Identifier' )
+
+ This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
+ from [X.520].
+
+3.3.33. Telex Number
+
+ A value of the Telex Number syntax specifies the telex number,
+ country code, and answerback code of a telex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ telex-number = actual-number DOLLAR country-code
+ DOLLAR answerback
+ actual-number = PrintableString
+ country-code = PrintableString
+ answerback = PrintableString
+
+ The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
+ rule is defined in [RFC4512].
+
+ The LDAP definition for the Telex Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+ This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
+
+3.3.34. UTC Time
+
+ A value of the UTC Time syntax is a character string representing a
+ date and time to a precision of one minute or one second. The year
+ is given as a two-digit number. The LDAP-specific encoding of a
+ value of this syntax follows the format defined in [ASN.1] for the
+ UTCTime type and is described by the following ABNF:
+
+ UTCTime = year month day hour minute [ second ]
+ [ u-time-zone ]
+ u-time-zone = %x5A ; "Z"
+ / u-differential
+
+
+
+Legg Standards Track [Page 24]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ u-differential = ( MINUS / PLUS ) hour minute
+
+ The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
+ rules are defined in Section 3.3.13. The <PLUS> rule is defined in
+ [RFC4512].
+
+ The above ABNF allows character strings that do not represent valid
+ dates (in the Gregorian calendar) and/or valid times. Such character
+ strings SHOULD be considered invalid for this syntax.
+
+ The time value represents coordinated universal time if the "Z" form
+ of <u-time-zone> is used; otherwise, the value represents a local
+ time. In the latter case, if <u-differential> is provided, then
+ coordinated universal time can be calculated by subtracting the
+ differential from the local time. The <u-time-zone> SHOULD be
+ present in time values, and the "Z" form of <u-time-zone> SHOULD be
+ used in preference to <u-differential>.
+
+ The LDAP definition for the UTC Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+ Note: This syntax is deprecated in favor of the Generalized Time
+ syntax.
+
+ The UTC Time syntax corresponds to the UTCTime ASN.1 type from
+ [ASN.1].
+
+4. Matching Rules
+
+ Matching rules are used by directory implementations to compare
+ attribute values against assertion values when performing Search and
+ Compare operations [RFC4511]. They are also used when comparing a
+ purported distinguished name [RFC4512] with the name of an entry.
+ When modifying entries, matching rules are used to identify values to
+ be deleted and to prevent an attribute from containing two equal
+ values.
+
+ Matching rules that are required for directory operation, or that are
+ in common use, are specified in this section.
+
+4.1. General Considerations
+
+ A matching rule is applied to attribute values through an
+ AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The
+ conditions under which an AttributeValueAssertion or
+ MatchingRuleAssertion evaluates to Undefined are specified elsewhere
+ [RFC4511]. If an assertion is not Undefined, then the result of the
+
+
+
+Legg Standards Track [Page 25]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ assertion is the result of applying the selected matching rule. A
+ matching rule evaluates to TRUE, and in some cases Undefined, as
+ specified in the description of the matching rule; otherwise, it
+ evaluates to FALSE.
+
+ Each assertion contains an assertion value. The definition of each
+ matching rule specifies the syntax for the assertion value. The
+ syntax of the assertion value is typically, but not necessarily, the
+ same as the syntax of the attribute values to which the matching rule
+ may be applied. Note that an AssertionValue in a SubstringFilter
+ [RFC4511] conforms to the assertion syntax of the equality matching
+ rule for the attribute type rather than to the assertion syntax of
+ the substrings matching rule for the attribute type. Conceptually,
+ the entire SubstringFilter is converted into an assertion value of
+ the substrings matching rule prior to applying the rule.
+
+ The definition of each matching rule indicates the attribute syntaxes
+ to which the rule may be applied, by specifying conditions the
+ corresponding ASN.1 type of a candidate attribute syntax must
+ satisfy. These conditions are also satisfied if the corresponding
+ ASN.1 type is a tagged or constrained derivative of the ASN.1 type
+ explicitly mentioned in the rule description (i.e., ASN.1 tags and
+ constraints are ignored in checking applicability), or is an
+ alternative reference notation for the explicitly mentioned type.
+ Each rule description lists, as examples of applicable attribute
+ syntaxes, the complete list of the syntaxes defined in this document
+ to which the matching rule applies. A matching rule may be
+ applicable to additional syntaxes defined in other documents if those
+ syntaxes satisfy the conditions on the corresponding ASN.1 type.
+
+ The description of each matching rule indicates whether the rule is
+ suitable for use as the equality matching rule (EQUALITY), ordering
+ matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
+ attribute type definition [RFC4512].
+
+ Each matching rule is uniquely identified with an object identifier.
+ The definition of a matching rule should not subsequently be changed.
+ If a change is desirable, then a new matching rule with a different
+ object identifier should be defined instead.
+
+ Servers MAY implement the wordMatch and keywordMatch matching rules,
+ but they SHOULD implement the other matching rules in Section 4.2.
+ Servers MAY implement additional matching rules.
+
+ Servers that implement the extensibleMatch filter SHOULD allow the
+ matching rules listed in Section 4.2 to be used in the
+ extensibleMatch filter and SHOULD allow matching rules to be used
+ with all attribute types known to the server, where the assertion
+
+
+
+Legg Standards Track [Page 26]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ syntax of the matching rule is the same as the value syntax of the
+ attribute.
+
+ Servers MUST publish, in the matchingRules attribute, the definitions
+ of matching rules referenced by values of the attributeTypes and
+ matchingRuleUse attributes in the same subschema entry. Other
+ unreferenced matching rules MAY be published in the matchingRules
+ attribute.
+
+ If the server supports the extensibleMatch filter, then the server
+ MAY use the matchingRuleUse attribute to indicate the applicability
+ (in an extensibleMatch filter) of selected matching rules to
+ nominated attribute types.
+
+4.2. Matching Rule Definitions
+
+ Nominated character strings in assertion and attribute values are
+ prepared according to the string preparation algorithms [RFC4518] for
+ LDAP when evaluating the following matching rules:
+
+ numericStringMatch,
+ numericStringSubstringsMatch,
+ caseExactMatch,
+ caseExactOrderingMatch,
+ caseExactSubstringsMatch,
+ caseExactIA5Match,
+ caseIgnoreIA5Match,
+ caseIgnoreIA5SubstringsMatch,
+ caseIgnoreListMatch,
+ caseIgnoreListSubstringsMatch,
+ caseIgnoreMatch,
+ caseIgnoreOrderingMatch,
+ caseIgnoreSubstringsMatch,
+ directoryStringFirstComponentMatch,
+ telephoneNumberMatch,
+ telephoneNumberSubstringsMatch and
+ wordMatch.
+
+ The Transcode, Normalize, Prohibit, and Check bidi steps are the same
+ for each of the matching rules. However, the Map and Insignificant
+ Character Handling steps depend on the specific rule, as detailed in
+ the description of these matching rules in the sections that follow.
+
+4.2.1. bitStringMatch
+
+ The bitStringMatch rule compares an assertion value of the Bit String
+ syntax to an attribute value of a syntax (e.g., the Bit String
+ syntax) whose corresponding ASN.1 type is BIT STRING.
+
+
+
+Legg Standards Track [Page 27]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ If the corresponding ASN.1 type of the attribute syntax does not have
+ a named bit list [ASN.1] (which is the case for the Bit String
+ syntax), then the rule evaluates to TRUE if and only if the attribute
+ value has the same number of bits as the assertion value and the bits
+ match on a bitwise basis.
+
+ If the corresponding ASN.1 type does have a named bit list, then
+ bitStringMatch operates as above, except that trailing zero bits in
+ the attribute and assertion values are treated as absent.
+
+ The LDAP definition for the bitStringMatch rule is:
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ The bitStringMatch rule is an equality matching rule.
+
+4.2.2. booleanMatch
+
+ The booleanMatch rule compares an assertion value of the Boolean
+ syntax to an attribute value of a syntax (e.g., the Boolean syntax)
+ whose corresponding ASN.1 type is BOOLEAN.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are both TRUE or both FALSE.
+
+ The LDAP definition for the booleanMatch rule is:
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The booleanMatch rule is an equality matching rule.
+
+4.2.3. caseExactIA5Match
+
+ The caseExactIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g., the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+
+
+Legg Standards Track [Page 28]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The LDAP definition for the caseExactIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The caseExactIA5Match rule is an equality matching rule.
+
+4.2.4. caseExactMatch
+
+ The caseExactMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String, Printable String, Country String, or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of the
+ alternative string types of DirectoryString, such as PrintableString
+ (the other alternatives do not correspond to any syntax defined in
+ this document).
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactMatch rule is:
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactMatch rule is an equality matching rule.
+
+4.2.5. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g., the
+ Directory String, Printable String, Country String, or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string;
+ i.e., the attribute value is "less than" the assertion value.
+
+
+
+
+
+Legg Standards Track [Page 29]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactOrderingMatch rule is:
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactOrderingMatch rule is an ordering matching rule.
+
+4.2.6. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
+ the Directory String, Printable String, Country String, or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are not case folded in the Map preparation
+ step, and only Insignificant Space Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the caseExactSubstringsMatch rule is:
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseExactSubstringsMatch rule is a substrings matching rule.
+
+4.2.7. caseIgnoreIA5Match
+
+ The caseIgnoreIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g., the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+
+
+
+Legg Standards Track [Page 30]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The caseIgnoreIA5Match rule is an equality matching rule.
+
+4.2.8. caseIgnoreIA5SubstringsMatch
+
+ The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
+ IA5String.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
+
+4.2.9. caseIgnoreListMatch
+
+ The caseIgnoreListMatch rule compares an assertion value that is a
+ sequence of strings to an attribute value of a syntax (e.g., the
+
+
+
+Legg Standards Track [Page 31]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
+ OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of strings and corresponding
+ strings (by position) match according to the caseIgnoreMatch matching
+ rule.
+
+ In [X.520], the assertion syntax for this matching rule is defined to
+ be:
+
+ SEQUENCE OF DirectoryString {ub-match}
+
+ That is, it is different from the corresponding type for the Postal
+ Address syntax. The choice of the Postal Address syntax for the
+ assertion syntax of the caseIgnoreListMatch in LDAP should not be
+ seen as limiting the matching rule to apply only to attributes with
+ the Postal Address syntax.
+
+ The LDAP definition for the caseIgnoreListMatch rule is:
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The caseIgnoreListMatch rule is an equality matching rule.
+
+4.2.10. caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
+ SEQUENCE OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ matches, per the caseIgnoreSubstringsMatch rule, the character string
+ formed by concatenating the strings of the attribute value, except
+ that none of the <initial>, <any>, or <final> substrings of the
+ assertion value are considered to match a substring of the
+ concatenated string which spans more than one of the original strings
+ of the attribute value.
+
+ Note that, in terms of the LDAP-specific encoding of the Postal
+ Address syntax, the concatenated string omits the <DOLLAR> line
+ separator and the escaping of "\" and "$" characters.
+
+ The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+
+
+
+Legg Standards Track [Page 32]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+
+4.2.11. caseIgnoreMatch
+
+ The caseIgnoreMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String, Printable String, Country String, or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of its
+ alternative string types.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreMatch rule is:
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreMatch rule is an equality matching rule.
+
+4.2.12. caseIgnoreOrderingMatch
+
+ The caseIgnoreOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g., the
+ Directory String, Printable String, Country String, or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string;
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreOrderingMatch rule is:
+
+
+
+Legg Standards Track [Page 33]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreOrderingMatch rule is an ordering matching rule.
+
+4.2.13. caseIgnoreSubstringsMatch
+
+ The caseIgnoreSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
+ the Directory String, Printable String, Country String, or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreSubstringsMatch rule is:
+
+ ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreSubstringsMatch rule is a substrings matching rule.
+
+4.2.14. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares an assertion
+ value of the Directory String syntax to an attribute value of a
+ syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+ first component of the DirectoryString ASN.1 type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+
+
+
+
+
+Legg Standards Track [Page 34]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ caseIgnoreMatch.
+
+ The LDAP definition for the directoryStringFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The directoryStringFirstComponentMatch rule is an equality matching
+ rule. When using directoryStringFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+4.2.15. distinguishedNameMatch
+
+ The distinguishedNameMatch rule compares an assertion value of the DN
+ syntax to an attribute value of a syntax (e.g., the DN syntax) whose
+ corresponding ASN.1 type is DistinguishedName.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of relative distinguished names
+ and corresponding relative distinguished names (by position) are the
+ same. A relative distinguished name (RDN) of the assertion value is
+ the same as an RDN of the attribute value if and only if they have
+ the same number of attribute value assertions and each attribute
+ value assertion (AVA) of the first RDN is the same as the AVA of the
+ second RDN with the same attribute type. The order of the AVAs is
+ not significant. Also note that a particular attribute type may
+ appear in at most one AVA in an RDN. Two AVAs with the same
+ attribute type are the same if their values are equal according to
+ the equality matching rule of the attribute type. If one or more of
+ the AVA comparisons evaluate to Undefined and the remaining AVA
+ comparisons return TRUE then the distinguishedNameMatch rule
+ evaluates to Undefined.
+
+ The LDAP definition for the distinguishedNameMatch rule is:
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The distinguishedNameMatch rule is an equality matching rule.
+
+
+
+
+
+
+Legg Standards Track [Page 35]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+4.2.16. generalizedTimeMatch
+
+ The generalizedTimeMatch rule compares an assertion value of the
+ Generalized Time syntax to an attribute value of a syntax (e.g., the
+ Generalized Time syntax) whose corresponding ASN.1 type is
+ GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents the same universal coordinated time as the assertion
+ value. If a time is specified with the minutes or seconds absent,
+ then the number of minutes or seconds (respectively) is assumed to be
+ zero.
+
+ The LDAP definition for the generalizedTimeMatch rule is:
+
+ ( 2.5.13.27 NAME 'generalizedTimeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeMatch rule is an equality matching rule.
+
+4.2.17. generalizedTimeOrderingMatch
+
+ The generalizedTimeOrderingMatch rule compares the time ordering of
+ an assertion value of the Generalized Time syntax to an attribute
+ value of a syntax (e.g., the Generalized Time syntax) whose
+ corresponding ASN.1 type is GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents a universal coordinated time that is earlier than the
+ universal coordinated time represented by the assertion value.
+
+ The LDAP definition for the generalizedTimeOrderingMatch rule is:
+
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeOrderingMatch rule is an ordering matching rule.
+
+4.2.18. integerFirstComponentMatch
+
+ The integerFirstComponentMatch rule compares an assertion value of
+ the Integer syntax to an attribute value of a syntax (e.g., the DIT
+ Structure Rule Description syntax) whose corresponding ASN.1 type is
+ a SEQUENCE with a mandatory first component of the INTEGER ASN.1
+ type.
+
+
+
+
+
+
+Legg Standards Track [Page 36]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ first component of the attribute value are the same integer value.
+
+ The LDAP definition for the integerFirstComponentMatch matching rule
+ is:
+
+ ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerFirstComponentMatch rule is an equality matching rule.
+ When using integerFirstComponentMatch to compare two attribute values
+ (of an applicable syntax), an assertion value must first be derived
+ from one of the attribute values. An assertion value can be derived
+ from an attribute value by taking the first component of that
+ attribute value.
+
+4.2.19. integerMatch
+
+ The integerMatch rule compares an assertion value of the Integer
+ syntax to an attribute value of a syntax (e.g., the Integer syntax)
+ whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same integer value.
+
+ The LDAP definition for the integerMatch matching rule is:
+
+ ( 2.5.13.14 NAME 'integerMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerMatch rule is an equality matching rule.
+
+4.2.20. integerOrderingMatch
+
+ The integerOrderingMatch rule compares an assertion value of the
+ Integer syntax to an attribute value of a syntax (e.g., the Integer
+ syntax) whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the integer value of the
+ attribute value is less than the integer value of the assertion
+ value.
+
+ The LDAP definition for the integerOrderingMatch matching rule is:
+
+
+
+
+Legg Standards Track [Page 37]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerOrderingMatch rule is an ordering matching rule.
+
+4.2.21. keywordMatch
+
+ The keywordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ character string matches any keyword in the attribute value. The
+ identification of keywords in the attribute value and the exactness
+ of the match are both implementation specific.
+
+ The LDAP definition for the keywordMatch rule is:
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+4.2.22. numericStringMatch
+
+ The numericStringMatch rule compares an assertion value of the
+ Numeric String syntax to an attribute value of a syntax (e.g., the
+ Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the numericStringMatch matching rule is:
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringMatch rule is an equality matching rule.
+
+
+
+
+
+
+
+Legg Standards Track [Page 38]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+4.2.23. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares an assertion value of
+ the Numeric String syntax to an attribute value of a syntax (e.g.,
+ the Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string;
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The rule is identical to the caseIgnoreOrderingMatch rule except that
+ all space characters are skipped during comparison (case is
+ irrelevant as the characters are numeric).
+
+ The LDAP definition for the numericStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringOrderingMatch rule is an ordering matching rule.
+
+4.2.24. numericStringSubstringsMatch
+
+ The numericStringSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+
+
+
+Legg Standards Track [Page 39]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the numericStringSubstringsMatch matching
+ rule is:
+
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The numericStringSubstringsMatch rule is a substrings matching rule.
+
+4.2.25. objectIdentifierFirstComponentMatch
+
+ The objectIdentifierFirstComponentMatch rule compares an assertion
+ value of the OID syntax to an attribute value of a syntax (e.g., the
+ Attribute Type Description, DIT Content Rule Description, LDAP Syntax
+ Description, Matching Rule Description, Matching Rule Use
+ Description, Name Form Description, or Object Class Description
+ syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+ first component of the OBJECT IDENTIFIER ASN.1 type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ objectIdentifierMatch.
+
+ The LDAP definition for the objectIdentifierFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierFirstComponentMatch rule is an equality matching
+ rule. When using objectIdentifierFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+4.2.26. objectIdentifierMatch
+
+ The objectIdentifierMatch rule compares an assertion value of the OID
+ syntax to an attribute value of a syntax (e.g., the OID syntax) whose
+ corresponding ASN.1 type is OBJECT IDENTIFIER.
+
+
+
+
+Legg Standards Track [Page 40]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ attribute value represent the same object identifier; that is, the
+ same sequence of integers, whether represented explicitly in the
+ <numericoid> form of <oid> or implicitly in the <descr> form (see
+ [RFC4512]).
+
+ If an LDAP client supplies an assertion value in the <descr> form and
+ the chosen descriptor is not recognized by the server, then the
+ objectIdentifierMatch rule evaluates to Undefined.
+
+ The LDAP definition for the objectIdentifierMatch matching rule is:
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierMatch rule is an equality matching rule.
+
+4.2.27. octetStringMatch
+
+ The octetStringMatch rule compares an assertion value of the Octet
+ String syntax to an attribute value of a syntax (e.g., the Octet
+ String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
+ STRING ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same length and corresponding octets (by
+ position) are the same.
+
+ The LDAP definition for the octetStringMatch matching rule is:
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringMatch rule is an equality matching rule.
+
+4.2.28. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares an assertion value of the
+ Octet String syntax to an attribute value of a syntax (e.g., the
+ Octet String or JPEG syntax) whose corresponding ASN.1 type is the
+ OCTET STRING ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value appears
+ earlier in the collation order than the assertion value. The rule
+ compares octet strings from the first octet to the last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+
+
+
+Legg Standards Track [Page 41]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ strings contain different numbers of octets but the longer string is
+ identical to the shorter string up to the length of the shorter
+ string, then the shorter string precedes the longer string.
+
+ The LDAP definition for the octetStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringOrderingMatch rule is an ordering matching rule.
+
+4.2.29. telephoneNumberMatch
+
+ The telephoneNumberMatch rule compares an assertion value of the
+ Telephone Number syntax to an attribute value of a syntax (e.g., the
+ Telephone Number syntax) whose corresponding ASN.1 type is a
+ PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ telephoneNumber Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the telephoneNumberMatch matching rule is:
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumberMatch rule is an equality matching rule.
+
+4.2.30. telephoneNumberSubstringsMatch
+
+ The telephoneNumberSubstringsMatch rule compares an assertion value
+ of the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
+ a PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+
+
+
+Legg Standards Track [Page 42]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ (3) a <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only telephoneNumber Insignificant Character Handling is applied
+ in the Insignificant Character Handling step.
+
+ The LDAP definition for the telephoneNumberSubstringsMatch matching
+ rule is:
+
+ ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The telephoneNumberSubstringsMatch rule is a substrings matching
+ rule.
+
+4.2.31. uniqueMemberMatch
+
+ The uniqueMemberMatch rule compares an assertion value of the Name
+ And Optional UID syntax to an attribute value of a syntax (e.g., the
+ Name And Optional UID syntax) whose corresponding ASN.1 type is
+ NameAndOptionalUID.
+
+ The rule evaluates to TRUE if and only if the <distinguishedName>
+ components of the assertion value and attribute value match according
+ to the distinguishedNameMatch rule and either, (1) the <BitString>
+ component is absent from both the attribute value and assertion
+ value, or (2) the <BitString> component is present in both the
+ attribute value and the assertion value and the <BitString> component
+ of the assertion value matches the <BitString> component of the
+ attribute value according to the bitStringMatch rule.
+
+ Note that this matching rule has been altered from its description in
+ X.520 [X.520] in order to make the matching rule commutative. Server
+ implementors should consider using the original X.520 semantics
+ (where the matching was less exact) for approximate matching of
+ attributes with uniqueMemberMatch as the equality matching rule.
+
+ The LDAP definition for the uniqueMemberMatch matching rule is:
+
+ ( 2.5.13.23 NAME 'uniqueMemberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ The uniqueMemberMatch rule is an equality matching rule.
+
+
+
+
+Legg Standards Track [Page 43]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+4.2.32. wordMatch
+
+ The wordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value word
+ matches, according to the semantics of caseIgnoreMatch, any word in
+ the attribute value. The precise definition of a word is
+ implementation specific.
+
+ The LDAP definition for the wordMatch rule is:
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+5. Security Considerations
+
+ In general, the LDAP-specific encodings for syntaxes defined in this
+ document do not define canonical encodings. That is, a
+ transformation from an LDAP-specific encoding into some other
+ encoding (e.g., BER) and back into the LDAP-specific encoding will
+ not necessarily reproduce exactly the original octets of the LDAP-
+ specific encoding. Therefore, an LDAP-specific encoding should not
+ be used where a canonical encoding is required.
+
+ Furthermore, the LDAP-specific encodings do not necessarily enable an
+ alternative encoding of values of the Directory String and DN
+ syntaxes to be reconstructed; e.g., a transformation from a
+ Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
+ encoding and back to a DER encoding may not reproduce the original
+ DER encoding. Therefore, LDAP-specific encodings should not be used
+ where reversibility to DER is needed; e.g., for the verification of
+ digital signatures. Instead, DER or a DER-reversible encoding should
+ be used.
+
+ When interpreting security-sensitive fields (in particular, fields
+ used to grant or deny access), implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+6. Acknowledgements
+
+ This document is primarily a revision of RFC 2252 by M. Wahl, A.
+ Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
+ ASID Working Group.
+
+
+
+
+
+Legg Standards Track [Page 44]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ This document is based on input from the IETF LDAPBIS working group.
+ The author would like to thank Kathy Dally for editing the early
+ drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
+ their significant contributions to this revision.
+
+7. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [BCP64] as indicated by the following templates:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@eb2bcom.com>
+ Usage: see comment
+ Specification: RFC 4517
+ Author/Change Controller: IESG
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ bitStringMatch M 2.5.13.16
+ booleanMatch M 2.5.13.13
+ caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
+ caseIgnoreListMatch M 2.5.13.11
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ caseIgnoreMatch M 2.5.13.2
+ caseIgnoreOrderingMatch M 2.5.13.3
+ caseIgnoreSubstringsMatch M 2.5.13.4
+ directoryStringFirstComponentMatch M 2.5.13.31
+ distinguishedNameMatch M 2.5.13.1
+ generalizedTimeMatch M 2.5.13.27
+ generalizedTimeOrderingMatch M 2.5.13.28
+ integerFirstComponentMatch M 2.5.13.29
+ integerMatch M 2.5.13.14
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
+ numericStringMatch M 2.5.13.8
+ numericStringOrderingMatch M 2.5.13.9
+ numericStringSubstringsMatch M 2.5.13.10
+ objectIdentifierFirstComponentMatch M 2.5.13.30
+ octetStringMatch M 2.5.13.17
+ octetStringOrderingMatch M 2.5.13.18
+ telephoneNumberMatch M 2.5.13.20
+
+
+
+Legg Standards Track [Page 45]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ telephoneNumberSubstringsMatch M 2.5.13.21
+ uniqueMemberMatch M 2.5.13.23
+ wordMatch M 2.5.13.32
+
+ The descriptor for the object identifier 2.5.13.0 was incorrectly
+ registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
+ It has been changed to the following, with a reference to
+ RFC 4517.
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ objectIdentifierMatch M 2.5.13.0
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): caseIgnoreIA5SubstringsMatch
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@eb2bcom.com>
+ Usage: other (M)
+ Specification: RFC 4517
+ Author/Change Controller: IESG
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+Legg Standards Track [Page 46]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC 4518,
+ June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988.
+
+ [FAX] Standardization of Group 3 facsimile apparatus for
+ document transmission - Terminal Equipment and Protocols
+ for Telematic Services, ITU-T Recommendation T.4, 1993
+
+ [T.50] International Reference Alphabet (IRA) (Formerly
+ International Alphabet No. 5 or IA5) Information
+ Technology - 7-Bit Coded Character Set for Information
+ Interchange, ITU-T Recommendation T.50, 1992
+
+ [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+ Information Technology - Message Handling Systems (MHS):
+ Interpersonal messaging system
+
+ [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected attribute types
+
+ [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times".
+
+
+
+
+
+Legg Standards Track [Page 47]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-
+ 1: 1993 (with amendments).
+
+ [JPEG] JPEG File Interchange Format (Version 1.02). Eric
+ Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+ 1992.
+
+8.2. Informative References
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June
+ 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 48]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+Appendix A. Summary of Syntax Object Identifiers
+
+ The following list summarizes the object identifiers assigned to the
+ syntaxes defined in this document.
+
+ Syntax OBJECT IDENTIFIER
+ ==============================================================
+ Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
+ Bit String 1.3.6.1.4.1.1466.115.121.1.6
+ Boolean 1.3.6.1.4.1.1466.115.121.1.7
+ Country String 1.3.6.1.4.1.1466.115.121.1.11
+ Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
+ Directory String 1.3.6.1.4.1.1466.115.121.1.15
+ DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
+ DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
+ DN 1.3.6.1.4.1.1466.115.121.1.12
+ Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
+ Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
+ Fax 1.3.6.1.4.1.1466.115.121.1.23
+ Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
+ Guide 1.3.6.1.4.1.1466.115.121.1.25
+ IA5 String 1.3.6.1.4.1.1466.115.121.1.26
+ Integer 1.3.6.1.4.1.1466.115.121.1.27
+ JPEG 1.3.6.1.4.1.1466.115.121.1.28
+ LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
+ Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
+ Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
+ Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
+ Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
+ Numeric String 1.3.6.1.4.1.1466.115.121.1.36
+ Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
+ Octet String 1.3.6.1.4.1.1466.115.121.1.40
+ OID 1.3.6.1.4.1.1466.115.121.1.38
+ Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
+ Postal Address 1.3.6.1.4.1.1466.115.121.1.41
+ Printable String 1.3.6.1.4.1.1466.115.121.1.44
+ Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
+ Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
+ Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
+ Telex Number 1.3.6.1.4.1.1466.115.121.1.52
+ UTC Time 1.3.6.1.4.1.1466.115.121.1.53
+
+Appendix B. Changes from RFC 2252
+
+ This annex lists the significant differences between this
+ specification and RFC 2252.
+
+
+
+
+
+Legg Standards Track [Page 49]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ This annex is provided for informational purposes only. It is not a
+ normative part of this specification.
+
+ 1. The IESG Note has been removed.
+
+ 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
+ and revised. Changes to the parts of these sections moved to
+ [RFC4512] are detailed in [RFC4512].
+
+ 3. BNF descriptions of syntax formats have been replaced by ABNF
+ [RFC4234] specifications.
+
+ 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
+ use of a backslash quoting mechanism to escape separator symbols
+ has been removed. The escaping mechanism is now explicitly
+ represented in the ABNF for the syntaxes where this provision
+ applies.
+
+ 5. The description of each of the LDAP syntaxes has been expanded so
+ that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
+ definitions has been made explicit.
+
+ 7. The set of characters allowed in a <PrintableString> (formerly
+ <printablestring>) has been corrected to align with the
+ PrintableString ASN.1 type in [ASN.1]. Specifically, the double
+ quote character has been removed and the single quote character
+ and equals sign have been added.
+
+ 8. Values of the Directory String, Printable String and Telephone
+ Number syntaxes are now required to have at least one character.
+
+ 9. The <DITContentRuleDescription>, <NameFormDescription> and
+ <DITStructureRuleDescription> rules have been moved to [RFC4512].
+
+ 10. The corresponding ASN.1 type for the Other Mailbox syntax has
+ been incorporated from RFC 1274.
+
+ 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
+ has been invented.
+
+ 12. The Binary syntax has been removed because it was not adequately
+ specified, implementations with different incompatible
+ interpretations exist, and it was confused with the ;binary
+ transfer encoding.
+
+
+
+
+Legg Standards Track [Page 50]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ 13. All discussion of transfer options, including the ";binary"
+ option, has been removed. All imperatives regarding binary
+ transfer of values have been removed.
+
+ 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
+ Terminal Identifier and Telex Number syntaxes from RFC 2256 have
+ been incorporated.
+
+ 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
+ been extended to accommodate empty "and" and "or" expressions.
+
+ 16. An encoding for the <ttx-value> rule in the Teletex Terminal
+ Identifier syntax has been defined.
+
+ 17. The PKI-related syntaxes (Certificate, Certificate List and
+ Certificate Pair) have been removed. They are reintroduced in
+ [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
+
+ 18. The MHS OR Address syntax has been removed since its
+ specification (in RFC 2156) is not at draft standard maturity.
+
+ 19. The DL Submit Permission syntax has been removed as it depends on
+ the MHS OR Address syntax.
+
+ 20. The Presentation Address syntax has been removed since its
+ specification (in RFC 1278) is not at draft standard maturity.
+
+ 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
+ Type, LDAP Schema Description, Master And Shadow Access Points,
+ Modify Rights, Protocol Information, Subtree Specification,
+ Supplier Information, Supplier Or Consumer and Supplier And
+ Consumer syntaxes have been removed. These syntaxes are
+ referenced in RFC 2252, but not defined.
+
+ 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
+ Mail Preference syntax have been removed on the grounds that they
+ are out of scope for the core specification.
+
+ 23. The description of each of the matching rules has been expanded
+ so that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+ been added.
+
+ 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
+ caseIgnoreSubstringsMatch matching rules have been added to the
+ list of matching rules for which the provisions for handling
+
+
+
+Legg Standards Track [Page 51]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ leading, trailing and multiple adjoining whitespace characters
+ apply (now through string preparation). This is consistent with
+ the definitions of these matching rules in X.500. The
+ caseIgnoreIA5SubstringsMatch rule has also been added to the
+ list.
+
+ 26. The specification of the octetStringMatch matching rule from
+ RFC 2256 has been added to this document.
+
+ 27. The presentationAddressMatch matching rule has been removed as it
+ depends on an assertion syntax (Presentation Address) that is not
+ at draft standard maturity.
+
+ 28. The protocolInformationMatch matching rule has been removed as it
+ depends on an undefined assertion syntax (Protocol Information).
+
+ 29. The definitive reference for ASN.1 has been changed from X.208 to
+ X.680 since X.680 is the version of ASN.1 referred to by X.500.
+
+ 30. The specification of the caseIgnoreListSubstringsMatch matching
+ rule from RFC 2798 & X.520 has been added.
+
+ 31. String preparation algorithms have been applied to the character
+ string matching rules.
+
+ 32. The specifications of the booleanMatch, caseExactMatch,
+ caseExactOrderingMatch, caseExactSubstringsMatch,
+ directoryStringFirstComponentMatch, integerOrderingMatch,
+ keywordMatch, numericStringOrderingMatch,
+ octetStringOrderingMatch and wordMatch matching rules from
+ RFC 3698 & X.520 have been added.
+
+Author's Address
+
+ Steven Legg
+ eB2Bcom
+ Suite3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg@eb2bcom.com
+
+
+
+
+
+
+
+Legg Standards Track [Page 52]
+\f
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Legg Standards Track [Page 53]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4518 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Internationalized String Preparation
+
+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 (2006).
+
+Abstract
+
+ The previous Lightweight Directory Access Protocol (LDAP) technical
+ specifications did not precisely define how character string matching
+ is to be performed. This led to a number of usability and
+ interoperability problems. This document defines string preparation
+ algorithms for character-based matching rules defined for use in
+ LDAP.
+
+1. Introduction
+
+1.1. Background
+
+ A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
+ rule [RFC4517] defines an algorithm for determining whether a
+ presented value matches an attribute value in accordance with the
+ criteria defined for the rule. The proposition may be evaluated to
+ True, False, or Undefined.
+
+ True - the attribute contains a matching value,
+
+ False - the attribute contains no matching value,
+
+ Undefined - it cannot be determined whether the attribute contains
+ a matching value.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For instance, the caseIgnoreMatch matching rule may be used to
+ compare whether the commonName attribute contains a particular value
+ without regard for case and insignificant spaces.
+
+1.2. X.500 String Matching Rules
+
+ "X.520: Selected attribute types" [X.520] provides (among other
+ things) value syntaxes and matching rules for comparing values
+ commonly used in the directory [X.500]. These specifications are
+ inadequate for strings composed of Unicode [Unicode] characters.
+
+ The caseIgnoreMatch matching rule [X.520], for example, is simply
+ defined as being a case-insensitive comparison where insignificant
+ spaces are ignored. For printableString, there is only one space
+ character and case mapping is bijective, hence this definition is
+ sufficient. However, for Unicode string types such as
+ universalString, this is not sufficient. For example, a case-
+ insensitive matching implementation that folded lowercase characters
+ to uppercase would yield different results than an implementation
+ that used uppercase to lowercase folding. Or one implementation may
+ view space as referring to only SPACE (U+0020), a second
+ implementation may view any character with the space separator (Zs)
+ property as a space, and another implementation may view any
+ character with the whitespace (WS) category as a space.
+
+ The lack of precise specification for character string matching has
+ led to significant interoperability problems. When used in
+ certificate chain validation, security vulnerabilities can arise. To
+ address these problems, this document defines precise algorithms for
+ preparing character strings for matching.
+
+1.3. Relationship to "stringprep"
+
+ The character string preparation algorithms described in this
+ document are based upon the "stringprep" approach [RFC3454]. In
+ "stringprep", presented and stored values are first prepared for
+ comparison so that a character-by-character comparison yields the
+ "correct" result.
+
+ The approach used here is a refinement of the "stringprep" [RFC3454]
+ approach. Each algorithm involves two additional preparation steps.
+
+ a) Prior to applying the Unicode string preparation steps outlined in
+ "stringprep", the string is transcoded to Unicode.
+
+ b) After applying the Unicode string preparation steps outlined in
+ "stringprep", the string is modified to appropriately handle
+ characters insignificant to the matching rule.
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ Hence, preparation of character strings for X.500 [X.500] matching
+ [X.501] involves the following steps:
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check Bidi (Bidirectional)
+ 6) Insignificant Character Handling
+
+ These steps are described in Section 2.
+
+ It is noted that while various tables of Unicode characters included
+ or referenced by this specification are derived from Unicode
+ [Unicode] data, these tables are to be considered definitive for the
+ purpose of implementing this specification.
+
+1.4. Relationship to the LDAP Technical Specification
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ This document details new LDAP internationalized character string
+ preparation algorithms used by [RFC4517] and possible other technical
+ specifications defining LDAP syntaxes and/or matching rules.
+
+1.5. Relationship to X.500
+
+ LDAP is defined [RFC4510] in X.500 terms as an X.500 access
+ mechanism. As such, there is a strong desire for alignment between
+ LDAP and X.500 syntax and semantics. The character string
+ preparation algorithms described in this document are based upon
+ "Internationalized String Matching Rules for X.500" [XMATCH] proposal
+ to ITU/ISO Joint Study Group 2.
+
+1.6. Conventions and Terms
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+ In the lists of mappings and the prohibited characters, the "U+" is
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ left off to make the lists easier to read. The comments for
+ character ranges are shown in square brackets (such as "[CONTROL
+ CHARACTERS]") and do not come from the standard.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+ The term "combining mark", as used in this specification, refers to
+ any Unicode [Unicode] code point that has a mark property (Mn, Mc,
+ Me). Appendix A provides a definitive list of combining marks.
+
+2. String Preparation
+
+ The following six-step process SHALL be applied to each presented and
+ attribute value in preparation for character string matching rule
+ evaluation.
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check bidi
+ 6) Insignificant Character Handling
+
+ Failure in any step causes the assertion to evaluate to Undefined.
+
+ The character repertoire of this process is Unicode 3.2 [Unicode].
+
+ Note that this six-step process specification is intended to describe
+ expected matching behavior. Implementations are free to use
+ alternative processes so long as the matching rule evaluation
+ behavior provided is consistent with the behavior described by this
+ specification.
+
+2.1. Transcode
+
+ Each non-Unicode string value is transcoded to Unicode.
+
+ PrintableString [X.680] values are transcoded directly to Unicode.
+
+ UniversalString, UTF8String, and bmpString [X.680] values need not be
+ transcoded as they are Unicode-based strings (in the case of
+ bmpString, a subset of Unicode).
+
+ TeletexString [X.680] values are transcoded to Unicode. As there is
+ no standard for mapping TeletexString values to Unicode, the mapping
+ is left a local matter.
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For these and other reasons, use of TeletexString is NOT RECOMMENDED.
+
+ The output is the transcoded string.
+
+2.2. Map
+
+ SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+ points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
+ VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
+ mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+ mapped to nothing.
+
+ CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+ TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+ (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+ All other control code (e.g., Cc) points or code points with a
+ control function (e.g., Cf) are mapped to nothing. The following is
+ a complete list of these code points: U+0000-0008, 000E-001F, 007F-
+ 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
+ 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
+
+ ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code
+ points with Separator (space, line, or paragraph) property (e.g., Zs,
+ Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete
+ list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
+ 202F, 205F, 3000.
+
+ For case ignore, numeric, and stored prefix string matching rules,
+ characters are case folded per B.2 of [RFC3454].
+
+ The output is the mapped string.
+
+2.3. Normalize
+
+ The input string is to be normalized to Unicode Form KC
+ (compatibility composed) as described in [UAX15]. The output is the
+ normalized string.
+
+2.4. Prohibit
+
+ All Unassigned code points are prohibited. Unassigned code points
+ are listed in Table A.1 of [RFC3454].
+
+ Characters that, per Section 5.8 of [RFC3454], change display
+ properties or are deprecated are prohibited. These characters are
+ listed in Table C.8 of [RFC3454].
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ Private Use code points are prohibited. These characters are listed
+ in Table C.3 of [RFC3454].
+
+ All non-character code points are prohibited. These code points are
+ listed in Table C.4 of [RFC3454].
+
+ Surrogate codes are prohibited. These characters are listed in Table
+ C.5 of [RFC3454].
+
+ The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+ The step fails if the input string contains any prohibited code
+ point. Otherwise, the output is the input string.
+
+2.5. Check bidi
+
+ Bidirectional characters are ignored.
+
+2.6. Insignificant Character Handling
+
+ In this step, the string is modified to ensure proper handling of
+ characters insignificant to the matching rule. This modification
+ differs from matching rule to matching rule.
+
+ Section 2.6.1 applies to case ignore and exact string matching.
+ Section 2.6.2 applies to numericString matching.
+ Section 2.6.3 applies to telephoneNumber matching.
+
+2.6.1. Insignificant Space Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ NOTE - The previous steps ensure that the string cannot contain
+ any code points in the separator class, other than SPACE
+ (U+0020).
+
+ For input strings that are attribute values or non-substring
+ assertion values: If the input string contains no non-space
+ character, then the output is exactly two SPACEs. Otherwise (the
+ input string contains at least one non-space character), the string
+ is modified such that the string starts with exactly one space
+ character, ends with exactly one SPACE character, and any inner
+ (non-empty) sequence of space characters is replaced with exactly two
+ SPACE characters. For instance, the input strings
+ "foo<SPACE>bar<SPACE><SPACE>", result in the output
+ "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For input strings that are substring assertion values: If the string
+ being prepared contains no non-space characters, then the output
+ string is exactly one SPACE. Otherwise, the following steps are
+ taken:
+
+ - If the input string is an initial substring, it is modified to
+ start with exactly one SPACE character;
+
+ - If the input string is an initial or an any substring that ends in
+ one or more space characters, it is modified to end with exactly
+ one SPACE character;
+
+ - If the input string is an any or a final substring that starts in
+ one or more space characters, it is modified to start with exactly
+ one SPACE character; and
+
+ - If the input string is a final substring, it is modified to end
+ with exactly one SPACE character.
+
+ For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
+ an initial substring, the output would be
+ "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring,
+ the same input would result in "foo<SPACE>bar<SPACE>".
+
+ Appendix B discusses the rationale for the behavior.
+
+2.6.2. numericString Insignificant Character Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ All spaces are regarded as insignificant and are to be removed.
+
+ For example, removal of spaces from the Form KC string:
+ "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<SPACE><SPACE><SPACE>"
+ would result in the output string:
+ "" (an empty string).
+
+2.6.3. telephoneNumber Insignificant Character Handling
+
+ For the purposes of this section, a hyphen is defined to be a
+ HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+ NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+ (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ no combining marks and a space is defined to be the SPACE (U+0020)
+ code point followed by no combining marks.
+
+ All hyphens and spaces are considered insignificant and are to be
+ removed.
+
+ For example, removal of hyphens and spaces from the Form KC string:
+ "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<HYPHEN><HYPHEN><HYPHEN>"
+ would result in the (empty) output string:
+ "".
+
+3. Security Considerations
+
+ "Preparation of Internationalized Strings ("stringprep")" [RFC3454]
+ security considerations generally apply to the algorithms described
+ here.
+
+4. Acknowledgements
+
+ The approach used in this document is based upon design principles
+ and algorithms described in "Preparation of Internationalized Strings
+ ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
+ additional guidance was drawn from Unicode Technical Standards,
+ Technical Reports, and Notes.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510,
+ June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms, Version 3.2.0".
+ <http://www.unicode.org/unicode/reports/tr15/tr15-
+ 22.html>, March 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+5.2. Informative References
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
+ for X.500", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+Appendix A. Combining Marks
+
+ This appendix is normative.
+
+ This table was derived from Unicode [Unicode] data files; it lists
+ all code points with the Mn, Mc, or Me properties. This table is to
+ be considered definitive for the purposes of implementation of this
+ specification.
+
+ 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
+ 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
+ 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
+ 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
+ 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
+ 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
+ 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
+ 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
+ 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
+ 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
+ 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
+ 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
+ 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
+ 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
+ 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
+ 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
+ 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
+ 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
+ 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
+ 1D1AA-1D1AD
+
+Appendix B. Substrings Matching
+
+ This appendix is non-normative.
+
+ In the absence of substrings matching, the insignificant space
+ handling for case ignore/exact matching could be simplified.
+ Specifically, the handling could be to require that all sequences of
+ one or more spaces be replaced with one space and, if the string
+ contains non-space characters, removal of all leading spaces and
+ trailing spaces.
+
+ In the presence of substrings matching, this simplified space
+ handling would lead to unexpected and undesirable matching behavior.
+ For instance:
+
+ 1) (CN=foo\20*\20bar) would match the CN value "foobar";
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ 2) (CN=*\20foobar\20*) would match "foobar", but
+ (CN=*\20*foobar*\20*) would not.
+
+ Note to readers not familiar with LDAP substrings matching: the LDAP
+ filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
+ the attribute CN) that begins with A, contains B after A, ends with C
+ where C is also after B."
+
+ The first case illustrates that this simplified space handling would
+ cause leading and trailing spaces in substrings of the string to be
+ regarded as insignificant. However, only leading and trailing (as
+ well as multiple consecutive spaces) of the string (as a whole) are
+ insignificant.
+
+ The second case illustrates that this simplified space handling would
+ cause sub-partitioning failures. That is, if a prepared any
+ substring matches a partition of the attribute value, then an
+ assertion constructed by subdividing that substring into multiple
+ substrings should also match.
+
+ In designing an appropriate approach for space handling for
+ substrings matching, one must study key aspects of X.500 case
+ exact/ignore matching. X.520 [X.520] says:
+
+ The [substrings] rule returns TRUE if there is a partitioning of
+ the attribute value (into portions) such that:
+
+ - the specified substrings (initial, any, final) match
+ different portions of the value in the order of the strings
+ sequence;
+
+ - initial, if present, matches the first portion of the value;
+
+ - final, if present, matches the last portion of the value;
+
+ - any, if present, matches some arbitrary portion of the
+ value.
+
+ That is, the substrings assertion (CN=foo\20*\20bar) matches the
+ attribute value "foo<SPACE><SPACE>bar" as the value can be
+ partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
+ the above requirements.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ X.520 also says:
+
+ [T]he following spaces are regarded as not significant:
+
+ - leading spaces (i.e., those preceding the first character
+ that is not a space);
+
+ - trailing spaces (i.e., those following the last character
+ that is not a space);
+
+ - multiple consecutive spaces (these are taken as equivalent
+ to a single space character).
+
+ This statement applies to the assertion values and attribute values
+ as whole strings, and not individually to substrings of an assertion
+ value. In particular, the statements should be taken to mean that if
+ an assertion value and attribute value match without any
+ consideration to insignificant characters, then that assertion value
+ should also match any attribute value that differs only by inclusion
+ nor removal of insignificant characters.
+
+ Hence the assertion (CN=foo\20*\20bar) matches
+ "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
+ only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
+ of insignificant spaces.
+
+ Astute readers of this text will also note that there are special
+ cases where the specified space handling does not ignore spaces that
+ could be considered insignificant. For instance, the assertion
+ (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
+ (insignificant spaces present in value) or " " (insignificant spaces
+ not present in value). However, as these cases have no practical
+ application that cannot be met by simple assertions, e.g., (cn=\20),
+ and this minor anomaly can only be fully addressed by a preparation
+ algorithm to be used in conjunction with character-by-character
+ partitioning and matching, the anomaly is considered acceptable.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+\f
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group A. Sciberras, Ed.
+Request for Comments: 4519 eB2Bcom
+Obsoletes: 2256 June 2006
+Updates: 2247, 2798, 2377
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Schema for User Applications
+
+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 (2006).
+
+Abstract
+
+ This document is an integral part of the Lightweight Directory Access
+ Protocol (LDAP) technical specification. It provides a technical
+ specification of attribute types and object classes intended for use
+ by LDAP directory clients for many directory services, such as White
+ Pages. These objects are widely used as a basis for the schema in
+ many LDAP directories. This document does not cover attributes used
+ for the administration of directory servers, nor does it include
+ directory objects defined for specific uses in other documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 1]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship with Other Specifications .....................3
+ 1.2. Conventions ................................................4
+ 1.3. General Issues .............................................4
+ 2. Attribute Types .................................................4
+ 2.1. 'businessCategory' .........................................5
+ 2.2. 'c' ........................................................5
+ 2.3. 'cn' .......................................................5
+ 2.4. 'dc' .......................................................6
+ 2.5. 'description' ..............................................6
+ 2.6. 'destinationIndicator' .....................................7
+ 2.7. 'distinguishedName' ........................................7
+ 2.8. 'dnQualifier' ..............................................8
+ 2.9. 'enhancedSearchGuide' ......................................8
+ 2.10. 'facsimileTelephoneNumber' ................................9
+ 2.11. 'generationQualifier' .....................................9
+ 2.12. 'givenName' ...............................................9
+ 2.13. 'houseIdentifier' .........................................9
+ 2.14. 'initials' ...............................................10
+ 2.15. 'internationalISDNNumber' ................................10
+ 2.16. 'l' ......................................................10
+ 2.17. 'member' .................................................11
+ 2.18. 'name' ...................................................11
+ 2.19. 'o' ......................................................11
+ 2.20. 'ou' .....................................................12
+ 2.21. 'owner' ..................................................12
+ 2.22. 'physicalDeliveryOfficeName' .............................12
+ 2.23. 'postalAddress' ..........................................13
+ 2.24. 'postalCode' .............................................13
+ 2.25. 'postOfficeBox' ..........................................14
+ 2.26. 'preferredDeliveryMethod' ................................14
+ 2.27. 'registeredAddress' ......................................14
+ 2.28. 'roleOccupant' ...........................................15
+ 2.29. 'searchGuide' ............................................15
+ 2.30. 'seeAlso' ................................................15
+ 2.31. 'serialNumber' ...........................................16
+ 2.32. 'sn' .....................................................16
+ 2.33. 'st' .....................................................16
+ 2.34. 'street' .................................................17
+ 2.35. 'telephoneNumber' ........................................17
+ 2.36. 'teletexTerminalIdentifier' ..............................17
+ 2.37. 'telexNumber' ............................................18
+ 2.38. 'title' ..................................................18
+ 2.39. 'uid' ....................................................18
+ 2.40. 'uniqueMember' ...........................................19
+ 2.41. 'userPassword' ...........................................19
+
+
+
+Sciberras Standards Track [Page 2]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 2.42. 'x121Address' ............................................20
+ 2.43. 'x500UniqueIdentifier' ...................................20
+ 3. Object Classes .................................................20
+ 3.1. 'applicationProcess' ......................................21
+ 3.2. 'country' .................................................21
+ 3.3. 'dcObject' ................................................21
+ 3.4. 'device' ..................................................21
+ 3.5. 'groupOfNames' ............................................22
+ 3.6. 'groupOfUniqueNames' ......................................22
+ 3.7. 'locality' ................................................23
+ 3.8. 'organization' ............................................23
+ 3.9. 'organizationalPerson' ....................................24
+ 3.10. 'organizationalRole' .....................................24
+ 3.11. 'organizationalUnit' .....................................24
+ 3.12. 'person' .................................................25
+ 3.13. 'residentialPerson' ......................................25
+ 3.14. 'uidObject' ..............................................26
+ 4. IANA Considerations ............................................26
+ 5. Security Considerations ........................................28
+ 6. Acknowledgements ...............................................28
+ 7. References .....................................................29
+ 7.1. Normative References ......................................29
+ 7.2. Informative References ....................................30
+ Appendix A Changes Made Since RFC 2256 ...........................32
+
+1. Introduction
+
+ This document provides an overview of attribute types and object
+ classes intended for use by Lightweight Directory Access Protocol
+ (LDAP) directory clients for many directory services, such as White
+ Pages. Originally specified in the X.500 [X.500] documents, these
+ objects are widely used as a basis for the schema in many LDAP
+ directories. This document does not cover attributes used for the
+ administration of directory servers, nor does it include directory
+ objects defined for specific uses in other documents.
+
+1.1. Relationship with Other Specifications
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety. In terms of RFC 2256,
+ Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections
+ 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The
+ remainder of RFC 2256 is obsoleted by this document. The technical
+ specification for the 'dc' attribute type and 'dcObject' object class
+ found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
+ document. The remainder of RFC 2247 remains in force.
+
+
+
+
+Sciberras Standards Track [Page 3]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ This document updates RFC 2798 by replacing the informative
+ description of the 'uid' attribute type with the definitive
+ description provided in Section 2.39 of this document.
+
+ This document updates RFC 2377 by replacing the informative
+ description of the 'uidObject' object class with the definitive
+ description provided in Section 3.14 of this document.
+
+ A number of schema elements that were included in the previous
+ revision of the LDAP Technical Specification are not included in this
+ revision of LDAP. PKI-related schema elements are now specified in
+ [RFC4523]. Unless reintroduced in future technical specifications,
+ the remainder are to be considered Historic.
+
+ The descriptions in this document SHALL be considered definitive for
+ use in LDAP.
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3. General Issues
+
+ This document references Syntaxes defined in Section 3 of [RFC4517]
+ and Matching Rules defined in Section 4 of [RFC4517].
+
+ The definitions of Attribute Types and Object Classes are written
+ using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
+ AttributeTypeDescription and ObjectClassDescription given in
+ [RFC4512]. Lines have been folded for readability. When such values
+ are transferred as attribute values in the LDAP Protocol, the values
+ will not contain line breaks.
+
+2. Attribute Types
+
+ The attribute types contained in this section hold user information.
+
+ There is no requirement that servers implement the 'searchGuide' and
+ 'teletexTerminalIdentifier' attribute types. In fact, their use is
+ greatly discouraged.
+
+ An LDAP server implementation SHOULD recognize the rest of the
+ attribute types described in this section.
+
+
+
+
+
+
+Sciberras Standards Track [Page 4]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.1. 'businessCategory'
+
+ The 'businessCategory' attribute type describes the kinds of business
+ performed by an organization. Each kind is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Examples: "banking", "transportation", and "real estate".
+
+2.2. 'c'
+
+ The 'c' ('countryName' in X.500) attribute type contains a two-letter
+ ISO 3166 [ISO3166] country code.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+ [RFC4517].
+
+ Examples: "DE", "AU" and "FR".
+
+2.3. 'cn'
+
+ The 'cn' ('commonName' in X.500) attribute type contains names of an
+ object. Each name is one value of this multi-valued attribute. If
+ the object corresponds to a person, it is typically the person's full
+ name.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
+
+ Examples: "Martin K Smith", "Marty Smith" and "printer12".
+
+
+
+
+
+
+Sciberras Standards Track [Page 5]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.4. 'dc'
+
+ The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
+ holding one component, a label, of a DNS domain name
+ [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
+ attribute is a string of ASCII characters adhering to the following
+ ABNF [RFC4234]:
+
+ label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30-39 ; "0"-"9"
+ HYPHEN = %x2D ; hyphen ("-")
+
+ The encoding of IA5String for use in LDAP is simply the characters of
+ the ASCII label. The equality matching rule is case insensitive, as
+ is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
+
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
+ [RFC4517].
+
+ Examples: Valid values include "example" and "com" but not
+ "example.com". The latter is invalid as it contains multiple domain
+ components.
+
+ It is noted that the directory service will not ensure that values of
+ this attribute conform to the host label restrictions [RFC1123]
+ illustrated by the <label> production provided above. It is the
+ directory client's responsibility to ensure that the labels it stores
+ in this attribute are appropriately restricted.
+
+ Directory applications supporting International Domain Names SHALL
+ use the ToASCII method [RFC3490] to produce the domain component
+ label. The special considerations discussed in Section 4 of RFC 3490
+ [RFC3490] should be taken, depending on whether the domain component
+ is used for "stored" or "query" purposes.
+
+2.5. 'description'
+
+ The 'description' attribute type contains human-readable descriptive
+ phrases about the object. Each description is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+
+
+Sciberras Standards Track [Page 6]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.4.13 NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Examples: "a color printer", "Maintenance is done every Monday, at
+ 1pm.", and "distribution list for all technical staff".
+
+2.6. 'destinationIndicator'
+
+ The 'destinationIndicator' attribute type contains country and city
+ strings associated with the object (the addressee) needed to provide
+ the Public Telegram Service. The strings are composed in accordance
+ with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [RFC4517].
+
+ Examples: "AASD" as a destination indicator for Sydney, Australia.
+ "GBLD" as a destination indicator for London, United
+ Kingdom.
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the F.1 and F.31 CCITT Recommendations. It is
+ the application's responsibility to ensure destination indicators
+ that it stores in this attribute are appropriately constructed.
+
+2.7. 'distinguishedName'
+
+ The 'distinguishedName' attribute type is not used as the name of the
+ object itself, but it is instead a base type from which some user
+ attribute types with a DN syntax can inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations that do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+
+
+
+Sciberras Standards Track [Page 7]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.49 NAME 'distinguishedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
+
+2.8. 'dnQualifier'
+
+ The 'dnQualifier' attribute type contains disambiguating information
+ strings to add to the relative distinguished name of an entry. The
+ information is intended for use when merging data from multiple
+ sources in order to prevent conflicts between entries that would
+ otherwise have the same name. Each string is one value of this
+ multi-valued attribute. It is recommended that a value of the
+ 'dnQualifier' attribute be the same for all entries from a particular
+ source.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.46 NAME 'dnQualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [RFC4517].
+
+ Examples: "20050322123345Z" - timestamps can be used to disambiguate
+ information.
+ "123456A" - serial numbers can be used to disambiguate
+ information.
+
+2.9. 'enhancedSearchGuide'
+
+ The 'enhancedSearchGuide' attribute type contains sets of information
+ for use by directory clients in constructing search filters. Each
+ set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [RFC4517].
+
+
+
+
+
+Sciberras Standards Track [Page 8]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ Examples: "person#(sn$APPROX)#wholeSubtree" and
+ "organizationalUnit#(ou$SUBSTR)#oneLevel".
+
+2.10. 'facsimileTelephoneNumber'
+
+ The 'facsimileTelephoneNumber' attribute type contains telephone
+ numbers (and, optionally, the parameters) for facsimile terminals.
+ Each telephone number is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+ 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+ Number syntax [RFC4517].
+
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
+
+2.11. 'generationQualifier'
+
+ The 'generationQualifier' attribute type contains name strings that
+ are typically the suffix part of a person's name. Each string is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
+
+ Examples: "III", "3rd", and "Jr.".
+
+2.12. 'givenName'
+
+ The 'givenName' attribute type contains name strings that are the
+ part of a person's name that is not their surname. Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
+
+ Examples: "Andrew", "Charles", and "Joanne".
+
+2.13. 'houseIdentifier'
+
+ The 'houseIdentifier' attribute type contains identifiers for a
+ building within a location. Each identifier is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+
+
+Sciberras Standards Track [Page 9]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Example: "20" to represent the house number 20.
+
+2.14. 'initials'
+
+ The 'initials' attribute type contains strings of initials of some or
+ all of an individual's names, except the surname(s). Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.43 NAME 'initials'
+ SUP name )
+
+ Examples: "K. A." and "K".
+
+2.15. 'internationalISDNNumber'
+
+ The 'internationalISDNNumber' attribute type contains Integrated
+ Services Digital Network (ISDN) addresses, as defined in the
+ International Telecommunication Union (ITU) Recommendation E.164
+ [E.164]. Each address is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.25 NAME 'internationalISDNNumber'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [RFC4517].
+
+ Example: "0198 333 333".
+
+2.16. 'l'
+
+ The 'l' ('localityName' in X.500) attribute type contains names of a
+ locality or place, such as a city, county, or other geographic
+ region. Each name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+
+
+
+
+Sciberras Standards Track [Page 10]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
+
+ Examples: "Geneva", "Paris", and "Edinburgh".
+
+2.17. 'member'
+
+ The 'member' attribute type contains the distinguished names of
+ objects that are on a list or in a group. Each name is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.31 NAME 'member'
+ SUP distinguishedName )
+
+ Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
+ "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
+ be two members of the financial team (group) at Widget,
+ Inc., in which case, both of these distinguished names
+ would be present as individual values of the member
+ attribute.
+
+2.18. 'name'
+
+ The 'name' attribute type is the attribute supertype from which user
+ attribute types with the name syntax inherit. Such attribute types
+ are typically used for naming. The attribute type is multi-valued.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations that do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.41 NAME 'name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+2.19. 'o'
+
+ The 'o' ('organizationName' in X.500) attribute type contains the
+ names of an organization. Each name is one value of this
+ multi-valued attribute.
+
+
+
+Sciberras Standards Track [Page 11]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.10 NAME 'o'
+ SUP name )
+
+ Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
+
+2.20. 'ou'
+
+ The 'ou' ('organizationalUnitName' in X.500) attribute type contains
+ the names of an organizational unit. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.11 NAME 'ou'
+ SUP name )
+
+ Examples: "Finance", "Human Resources", and "Research and
+ Development".
+
+2.21. 'owner'
+
+ The 'owner' attribute type contains the distinguished names of
+ objects that have an ownership responsibility for the object that is
+ owned. Each owner's name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
+
+ Example: The mailing list object, whose DN is "cn=All Employees,
+ ou=Mailing List,o=Widget\, Inc.", is owned by the Human
+ Resources Director.
+
+ Therefore, the value of the 'owner' attribute within the
+ mailing list object, would be the DN of the director (role):
+ "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
+
+2.22. 'physicalDeliveryOfficeName'
+
+ The 'physicalDeliveryOfficeName' attribute type contains names that a
+ Postal Service uses to identify a post office.
+ (Source: X.520 [X.520])
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 12]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
+
+2.23. 'postalAddress'
+
+ The 'postalAddress' attribute type contains addresses used by a
+ Postal Service to perform services for the object. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [RFC4517].
+
+ Example: "15 Main St.$Ottawa$Canada".
+
+2.24. 'postalCode'
+
+ The 'postalCode' attribute type contains codes used by a Postal
+ Service to identify postal service zones. Each code is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Example: "22180", to identify Vienna, VA, in the USA.
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 13]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.25. 'postOfficeBox'
+
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
+ at a box on the premises of the Postal Service. Each postal box
+ identifier is a single value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.18 NAME 'postOfficeBox'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Example: "Box 45".
+
+2.26. 'preferredDeliveryMethod'
+
+ The 'preferredDeliveryMethod' attribute type contains an indication
+ of the preferred method of getting a message to the object.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+ [RFC4517].
+
+ Example: If the mhs-delivery Delivery Method is preferred over
+ telephone-delivery, which is preferred over all other
+ methods, the value would be: "mhs $ telephone".
+
+2.27. 'registeredAddress'
+
+ The 'registeredAddress' attribute type contains postal addresses
+ suitable for reception of telegrams or expedited documents, where it
+ is necessary to have the recipient accept delivery. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+
+
+
+
+Sciberras Standards Track [Page 14]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [RFC4517].
+
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
+
+2.28. 'roleOccupant'
+
+ The 'roleOccupant' attribute type contains the distinguished names of
+ objects (normally people) that fulfill the responsibilities of a role
+ object. Each distinguished name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+ Example: The role object, "cn=Human Resources
+ Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
+ people whose object names are "cn=Mary
+ Smith,ou=employee,o=Widget\, Inc." and "cn=James
+ Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
+ attribute will contain both of these distinguished names,
+ since they are the occupants of this role.
+
+2.29. 'searchGuide'
+
+ The 'searchGuide' attribute type contains sets of information for use
+ by clients in constructing search filters. It is superseded by
+ 'enhancedSearchGuide', described above in Section 2.9. Each set is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+ 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
+
+ Example: "person#sn$EQ".
+
+2.30. 'seeAlso'
+
+ The 'seeAlso' attribute type contains the distinguished names of
+ objects that are related to the subject object. Each related object
+ name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
+
+
+
+Sciberras Standards Track [Page 15]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ Example: The person object "cn=James Brown,ou=employee,o=Widget\,
+ Inc." is related to the role objects "cn=Football Team
+ Captain,ou=sponsored activities,o=Widget\, Inc." and
+ "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
+ Since the role objects are related to the person object, the
+ 'seeAlso' attribute will contain the distinguished name of
+ each role object as separate values.
+
+2.31. 'serialNumber'
+
+ The 'serialNumber' attribute type contains the serial numbers of
+ devices. Each serial number is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.5 NAME 'serialNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [RFC4517].
+
+ Examples: "WI-3005" and "XF551426".
+
+2.32. 'sn'
+
+ The 'sn' ('surname' in X.500) attribute type contains name strings
+ for the family names of a person. Each string is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
+
+ Example: "Smith".
+
+2.33. 'st'
+
+ The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
+ full names of states or provinces. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+
+ Example: "California".
+
+
+
+Sciberras Standards Track [Page 16]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.34. 'street'
+
+ The 'street' ('streetAddress' in X.500) attribute type contains site
+ information from a postal address (i.e., the street name, place,
+ avenue, and the house number). Each street is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Example: "15 Main St.".
+
+2.35. 'telephoneNumber'
+
+ The 'telephoneNumber' attribute type contains telephone numbers that
+ comply with the ITU Recommendation E.123 [E.123]. Each number is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
+ [RFC4517].
+
+ Example: "+1 234 567 8901".
+
+2.36. 'teletexTerminalIdentifier'
+
+ The withdrawal of Recommendation F.200 has resulted in the withdrawal
+ of this attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+ 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
+ Identifier syntax [RFC4517].
+
+
+
+
+
+Sciberras Standards Track [Page 17]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.37. 'telexNumber'
+
+ The 'telexNumber' attribute type contains sets of strings that are a
+ telex number, country code, and answerback code of a telex terminal.
+ Each set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+ 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
+ [RFC4517].
+
+ Example: "12345$023$ABCDE".
+
+2.38. 'title'
+
+ The 'title' attribute type contains the title of a person in their
+ organizational context. Each title is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.12 NAME 'title'
+ SUP name )
+ Examples: "Vice President", "Software Engineer", and "CEO".
+
+2.39. 'uid'
+
+ The 'uid' ('userid' in RFC 1274) attribute type contains computer
+ system login names associated with the object. Each name is one
+ value of this multi-valued attribute.
+ (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
+
+ ( 0.9.2342.19200300.100.1.1 NAME 'uid'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [RFC4517].
+
+ Examples: "s9709015", "admin", and "Administrator".
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 18]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.40. 'uniqueMember'
+
+ The 'uniqueMember' attribute type contains the distinguished names of
+ an object that is on a list or in a group, where the relative
+ distinguished names of the object include a value that distinguishes
+ between objects when a distinguished name has been reused. Each
+ distinguished name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.50 NAME 'uniqueMember'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
+ syntax [RFC4517].
+
+ Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
+ disbanded, establishing a new battalion with the "same" name
+ would have a unique identifier value added, resulting in
+ "ou=1st Battalion, o=Defense,c=US#'010101'B".
+
+2.41. 'userPassword'
+
+ The 'userPassword' attribute contains octet strings that are known
+ only to the user and the system to which the user has access. Each
+ string is one value of this multi-valued attribute.
+
+ The application SHOULD prepare textual strings used as passwords by
+ transcoding them to Unicode, applying SASLprep [RFC4013], and
+ encoding as UTF-8. The determination of whether a password is
+ textual is a local client matter.
+ (Source: X.509 [X.509])
+
+ ( 2.5.4.35 NAME 'userPassword'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
+ [RFC4517].
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords is strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+ An example of a need for multiple values in the 'userPassword'
+ attribute is an environment where every month the user is expected to
+
+
+
+Sciberras Standards Track [Page 19]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ use a different password generated by some automated system. During
+ transitional periods, like the last and first day of the periods, it
+ may be necessary to allow two passwords for the two consecutive
+ periods to be valid in the system.
+
+2.42. 'x121Address'
+
+ The 'x121Address' attribute type contains data network addresses as
+ defined by ITU Recommendation X.121 [X.121]. Each address is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.24 NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [RFC4517].
+
+ Example: "36111222333444555".
+
+2.43. 'x500UniqueIdentifier'
+
+ The 'x500UniqueIdentifier' attribute type contains binary strings
+ that are used to distinguish between objects when a distinguished
+ name has been reused. Each string is one value of this multi-valued
+ attribute.
+
+ In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
+ This is a different attribute type from both the 'uid' and
+ 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
+ attribute type is defined in [RFC4524].
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
+ [RFC4517].
+
+3. Object Classes
+
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the 'objectClass' attribute (see [RFC4512]).
+
+
+
+
+
+Sciberras Standards Track [Page 20]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+3.1. 'applicationProcess'
+
+ The 'applicationProcess' object class definition is the basis of an
+ entry that represents an application executing in a computer system.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.11 NAME 'applicationProcess'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $
+ ou $
+ l $
+ description ) )
+
+3.2. 'country'
+
+ The 'country' object class definition is the basis of an entry that
+ represents a country.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
+
+3.3. 'dcObject'
+
+ The 'dcObject' object class permits an entry to contains domain
+ component information. This object class is defined as auxiliary,
+ because it will be used in conjunction with an existing structural
+ object class.
+ (Source: RFC 2247 [RFC2247])
+
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ SUP top
+ AUXILIARY
+ MUST dc )
+
+3.4. 'device'
+
+ The 'device' object class is the basis of an entry that represents an
+ appliance, computer, or network element.
+ (Source: X.521 [X.521])
+
+
+
+
+
+Sciberras Standards Track [Page 21]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
+
+3.5. 'groupOfNames'
+
+ The 'groupOfNames' object class is the basis of an entry that
+ represents a set of named objects including information related to
+ the purpose or maintenance of the set.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.9 NAME 'groupOfNames'
+ SUP top
+ STRUCTURAL
+ MUST ( member $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.6. 'groupOfUniqueNames'
+
+ The 'groupOfUniqueNames' object class is the same as the
+ 'groupOfNames' object class except that the object names are not
+ repeated or reassigned within a set scope.
+ (Source: X.521 [X.521])
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 22]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.7. 'locality'
+
+ The 'locality' object class is the basis of an entry that represents
+ a place in the physical world.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.3 NAME 'locality'
+ SUP top
+ STRUCTURAL
+ MAY ( street $
+ seeAlso $
+ searchGuide $
+ st $
+ l $
+ description ) )
+
+3.8. 'organization'
+
+ The 'organization' object class is the basis of an entry that
+ represents a structured group of people.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.4 NAME 'organization'
+ SUP top
+ STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $
+ businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationalISDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ st $ l $ description ) )
+
+
+
+
+
+Sciberras Standards Track [Page 23]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+3.9. 'organizationalPerson'
+
+ The 'organizationalPerson' object class is the basis of an entry that
+ represents a person in relation to an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.7 NAME 'organizationalPerson'
+ SUP person
+ STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationalISDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ ou $ st $ l ) )
+
+3.10. 'organizationalRole'
+
+ The 'organizationalRole' object class is the basis of an entry that
+ represents a job, function, or position in an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.8 NAME 'organizationalRole'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationalISDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $
+ description ) )
+
+3.11. 'organizationalUnit'
+
+ The 'organizationalUnit' object class is the basis of an entry that
+ represents a piece of an organization.
+ (Source: X.521 [X.521])
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 24]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ ( 2.5.6.5 NAME 'organizationalUnit'
+ SUP top
+ STRUCTURAL
+ MUST ou
+ MAY ( businessCategory $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationalISDNNumber $ l $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ searchGuide $ seeAlso $ st $ street $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ userPassword $ x121Address ) )
+
+3.12 'person'
+
+ The 'person' object class is the basis of an entry that represents a
+ human being.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.6 NAME 'person'
+ SUP top
+ STRUCTURAL
+ MUST ( sn $
+ cn )
+ MAY ( userPassword $
+ telephoneNumber $
+ seeAlso $ description ) )
+
+3.13. 'residentialPerson'
+
+ The 'residentialPerson' object class is the basis of an entry that
+ includes a person's residence in the representation of the person.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.10 NAME 'residentialPerson'
+ SUP person
+ STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationalISDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 25]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+3.14. 'uidObject'
+
+ The 'uidObject' object class permits an entry to contains user
+ identification information. This object class is defined as
+ auxiliary, because it will be used in conjunction with an existing
+ structural object class.
+ (Source: RFC 2377 [RFC2377])
+
+ ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ SUP top
+ AUXILIARY
+ MUST uid )
+
+4. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry as indicated in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comments
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Andrew Sciberras <andrew.sciberras@eb2bcom.com>
+ Usage: (A = attribute type, O = Object Class) see comment
+ Specification: RFC 4519
+ Author/Change Controller: IESG
+
+ Comments
+
+ In the LDAP descriptors registry, the following descriptors (short
+ names) have been updated to refer to RFC 4519. Names that need to
+ be reserved, rather than assigned to an Object Identifier, will
+ contain an Object Identifier value of RESERVED.
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ applicationProcess O 2.5.6.11
+ businessCategory A 2.5.4.15
+ c A 2.5.4.6
+ cn A 2.5.4.3
+ commonName A 2.5.4.3
+ country O 2.5.6.2
+ countryName A 2.5.4.6
+ dc A 0.9.2342.19200300.100.1.25
+ dcObject O 1.3.6.1.4.1.1466.344
+ description A 2.5.4.13
+ destinationIndicator A 2.5.4.27
+ device O 2.5.6.14
+
+
+
+Sciberras Standards Track [Page 26]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ distinguishedName A 2.5.4.49
+ dnQualifier A 2.5.4.46
+ domainComponent A 0.9.2342.19200300.100.1.25
+ enhancedSearchGuide A 2.5.4.47
+ facsimileTelephoneNumber A 2.5.4.23
+ generationQualifier A 2.5.4.44
+ givenName A 2.5.4.42
+ gn A RESERVED
+ groupOfNames O 2.5.6.9
+ groupOfUniqueNames O 2.5.6.17
+ houseIdentifier A 2.5.4.51
+ initials A 2.5.4.43
+ internationalISDNNumber A 2.5.4.25
+ l A 2.5.4.7
+ locality O 2.5.6.3
+ localityName A 2.5.4.7
+ member A 2.5.4.31
+ name A 2.5.4.41
+ o A 2.5.4.10
+ organization O 2.5.6.4
+ organizationName A 2.5.4.10
+ organizationalPerson O 2.5.6.7
+ organizationalRole O 2.5.6.8
+ organizationalUnit O 2.5.6.5
+ organizationalUnitName A 2.5.4.11
+ ou A 2.5.4.11
+ owner A 2.5.4.32
+ person O 2.5.6.6
+ physicalDeliveryOfficeName A 2.5.4.19
+ postalAddress A 2.5.4.16
+ postalCode A 2.5.4.17
+ postOfficeBox A 2.5.4.18
+ preferredDeliveryMethod A 2.5.4.28
+ registeredAddress A 2.5.4.26
+ residentialPerson O 2.5.6.10
+ roleOccupant A 2.5.4.33
+ searchGuide A 2.5.4.14
+ seeAlso A 2.5.4.34
+ serialNumber A 2.5.4.5
+ sn A 2.5.4.4
+ st A 2.5.4.8
+ street A 2.5.4.9
+ surname A 2.5.4.4
+ telephoneNumber A 2.5.4.20
+ teletexTerminalIdentifier A 2.5.4.22
+ telexNumber A 2.5.4.21
+
+
+
+Sciberras Standards Track [Page 27]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ title A 2.5.4.12
+ uid A 0.9.2342.19200300.100.1.1
+ uidObject O 1.3.6.1.1.3.1
+ uniqueMember A 2.5.4.50
+ userid A 0.9.2342.19200300.100.1.1
+ userPassword A 2.5.4.35
+ x121Address A 2.5.4.24
+ x500UniqueIdentifier A 2.5.4.45
+
+5. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations, or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and
+ integrity, since this may result in disclosure of the password to
+ unauthorized parties.
+
+ Multiple attribute values for the 'userPassword' attribute need to be
+ used with care. Especially reset/deletion of a password by an
+ administrator without knowing the old user password gets tricky or
+ impossible if multiple values for different applications are present.
+
+ Certainly, applications that intend to replace the 'userPassword'
+ value(s) with new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). In addition, server
+ implementations are encouraged to provide administrative controls
+ that, if enabled, restrict the 'userPassword' attribute to one value.
+
+ Note that when used for authentication purposes [RFC4513], the user
+ need only prove knowledge of one of the values, not all of the
+ values.
+
+6. Acknowledgements
+
+ The definitions, on which this document is based, have been developed
+ by committees for telecommunications and international standards.
+
+ This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
+ product of the IETF ASID Working Group.
+
+
+
+
+
+
+Sciberras Standards Track [Page 28]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ The 'dc' attribute type definition and the 'dcObject' object class
+ definition in this document supersede the specification in RFC 2247
+ by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
+
+ The 'uid' attribute type definition in this document supersedes the
+ specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
+ and of the uid in RFC 2798 by M. Smith.
+
+ The 'uidObject' object class definition in this document supersedes
+ the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
+ Huber, S. Sataluri, and M. Wahl.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The author wishes to thank S. Legg and K. Zeilenga for their
+ significant contribution to this update. The author would also like
+ to thank Kathy Dally, who edited early versions of this document.
+
+7. References
+
+7.1. Normative References
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988
+
+ [E.164] The international public telecommunication numbering plan,
+ ITU-T Recommendation E.164, 1997
+
+ [F.1] Operational Provisions For The International Public
+ Telegram Service Transmission System, CCITT Recommendation
+ F.1, 1992
+
+ [F.31] Telegram Retransmission System, CCITT Recommendation F.31,
+ 1988
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+
+
+Sciberras Standards Track [Page 29]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+ and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+ [X.121] International numbering plan for public data networks,
+ ITU-T Recommendation X.121, 1996
+
+ [X.509] The Directory: Authentication Framework, ITU-T
+ Recommendation X.509, 1993
+
+ [X.520] The Directory: Selected Attribute Types, ITU-T
+ Recommendation X.520, 1993
+
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
+
+7.2. Informative References
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
+ "Naming Plan for Internet Directory-Enabled Applications",
+ RFC 2377, September 1998.
+
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000.
+
+
+
+Sciberras Standards Track [Page 30]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
+ June 2006.
+
+ [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 31]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+Appendix A. Changes Made Since RFC 2256
+
+ This appendix lists the changes that have been made from RFC 2256 to
+ RFC 4519.
+
+ This appendix is not a normative part of this specification, which
+ has been provided for informational purposes only.
+
+ 1. Replaced the document title.
+
+ 2. Removed the IESG Note.
+
+ 3. Dependencies on RFC 1274 have been eliminated.
+
+ 4. Added a Security Considerations section and an IANA
+ Considerations section.
+
+ 5. Deleted the conformance requirement for subschema object
+ classes in favor of a statement in [RFC4517].
+
+ 6. Added explanation to attribute types and to each object class.
+
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ (moved to [RFC4517]).
+
+ 8. Removed the certificate-related attribute types:
+ authorityRevocationList, cACertificate,
+ certificateRevocationList, crossCertificatePair,
+ deltaRevocationList, supportedAlgorithms, and userCertificate.
+
+ Removed the certificate-related Object Classes:
+ certificationAuthority, certificationAuthority-V2,
+ cRLDistributionPoint, strongAuthenticationUser, and
+ userSecurityInformation
+
+ LDAP PKI is now discussed in [RFC4523].
+
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
+
+ 10. Deleted the aliasedObjectName and objectClass attribute type
+ definitions. Deleted the alias and top object class
+ definitions. They are included in [RFC4512].
+
+
+
+
+
+
+Sciberras Standards Track [Page 32]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 11. Added the 'dc' attribute type from RFC 2247, making the
+ distinction between 'stored' and 'query' values when preparing
+ IDN strings.
+
+ 12. Numerous editorial changes.
+
+ 13. Removed upper bound after the SYNTAX oid in all attribute
+ definitions where it appeared.
+
+ 14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
+ userPassword.
+
+ 15. Included definitions, comments and references for 'dcObject'
+ and 'uidObject'.
+
+ 16. Replaced PKI schema references to use RFC 4523.
+
+ 17. Spelt out and referenced ABNF on first usage.
+
+ 18. Removed Section 2.4 (Source). Replaced the source table with
+ explicit references for each definition.
+
+ 19. All references to an attribute type or object class are
+ enclosed in single quotes.
+
+ 20. The layout of attribute type definitions has been changed to
+ provide consistency throughout the document:
+ > Section Heading
+ > Description of Attribute type
+ > Multivalued description
+ > Source Information
+ > Definition
+ > Example
+ > Additional Comments
+
+ Adding this consistent output included the addition of
+ examples to some definitions.
+
+ 21. References to alternate names for attributes types are
+ provided with a reference to where they were originally
+ specified.
+
+ 22. Clarification of the description of 'distinguishedName' and
+ 'name', in regards to these attribute types being supertypes.
+
+ 23. Spelt out ISDN on first usage.
+
+
+
+
+
+Sciberras Standards Track [Page 33]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 24. Inserted a reference to [RFC4517] for the
+ 'teletexTerminalIdentifier' definition's SYNTAX OID.
+
+ 25. Additional names were added to the IANA Considerations. Names
+ include 'commonName', 'dcObject', 'domainComponent', 'GN',
+ 'localityName', 'organizationName', 'organizationUnitName',
+ 'surname', 'uidObject' and 'userid'.
+
+ 26. Renamed all instances of supercede to supersede.
+
+ 27. Moved [F.1], [F.31] and [RFC4013] from informative to
+ normative references.
+
+ 28. Changed the 'c' definition to be consistent with X.500.
+
+Author's Address
+
+ Andrew Sciberras
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre,
+ 935 Station Street,
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7833
+ EMail: andrew.sciberras@eb2bcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 34]
+\f
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 35]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4520 OpenLDAP Foundation
+BCP: 64 June 2006
+Obsoletes: 3383
+Category: Best Current Practice
+
+
+ Internet Assigned Numbers Authority (IANA) Considerations for
+ the Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of the Lightweight Directory Access Protocol (LDAP). The document
+ also provides guidelines to the Internet Assigned Numbers Authority
+ (IANA) describing conditions under which new values can be assigned.
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
+ extensible protocol. LDAP supports:
+
+ - the addition of new operations,
+ - the extension of existing operations, and
+ - the extensible schema.
+
+ This document details procedures for registering values used to
+ unambiguously identify extensible elements of the protocol, including
+ the following:
+
+ - LDAP message types
+ - LDAP extended operations and controls
+ - LDAP result codes
+ - LDAP authentication methods
+ - LDAP attribute description options
+ - Object Identifier descriptors
+
+
+
+
+
+Zeilenga Best Current Practice [Page 1]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+ This document replaces RFC 3383.
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+ The term "registration owner" (or "owner") refers to the party
+ authorized to change a value's registration.
+
+2.2. Requirement Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this case, "the specification", as used by BCP 14, refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [RFC4234]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ LDIGIT = %x31-39 ; "1"-"9"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ HYPHEN = %x2D ; "-"
+ DOT = %x2E ; "."
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ keychar = ALPHA / DIGIT / HYPHEN
+ leadkeychar = ALPHA
+ keystring = leadkeychar *keychar
+ keyword = keystring
+
+ Keywords are case insensitive.
+
+
+
+
+Zeilenga Best Current Practice [Page 2]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value that can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registrations.
+
+ LDAP values specified in RFCs MUST be registered. Other LDAP values,
+ except those in private-use name spaces, SHOULD be registered. RFCs
+ SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
+ values.
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers (OIDs) [X.680]. Specifications that assign OIDs to
+ elements SHOULD state who delegated the OIDs for their use.
+
+ For IETF-developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
+ by others, any properly delegated OID can be used, including those
+ under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+ Enterprise Numbers" (1.3.6.1.4.1.x).
+
+ Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+ Review with Specification Required. Only one OID per specification
+ will be assigned. The specification MAY then assign any number of
+ OIDs within this arc without further coordination with IANA.
+
+ Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+ IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
+ assignment of Internet Private Enterprise Numbers are detailed in RFC
+ 2578 [RFC2578].
+
+ To avoid interoperability problems between early implementations of a
+ "work in progress" and implementations of the published specification
+ (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+ progress" and early implementations. OIDs under the Internet
+ Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+ Practices for IANA assignment of these Internet Experimental numbers
+ are detailed in RFC 2578 [RFC2578].
+
+3.2. Protocol Mechanisms
+
+ LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
+ for discovery of protocol mechanisms identified by OIDs, including
+ the supportedControl, supportedExtension, and supportedFeatures
+ attributes [RFC4512].
+
+
+
+Zeilenga Best Current Practice [Page 3]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ A registry of OIDs used for discovery of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ Protocol mechanisms are registered on a First Come First Served
+ basis.
+
+3.3. LDAP Syntaxes
+
+ This registry provides a listing of LDAP syntaxes [RFC4512]. Each
+ LDAP syntax is identified by an OID. This registry is provided to
+ allow implementors and others to locate the technical specification
+ describing a particular LDAP Syntax.
+
+ LDAP Syntaxes are registered on a First Come First Served with
+ Specification Required basis.
+
+ Note: Unlike object classes, attribute types, and various other kinds
+ of schema elements, descriptors are not used in LDAP to
+ identify LDAP Syntaxes.
+
+3.4. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify select protocol
+ extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
+ extensions, and other objects.
+
+ Although the protocol allows the same descriptor to refer to
+ different object identifiers in certain cases and the registry
+ supports multiple registrations of the same descriptor (each
+ indicating a different kind of schema element and different object
+ identifier), multiple registrations of the same descriptor are to be
+ avoided. All such multiple registration requests require Expert
+ Review.
+
+ Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
+ Unicode characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form (e.g.,
+ 1.1.0.23.40) conforming to the following ABNF:
+
+
+
+Zeilenga Best Current Practice [Page 4]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ numericoid = number 1*( DOT number )
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A value ending with a hyphen ("-") reserves all descriptors that
+ start with that value. For example, the registration of the option
+ "descrFamily-" reserves all options that start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+ The registrant need not "own" the OID being named.
+
+ The OID name space is managed by the ISO/IEC Joint Technical
+ Committee 1 - Subcommittee 6.
+
+3.5. AttributeDescription Options
+
+ An AttributeDescription [RFC4512] can contain zero or more options
+ specifying additional semantics. An option SHALL be restricted to a
+ string of UTF-8 encoded Unicode characters limited by the following
+ ABNF:
+
+ option = keystring
+
+ Options are case insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names that start
+ with the name. For example, the registration of the option
+ "optionFamily-" reserves all options that start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 5]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+3.6. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [RFC4511. The protocolOp CHOICE indicates the type of message
+ encapsulated. Each message type consists of an ASN.1 identifier in
+ the form of a keyword and a non-negative choice number. The choice
+ number is combined with the class (APPLICATION) and data type
+ (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+ encoding. The choice numbers for existing protocol messages are
+ implicit in the protocol's ASN.1 defined in [RFC4511].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages that reduce but do not
+ eliminate the need to add new message types.
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [RFC4511]. Each authentication choice consists of an ASN.1
+ identifier in the form of a keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet.
+ LIMITED USE - method is appropriate for limited use.
+ OBSOLETE - method has been deprecated or otherwise found to
+ be inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of the class OBSOLETE cannot
+ be registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+
+
+
+Zeilenga Best Current Practice [Page 6]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports Simple Authentication and Security Layers
+ [RFC4422] as an authentication choice. SASL is an extensible
+ authentication framework.
+
+3.8. LDAP Result Codes
+
+ LDAP result messages carry a resultCode enumerated value to indicate
+ the outcome of the operation [RFC4511]. Each result code consists of
+ an ASN.1 identifier in the form of a keyword and a non-negative
+ integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+3.9. LDAP Search Scope
+
+ LDAP SearchRequest messages carry a scope-enumerated value to
+ indicate the extent of search within the DIT [RFC4511]. Each search
+ value consists of an ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New scope integers in the range 0-1023 require Standards Action to be
+ registered. New scope integers in the range 1024-4095 require Expert
+ Review with Specification Required. New scope integers in the range
+ 4096-16383 will be registered on a First Come First Served basis.
+ Keywords associated with integers in the range 0-4095 SHALL NOT start
+ with "e-" or "x-". Keywords associated with integers in the range
+ 4096-16383 SHALL start with "e-". Values greater than or equal to
+ 16384 and keywords starting with "x-" are for Private Use and cannot
+ be registered.
+
+3.10. LDAP Filter Choice
+
+ LDAP filters are used in making assertions against an object
+ represented in the directory [RFC4511]. The Filter CHOICE indicates
+ a type of assertion. Each Filter CHOICE consists of an ASN.1
+ identifier in the form of a keyword and a non-negative choice number.
+
+
+
+Zeilenga Best Current Practice [Page 7]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ The choice number is combined with the class (APPLICATION) and data
+ type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+ message's encoding.
+
+ Note: LDAP provides the extensibleMatching choice, which reduces but
+ does not eliminate the need to add new filter choices.
+
+3.11. LDAP ModifyRequest Operation Type
+
+ The LDAP ModifyRequest carries a sequence of modification operations
+ [RFC4511]. Each kind (e.g., add, delete, replace) of operation
+ consists of an ASN.1 identifier in the form of a keyword and a non-
+ negative integer.
+
+ New operation type integers in the range 0-1023 require Standards
+ Action to be registered. New operation type integers in the range
+ 1024-4095 require Expert Review with Specification Required. New
+ operation type integers in the range 4096-16383 will be registered on
+ a First Come First Served basis. Keywords associated with integers
+ in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
+ associated with integers in the range 4096-16383 SHALL start with
+ "e-". Values greater than or equal to 16384 and keywords starting
+ with "x-" are for Private Use and cannot be registered.
+
+3.12. LDAP authzId Prefixes
+
+ Authorization Identities in LDAP are strings conforming to the
+ <authzId> production [RFC4513]. This production is extensible. Each
+ new specific authorization form is identified by a prefix string
+ conforming to the following ABNF:
+
+ prefix = keystring COLON
+ COLON = %x3A ; COLON (":" U+003A)
+
+ Prefixes are case insensitive.
+
+ While the protocol places no maximum length restriction upon prefix
+ strings, they should be short. Prefixes longer than 12 characters
+ may be viewed as too long to register.
+
+ Prefixes beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Prefixes beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other prefixes require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+
+Zeilenga Best Current Practice [Page 8]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+3.13. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well-known attributes was used in the LDAPv2
+ string representation of a distinguished name [RFC1779]. LDAPv2 is
+ now Historic [RFC3494].
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 [RFC4514] uses Object Identifier Descriptors
+ [Section 3.2] (which have a different syntax than directory system
+ names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be regarded as the
+ registration owner of all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory@apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone may
+ subscribe to this list by sending a request to <directory-
+ request@apps.ietf.org>. During the review, objections may be raised
+ by anyone (including the Expert) on the list. After completion of
+ the review, the Expert, based on public comments, SHALL either
+ approve the request and forward it to the IANA OR deny the request.
+ In either case, the Expert SHALL promptly notify the requester of the
+ action. Actions of the Expert may be appealed [RFC2026]. The Expert
+ is appointed by Applications Area Directors. The requester is viewed
+ as the registration owner of values registered under Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana@iana.org>. The
+ requester is viewed as the registration owner of values registered
+ under First Come First Served.
+
+
+
+Zeilenga Best Current Practice [Page 9]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademark issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+ revise the I-D to use registered values.
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on its web site: <http://www.iana.org/>.
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the registration owner is unable or is unwilling to make
+ necessary updates, the IESG MAY assume ownership of the registration
+ in order to update the registration.
+
+5.3. Comments
+
+ For cases where others (anyone other than the registration owner)
+ have significant objections to the claims in a registration and the
+ registration owner does not agree to change the registration,
+ comments MAY be attached to a registration upon Expert Review. For
+ registrations owned by the IESG, the objections SHOULD be addressed
+ by initiating a request for Expert Review.
+
+ The form of these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+6. Security Considerations
+
+ The security considerations detailed in BCP 26 [RFC2434] are
+ generally applicable to this document. Additional security
+ considerations specific to each name space are discussed in Section
+ 3, where appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [RFC4510].
+
+
+
+
+
+Zeilenga Best Current Practice [Page 10]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+7. Acknowledgement
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group (WG). This document is a revision of RFC 3383, also a
+ product of the LDAPBIS WG.
+
+ This document includes text borrowed from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+ Harald Alvestrand.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ STD 58, RFC 2578, April 1999.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+
+
+Zeilenga Best Current Practice [Page 11]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+ 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(2002)
+ (also ISO/IEC 8824-1:2002).
+
+8.2. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC3494] Zeilenga, K.,"Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422, June
+ 2006.
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 12]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values. Note that more than one value may be requested by
+ extending the template by listing multiple values, or through use of
+ tables.
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension or Feature or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 13]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.3. LDAP Syntax Registration Template
+
+ Subject: Request for LDAP Syntax Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.4. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of administrative role, attribute type, matching rule,
+ name form, object class, URL extension, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 14]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.5. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.6. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+Zeilenga Best Current Practice [Page 15]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.8. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.8. LDAP Search Scope Registration Template
+
+ Subject: Request for LDAP Search Scope Registration
+
+ Search Scope Name:
+
+ Filter Scope String:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 16]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.9. LDAP Filter Choice Registration Template
+
+ Subject: Request for LDAP Filter Choice Registration
+
+ Filter Choice Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.10. LDAP ModifyRequest Operation Registration Template
+
+ Subject: Request for LDAP ModifyRequest Operation Registration
+
+ ModifyRequest Operation Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+Appendix B. Changes since RFC 3383
+
+ This informative appendix provides a summary of changes made since
+ RFC 3383.
+
+ - Object Identifier Descriptors practices were updated to require
+ all descriptors defined in RFCs to be registered and
+ recommending all other descriptors (excepting those in
+ private-use name space) be registered. Additionally, all
+ requests for multiple registrations of the same descriptor are
+ now subject to Expert Review.
+
+ - Protocol Mechanisms practices were updated to include values of
+ the 'supportedFeatures' attribute type.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 17]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+ operation, and authzId prefixes registries were added.
+
+ - References to RFCs comprising the LDAP technical specifications
+ have been updated to latest revisions.
+
+ - References to ISO 10646 have been replaced with [Unicode].
+
+ - The "Assigned Values" appendix providing initial registry
+ values was removed.
+
+ - Numerous editorial changes were made.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 18]
+\f
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 19]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4521 OpenLDAP Foundation
+BCP: 118 June 2006
+Category: Best Current Practice
+
+
+ Considerations for
+ Lightweight Directory Access Protocol (LDAP) Extensions
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is extensible. It
+ provides mechanisms for adding new operations, extending existing
+ operations, and expanding user and system schemas. This document
+ discusses considerations for designers of LDAP extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 1]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 2. General Considerations ..........................................4
+ 2.1. Scope of Extension .........................................4
+ 2.2. Interaction between extensions .............................4
+ 2.3. Discovery Mechanism ........................................4
+ 2.4. Internationalization Considerations ........................5
+ 2.5. Use of the Basic Encoding Rules ............................5
+ 2.6. Use of Formal Languages ....................................5
+ 2.7. Examples ...................................................5
+ 2.8. Registration of Protocol Values ............................5
+ 3. LDAP Operation Extensions .......................................6
+ 3.1. Controls ...................................................6
+ 3.1.1. Extending Bind Operation with Controls ..............6
+ 3.1.2. Extending the Start TLS Operation with Controls .....7
+ 3.1.3. Extending the Search Operation with Controls ........7
+ 3.1.4. Extending the Update Operations with Controls .......8
+ 3.1.5. Extending the Responseless Operations with Controls..8
+ 3.2. Extended Operations ........................................8
+ 3.3. Intermediate Responses .....................................8
+ 3.4. Unsolicited Notifications ..................................9
+ 4. Extending the LDAP ASN.1 Definition .............................9
+ 4.1. Result Codes ...............................................9
+ 4.2. LDAP Message Types .........................................9
+ 4.3. Authentication Methods ....................................10
+ 4.4. General ASN.1 Extensibility ...............................10
+ 5. Schema Extensions ..............................................10
+ 5.1. LDAP Syntaxes .............................................11
+ 5.2. Matching Rules ............................................11
+ 5.3. Attribute Types ...........................................12
+ 5.4. Object Classes ............................................12
+ 6. Other Extension Mechanisms .....................................12
+ 6.1. Attribute Description Options .............................12
+ 6.2. Authorization Identities ..................................12
+ 6.3. LDAP URL Extensions .......................................12
+ 7. Security Considerations ........................................12
+ 8. Acknowledgements ...............................................13
+ 9. References .....................................................13
+ 9.1. Normative References ......................................13
+ 9.2. Informative References ....................................15
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 2]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
+ extensible protocol.
+
+ LDAP allows for new operations to be added and for existing
+ operations to be enhanced [RFC4511].
+
+ LDAP allows additional schema to be defined [RFC4512][RFC4517]. This
+ can include additional object classes, attribute types, matching
+ rules, additional syntaxes, and other elements of schema. LDAP
+ provides an ability to extend attribute types with options [RFC4512].
+
+ LDAP supports a Simple Authentication and Security Layer (SASL)
+ authentication method [RFC4511][RFC4513]. SASL [RFC4422] is
+ extensible. LDAP may be extended to support additional
+ authentication methods [RFC4511].
+
+ LDAP supports establishment of Transport Layer Security (TLS)
+ [RFC4511][RFC4513]. TLS [RFC4346] is extensible.
+
+ LDAP has an extensible Uniform Resource Locator (URL) format
+ [RFC4516].
+
+ Lastly, LDAP allows for certain extensions to the protocol's Abstract
+ Syntax Notation - One (ASN.1) [X.680] definition to be made. This
+ facilitates a wide range of protocol enhancements, for example, new
+ result codes needed to support extensions to be added through
+ extension of the protocol's ASN.1 definition.
+
+ This document describes practices that engineers should consider when
+ designing extensions to LDAP.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this document, "the specification", as used by BCP 14, RFC 2119,
+ refers to the engineering of LDAP extensions.
+
+ The term "Request Control" refers to a control attached to a client-
+ generated message sent to a server. The term "Response Control"
+ refers to a control attached to a server-generated message sent to a
+ client.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 3]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ DIT stands for Directory Information Tree.
+ DSA stands for Directory System Agent, a server.
+ DSE stands for DSA-Specific Entry.
+ DUA stands for Directory User Agent, a client.
+ DN stands for Distinguished Name.
+
+2. General Considerations
+
+2.1. Scope of Extension
+
+ Mutually agreeing peers may, within the confines of an extension,
+ agree to significant changes in protocol semantics. However,
+ designers MUST consider the impact of an extension upon protocol
+ peers that have not agreed to implement or otherwise recognize and
+ support the extension. Extensions MUST be "truly optional"
+ [RFC2119].
+
+2.2. Interaction between extensions
+
+ Designers SHOULD consider how extensions they engineer interact with
+ other extensions.
+
+ Designers SHOULD consider the extensibility of extensions they
+ specify. Extensions to LDAP SHOULD themselves be extensible.
+
+ Except where it is stated otherwise, extensibility is implied.
+
+2.3. Discovery Mechanism
+
+ Extensions SHOULD provide adequate discovery mechanisms.
+
+ As LDAP design is based upon the client-request/server-response
+ paradigm, the general discovery approach is for the client to
+ discover the capabilities of the server before utilizing a particular
+ extension. Commonly, this discovery involves querying the root DSE
+ and/or other DSEs for operational information associated with the
+ extension. LDAP provides no mechanism for a server to discover the
+ capabilities of a client.
+
+ The 'supportedControl' attribute [RFC4512] is used to advertise
+ supported controls. The 'supportedExtension' attribute [RFC4512] is
+ used to advertise supported extended operations. The
+ 'supportedFeatures' attribute [RFC4512] is used to advertise
+ features. Other root DSE attributes MAY be defined to advertise
+ other capabilities.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 4]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+2.4. Internationalization Considerations
+
+ LDAP is designed to support the full Unicode [Unicode] repertory of
+ characters. Extensions SHOULD avoid unnecessarily restricting
+ applications to subsets of Unicode (e.g., Basic Multilingual Plane,
+ ISO 8859-1, ASCII, Printable String).
+
+ LDAP Language Tag options [RFC3866] provide a mechanism for tagging
+ text (and other) values with language information. Extensions that
+ define attribute types SHOULD allow use of language tags with these
+ attributes.
+
+2.5. Use of the Basic Encoding Rules
+
+ Numerous elements of LDAP are described using ASN.1 [X.680] and are
+ encoded using a particular subset [Protocol, Section 5.2] of the
+ Basic Encoding Rules (BER) [X.690]. To allow reuse of
+ parsers/generators used in implementing the LDAP "core" technical
+ specification [RFC4510], it is RECOMMENDED that extension elements
+ (e.g., extension specific contents of controlValue, requestValue,
+ responseValue fields) described by ASN.1 and encoded using BER be
+ subjected to the restrictions of [Protocol, Section 5.2].
+
+2.6. Use of Formal Languages
+
+ Formal languages SHOULD be used in specifications in accordance with
+ IESG guidelines [FORMAL].
+
+2.7. Examples
+
+ Example DN strings SHOULD conform to the syntax defined in [RFC4518].
+ Example LDAP filter strings SHOULD conform to the syntax defined in
+ [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in
+ [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849].
+
+2.8. Registration of Protocol Values
+
+ Designers SHALL register protocol values of their LDAP extensions in
+ accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that
+ create new extensible protocol elements SHALL extend existing
+ registries or establish new registries for values of these elements
+ in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
+ [RFC2434].
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 5]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+3. LDAP Operation Extensions
+
+ Extensions SHOULD use controls in defining extensions that complement
+ existing operations. Where the extension to be defined does not
+ complement an existing operation, designers SHOULD consider defining
+ an extended operation instead.
+
+ For example, a subtree delete operation could be designed as either
+ an extension of the delete operation or as a new operation. As the
+ feature complements the existing delete operation, use of the control
+ mechanism to extend the delete operation is likely more appropriate.
+
+ As a counter (and contrived) example, a locate services operation (an
+ operation that would return for a DN a set of LDAP URLs to services
+ that may hold the entry named by this DN) could be designed as either
+ a search operation or a new operation. As the feature doesn't
+ complement the search operation (e.g., the operation is not contrived
+ to search for entries held in the Directory Information Tree), it is
+ likely more appropriate to define a new operation using the extended
+ operation mechanism.
+
+3.1. Controls
+
+ Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
+ extending existing operations. The existing operation can be a base
+ operation defined in [RFC4511] (e.g., search, modify) , an extended
+ operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
+ an operation defined as an extension to a base or extended operation.
+
+ Extensions SHOULD NOT return Response controls unless the server has
+ specific knowledge that the client can make use of the control.
+ Generally, the client requests the return of a particular response
+ control by providing a related request control.
+
+ An existing operation MAY be extended to return IntermediateResponse
+ messages [Protocol, Section 4.13].
+
+ Specifications of controls SHALL NOT attach additional semantics to
+ the criticality of controls beyond those defined in [Protocol,
+ Section 4.1.11]. A specification MAY mandate the criticality take on
+ a particular value (e.g., TRUE or FALSE), where appropriate.
+
+3.1.1. Extending Bind Operation with Controls
+
+ Controls attached to the request and response messages of a Bind
+ Operation [RFC4511] are not protected by any security layers
+ established by that Bind operation.
+
+
+
+
+Zeilenga Best Current Practice [Page 6]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ Specifications detailing controls extending the Bind operation SHALL
+ detail that the Bind negotiated security layers do not protect the
+ information contained in these controls and SHALL detail how the
+ information in these controls is protected or why the information
+ does not need protection.
+
+ It is RECOMMENDED that designers consider alternative mechanisms for
+ providing the function. For example, an extended operation issued
+ subsequent to the Bind operation (hence, protected by the security
+ layers negotiated by the Bind operation) might be used to provide the
+ desired function.
+
+ Additionally, designers of Bind control extensions MUST also consider
+ how the controls' semantics interact with individual steps of a
+ multi-step Bind operation. Note that some steps are optional and
+ thus may require special attention in the design.
+
+3.1.2. Extending the Start TLS Operation with Controls
+
+ Controls attached to the request and response messages of a Start TLS
+ Operation [RFC4511] are not protected by the security layers
+ established by the Start TLS operation.
+
+ Specifications detailing controls extending the Start TLS operation
+ SHALL detail that the Start TLS negotiated security layers do not
+ protect the information contained in these controls and SHALL detail
+ how the information in these controls is protected or why the
+ information does not need protection.
+
+ It is RECOMMENDED that designers consider alternative mechanisms for
+ providing the function. For example, an extended operation issued
+ subsequent to the Start TLS operation (hence, protected by the
+ security layers negotiated by the Start TLS operation) might be used
+ to provided the desired function.
+
+3.1.3. Extending the Search Operation with Controls
+
+ The Search operation processing has two distinct phases:
+
+ - finding the base object; and
+
+ - searching for objects at or under that base object.
+
+ Specifications of controls extending the Search Operation should
+ clearly state in which phase(s) the control's semantics apply.
+ Semantics of controls that are not specific to the Search Operation
+ SHOULD apply in the finding phase.
+
+
+
+
+Zeilenga Best Current Practice [Page 7]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+3.1.4. Extending the Update Operations with Controls
+
+ Update operations have properties of atomicity, consistency,
+ isolation, and durability ([ACID]).
+
+ - atomicity: All or none of the DIT changes requested are made.
+
+ - consistency: The resulting DIT state must be conform to schema
+ and other constraints.
+
+ - isolation: Intermediate states are not exposed.
+
+ - durability: The resulting DIT state is preserved until
+ subsequently updated.
+
+ When defining a control that requests additional (or other) DIT
+ changes be made to the DIT, these additional changes SHOULD NOT be
+ treated as part of a separate transaction. The specification MUST be
+ clear as to whether the additional DIT changes are part of the same
+ or a separate transaction as the DIT changes expressed in the request
+ of the base operation.
+
+ When defining a control that requests additional (or other) DIT
+ changes be made to the DIT, the specification MUST be clear as to the
+ order in which these and the base changes are to be applied to the
+ DIT.
+
+3.1.5. Extending the Responseless Operations with Controls
+
+ The Abandon and Unbind operations do not include a response message.
+ For this reason, specifications for controls designed to be attached
+ to Abandon and Unbind requests SHOULD mandate that the control's
+ criticality be FALSE.
+
+3.2. Extended Operations
+
+ Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
+ mechanism for defining new operations. An extended operation
+ consists of an ExtendedRequest message, zero or more
+ IntermediateResponse messages, and an ExtendedResponse message.
+
+3.3. Intermediate Responses
+
+ Extensions SHALL use IntermediateResponse messages instead of
+ ExtendedResponse messages to return intermediate results.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 8]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+3.4. Unsolicited Notifications
+
+ Unsolicited notifications [Protocol, Section 4.4] offer a capability
+ for the server to notify the client of events not associated with the
+ operation currently being processed.
+
+ Extensions SHOULD be designed such that unsolicited notifications are
+ not returned unless the server has specific knowledge that the client
+ can make use of the notification. Generally, the client requests the
+ return of a particular unsolicited notification by performing a
+ related extended operation.
+
+ For example, a time hack extension could be designed to return
+ unsolicited notifications at regular intervals that were enabled by
+ an extended operation (which possibly specified the desired
+ interval).
+
+4. Extending the LDAP ASN.1 Definition
+
+ LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
+ definition [Protocol, Appendix B] to be made.
+
+4.1. Result Codes
+
+ Extensions that specify new operations or enhance existing operations
+ often need to define new result codes. The extension SHOULD be
+ designed such that a client has a reasonably clear indication of the
+ nature of the successful or non-successful result.
+
+ Extensions SHOULD use existing result codes to indicate conditions
+ that are consistent with the intended meaning [RFC4511][X.511] of
+ these codes. Extensions MAY introduce new result codes [RFC4520]
+ where no existing result code provides an adequate indication of the
+ nature of the result.
+
+ Extensions SHALL NOT disallow or otherwise restrict the return of
+ general service result codes, especially those reporting a protocol,
+ service, or security problem, or indicating that the server is unable
+ or unwilling to complete the operation.
+
+4.2. LDAP Message Types
+
+ While extensions can specify new types of LDAP messages by extending
+ the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
+ unnecessary and inappropriate. Existing operation extension
+ mechanisms (e.g., extended operations, unsolicited notifications, and
+ intermediate responses) SHOULD be used instead. However, there may
+ be cases where an extension does not fit well into these mechanisms.
+
+
+
+Zeilenga Best Current Practice [Page 9]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ In such cases, a new extension mechanism SHOULD be defined that can
+ be used by multiple extensions that have similar needs.
+
+4.3. Authentication Methods
+
+ The Bind operation currently supports two authentication methods,
+ simple and SASL. SASL [RFC4422] is an extensible authentication
+ framework used by multiple application-level protocols (e.g., BEEP,
+ IMAP, SMTP). It is RECOMMENDED that new authentication processes be
+ defined as SASL mechanisms. New LDAP authentication methods MAY be
+ added to support new authentication frameworks.
+
+ The Bind operation's primary function is to establish the LDAP
+ association [RFC4513]. No other operation SHALL be defined (or
+ extended) to establish the LDAP association. However, other
+ operations MAY be defined to establish other security associations
+ (e.g., IPsec).
+
+4.4. General ASN.1 Extensibility
+
+ Section 4 of [RFC4511] states the following:
+
+ In order to support future extensions to this protocol,
+ extensibility is implied where it is allowed per ASN.1 (i.e.,
+ sequence, set, choice, and enumerated types are extensible). In
+ addition, ellipses (...) have been supplied in ASN.1 types that
+ are explicitly extensible as discussed in [RFC4520]. Because of
+ the implied extensibility, clients and servers MUST (unless
+ otherwise specified) ignore trailing SEQUENCE components whose
+ tags they do not recognize.
+
+ Designers SHOULD avoid introducing extensions that rely on
+ unsuspecting implementations to ignore trailing components of
+ SEQUENCE whose tags they do not recognize.
+
+5. Schema Extensions
+
+ Extensions defining LDAP schema elements SHALL provide schema
+ definitions conforming with syntaxes defined in [Models, Section
+ 4.1]. While provided definitions MAY be reformatted (line wrapped)
+ for readability, this SHALL be noted in the specification.
+
+ For definitions that allow a NAME field, new schema elements SHOULD
+ provide one and only one name. The name SHOULD be short.
+
+ Each schema definition allows a DESC field. The DESC field, if
+ provided, SHOULD contain a short descriptive phrase. The DESC field
+ MUST be regarded as informational. That is, the specification MUST
+
+
+
+Zeilenga Best Current Practice [Page 10]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ be written such that its interpretation is the same with and without
+ the provided DESC fields.
+
+ The extension SHALL NOT mandate that implementations provide the same
+ DESC field in the schema they publish. Implementors MAY replace or
+ remove the DESC field.
+
+ Published schema elements SHALL NOT be redefined. Replacement schema
+ elements (new OIDs, new NAMEs) SHOULD be defined as needed.
+
+ Schema designers SHOULD reuse existing schema elements, where
+ appropriate. However, any reuse MUST not alter the semantics of the
+ element.
+
+5.1. LDAP Syntaxes
+
+ Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
+ Each extension detailing an LDAP syntax MUST specify the ASN.1 data
+ definition associated with the syntax. A distinct LDAP syntax SHOULD
+ be created for each distinct ASN.1 data definition (including
+ constraints).
+
+ Each LDAP syntax SHOULD have a string encoding defined for it. It is
+ RECOMMENDED that this string encoding be restricted to UTF-8
+ [RFC3629] encoded Unicode [Unicode] characters. Use of Generic
+ String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
+ string encoding rules to provide string encodings for complex ASN.1
+ data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that
+ the string encoding be described using a formal language (e.g., ABNF
+ [RFC4234]). Formal languages SHOULD be used in specifications in
+ accordance with IESG guidelines [FORMAL].
+
+ If no string encoding is defined, the extension SHALL specify how the
+ transfer encoding is to be indicated. Generally, the extension
+ SHOULD mandate use of binary or other transfer encoding option.
+
+5.2. Matching Rules
+
+ Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
+ SUBSTRING) may be associated with an attribute type. In addition,
+ LDAP provides an extensible matching rule mechanism.
+
+ The matching rule specification SHOULD detail which kind of matching
+ rule it is and SHOULD describe which kinds of values it can be used
+ with.
+
+ In addition to requirements stated in the LDAP technical
+ specification, equality matching rules SHOULD be commutative.
+
+
+
+Zeilenga Best Current Practice [Page 11]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+5.3. Attribute Types
+
+ Designers SHOULD carefully consider how the structure of values is to
+ be restricted. Designers SHOULD consider that servers will only
+ enforce constraints of the attribute's syntax. That is, an attribute
+ intended to hold URIs, but that has directoryString syntax, is not
+ restricted to values that are URIs.
+
+ Designers SHOULD carefully consider which matching rules, if any, are
+ appropriate for the attribute type. Matching rules specified for an
+ attribute type MUST be compatible with the attribute type's syntax.
+
+ Extensions specifying operational attributes MUST detail how servers
+ are to maintain and/or utilize values of each operational attribute.
+
+5.4. Object Classes
+
+ Designers SHOULD carefully consider whether each attribute of an
+ object class is required ("MUST") or allowed ("MAY").
+
+ Extensions specifying object classes that allow (or require)
+ operational attributes MUST specify how servers are to maintain
+ and/or utilize entries belonging to these object classes.
+
+6. Other Extension Mechanisms
+
+6.1. Attribute Description Options
+
+ Each option is identified by a string of letters, numbers, and
+ hyphens. This string SHOULD be short.
+
+6.2. Authorization Identities
+
+ Extensions interacting with authorization identities SHALL support
+ the LDAP authzId format [RFC4513]. The authzId format is extensible.
+
+6.3. LDAP URL Extensions
+
+ LDAP URL extensions are identified by a short string, a descriptor.
+ Like other descriptors, the string SHOULD be short.
+
+7. Security Considerations
+
+ LDAP does not place undue restrictions on the kinds of extensions
+ that can be implemented. While this document attempts to outline
+ some specific issues that designers need to consider, it is not (and
+
+
+
+
+
+Zeilenga Best Current Practice [Page 12]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ cannot be) all encompassing. Designers MUST do their own evaluations
+ of the security considerations applicable to their extensions.
+
+ Designers MUST NOT assume that the LDAP "core" technical
+ specification [RFC4510] adequately addresses the specific concerns
+ surrounding their extensions or assume that their extensions have no
+ specific concerns.
+
+ Extension specifications, however, SHOULD note whether security
+ considerations specific to the feature they are extending, as well as
+ general LDAP security considerations, apply to the extension.
+
+8. Acknowledgements
+
+ The author thanks the IETF LDAP community for their thoughtful
+ comments.
+
+ This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
+ Greenblatt.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [RFC3642] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 13]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP)", RFC 3866,
+ July 2004.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Search Filters",
+ RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4518, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422, June
+ 2006.
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 14]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [FORMAL] IESG, "Guidelines for the use of formal languages in IETF
+ specifications",
+ <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
+ specs.txt>, 2001.
+
+ [X.511] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Abstract Service
+ Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(2002)
+ (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2. Informative References
+
+ [ACID] Section 4 of ISO/IEC 10026-1:1992.
+
+ [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in
+ Progress.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+Zeilenga Best Current Practice [Page 15]
+\f
+RFC 4521 LDAP Extensions June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 16]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Legg
+Request for Comments: 4522 eB2Bcom
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option
+
+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 (2006).
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory has a defined syntax (i.e., data type). A syntax
+ definition specifies how attribute values conforming to the syntax
+ are normally represented when transferred in LDAP operations. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values. This
+ document defines an attribute option, the binary option, that can be
+ used to specify that the associated attribute values are instead
+ encoded according to the Basic Encoding Rules (BER) used by X.500
+ directories.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions .....................................................2
+ 3. The Binary Option ...............................................2
+ 4. Syntaxes Requiring Binary Transfer ..............................3
+ 5. Attributes Returned in a Search .................................4
+ 6. All User Attributes .............................................4
+ 7. Conflicting Requests ............................................5
+ 8. Security Considerations .........................................5
+ 9. IANA Considerations .............................................5
+ 10. References .....................................................5
+ 10.1. Normative References ......................................5
+ 10.2. Informative References ....................................6
+
+
+
+
+Legg Standards Track [Page 1]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
+ which constrains the structure and format of its values.
+
+ The description of each syntax [RFC4517] specifies how attribute or
+ assertion values [RFC4512] conforming to the syntax are normally
+ represented when transferred in LDAP operations [RFC4511]. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values.
+
+ This document defines an attribute option, the binary option, which
+ can be used in an attribute description [RFC4512] in an LDAP
+ operation to specify that the associated attribute values or
+ assertion values are, or are requested to be, encoded according to
+ the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
+ directories, instead of the usual LDAP-specific encoding.
+
+ The binary option was originally defined in RFC 2251 [RFC2251]. The
+ LDAP technical specification [RFC4510] has obsoleted the previously
+ defined LDAP technical specification [RFC3377], which included RFC
+ 2251. The binary option was not included in the revised LDAP
+ technical specification for a variety of reasons including
+ implementation inconsistencies. No attempt is made here to resolve
+ the known inconsistencies.
+
+ This document reintroduces the binary option for use with certain
+ attribute syntaxes, such as certificate syntax [RFC4523], that
+ specifically require it. No attempt has been made to address use of
+ the binary option with attributes of syntaxes that do not require its
+ use. Unless addressed in a future specification, this use is to be
+ avoided.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [BCP14].
+
+3. The Binary Option
+
+ The binary option is indicated with the attribute option string
+ "binary" in an attribute description. Note that, like all attribute
+ options, the string representing the binary option is case
+ insensitive.
+
+
+
+
+Legg Standards Track [Page 2]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+ Where the binary option is present in an attribute description, the
+ associated attribute values or assertion values MUST be BER encoded
+ (otherwise the values are encoded according to the LDAP-specific
+ encoding [RFC4517] for the attribute's syntax). Note that it is
+ possible for a syntax to be defined such that its LDAP-specific
+ encoding is exactly the same as its BER encoding.
+
+ In terms of the protocol [RFC4511], the binary option specifies that
+ the contents octets of the associated AttributeValue or
+ AssertionValue OCTET STRING are a complete BER encoding of the
+ relevant value.
+
+ The binary option is not a tagging option [RFC4512], so the presence
+ of the binary option does not specify an attribute subtype. An
+ attribute description containing the binary option references exactly
+ the same attribute as the attribute description without the binary
+ option. The supertype/subtype relationships of attributes with
+ tagging options are not altered in any way by the presence or absence
+ of the binary option.
+
+ An attribute description SHALL be treated as unrecognized if it
+ contains the binary option and the syntax of the attribute does not
+ have an associated ASN.1 type [RFC4517], or the BER encoding of
+ values of that type is not supported.
+
+ The presence or absence of the binary option only affects the
+ transfer of attribute and assertion values in the protocol; servers
+ store any particular attribute value in a format of their choosing.
+
+4. Syntaxes Requiring Binary Transfer
+
+ The attribute values of certain attribute syntaxes are defined
+ without an LDAP-specific encoding and are required to be transferred
+ in the BER-encoded form. For the purposes of this document, these
+ syntaxes are said to have a binary transfer requirement. The
+ certificate, certificate list, certificate pair, and supported
+ algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
+ transfer requirement. These syntaxes also have an additional
+ requirement that the exact BER encoding must be preserved. Note that
+ this is a property of the syntaxes themselves, and not a property of
+ the binary option. In the absence of this requirement, LDAP clients
+ would need to re-encode values using the Distinguished Encoding Rules
+ (DER).
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 3]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+5. Attributes Returned in a Search
+
+ An LDAP search request [RFC4511] contains a list of the attributes
+ (the requested attributes list) to be returned from each entry
+ matching the search filter. An attribute description in the
+ requested attributes list also implicitly requests all subtypes of
+ the attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [RFC4512].
+
+ The requested attributes list MAY contain attribute descriptions with
+ the binary option, but MUST NOT contain two attribute descriptions
+ with the same attribute type and the same tagging options (even if
+ only one of them has the binary option). The binary option in an
+ attribute description in the requested attributes list implicitly
+ applies to all the subtypes of the attribute type in the attribute
+ description (however, see Section 7).
+
+ Attributes of a syntax with the binary transfer requirement, if
+ returned, SHALL be returned in the binary form (i.e., with the binary
+ option in the attribute description and the associated attribute
+ values BER encoded) regardless of whether the binary option was
+ present in the request (for the attribute or for one of its
+ supertypes).
+
+ Attributes of a syntax without the binary transfer requirement, if
+ returned, SHOULD be returned in the form explicitly requested. That
+ is, if the attribute description in the requested attributes list
+ contains the binary option, then the corresponding attribute in the
+ result SHOULD be in the binary form. If the attribute description in
+ the request does not contain the binary option, then the
+ corresponding attribute in the result SHOULD NOT be in the binary
+ form. A server MAY omit an attribute from the result if it does not
+ support the requested encoding.
+
+ Regardless of the encoding chosen, a particular attribute value is
+ returned at most once.
+
+6. All User Attributes
+
+ If the list of attributes in a search request is empty or contains
+ the special attribute description string "*", then all user
+ attributes are requested to be returned.
+
+ Attributes of a syntax with the binary transfer requirement, if
+ returned, SHALL be returned in the binary form.
+
+
+
+
+
+
+Legg Standards Track [Page 4]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+ Attributes of a syntax without the binary transfer requirement and
+ having a defined LDAP-specific encoding SHOULD NOT be returned in the
+ binary form.
+
+ Attributes of a syntax without the binary transfer requirement and
+ without a defined LDAP-specific encoding may be returned in the
+ binary form or omitted from the result.
+
+7. Conflicting Requests
+
+ A particular attribute could be explicitly requested by an attribute
+ description and/or implicitly requested by the attribute descriptions
+ of one or more of its supertypes, or by the special attribute
+ description string "*". If the binary option is present in at least
+ one, but not all, of these attribute descriptions then the effect of
+ the request with respect to binary transfer is implementation
+ defined.
+
+8. Security Considerations
+
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ attribute description option registry [BCP64] as indicated by the
+ following template:
+
+ Subject:
+ Request for LDAP Attribute Description Option Registration
+ Option Name: binary
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@eb2bcom.com>
+ Specification: RFC 4522
+ Author/Change Controller: IESG
+
+10. References
+
+10.1. Normative References
+
+ [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Legg Standards Track [Page 5]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC RFC 4510,
+ June 2006.
+
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+10.2. Informative References
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 6]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+Author's Address
+
+ Dr. Steven Legg
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg@eb2bcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 7]
+\f
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Legg Standards Track [Page 8]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4523 OpenLDAP Foundation
+Obsoletes: 2252, 2256, 2587 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Schema Definitions for X.509 Certificates
+
+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 (2006).
+
+ Abstract
+
+ This document describes schema for representing X.509 certificates,
+ X.521 security information, and related elements in directories
+ accessible using the Lightweight Directory Access Protocol (LDAP).
+ The LDAP definitions for these X.509 and X.521 schema elements
+ replace those provided in RFCs 2252 and 2256.
+
+1. Introduction
+
+ This document provides LDAP [RFC4510] schema definitions [RFC4512]
+ for a subset of elements specified in X.509 [X.509] and X.521
+ [X.521], including attribute types for certificates, cross
+ certificate pairs, and certificate revocation lists; matching rules
+ to be used with these attribute types; and related object classes.
+ LDAP syntax definitions are also provided for associated assertion
+ and attribute values.
+
+ As the semantics of these elements are as defined in X.509 and X.521,
+ knowledge of X.509 and X.521 is necessary to make use of the LDAP
+ schema definitions provided herein.
+
+ This document, together with [RFC4510], obsoletes RFCs 2252 and 2256
+ in their entirety. The changes (in this document) made since RFC
+ 2252 and RFC 2256 include:
+
+ - addition of pkiUser, pkiCA, and deltaCRL classes;
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ - update of attribute types to include equality matching rules in
+ accordance with their X.500 specifications;
+
+ - addition of certificate, certificate pair, certificate list,
+ and algorithm identifier matching rules; and
+
+ - addition of LDAP syntax for assertion syntaxes for these
+ matching rules.
+
+ This document obsoletes RFC 2587. The X.509 schema descriptions for
+ LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. Syntaxes
+
+ This section describes various syntaxes used in LDAP to transfer
+ certificates and related data types.
+
+2.1. Certificate
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
+
+ A value of this syntax is an X.509 Certificate [X.509, clause 7].
+
+ Due to changes made to the definition of a Certificate through time,
+ no LDAP-specific encoding is defined for this syntax. Values of this
+ syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
+ [X.690] and MUST only be transferred using the ;binary transfer
+ option [RFC4522]; that is, by requesting and returning values using
+ attribute descriptions such as "userCertificate;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.2. CertificateList
+
+ ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
+
+ A value of this syntax is an X.509 CertificateList [X.509, clause
+ 7.3].
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ Due to changes made to the definition of a CertificateList through
+ time, no LDAP-specific encoding is defined for this syntax. Values
+ of this syntax SHOULD be encoded using DER [X.690] and MUST only be
+ transferred using the ;binary transfer option [RFC4522]; that is, by
+ requesting and returning values using attribute descriptions such as
+ "certificateRevocationList;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.3. CertificatePair
+
+ ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
+
+ A value of this syntax is an X.509 CertificatePair [X.509, clause
+ 11.2.3].
+
+ Due to changes made to the definition of an X.509 CertificatePair
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [RFC4522]; that
+ is, by requesting and returning values using attribute descriptions
+ such as "crossCertificatePair;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.4. SupportedAlgorithm
+
+ ( 1.3.6.1.4.1.1466.115.121.1.49
+ DESC 'X.509 Supported Algorithm' )
+
+ A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
+ 11.2.7].
+
+ Due to changes made to the definition of an X.509 SupportedAlgorithm
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [RFC4522]; that
+ is, by requesting and returning values using attribute descriptions
+ such as "supportedAlgorithms;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of the value MUST be preserved as presented.
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+2.5. CertificateExactAssertion
+
+ ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateExactAssertion [X.509,
+ clause 11.3.1]. Values of this syntax MUST be encoded using the
+ Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1
+ provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234]
+ grammar for this syntax.
+
+2.6. CertificateAssertion
+
+ ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
+
+ A value of this syntax is an X.509 CertificateAssertion [X.509,
+ clause 11.3.2]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.2 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.7. CertificatePairExactAssertion
+
+ ( 1.3.6.1.1.15.3
+ DESC 'X.509 Certificate Pair Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairExactAssertion
+ [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.8. CertificatePairAssertion
+
+ ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairAssertion [X.509,
+ clause 11.3.4]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.4 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.9. CertificateListExactAssertion
+
+ ( 1.3.6.1.1.15.5
+ DESC 'X.509 Certificate List Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateListExactAssertion
+ [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
+ this syntax.
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+2.10. CertificateListAssertion
+
+ ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
+
+ A value of this syntax is an X.509 CertificateListAssertion [X.509,
+ clause 11.3.6]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.6 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.11. AlgorithmIdentifier
+
+ ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )
+
+ A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
+ 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
+
+ Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this
+ syntax.
+
+3. Matching Rules
+
+ This section introduces a set of certificate and related matching
+ rules for use in LDAP. These rules are intended to act in accordance
+ with their X.500 counterparts.
+
+3.1. certificateExactMatch
+
+ The certificateExactMatch matching rule compares the presented
+ certificate exact assertion value with an attribute value of the
+ certificate syntax as described in clause 11.3.1 of [X.509].
+
+ ( 2.5.13.34 NAME 'certificateExactMatch'
+ DESC 'X.509 Certificate Exact Match'
+ SYNTAX 1.3.6.1.1.15.1 )
+
+3.2. certificateMatch
+
+ The certificateMatch matching rule compares the presented certificate
+ assertion value with an attribute value of the certificate syntax as
+ described in clause 11.3.2 of [X.509].
+
+ ( 2.5.13.35 NAME 'certificateMatch'
+ DESC 'X.509 Certificate Match'
+ SYNTAX 1.3.6.1.1.15.2 )
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+3.3. certificatePairExactMatch
+
+ The certificatePairExactMatch matching rule compares the presented
+ certificate pair exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.3 of [X.509].
+
+ ( 2.5.13.36 NAME 'certificatePairExactMatch'
+ DESC 'X.509 Certificate Pair Exact Match'
+ SYNTAX 1.3.6.1.1.15.3 )
+
+3.4. certificatePairMatch
+
+ The certificatePairMatch matching rule compares the presented
+ certificate pair assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.4 of [X.509].
+
+ ( 2.5.13.37 NAME 'certificatePairMatch'
+ DESC 'X.509 Certificate Pair Match'
+ SYNTAX 1.3.6.1.1.15.4 )
+
+3.5. certificateListExactMatch
+
+ The certificateListExactMatch matching rule compares the presented
+ certificate list exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.5 of [X.509].
+
+ ( 2.5.13.38 NAME 'certificateListExactMatch'
+ DESC 'X.509 Certificate List Exact Match'
+ SYNTAX 1.3.6.1.1.15.5 )
+
+3.6. certificateListMatch
+
+ The certificateListMatch matching rule compares the presented
+ certificate list assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.6 of [X.509].
+
+ ( 2.5.13.39 NAME 'certificateListMatch'
+ DESC 'X.509 Certificate List Match'
+ SYNTAX 1.3.6.1.1.15.6 )
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+3.7. algorithmIdentifierMatch
+
+ The algorithmIdentifierMatch mating rule compares a presented
+ algorithm identifier with an attribute value of the supported
+ algorithm as described in clause 11.3.7 of [X.509].
+
+ ( 2.5.13.40 NAME 'algorithmIdentifier'
+ DESC 'X.509 Algorithm Identifier Match'
+ SYNTAX 1.3.6.1.1.15.7 )
+
+4. Attribute Types
+
+ This section details a set of certificate and related attribute types
+ for use in LDAP.
+
+4.1. userCertificate
+
+ The userCertificate attribute holds the X.509 certificates issued to
+ the user by one or more certificate authorities, as discussed in
+ clause 11.2.1 of [X.509].
+
+ ( 2.5.4.36 NAME 'userCertificate'
+ DESC 'X.509 user certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "userCertificate;binary".
+
+4.2. cACertificate
+
+ The cACertificate attribute holds the X.509 certificates issued to
+ the certificate authority (CA), as discussed in clause 11.2.2 of
+ [X.509].
+
+ ( 2.5.4.37 NAME 'cACertificate'
+ DESC 'X.509 CA certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "cACertificate;binary".
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+4.3. crossCertificatePair
+
+ The crossCertificatePair attribute holds an X.509 certificate pair,
+ as discussed in clause 11.2.3 of [X.509].
+
+ ( 2.5.4.40 NAME 'crossCertificatePair'
+ DESC 'X.509 cross certificate pair'
+ EQUALITY certificatePairExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "crossCertificatePair;binary".
+
+4.4. certificateRevocationList
+
+ The certificateRevocationList attribute holds certificate lists, as
+ discussed in 11.2.4 of [X.509].
+
+ ( 2.5.4.39 NAME 'certificateRevocationList'
+ DESC 'X.509 certificate revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "certificateRevocationList;binary".
+
+4.5. authorityRevocationList
+
+ The authorityRevocationList attribute holds certificate lists, as
+ discussed in 11.2.5 of [X.509].
+
+ ( 2.5.4.38 NAME 'authorityRevocationList'
+ DESC 'X.509 authority revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "authorityRevocationList;binary".
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+4.6. deltaRevocationList
+
+ The deltaRevocationList attribute holds certificate lists, as
+ discussed in 11.2.6 of [X.509].
+
+ ( 2.5.4.53 NAME 'deltaRevocationList'
+ DESC 'X.509 delta revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "deltaRevocationList;binary".
+
+4.7. supportedAlgorithms
+
+ The supportedAlgorithms attribute holds supported algorithms, as
+ discussed in 11.2.7 of [X.509].
+
+ ( 2.5.4.52 NAME 'supportedAlgorithms'
+ DESC 'X.509 supported algorithms'
+ EQUALITY algorithmIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "supportedAlgorithms;binary".
+
+5. Object Classes
+
+ This section details a set of certificate-related object classes for
+ use in LDAP.
+
+5.1. pkiUser
+
+ This object class is used in augment entries for objects that may be
+ subject to certificates, as defined in clause 11.1.1 of [X.509].
+
+ ( 2.5.6.21 NAME 'pkiUser'
+ DESC 'X.509 PKI User'
+ SUP top AUXILIARY
+ MAY userCertificate )
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+5.2. pkiCA
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 11.1.2 of [X.509]
+
+ ( 2.5.6.22 NAME 'pkiCA'
+ DESC 'X.509 PKI Certificate Authority'
+ SUP top AUXILIARY
+ MAY ( cACertificate $ certificateRevocationList $
+ authorityRevocationList $ crossCertificatePair ) )
+
+5.3. cRLDistributionPoint
+
+ This class is used to represent objects that act as CRL distribution
+ points, as discussed in clause 11.1.3 of [X.509].
+
+ ( 2.5.6.19 NAME 'cRLDistributionPoint'
+ DESC 'X.509 CRL distribution point'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( certificateRevocationList $
+ authorityRevocationList $ deltaRevocationList ) )
+
+5.4. deltaCRL
+
+ The deltaCRL object class is used to augment entries to hold delta
+ revocation lists, as discussed in clause 11.1.4 of [X.509].
+
+ ( 2.5.6.23 NAME 'deltaCRL'
+ DESC 'X.509 delta CRL'
+ SUP top AUXILIARY
+ MAY deltaRevocationList )
+
+5.5. strongAuthenticationUser
+
+ This object class is used to augment entries for objects
+ participating in certificate-based authentication, as defined in
+ clause 6.15 of [X.521]. This object class is deprecated in favor of
+ pkiUser.
+
+ ( 2.5.6.15 NAME 'strongAuthenticationUser'
+ DESC 'X.521 strong authentication user'
+ SUP top AUXILIARY
+ MUST userCertificate )
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+5.6. userSecurityInformation
+
+ This object class is used to augment entries with needed additional
+ associated security information, as defined in clause 6.16 of
+ [X.521].
+
+ ( 2.5.6.18 NAME 'userSecurityInformation'
+ DESC 'X.521 user security information'
+ SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+5.7. certificationAuthority
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 6.17 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16 NAME 'certificationAuthority'
+ DESC 'X.509 certificate authority'
+ SUP top AUXILIARY
+ MUST ( authorityRevocationList $
+ certificateRevocationList $ cACertificate )
+ MAY crossCertificatePair )
+
+5.8. certificationAuthority-V2
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 6.18 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+ DESC 'X.509 certificate authority, version 2'
+ SUP certificationAuthority AUXILIARY
+ MAY deltaRevocationList )
+
+6. Security Considerations
+
+ General certificate considerations [RFC3280] apply to LDAP-aware
+ certificate applications. General LDAP security considerations
+ [RFC4510] apply as well.
+
+ While elements of certificate information are commonly signed, these
+ signatures only protect the integrity of the signed information. In
+ the absence of data integrity protections in LDAP (or lower layer,
+ e.g., IPsec), a server is not assured that client certificate request
+ (or other request) was unaltered in transit. Likewise, a client
+ cannot be assured that the results of the query were unaltered in
+
+
+
+
+Zeilenga Standards Track [Page 11]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ transit. Hence, it is generally recommended that implementations
+ make use of authentication and data integrity services in LDAP
+ [RFC4513][RFC4511].
+
+7. IANA Considerations
+
+7.1. Object Identifier Registration
+
+ The IANA has registered an LDAP Object Identifier [RFC4520] for use
+ in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4523
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP X.509 Certificate schema elements
+ introduced in this document.
+
+7.2. Descriptor Registration
+
+ The IANA has updated the LDAP
+ Descriptor registry [RFC44520] as indicated below.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): see table
+ Object Identifier: see table
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see table
+ Specification: RFC 4523
+ Author/Change Controller: IESG
+
+ algorithmIdentifierMatch M 2.5.13.40
+ authorityRevocationList A 2.5.4.38 *
+ cACertificate A 2.5.4.37 *
+ cRLDistributionPoint O 2.5.6.19 *
+ certificateExactMatch M 2.5.13.34
+ certificateListExactMatch M 2.5.13.38
+ certificateListMatch M 2.5.13.39
+ certificateMatch M 2.5.13.35
+ certificatePairExactMatch M 2.5.13.36
+ certificatePairMatch M 2.5.13.37
+ certificateRevocationList A 2.5.4.39 *
+ certificationAuthority O 2.5.6.16 *
+ certificationAuthority-V2 O 2.5.6.16.2 *
+ crossCertificatePair A 2.5.4.40 *
+
+
+
+Zeilenga Standards Track [Page 12]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ deltaCRL O 2.5.6.23 *
+ deltaRevocationList A 2.5.4.53 *
+ pkiCA O 2.5.6.22 *
+ pkiUser O 2.5.6.21 *
+ strongAuthenticationUser O 2.5.6.15 *
+ supportedAlgorithms A 2.5.4.52 *
+ userCertificate A 2.5.4.36 *
+ userSecurityInformation O 2.5.6.18 *
+
+ * Updates previous registration
+
+8. Acknowledgements
+
+ This document is based on X.509, a product of the ITU-T. A number of
+ LDAP schema definitions were based on those found in RFCs 2252 and
+ 2256, both products of the IETF ASID WG. The ABNF productions in
+ Appendix A were provided by Steven Legg. Additional material was
+ borrowed from prior works by David Chadwick and Steven Legg to refine
+ the LDAP X.509 schema.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option", RFC 4522, June 2006.
+
+ [X.509] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Authentication
+ Framework", X.509(2000).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ [X.521] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Selected Object
+ Classes", X.521(2000).
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+ Mapping between X.400 and RFC 822/MIME", RFC 2156, January
+ 1998.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC3642] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R. Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+Appendix A.
+
+ This appendix is informative.
+
+ This appendix provides ABNF [RFC4234] grammars for GSER-based
+ [RFC3641] LDAP-specific encodings specified in this document. These
+ grammars where produced using, and relying on, Common Elements for
+ GSER Encodings [RFC3642].
+
+A.1. CertificateExactAssertion
+
+ CertificateExactAssertion = "{" sp cea-serialNumber ","
+ sp cea-issuer sp "}"
+
+ cea-serialNumber = id-serialNumber msp CertificateSerialNumber
+ cea-issuer = id-issuer msp Name
+
+ id-serialNumber =
+ %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
+ id-issuer = %x69.73.73.75.65.72 ; 'issuer'
+
+ Name = id-rdnSequence ":" RDNSequence
+ id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
+
+ CertificateSerialNumber = INTEGER
+
+A.2. CertificateAssertion
+
+CertificateAssertion = "{" [ sp ca-serialNumber ]
+ [ sep sp ca-issuer ]
+ [ sep sp ca-subjectKeyIdentifier ]
+ [ sep sp ca-authorityKeyIdentifier ]
+ [ sep sp ca-certificateValid ]
+ [ sep sp ca-privateKeyValid ]
+ [ sep sp ca-subjectPublicKeyAlgID ]
+ [ sep sp ca-keyUsage ]
+ [ sep sp ca-subjectAltName ]
+ [ sep sp ca-policy ]
+ [ sep sp ca-pathToName ]
+ [ sep sp ca-subject ]
+ [ sep sp ca-nameConstraints ] sp "}"
+
+ca-serialNumber = id-serialNumber msp CertificateSerialNumber
+ca-issuer = id-issuer msp Name
+ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
+ SubjectKeyIdentifier
+ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+
+
+
+Zeilenga Standards Track [Page 15]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ca-certificateValid = id-certificateValid msp Time
+ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
+ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
+ OBJECT-IDENTIFIER
+ca-keyUsage = id-keyUsage msp KeyUsage
+ca-subjectAltName = id-subjectAltName msp AltNameType
+ca-policy = id-policy msp CertPolicySet
+ca-pathToName = id-pathToName msp Name
+ca-subject = id-subject msp Name
+ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
+
+id-subjectKeyIdentifier =
+ %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'subjectKeyIdentifier'
+id-authorityKeyIdentifier =
+ %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'authorityKeyIdentifier'
+id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
+ ; 'certificateValid'
+id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
+ ; 'privateKeyValid'
+id-subjectPublicKeyAlgID =
+ %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
+ ; 'subjectPublicKeyAlgID'
+id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
+id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
+ ; 'subjectAltName'
+id-policy = %x70.6F.6C.69.63.79 ; 'policy'
+id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
+id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
+id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
+ ; 'nameConstraints'
+
+SubjectKeyIdentifier = KeyIdentifier
+
+KeyIdentifier = OCTET-STRING
+
+AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
+ [ sep sp aki-authorityCertIssuer ]
+ [ sep sp aki-authorityCertSerialNumber ] sp "}"
+
+aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
+aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
+
+GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
+GeneralName = gn-otherName
+ / gn-rfc822Name
+ / gn-dNSName
+
+
+
+Zeilenga Standards Track [Page 16]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ / gn-x400Address
+ / gn-directoryName
+ / gn-ediPartyName
+ / gn-uniformResourceIdentifier
+ / gn-iPAddress
+ / gn-registeredID
+
+gn-otherName = id-otherName ":" OtherName
+gn-rfc822Name = id-rfc822Name ":" IA5String
+gn-dNSName = id-dNSName ":" IA5String
+gn-x400Address = id-x400Address ":" ORAddress
+gn-directoryName = id-directoryName ":" Name
+gn-ediPartyName = id-ediPartyName ":" EDIPartyName
+gn-iPAddress = id-iPAddress ":" OCTET-STRING
+gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
+
+gn-uniformResourceIdentifier = id-uniformResourceIdentifier
+ ":" IA5String
+
+id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
+gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
+ ; 'registeredID'
+
+OtherName = "{" sp on-type-id "," sp on-value sp "}"
+on-type-id = id-type-id msp OBJECT-IDENTIFIER
+on-value = id-value msp Value
+ ;; <Value> as defined in Section 3 of [RFC3641]
+
+id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
+id-value = %x76.61.6C.75.65 ; 'value'
+
+ORAddress = dquote *SafeIA5Character dquote
+SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote ; escaped double quote
+dquote = %x22 ; '"' (double quote)
+
+;; Note: The <ORAddress> rule encodes the x400Address component
+;; of a GeneralName as a character string between double quotes.
+;; The character string is first derived according to Section 4.1
+;; of [RFC2156], and then any embedded double quotes are escaped
+;; by being repeated. This resulting string is output between
+;; double quotes.
+
+EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
+nameAssigner = id-nameAssigner msp DirectoryString
+partyName = id-partyName msp DirectoryString
+id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
+ ; 'nameAssigner'
+
+
+
+Zeilenga Standards Track [Page 17]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
+
+aki-authorityCertSerialNumber = id-authorityCertSerialNumber
+ msp CertificateSerialNumber
+
+id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'keyIdentifier'
+id-authorityCertIssuer =
+ %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
+ ; 'authorityCertIssuer'
+
+id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
+ %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
+ ; 'authorityCertSerialNumber'
+
+Time = time-utcTime / time-generalizedTime
+time-utcTime = id-utcTime ":" UTCTime
+time-generalizedTime = id-generalizedTime ":" GeneralizedTime
+id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
+id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
+ ; 'generalizedTime'
+
+KeyUsage = BIT-STRING / key-usage-bit-list
+key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
+
+;; Note: The <key-usage-bit-list> rule encodes the one bits in
+;; a KeyUsage value as a comma separated list of identifiers.
+
+key-usage = id-digitalSignature
+ / id-nonRepudiation
+ / id-keyEncipherment
+ / id-dataEncipherment
+ / id-keyAgreement
+ / id-keyCertSign
+ / id-cRLSign
+ / id-encipherOnly
+ / id-decipherOnly
+
+id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
+ %x75.72.65 ; 'digitalSignature'
+id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
+ ; 'nonRepudiation'
+id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
+ ; 'keyEncipherment'
+id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
+ %x74 ; "dataEncipherment'
+id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
+ ; 'keyAgreement'
+
+
+
+Zeilenga Standards Track [Page 18]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
+ ; 'keyCertSign'
+id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
+id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'encipherOnly'
+id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'decipherOnly'
+
+AltNameType = ant-builtinNameForm / ant-otherNameForm
+
+ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
+ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
+
+id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
+ ; 'builtinNameForm'
+id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
+ ; 'otherNameForm'
+
+BuiltinNameForm = id-rfc822Name
+ / id-dNSName
+ / id-x400Address
+ / id-directoryName
+ / id-ediPartyName
+ / id-uniformResourceIdentifier
+ / id-iPAddress
+ / id-registeredId
+
+id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
+id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
+id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
+id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
+ ; 'directoryName'
+id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
+ ; 'ediPartyName'
+id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
+id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
+ ; 'registeredId'
+
+id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
+ %x72.63.65.49.64.65.6E.74.69.66.69.65.72
+ ; 'uniformResourceIdentifier'
+
+CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
+CertPolicyId = OBJECT-IDENTIFIER
+
+NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
+ [ sep sp ncs-excludedSubtrees ] sp "}"
+
+
+
+
+Zeilenga Standards Track [Page 19]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
+ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
+
+id-permittedSubtrees =
+ %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
+ ; 'permittedSubtrees'
+id-excludedSubtrees =
+ %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
+ ; 'excludedSubtrees'
+
+GeneralSubtrees = "{" sp GeneralSubtree
+ *( "," sp GeneralSubtree ) sp "}"
+GeneralSubtree = "{" sp gs-base
+ [ "," sp gs-minimum ]
+ [ "," sp gs-maximum ] sp "}"
+
+gs-base = id-base msp GeneralName
+gs-minimum = id-minimum msp BaseDistance
+gs-maximum = id-maximum msp BaseDistance
+
+id-base = %x62.61.73.65 ; 'base'
+id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
+id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
+
+BaseDistance = INTEGER-0-MAX
+
+A.3. CertificatePairExactAssertion
+
+ CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
+ [sep sp cpea-issuedBy ] sp "}"
+ ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
+
+ cpea-issuedTo = id-issuedToThisCAAssertion msp
+ CertificateExactAssertion
+ cpea-issuedBy = id-issuedByThisCAAssertion msp
+ CertificateExactAssertion
+
+ id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
+ id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 20]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+A.4. CertificatePairAssertion
+
+ CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
+ [sep sp cpa-issuedBy ] sp "}"
+ ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
+
+ cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
+ cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
+
+A.5. CertificateListExactAssertion
+
+ CertificateListExactAssertion = "{" sp clea-issuer ","
+ sp clea-thisUpdate
+ [ "," sp clea-distributionPoint ] sp "}"
+
+ clea-issuer = id-issuer msp Name
+ clea-thisUpdate = id-thisUpdate msp Time
+ clea-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+ id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
+ id-distributionPoint =
+ %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
+ ; 'distributionPoint'
+
+ DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
+
+ dpn-fullName = id-fullName ":" GeneralNames
+ dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
+ RelativeDistinguishedName
+
+ id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
+ id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
+ %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
+
+A.6. CertificateListAssertion
+
+ CertificateListAssertion = "{" [ sp cla-issuer ]
+ [ sep sp cla-minCRLNumber ]
+ [ sep sp cla-maxCRLNumber ]
+ [ sep sp cla-reasonFlags ]
+ [ sep sp cla-dateAndTime ]
+ [ sep sp cla-distributionPoint ]
+ [ sep sp cla-authorityKeyIdentifier ] sp "}"
+
+ cla-issuer = id-issuer msp Name
+ cla-minCRLNumber = id-minCRLNumber msp CRLNumber
+ cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
+
+
+
+Zeilenga Standards Track [Page 21]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ cla-reasonFlags = id-reasonFlags msp ReasonFlags
+ cla-dateAndTime = id-dateAndTime msp Time
+
+ cla-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+ cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+
+ id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
+ ; 'minCRLNumber'
+ id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
+ ; 'maxCRLNumber'
+ id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
+ id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
+
+ CRLNumber = INTEGER-0-MAX
+
+ ReasonFlags = BIT-STRING
+ / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
+
+ reason-flag = id-unused
+ / id-keyCompromise
+ / id-cACompromise
+ / id-affiliationChanged
+ / id-superseded
+ / id-cessationOfOperation
+ / id-certificateHold
+ / id-privilegeWithdrawn
+ / id-aACompromise
+
+ id-unused = %x75.6E.75.73.65.64 ; 'unused'
+ id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'keyCompromise'
+ id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'cACompromise'
+ id-affiliationChanged =
+ %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
+ ; 'affiliationChanged'
+ id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
+ id-cessationOfOperation =
+ %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
+ ; 'cessationOfOperation'
+ id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
+ ; 'certificateHold'
+ id-privilegeWithdrawn =
+ %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
+ ; 'privilegeWithdrawn'
+
+
+
+Zeilenga Standards Track [Page 22]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'aACompromise'
+
+A.7. AlgorithmIdentifier
+
+ AlgorithmIdentifier = "{" sp ai-algorithm
+ [ "," sp ai-parameters ] sp "}"
+
+ ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
+ ai-parameters = id-parameters msp Value
+ id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
+ id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 23]
+\f
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4524 OpenLDAP Foundation
+Obsoletes: 1274 June 2006
+Updates: 2247, 2798
+Category: Standards Track
+
+
+ COSINE LDAP/X.500 Schema
+
+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 (2006).
+
+Abstract
+
+ This document provides a collection of schema elements for use with
+ the Lightweight Directory Access Protocol (LDAP) from the COSINE and
+ Internet X.500 pilot projects.
+
+ This document obsoletes RFC 1274 and updates RFCs 2247 and 2798.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other Documents ............................3
+ 1.2. Terminology and Conventions ................................4
+ 2. COSINE Attribute Types ..........................................4
+ 2.1. associatedDomain ...........................................4
+ 2.2. associatedName .............................................5
+ 2.3. buildingName ...............................................5
+ 2.4. co .........................................................5
+ 2.5. documentAuthor .............................................6
+ 2.6. documentIdentifier .........................................6
+ 2.7. documentLocation ...........................................6
+ 2.8. documentPublisher ..........................................7
+ 2.9. documentTitle ..............................................7
+ 2.10. documentVersion ...........................................7
+ 2.11. drink .....................................................8
+ 2.12. homePhone .................................................8
+ 2.13. homePostalAddress .........................................8
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ 2.14. host ......................................................9
+ 2.15. info ......................................................9
+ 2.16. mail ......................................................9
+ 2.17. manager ..................................................10
+ 2.18. mobile ...................................................10
+ 2.19. organizationalStatus .....................................11
+ 2.20. pager ....................................................11
+ 2.21. personalTitle ............................................11
+ 2.22. roomNumber ...............................................12
+ 2.23. secretary ................................................12
+ 2.24. uniqueIdentifier .........................................12
+ 2.25. userClass ................................................13
+ 3. COSINE Object Classes ..........................................13
+ 3.1. account ...................................................13
+ 3.2. document ..................................................14
+ 3.3. documentSeries ............................................14
+ 3.4. domain ....................................................15
+ 3.5. domainRelatedObject .......................................16
+ 3.6. friendlyCountry ...........................................16
+ 3.7. rFC822LocalPart ...........................................17
+ 3.8. room ......................................................18
+ 3.9. simpleSecurityObject ......................................18
+ 4. Security Considerations ........................................18
+ 5. IANA Considerations ............................................19
+ 6. Acknowledgements ...............................................20
+ 7. References .....................................................20
+ 7.1. Normative References ......................................20
+ 7.2. Informative References ....................................21
+ Appendix A. Changes since RFC 1274 ...............................23
+ A.1. LDAP Short Names .........................................23
+ A.2. pilotObject ..............................................23
+ A.3. pilotPerson ..............................................23
+ A.4. dNSDomain ................................................24
+ A.5. pilotDSA and qualityLabelledData .........................24
+ A.6. Attribute Syntaxes .......................................24
+ Appendix B. Changes since RFC 2247 ...............................24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+1. Introduction
+
+ In the late 1980s, X.500 Directory Services were standardized by the
+ CCITT (Commite' Consultatif International de Telegraphique et
+ Telephonique), now a part of the ITU (International Telephone Union).
+ This lead to Directory Service piloting activities in the early
+ 1990s, including the COSINE (Co-operation and Open Systems
+ Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in
+ Europe. Motivated by needs for large-scale directory pilots, RFC
+ 1274 was published to standardize the directory schema and naming
+ architecture for use in the COSINE and other Internet X.500 pilots
+ [RFC1274].
+
+ In the years that followed, X.500 Directory Services have evolved to
+ incorporate new capabilities and even new protocols. In particular,
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
+ introduced in the early 1990s [RFC1487], with Version 3 of LDAP
+ introduced in the late 1990s [RFC2251] and subsequently revised in
+ 2005 [RFC4510].
+
+ While much of the material in RFC 1274 has been superceded by
+ subsequently published ITU-T Recommendations and IETF RFCs, many of
+ the schema elements lack standardized schema descriptions for use in
+ modern X.500 and LDAP directory services despite the fact that these
+ schema elements are in wide use today. As the old schema
+ descriptions cannot be used without adaptation, interoperability
+ issues may arise due to lack of standardized modern schema
+ descriptions.
+
+ This document addresses these issues by offering standardized schema
+ descriptions, where needed, for widely used COSINE schema elements.
+
+1.1. Relationship to Other Documents
+
+ This document, together with [RFC4519] and [RFC4517], obsoletes RFC
+ 1274 in its entirety. [RFC4519] replaces Sections 9.3.1 (Userid) and
+ 9.3.21 (Domain Component) of RFC 1274. [RFC4517] replaces Section
+ 9.4 (Generally useful syntaxes) of RFC 1274.
+
+ This document replaces the remainder of RFC 1274. Appendix A
+ discusses changes since RFC 1274, as well as why certain schema
+ elements were not brought forward in this revision of the COSINE
+ schema. All elements not brought are to be regarded as Historic.
+
+ The description of the 'domain' object class provided in this
+ document supercedes that found in RFC 2247. That is, Section 3.4 of
+ this document replaces Section 5.2 of [RFC2247].
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Some of the schema elements specified here were described in RFC 2798
+ (inetOrgPerson schema). This document supersedes these descriptions.
+ This document, together with [RFC4519], replaces Section 9.1.3 of RFC
+ 2798.
+
+1.2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ DIT stands for Directory Information Tree.
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent, a server.
+ DSE stands for DSA-Specific Entry.
+ DUA stands for Directory User Agent, a client.
+
+ These terms are discussed in [RFC4512].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. COSINE Attribute Types
+
+ This section details COSINE attribute types for use in LDAP.
+
+2.1. associatedDomain
+
+ The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
+ host names [RFC1123] that are associated with an object. That is,
+ values of this attribute should conform to the following ABNF:
+
+ domain = root / label *( DOT label )
+ root = SPACE
+ label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
+ LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
+ SPACE = %x20 ; space (" ")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+
+ For example, the entry in the DIT with a DN <DC=example,DC=com> might
+ have an associated domain of "example.com".
+
+ ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [RFC4517].
+
+ Note that the directory will not ensure that values of this attribute
+ conform to the <domain> production provided above. It is the
+ application's responsibility to ensure that domains it stores in this
+ attribute are appropriately represented.
+
+ Also note that applications supporting Internationalized Domain Names
+ SHALL use the ToASCII method [RFC3490] to produce <label> components
+ of the <domain> production.
+
+2.2. associatedName
+
+ The 'associatedName' attribute specifies names of entries in the
+ organizational DIT associated with a DNS domain [RFC1034][RFC2181].
+
+ ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.3. buildingName
+
+ The 'buildingName' attribute specifies names of the buildings where
+ an organization or organizational unit is based, for example, "The
+ White House".
+
+ ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.4. co
+
+ The 'co' (Friendly Country Name) attribute specifies names of
+ countries in human-readable format, for example, "Germany" and
+ "Federal Republic of Germany". It is commonly used in conjunction
+ with the 'c' (Country Name) [RFC4519] attribute (whose values are
+ restricted to the two-letter codes defined in [ISO3166]).
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ ( 0.9.2342.19200300.100.1.43 NAME 'co'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.5. documentAuthor
+
+ The 'documentAuthor' attribute specifies the distinguished names of
+ authors (or editors) of a document. For example,
+
+ ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.6. documentIdentifier
+
+ The 'documentIdentifier' attribute specifies unique identifiers for a
+ document. A document may be identified by more than one unique
+ identifier. For example, RFC 3383 and BCP 64 are unique identifiers
+ that (presently) refer to the same document.
+
+ ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.7. documentLocation
+
+ The 'documentLocation' attribute specifies locations of the document
+ original.
+
+ ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.8. documentPublisher
+
+ The 'documentPublisher' attribute is the persons and/or organizations
+ that published the document. Documents that are jointly published
+ have one value for each publisher.
+
+ ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.9. documentTitle
+
+ The 'documentTitle' attribute specifies the titles of a document.
+ Multiple values are allowed to accommodate both long and short
+ titles, or other situations where a document has multiple titles, for
+ example, "The Lightweight Directory Access Protocol Technical
+ Specification" and "The LDAP Technical Specification".
+
+ ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.10. documentVersion
+
+ The 'documentVersion' attribute specifies the version information of
+ a document.
+
+ ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.11. drink
+
+ The 'drink' (favoriteDrink) attribute specifies the favorite drinks
+ of an object (or person), for instance, "cola" and "beer".
+
+ ( 0.9.2342.19200300.100.1.5 NAME 'drink'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.12. homePhone
+
+ The 'homePhone' (Home Telephone Number) attribute specifies home
+ telephone numbers (e.g., "+1 775 555 1234") associated with a person.
+
+ ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+2.13. homePostalAddress
+
+ The 'homePostalAddress' attribute specifies home postal addresses for
+ an object. Each value should be limited to up to 6 directory strings
+ of 30 characters each. (Note: It is not intended that the directory
+ service enforce these limits.)
+
+ ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
+ 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+2.14. host
+
+ The 'host' attribute specifies host computers, generally by their
+ primary fully qualified domain name (e.g., my-host.example.com).
+
+ ( 0.9.2342.19200300.100.1.9 NAME 'host'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.15. info
+
+ The 'info' attribute specifies any general information pertinent to
+ an object. This information is not necessarily descriptive of the
+ object.
+
+ Applications should not attach specific semantics to values of this
+ attribute. The 'description' attribute [RFC4519] is available for
+ specifying descriptive information pertinent to an object.
+
+ ( 0.9.2342.19200300.100.1.4 NAME 'info'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.16. mail
+
+ The 'mail' (rfc822mailbox) attribute type holds Internet mail
+ addresses in Mailbox [RFC2821] form (e.g., user@example.com).
+
+ ( 0.9.2342.19200300.100.1.3 NAME 'mail'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Note that the directory will not ensure that values of this attribute
+ conform to the <Mailbox> production [RFC2821]. It is the
+ application's responsibility to ensure that domains it stores in this
+ attribute are appropriately represented.
+
+ Additionally, the directory will compare values per the matching
+ rules named in the above attribute type description. As these rules
+ differ from rules that normally apply to <Mailbox> comparisons,
+ operational issues may arise. For example, the assertion
+ (mail=joe@example.com) will match "JOE@example.com" even though the
+ <local-parts> differ. Also, where a user has two <Mailbox>es whose
+ addresses differ only by case of the <local-part>, both cannot be
+ listed as values of the user's mail attribute (as they are considered
+ equal by the 'caseIgnoreIA5Match' rule).
+
+ Also note that applications supporting internationalized domain names
+ SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
+ components of the <Mailbox> production.
+
+2.17. manager
+
+ The 'manager' attribute specifies managers, by distinguished name, of
+ the person (or entity).
+
+ ( 0.9.2342.19200300.100.1.10 NAME 'manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.18. mobile
+
+ The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
+ telephone numbers (e.g., "+1 775 555 6789") associated with a person
+ (or entity).
+
+ ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+2.19. organizationalStatus
+
+ The 'organizationalStatus' attribute specifies categories by which a
+ person is often referred to in an organization. Examples of usage in
+ academia might include "undergraduate student", "researcher",
+ "professor", and "staff". Multiple values are allowed where the
+ person is in multiple categories.
+
+ Directory administrators and application designers SHOULD consider
+ carefully the distinctions between this and the 'title' and
+ 'userClass' attributes.
+
+ ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.20. pager
+
+ The 'pager' (pagerTelephoneNumber) attribute specifies pager
+ telephone numbers (e.g., "+1 775 555 5555") for an object.
+
+ ( 0.9.2342.19200300.100.1.42 NAME 'pager'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+2.21. personalTitle
+
+ The 'personalTitle' attribute specifies personal titles for a person.
+ Examples of personal titles are "Frau", "Dr.", "Herr", and
+ "Professor".
+
+ ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.22. roomNumber
+
+ The 'roomNumber' attribute specifies the room number of an object.
+ During periods of renumbering, or in other circumstances where a room
+ has multiple valid room numbers associated with it, multiple values
+ may be provided. Note that the 'cn' (commonName) attribute type
+ SHOULD be used for naming room objects.
+
+ ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.23. secretary
+
+ The 'secretary' attribute specifies secretaries and/or administrative
+ assistants, by distinguished name.
+
+ ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.24. uniqueIdentifier
+
+ The 'uniqueIdentifier' attribute specifies a unique identifier for an
+ object represented in the Directory. The domain within which the
+ identifier is unique and the exact semantics of the identifier are
+ for local definition. For a person, this might be an institution-
+ wide payroll number. For an organizational unit, it might be a
+ department code.
+
+ ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+ Note: X.520 also describes an attribute called 'uniqueIdentifier'
+ (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP
+ [RFC4519]. The attribute detailed here ought not be confused
+ with 'x500UniqueIdentifier'.
+
+2.25. userClass
+
+ The 'userClass' attribute specifies categories of computer or
+ application user. The semantics placed on this attribute are for
+ local interpretation. Examples of current usage of this attribute in
+ academia are "student", "staff", and "faculty". Note that the
+ 'organizationalStatus' attribute type is now often preferred, as it
+ makes no distinction between persons as opposed to users.
+
+ ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+3. COSINE Object Classes
+
+ This section details COSINE object classes for use in LDAP.
+
+3.1. account
+
+ The 'account' object class is used to define entries representing
+ computer accounts. The 'uid' attribute SHOULD be used for naming
+ entries of this object class.
+
+ ( 0.9.2342.19200300.100.4.5 NAME 'account'
+ SUP top STRUCTURAL
+ MUST uid
+ MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+ The 'top' object class is described in [RFC4512]. The 'description',
+ 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
+ [RFC4519]. The 'host' attribute type is described in Section 2 of
+ this document.
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ 3.3. documentSeriesExample:
+
+ dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
+ objectClass: account
+ uid: kdz
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+3.2. document
+
+ The 'document' object class is used to define entries that represent
+ documents.
+
+ ( 0.9.2342.19200300.100.4.6 NAME 'document'
+ SUP top STRUCTURAL
+ MUST documentIdentifier
+ MAY ( cn $ description $ seeAlso $ l $ o $ ou $
+ documentTitle $ documentVersion $ documentAuthor $
+ documentLocation $ documentPublisher ) )
+
+ The 'top' object class is described in [RFC4512]. The 'cn',
+ 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
+ described in [RFC4519]. The 'documentIdentifier', 'documentTitle',
+ 'documentVersion', 'documentAuthor', 'documentLocation', and
+ 'documentPublisher' attribute types are described in Section 2 of
+ this document.
+
+ Example:
+
+ dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM
+ objectClass: document
+ documentIdentifier: RFC 4524
+ documentTitle: COSINE LDAP/X.500 Schema
+ documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+ documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
+ documentPublisher: Internet Engineering Task Force
+ description: A collection of schema elements for use in LDAP
+ description: Obsoletes RFC 1274
+ seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
+ seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
+
+3.3. documentSeries
+
+ The 'documentSeries' object class is used to define an entry that
+ represents a series of documents (e.g., The Request For Comments
+ memos).
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( description $ l $ o $ ou $ seeAlso $
+ telephonenumber ) )
+
+ The 'top' object class is described in [RFC4512]. The 'description',
+ 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
+ described in [RFC4519].
+
+ Example:
+
+ dn: cn=RFC,dc=Example,dc=COM
+ objectClass: documentSeries
+ cn: Request for Comments
+ cn: RFC
+ description: a series of memos about the Internet
+
+3.4. domain
+
+ The 'domain' object class is used to define entries that represent
+ DNS domains for objects that are not organizations, organizational
+ units, or other kinds of objects more appropriately defined using an
+ object class specific to the kind of object being defined (e.g.,
+ 'organization', 'organizationUnit').
+
+ The 'dc' attribute should be used for naming entries of the 'domain'
+ object class.
+
+ ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+ SUP top STRUCTURAL
+ MUST dc
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description $ o $
+ associatedName ) )
+
+ The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
+ 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
+ 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
+ 'teletexTerminalIdentifier', 'telephoneNumber',
+ 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
+ 'postOfficeBox', 'postalCode', 'postalAddress',
+ 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types
+
+
+
+Zeilenga Standards Track [Page 15]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ are described in [RFC4519]. The 'associatedName' attribute type is
+ described in Section 2 of this document.
+
+ Example:
+
+ dn: dc=com
+ objectClass: domain
+ dc: com
+ description: the .COM TLD
+
+3.5. domainRelatedObject
+
+ The 'domainRelatedObject' object class is used to define entries that
+ represent DNS domains that are "equivalent" to an X.500 domain, e.g.,
+ an organization or organizational unit.
+
+ ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+ SUP top AUXILIARY
+ MUST associatedDomain )
+
+ The 'top' object class is described in [RFC4512]. The
+ 'associatedDomain' attribute type is described in Section 2 of this
+ document.
+
+ Example:
+
+ dn: dc=example,dc=com
+ objectClass: organization
+ objectClass: dcObject
+ objectClass: domainRelatedObject
+ dc: example
+ associatedDomain: example.com
+ o: Example Organization
+
+ The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
+ attribute types are described in [RFC4519].
+
+3.6. friendlyCountry
+
+ The 'friendlyCountry' object class is used to define entries
+ representing countries in the DIT. The object class is used to allow
+ friendlier naming of countries than that allowed by the object class
+ 'country' [RFC4519].
+
+ ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST co )
+
+
+
+
+Zeilenga Standards Track [Page 16]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The 'country' object class is described in [RFC4519]. The 'co'
+ attribute type is described in Section 2 of this document.
+
+ Example:
+
+ dn: c=DE
+ objectClass: country
+ objectClass: friendlyCountry
+ c: DE
+ co: Deutschland
+ co: Germany
+ co: Federal Republic of Germany
+ co: FRG
+
+ The 'c' attribute type is described in [RFC4519].
+
+3.7. rFC822LocalPart
+
+ The 'rFC822LocalPart' object class is used to define entries that
+ represent the local part of Internet mail addresses [RFC2822]. This
+ treats the local part of the address as a 'domain' object.
+
+ ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( cn $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
+ seeAlso $ sn $ street $ telephoneNumber $
+ teletexTerminalIdentifier $ telexNumber $ x121Address ) )
+
+ The 'domain' object class is described in Section 3.4 of this
+ document. The 'cn', 'description', 'destinationIndicator',
+ 'facsimileTelephoneNumber', 'internationaliSDNNumber,
+ 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
+ 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
+ 'seeAlso', 'sn, 'street', 'telephoneNumber',
+ 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address'
+ attribute types are described in [RFC4519].
+
+ Example:
+
+ dn: dc=kdz,dc=example,dc=com
+ objectClass: domain
+ objectClass: rFC822LocalPart
+ dc: kdz
+ associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+
+
+
+Zeilenga Standards Track [Page 17]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The 'dc' attribute type is described in [RFC4519].
+
+3.8. room
+
+ The 'room' object class is used to define entries representing rooms.
+ The 'cn' (commonName) attribute SHOULD be used for naming entries of
+ this object class.
+
+ ( 0.9.2342.19200300.100.4.7 NAME 'room'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
+
+ The 'top' object class is described in [RFC4512]. The 'cn',
+ 'description', 'seeAlso', and 'telephoneNumber' attribute types are
+ described in [RFC4519]. The 'roomNumber' attribute type is described
+ in Section 2 of this document.
+
+ dn: cn=conference room,dc=example,dc=com
+ objectClass: room
+ cn: conference room
+ telephoneNumber: +1 755 555 1111
+
+3.9. simpleSecurityObject
+
+ The 'simpleSecurityObject' object class is used to require an entry
+ to have a 'userPassword' attribute when the entry's structural object
+ class does not require (or allow) the 'userPassword attribute'.
+
+ ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+ The 'top' object class is described in [RFC4512]. The 'userPassword'
+ attribute type is described in [RFC4519].
+
+ dn: dc=kdz,dc=Example,dc=COM
+ objectClass: account
+ objectClass: simpleSecurityObject
+ uid: kdz
+ userPassword: My Password
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+4. Security Considerations
+
+ General LDAP security considerations [RFC4510] are applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+
+
+Zeilenga Standards Track [Page 18]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Directories administrators should ensure that access to sensitive
+ information be restricted to authorized entities and that appropriate
+ data security services, including data integrity and data
+ confidentiality, are used to protect against eavesdropping.
+
+ Simple authentication (e.g., plain text passwords) mechanisms should
+ only be used when adequate data security services are in place. LDAP
+ offers reasonably strong authentication and data security services
+ [RFC4513].
+
+5. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [RFC4520] as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comments
+ Specification: RFC 4524
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors have been updated to refer to RFC 4524.
+
+ NAME Type OID
+ ------------------------ ---- --------------------------
+ account O 0.9.2342.19200300.100.4.5
+ associatedDomain A 0.9.2342.19200300.100.1.37
+ associatedName A 0.9.2342.19200300.100.1.38
+ buildingName A 0.9.2342.19200300.100.1.48
+ co A 0.9.2342.19200300.100.1.43
+ document O 0.9.2342.19200300.100.4.6
+ documentAuthor A 0.9.2342.19200300.100.1.14
+ documentIdentifier A 0.9.2342.19200300.100.1.11
+ documentLocation A 0.9.2342.19200300.100.1.15
+ documentPublisher A 0.9.2342.19200300.100.1.56
+ documentSeries O 0.9.2342.19200300.100.4.8
+ documentTitle A 0.9.2342.19200300.100.1.12
+ documentVersion A 0.9.2342.19200300.100.1.13
+ domain O 0.9.2342.19200300.100.4.13
+ domainRelatedObject O 0.9.2342.19200300.100.4.17
+ drink A 0.9.2342.19200300.100.1.5
+ favouriteDrink A* 0.9.2342.19200300.100.1.5
+ friendlyCountry O 0.9.2342.19200300.100.4.18
+
+
+
+Zeilenga Standards Track [Page 19]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ friendlyCountryName A* 0.9.2342.19200300.100.1.43
+ homePhone A 0.9.2342.19200300.100.1.20
+ homePostalAddress A 0.9.2342.19200300.100.1.39
+ homeTelephone A* 0.9.2342.19200300.100.1.20
+ host A 0.9.2342.19200300.100.1.9
+ info A 0.9.2342.19200300.100.1.4
+ mail A 0.9.2342.19200300.100.1.3
+ manager A 0.9.2342.19200300.100.1.10
+ mobile A 0.9.2342.19200300.100.1.41
+ mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
+ organizationalStatus A 0.9.2342.19200300.100.1.45
+ pager A 0.9.2342.19200300.100.1.42
+ pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
+ personalTitle A 0.9.2342.19200300.100.1.40
+ rFC822LocalPart O 0.9.2342.19200300.100.4.14
+ rfc822Mailbox A* 0.9.2342.19200300.100.1.3
+ room O 0.9.2342.19200300.100.4.7
+ roomNumber A 0.9.2342.19200300.100.1.6
+ secretary A 0.9.2342.19200300.100.1.21
+ simpleSecurityObject O 0.9.2342.19200300.100.4.19
+ singleLevelQuality A 0.9.2342.19200300.100.1.50
+ uniqueIdentifier A 0.9.2342.19200300.100.1.44
+ userClass A 0.9.2342.19200300.100.1.8
+
+ where Type A is Attribute, Type O is ObjectClass, and *
+ indicates that the registration is historic in nature.
+
+6. Acknowledgements
+
+ This document is based on RFC 1274, by Paul Barker and Steve Kille,
+ as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick
+ Huber, and Sri Satulari.
+
+7. References
+
+7.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October
+ 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Zeilenga Standards Track [Page 20]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
+ 2821, April 2001.
+
+ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
+ 2001.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+7.2. Informative References
+
+ [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991
+ INTERNET MONTHLY REPORTS (p. 28-29),
+ http://www.iana.org/periodic-reports/imr-mar91.txt
+
+
+
+
+Zeilenga Standards Track [Page 21]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ [ISO3166] International Organization for Standardization, "Codes
+ for the representation of names of countries", ISO
+ 3166.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
+ November 1991.
+
+ [RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight
+ Directory Access Protocol", RFC 1487, July 1993.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 22]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+Appendix A. Changes since RFC 1274
+
+ This document represents a substantial rewrite of RFC 1274. The
+ following sections summarize the substantive changes.
+
+A.1. LDAP Short Names
+
+ A number of COSINE attribute types have short names in LDAP.
+
+ X.500 Name LDAP Short Name
+ ------------- ---------------
+ domainComponent dc
+ favoriteDrink drink
+ friendCountryName co
+ homeTelephoneNumber homePhone
+ mobileTelephoneNumber mobile
+ pagerTelephoneNumber pager
+ rfc822Mailbox mail
+ userid uid
+
+ While the LDAP short names are generally used in LDAP, some
+ implementations may (for legacy reasons [RFC3494]) recognize the
+ attribute type by its X.500 name. Hence, the X.500 names have been
+ reserved solely for this purpose.
+
+ Note: 'uid' and 'dc' are described in [RFC4519].
+
+A.2. pilotObject
+
+ The 'pilotObject' object class was not brought forward as its
+ function is largely replaced by operational attributes introduced in
+ X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the
+ function of the 'lastModifiedBy' and 'lastModifiedTime' attribute
+ types is now served by the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' operational attributes
+ [RFC4512].
+
+A.3. pilotPerson
+
+ The 'pilotPerson' object class was not brought forward as its
+ function is largely replaced by the 'organizationalPerson' [RFC4512]
+ object class and its subclasses, such as 'inetOrgPerson' [RFC2798].
+
+ Most of the related attribute types (e.g., 'mail', 'manager') were
+ brought forward as they are used in other object classes.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 23]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+A.4. dNSDomain
+
+ The 'dNSDomain' object class and related attribute types were not
+ brought forward as its use is primarily experimental [RFC1279].
+
+A.5. pilotDSA and qualityLabelledData
+
+ The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
+ related attribute types, were not brought forward as its use is
+ primarily experimental [QoS].
+
+A.6. Attribute Syntaxes
+
+ RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
+ This has been replaced with the IA5String syntax and appropriate
+ matching rules in 'mail' and 'associatedDomain'.
+
+ RFC 1274 restricted 'mail' to have non-zero length values. This
+ restriction is not reflected in the IA5String syntax used in the
+ definitions provided in this specification. However, as values are
+ to conform to the <Mailbox> production, the 'mail' should not contain
+ zero-length values. Unfortunately, the directory service will not
+ enforce this restriction.
+
+Appendix B. Changes since RFC 2247
+
+ The 'domainNameForm' name form was not brought forward as
+ specification of name forms used in LDAP is left to a future
+ specification.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+\f
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 25]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4525 OpenLDAP Foundation
+Category: Informational June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Modify-Increment Extension
+
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes an extension to the Lightweight Directory
+ Access Protocol (LDAP) Modify operation to support an increment
+ capability. This extension is useful in provisioning applications,
+ especially when combined with the assertion control and/or the pre-
+ read or post-read control extension.
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................1
+ 2. The Modify-Increment Extension ..................................2
+ 3. LDIF Support ....................................................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................3
+ 5.1. Object Identifier ..........................................3
+ 5.2. LDAP Protocol Mechanism ....................................3
+ 5.3. LDAP Protocol Mechanism ....................................4
+ 6. References ......................................................4
+ 6.1. Normative References .......................................4
+ 6.2. Informative References .....................................5
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not
+ currently provide an operation to increment values of an attribute.
+ A client must read the values of the attribute and then modify those
+ values to increment them by the desired amount. As the values may be
+ updated by other clients between this add and modify, the client must
+
+
+
+Zeilenga Informational [Page 1]
+\f
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ be careful to construct the modify request so that it fails in this
+ case, and upon failure, to re-read the values and construct a new
+ modify request.
+
+ This document extends the LDAP Modify Operation [RFC4511] to support
+ an increment values capability. This feature is intended to be used
+ with either the LDAP pre-read or post-read control extensions
+ [RFC4527]. This feature may also be used with the LDAP assertion
+ control extension [RFC4528] to provide test-and-increment
+ functionality.
+
+ In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+ "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119].
+
+2. The Modify-Increment Extension
+
+ This document extends the LDAP Modify request to support a increment
+ values capability. Implementations of this extension SHALL support
+ an additional ModifyRequest operation enumeration value increment
+ (3), as described herein. Implementations not supporting this
+ extension will treat this value as they would an unlisted value,
+ e.g., as a protocol error.
+
+ The increment (3) operation value specifies that an increment values
+ modification is requested. All existing values of the modification
+ attribute are to be incremented by the listed value. The
+ modification attribute must be appropriate for the request (e.g., it
+ must have INTEGER or other increment-able values), and the
+ modification must provide one and only one value. If the attribute
+ is not appropriate for the request, a constraintViolation or other
+ appropriate error is to be returned. If multiple values are
+ provided, a protocolError is to be returned.
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512]
+ attribute in the root DSE. Clients supporting this feature SHOULD
+ NOT use the feature unless they know the server supports it.
+
+3. LDIF Support
+
+ To represent Modify-Increment requests in LDAP Data Interchange
+ Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
+ extended as follows:
+
+ mod-spec =/ "increment:" FILL AttributeDescription SEP
+ attrval-spec "-" SEP
+
+
+
+
+Zeilenga Informational [Page 2]
+\f
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ For example,
+
+ # Increment uidNumber
+ dn: cn=max-assigned uidNumber,dc=example,dc=com
+ changetype: modify
+ increment: uidNumber
+ uidNumber: 1
+ -
+
+ This LDIF fragment represents a Modify request to increment the
+ value(s) of uidNumber by 1.
+
+4. Security Considerations
+
+ General LDAP security considerations [RFC4510], as well as those
+ specific to the LDAP Modify [RFC4511], apply to this Modify-Increment
+ extension. Beyond these considerations, it is noted that
+ introduction of this extension should reduce application complexity
+ (by providing one operation for what presently requires multiple
+ operations) and, hence, it may aid in the production of correct and
+ secure implementations.
+
+5. IANA Considerations
+
+ Registration of the following values [RFC4520] have been completed.
+
+5.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier to identify the LDAP
+ Modify-Increment feature, as defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4525
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Modify-Increment feature
+
+5.2. LDAP Protocol Mechanism
+
+ The following LDAP Protocol Mechanism has been registered.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.14
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+
+
+Zeilenga Informational [Page 3]
+\f
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ Usage: Feature
+ Specification: RFC 4525
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+5.3. LDAP Protocol Mechanism
+
+ The IANA has assigned an LDAP ModifyRequest Operation Type (3)
+ [RFC4520] for use in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ ModifyRequest Operation Name: increment
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFC 4525
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 4]
+\f
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+6.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+ [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Assertion Control", RFC 4528, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 5]
+\f
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Informational [Page 6]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4526 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Absolute True and False Filters
+
+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 (2006).
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol
+ (LDAP) to support absolute True and False filters based upon similar
+ capabilities found in X.500 directory systems. The document also
+ extends the String Representation of LDAP Search Filters to support
+ these filters.
+
+Table of Contents
+
+ 1. Background ......................................................1
+ 2. Absolute True and False Filters .................................2
+ 3. Security Considerations .........................................2
+ 4. IANA Considerations .............................................3
+ 5. References ......................................................3
+ 5.1. Normative References .......................................3
+ 5.2. Informative References .....................................3
+
+1. Background
+
+ The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+ True and False assertions. An 'and' filter with zero elements always
+ evaluates to True. An 'or' filter with zero elements always
+ evaluates to False. These filters are commonly used when requesting
+ DSA-specific Entries (DSEs) that do not necessarily have
+ 'objectClass' attributes; that is, where "(objectClass=*)" may
+ evaluate to False.
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+ Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
+ number of elements in 'and' and 'or' filter sets, the LDAPv2 string
+ representation [RFC1960][RFC3494] could not represent empty 'and' and
+ 'or' filter sets. Due to this, absolute True or False filters were
+ (unfortunately) eliminated from LDAPv3 [RFC4510].
+
+ This documents extends LDAPv3 to support absolute True and False
+ assertions by allowing empty 'and' and 'or' in Search filters
+ [RFC4511] and extends the filter string representation [RFC4515] to
+ allow empty filter lists.
+
+ It is noted that certain search operations, such as those used to
+ retrieve subschema information [RFC4512], require use of particular
+ filters. This document does not change these requirements.
+
+ This feature is intended to allow a more direct mapping between DAP
+ and LDAP (as needed to implement DAP-to-LDAP gateways).
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+2. Absolute True and False Filters
+
+ Implementations of this extension SHALL allow 'and' and 'or' choices
+ with zero filter elements.
+
+ An 'and' filter consisting of an empty set of filters SHALL evaluate
+ to True. This filter is represented by the string "(&)".
+
+ An 'or' filter consisting of an empty set of filters SHALL evaluate
+ to False. This filter is represented by the string "(|)".
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
+ [RFC4512] attribute in the root DSE.
+
+ Clients supporting this feature SHOULD NOT use the feature unless
+ they know that the server supports it.
+
+3. Security Considerations
+
+ The (re)introduction of absolute True and False filters is not
+ believed to raise any new security considerations.
+
+ Implementors of this (or any) LDAPv3 extension should be familiar
+ with general LDAPv3 security considerations [RFC4510].
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+4. IANA Considerations
+
+ Registration of this feature has been completed by the IANA
+ [RFC4520].
+
+ Subject: Request for LDAP Protocol Mechanism Registration Object
+ Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
+ RFC 4526 Author/Change Controller: IESG Comments: none
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+5.2. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol", RFC 1777, March 1995.
+
+ [RFC1960] Howes, T., "A String Representation of LDAP Search
+ Filters", RFC 1960, June 1996.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4527 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Read Entry Controls
+
+
+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 (2006).
+
+Abstract
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) to allow the client to read the target entry
+ of an update operation. The client may request to read the entry
+ before and/or after the modifications are applied. These reads are
+ done as an atomic part of the update operation.
+
+Table of Contents
+
+ 1. Background and Intent of Use ....................................2
+ 2. Terminology .....................................................2
+ 3. Read Entry Controls .............................................3
+ 3.1. The Pre-Read Controls ......................................3
+ 3.2. The Post-Read Controls .....................................3
+ 4. Interaction with Other Controls .................................4
+ 5. Security Considerations .........................................4
+ 6. IANA Considerations .............................................5
+ 6.1. Object Identifier ..........................................5
+ 6.2. LDAP Protocol Mechanisms ...................................5
+ 7. Acknowledgement .................................................5
+ 8. References ......................................................6
+ 8.1. Normative References .......................................6
+ 8.2. Informative References .....................................7
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+1. Background and Intent of Use
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) [RFC4510] to allow the client to read the
+ target entry of an update operation (e.g., Add, Delete, Modify,
+ ModifyDN). The extension utilizes controls [RFC4511] attached to
+ update requests to request and return copies of the target entry.
+ One request control, called the Pre-Read request control, indicates
+ that a copy of the entry before application of update is to be
+ returned. Another control, called the Post-Read request control,
+ indicates that a copy of the entry after application of the update is
+ to be returned. Each request control has a corresponding response
+ control used to return the entry.
+
+ To ensure proper isolation, the controls are processed as an atomic
+ part of the update operation.
+
+ The functionality offered by these controls is based upon similar
+ functionality in the X.500 Directory Access Protocol (DAP) [X.511].
+
+ The Pre-Read controls may be used to obtain replaced or deleted
+ values of modified attributes or a copy of the entry being deleted.
+
+ The Post-Read controls may be used to obtain values of operational
+ attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp'
+ [RFC4512] attributes, updated by the server as part of the update
+ operation.
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent (i.e., a directory server).
+ DSE stands for DSA-specific Entry.
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+3. Read Entry Controls
+
+3.1. The Pre-Read Controls
+
+ The Pre-Read request and response controls are identified by the
+ 1.3.6.1.1.13.1 object identifier. Servers implementing these
+ controls SHOULD publish 1.3.6.1.1.13.1 as a value of the
+ 'supportedControl' [RFC4512] in their root DSE.
+
+ The Pre-Read request control is a LDAP Control [RFC4511] whose
+ controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded
+ AttributeSelection [RFC4511], as extended by [RFC3673]. The
+ criticality may be TRUE or FALSE. This control is appropriate for
+ the modifyRequest, delRequest, and modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose
+ controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET
+ STRING, contains a BER-encoded SearchResultEntry. The criticality
+ may be TRUE or FALSE. This control is appropriate for the
+ modifyResponse, delResponse, and modDNResponse LDAP messages with a
+ resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of the target
+ entry prior to the application of the update. The AttributeSelection
+ indicates, as discussed in [RFC4511][RFC3673], which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no Pre-Read response control is provided.
+
+3.2. The Post-Read Controls
+
+ The Post-Read request and response controls are identified by the
+ 1.3.6.1.1.13.2 object identifier. Servers implementing these
+ controls SHOULD publish 1.3.6.1.1.13.2 as a value of the
+ 'supportedControl' [RFC4512] in their root DSE.
+
+ The Post-Read request control is a LDAP Control [RFC4511] whose
+ controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET
+ STRING, contains a BER-encoded AttributeSelection [RFC4511], as
+ extended by [RFC3673]. The criticality may be TRUE or FALSE. This
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+ control is appropriate for the addRequest, modifyRequest, and
+ modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose
+ controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded
+ SearchResultEntry. The criticality may be TRUE or FALSE. This
+ control is appropriate for the addResponse, modifyResponse, and
+ modDNResponse LDAP messages with a resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of the target
+ entry after the application of the update. The AttributeSelection
+ indicates, as discussed in [RFC4511][RFC3673], which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no Post-Read response control is provided.
+
+4. Interaction with Other Controls
+
+ The Pre-Read and Post-Read controls may be combined with each other
+ and/or with a variety of other controls. When combined with the
+ assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],
+ the semantics of each control included in the combination applies.
+ The Pre-Read and Post-Read controls may be combined with other
+ controls as detailed in other technical specifications.
+
+5. Security Considerations
+
+ The controls defined in this document extend update operations to
+ support read capabilities. Servers MUST ensure that the client is
+ authorized for reading of the information provided in this control
+ and that the client is authorized to perform the requested directory
+ update.
+
+ Security considerations for the update operations [RFC4511] extended
+ by this control, as well as general LDAP security considerations
+ [RFC4510], generally apply to implementation and use of this
+ extension
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+6. IANA Considerations
+
+ Registration of the following protocol values [RFC4520] have been
+ completed by the IANA.
+
+6.1. Object Identifier
+
+ The IANA has registered an LDAP Object Identifier to identify LDAP
+ protocol elements defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: Identifies the LDAP Read Entry Controls
+
+6.2. LDAP Protocol Mechanisms
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.13.1
+ Description: LDAP Pre-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: none
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.13.2
+ Description: LDAP Post-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: none
+
+7. Acknowledgement
+
+ The LDAP Pre-Read and Post-Read controls are modeled after similar
+ capabilities offered in the DAP [X.511].
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Assertion Control", RFC 4528, June 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(1997) (also
+ ISO/IEC 8825-1:1998).
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+8.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) EntryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4528 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Assertion Control
+
+
+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 (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Assertion Control, which allows a client to specify that a
+ directory operation should only be processed if an assertion applied
+ to the target entry of the operation is true. It can be used to
+ construct "test and set", "test and clear", and other conditional
+ operations.
+
+Table of Contents
+
+ 1. Overview ........................................................2
+ 2. Terminology .....................................................2
+ 3. The Assertion Control ...........................................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................4
+ 5.1. Object Identifier ..........................................4
+ 5.2. LDAP Protocol Mechanism ....................................4
+ 5.3. LDAP Result Code ...........................................4
+ 6. Acknowledgements ................................................5
+ 7. References ......................................................5
+ 7.1. Normative References .......................................5
+ 7.2. Informative References .....................................5
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4528 LDAP Assertion Control June 2006
+
+
+1. Overview
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] assertion control. The assertion control allows the
+ client to specify a condition that must be true for the operation to
+ be processed normally. Otherwise, the operation is not performed.
+ For instance, the control can be used with the Modify operation
+ [RFC4511] to perform atomic "test and set" and "test and clear"
+ operations.
+
+ The control may be attached to any update operation to support
+ conditional addition, deletion, modification, and renaming of the
+ target object. The asserted condition is evaluated as an integral
+ part the operation.
+
+ The control may also be used with the search operation. Here, the
+ assertion is applied to the base object of the search before
+ searching for objects that match the search scope and filter.
+
+ The control may also be used with the compare operation. Here, it
+ extends the compare operation to allow a more complex assertion.
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+3. The Assertion Control
+
+ The assertion control is an LDAP Control [RFC4511] whose controlType
+ is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
+ [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
+ There is no corresponding response control.
+
+ The control is appropriate for both LDAP interrogation and update
+ operations [RFC4511], including Add, Compare, Delete, Modify,
+ ModifyDN (rename), and Search. It is inappropriate for Abandon,
+ Bind, Unbind, and StartTLS operations.
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4528 LDAP Assertion Control June 2006
+
+
+ When the control is attached to an LDAP request, the processing of
+ the request is conditional on the evaluation of the Filter as applied
+ against the target of the operation. If the Filter evaluates to
+ TRUE, then the request is processed normally. If the Filter
+ evaluates to FALSE or Undefined, then assertionFailed (122)
+ resultCode is returned, and no further processing is performed.
+
+ For Add, Compare, and ModifyDN operations, the target is indicated by
+ the entry field in the request. For Modify operations, the target is
+ indicated by the object field. For Delete operations, the target is
+ indicated by the DelRequest type. For Compare operations and all
+ update operations, the evaluation of the assertion MUST be performed
+ as an integral part of the operation. That is, the evaluation of the
+ assertion and the normal processing of the operation SHALL be done as
+ one atomic action.
+
+ For Search operations, the target is indicated by the baseObject
+ field, and the evaluation is done after "finding" but before
+ "searching" [RFC4511]. Hence, no entries or continuations references
+ are returned if the assertion fails.
+
+ Servers implementing this technical specification SHOULD publish the
+ object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
+ attribute [RFC4512] in their root DSE. A server MAY choose to
+ advertise this extension only when the client is authorized to use
+ it.
+
+ Other documents may specify how this control applies to other LDAP
+ operations. In doing so, they must state how the target entry is
+ determined.
+
+4. Security Considerations
+
+ The filter may, like other components of the request, contain
+ sensitive information. When it does, this information should be
+ appropriately protected.
+
+ As with any general assertion mechanism, the mechanism can be used to
+ determine directory content. Hence, this mechanism SHOULD be subject
+ to appropriate access controls.
+
+ Some assertions may be very complex, requiring significant time and
+ resources to evaluate. Hence, this mechanism SHOULD be subject to
+ appropriate administrative controls.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4528 LDAP Assertion Control June 2006
+
+
+ Security considerations for the base operations [RFC4511] extended by
+ this control, as well as general LDAP security considerations
+ [RFC4510], generally apply to implementation and use of this
+ extension.
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier [RFC4520] to identify
+ the LDAP Assertion Control defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Assertion Control
+
+5.2. LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [RFC4520] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.12
+ Description: Assertion Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments: none
+
+5.3. LDAP Result Code
+
+ The IANA has assigned an LDAP Result Code [RFC4520] called
+ 'assertionFailed' (122).
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: assertionFailed
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4528 LDAP Assertion Control June 2006
+
+
+6. Acknowledgements
+
+ The assertion control concept is attributed to Morteza Ansari.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(2002) (also
+ ISO/IEC 8825-1:2002).
+
+7.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4528 LDAP Assertion Control June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4529 OpenLDAP Foundation
+Category: Informational June 2006
+
+
+ Requesting Attributes by Object Class in the
+ Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) search operation
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, and/or attributes selected by
+ their description. This document extends LDAP to support a mechanism
+ that LDAP clients may use to request the return of all attributes of
+ an object class.
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................1
+ 2. Terminology .....................................................2
+ 3. Return of all Attributes of an Object Class .....................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................3
+ 6. References ......................................................4
+ 6.1. Normative References .......................................4
+ 6.2. Informative References .....................................4
+
+1. Background and Intended Use
+
+ In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
+ search operation [RFC4511] supports requesting the return of a set of
+ attributes. This set is determined by a list of attribute
+ descriptions. Two special descriptors are defined to request all
+ user attributes ("*") [RFC4511] and all operational attributes ("+")
+ [RFC3673]. However, there is no convenient mechanism for requesting
+ pre-defined sets of attributes such as the set of attributes used to
+ represent a particular class of object.
+
+
+
+Zeilenga Informational [Page 1]
+\f
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ This document extends LDAP to allow an object class identifier to be
+ specified in attributes lists, such as in Search requests, to request
+ the return of all attributes belonging to an object class. The
+ COMMERCIAL AT ("@", U+0040) character is used to distinguish an
+ object class identifier from an attribute descriptions.
+
+ For example, the attribute list of "@country" is equivalent to the
+ attribute list of 'c', 'searchGuide', 'description', and
+ 'objectClass'. This object class is described in [RFC4519].
+
+ This extension is intended primarily to be used where the user is in
+ direct control of the parameters of the LDAP search operation, for
+ instance when entering an LDAP URL [RFC4516] into a web browser, such
+ as <ldap:///dc=example,dc=com?@organization?base>.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+3. Return of All Attributes of an Object Class
+
+ This extension allows object class identifiers to be provided in the
+ attributes field of the LDAP SearchRequest [RFC4511] or other request
+ values of the AttributeSelection data type (e.g., attributes field in
+ pre/post read controls [ReadEntry]) and/or <attributeSelector>
+ production (e.g., attributes of an LDAP URL [RFC4516]). For each
+ object class identified in the attributes field, the request is to be
+ treated as if each attribute allowed by that class (by "MUST" or
+ "MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
+
+ This extension extends the <attributeSelector> [RFC4511] production
+ as indicated by the following ABNF [RFC4234]:
+
+ attributeSelector =/ objectclassdescription
+ objectclassdescription = ATSIGN oid options
+ ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
+
+ where <oid> and <options> productions are as defined in [RFC4512].
+
+
+
+
+
+
+
+Zeilenga Informational [Page 2]
+\f
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ The <oid> component of an <objectclassdescription> production
+ identifies the object class by short name (descr) or object
+ identifier (numericoid). If the value of the <oid> component is
+ unrecognized or does not refer to an object class, the object class
+ description is to be treated as an unrecognized attribute
+ description.
+
+ The <options> production is included in the grammar for extensibility
+ purposes. An object class description with an unrecognized or
+ inappropriate option is to be treated as unrecognized.
+
+ Although object class description options and attribute description
+ options share the same syntax, they are not semantically related.
+ This document does not define any object description option.
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
+ [RFC4512] attribute in the root DSE. Clients supporting this feature
+ SHOULD NOT use the feature unless they know that the server supports
+ it.
+
+4. Security Considerations
+
+ This extension provides a shorthand for requesting all attributes of
+ an object class. Because these attributes could have been listed
+ individually, introduction of this shorthand is not believed to raise
+ additional security considerations.
+
+ Implementors of this LDAP extension should be familiar with security
+ considerations applicable to the LDAP search operation [RFC4511], as
+ well as with general LDAP security considerations [RFC4510].
+
+5. IANA Considerations
+
+ Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
+ document has been completed.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.2
+ Description: OC AD Lists
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFC 4529
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+
+
+
+
+Zeilenga Informational [Page 3]
+\f
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2. Informative References
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+Zeilenga Informational [Page 4]
+\f
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 5]
+\f
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Informational [Page 6]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4530 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ entryUUID Operational Attribute
+
+
+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 (2006).
+
+Abstract
+
+ This document describes the LDAP/X.500 'entryUUID' operational
+ attribute and associated matching rules and syntax. The attribute
+ holds a server-assigned Universally Unique Identifier (UUID) for the
+ object. Directory clients may use this attribute to distinguish
+ objects identified by a distinguished name or to locate an object
+ after renaming.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................2
+ 2. UUID Schema Elements ............................................3
+ 2.1. UUID Syntax ................................................3
+ 2.2. 'uuidMatch' Matching Rule ..................................3
+ 2.3. 'uuidOrderingMatch' Matching Rule ..........................3
+ 2.4. 'entryUUID' Attribute ......................................4
+ 3. Security Considerations .........................................4
+ 4. IANA Considerations .............................................5
+ 4.1. Object Identifier Registration .............................5
+ 4.2. UUID Syntax Registration ...................................5
+ 4.3. 'uuidMatch' Descriptor Registration ........................5
+ 4.4. 'uuidOrderingMatch' Descriptor Registration ................5
+ 4.5. 'entryUUID' Descriptor Registration ........................6
+ 5. Acknowledgements ................................................6
+ 6. References ......................................................6
+ 6.1. Normative References .......................................6
+ 6.2. Informative References .....................................7
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
+ is identified by its distinguished name (DN). However, DNs are not
+ stable identifiers. That is, a new object may be identified by a DN
+ that previously identified another (now renamed or deleted) object.
+
+ A Universally Unique Identifier (UUID) is "an identifier unique
+ across both space and time, with respect to the space of all UUIDs"
+ [RFC4122]. UUIDs are used in a wide range of systems.
+
+ This document describes the 'entryUUID' operational attribute, which
+ holds the UUID assigned to the object by the server. Clients may use
+ this attribute to distinguish objects identified by a particular
+ distinguished name or to locate a particular object after renaming.
+
+ This document defines the UUID syntax, the 'uuidMatch' and
+ 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
+ type.
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+2. UUID Schema Elements
+
+2.1. UUID Syntax
+
+ A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
+ bit) value that identifies an object. The ASN.1 [X.680] type UUID is
+ defined to represent UUIDs as follows:
+
+ UUID ::= OCTET STRING (SIZE(16))
+ -- constrained to an UUID [RFC4122]
+
+ In LDAP, UUID values are encoded using the [ASCII] character string
+ representation described in [RFC4122]. For example,
+ "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+
+ The following is an LDAP syntax description suitable for publication
+ in subschema subentries.
+
+ ( 1.3.6.1.1.16.1 DESC 'UUID' )
+
+2.2. 'uuidMatch' Matching Rule
+
+ The 'uuidMatch' matching rule compares an asserted UUID with a stored
+ UUID for equality. Its semantics are the same as the
+ 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs
+ from 'octetStringMatch' in that the assertion value is encoded using
+ the UUID string representation instead of the normal OCTET STRING
+ string representation.
+
+ The following is an LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
+ SYNTAX 1.3.6.1.1.16.1 )
+
+2.3. 'uuidOrderingMatch' Matching Rule
+
+ The 'uuidOrderingMatch' matching rule compares an asserted UUID with
+ a stored UUID for ordering. Its semantics are the same as the
+ 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule
+ differs from 'octetStringOrderingMatch' in that the assertion value
+ is encoded using the UUID string representation instead of the normal
+ OCTET STRING string representation.
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+ The following is an LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
+ SYNTAX 1.3.6.1.1.16.1 )
+
+ Note that not all UUID variants have a defined ordering; and even
+ where it does, servers are not obligated to assign UUIDs in any
+ particular order. This matching rule is provided for completeness.
+
+2.4. 'entryUUID' Attribute
+
+ The 'entryUUID' operational attribute provides the Universally Unique
+ Identifier (UUID) assigned to the entry.
+
+ The following is an LDAP attribute type description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.4 NAME 'entryUUID'
+ DESC 'UUID of the entry'
+ EQUALITY uuidMatch
+ ORDERING uuidOrderingMatch
+ SYNTAX 1.3.6.1.1.16.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL generate and assign a new UUID to each entry upon its
+ addition to the directory and provide that UUID as the value of the
+ 'entryUUID' operational attribute. An entry's UUID is immutable.
+
+ UUID are to be generated in accordance with Section 4 of [RFC4122].
+ In particular, servers MUST ensure that each generated UUID is unique
+ in space and time.
+
+3. Security Considerations
+
+ An entry's relative distinguish name (RDN) is composed from attribute
+ values of the entry, which are commonly descriptive of the object the
+ entry represents. Although deployers are encouraged to use naming
+ attributes whose values are widely disclosable [RFC4514], entries are
+ often named using information that cannot be disclosed to all
+ parties. As UUIDs do not contain any descriptive information of the
+ object they identify, UUIDs may be used to identify a particular
+ entry without disclosure of its contents.
+
+ General UUID security considerations [RFC4122] apply.
+
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+ General LDAP security considerations [RFC4510] apply.
+
+4. IANA Considerations
+
+ The IANA has registered the LDAP values [RFC4520] specified in this
+ document.
+
+4.1. Object Identifier Registration
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID schema elements
+
+4.2. UUID Syntax Registration
+
+ Subject: Request for LDAP Syntax Registration
+ Object Identifier: 1.3.6.1.1.16.1
+ Description: UUID
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID syntax
+
+4.3. 'uuidMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidMatch
+ Object Identifier: 1.3.6.1.1.16.2
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+4.4. 'uuidOrderingMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidOrderingMatch
+ Object Identifier: 1.3.6.1.1.16.3
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+4.5. 'entryUUID' Descriptor Registration
+
+ The IANA has registered the LDAP 'entryUUID' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryUUID
+ Object Identifier: 1.3.6.1.1.16.4
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+5. Acknowledgements
+
+ This document is based upon discussions in the LDAP Update and
+ Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
+ provided review.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+ 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2. Informative References
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
+RFC 4530 LDAP entryUUID June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4531 OpenLDAP Foundation
+Category: Experimental June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Turn Operation
+
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to reverse (or "turn") the roles of client
+ and server for subsequent protocol exchanges in the session, or to
+ enable each peer to act as both client and server with respect to the
+ other.
+
+Table of Contents
+
+ 1. Background and Intent of Use ....................................2
+ 1.1. Terminology ................................................2
+ 2. Turn Operation ..................................................2
+ 2.1. Turn Request ...............................................3
+ 2.2. Turn Response ..............................................3
+ 3. Authentication ..................................................3
+ 3.1. Use with TLS and Simple Authentication .....................4
+ 3.2. Use with TLS and SASL EXTERNAL .............................4
+ 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
+ 4. TLS and SASL Security Layers ....................................5
+ 5. Security Considerations .........................................6
+ 6. IANA Considerations .............................................6
+ 6.1. Object Identifier ..........................................6
+ 6.2. LDAP Protocol Mechanism ....................................7
+ 7. References ......................................................7
+ 7.1. Normative References .......................................7
+ 7.2. Informative References .....................................8
+
+
+
+
+Zeilenga Experimental [Page 1]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+1. Background and Intent of Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511]
+ is a client-server protocol that typically operates over reliable
+ octet-stream transports, such as the Transport Control Protocol
+ (TCP). Generally, the client initiates the stream by connecting to
+ the server's listener at some well-known address.
+
+ There are cases where it is desirable for the server to initiate the
+ stream. Although it certainly is possible to write a technical
+ specification detailing how to implement server-initiated LDAP
+ sessions, this would require the design of new authentication and
+ other security mechanisms to support server-initiated LDAP sessions.
+
+ Instead, this document introduces an operation, the Turn operation,
+ which may be used to reverse the client-server roles of the protocol
+ peers. This allows the initiating protocol peer to become the server
+ (after the reversal).
+
+ As an additional feature, the Turn operation may be used to allow
+ both peers to act in both roles. This is useful where both peers are
+ directory servers that desire to request, as LDAP clients, that
+ operations be performed by the other. This may be useful in
+ replicated and/or distributed environments.
+
+ This operation is intended to be used between protocol peers that
+ have established a mutual agreement, by means outside of the
+ protocol, that requires reversal of client-server roles, or allows
+ both peers to act both as client and server.
+
+1.1. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+2. Turn Operation
+
+ The Turn operation is defined as an LDAP-Extended Operation
+ [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The
+ function of the Turn Operation is to request that the client-server
+ roles be reversed, or, optionally, to request that both protocol
+ peers be able to act both as client and server in respect to the
+ other.
+
+
+
+
+
+
+Zeilenga Experimental [Page 2]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+2.1. Turn Request
+
+ The Turn request is an ExtendedRequest where the requestName field
+ contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-
+ encoded turnValue:
+
+ turnValue ::= SEQUENCE {
+ mutual BOOLEAN DEFAULT FALSE,
+ identifier LDAPString
+ }
+
+ A TRUE mutual field value indicates a request to allow both peers to
+ act both as client and server. A FALSE mutual field value indicates
+ a request to reserve the client and server roles.
+
+ The value of the identifier field is a locally defined policy
+ identifier (typically associated with a mutual agreement for which
+ this turn is be executed as part of).
+
+2.2. Turn Response
+
+ A Turn response is an ExtendedResponse where the responseName and
+ responseValue fields are absent. A resultCode of success is returned
+ if and only if the responder is willing and able to turn the session
+ as requested. Otherwise, a different resultCode is returned.
+
+3. Authentication
+
+ This extension's authentication model assumes separate authentication
+ of the peers in each of their roles. A separate Bind exchange is
+ expected between the peers in their new roles to establish identities
+ in these roles.
+
+ Upon completion of the Turn, the responding peer in its new client
+ role has an anonymous association at the initiating peer in its new
+ server role. If the turn was mutual, the authentication association
+ of the initiating peer in its pre-existing client role is left intact
+ at the responding peer in its pre-existing server role. If the turn
+ was not mutual, this association is void.
+
+ The responding peer may establish its identity in its client role by
+ requesting and successfully completing a Bind operation.
+
+ The remainder of this section discusses some authentication
+ scenarios. In the protocol exchange illustrations, A refers to the
+ initiating peer (the original client) and B refers to the responding
+ peer (the original server).
+
+
+
+
+Zeilenga Experimental [Page 3]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+3.1. Use with TLS and Simple Authentication
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS (Transport Layer Security) [RFC4346] is started
+ and the initiating peer (the original client) establishes its
+ identity with the responding peer prior to the Turn using the
+ DN/password mechanism of the Simple method of the Bind operation.
+ After the turn, the responding peer, in its new client role,
+ establishes its identity with the initiating peer in its new server
+ role.
+
+3.2. Use with TLS and SASL EXTERNAL
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(SASL(EXTERNAL)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS is started (with each peer providing a valid
+ certificate), and the initiating peer (the original client)
+ establishes its identity through the use of the EXTERNAL mechanism of
+ the SASL (Simple Authentication and Security Layer) [RFC4422] method
+ of the Bind operation prior to the Turn. After the turn, the
+ responding peer, in its new client role, establishes its identity
+ with the initiating peer in its new server role.
+
+3.3. Use of Mutual Authentication and SASL EXTERNAL
+
+ A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual
+ authentication. The initiating peer, in its new server role, may use
+ the identity of the responding peer, established by a prior
+ authentication exchange, as its source for "external" identity in
+ subsequent EXTERNAL exchange.
+
+ A->B: Bind(SASL(GSSAPI)) Request
+ <intermediate messages>
+
+
+
+Zeilenga Experimental [Page 4]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, a GSSAPI mutual-authentication exchange is
+ completed between the initiating peer (the original client) and the
+ responding server (the original server) prior to the turn. After the
+ turn, the responding peer, in its new client role, requests that the
+ initiating peer utilize an "external" identity to establish its LDAP
+ authorization identity.
+
+4. TLS and SASL Security Layers
+
+ As described in [RFC4511], LDAP supports both Transport Layer
+ Security (TLS) [RFC4346] and Simple Authentication and Security Layer
+ (SASL) [RFC4422] security frameworks. The following table
+ illustrates the relationship between the LDAP message layer, SASL
+ layer, TLS layer, and transport connection within an LDAP session.
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+ This extension does not alter this relationship, nor does it remove
+ the general restriction against multiple TLS layers, nor does it
+ remove the general restriction against multiple SASL layers.
+
+ As specified in [RFC4511], the StartTLS operation is used to initiate
+ negotiation of a TLS layer. If a TLS is already installed, the
+ StartTLS operation must fail. Upon establishment of the TLS layer,
+ regardless of which peer issued the request to start TLS, the peer
+ that initiated the LDAP session (the original client) performs the
+ "server identity check", as described in Section 3.1.5 of [RFC4513],
+ treating itself as the "client" and its peer as the "server".
+
+ As specified in [RFC4422], a newly negotiated SASL security layer
+ replaces the installed SASL security layer. Though the client/server
+
+
+
+Zeilenga Experimental [Page 5]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ roles in LDAP, and hence SASL, may be reversed in subsequent
+ exchanges, only one SASL security layer may be installed at any
+ instance.
+
+5. Security Considerations
+
+ Implementors should be aware that the reversing of client/server
+ roles and/or allowing both peers to act as client and server likely
+ introduces security considerations not foreseen by the authors of
+ this document. In particular, the security implications of the
+ design choices made in the authentication and data security models
+ for this extension (discussed in Sections 3 and 4, respectively) are
+ not fully studied. It is hoped that experimentation with this
+ extension will lead to better understanding of the security
+ implications of these models and other aspects of this extension, and
+ that appropriate considerations will be documented in a future
+ document. The following security considerations are apparent at this
+ time.
+
+ Implementors should take special care to process LDAP, SASL, TLS, and
+ other events in the appropriate roles for the peers. Note that while
+ the Turn reverses the client/server roles with LDAP, and in SASL
+ authentication exchanges, it does not reverse the roles within the
+ TLS layer or the transport connection.
+
+ The responding server (the original server) should restrict use of
+ this operation to authorized clients. Client knowledge of a valid
+ identifier should not be the sole factor in determining authorization
+ to turn.
+
+ Where the peers except to establish TLS, TLS should be started prior
+ to the Turn and any request to authenticate via the Bind operation.
+
+ LDAP security considerations [RFC4511][RFC4513] generally apply to
+ this extension.
+
+6. IANA Considerations
+
+ The following values [RFC4520] have been registered by the IANA.
+
+6.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier to identify the LDAP
+ Turn Operation, as defined in this document.
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 6]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4531
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Turn Operation
+
+6.2. LDAP Protocol Mechanism
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.19
+ Description: LDAP Turn Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 4531
+ Author/Change Controller: Author
+ Comments: none
+
+7. References
+
+7.1. Normative References
+
+ [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.1", RFC 4346, April
+ 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+
+
+
+
+
+Zeilenga Experimental [Page 7]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(2002) (also
+ ISO/IEC 8825-1:2002).
+
+7.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
+ Mechanism", Work in Progress, May 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 8]
+\f
+RFC 4531 LDAP Turn Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 9]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4532 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ "Who am I?" Operation
+
+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 (2006).
+
+Abstract
+
+ This specification provides a mechanism for Lightweight Directory
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ the server has associated with the user or application entity. This
+ mechanism is specified as an LDAP extended operation called the LDAP
+ "Who am I?" operation.
+
+1. Background and Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] operation that clients can use to obtain the primary
+ authorization identity, in its primary form, that the server has
+ associated with the user or application entity. The operation is
+ called the "Who am I?" operation.
+
+ This specification is intended to replace the existing Authorization
+ Identity Controls [RFC3829] mechanism, which uses Bind request and
+ response controls to request and return the authorization identity.
+ Bind controls are not protected by security layers established by the
+ Bind operation that includes them. While it is possible to establish
+ security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
+ operation, it is often desirable to use security layers established
+ by the Bind operation. An extended operation sent after a Bind
+ operation is protected by the security layers established by the Bind
+ operation.
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ There are other cases where it is desirable to request the
+ authorization identity that the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [RFC4370] to determine the authorization identity that the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the
+ Bind operation.
+
+ Servers often associate multiple authorization identities with the
+ client, and each authorization identity may be represented by
+ multiple authzId [RFC4513] strings. This operation requests and
+ returns the authzId that the server considers primary. In the
+ specification, the term "the authorization identity" and "the
+ authzId" are generally to be read as "the primary authorization
+ identity" and the "the primary authzId", respectively.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+ [RFC4511] identified by the whoamiOID Object Identifier (OID). This
+ section details the syntax of the operation's whoami request and
+ response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with a requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+ 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
+ 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and the response field, if present, is empty or an
+ authzId [RFC4513]. For example, a whoami response returning the
+ authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+ 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
+ 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
+ 4e 45 54
+
+3. Operational Semantics
+
+ The "Who am I?" operation provides a mechanism, a whoami Request, for
+ the client to request that the server return the authorization
+ identity it currently associates with the client. It also provides a
+ mechanism, a whoami Response, for the server to respond to that
+ request.
+
+ Servers indicate their support for this extended operation by
+ providing a whoamiOID object identifier as a value of the
+ 'supportedExtension' attribute type in their root DSE. The server
+ SHOULD advertise this extension only when the client is willing and
+ able to perform this operation.
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is present but
+ empty. Otherwise, the server provides the authzId [RFC4513]
+ representing the authorization identity it currently associates with
+ the client in the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+ As described in [RFC4511] and [RFC4513], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ Bind operation. Where a whoami Request is received in violation of
+ this absolute prohibition, the server should return a whoami Response
+ with an operationsError resultCode.
+
+4. Extending the "Who am I?" Operation with Controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism [RFC4511]. When extended by controls, the "Who am
+ I?" operation requests and returns the authorization identity the
+ server associates with the client in a particular context indicated
+ by the controls.
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [RFC4370] is used by clients to
+ request that the operation it is attached to operate under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC4513], it is desirable to request that the server provide the
+ authzId it associates with the assumed identity.
+
+ When a Proxied Authorization Control is be attached to the "Who am
+ I?" operation, the operation requests the return of the authzId the
+ server associates with the identity asserted in the Proxied
+ Authorization Control. The authorizationDenied (123) result code is
+ used to indicate that the server does not allow the client to assume
+ the asserted identity.
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ they are, security layers [RFC4511][RFC4513] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+ Servers may place access control or other restrictions upon the use
+ of this operation. As stated in Section 3, the server SHOULD
+ advertise this extension when it is willing and able to perform the
+ operation.
+
+ As with any other extended operations, general LDAP security
+ considerations [RFC4510] apply.
+
+
+
+Zeilenga Standards Track [Page 4]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+6. IANA Considerations
+
+ The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
+ I?" extended operation. This OID was assigned [ASSIGN] by the
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+ Registration of this protocol mechanism [RFC4520] has been completed
+ by the IANA.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.11.3
+ Description: Who am I?
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 4532
+ Author/Change Controller: IESG
+ Comments: none
+
+7. Acknowledgement
+
+ This document borrows from prior work in this area, including
+ "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
+ Smith, and Mark Wahl.
+
+ The LDAP "Who am I?" operation takes it's name from the UNIX
+ whoami(1) command. The whoami(1) command displays the effective user
+ ID.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control", RFC 4370, February 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+8.2. Informative References
+
+ [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
+ Access Protocol (LDAP) Authorization Identity Request and
+ Response Controls", RFC 3829, July 2004.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+\f
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4533 OpenLDAP Foundation
+Category: Experimental J.H. Choi
+ IBM Corporation
+ June 2006
+
+
+ The Lightweight Directory Access Protocol (LDAP)
+ Content Synchronization Operation
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+ The IESG notes that this work was originally discussed in the LDUP
+ working group. The group came to consensus on a different approach,
+ documented in RFC 3928; that document is on the standards track and
+ should be reviewed by those considering implementation of this
+ proposal.
+
+Abstract
+
+ This specification describes the Lightweight Directory Access
+ Protocol (LDAP) Content Synchronization Operation. The operation
+ allows a client to maintain a copy of a fragment of the Directory
+ Information Tree (DIT). It supports both polling for changes and
+ listening for changes. The operation is defined as an extension of
+ the LDAP Search Operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 1]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Background .................................................3
+ 1.2. Intended Usage .............................................4
+ 1.3. Overview ...................................................5
+ 1.4. Conventions ................................................8
+ 2. Elements of the Sync Operation ..................................8
+ 2.1. Common ASN.1 Elements ......................................9
+ 2.2. Sync Request Control .......................................9
+ 2.3. Sync State Control ........................................10
+ 2.4. Sync Done Control .........................................10
+ 2.5. Sync Info Message .........................................11
+ 2.6. Sync Result Codes .........................................11
+ 3. Content Synchronization ........................................11
+ 3.1. Synchronization Session ...................................12
+ 3.2. Content Determination .....................................12
+ 3.3. refreshOnly Mode ..........................................13
+ 3.4. refreshAndPersist Mode ....................................16
+ 3.5. Search Request Parameters .................................17
+ 3.6. objectName ................................................18
+ 3.7. Canceling the Sync Operation ..............................19
+ 3.8. Refresh Required ..........................................19
+ 3.9. Chattiness Considerations .................................20
+ 3.10. Operation Multiplexing ...................................21
+ 4. Meta Information Considerations ................................22
+ 4.1. Entry DN ..................................................22
+ 4.2. Operational Attributes ....................................22
+ 4.3. Collective Attributes .....................................23
+ 4.4. Access and Other Administrative Controls ..................23
+ 5. Interaction with Other Controls ................................23
+ 5.1. ManageDsaIT Control .......................................24
+ 5.2. Subentries Control ........................................24
+ 6. Shadowing Considerations .......................................24
+ 7. Security Considerations ........................................25
+ 8. IANA Considerations ............................................26
+ 8.1. Object Identifier .........................................26
+ 8.2. LDAP Protocol Mechanism ...................................26
+ 8.3. LDAP Result Codes .........................................26
+ 9. Acknowledgements ...............................................26
+ 10. Normative References ..........................................27
+ 11. Informative References ........................................28
+ Appendix A. CSN-based Implementation Considerations ..............29
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 2]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
+ mechanism, the search operation [RFC4511], that allows a client to
+ request directory content matching a complex set of assertions and to
+ request that the server return this content, subject to access
+ control and other restrictions, to the client. However, LDAP does
+ not provide (despite the introduction of numerous extensions in this
+ area) an effective and efficient mechanism for maintaining
+ synchronized copies of directory content. This document introduces a
+ new mechanism specifically designed to meet the content
+ synchronization requirements of sophisticated directory applications.
+
+ This document defines the LDAP Content Synchronization Operation, or
+ Sync Operation for short, which allows a client to maintain a
+ synchronized copy of a fragment of a Directory Information Tree
+ (DIT). The Sync Operation is defined as a set of controls and other
+ protocol elements that extend the Search Operation.
+
+1.1. Background
+
+ Over the years, a number of content synchronization approaches have
+ been suggested for use in LDAP directory services. These approaches
+ are inadequate for one or more of the following reasons:
+
+ - failure to ensure a reasonable level of convergence;
+
+ - failure to detect that convergence cannot be achieved (without
+ reload);
+
+ - require pre-arranged synchronization agreements;
+
+ - require the server to maintain histories of past changes to DIT
+ content and/or meta information;
+
+ - require the server to maintain synchronization state on a per-
+ client basis; and/or
+
+ - are overly chatty.
+
+ The Sync Operation provides eventual convergence of synchronized
+ content when possible and, when not, notification that a full reload
+ is required.
+
+ The Sync Operation does not require pre-arranged synchronization
+ agreements.
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 3]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ The Sync Operation does not require that servers maintain or use any
+ history of past changes to the DIT or to meta information. However,
+ servers may maintain and use histories (e.g., change logs,
+ tombstones, DIT snapshots) to reduce the number of messages generated
+ and to reduce their size. As it is not always feasible to maintain
+ and use histories, the operation may be implemented using purely
+ (current) state-based approaches. The Sync Operation allows use of
+ either the state-based approach or the history-based approach on an
+ operation-by-operation basis to balance the size of history and the
+ amount of traffic. The Sync Operation also allows the combined use
+ of the state-based and the history-based approaches.
+
+ The Sync Operation does not require that servers maintain
+ synchronization state on a per-client basis. However, servers may
+ maintain and use per-client state information to reduce the number of
+ messages generated and the size of such messages.
+
+ A synchronization mechanism can be considered overly chatty when
+ synchronization traffic is not reasonably bounded. The Sync
+ Operation traffic is bounded by the size of updated (or new) entries
+ and the number of unchanged entries in the content. The operation is
+ designed to avoid full content exchanges, even when the history
+ information available to the server is insufficient to determine the
+ client's state. The operation is also designed to avoid transmission
+ of out-of-content history information, as its size is not bounded by
+ the content and it is not always feasible to transmit such history
+ information due to security reasons.
+
+ This document includes a number of non-normative appendices providing
+ additional information to server implementors.
+
+1.2. Intended Usage
+
+ The Sync Operation is intended to be used in applications requiring
+ eventually-convergent content synchronization. Upon completion of
+ each synchronization stage of the operation, all information to
+ construct a synchronized client copy of the content has been provided
+ to the client or the client has been notified that a complete content
+ reload is necessary. Except for transient inconsistencies due to
+ concurrent operation (or other) processing at the server, the client
+ copy is an accurate reflection of the content held by the server.
+ Transient inconsistencies will be resolved by subsequent
+ synchronization operations.
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 4]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Possible uses include the following:
+
+ - White page service applications may use the Sync Operation to
+ maintain a current copy of a DIT fragment, for example, a mail
+ user agent that uses the sync operation to maintain a local
+ copy of an enterprise address book.
+
+ - Meta-information engines may use the Sync Operation to maintain
+ a copy of a DIT fragment.
+
+ - Caching proxy services may use the Sync Operation to maintain a
+ coherent content cache.
+
+ - Lightweight master-slave replication between heterogeneous
+ directory servers. For example, the Sync Operation can be used
+ by a slave server to maintain a shadow copy of a DIT fragment.
+ (Note: The International Telephone Union (ITU) has defined the
+ X.500 Directory [X.500] Information Shadowing Protocol (DISP)
+ [X.525], which may be used for master-slave replication between
+ directory servers. Other experimental LDAP replication
+ protocols also exist.)
+
+ This protocol is not intended to be used in applications requiring
+ transactional data consistency.
+
+ As this protocol transfers all visible values of entries belonging to
+ the content upon change instead of change deltas, this protocol is
+ not appropriate for bandwidth-challenged applications or deployments.
+
+1.3. Overview
+
+ This section provides an overview of basic ways the Sync Operation
+ can be used to maintain a synchronized client copy of a DIT fragment.
+
+ - Polling for changes: refreshOnly mode
+
+ - Listening for changes: refreshAndPersist mode
+
+1.3.1. Polling for Changes (refreshOnly)
+
+ To obtain its initial client copy, the client issues a Sync request:
+ a search request with the Sync Request Control with mode set to
+ refreshOnly. The server, much like it would with a normal search
+ operation, returns (subject to access controls and other
+ restrictions) the content matching the search criteria (baseObject,
+ scope, filter, attributes). Additionally, with each entry returned,
+ the server provides a Sync State Control indicating state add. This
+ control contains the Universally Unique Identifier (UUID) [UUID] of
+
+
+
+Zeilenga & Choi Experimental [Page 5]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ the entry [RFC4530]. Unlike the Distinguished Name (DN), which may
+ change over time, an entry's UUID is stable. The initial content is
+ followed by a SearchResultDone with a Sync Done Control. The Sync
+ Done Control provides a syncCookie. The syncCookie represents
+ session state.
+
+ To poll for updates to the client copy, the client reissues the Sync
+ Operation with the syncCookie previously returned. The server, much
+ as it would with a normal search operation, determines which content
+ would be returned as if the operation were a normal search operation.
+ However, using the syncCookie as an indicator of what content the
+ client was sent previously, the server sends copies of entries that
+ have changed with a Sync State Control indicating state add. For
+ each changed entry, all (modified or unmodified) attributes belonging
+ to the content are sent.
+
+ The server may perform either or both of the two distinct
+ synchronization phases that are distinguished by how to synchronize
+ entries deleted from the content: the present and the delete phases.
+ When the server uses a single phase for the refresh stage, each phase
+ is marked as ended by a SearchResultDone with a Sync Done Control. A
+ present phase is identified by a FALSE refreshDeletes value in the
+ Sync Done Control. A delete phase is identified by a TRUE
+ refreshDeletes value. The present phase may be followed by a delete
+ phase. The two phases are delimited by a refreshPresent Sync Info
+ Message having a FALSE refreshDone value. In the case that both the
+ phases are used, the present phase is used to bring the client copy
+ up to the state at which the subsequent delete phase can begin.
+
+ In the present phase, the server sends an empty entry (i.e., no
+ attributes) with a Sync State Control indicating state present for
+ each unchanged entry.
+
+ The delete phase may be used when the server can reliably determine
+ which entries in the prior client copy are no longer present in the
+ content and the number of such entries is less than or equal to the
+ number of unchanged entries. In the delete mode, the server sends an
+ empty entry with a Sync State Control indicating state delete for
+ each entry that is no longer in the content, instead of returning an
+ empty entry with state present for each present entry.
+
+ The server may send syncIdSet Sync Info Messages containing the set
+ of UUIDs of either unchanged present entries or deleted entries,
+ instead of sending multiple individual messages. If refreshDeletes
+ of syncIdSet is set to FALSE, the UUIDs of unchanged present entries
+ are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is
+ set to TRUE, the UUIDs of the entries no longer present in the
+ content are contained in the syncUUIDs set. An optional cookie can
+
+
+
+Zeilenga & Choi Experimental [Page 6]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ be included in the syncIdSet to represent the state of the content
+ after synchronizing the presence or the absence of the entries
+ contained in the syncUUIDs set.
+
+ The synchronized copy of the DIT fragment is constructed by the
+ client.
+
+ If refreshDeletes of syncDoneValue is FALSE, the new copy includes
+ all changed entries returned by the reissued Sync Operation, as well
+ as all unchanged entries identified as being present by the reissued
+ Sync Operation, but whose content is provided by the previous Sync
+ Operation. The unchanged entries not identified as being present are
+ deleted from the client content. They had been either deleted,
+ moved, or otherwise scoped-out from the content.
+
+ If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
+ changed entries returned by the reissued Sync Operation, as well as
+ all other entries of the previous copy except for those that are
+ identified as having been deleted from the content.
+
+ The client can, at some later time, re-poll for changes to this
+ synchronized client copy.
+
+1.3.2. Listening for Changes (refreshAndPersist)
+
+ Polling for changes can be expensive in terms of server, client, and
+ network resources. The refreshAndPersist mode allows for active
+ updates of changed entries in the content.
+
+ By selecting the refreshAndPersist mode, the client requests that the
+ server send updates of entries that are changed after the initial
+ refresh content is determined. Instead of sending a SearchResultDone
+ Message as in polling, the server sends a Sync Info Message to the
+ client indicating that the refresh stage is complete and then enters
+ the persist stage. After receipt of this Sync Info Message, the
+ client will construct a synchronized copy as described in Section
+ 1.3.1.
+
+ The server may then send change notifications as the result of the
+ original Sync search request, which now remains persistent in the
+ server. For entries to be added to the returned content, the server
+ sends a SearchResultEntry (with attributes) with a Sync State Control
+ indicating state add. For entries to be deleted from the content,
+ the server sends a SearchResultEntry containing no attributes and a
+ Sync State Control indicating state delete. For entries to be
+ modified in the return content, the server sends a SearchResultEntry
+ (with attributes) with a Sync State Control indicating state modify.
+
+
+
+
+Zeilenga & Choi Experimental [Page 7]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Upon modification of an entry, all (modified or unmodified)
+ attributes belonging to the content are sent.
+
+ Note that renaming an entry of the DIT may cause an add state change
+ where the entry is renamed into the content, a delete state change
+ where the entry is renamed out of the content, and a modify state
+ change where the entry remains in the content. Also note that a
+ modification of an entry of the DIT may cause an add, delete, or
+ modify state change to the content.
+
+ Upon receipt of a change notification, the client updates its copy of
+ the content.
+
+ If the server desires to update the syncCookie during the persist
+ stage, it may include the syncCookie in any Sync State Control or
+ Sync Info Message returned.
+
+ The operation persists until canceled [RFC3909] by the client or
+ terminated by the server. A Sync Done Control shall be attached to
+ SearchResultDone Message to provide a new syncCookie.
+
+1.4. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+2. Elements of the Sync Operation
+
+ The Sync Operation is defined as an extension to the LDAP Search
+ Operation [RFC4511] where the directory user agent (DUA or client)
+ submits a SearchRequest Message with a Sync Request Control and the
+ directory system agent (DSA or server) responds with zero or more
+ SearchResultEntry Messages, each with a Sync State Control; zero or
+ more SearchResultReference Messages, each with a Sync State Control;
+ zero or more Sync Info Intermediate Response Messages; and a
+ SearchResultDone Message with a Sync Done Control.
+
+ To allow clients to discover support for this operation, servers
+ implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1
+ as a value of the 'supportedControl' attribute [RFC4512] of the root
+ DSA-specific entry (DSE). A server MAY choose to advertise this
+ extension only when the client is authorized to use it.
+
+
+
+Zeilenga & Choi Experimental [Page 8]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.1. Common ASN.1 Elements
+
+2.1.1. syncUUID
+
+ The syncUUID data type is an OCTET STRING holding a 128-bit
+ (16-octet) Universally Unique Identifier (UUID) [UUID].
+
+ syncUUID ::= OCTET STRING (SIZE(16))
+ -- constrained to UUID
+
+2.1.2. syncCookie
+
+ The syncCookie is a notational convenience to indicate that, while
+ the syncCookie type is encoded as an OCTET STRING, its value is an
+ opaque value containing information about the synchronization session
+ and its state. Generally, the session information would include a
+ hash of the operation parameters that the server requires not be
+ changed and the synchronization state information would include a
+ commit (log) sequence number, a change sequence number, or a time
+ stamp. For convenience of description, the term "no cookie" refers
+ either to a null cookie or to a cookie with pre-initialized
+ synchronization state.
+
+ syncCookie ::= OCTET STRING
+
+2.2. Sync Request Control
+
+ The Sync Request Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the
+ controlValue, an OCTET STRING, contains a BER-encoded
+ syncRequestValue. The criticality field is either TRUE or FALSE.
+
+ syncRequestValue ::= SEQUENCE {
+ mode ENUMERATED {
+ -- 0 unused
+ refreshOnly (1),
+ -- 2 reserved
+ refreshAndPersist (3)
+ },
+ cookie syncCookie OPTIONAL,
+ reloadHint BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Request Control is only applicable to the SearchRequest
+ Message.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 9]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.3. Sync State Control
+
+ The Sync State Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the
+ controlValue, an OCTET STRING, contains a BER-encoded syncStateValue.
+ The criticality is FALSE.
+
+ syncStateValue ::= SEQUENCE {
+ state ENUMERATED {
+ present (0),
+ add (1),
+ modify (2),
+ delete (3)
+ },
+ entryUUID syncUUID,
+ cookie syncCookie OPTIONAL
+ }
+
+ The Sync State Control is only applicable to SearchResultEntry and
+ SearchResultReference Messages.
+
+2.4. Sync Done Control
+
+ The Sync Done Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the
+ controlValue contains a BER-encoded syncDoneValue. The criticality
+ is FALSE (and hence absent).
+
+ syncDoneValue ::= SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Done Control is only applicable to the SearchResultDone
+ Message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 10]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.5. Sync Info Message
+
+ The Sync Info Message is an LDAP Intermediate Response Message
+ [RFC4511] where responseName is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
+ syncInfoValue. The criticality is FALSE (and hence absent).
+
+ syncInfoValue ::= CHOICE {
+ newcookie [0] syncCookie,
+ refreshDelete [1] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ refreshPresent [2] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ syncIdSet [3] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE,
+ syncUUIDs SET OF syncUUID
+ }
+ }
+
+2.6. Sync Result Codes
+
+ The following LDAP resultCode [RFC4511] is defined:
+
+ e-syncRefreshRequired (4096)
+
+3. Content Synchronization
+
+ The Sync Operation is invoked when the client sends a SearchRequest
+ Message with a Sync Request Control.
+
+ The absence of a cookie or an initialized synchronization state in a
+ cookie indicates a request for initial content, while the presence of
+ a cookie representing a state of a client copy indicates a request
+ for a content update. Synchronization Sessions are discussed in
+ Section 3.1. Content Determination is discussed in Section 3.2.
+
+ The mode is either refreshOnly or refreshAndPersist. The refreshOnly
+ and refreshAndPersist modes are discussed in Sections 3.3 and 3.4,
+ respectively. The refreshOnly mode consists only of a refresh stage,
+ while the refreshAndPersist mode consists of a refresh stage and a
+ subsequent persist stage.
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 11]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+3.1. Synchronization Session
+
+ A sequence of Sync Operations where the last cookie returned by the
+ server for one operation is provided by the client in the next
+ operation is said to belong to the same Synchronization Session.
+
+ The client MUST specify the same content-controlling parameters (see
+ Section 3.5) in each Search Request of the session. The client
+ SHOULD also issue each Sync request of a session under the same
+ authentication and authorization associations with equivalent
+ integrity and protections. If the server does not recognize the
+ request cookie or the request is made under different associations or
+ non-equivalent protections, the server SHALL return the initial
+ content as if no cookie had been provided or return an empty content
+ with the e-syncRefreshRequired LDAP result code. The decision
+ between the return of the initial content and the return of the empty
+ content with the e-syncRefreshRequired result code MAY be based on
+ reloadHint in the Sync Request Control from the client. If the
+ server recognizes the request cookie as representing empty or initial
+ synchronization state of the client copy, the server SHALL return the
+ initial content.
+
+ A Synchronization Session may span multiple LDAP sessions between the
+ client and the server. The client SHOULD issue each Sync request of
+ a session to the same server. (Note: Shadowing considerations are
+ discussed in Section 6.)
+
+3.2. Content Determination
+
+ The content to be provided is determined by parameters of the Search
+ Request, as described in [RFC4511], and possibly other controls. The
+ same content parameters SHOULD be used in each Sync request of a
+ session. If different content is requested and the server is
+ unwilling or unable to process the request, the server SHALL return
+ the initial content as if no cookie had been provided or return an
+ empty content with the e-syncRefreshRequired LDAP result code. The
+ decision between the return of the initial content and the return of
+ the empty content with the e-syncRefreshRequired result code MAY be
+ based on reloadHint in the Sync Request Control from the client.
+
+ The content may not necessarily include all entries or references
+ that would be returned by a normal search operation, nor, for those
+ entries included, all attributes returned by a normal search. When
+ the server is unwilling or unable to provide synchronization for any
+ attribute for a set of entries, the server MUST treat all filter
+ components matching against these attributes as Undefined and MUST
+ NOT return these attributes in SearchResultEntry responses.
+
+
+
+
+Zeilenga & Choi Experimental [Page 12]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Servers SHOULD support synchronization for all non-collective user-
+ application attributes for all entries.
+
+ The server may also return continuation references to other servers
+ or to itself. The latter is allowed as the server may partition the
+ entries it holds into separate synchronization contexts.
+
+ The client may chase all or some of these continuations, each as a
+ separate content synchronization session.
+
+3.3. refreshOnly Mode
+
+ A Sync request with mode refreshOnly and with no cookie is a poll for
+ initial content. A Sync request with mode refreshOnly and with a
+ cookie representing a synchronization state is a poll for content
+ update.
+
+3.3.1. Initial Content Poll
+
+ Upon receipt of the request, the server provides the initial content
+ using a set of zero or more SearchResultEntry and
+ SearchResultReference Messages followed by a SearchResultDone
+ Message.
+
+ Each SearchResultEntry Message SHALL include a Sync State Control of
+ state add, an entryUUID containing the entry's UUID, and no cookie.
+ Each SearchResultReference Message SHALL include a Sync State Control
+ of state add, an entryUUID containing the UUID associated with the
+ reference (normally the UUID of the associated named referral
+ [RFC3296] object), and no cookie. The SearchResultDone Message SHALL
+ include a Sync Done Control having refreshDeletes set to FALSE.
+
+ A resultCode value of success indicates that the operation
+ successfully completed. Otherwise, the result code indicates the
+ nature of the failure. The server may return e-syncRefreshRequired
+ result code on the initial content poll if it is safe to do so when
+ it is unable to perform the operation due to various reasons.
+ reloadHint is set to FALSE in the SearchRequest Message requesting
+ the initial content poll.
+
+ If the operation is successful, a cookie representing the
+ synchronization state of the current client copy SHOULD be returned
+ for use in subsequent Sync Operations.
+
+3.3.2. Content Update Poll
+
+ Upon receipt of the request, the server provides the content refresh
+ using a set of zero or more SearchResultEntry and
+
+
+
+Zeilenga & Choi Experimental [Page 13]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ SearchResultReference Messages followed by a SearchResultDone
+ Message.
+
+ The server is REQUIRED to:
+
+ a) provide the sequence of messages necessary for eventual
+ convergence of the client's copy of the content to the server's
+ copy,
+
+ b) treat the request as an initial content request (e.g., ignore
+ the cookie or the synchronization state represented in the
+ cookie),
+
+ c) indicate that the incremental convergence is not possible by
+ returning e-syncRefreshRequired,
+
+ d) return a resultCode other than success or e-
+ syncRefreshRequired.
+
+ A Sync Operation may consist of a single present phase, a single
+ delete phase, or a present phase followed by a delete phase.
+
+ In each phase, for each entry or reference that has been added to the
+ content or been changed since the previous Sync Operation indicated
+ by the cookie, the server returns a SearchResultEntry or
+ SearchResultReference Message, respectively, each with a Sync State
+ Control consisting of state add, an entryUUID containing the UUID of
+ the entry or reference, and no cookie. Each SearchResultEntry
+ Message represents the current state of a changed entry. Each
+ SearchResultReference Message represents the current state of a
+ changed reference.
+
+ In the present phase, for each entry that has not been changed since
+ the previous Sync Operation, an empty SearchResultEntry is returned
+ whose objectName reflects the entry's current DN, whose attributes
+ field is empty, and whose Sync State Control consists of state
+ present, an entryUUID containing the UUID of the entry, and no
+ cookie. For each reference that has not been changed since the
+ previous Sync Operation, an empty SearchResultReference containing an
+ empty SEQUENCE OF LDAPURL is returned with a Sync State Control
+ consisting of state present, an entryUUID containing the UUID of the
+ entry, and no cookie. No messages are sent for entries or references
+ that are no longer in the content.
+
+ Multiple empty entries with a Sync State Control of state present
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to FALSE. syncUUIDs contain a set of
+ UUIDs of the entries and references unchanged since the last Sync
+
+
+
+Zeilenga & Choi Experimental [Page 14]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Operation. syncUUIDs may be empty. The Sync Info Message of
+ syncIdSet may contain a cookie to represent the state of the content
+ after performing the synchronization of the entries in the set.
+
+ In the delete phase, for each entry no longer in the content, the
+ server returns a SearchResultEntry whose objectName reflects a past
+ DN of the entry or is empty, whose attributes field is empty, and
+ whose Sync State Control consists of state delete, an entryUUID
+ containing the UUID of the deleted entry, and no cookie. For each
+ reference no longer in the content, a SearchResultReference
+ containing an empty SEQUENCE OF LDAPURL is returned with a Sync State
+ Control consisting of state delete, an entryUUID containing the UUID
+ of the deleted reference, and no cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references that have been deleted from the
+ content since the last Sync Operation. syncUUIDs may be empty. The
+ Sync Info Message of syncIdSet may contain a cookie to represent the
+ state of the content after performing the synchronization of the
+ entries in the set.
+
+ When a present phase is followed by a delete phase, the two phases
+ are delimited by a Sync Info Message containing syncInfoValue of
+ refreshPresent, which may contain a cookie representing the state
+ after completing the present phase. The refreshPresent contains
+ refreshDone, which is always FALSE in the refreshOnly mode of Sync
+ Operation because it is followed by a delete phase.
+
+ If a Sync Operation consists of a single phase, each phase and hence
+ the Sync Operation are marked as ended by a SearchResultDone Message
+ with Sync Done Control, which SHOULD contain a cookie representing
+ the state of the content after completing the Sync Operation. The
+ Sync Done Control contains refreshDeletes, which is set to FALSE for
+ the present phase and set to TRUE for the delete phase.
+
+ If a Sync Operation consists of a present phase followed by a delete
+ phase, the Sync Operation is marked as ended at the end of the delete
+ phase by a SearchResultDone Message with Sync Done Control, which
+ SHOULD contain a cookie representing the state of the content after
+ completing the Sync Operation. The Sync Done Control contains
+ refreshDeletes, which is set to TRUE.
+
+ The client can specify whether it prefers to receive an initial
+ content by supplying reloadHint of TRUE or to receive a e-
+ syncRefreshRequired resultCode by supplying reloadHint of FALSE
+ (hence absent), in the case that the server determines that it is
+
+
+
+Zeilenga & Choi Experimental [Page 15]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ impossible or inefficient to achieve the eventual convergence by
+ continuing the current incremental synchronization thread.
+
+ A resultCode value of success indicates that the operation is
+ successfully completed. A resultCode value of e-syncRefreshRequired
+ indicates that a full or partial refresh is needed. Otherwise, the
+ result code indicates the nature of failure. A cookie is provided in
+ the Sync Done Control for use in subsequent Sync Operations for
+ incremental synchronization.
+
+3.4. refreshAndPersist Mode
+
+ A Sync request with mode refreshAndPersist asks for initial content
+ or content update (during the refresh stage) followed by change
+ notifications (during the persist stage).
+
+3.4.1. refresh Stage
+
+ The content refresh is provided as described in Section 3.3, except
+ that the successful completion of content refresh is indicated by
+ sending a Sync Info Message of refreshDelete or refreshPresent with a
+ refreshDone value set to TRUE instead of a SearchResultDone Message
+ with resultCode success. A cookie SHOULD be returned in the Sync
+ Info Message to represent the state of the content after finishing
+ the refresh stage of the Sync Operation.
+
+3.4.2. persist Stage
+
+ Change notifications are provided during the persist stage.
+
+ As updates are made to the DIT, the server notifies the client of
+ changes to the content. DIT updates may cause entries and references
+ to be added to the content, deleted from the content, or modified
+ within the content. DIT updates may also cause references to be
+ added, deleted, or modified within the content.
+
+ Where DIT updates cause an entry to be added to the content, the
+ server provides a SearchResultEntry Message that represents the entry
+ as it appears in the content. The message SHALL include a Sync State
+ Control with state of add, an entryUUID containing the entry's UUID,
+ and an optional cookie.
+
+ Where DIT updates cause a reference to be added to the content, the
+ server provides a SearchResultReference Message that represents the
+ reference in the content. The message SHALL include a Sync State
+ Control with state of add, an entryUUID containing the UUID
+ associated with the reference, and an optional cookie.
+
+
+
+
+Zeilenga & Choi Experimental [Page 16]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Where DIT updates cause an entry to be modified within the content,
+ the server provides a SearchResultEntry Message that represents the
+ entry as it appears in the content. The message SHALL include a Sync
+ State Control with state of modify, an entryUUID containing the
+ entry's UUID, and an optional cookie.
+
+ Where DIT updates cause a reference to be modified within the
+ content, the server provides a SearchResultReference Message that
+ represents the reference in the content. The message SHALL include a
+ Sync State Control with state of modify, an entryUUID containing the
+ UUID associated with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be deleted from the content, the
+ server provides a SearchResultEntry Message with no attributes. The
+ message SHALL include a Sync State Control with state of delete, an
+ entryUUID containing the entry's UUID, and an optional cookie.
+
+ Where DIT updates cause a reference to be deleted from the content,
+ the server provides a SearchResultReference Message with an empty
+ SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control
+ with state of delete, an entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references that have been deleted from the
+ content. The Sync Info Message of syncIdSet may contain a cookie to
+ represent the state of the content after performing the
+ synchronization of the entries in the set.
+
+ With each of these messages, the server may provide a new cookie to
+ be used in subsequent Sync Operations. Additionally, the server may
+ also return Sync Info Messages of choice newCookie to provide a new
+ cookie. The client SHOULD use the newest (last) cookie it received
+ from the server in subsequent Sync Operations.
+
+3.5. Search Request Parameters
+
+ As stated in Section 3.1, the client SHOULD specify the same
+ content-controlling parameters in each Search Request of the session.
+ All fields of the SearchRequest Message are considered content-
+ controlling parameters except for sizeLimit and timeLimit.
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 17]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+3.5.1. baseObject
+
+ As with the normal search operation, the refresh and persist stages
+ are not isolated from DIT changes. It is possible that the entry
+ referred to by the baseObject is deleted, renamed, or moved. It is
+ also possible that the alias object used in finding the entry
+ referred to by the baseObject is changed such that the baseObject
+ refers to a different entry.
+
+ If the DIT is updated during processing of the Sync Operation in a
+ manner that causes the baseObject no longer to refer to any entry or
+ in a manner that changes the entry the baseObject refers to, the
+ server SHALL return an appropriate non-success result code, such as
+ noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
+ e-syncRefreshRequired.
+
+3.5.2. derefAliases
+
+ This operation does not support alias dereferencing during searching.
+ The client SHALL specify neverDerefAliases or derefFindingBaseObj for
+ the SearchRequest derefAliases parameter. The server SHALL treat
+ other values (e.g., derefInSearching, derefAlways) as protocol
+ errors.
+
+3.5.3. sizeLimit
+
+ The sizeLimit applies only to entries (regardless of their state in
+ Sync State Control) returned during the refreshOnly operation or the
+ refresh stage of the refreshAndPersist operation.
+
+3.5.4. timeLimit
+
+ For a refreshOnly Sync Operation, the timeLimit applies to the whole
+ operation. For a refreshAndPersist operation, the timeLimit applies
+ only to the refresh stage including the generation of the Sync Info
+ Message with a refreshDone value of TRUE.
+
+3.5.5. filter
+
+ The client SHOULD avoid filter assertions that apply to the values of
+ the attributes likely to be considered by the server as ones holding
+ meta-information. See Section 4.
+
+3.6. objectName
+
+ The Sync Operation uses entryUUID values provided in the Sync State
+ Control as the primary keys to entries. The client MUST use these
+ entryUUIDs to correlate synchronization messages.
+
+
+
+Zeilenga & Choi Experimental [Page 18]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ In some circumstances, the DN returned may not reflect the entry's
+ current DN. In particular, when the entry is being deleted from the
+ content, the server may provide an empty DN if the server does not
+ wish to disclose the entry's current DN (or, if deleted from the DIT,
+ the entry's last DN).
+
+ Also note that the entry's DN may be viewed as meta information (see
+ Section 4.1).
+
+3.7. Canceling the Sync Operation
+
+ Servers MUST implement the LDAP Cancel [RFC3909] Operation and
+ support cancellation of outstanding Sync Operations as described
+ here.
+
+ To cancel an outstanding Sync Operation, the client issues an LDAP
+ Cancel [RFC3909] Operation.
+
+ If at any time the server becomes unwilling or unable to continue
+ processing a Sync Operation, the server SHALL return a
+ SearchResultDone with a non-success resultCode indicating the reason
+ for the termination of the operation.
+
+ Whether the client or the server initiated the termination, the
+ server may provide a cookie in the Sync Done Control for use in
+ subsequent Sync Operations.
+
+3.8. Refresh Required
+
+ In order to achieve the eventually-convergent synchronization, the
+ server may terminate the Sync Operation in the refresh or persist
+ stages by returning an e-syncRefreshRequired resultCode to the
+ client. If no cookie is provided, a full refresh is needed. If a
+ cookie representing a synchronization state is provided in this
+ response, an incremental refresh is needed.
+
+ To obtain a full refresh, the client then issues a new
+ synchronization request with no cookie. To obtain an incremental
+ reload, the client issues a new synchronization with the provided
+ cookie.
+
+ The server may choose to provide a full copy in the refresh stage
+ (e.g., ignore the cookie or the synchronization state represented in
+ the cookie) instead of providing an incremental refresh in order to
+ achieve the eventual convergence.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 19]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ The decision between the return of the initial content and the return
+ of the e-syncRefreshRequired result code may be based on reloadHint
+ in the Sync Request Control from the client.
+
+ In the case of persist stage Sync, the server returns the resultCode
+ of e-syncRefreshRequired to the client to indicate that the client
+ needs to issue a new Sync Operation in order to obtain a synchronized
+ copy of the content. If no cookie is provided, a full refresh is
+ needed. If a cookie representing a synchronization state is
+ provided, an incremental refresh is needed.
+
+ The server may also return e-syncRefreshRequired if it determines
+ that a refresh would be more efficient than sending all the messages
+ required for convergence.
+
+ Note that the client may receive one or more of SearchResultEntry,
+ SearchResultReference, and/or Sync Info Messages before it receives a
+ SearchResultDone Message with the e-syncRefreshRequired result code.
+
+3.9. Chattiness Considerations
+
+ The server MUST ensure that the number of entry messages generated to
+ refresh the client content does not exceed the number of entries
+ presently in the content. While there is no requirement for servers
+ to maintain history information, if the server has sufficient history
+ to allow it to reliably determine which entries in the prior client
+ copy are no longer present in the content and the number of such
+ entries is less than or equal to the number of unchanged entries, the
+ server SHOULD generate delete entry messages instead of present entry
+ messages (see Section 3.3.2).
+
+ When the amount of history information maintained in the server is
+ not enough for the clients to perform infrequent refreshOnly Sync
+ Operations, it is likely that the server has incomplete history
+ information (e.g., due to truncation) by the time those clients
+ connect again.
+
+ The server SHOULD NOT resort to full reload when the history
+ information is not enough to generate delete entry messages. The
+ server SHOULD generate either present entry messages only or present
+ entry messages followed by delete entry messages to bring the client
+ copy to the current state. In the latter case, the present entry
+ messages bring the client copy to a state covered by the history
+ information maintained in the server.
+
+ The server SHOULD maintain enough (current or historical) state
+ information (such as a context-wide last modify time stamp) to
+ determine if no changes were made in the context since the content
+
+
+
+Zeilenga & Choi Experimental [Page 20]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ refresh was provided and, when no changes were made, generate zero
+ delete entry messages instead of present messages.
+
+ The server SHOULD NOT use the history information when its use does
+ not reduce the synchronization traffic or when its use can expose
+ sensitive information not allowed to be received by the client.
+
+ The server implementor should also consider chattiness issues that
+ span multiple Sync Operations of a session. As noted in Section 3.8,
+ the server may return e-syncRefreshRequired if it determines that a
+ reload would be more efficient than continuing under the current
+ operation. If reloadHint in the Sync Request is TRUE, the server may
+ initiate a reload without directing the client to request a reload.
+
+ The server SHOULD transfer a new cookie frequently to avoid having to
+ transfer information already provided to the client. Even where DIT
+ changes do not cause content synchronization changes to be
+ transferred, it may be advantageous to provide a new cookie using a
+ Sync Info Message. However, the server SHOULD avoid overloading the
+ client or network with Sync Info Messages.
+
+ During persist mode, the server SHOULD coalesce multiple outstanding
+ messages updating the same entry. The server MAY delay generation of
+ an entry update in anticipation of subsequent changes to that entry
+ that could be coalesced. The length of the delay should be long
+ enough to allow coalescing of update requests issued back to back but
+ short enough that the transient inconsistency induced by the delay is
+ corrected in a timely manner.
+
+ The server SHOULD use the syncIdSet Sync Info Message when there are
+ multiple delete or present messages to reduce the amount of
+ synchronization traffic.
+
+ Also note that there may be many clients interested in a particular
+ directory change, and that servers attempting to service all of these
+ at once may cause congestion on the network. The congestion issues
+ are magnified when the change requires a large transfer to each
+ interested client. Implementors and deployers of servers should take
+ steps to prevent and manage network congestion.
+
+3.10. Operation Multiplexing
+
+ The LDAP protocol model [RFC4511] allows operations to be multiplexed
+ over a single LDAP session. Clients SHOULD NOT maintain multiple
+ LDAP sessions with the same server. Servers SHOULD ensure that
+ responses from concurrently processed operations are interleaved
+ fairly.
+
+
+
+
+Zeilenga & Choi Experimental [Page 21]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Clients SHOULD combine Sync Operations whose result set is largely
+ overlapping. This avoids having to return multiple messages, once
+ for each overlapping session, for changes to entries in the overlap.
+
+ Clients SHOULD NOT combine Sync Operations whose result sets are
+ largely non-overlapping. This ensures that an event requiring an
+ e-syncRefreshRequired response can be limited to as few result sets
+ as possible.
+
+4. Meta Information Considerations
+
+4.1. Entry DN
+
+ As an entry's DN is constructed from its relative DN (RDN) and the
+ entry's parent's DN, it is often viewed as meta information.
+
+ While renaming or moving to a new superior causes the entry's DN to
+ change, that change SHOULD NOT, by itself, cause synchronization
+ messages to be sent for that entry. However, if the renaming or the
+ moving could cause the entry to be added or deleted from the content,
+ appropriate synchronization messages should be generated to indicate
+ this to the client.
+
+ When a server treats the entry's DN as meta information, the server
+ SHALL either
+
+ - evaluate all MatchingRuleAssertions [RFC4511] to TRUE if
+ matching a value of an attribute of the entry, otherwise
+ Undefined, or
+
+ - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
+ Undefined.
+
+ The latter choice is offered for ease of server implementation.
+
+4.2. Operational Attributes
+
+ Where values of an operational attribute are determined by values not
+ held as part of the entry it appears in, the operational attribute
+ SHOULD NOT support synchronization of that operational attribute.
+
+ For example, in servers that implement the X.501 subschema model
+ [X.501], servers should not support synchronization of the
+ subschemaSubentry attribute as its value is determined by values held
+ and administrated in subschema subentries.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 22]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ As a counter example, servers that implement aliases [RFC4512][X.501]
+ can support synchronization of the aliasedObjectName attribute as its
+ values are held and administrated as part of the alias entries.
+
+ Servers SHOULD support synchronization of the following operational
+ attributes: createTimestamp, modifyTimestamp, creatorsName,
+ modifiersName [RFC4512]. Servers MAY support synchronization of
+ other operational attributes.
+
+4.3. Collective Attributes
+
+ A collective attribute is "a user attribute whose values are the same
+ for each member of an entry collection" [X.501]. Use of collective
+ attributes in LDAP is discussed in [RFC3671].
+
+ Modification of a collective attribute generally affects the content
+ of multiple entries, which are the members of the collection. It is
+ inefficient to include values of collective attributes visible in
+ entries of the collection, as a single modification of a collective
+ attribute requires transmission of multiple SearchResultEntry (one
+ for each entry of the collection that the modification affected).
+
+ Servers SHOULD NOT synchronize collective attributes appearing in
+ entries of any collection. Servers MAY support synchronization of
+ collective attributes appearing in collective attribute subentries.
+
+4.4. Access and Other Administrative Controls
+
+ Entries are commonly subject to access and other administrative
+ Controls. While portions of the policy information governing a
+ particular entry may be held in the entry, policy information is
+ often held elsewhere (in superior entries, in subentries, in the root
+ DSE, in configuration files, etc.). Because of this, changes to
+ policy information make it difficult to ensure eventual convergence
+ during incremental synchronization.
+
+ Where it is impractical or infeasible to generate content changes
+ resulting from a change to policy information, servers may opt to
+ return e-syncRefreshRequired or to treat the Sync Operation as an
+ initial content request (e.g., ignore the cookie or the
+ synchronization state represented in the cookie).
+
+5. Interaction with Other Controls
+
+ The Sync Operation may be used with:
+
+ - ManageDsaIT Control [RFC3296]
+
+
+
+
+Zeilenga & Choi Experimental [Page 23]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ - Subentries Control [RFC3672]
+
+ as described below. The Sync Operation may be used with other LDAP
+ extensions as detailed in other documents.
+
+5.1. ManageDsaIT Control
+
+ The ManageDsaIT Control [RFC3296] indicates that the operation acts
+ upon the DSA Information Tree and causes referral and other special
+ entries to be treated as object entries with respect to the
+ operation.
+
+5.2. Subentries Control
+
+ The Subentries Control is used with the search operation "to control
+ the visibility of entries and subentries which are within scope"
+ [RFC3672]. When used with the Sync Operation, the subentries control
+ and other factors (search scope, filter, etc.) are used to determine
+ whether an entry or subentry appears in the content.
+
+6. Shadowing Considerations
+
+ As noted in [RFC4511], some servers may hold shadow copies of entries
+ that can be used to answer search and comparison queries. Such
+ servers may also support content synchronization requests. This
+ section discusses considerations for implementors and deployers for
+ the implementation and deployment of the Sync operation in shadowed
+ directories.
+
+ While a client may know of multiple servers that are equally capable
+ of being used to obtain particular directory content from, a client
+ SHOULD NOT assume that each of these servers is equally capable of
+ continuing a content synchronization session. As stated in Section
+ 3.1, the client SHOULD issue each Sync request of a Sync session to
+ the same server.
+
+ However, through domain naming or IP address redirection or other
+ techniques, multiple physical servers can be made to appear as one
+ logical server to a client. Only servers that are equally capable in
+ regards to their support for the Sync operation and that hold equally
+ complete copies of the entries should be made to appear as one
+ logical server. In particular, each physical server acting as one
+ logical server SHOULD be equally capable of continuing a content
+ synchronization based upon cookies provided by any of the other
+ physical servers without requiring a full reload. Because there is
+ no standard LDAP shadowing mechanism, the specification of how to
+ independently implement equally capable servers (as well as the
+ precise definition of "equally capable") is left to future documents.
+
+
+
+Zeilenga & Choi Experimental [Page 24]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Note that it may be difficult for the server to reliably determine
+ what content was provided to the client by another server, especially
+ in the shadowing environments that allow shadowing events to be
+ coalesced. For these servers, the use of the delete phase discussed
+ in Section 3.3.2 may not be applicable.
+
+7. Security Considerations
+
+ In order to maintain a synchronized copy of the content, a client is
+ to delete information from its copy of the content as described
+ above. However, the client may maintain knowledge of information
+ disclosed to it by the server separate from its copy of the content
+ used for synchronization. Management of this knowledge is beyond the
+ scope of this document. Servers should be careful not to disclose
+ information for content the client is not authorized to have
+ knowledge of and/or about.
+
+ While the information provided by a series of refreshOnly Sync
+ Operations is similar to that provided by a series of Search
+ Operations, persist stage may disclose additional information. A
+ client may be able to discern information about the particular
+ sequence of update operations that caused content change.
+
+ Implementors should take precautions against malicious cookie
+ content, including malformed cookies or valid cookies used with
+ different security associations and/or protections in an attempt to
+ obtain unauthorized access to information. Servers may include a
+ digital signature in the cookie to detect tampering.
+
+ The operation may be the target of direct denial-of-service attacks.
+ Implementors should provide safeguards to ensure the operation is not
+ abused. Servers may place access control or other restrictions upon
+ the use of this operation.
+
+ Note that even small updates to the directory may cause a significant
+ amount of traffic to be generated to clients using this operation. A
+ user could abuse its update privileges to mount an indirect denial of
+ service to these clients, other clients, and/or portions of the
+ network. Servers should provide safeguards to ensure that update
+ operations are not abused.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP security considerations [RFC4510].
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 25]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+8. IANA Considerations
+
+ Registration of the following values have been completed by the IANA
+ [RFC4520].
+
+8.1. Object Identifier
+
+ The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+8.2. LDAP Protocol Mechanism
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
+ Description: LDAP Content Synchronization Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4533
+ Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+ Comments: none
+
+8.3. LDAP Result Codes
+
+ The IANA has registered the LDAP Result Code described in this
+ document.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: e-syncRefreshRequired (4096)
+ Specification: RFC 4533
+ Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+ Comments: none
+
+9. Acknowledgements
+
+ This document borrows significantly from the LDAP Client Update
+ Protocol [RFC3928], a product of the IETF LDUP working group. This
+ document also benefited from Persistent Search [PSEARCH], Triggered
+ Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
+ This document also borrows from "Lightweight Directory Access
+ Protocol (v3)" [RFC2251].
+
+
+
+
+Zeilenga & Choi Experimental [Page 26]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Cancel Operation", RFC 3909, October 2004.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) entryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [UUID] International Organization for Standardization (ISO),
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996
+
+ [X.501] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory -- Models,"
+ X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(1997)
+ (also ISO/IEC 8824-1:1998).
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 27]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(1997) (also ISO/IEC 8825-1:1998).
+
+11. Informative References
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J.
+ Parham, "Lightweight Directory Access Protocol (LDAP)
+ Client Update Protocol (LCUP)", RFC 3928, October 2004.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [X.500] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory -- Overview of
+ concepts, models and services," X.500(1993) (also ISO/IEC
+ 9594-1:1994).
+
+ [X.525] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Replication",
+ X.525(1993).
+
+ [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
+ Synchronization", Work in Progress.
+
+ [PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP
+ Change Notification Mechanism", Work in Progress.
+
+ [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in
+ Progress.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 28]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Appendix A. CSN-based Implementation Considerations
+
+ This appendix is provided for informational purposes only; it is not
+ a normative part of the LDAP Content Synchronization Operation's
+ technical specification.
+
+ This appendix discusses LDAP Content Synchronization Operation server
+ implementation considerations associated with Change Sequence Number
+ based approaches.
+
+ Change Sequence Number based approaches are targeted for use in
+ servers that do not maintain history information (e.g., change logs,
+ state snapshots) about changes made to the Directory and hence, must
+ rely on current directory state and minimal synchronization state
+ information embedded in Sync Cookie. Servers that maintain history
+ information should consider other approaches that exploit the history
+ information.
+
+ A Change Sequence Number is effectively a time stamp that has
+ sufficient granularity to ensure that the precedence relationship in
+ time of two updates to the same object can be determined. Change
+ Sequence Numbers are not to be confused with Commit Sequence Numbers
+ or Commit Log Record Numbers. A Commit Sequence Number allows one to
+ determine how two commits (to the same object or different objects)
+ relate to each other in time. A Change Sequence Number associated
+ with different entries may be committed out of order. In the
+ remainder of this Appendix, the term CSN refers to a Change Sequence
+ Number.
+
+ In these approaches, the server not only maintains a CSN for each
+ directory entry (the entry CSN) but also maintains a value that we
+ will call the context CSN. The context CSN is the greatest committed
+ entry CSN that is not greater than any outstanding (uncommitted)
+ entry CSNs for all entries in a directory context. The values of
+ context CSN are used in syncCookie values as synchronization state
+ indicators.
+
+ As search operations are not isolated from individual directory
+ update operations and individual update operations cannot be assumed
+ to be serialized, one cannot assume that the returned content
+ incorporates each relevant change whose change sequence number is
+ less than or equal to the greatest entry CSN in the content. The
+ content incorporates all the relevant changes whose change sequence
+ numbers are less than or equal to context CSN before search
+ processing. The content may also incorporate any subset of the
+ changes whose change sequence number is greater than context CSN
+ before search processing but less than or equal to the context CSN
+ after search processing. The content does not incorporate any of the
+
+
+
+Zeilenga & Choi Experimental [Page 29]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ changes whose CSN is greater than the context CSN after search
+ processing.
+
+ A simple server implementation could use the value of the context CSN
+ before search processing to indicate state. Such an implementation
+ would embed this value into each SyncCookie returned. We'll call
+ this the cookie CSN. When a refresh was requested, the server would
+ simply generate "update" messages for all entries in the content
+ whose CSN is greater than the supplied cookie CSN and generate
+ "present" messages for all other entries in the content. However, if
+ the current context CSN is the same as the cookie CSN, the server
+ should instead generate zero "updates" and zero "delete" messages and
+ indicate a refreshDeletes of TRUE, as the directory has not changed.
+
+ The implementation should also consider the impact of changes to meta
+ information, such as access controls, that affect content
+ determination. One approach is for the server to maintain a
+ context-wide meta information CSN or meta CSN. This meta CSN would
+ be updated whenever meta information affecting content determination
+ was changed. If the value of the meta CSN is greater than the cookie
+ CSN, the server should ignore the cookie and treat the request as an
+ initial request for content.
+
+ Additionally, servers may want to consider maintaining some per-
+ session history information to reduce the number of messages needed
+ to be transferred during incremental refreshes. Specifically, a
+ server could record information about entries as they leave the scope
+ of a disconnected sync session and later use this information to
+ generate delete messages instead of present messages.
+
+ When the history information is truncated, the CSN of the latest
+ truncated history information entry may be recorded as the truncated
+ CSN of the history information. The truncated CSN may be used to
+ determine whether a client copy can be covered by the history
+ information by comparing it to the synchronization state contained in
+ the cookie supplied by the client.
+
+ When there is a large number of sessions, it may make sense to
+ maintain such history only for the selected clients. Also, servers
+ taking this approach need to consider resource consumption issues to
+ ensure reasonable server operation and to protect against abuse. It
+ may be appropriate to restrict this mode of operation by policy.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 30]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Authors' Addresses
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+ Jong Hyuk Choi
+ IBM Corporation
+
+ EMail: jongchoi@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 31]
+\f
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 32]
+\f
projects / openldap / commitdiff