+
INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-14.txt Novell, Inc.
-Obsoletes: 2829, 2830 February, 2005
-Intended Category: Draft Standard
+draft-ietf-ldapbis-authmeth-18.txt Novell, Inc.
+Obsoletes: 2251, 2829, 2830 November, 2005
+Intended Category: Standards Track
LDAP: Authentication Methods
and
- Connection Level Security Mechanisms
+ Security Mechanisms
Status of this Memo
- 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, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
+ 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.
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.
+ Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
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
+ 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.
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
Abstract
-Harrison Expires August 2005 [Page 1]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ This document describes authentication methods and security
+ mechanisms of the Lightweight Directory Access Protocol (LDAP).
- This document describes authentication methods and connection level
- security mechanisms of the Lightweight Directory Access Protocol
- (LDAP).
- This document details establishment of TLS (Transport Layer
- Security) using the StartTLS operation.
+Harrison Expires March 2006 [Page 1]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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 plain-text password
- mechanisms and the SASL (Simple Authentication and Security Layer)
- Bind authentication method including DIGEST-MD5 and EXTERNAL
- mechanisms.
+ including anonymous, unauthenticated, and name/password mechanisms
+ and the Secure Authentication and Security Layer (SASL) Bind
+ authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization
- states through which a connection to an LDAP server may pass and the
+ states through which a session to an LDAP server may pass and the
actions that trigger these state changes.
Table of Contents
1. Introduction.....................................................3
1.1. Relationship to Other Documents................................5
- 1.2. Conventions....................................................5
+ 1.2. Conventions....................................................6
2. Implementation Requirements......................................6
3. StartTLS Operation...............................................7
- 3.1. Sequencing of the StartTLS Operation...........................7
- 3.1.1. StartTLS Request ............................................7
- 3.1.2. StartTLS Response............................................8
- 3.1.3. TLS Version Negotiation......................................8
- 3.1.4. Client Certificate...........................................8
- 3.1.5. Discovery of Resultant Security Level........................8
- 3.1.6. Server Identity Check........................................9
- 3.1.7. Refresh of Server Capabilities Information...................9
- 3.2. Effects of TLS on a Client's Authorization Identity...........10
- 3.3. TLS Ciphersuites..............................................10
- 3.3.1. TLS Ciphersuites Recommendations............................10
- 4. Associations....................................................11
- 4.1. Anonymous Association on Unbound Connections..................11
- 4.2. Anonymous Association After Failed Bind.......................12
- 4.3. Invalidated Associations......................................12
- 5. Bind Operation..................................................12
- 5.1. Simple Authentication Choice..................................12
- 5.2. SASL Authentication Choice....................................12
- 6. Anonymous Authentication Mechanism of Simple Bind...............13
- 7. Unauthenticated Authentication Mechanism of Simple Bind.........13
- 8. Simple Authentication Mechanism of Simple Bind .................13
- 9. SASL Protocol Profile...........................................14
- 9.1. SASL Service Name for LDAP....................................14
- 9.2. SASL Authentication Initiation and Protocol Exchange..........14
- 9.3. Octet Where Negotiated Security Mechanisms Take Effect........15
- 9.4. Determination of Supported SASL Mechanisms....................15
-
-
-Harrison Expires August 2005 [Page 2]
+ 3.1. TLS Establishment Procedures...................................7
+ 3.1.1. StartTLS Request Sequencing..................................7
+ 3.1.2. Client Certificate...........................................8
+ 3.1.3. Server Identity Check........................................8
+ 3.1.3.1. Comparison of DNS Names....................................9
+ 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
+ 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
+
+Harrison Expires March 2006 [Page 2]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- 9.5. Rules for Using SASL Layers...................................16
- 9.6 Support for Multiple Authentications...........................16
- 9.7. SASL Authorization Identities.................................16
- 10. SASL DIGEST-MD5 Authentication Mechanism.......................17
- 11. SASL EXTERNAL Authentication Mechanism.........................17
- 11.1. Implicit Assertion...........................................18
- 11.2. Explicit Assertion...........................................18
- 12. Security Considerations........................................18
- 12.1. General LDAP Security Considerations.........................18
- 12.1.1. Password-related Security Considerations...................19
- 12.2. StartTLS Security Considerations.............................20
- 12.3. Unauthenticated Mechanism Security Considerations............20
- 12.4. Simple Mechanism Security Considerations.....................21
- 12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21
- 12.6. Related Security Considerations..............................21
- 13. IANA Considerations............................................21
- Acknowledgments....................................................21
- Normative References...............................................21
- Informative References.............................................23
- Author's Address...................................................23
- Appendix A. Association State Transition Tables....................23
- A.1. Association States............................................23
- A.2. Actions that Affect Association State.........................24
- A.3. Association State Transition Table............................24
- Appendix B. Authentication and Authorization Concepts..............25
- B.1. Access Control Policy.........................................25
- B.2. Access Control Factors........................................25
- B.3. Authentication, Credentials, Identity.........................25
- B.4. Authorization Identity........................................25
- Appendix C. RFC 2829 Change History................................26
- Appendix D. RFC 2830 Change History................................30
- Appendix E. RFC 2251 Change History................................30
- Appendix F. Change History to Combined Document....................31
- Intellectual Property Rights.......................................45
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 6.1. General LDAP Security Considerations..........................20
+ 6.2. StartTLS Security Considerations..............................20
+ 6.3. Bind Operation Security Considerations........................21
+ 6.3.1. Unauthenticated Mechanism Security Considerations...........21
+ 6.3.2. Name/Password Mechanism Security Considerations.............21
+ 6.3.3. Password-related Security Considerations....................22
+ 6.3.4. Hashed Password Security Considerations.....................23
+ 6.4. Related Security Considerations...............................23
+ 7. IANA Considerations.............................................23
+ 8. Acknowledgments.................................................23
+ 9. Normative References............................................23
+ 10. Informative References.........................................25
+ Author's Address...................................................25
+ Appendix A. Authentication and Authorization Concepts..............25
+ A.1. Access Control Policy.........................................26
+ A.2. Access Control Factors........................................26
+ A.3. Authentication, Credentials, Identity.........................26
+ A.4. Authorization Identity........................................26
+ Appendix B. Summary of Changes.....................................27
+ B.1. Changes Made to RFC 2251......................................27
+ B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............27
+ 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)....................28
+ B.2.2. Section 5.1 (Anonymous authentication procedure)............28
+ B.2.3. Section 6 (Password-based authentication)...................28
+ B.2.4. Section 6.1 (Digest authentication).........................28
+ 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).....29
+ B.2.8. Section 8 (Other mechanisms)................................29
+ B.2.9. Section 9 (Authorization identity)..........................29
+ B.2.10. Section 10 (TLS Ciphersuites)..............................29
+ 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)....30
+ B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......30
+ B.3.4. Section 5.1.1 (TLS Closure Effects).........................30
+ Appendix C. Changes for draft-ldapbis-authmeth-18..................30
+ Intellectual Property Rights.......................................31
+ Full Copyright Statement...........................................32
1. Introduction
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.
+ 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.
+
+
+
+Harrison Expires March 2006 [Page 3]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
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:
-
-
-
-
-Harrison Expires August 2005 [Page 3]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ 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 others'
- access.
+ (2) Unauthorized access to directory data by monitoring access of
+ others.
(3) Unauthorized access to reusable client authentication
- information by monitoring others' access.
+ information by monitoring access of others.
(4) Unauthorized modification of directory data.
- (5) Unauthorized modification of configuration information,
+ (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
- 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.
+ 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
+ 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
+ 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.
(1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous,
- unauthenticated, and authenticated-with-password mechanisms, and
- the Secure Authentication and Security Layer (SASL) method which
- supports a wide variety of authentication mechanisms,
+ unauthenticated, and name/password mechanisms, and the Secure
+ 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 protection by means of security layers in TLS or
- SASL mechanisms,
+ (LDAP does not offer a standard access control facility).
- (4) Data confidentiality protection by means of security layers in
- TLS or SASL mechanisms,
+Harrison Expires March 2006 [Page 4]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+ (3) Data integrity service by means of security layers in Transport
+ Layer Security (TLS) or SASL mechanisms.
-Harrison Expires August 2005 [Page 4]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ (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, and
+ 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 [RFC2401].
- At the moment, imposition of access controls is done by means
- outside the scope of LDAP.
-
- Considering the above requirements, experience has shown that simply
- allowing implementations to pick and choose among the possible
- alternatives 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 support only clear text passwords that provide inadequate
- security for most circumstances.
+ 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 are
- used in different systems (e.g. user name in string form). Because
- some authentication mechanisms transmit credentials in plain text
- form and/or do not provide data security services, it is necessary
- to ensure secure interoperability by identifying a mandatory-to-
- implement mechanism for establishing transport-layer security
- services.
+ 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.
- Appendix B contains example deployment scenarios that list the
- mechanisms that might be used to achieve a reasonable level of
- security in various circumstances.
+ 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].
+ Specification [Roadmap].
- This document obsoletes RFC 2829.
+ 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.
- Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
- remainder of RFC 2830 is obsoleted 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.
-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].
-Harrison Expires August 2005 [Page 5]
+Harrison Expires March 2006 [Page 5]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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).
services used in providing directory services, as well as
associations established by these services.
- The term "association" refers to the association that exists between
- the transport connection and its current authorization state. As a
- shorthand, an association with an authorization state of <state> can
- be referred to as a "<state> association", e.g. an association with
- an anonymous authorization state is an anonymous association.
+ 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
+ with the definitions provided in [RFC2828]. In addition, several
terms and concepts relating to security, authentication, and
- authorization are presented in Appendix C of this document. While
+ 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 C before reading the remainder of this document.
+ 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 simple bind (section 6).
+ 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 simple bind MUST
- support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section
- 10). DIGEST-MD5 is a reasonably strong authentication mechanism
- that provides (mandatory-to-implement) data security (data integrity
- and data confidentiality) services.
-
- LDAP implementations SHOULD support the simple (DN and password)
- authentication mechanism of simple bind (section 8).
- Implementations that support this authentication mechanism MUST be
- capable of protecting using TLS as established by the StartTLS
- operation (section 3), SHOULD disallow the use of this
-
-Harrison Expires August 2005 [Page 6]
+
+
+
+
+Harrison Expires March 2006 [Page 6]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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.
Some of these mechanisms are discussed below.
LDAP server implementations SHOULD support client assertion of
- authorization identity via the SASL EXTERNAL mechanism (sections
- 3.2.2 and 9).
+ 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_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite.
- LDAP server implementations SHOULD support the StartTLS operation
- (section 3), and server implementations that do support the StartTLS
- operation MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- ciphersuite.
3. StartTLS Operation
The Start Transport Layer Security (StartTLS) operation defined in
section 4.14 of [Protocol] provides the ability to establish TLS
- [TLS] on an LDAP connection.
+ [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 11), and then only if the SASL EXTERNAL implementation
+ section 5.2.3), and then only if the SASL EXTERNAL implementation
chooses to make use of the TLS credentials.
-3.1. Sequencing of the StartTLS Operation
+
+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 association including discovery
+ 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
- A client may send the StartTLS extended request at any time after
- establishing an LDAP connection, except:
+3.1.1. StartTLS Request Sequencing
- - when TLS is currently established on the connection,
- - when a multi-stage SASL negotiation is in progress on the
- connection, or
- - when it has not yet received responses for all operation
- requests previously issued on the connection.
+Harrison Expires March 2006 [Page 7]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
- As described in [Protocol] Section 4.14.2.2, a (detected) violation
- of any of these requirements results in a return of the
- operationsError resultCode.
+ 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.
-Harrison Expires August 2005 [Page 7]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ 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
+ 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 server hardware speed, network latencies,
- etc.
+ 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 4) before sending a
- StartTLS operation request.
+ 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. StartTLS Response
- The server will return an extended response with the resultCode of
- success if it is willing and able to negotiate TLS.
+3.1.2. Client Certificate
- It will return a resultCode other than success (as documented in
- [Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
- The state of the association is unaffected if a non-success
- resultCode is returned.
+ 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.
- 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 during 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. TLS Version Negotiation
- Negotiating the version of TLS to be used is a part of the TLS
- Handshake Protocol [TLS]. Please refer to that document for details.
+3.1.3. Server Identity Check
-3.1.4. Client Certificate
+ 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".
- If an LDAP server requests a client to provide its certificate
- during TLS negotiation and the client does not present a suitable
- 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
- binds using the SASL EXTERNAL authentication mechanism (section 9),
- information in the certificate may be used by the server to
- establish the client's authorization identity.
-3.1.5. Discovery of Resultant Security Level
+Harrison Expires March 2006 [Page 8]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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.
+
+
+3.1.3.1. Comparison of DNS Names
- After a TLS layer is established on a transport connection, both
- parties are to individually decide whether or not to continue based
- on the security level achieved. The procedure for ascertaining the
- TLS layer's security level is implementation dependent.
-Harrison Expires August 2005 [Page 8]
+
+
+Harrison Expires March 2006 [Page 9]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
- If the client or server decides that the security level is not high
- enough for it to continue, it SHOULD gracefully remove the TLS
- connection immediately after the TLS negotiation has completed (see
- [Protocol] section 4.13.3.1 and section 3.2.3 below). The client
- may then close the transport connection, attempt to StartTLS again,
- send an unbind request, or send any other LDAP request.
+ 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:
-3.1.6. Server Identity Check
+ * 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).
- 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.
+ 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.
- Matching is performed according to these rules:
+ 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.
- - The client MUST use the server name provided by the user (or
- other trusted entity) as the value to compare against the server
- name as expressed in the server's certificate. A hostname
- derived from user input is to be considered provided by the user
- only if derived in a secure fashion (e.g., DNSSEC).
- - If a subjectAltName extension of type dNSName is present in the
- certificate, it SHOULD be used as the source of the server's
- identity.
+3.1.3.2. Comparison of IP Addresses
- - The string values to be compared MUST be prepared according to
- the rules described in [Matching].
+ 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.
- - The "*" wildcard character is allowed. If present, it applies
- only to the left-most name component.
- For example, *.bar.com would match a.bar.com and b.bar.com, but
- it would not match a.x.bar.com nor would it match 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 with any
- one of the set is considered acceptable.
+3.1.3.3. Comparison of other subjectName types
- 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
- 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 connection and then return
- and/or log an error indicating that the server's identity is suspect.
+ Client implementations MAY support matching against subjectAltName
+ values of other types as described in other documents.
- 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 requested to provide. The
- client may need to make use of local policy information in making
- this determination.
-3.1.7. Refresh of Server Capabilities Information
+3.1.4. Discovery of Resultant Security Level
-Harrison Expires August 2005 [Page 9]
+
+
+
+
+
+
+Harrison Expires March 2006 [Page 10]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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.
- Upon installing a TLS layer, 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.
+
+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).
+ 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
-3.2. Effects of TLS on a Client's Authorization Identity
+ 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.
- The decision to keep or invalidate the established state of the
- association (section 4.3) after TLS layer installation or removal is
- a matter of local server policy.
3.3. TLS Ciphersuites
Several issues should be considered when selecting TLS ciphersuites
- that are appropriate for use in a given circumstance. These issues
+ 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
+ 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
- Client and server implementers should carefully consider the
value of the password or data being protected versus the level
- of confidentially protection provided by the ciphersuite to
+ of confidentiality protection provided by the ciphersuite to
ensure that the level of protection afforded by the ciphersuite
is appropriate.
+Harrison Expires March 2006 [Page 11]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+
- The ciphersuite's vulnerability (or lack thereof) to man-in-the-
- middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ 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 tolerable.
-3.3.1. TLS Ciphersuites Recommendations
+ - 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.
- [[TODO: Kurt will have someone from security to look at this and
- will propose how to handle discussion of specific TLS ciphersuites
- in this draft.]]
- As of the writing of this document, the following recommendations
- regarding TLS ciphersuites are applicable. Because circumstances are
+4. Authorization State
-Harrison Expires August 2005 [Page 10]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- constantly changing, this list must not be considered exhaustive,
- but is hoped that it will serve as a useful starting point for
- implementers.
-
- The following ciphersuites defined in [TLS] 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 [TLS] can be cracked easily
- (less than a day of CPU time on a standard CPU in 2000) and are NOT
- RECOMMENDED for use in confidentiality protection of passwords or
- data:
-
- 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:
-
- 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
-
-4. Associations
-
- Every LDAP connection has an associated authorization state referred
- to as the "association". 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 change
- the authorization state of the association.
-
-4.1. Anonymous Association on Unbound Connections
-
- Prior to the successful completion of a Bind operation and during
- any subsequent authentication exchange, the association has an
- anonymous authorization state. Among other things this implies that
- the client need not send a Bind Request in the first PDU of the LDAP
- message layer. The client may send any operation request prior to
- binding, and the server MUST treat it as if it had been performed
- after an anonymous bind operation (section 6). This association
- state is sometimes referred to as an implied anonymous bind.
-
-
-Harrison Expires August 2005 [Page 11]
+ 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 March 2006 [Page 12]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-4.2. Anonymous Association After Failed Bind
-
- Upon receipt of a Bind request, the association is moved to an
- anonymous state and only upon successful completion of the
- authentication exchange (and the Bind operation) is the association
- moved to an authenticated state. Thus, a failed Bind operation
- produces an anonymous association.
-
-4.3. Invalidated Associations
-
- The server may move the association to an invalidated state at any
- time, e.g. if an established security layer between the client and
- server has unexpectedly failed or been compromised. While the LDAP
- session has an invalidated association, the server may reject any
- operation request other than Bind, Unbind, and StartTLS by
- responding with a resultCode of strongerAuthRequired to indicate
- that the server requires stronger authentication before it will
- attempt to perform the requested operation. In practice, this means
- that the client needs to bind to(re)establish a suitably strong
- authorization state on the association before the server will
- attempt to perform the requested operation.
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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 on the association.
+ establish a new authorization state.
The Bind request typically specifies the desired authentication
identity. Some Bind mechanisms also allow the client to specify the
specified, the server derives it from the authentication identity in
an implementation-specific manner.
- If the authorization identity is specified the server MUST verify
+ 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
+ (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 Choice
- The simple authentication choice of the Bind Operation provides
+5.1. Simple Authentication Method
+
+ The simple authentication method of the Bind Operation provides
three authentication mechanisms:
- 1. An anonymous authentication mechanism (section 6),
+ - An anonymous authentication mechanism (section 5.1.1).
- 2. An unauthenticated authentication mechanism (section 7), and
+ - An unauthenticated authentication mechanism (section 5.1.2).
- 3. A simple authentication mechanism using credentials consisting
- of a name (in the form of an LDAP distinguished name [LDAPDN])
- and a password (section 8).
+ - 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.2. SASL Authentication Choice
-Harrison Expires August 2005 [Page 12]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+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.
- The sasl authentication choice of the Bind Operation provides
- facilities for using any SASL mechanism (sections 9-11) including
- authentication mechanisms and other services (e.g. data security
- services).
-6. Anonymous Authentication Mechanism of Simple Bind
+5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
- An LDAP client may use the anonymous authentication mechanism of the
- simple Bind choice to explicitly establish an anonymous association
- 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.
-7. Unauthenticated Authentication Mechanism of Simple Bind
+Harrison Expires March 2006 [Page 13]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
An LDAP client may use the unauthenticated authentication mechanism
- of the simple Bind choice to establish an anonymous association by
- sending a Bind request with a name value, a distinguished name in
- LDAP string form [LDAPDN] of non-zero length, and specifying the the
- simple authentication choice containing a password value of zero
- length.
-
- Unauthenticated binds can have significant security issues (see
- section 12.3). Servers SHOULD by default reject unauthenticated bind
- requests with a resultCode of invalidCredentials, and clients may
- need to actively detect situations where they would unintentionally
- make an unauthenticated bind request.
-
-8. Simple Authentication Mechanism of Simple Bind
-
- An LDAP client may use the simple authentication mechanism of the
- simple Bind choice to establish an authenticated association 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
+ 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 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
+ 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
+ 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 invalidA resultCode of success indicates that the credentials
- are valid and the server is willing to provide service to the entity
- these credentials identify.
+ 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 2005 [Page 13]
+Harrison Expires March 2006 [Page 14]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
+
+ The name/password authentication mechanism of the simple Bind method
+ is not suitable for authentication in environments without
+ confidentiality protection.
- Server behavior is undefined for bind requests specifying the simple
- authentication mechanism with a zero-length name value and a
- password value of non-zero length.
- The simple authentication mechanism of simple bind is not suitable
- for authentication in environments where there is no network or
- transport layer confidentiality.x
+5.2. SASL Authentication Method
-9. SASL Protocol Profile
+ 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).
- LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
- includes native anonymous and simple (plain text) authentication
- methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
- are typically not used with LDAP.
+
+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 5). This section explains how each of these
- profiling requirements are met by LDAP.
+ protocol ([SASL] section 4). This section explains how each of
+ these profiling requirements are met by LDAP.
-9.1. SASL Service Name for 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.
-9.2. SASL Authentication Initiation and Protocol Exchange
- SASL authentication is initiated via an LDAP Bind request
+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 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
+ MAY be used to provide an initial client response for
mechanisms that are defined to have the client send data first
- (see [SASL] sections 5 and 5.1).
+ (see [SASL] sections 3 and 5 ).
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires March 2006 [Page 15]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
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
+ 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 invoking the
- Bind operation multiple times. A challenge is indicated by the
- server sending a BindResponse PDU with the resultCode set to
- saslBindInProgress. This indicates that the server requires the
- client to send a new BindRequest PDU with the same sasl mechanism to
- continue the authentication process.
-
- To 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 PDU
- message to transmit each challenge. LDAP clients use the credentials
-
-Harrison Expires August 2005 [Page 14]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- field, an OCTET STRING, in the SaslCredentials sequence of a
- BindRequest PDU message to transmit each response. Note that unlike
- some Internet protocols where SASL is used, LDAP is not text based,
- thus no Base64 transformations are performed on these challenge and
- response values.
-
- Clients sending a BindRequest with the sasl choice selected SHOULD
- send an zero-length value in the name field. Servers receiving a
- bind request 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
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
+ 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
+ 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
- is not saslBindInProgress (either success or another error
- indication).
+ 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. If a server does not intend
- to send a challenge value in a BindResponse message, the server
- SHALL omit the serverSaslCreds field (rather than including the
- field with a zero-length value).
+ 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 March 2006 [Page 16]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
-9.3. Octet Where Negotiated Security Mechanisms Take Effect
+ 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 successful BindResponse in the
- exchange.
+ 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
+ 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.
-9.4. Determination of Supported SASL Mechanisms
+
+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
+ 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
-
-Harrison Expires August 2005 [Page 15]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- current LDAP session state. LDAP servers SHOULD allow a client with
- an anonymous association to retrieve the supportedSASLMechanisms
- attribute of the root DSE.
+ 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.
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
+ 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 connection.
+ their requirements before proceeding to use the session.
+
-9.5. Rules for Using SASL Layers
+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 it obtained prior to the initiation
+ of the SASL negotiation and not obtained through secure mechanisms.
+
+Harrison Expires March 2006 [Page 17]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
- If a SASL layer is installed, the client SHOULD discard 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
+ 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 SASL
layer does not affect the continuing service of the TLS layer and
vice versa.
-9.6 Support for Multiple Authentications
- LDAP supports multiple SASL authentications as defined in [SASL]
- section 6.3.
-
-9.7. SASL Authorization Identities
-
- Some SASL mechanisms allow clients to request a desired
- authorization identity for the association. The decision to allow or
- disallow the current authentication identity to have access to the
- requested authorization identity is a matter of local policy ([SASL]
- section 4.2). The authorization identity is a string of UTF-8
- [RFC3629] encoded [Unicode] characters corresponding to the
- following ABNF [RFC2234] grammar:
+5.2.1.7. Support for Multiple Authentications
- authzId ::= dnAuthzId / uAuthzId
+ LDAP supports multiple SASL authentications as defined in [SASL]
+ section 4.
- DNCOLON ::= %x64 %x6e %x3a ; "dn:"
- UCOLON ::= %x75 %x3a ; "u:"
- ; distinguished-name-based authz id.
- dnAuthzId ::= DNCOLON distinguishedName
+5.2.1.8. SASL Authorization Identities
- ; unspecified authorization id, UTF-8 encoded.
- uAuthzId ::= UCOLON userid
- userid ::= *UTF8 ; syntax unspecified
+ 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:
- where the <distinguishedName> production is defined in section 3 of
- [LDAPDN] and the <UTF8> production is defined in section 1.3 of
- [Models].
+ authzId = dnAuthzId / uAuthzId
-Harrison Expires August 2005 [Page 16]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ ; distinguished-name-based authz id
+ dnAuthzId = "dn:" distinguishedName
+ ; unspecified authorization id, UTF-8 encoded
+ uAuthzId = "u:" userid
+ userid = *UTF8 ; syntax unspecified
- In order to support additional specific authorization identity
- forms, future updates to this specification may add new choices
- supporting other forms of the authzId production.
+ 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
+ the distinguishedNameMatch matching rule [Syntaxes]. There is no
requirement that the asserted distinguishedName value be that of an
entry in the directory.
The uAuthzId choice allows clients to assert an authorization
- identity that is not in distinguished name form. The format of
- userid is defined as only a sequence of UTF-8 [RFC3629] encoded
+ 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 using
- [SASLPrep] and then the two values are compared octet-wise.
-
-10. SASL DIGEST-MD5 Authentication Mechanism
-
- The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
- authentication with protection against passive eavesdropping attacks
- but does not provide protection against man-in-the-middle attacks.
- DIGEST-MD5 also provides data integrity and data confidentiality
- capabilities.
-
- Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
- OPTIONAL in clients and servers.
-
- Implementers must take care to ensure that they maintain the
- semantics of the DIGEST-MD5 specification even when handling data
- that has different semantics in the LDAP protocol.
- For example, the SASL DIGEST-MD5 authentication mechanism utilizes
- realm and username values ([DIGEST-MD5] section 2.1) which are
- syntactically simple strings and semantically simple realm and
- username values. These values are not LDAP DNs, and there is no
- requirement that they be represented or treated as such. Username
- and realm values that look like LDAP DNs in form, e.g. <cn=bob,
- dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
- treats them as simple strings for comparison purposes. To illustrate
- further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
- <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
- being compared semantically as LDAP DNs because the cn attribute is
- defined to be case insensitive, however the two values are not
- equivalent if they represent username values in DIGEST-MD5 because
- [SASLPrep] semantics are used by DIGEST-MD5.
-
-11. 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
+ 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.
-Harrison Expires August 2005 [Page 17]
+Harrison Expires March 2006 [Page 18]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
+
+
+ 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 or IP-level security
- [RFC2401]).
-
- The authorization identity used to determine the resulting
- association is derived from the security credentials in an
- implementation-specific manner. 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 association in an anonymous state (section 5), the
- state of any installed security layer is unaffected.
+ [RFC2401]). 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 an
- authorization identity desired for the association. The former is
- known as an implicit assertion, and the latter as an explicit
- assertion.
+ 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.
+
-11.1. Implicit Assertion
+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
+ (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
+ 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
+ local policy. The underlying mechanics of how this is accomplished
are implementation specific.
-11.2. Explicit Assertion
+
+
+Harrison Expires March 2006 [Page 19]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+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 9.7.
+ 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.
-12. Security Considerations
- Security issues are discussed throughout this document. The
+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.
-12.1. General LDAP 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 by database administrators. Access
+ 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.
+
+ 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
+
+
+Harrison Expires March 2006 [Page 20]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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 SHOULD by default 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 configured
+ to refuse to proceed without an acceptable level of security.
+
+ 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 2005 [Page 18]
+ 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
+
+
+Harrison Expires March 2006 [Page 21]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- control SHOULD always be applied when reading sensitive information
- or updating directory information.
-
- Servers can minimize denial of service attacks by providing the
- ability to configure and enforce administrative limits on
- operations, timing out idle connections and returning the
- unwillingToPerform resultCode rather than performing computationally
- expensive operations requested by unauthorized clients.
-
- A connection on which the client has not established connection
- 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
- implementors SHOULD take measures to protect confidential 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.
-
-12.1.1. Password-related Security Considerations
+Internet-Draft LDAP Authentication Methods September 2005
+
+ 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,
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 support authentication methods using
- cleartext passwords and other unprotected authentication credentials
- unless the data on the connection is protected using TLS or other
- data confidentiality and data integrity protection.
+ 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.
OR
Some other data confidentiality mechanism that protects the
- password value from snooping has been provided.
-
-Harrison Expires August 2005 [Page 19]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
+ password value from eavesdropping has been provided.
OR
The server returns a resultCode of confidentialityRequired for
- the operation (i.e. simple 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.
-
-12.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 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, 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
- connection. For example, the security level of the TLS layer might
- have been negotiated down to plaintext.
-
- Clients SHOULD by default 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 configured
- to refuse to proceed without an acceptable level of security.
+ 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 implementors 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.
+ 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.
- Implementers should be aware of and understand TLS security
- considerations as discussed in the TLS specification [TLS].
-12.3. Unauthenticated Mechanism Security Considerations
- Operational experience shows that clients can (and frequently do)
- misuse the unauthenticated authentication mechanism of simple bind
- (see section 7). For example, a client program might make a
- decision to grant access to non-directory information on the basis
- of completing a successful bind operation. LDAP server
- implementations may return a success response to an unauthenticated
- bind request thus leaving the client with the impression that the
- server has successfully authenticated the identity represented by
- the user name when in reality, an anonymous association 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.
-
-
-Harrison Expires August 2005 [Page 20]
+Harrison Expires March 2006 [Page 22]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-12.4. Simple Mechanism Security Considerations
-
- The simple authentication mechanism of simple bind discloses the
- password to the server, which is an inherent security risk. There
- are other mechanisms such as DIGEST-MD5 that do not disclose
- password to server.
+Internet-Draft LDAP Authentication Methods September 2005
-12.5. SASL DIGEST-MD5 Mechanism Security Considerations
+6.3.4. Hashed Password Security Considerations
- The SASL DIGEST-MD5 mechanism is prone to the qop substitution
- attack, as discussed in 3.6 of [DIGEST-MD5]. The qop substitution
- attack can be mitigated (as discussed in 3.6 of [DIGEST-MD5]).
+ 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.
- The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
- authentication with protection against passive eavesdropping attacks
- but does not provide protection against man-in-the-middle attacks.
- Implementers should be aware of and understand DIGEST-MD5 security
- considerations as discussed in the DIGEST-MD5 specification [DIGEST-
- MD5].
-
-12.6. Related Security Considerations
+6.4. 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], [SASLPrep], [StringPrep] and
+ apply and can be found in [SASL], [RFC4013], [StringPrep] and
[RFC3629].
-13. IANA Considerations
- The following IANA considerations apply to this document:
+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.
- [[TODO: add any missing IANA Considerations.]]
-
-Acknowledgments
- This document combines information originally contained in RFC 2829
- and RFC 2830. The editor acknowledges the work of Harald Tveit
- Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
- and Mark Wahl, each of whom authored one or more of these documents.
+8. Acknowledgments
- This document is based upon input of the IETF LDAP Revision working
- group. The contributions and suggestions made by its members in
- shaping the contents and technical accuracy of this document is
- greatly appreciated.
+ This document combines information originally contained in RFC 2251,
+ RFC 2829 and RFC 2830 which are products of the LDAP Extensions
+ (LDAPEXT) Working Group.
-Normative References
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ working group.
-
-Harrison Expires August 2005 [Page 21]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+9. Normative References
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]]
- [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234, November 1997.
-
- [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.
-
- [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
[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.
Information Models", draft-ietf-ldapbis-models-xx.txt,
a work in progress.
+Harrison Expires March 2006 [Page 23]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+
[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.
+
+ [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.
Security Layer (SASL)", 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).
+ [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
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, STD 63, November 2003.
-Harrison Expires August 2005 [Page 22]
+
+
+
+Harrison Expires March 2006 [Page 24]
\f
-Internet-Draft LDAP Authentication Methods February 2005
+Internet-Draft LDAP Authentication Methods September 2005
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-Informative References
- [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-
- zeilenga-sasl-anon-xx.txt, a work in progress.
+10. Informative References
- [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
- 2000.
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
- sasl-plain-xx.txt, a work in progress.
+ [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.
+
+ [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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
+1 801 861 2642
roger_harrison@novell.com
-Appendix A. Association State Transition Tables
-
- This section provides a state transition table to represent a state
- diagram for the various authentication states through which an
- association may pass during the course of its existence and the
- actions that cause these changes in state.
- This section is based entirely on information found in this document
- and other documents that are part of the LDAP Technical
- Specification [Roadmap]. As such, it is strictly informational in
- nature.
+Appendix A. Authentication and Authorization Concepts
-A.1. Association States
-
- The following table lists the valid association states and provides
- a description of each state. The ID for each state is used in the
- state transition table in section A.3.
-
- ID Association State Description
- -- --------------------------------------------------------------
-
-
-Harrison Expires August 2005 [Page 23]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- S1 Anonymous
- no Authentication ID is associated with the LDAP connection
- no Authorization ID is in force
- S2 Authenticated
- Authentication ID = I
- Authorization ID = X
- S3 Invalidated
-
-A.2. Actions that Affect Association State
-
- The following table lists the actions that can affect the
- authentication and authorization state of an association. The ID for
- each action is used in the state transition table in section A.3.
-
- ID Action
- -- --------------------------------------------------------------
- A1 Client bind request fails
- A2 Client successfully performs anonymous simple bind or
- unauthenticated simple bind
- A3 Client successfully binds producing an authentication ID of I.
- Authentication ID I maps to authorization ID X. Depending on
- the bind mechanism and associated parameters authorization ID X
- was either derived from authentication ID I or was explicitly
- requested as part of the bind operation.
- A4 Client StartTLS request fails
- A5 Client StartTLS request succeeds
- A6 Client or Server: graceful TLS layer removal
- A7 Server decides to invalidate current association state
-
-A.3. Association State Transition Table
-
- The Association table below lists the the actions that could affect
- the authorization state of an association and the resulting state of
- an association after a given action occurs.
-
- S1, the initial state for the state machine described in this table,
- is the association state when an LDAP connection is initially
- established.
-
- Next State
- Action Comment
- ---------------- --------------- -------------------------------
- A1 S1 Section 4
- A2 S1 Sections 6 and 7
- A3 S2
- A4 no change [Protocol] section 4.14.2.2
- A5 no change or S3* [Protocol] section 4.14.2.1
- A6 no change or S3* [Protocol] section 4.14.3.1
- A7 S3
-
- * The server may invalidate the association after installing or
- removing a TLS layer (section 3.2).
-
-
-
-Harrison Expires August 2005 [Page 24]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-Appendix B. 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.
-B.1. Access Control Policy
+
+Harrison Expires March 2006 [Page 25]
+\f
+Internet-Draft LDAP Authentication Methods September 2005
+
+
+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
+ other entities accessing those resources. Security objects and
mechanisms, such as those described here, enable the expression of
access control policies and their enforcement.
-B.2. Access Control Factors
+
+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 (section 4.2 of
- [Protocol]). 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
+ 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 connection via which the request is transmitted,
- others (e.g. time of day) may be "environmental".
+ associated with the transport 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.
+ 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.
-B.3. Authentication, Credentials, Identity
+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 association state with the
- other party (typically a server). Authentication is the process of
+ 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
+ the identity they assert. An authentication identity is the name
presented in a credential.
- There are many forms of authentication credentials -- the form used
+ 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.
-
-B.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
-
-
-Harrison Expires August 2005 [Page 25]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- 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 [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 performed in an implementation-specific manner.
-
-Appendix C. RFC 2829 Change History
-
- This appendix lists the changes made to the text of RFC 2829 in
- preparing this document.
-
-C.0. General Editorial Changes
- Version -00
-
- - Changed other instances of the term LDAP to LDAP where v3 of the
- protocol is implied. Also made all references to LDAP use the
- same wording.
-
- - Miscellaneous grammatical changes to improve readability.
-
- - Made capitalization in section headings consistent.
-
- Version -01
-
- - Changed title to reflect inclusion of material from RFC 2830 and
- 2251.
-
-C.1. Changes to Section 1
-
- Version -01
-
- - Moved conventions used in document to a separate section.
-
-C.2. Changes to Section 2
-
- Version -01
-
- - Moved section to an appendix.
-
-C.3. Changes to Section 3
-
- Version -01
-
-
-Harrison Expires August 2005 [Page 26]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Moved section to an appendix.
-
-C.4 Changes to Section 4
-
- Version -00
-
- - Changed "Distinguished Name" to "LDAP distinguished name".
-
-C.5. Changes to Section 5
-
- Version -00
-
- - Added the following sentence: "Servers SHOULD NOT allow clients
- with anonymous authentication to modify directory entries or
- access sensitive information in directory entries."
-
-C.5.1. Changes to Section 5.1
-
- Version -00
-
- - Replaced the text describing the procedure for performing an
- anonymous bind (protocol) with a reference to section 4.2 of RFC
- 2251 (the protocol spec).
-
- Version -01
-
- - Brought text describing procedure for performing an anonymous
- bind from section 4.2 of RFC 2251 bis. This text will be
- removed from the draft standard version of that document.
-
-C.6. Changes to Section 6.
-
- Version -00
-
- Reorganized text in section 6.1 as follows:
-
- 1. Added a new section (6.1) titled "Simple Authentication" and
- moved one of two introductory paragraphs for section 6 into
- section 6.1. Added sentences to the paragraph indicating:
-
- a. simple authentication is not suitable for environments where
- confidentiality is not available.
-
- b. LDAP implementations SHOULD NOT support simple
- authentication unless confidentiality and data integrity
- mechanisms are in force.
-
- 2. Moved first paragraph of section 6 (beginning with "LDAP
- implementations MUST support authentication with a password...")
- to section on Digest Authentication (Now section 6.2).
-
-C.6.1. Changes to Section 6.1.
-
- Version -00 Renamed section to 6.2
-
-Harrison Expires August 2005 [Page 27]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-
- - Added sentence from original section 6 indicating that the
- DIGEST-MD5 SASL mechanism is required for all conforming LDAP
- implementations
-
-C.6.2. Changes to Section 6.2
-
- Version -00
-
- - Renamed section to 6.3
-
- - Reworded first paragraph to remove reference to user and the
- userPassword password attribute Made the first paragraph more
- general by simply saying that if a directory supports simple
- authentication that the simple bind operation MAY performed
- following negotiation of a TLS ciphersuite that supports
- confidentiality.
-
- - Replaced "the name of the user's entry" with "a DN" since not
- all bind operations are performed on behalf of a "user."
-
- - Added Section 6.3.1 heading just prior to paragraph 5.
-
- - Paragraph 5: replaced "The server" with "DSAs that map the DN
- sent in the bind request to a directory entry with a
- userPassword attribute."
-
-C.6.3. Changes to section 6.3.
-
- Version -00
-
- - Renamed to section 6.4.
-
-C.7. Changes to section 7.
-
- none
-
-C.7.1. Changes to section 7.1.
-
- Version -00
-
- - Clarified the entity issuing a certificate by moving the phrase
- "to have issued the certificate" immediately after
- "Certification Authority."
-
-C.8. Changes to section 8.
-
- Version -00
-
- - Removed the first paragraph because simple authentication is
- covered explicitly in section 6.
-
- - Added section 8.1. heading just prior to second paragraph.
-
-
-Harrison Expires August 2005 [Page 28]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Added section 8.2. heading just prior to third paragraph.
-
- - Added section 8.3. heading just prior to fourth paragraph.
-
- Version -01
-
- - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
- for Other Security Services) to bring material on SASL
- mechanisms together into one location.
-
-C.9. Changes to section 9.
-
- Version -00
-
- - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
- mechanism."
-
- - Added section 9.1. heading.
-
- - Modified a comment in the ABNF from "unspecified userid" to
- "unspecified authz id".
-
- - Deleted sentence, "A utf8string is defined to be the UTF-8
- encoding of one or more ISO 10646 characters," because it is
- redundant.
-
- - Added section 9.1.1. heading.
-
- - Added section 9.1.2. heading.
-
- Version -01
-
- - Moved entire section 9 to become section 3.5 so that it would be
- with other SASL material.
-
-C.10. Changes to Section 10.
-
- Version -00
-
- - Updated reference to cracking from a week of CPU time in 1997 to
- be a day of CPU time in 2000.
-
- - Added text: "These ciphersuites are NOT RECOMMENDED for use...
- and server implementers SHOULD" to sentence just prior the
- second list of ciphersuites.
-
- - Added text: "and MAY support other ciphersuites offering
- equivalent or better protection," to the last paragraph of the
- section.
-
-C.11. Changes to Section 11.
-
- Version -01
-
-
-Harrison Expires August 2005 [Page 29]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Moved to section 3.6 to be with other SASL material.
-
-C.12. Changes to Section 12.
-
- Version -00
-
- - Inserted new section 12 that specifies when SASL protections
- begin following SASL negotiation, etc. The original section 12
- is renumbered to become section 13.
-
- Version -01
-
- - Moved to section 3.7 to be with other SASL material.
-
-C.13. Changes to Section 13 (original section 12).
-
- None
-
-Appendix D. RFC 2830 Change History
-
- This appendix lists the changes made to the text of RFC 2830 in
- preparing this document.
-
-D.0. General Editorial Changes
-
- - Material showing the PDUs for the StartTLS response was broken
- out into a new section.
-
- - The wording of the definition of the StartTLS request and
- StartTLS response was changed to make them parallel. NO changes
- were made to the ASN.1 definition or the associated values of
- the parameters.
-
- - A separate section heading for graceful TLS closure was added
- for parallelism with section on abrupt TLS closure.
-
-Appendix E. RFC 2251 Change History
-
- This appendix lists the changes made to the text of RFC 2251 in
- preparing this document.
-
-E.0. General Editorial Changes
-
- - All material from section 4.2 of RFC 2251 was moved into this
- document.
-
- - A new section was created for the Bind Request
-
- - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
- after the section on the Bind Response for parallelism with the
- presentation of the StartTLS operations. The section was also
- subdivided to explicitly call out the various effects being
- described within it.
-
-
-Harrison Expires August 2005 [Page 30]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - All SASL profile information from RFC 2829 was brought within
- the discussion of the Bind operation (primarily sections 4.4 -
- 4.7).
-
-Appendix F. Change History to Combined Document
-
-F.1. Changes for draft-ldap-bis-authmeth-02
-
- General
-
- - Added references to other LDAP standard documents, to sections
- within the document, and fixed broken references.
-
- - General editorial changes--punctuation, spelling, formatting,
- etc.
-
- Section 1.
-
- - Added glossary of terms and added sub-section headings
-
- Section 2.
-
- - Clarified security mechanisms 3, 4, & 5 and brought language in
- line with IETF security glossary.
-
- Section 3.
-
- - Brought language in requirement (3) in line with security
- glossary.
-
- - Clarified that information fetched prior to initiation of TLS
- negotiation must be discarded
-
- -Clarified that information fetched prior to initiation of SASL
- negotiation must be discarded
-
- - Rewrote paragraph on SASL negotiation requirements to clarify
- intent
-
- Section 4.4.
-
- - Added stipulation that sasl choice allows for any SASL mechanism
- not prohibited by this document. (Resolved conflict between this
- statement and one that prohibited use of ANONYMOUS and PLAIN
- SASL mechanisms.)
-
- Section 5.3.6
-
- - Added a.x.bar.com to wildcard matching example on hostname check.
-
- Section 6
-
-
-
-
-Harrison Expires August 2005 [Page 31]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Added Association State Transition Tables to show the various
- states through which an association may pass along with the
- actions and decisions required to traverse from state to state.
-
- Appendix A
-
- - Brought security terminology in line with IETF security glossary
- throughout the appendix.
-
-F.2. Changes for draft-ldapbis-authmeth-03
-
- General
-
- - Added introductory notes and changed title of document and
- references to conform to WG chair suggestions for the overall
- technical specification.
-
- - Several issues--H.13, H.14, H.16, H.17--were resolved without
- requiring changes to the document.
-
- Section 3
-
- - Removed reference to /etc/passwd file and associated text.
-
- Section 4
-
- - Removed sections 4.1, 4.2 and parts of section 4.3. This
- information was being duplicated in the protocol specification
- and will now reside there permanently.
- Section 4.2
-
- - changed words, "not recommended" to "strongly discouraged"
+ 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.
- Section 4.3
- - Based on ldapbis WG discussion at IETF52 two sentences were
- added indicating that clients SHOULD NOT send a DN value when
- binding with the sasl choice and servers SHALL ignore any value
- received in this circumstance.
- -
+A.4. Authorization Identity
- Section 8.3.1
-
- - Generalized the language of this section to not refer to any
- specific password attribute or to refer to the directory entry
- as a "user" entry.
+ 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."
- Section 11
- - Added security consideration regarding misuse of unauthenticated
- access.
- - Added security consideration requiring access control to be
- applied only to authenticated users and recommending it be
-Harrison Expires August 2005 [Page 32]
+Harrison Expires March 2006 [Page 26]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- applied when reading sensitive information or updating directory
- information.
-
-F.3. Changes for draft-ldapbis-authmeth-04
-
- General
+Internet-Draft LDAP Authentication Methods September 2005
- - Changed references to use [RFCnnnn] format wherever possible.
- (References to works in progress still use [name] format.)
- - Various edits to correct typos and bring field names, etc. in
- line with specification in [Protocol] draft.
-
- - Several issues--H.13, H.14, H.16, H.17--were resolved without
- requiring changes to the document.
-
- Section 4.4.1.
-
- - Changed ABNF grammar to use productions that are like those in
- the model draft.
-
- Section 5
-
- - Removed sections 5.1, 5.2, and 5.4 that will be added to
- [Protocol]. Renumbered sections to accommodate this change.
- -
+ 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.
+
+ 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.
- Section 6
- - Reviewed Association State table for completeness and accuracy.
- Renumbered actions A3, , and A5 to be A5, A3, and A4
- respectively. Re-ordered several lines in the table to ensure
- that actions are in ascending order (makes analyzing the table
- much more logical). Added action A2 to several states where it
- was missing and valid. Added actions A7 and A8 placeholders to
- states S1, S2, S4 and S5 pending resolution of issue H.28.
+B.1. Changes Made to RFC 2251
- Section 11
+ 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].
- - Modified security consideration (originally added in -03)
- requiring access control to be applied only to authenticated
- users. This seems nonsensical because anonymous users may have
- access control applied to limit permissible actions.
- -
- Section 13
- - Verified all normative references and moved informative
- references to a new section 14.
+B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
-F.4. Changes for draft-ldapbis-authmeth-05
- General
- - General editory changes to fix punctuation, spelling, line
- length issues, etc.
-Harrison Expires August 2005 [Page 33]
+Harrison Expires March 2006 [Page 27]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Verified and updated intra- and inter-document references
- throughout.
- - Document-wide review for proper usage of RFC 2119 keywords with
- several changes to correct improper usage.
-
- Abstract
- - Updated to match current contents of documents. This was needed
- due to movement of material on Bind and StartTLS operations to
- [Protocol] in this revision.
-
- Section 3.
-
- - Renamed section to "Rationale for LDAP Security Mechanisms" and
- removed text that did not support this theme. Part of the
- motivation for this change was to remove the implication of the
- previous section title, "Required Security Mechanisms", and
- other text found in the section that everything in the section
- was a requirement
+Internet-Draft LDAP Authentication Methods September 2005
- - Information from several removed paragraphs that describe
- deployment scenarios will be added Appendix A in the next
- revision of the draft.
+ - 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.
- - Paragraph beginning, " If TLS is negotiated, the client MUST
- discard all information..." was moved to section 5.1.7 and
- integrated with related material there.
- - Paragraph beginning, "If a SASL security layer is negotiated..."
- was moved to section 4.2
+B.1.2. Section 4.2.2 (Authentication and Other Security Services)
- Section 4.l.
+ - 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.
- - Changed wording of first paragraph to clarify meaning.
- Section 4.2.
- - Added paragraph from section 3 of -04 beginning, "If a SASL
- security layer is negotiated..."
+B.2. Changes Made to RFC 2829
- Section 4.3.3.
- - Renamed to "Other SASL Mechanisms" and completely rewrote the
- section (one sentence) to generalize the treatment of SASL
- mechanisms not explicitly mentioned in this document.
-
- Section 4.4.1.
-
- - Added paragraph beginning, "The dnAuthzID choice allows client
- applications..." to clarify whether DN form authorization
- identities have to also have a corresponding directory entry.
- This change was based on editor's perception of WG consensus.
-
- - Made minor clarifying edits in the paragraph beginning, "The
- uAuthzID choice allows for compatibility..."
-
-
-Harrison Expires August 2005 [Page 34]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ This section summarizes the substantive changes made to RFC 2829.
- Section 5.1.1.
- - Made minor clarifying edits in the last paragraph of the
- section.
+B.2.1. Section 4 (Required security mechanisms)
- Section 5.1.7.
+ - 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].
- - Wording from section 3 paragraph beginning " If TLS is
- negotiated, the client MUST discard all information..." was
- moved to this section and integrated with existing text.
- Section 5.2.
+B.2.2. Section 5.1 (Anonymous authentication procedure)
- - Changed usage of "TLS connection" to "TLS session" throughout.
+ - 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.
- - Removed empty section 5.2.1 and renumbered sections it had
- previously contained.
- Section 8.
+B.2.3. Section 6 (Password-based authentication)
- - Added introductory paragraph at beginning of section.
+ - See section B.2.1.
- Section 8.1.
- - Changed term "data privacy" to "data confidentiality" to be
- consistent with usage in rest of document.
+B.2.4. Section 6.1 (Digest authentication)
- Section 8.2.
- - Changed first paragraph to require implementations that
- implement *password-based* authentication to implement and
- support DIGEST-MD5 SASL authentication.
- Section 11.
- - First paragraph: changed "session encryption" to "session
- confidentiality protection" to be consistent with usage in rest
- of document.
- Appendix B.
-
- - Began changes to incorporate information on deployment scenarios
- removed from section 3.
-
-F.5. Changes for draft-ldapbis-authmeth-06
-
- General
-
- - Combined Section 2 (Introduction) and Section 3 (Motivation) and
- moved Introduction to section 1. All following sections numbers
- were decremented by one as result.
-
- - Edits to fix typos, I-D nits, etc.
-
-
-Harrison Expires August 2005 [Page 35]
+Harrison Expires March 2006 [Page 28]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Opened several new issues in Appendix G based on feedback from
- WG. Some of these have been resolved. Others require further
- discussion.
+Internet-Draft LDAP Authentication Methods September 2005
- Section 1
+ - 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.
- - Added additional example of spoofing under threat (7).
- Section 2.1
+B.2.5. Section 6.2 ("simple" authentication choice with TLS)
- - Changed definition of "association" and added terms,
- "connection" and "TLS connection" to bring usage in line with
- [Protocol].
+ - Renamed the "simple" authentication mechanism to the
+ name/password authentication mechanism to better describe it.
- Section 4.1.6
+ - 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.
- - Clarified sentence stating that the client MUST NOT use derived
- forms of DNS names.
+ - 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.
- Section 5.1
- - Began edits to association state table to clarify meaning of
- various states and actions.
+B.2.6. Section 6.3 (Other authentication choices with TLS)
- - Added action A9 to cover abandoned bind operation and added
- appropriate transitions to the state transition table to
- accommodate it.
+ - See section B.2.5.
- Section 7.2
- - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
- mechanism is required to implement.
+B.2.7. Section 7.1 (Certificate-based authentication with TLS)
- Section 9
+ - See section B.2.5.
- - Rewrote the section to make the advice more applicable over the
- long term, i.e. more "timeless." The intent of content in the
- original section was preserved.
- Section 10
+B.2.8. Section 8 (Other mechanisms)
- - Added a clarifying example to the consideration regarding misuse
- of unauthenticated access.
+ - 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.
-F.6. Changes for draft-ldapbis-authmeth-07
- General
-
- - Updated external and internal references to accommodate changes
- in recent drafts.
+B.2.9. Section 9 (Authorization identity)
- - Opened several new issues in Appendix G based on feedback from
- WG. Some of these have been resolved. Others require further
- discussion.
+ - 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.
-Harrison Expires August 2005 [Page 36]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ - Clarified that uAuthzID values should not be assumed to be
+ globally unique.
- Section 3
+B.2.10. Section 10 (TLS Ciphersuites)
- - Rewrote much of section 3.3 to meet the SASL profile
- requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
- - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
- bring in line with WG consensus.
- Section 4
-
- - Note to implementers in section 4.1.1 based on operational
- experience.
-
- - Clarification on client continuing by performing a StartTLS with
- TLS already established in section 4.1.4.
-
- - Moved verification of mapping of client's authentication ID to
- asserted authorization ID to apply only to explicit assertion.
- The local policy in place for implicit assertion is adequate.
-
- Section 7
-
- - Removed most of section 7.2 as the information is now covered
- adequately via the new SASL profile in section 3.3. Added note
- to implementors regarding the treatment of username and realm
- values in DIGEST-MD5.
-
- - Section 7.3. Minor clarifications in wording.
-
- - Section 7.3.1. Clarification that a match of the presented value
- to any member of the set of stored passwords constitutes a
- successful authentication.
-
-F.7. Changes for draft-ldapbis-authmeth-08
-
- General
-
- - Changed usage from LDAPv3 to LDAP for usage consistency across
- LDAP technical specification.
-
- - Fixed a number of usage nits for consistency and to bring doc in
- conformance with publication guidelines.
-
- Abstract
-
- - Significant cleanup and rewording of abstract based on WG
- feedback.
-
- Section 2.1
-
- - New definition of user.
-
- Section 3
-
-Harrison Expires August 2005 [Page 37]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-
- - Added 1.5 sentences at end of introductory paragraph indicating
- the effect of the Bind op on the association.
-
- Section 3.1
-
- - Retitled section and clarified wording
-
- Section 3.2
-
- - Clarified that simple authentication choice provides three types
- of authentication: anonymous, unauthenticated, and simple
- password.
-
- Section 3.3.3
-
- - New wording clarifying when negotiated security mechanisms take
- effect.
-
- Section 3.3.5
-
- - Changed requirement to discard information about server fetched
- prior to SASL negotiation from MUST to SHOULD to allow for
- information obtained through secure mechanisms.
-
- Section 3.3.6
-
- - Simplified wording of first paragraph based on suggestion from
- WG.
-
- Section 3.4
-
- - Minor clarifications in wording.
-
- Section 3.4.1
-
- - Minor clarifications in wording in first sentence.
- - Explicitly called out that the DN value in the dnAuthzID form is
- to be matched using DN matching rules.
- - Called out that the uAuthzID MUST be prepared using SASLprep
- rules before being compared.
- - Clarified requirement on assuming global uniqueness by changing
- a "generally... MUST" wording to "SHOULD".
-
- Section 4.1.1
-
- - Simplified wording describing conditions when StartTLS cannot be
- sent.
- - Simplified wording in note to implementers regarding race
- condition with outstanding LDAP operations on connection.
-
- Section 4.1.5
-
- - Removed section and moved relevant text to section 4.2.2.
-
-Harrison Expires August 2005 [Page 38]
+Harrison Expires March 2006 [Page 29]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
-
- Section 4.1.6
-
- - Renumbered to 4.1.5.
- - Updated server identity check rules for server's name based on
- WG list discussion.
-
- Section 4.1.7
-
- - Renumbered to 4.1.6
- - Changed requirement to discard information about server fetched
- prior to TLS negotion from MUST to SHOULD to allow for
- information obtained through secure mechanisms.
-
- Section 6.1
-
- - Clarified wording.
- - Added definition of anonymous and unauthenticated binds.
-
- Section 10
-
- - Added security consideration (moved from elsewhere) discouraging
- use of cleartext passwords on unprotected communication
- channels.
-
- Section 11
-
- - Added an IANA consideration to update GSSAPI service name
- registry to point to [Roadmap] and [Authmeth]
-
-F.8. Changes for draft-ldapbis-authmeth-09
-
- General
-
- - Updated section references within document
- - Changed reference tags to match other docs in LDAP TS
- - Used non-quoted names for all SASL mechanisms
-
- Abstract
+Internet-Draft LDAP Authentication Methods September 2005
- - Inspected keyword usage and removed several improper usages.
-
- - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
- implement mechanism. This is covered elsewhere in document.
-
- - Moved section 5, authentication state table, of -08 draft to
- section 8 of -09 and completely rewrote it.
-
- Section 1
-
- - Reworded sentence beginning, "It is also desirable to allow
- authentication methods to carry identities based on existing,
- non-LDAP DN-forms..."
-
-
-Harrison Expires August 2005 [Page 39]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Clarified relationship of this document to other documents in
- the LDAP TS.
-
- Section 3.3.5
-
- - Removed paragraph beginning,"If the client is configured to
- support multiple SASL mechanisms..." because the actions
- specified in the paragraph do not provide the protections
- indicated. Added a new paragraph indicating that clients and
- server should allow specification of acceptable mechanisms and
- only allow those mechanisms to be used.
-
- - Clarified independent behavior when TLS and SASL security layers
- are both in force (e.g. one being removed doesn't affect the
- other).
-
- Section 3.3.6
-
- - Moved most of section 4.2.2, Client Assertion of Authorization
- Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
-
- Section 3.3.6.4
-
- - Moved some normative comments into text body.
-
- Section 4.1.2
-
- - Non success resultCode values are valid if server is *unwilling*
- or unable to negotiate TLS.
-
- Section 4.2.1
-
- - Rewrote entire section based on WG feedback.
-
- Section 4.2.2
-
- - Moved most of this section to 3.3.6 for better document flow.
-
- Section 4.2.3
-
- - Rewrote entire section based on WG feedback.
-
- Section 5.1
-
- - Moved imperative language regarding unauthenticated access from
- security considerations to here.
-
- Section 6
-
- - Added several paragraphs regarding the risks of transmitting
- passwords in the clear and requiring server implementations to
- provide a specific configuration that reduces these risks.
-
- Section 6.2
-
-Harrison Expires August 2005 [Page 40]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
+ - 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.
- - Added sentence describing protections provided by DIGEST-MD5
- method.
- - Changed DNs in exmple to be dc=example,dc=com.
- Section 10
+B.3. Changes Made to RFC 2830:
- - Updated consideration on use of cleartext passwords to include
- other unprotected authentication credentials
- - Substantial rework of consideration on misuse of unauthenticated
- bind.
+ 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.
-F.9. Changes for draft-ldapbis-authmeth-10
- - Reorganized content of sections 3-9 to improve document flow and
- reduce redundancy.
- - Resolved issue of effect of Start TLS and TLS closure on
- association state.
- - Made numerous minor wording changes based on WG feedback.
- - Updated list of threats for Section 1.
- - Recommendation that servers should not support weaker TLS
- ciphersuites unless other protection is in place.
- - Moved authentication state table to appendix and relettered
- appendices.
+B.3.1. Section 3.6 (Server Identity Check)
-F.10. Changes for draft-ldapbis-authmeth-11
+ - 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.
- General
- - Many editorial changes throughout to clarify wording and better
- express intent, primarily based on suggestions from WG mail
- list.
- - More standard naming of authentication mechanisms throughout
- document, e.g. "Anonymous Authentication Mechanism of the Simple
- Bind Choice".
+B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
- Section 1
+ - 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.
- - Editorial changes to add clarity.
- - Moved section 2 of authmeth -09 into section 1
- Section 2
+B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
- - New section outlining implementation requirements.
+ - Establishing a TLS layer on an LDAP session may now cause the
+ authorization state of the LDAP session to change.
- Section 3.1.1
- - Editorial clarification on need for following operation
- sequencing requirements.
+B.3.4. Section 5.1.1 (TLS Closure Effects)
- Section 3.1.4
+ - 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-18
-Harrison Expires August 2005 [Page 41]
+Harrison Expires March 2006 [Page 30]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - New section added to describe use of client certificates with
- StartTLS. Incorporates material moved from other sections of
- authmeth -09.
-
- Section 4
- - New section added to discuss associations. Related material was
- moved from various other sections of authmeth -09 and
- incorporated into this new section.
+Internet-Draft LDAP Authentication Methods September 2005
- Section 5
+ [[Note to RFC Editor: Please remove this appendix upon publication
+ of this Internet-Draft as an RFC.]]
- - Added several paragraphs regarding transmission and derivation
- of authentication and authorization identities using the Bind
- operation.
+ This appendix is non-normative.
- Section 8
-
- - Clarified rules for determining valid credentials and situations
- where invalidCredentials result is to be returned.
-
- Section 14
-
- - Added three security considerations based on WG feedback.
-
- Appendix A
-
- - Simplfied state tables by removing two unnecessary actions from
- the actions table, and removing the current state column of the
- state transition table. Updated references to authmeth and
- [Protocol].
-
-F.11. Changes for draft-ldapbis-authmeth-12
+ This appendix summarizes changes made in this revision of the
+ document.
General
- - Changed refererences from Start TLS to StartTLS.
- - Removed Appendix B: Example Deployment Scenarios
- - Removed Appendix H as all issues listed in the appendix are now
- resolved.
-
- Section 2
-
- - Added implementation requirement that server implementations
- that SUPPORT StartTLS MUST support the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
- Section 3.1.2
+ - Resolved all known outstanding issues and comments for -17 draft.
+ - Edits for clarity and consistency.
- - Added wording clarifying that a client's association is
- unaffected if a non-success resultCode is returned in the
- StartTLS response.
-
- Section 9.2
-
-
-Harrison Expires August 2005 [Page 42]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Final paragraph of this section details requirements for
- serverSaslCreds field when no challenge value is sent.
-
- Section 10
-
- - Clarified language on uAuthzID usage.
-
- Section 12
-
- - Moved entire section into security considerations. New section
- number is 12.1.1.
- - Reorganized security considerations by topic.
- - Added several security considerations based on WG feedback.
-
- Section 13
-
- - Moved section to become section 3.3.
-
-F.12. Changes for draft-ldapbis-authmeth-13
-
- General
-
- - General edits for clarity and to remove errors.
- - Reworded definition of association (section 1.2) and reworked
- usage of association throughout document. Current semantics:
- every connection has an association with the same lifetime as
- the connection, and that association passes through various
- authorization states.
- - Made usage of data confidentiality consistent throughout
+ Section 1.1
+ - Added paragraph detailing which RFCs are obsoleted by this
document.
- Section 1
- - Reworded mechanisms 3 and 4 for more parallelism.
- - Changed language on rationale for required mechanisms from
- future to past tense.
-
Section 2
- - Clarified that implementations may support any additional
- authentication mechanism, not just mechanisms associated with
- simple and SASL bind choices.
-
- Section 3
- - Moved paragraph explaining goals for using TLS with LDAP from
- security considerations to here.
-
- Section 4.3
- - Reworked text to better explain meaning of strongAuthRequired
- resultCode when for invalidated associations.
-
- Section 8
- - Clarified action when simple bind request has a DN with invalid
- syntax.
-
- Section 12.1
-
-Harrison Expires August 2005 [Page 43]
-\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Added ability to configure and enforce administrative service
- limits as a way to protect against denial of service attacks.
+ - Deleted a sentence at the end of paragraph 2 that is redundant
+ with the first sentence of paragraph 3.
- Section 12.2
- - Clarified that this security consideration relates to performing
- client authentication during the TLS handshake and not to
- subsequent SASL EXTERNAL authentication.
+ Section 3.1.3.1
+ - Restored a wildcard matching example that was inadvertently
+ deleted by extensive edits to this section in -16 draft.
- Appendix A
- - Updated tables by collapsing identical states and actions. Also
- added an invalidated association state and accompanying actions.
+ Section 5.1.2
+ - Substantially edited this section to clarify the proper (and
+ improper) use of the distinguished name in the unauthenticated
+ authentication mechanism.
+ - Clarified client and server behavior to protect against security
+ risks associated with the unauthenticated authentication
+ mechanism.
+ Section 5.2.1.2
+ - Moved last sentence of this section into a new section 5.2.1.3
+ detailing optional fields used by LDAP.
+ Section 5.2.2
+ - Removed the third paragraph because it provided an example that
+ was misleading in that it implied that one could accurately
+ match data prepared for use with SASL mechanisms using LDAP
+ matching semantics.
-F.13. Changes for draft-ldapbis-authmeth-14
+ Appendix B
- General
-
- - Moved to standardized LDAP TS terms: transport connection, TLS
- layer, SASL layer, and LDAP message layer. Reworked usage of
- terminology throughout document to conform to latest usage.
- - Changed language on resultCode values to be less prescriptive
- and more descriptive.
+ - Added a list of substantive changes to RFC 2251.
- Section 1
- - Changed format and definitions of terms to parallel latest
- revision of [Protocol].
+Intellectual Property Rights
- Section 2
- - Updated implementation requirements for protecting LDAP simple
- bind mechanism to conform to WG consensus.
- Section 3.1.1
- - Moved last paragraph to security considerations and made
- generalized discussion of use of confidentialityRequired
- resultCode general for all data confidentiality services not
- just TLS.
- Section 3.1.4
- ûRewrote last paragraph to clarify that SASL EXTERNAL is a
- client action when server uses certificate information to
- derive authorization ID.
- Section 3.2
- ûCollapsed three subsections into a single subsection. Removed
- text that implied that the TLS credentials were the only lower
- layer credentials that are used by SASL EXTERNAL in determining
- authentication ID and authorization ID.
- Section 8
- - Removed most of last paragraph that was redundant with
- implementation requirements in section 2.
- Section 10
-Harrison Expires August 2005 [Page 44]
+Harrison Expires March 2006 [Page 31]
\f
-Internet-Draft LDAP Authentication Methods February 2005
-
- - Changed to SASL DIGEST-MD5 (was section 11 in -13 revision)
-
- Section 11
- - Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved
- discussion of SASL authorization identities to Section 9.7.
- Clarified language around implicit and explicit assertion of
- authroization identities.
-
- Appendix A
- - Further collapsed identical states and actions continuing work
- in previous revisions.
-
-Intellectual Property Rights
+Internet-Draft LDAP Authentication Methods September 2005
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
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.
+ 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
-Harrison Expires August 2005 [Page 45]
-\f
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires March 2006 [Page 32]
+\f
\ No newline at end of file
-
-Internet-Draft Editor: J. Sermersheim
-Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-31.txt May 2005
-Obsoletes: RFCs 2251, 2830, 3771
-
-
- LDAP: The Protocol
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 November 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>.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-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).
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 1
-\f
- Lightweight Directory Access Protocol Version 3
-
-
-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............................................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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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.
-
- 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 3.3.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 Nov 2005 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
- 8.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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 is typically not required to be present as the
- syntax and semantics of the response (including the format of the
- responseValue) is implicitly known and associated with the request by
- the messageID.
-
- If the Extended operation associated with the requestName is not
- supported by the server, the server MUST NOT provide a responseName
- nor a responseValue and MUST return with resultCode set to
- protocolError.
-
- The requestValue and responseValue fields contain any 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 Nov 2005 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 my 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 Nov 2005 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 Nov 2005 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 made, servers supporting the operation
- MUST return a StartTLS response message to the requestor. The
- responseName, if present, is also "1.3.6.1.4.1.1466.20037". The
- responseValue is absent.
-
- If the server is willing and able to negotiate TLS, it returns with
- the resultCode set to success. Refer to Section 4 of [AuthMeth] for
- details.
-
- 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.
-
-
-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.
-
-
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 38
-\f
- Lightweight Directory Access Protocol Version 3
-
- 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.
-
- - OCTET STRING values are encoded in the primitive form only.
-
-
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 39
-\f
- Lightweight Directory Access Protocol Version 3
-
- - 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.
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 40
-\f
- Lightweight Directory Access Protocol Version 3
-
- 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.
-
- 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.
-
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 41
-\f
- Lightweight Directory Access Protocol Version 3
-
- 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).
-
- [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).
-
-
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 42
-\f
- Lightweight Directory Access Protocol Version 3
-
- [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).
-
- [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.
-
-
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 43
-\f
- Lightweight Directory Access Protocol Version 3
-
- [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
-
- 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.
-
-Sermersheim Internet-Draft - Expires Nov 2005 Page 44
-\f
- Lightweight Directory Access Protocol Version 3
-
-
- It is requested that the IANA update the occurrence of "RFC XXXX" in
- Appendix B with this RFC number at publication.
-
-
-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 Nov 2005 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.
-
- Servers may substitute some result codes due to access controls which
- prevent their disclosure.
-
-
-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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 Page 50
-\f
- Lightweight Directory Access Protocol Version 3
-
-Appendix B - Complete ASN.1 Definition
-
- This appendix is normative.
-
- Lightweight-Directory-Access-Protocol-V3
- -- 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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 Nov 2005 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.
-
-
-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 Nov 2005 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 Nov 2005 Page 64
-\f
\ No newline at end of file
+ \r
+\r
+Internet-Draft Editor: J. Sermersheim \r
+Intended Category: Standard Track Novell, Inc \r
+Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005 \r
+Obsoletes: RFCs 2251, 2830, 3771 \r
+ \r
+ \r
+ LDAP: The Protocol \r
+ \r
+ \r
+Status of this Memo \r
+ \r
+ By submitting this Internet-Draft, each \r
+ author represents that any applicable patent or other IPR claims of \r
+ which he or she is aware have been or will be disclosed, and any of \r
+ which he or she becomes aware will be disclosed, in accordance with \r
+ Section 6 of BCP 79. \r
+ \r
+ Internet-Drafts are working documents of the Internet Engineering \r
+ Task Force (IETF), its areas, and its working groups. Note that other \r
+ groups may also distribute working documents as Internet-Drafts. \r
+ \r
+ Internet-Drafts are draft documents valid for a maximum of six months \r
+ and may be updated, replaced, or obsoleted by other documents at any \r
+ time. It is inappropriate to use Internet-Drafts as reference \r
+ material or to cite them other than as "work in progress". \r
+ \r
+ The list of current Internet-Drafts can be accessed at \r
+ http://www.ietf.org/ietf/1id-abstracts.txt. \r
+ \r
+ The list of Internet-Draft Shadow Directories can be accessed at \r
+ http://www.ietf.org/shadow.html. \r
+ \r
+ This Internet-Draft will expire in February 2005. \r
+ \r
+ Technical discussion of this document will take place on the IETF \r
+ LDAP Revision Working Group (LDAPbis) mailing list <ietf-\r
+ ldapbis@openldap.org>. Please send editorial comments directly to the \r
+ editor <jimse@novell.com>. \r
+ \r
+ \r
+Abstract \r
+ \r
+ This document describes the protocol elements, along with their \r
+ semantics and encodings, of the Lightweight Directory Access Protocol \r
+ (LDAP). LDAP provides access to distributed directory services that \r
+ act in accordance with X.500 data and service models. These protocol \r
+ elements are based on those described in the X.500 Directory Access \r
+ Protocol (DAP). \r
+ \r
+ \r
+Table of Contents \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 1 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ 1. Introduction....................................................3 \r
+ 1.1. Relationship to Other LDAP Specifications.....................3 \r
+ 2. Conventions.....................................................3 \r
+ 3. Protocol Model..................................................4 \r
+ 3.1 Operation and LDAP Message Layer Relationship..................5 \r
+ 4. Elements of Protocol............................................5 \r
+ 4.1. Common Elements...............................................5 \r
+ 4.1.1. Message Envelope............................................5 \r
+ 4.1.2. String Types................................................7 \r
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........7 \r
+ 4.1.4. Attribute Descriptions......................................8 \r
+ 4.1.5. Attribute Value.............................................8 \r
+ 4.1.6. Attribute Value Assertion...................................8 \r
+ 4.1.7. Attribute and PartialAttribute..............................9 \r
+ 4.1.8. Matching Rule Identifier....................................9 \r
+ 4.1.9. Result Message..............................................9 \r
+ 4.1.10. Referral..................................................11 \r
+ 4.1.11. Controls..................................................13 \r
+ 4.2. Bind Operation...............................................14 \r
+ 4.3. Unbind Operation.............................................17 \r
+ 4.4. Unsolicited Notification.....................................17 \r
+ 4.5. Search Operation.............................................18 \r
+ 4.6. Modify Operation.............................................29 \r
+ 4.7. Add Operation................................................31 \r
+ 4.8. Delete Operation.............................................31 \r
+ 4.9. Modify DN Operation..........................................32 \r
+ 4.10. Compare Operation...........................................33 \r
+ 4.11. Abandon Operation...........................................34 \r
+ 4.12. Extended Operation..........................................35 \r
+ 4.13. IntermediateResponse Message................................36 \r
+ 4.14. StartTLS Operation..........................................37 \r
+ 5. Protocol Encoding, Connection, and Transfer....................39 \r
+ 5.1. Protocol Encoding............................................39 \r
+ 5.2. Transmission Control Protocol (TCP)..........................40 \r
+ 5.3. Termination of the LDAP session..............................40 \r
+ 6. Security Considerations........................................40 \r
+ 7. Acknowledgements...............................................42 \r
+ 8. Normative References...........................................42 \r
+ 9. Informative References.........................................44 \r
+ 10. IANA Considerations...........................................44 \r
+ 11. Editor's Address..............................................45 \r
+ Appendix A - LDAP Result Codes....................................46 \r
+ A.1 Non-Error Result Codes........................................46 \r
+ A.2 Result Codes..................................................46 \r
+ Appendix B - Complete ASN.1 Definition............................51 \r
+ Appendix C - Changes..............................................57 \r
+ C.1 Changes made to RFC 2251:.....................................57 \r
+ C.2 Changes made to RFC 2830:.....................................62 \r
+ C.3 Changes made to RFC 3771:.....................................63 \r
+ \r
+ \r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 2 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+1. Introduction \r
+ \r
+ The Directory is "a collection of open systems cooperating to provide \r
+ directory services" [X.500]. A directory user, which may be a human \r
+ or other entity, accesses the Directory through a client (or \r
+ Directory User Agent (DUA)). The client, on behalf of the directory \r
+ user, interacts with one or more servers (or Directory System Agents \r
+ (DSA)). Clients interact with servers using a directory access \r
+ protocol. \r
+ \r
+ This document details the protocol elements of the Lightweight \r
+ Directory Access Protocol (LDAP), along with their semantics. \r
+ Following the description of protocol elements, it describes the way \r
+ in which the protocol elements are encoded and transferred. \r
+ \r
+ \r
+1.1. Relationship to Other LDAP Specifications \r
+ \r
+ This document is an integral part of the LDAP Technical Specification \r
+ [Roadmap] which obsoletes the previously defined LDAP technical \r
+ specification, RFC 3377, in its entirety. \r
+ \r
+ This document, together with [Roadmap], [AuthMeth], and [Models], \r
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by \r
+ [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by \r
+ [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5, \r
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph) \r
+ are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by \r
+ this document. Appendix C.1 summarizes substantive changes in the \r
+ remainder. \r
+ \r
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of \r
+ RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes \r
+ substantive changes to the remaining sections. \r
+ \r
+ This document also obsoletes RFC 3771 in entirety. \r
+ \r
+ \r
+2. Conventions \r
+ \r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", \r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are \r
+ to be interpreted as described in [Keyword]. \r
+ \r
+ Character names in this document use the notation for code points and \r
+ names from the Unicode Standard [Unicode]. For example, the letter \r
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. \r
+ \r
+ Note: a glossary of terms used in Unicode can be found in [Glossary]. \r
+ Information on the Unicode character encoding model can be found in \r
+ [CharModel]. \r
+ \r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 3 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The term "transport connection" refers to the underlying transport \r
+ services used to carry the protocol exchange, as well as associations \r
+ established by these services. \r
+ \r
+ The term "TLS layer" refers to TLS services used in providing \r
+ security services, as well as associations established by these \r
+ services. \r
+ \r
+ The term "SASL layer" refers to SASL services used in providing \r
+ security services, as well as associations established by these \r
+ services. \r
+ \r
+ The term "LDAP message layer" refers to the LDAP Message Protocol \r
+ Data Unit (PDU) services used in providing directory services, as \r
+ well as associations established by these services. \r
+ \r
+ The term "LDAP session" refers to combined services (transport \r
+ connection, TLS layer, SASL layer, LDAP message layer) and their \r
+ associations. \r
+ \r
+ See the table in Section 5 for an illustration of these four terms. \r
+ \r
+ \r
+3. Protocol Model \r
+ \r
+ The general model adopted by this protocol is one of clients \r
+ performing protocol operations against servers. In this model, a \r
+ client transmits a protocol request describing the operation to be \r
+ performed to a server. The server is then responsible for performing \r
+ the necessary operation(s) in the Directory. Upon completion of an \r
+ operation, the server typically returns a response containing \r
+ appropriate data to the requesting client. \r
+ \r
+ Protocol operations are generally independent of one another. Each \r
+ operation is processed as an atomic action, leaving the directory in \r
+ a consistent state. \r
+ \r
+ Although servers are required to return responses whenever such \r
+ responses are defined in the protocol, there is no requirement for \r
+ synchronous behavior on the part of either clients or servers. \r
+ Requests and responses for multiple operations generally may be \r
+ exchanged between a client and server in any order. If required, \r
+ synchronous behavior may be controlled by client applications. \r
+ \r
+ The core protocol operations defined in this document can be mapped \r
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511]. \r
+ However there is not a one-to-one mapping between LDAP operations and \r
+ X.500 Directory Access Protocol (DAP) operations. Server \r
+ implementations acting as a gateway to X.500 directories may need to \r
+ make multiple DAP requests to service a single LDAP request. \r
+ \r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 4 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+3.1. Operation and LDAP Message Layer Relationship \r
+ \r
+ Protocol operations are exchanged at the LDAP message layer. When the \r
+ transport connection is closed, any uncompleted operations at the \r
+ LDAP message layer, when possible, are abandoned, and when not \r
+ possible, are completed without transmission of the response. Also, \r
+ when the transport connection is closed, the client MUST NOT assume \r
+ that any uncompleted update operations have succeeded or failed. \r
+ \r
+ \r
+4. Elements of Protocol \r
+ \r
+ The protocol is described using Abstract Syntax Notation One \r
+ ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding \r
+ Rules ([BER]). Section 5 specifies how the protocol elements are \r
+ encoded and transferred. \r
+ \r
+ In order to support future extensions to this protocol, extensibility \r
+ is implied where it is allowed per ASN.1 (i.e. sequence, set, choice, \r
+ and enumerated types are extensible). In addition, ellipses (...) \r
+ have been supplied in ASN.1 types that are explicitly extensible as \r
+ discussed in [LDAPIANA]. Because of the implied extensibility, \r
+ clients and servers MUST (unless otherwise specified) ignore trailing \r
+ SEQUENCE components whose tags they do not recognize. \r
+ \r
+ Changes to the protocol other than through the extension mechanisms \r
+ described here require a different version number. A client indicates \r
+ the version it is using as part of the BindRequest, described in \r
+ Section 4.2. If a client has not sent a Bind, the server MUST assume \r
+ the client is using version 3 or later. \r
+ \r
+ Clients may attempt to determine the protocol versions a server \r
+ supports by reading the 'supportedLDAPVersion' attribute from the \r
+ root DSE (DSA-Specific Entry) [Models]. \r
+ \r
+ \r
+4.1. Common Elements \r
+ \r
+ This section describes the LDAPMessage envelope Protocol Data Unit \r
+ (PDU) format, as well as data type definitions, which are used in the \r
+ protocol operations. \r
+ \r
+ \r
+4.1.1. Message Envelope \r
+ \r
+ For the purposes of protocol exchanges, all protocol operations are \r
+ encapsulated in a common envelope, the LDAPMessage, which is defined \r
+ as follows: \r
+ \r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 5 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ LDAPMessage ::= SEQUENCE { \r
+ messageID MessageID, \r
+ protocolOp CHOICE { \r
+ bindRequest BindRequest, \r
+ bindResponse BindResponse, \r
+ unbindRequest UnbindRequest, \r
+ searchRequest SearchRequest, \r
+ searchResEntry SearchResultEntry, \r
+ searchResDone SearchResultDone, \r
+ searchResRef SearchResultReference, \r
+ modifyRequest ModifyRequest, \r
+ modifyResponse ModifyResponse, \r
+ addRequest AddRequest, \r
+ addResponse AddResponse, \r
+ delRequest DelRequest, \r
+ delResponse DelResponse, \r
+ modDNRequest ModifyDNRequest, \r
+ modDNResponse ModifyDNResponse, \r
+ compareRequest CompareRequest, \r
+ compareResponse CompareResponse, \r
+ abandonRequest AbandonRequest, \r
+ extendedReq ExtendedRequest, \r
+ extendedResp ExtendedResponse, \r
+ ..., \r
+ intermediateResponse IntermediateResponse }, \r
+ controls [0] Controls OPTIONAL } \r
+ \r
+ MessageID ::= INTEGER (0 .. maxInt) \r
+ \r
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- \r
+ \r
+ The ASN.1 type Controls is defined in Section 4.1.11. \r
+ \r
+ The function of the LDAPMessage is to provide an envelope containing \r
+ common fields required in all protocol exchanges. At this time the \r
+ only common fields are the messageID and the controls. \r
+ \r
+ If the server receives an LDAPMessage from the client in which the \r
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot \r
+ be parsed, the tag of the protocolOp is not recognized as a request, \r
+ or the encoding structures or lengths of data fields are found to be \r
+ incorrect, then the server SHOULD return the Notice of Disconnection \r
+ described in Section 4.4.1, with the resultCode set to protocolError, \r
+ and MUST immediately terminate the LDAP session as described in \r
+ Section 5.3. \r
+ \r
+ In other cases where the client or server cannot parse an LDAP PDU, \r
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where \r
+ further communication (including providing notice) would be \r
+ pernicious. Otherwise, server implementations MUST return an \r
+ appropriate response to the request, with the resultCode set to \r
+ protocolError. \r
+ \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 6 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+4.1.1.1. Message ID \r
+ \r
+ All LDAPMessage envelopes encapsulating responses contain the \r
+ messageID value of the corresponding request LDAPMessage. \r
+ \r
+ The message ID of a request MUST have a non-zero value different from \r
+ the messageID of any other request in progress in the same LDAP \r
+ session. The zero value is reserved for the unsolicited notification \r
+ message. \r
+ \r
+ Typical clients increment a counter for each request. \r
+ \r
+ A client MUST NOT send a request with the same message ID as an \r
+ earlier request in the same LDAP session unless it can be determined \r
+ that the server is no longer servicing the earlier request (e.g. \r
+ after the final response is received, or a subsequent Bind \r
+ completes). Otherwise the behavior is undefined. For this purpose, \r
+ note that Abandon and successfully abandoned operations do not send \r
+ responses. \r
+ \r
+ \r
+4.1.2. String Types \r
+ \r
+ The LDAPString is a notational convenience to indicate that, although \r
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the \r
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded \r
+ following the [UTF-8] algorithm. Note that Unicode characters U+0000 \r
+ through U+007F are the same as ASCII 0 through 127, respectively, and \r
+ have the same single octet UTF-8 encoding. Other Unicode characters \r
+ have a multiple octet UTF-8 encoding. \r
+ \r
+ LDAPString ::= OCTET STRING -- UTF-8 encoded, \r
+ -- [ISO10646] characters \r
+ \r
+ The LDAPOID is a notational convenience to indicate that the \r
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal \r
+ representation of an OBJECT IDENTIFIER. Although an LDAPOID is \r
+ encoded as an OCTET STRING, values are limited to the definition of \r
+ <numericoid> given in Section 1.4 of [Models]. \r
+ \r
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] \r
+ \r
+ For example, \r
+ \r
+ 1.3.6.1.4.1.1466.1.2.3 \r
+ \r
+ \r
+4.1.3. Distinguished Name and Relative Distinguished Name \r
+ \r
+ An LDAPDN is defined to be the representation of a Distinguished Name \r
+ (DN) after encoding according to the specification in [LDAPDN]. \r
+ \r
+ LDAPDN ::= LDAPString \r
+ -- Constrained to <distinguishedName> [LDAPDN] \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 7 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ A RelativeLDAPDN is defined to be the representation of a Relative \r
+ Distinguished Name (RDN) after encoding according to the \r
+ specification in [LDAPDN]. \r
+ \r
+ RelativeLDAPDN ::= LDAPString \r
+ -- Constrained to <name-component> [LDAPDN] \r
+ \r
+ \r
+4.1.4. Attribute Descriptions \r
+ \r
+ The definition and encoding rules for attribute descriptions are \r
+ defined in Section 2.5 of [Models]. Briefly, an attribute description \r
+ is an attribute type and zero or more options. \r
+ \r
+ AttributeDescription ::= LDAPString \r
+ -- Constrained to <attributedescription> \r
+ -- [Models] \r
+ \r
+ \r
+4.1.5. Attribute Value \r
+ \r
+ A field of type AttributeValue is an OCTET STRING containing an \r
+ encoded attribute value. The attribute value is encoded according to \r
+ the LDAP-specific encoding definition of its corresponding syntax. \r
+ The LDAP-specific encoding definitions for different syntaxes and \r
+ attribute types may be found in other documents and in particular \r
+ [Syntaxes]. \r
+ \r
+ AttributeValue ::= OCTET STRING \r
+ \r
+ Note that there is no defined limit on the size of this encoding; \r
+ thus protocol values may include multi-megabyte attribute values \r
+ (e.g. photographs). \r
+ \r
+ Attribute values may be defined which have arbitrary and non-\r
+ printable syntax. Implementations MUST NOT display nor attempt to \r
+ decode an attribute value if its syntax is not known. The \r
+ implementation may attempt to discover the subschema of the source \r
+ entry, and retrieve the descriptions of 'attributeTypes' from it \r
+ [Models]. \r
+ \r
+ Clients MUST only send attribute values in a request that are valid \r
+ according to the syntax defined for the attributes. \r
+ \r
+ \r
+4.1.6. Attribute Value Assertion \r
+ \r
+ The AttributeValueAssertion (AVA) type definition is similar to the \r
+ one in the X.500 Directory standards. It contains an attribute \r
+ description and a matching rule ([Models] Section 4.1.3) assertion \r
+ value suitable for that type. Elements of this type are typically \r
+ used to assert that the value in assertionValue matches a value of an \r
+ attribute. \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 8 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ AttributeValueAssertion ::= SEQUENCE { \r
+ attributeDesc AttributeDescription, \r
+ assertionValue AssertionValue } \r
+ \r
+ AssertionValue ::= OCTET STRING \r
+ \r
+ The syntax of the AssertionValue depends on the context of the LDAP \r
+ operation being performed. For example, the syntax of the EQUALITY \r
+ matching rule for an attribute is used when performing a Compare \r
+ operation. Often this is the same syntax used for values of the \r
+ attribute type, but in some cases the assertion syntax differs from \r
+ the value syntax. See objectIdentiferFirstComponentMatch in \r
+ [Syntaxes] for an example. \r
+ \r
+ \r
+4.1.7. Attribute and PartialAttribute \r
+ \r
+ Attributes and partial attributes consist of an attribute description \r
+ and attribute values. A PartialAttribute allows zero values, while \r
+ Attribute requires at least one value. \r
+ \r
+ PartialAttribute ::= SEQUENCE { \r
+ type AttributeDescription, \r
+ vals SET OF value AttributeValue } \r
+ \r
+ Attribute ::= PartialAttribute(WITH COMPONENTS { \r
+ ..., \r
+ vals (SIZE(1..MAX))}) \r
+ \r
+ No two of the attribute values may be equivalent as described by \r
+ Section 2.3 of [Models]. The set of attribute values is unordered. \r
+ Implementations MUST NOT rely upon the ordering being repeatable. \r
+ \r
+ \r
+4.1.8. Matching Rule Identifier \r
+ \r
+ Matching rules are defined in Section 4.1.3 of [Models]. A matching \r
+ rule is identified in the protocol by the printable representation of \r
+ either its <numericoid>, or one of its short name descriptors \r
+ [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'. \r
+ \r
+ MatchingRuleId ::= LDAPString \r
+ \r
+ \r
+4.1.9. Result Message \r
+ \r
+ The LDAPResult is the construct used in this protocol to return \r
+ success or failure indications from servers to clients. To various \r
+ requests, servers will return responses containing the elements found \r
+ in LDAPResult to indicate the final status of the protocol operation \r
+ request. \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 9 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ LDAPResult ::= SEQUENCE { \r
+ resultCode ENUMERATED { \r
+ success (0), \r
+ operationsError (1), \r
+ protocolError (2), \r
+ timeLimitExceeded (3), \r
+ sizeLimitExceeded (4), \r
+ compareFalse (5), \r
+ compareTrue (6), \r
+ authMethodNotSupported (7), \r
+ strongerAuthRequired (8), \r
+ -- 9 reserved -- \r
+ referral (10), \r
+ adminLimitExceeded (11), \r
+ unavailableCriticalExtension (12), \r
+ confidentialityRequired (13), \r
+ saslBindInProgress (14), \r
+ noSuchAttribute (16), \r
+ undefinedAttributeType (17), \r
+ inappropriateMatching (18), \r
+ constraintViolation (19), \r
+ attributeOrValueExists (20), \r
+ invalidAttributeSyntax (21), \r
+ -- 22-31 unused -- \r
+ noSuchObject (32), \r
+ aliasProblem (33), \r
+ invalidDNSyntax (34), \r
+ -- 35 reserved for undefined isLeaf -- \r
+ aliasDereferencingProblem (36), \r
+ -- 37-47 unused -- \r
+ inappropriateAuthentication (48), \r
+ invalidCredentials (49), \r
+ insufficientAccessRights (50), \r
+ busy (51), \r
+ unavailable (52), \r
+ unwillingToPerform (53), \r
+ loopDetect (54), \r
+ -- 55-63 unused -- \r
+ namingViolation (64), \r
+ objectClassViolation (65), \r
+ notAllowedOnNonLeaf (66), \r
+ notAllowedOnRDN (67), \r
+ entryAlreadyExists (68), \r
+ objectClassModsProhibited (69), \r
+ -- 70 reserved for CLDAP -- \r
+ affectsMultipleDSAs (71), \r
+ -- 72-79 unused -- \r
+ other (80), \r
+ ... }, \r
+ matchedDN LDAPDN, \r
+ diagnosticMessage LDAPString, \r
+ referral [3] Referral OPTIONAL } \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 10 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The resultCode enumeration is extensible as defined in Section 3.6 of \r
+ [LDAPIANA]. The meanings of the listed result codes are given in \r
+ Appendix A. If a server detects multiple errors for an operation, \r
+ only one result code is returned. The server should return the result \r
+ code that best indicates the nature of the error encountered. Servers \r
+ may return substituted result codes to prevent unauthorized \r
+ disclosures. \r
+ \r
+ The diagnosticMessage field of this construct may, at the server's \r
+ option, be used to return a string containing a textual, human-\r
+ readable (terminal control and page formatting characters should be \r
+ avoided) diagnostic message. As this diagnostic message is not \r
+ standardized, implementations MUST NOT rely on the values returned. \r
+ Diagnostic messages typically supplement the resultCode with \r
+ additional information. If the server chooses not to return a textual \r
+ diagnostic, the diagnosticMessage field MUST be empty. \r
+ \r
+ For certain result codes (typically, but not restricted to \r
+ noSuchObject, aliasProblem, invalidDNSyntax and \r
+ aliasDereferencingProblem), the matchedDN field is set (subject to \r
+ access controls) to the name of the last entry (object or alias) used \r
+ in finding the target (or base) object. This will be a truncated form \r
+ of the provided name or, if an alias was dereferenced while \r
+ attempting to locate the entry, of the resulting name. Otherwise the \r
+ matchedDN field is empty. \r
+ \r
+ \r
+4.1.10. Referral \r
+ \r
+ The referral result code indicates that the contacted server cannot \r
+ or will not perform the operation and that one or more other servers \r
+ may be able to. Reasons for this include: \r
+ \r
+ - The target entry of the request is not held locally, but the \r
+ server has knowledge of its possible existence elsewhere. \r
+ \r
+ - The operation is restricted on this server -- perhaps due to a \r
+ read-only copy of an entry to be modified. \r
+ \r
+ The referral field is present in an LDAPResult if the resultCode is \r
+ set to referral, and absent with all other result codes. It contains \r
+ one or more references to one or more servers or services that may be \r
+ accessed via LDAP or other protocols. Referrals can be returned in \r
+ response to any operation request (except Unbind and Abandon which do \r
+ not have responses). At least one URI MUST be present in the \r
+ Referral. \r
+ \r
+ During a Search operation, after the baseObject is located, and \r
+ entries are being evaluated, the referral is not returned. Instead, \r
+ continuation references, described in Section 4.5.3, are returned \r
+ when other servers would need to be contacted to complete the \r
+ operation. \r
+ \r
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 11 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ URI ::= LDAPString -- limited to characters permitted in \r
+ -- URIs \r
+ \r
+ If the client wishes to progress the operation, it contacts one of \r
+ the supported services found in the referral. If multiple URIs are \r
+ present, the client assumes that any supported URI may be used to \r
+ progress the operation. \r
+ \r
+ Clients that follow referrals MUST ensure that they do not loop \r
+ between servers. They MUST NOT repeatedly contact the same server for \r
+ the same request with the same parameters. Some clients use a counter \r
+ that is incremented each time referral handling occurs for an \r
+ operation, and these kinds of clients MUST be able to handle at least \r
+ ten nested referrals while progressing the operation. \r
+ \r
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP] \r
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL]. \r
+ \r
+ Referral values which are LDAP URLs follow these rules: \r
+ \r
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST \r
+ be present, with the new target object name. \r
+ \r
+ - It is RECOMMENDED that the <dn> part be present to avoid \r
+ ambiguity. \r
+ \r
+ - If the <dn> part is present, the client uses this name in its next \r
+ request to progress the operation, and if it is not present the \r
+ client uses the same name as in the original request. \r
+ \r
+ - Some servers (e.g. participating in distributed indexing) may \r
+ provide a different filter in a URL of a referral for a Search \r
+ operation. \r
+ \r
+ - If the <filter> part of the LDAP URL is present, the client uses \r
+ this filter in its next request to progress this Search, and if it \r
+ is not present the client uses the same filter as it used for that \r
+ Search. \r
+ \r
+ - For Search, it is RECOMMENDED that the <scope> part be present to \r
+ avoid ambiguity. \r
+ \r
+ - If the <scope> part is missing, the scope of the original Search \r
+ is used by the client to progress the operation. \r
+ \r
+ - Other aspects of the new request may be the same as or different \r
+ from the request which generated the referral. \r
+ \r
+ Other kinds of URIs may be returned. The syntax and semantics of such \r
+ URIs is left to future specifications. Clients may ignore URIs that \r
+ they do not support. \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 12 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ UTF-8 encoded characters appearing in the string representation of a \r
+ DN, search filter, or other fields of the referral value may not be \r
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method \r
+ in [URI]. \r
+ \r
+ \r
+4.1.11. Controls \r
+ \r
+ Controls provide a mechanism whereby the semantics and arguments of \r
+ existing LDAP operations may be extended. One or more controls may be \r
+ attached to a single LDAP message. A control only affects the \r
+ semantics of the message it is attached to. \r
+ \r
+ Controls sent by clients are termed 'request controls' and those sent \r
+ by servers are termed 'response controls'. \r
+ \r
+ Controls ::= SEQUENCE OF control Control \r
+ \r
+ Control ::= SEQUENCE { \r
+ controlType LDAPOID, \r
+ criticality BOOLEAN DEFAULT FALSE, \r
+ controlValue OCTET STRING OPTIONAL } \r
+ \r
+ The controlType field is the dotted-decimal representation of an \r
+ OBJECT IDENTIFIER which uniquely identifies the control. This \r
+ provides unambiguous naming of controls. Often, response control(s) \r
+ solicited by a request control share controlType values with the \r
+ request control. \r
+ \r
+ The criticality field only has meaning in controls attached to \r
+ request messages (except UnbindRequest). For controls attached to \r
+ response messages and the UnbindRequest, the criticality field SHOULD \r
+ be FALSE, and MUST be ignored by the receiving protocol peer. A value \r
+ of TRUE indicates that it is unacceptable to perform the operation \r
+ without applying the semantics of the control. Specifically, the \r
+ criticality field is applied as follows: \r
+ \r
+ - If the server does not recognize the control type, determines that \r
+ it is not appropriate for the operation, or is otherwise unwilling \r
+ to perform the operation with the control, and the criticality \r
+ field is TRUE, the server MUST NOT perform the operation, and for \r
+ operations that have a response message, MUST return with the \r
+ resultCode set to unavailableCriticalExtension. \r
+ \r
+ - If the server does not recognize the control type, determines that \r
+ it is not appropriate for the operation, or is otherwise unwilling \r
+ to perform the operation with the control, and the criticality \r
+ field is FALSE, the server MUST ignore the control. \r
+ \r
+ - Regardless of criticality, if a control is applied to an \r
+ operation, it is applied consistently and impartially to the \r
+ entire operation. \r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 13 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The controlValue may contain information associated with the \r
+ controlType. Its format is defined by the specification of the \r
+ control. Implementations MUST be prepared to handle arbitrary \r
+ contents of the controlValue octet string, including zero bytes. It \r
+ is absent only if there is no value information which is associated \r
+ with a control of its type. When a controlValue is defined in terms \r
+ of ASN.1, and BER encoded according to Section 5.1, it also follows \r
+ the extensibility rules in Section 4. \r
+ \r
+ Servers list the controlType of request controls they recognize in \r
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of \r
+ [Models]). \r
+ \r
+ Controls SHOULD NOT be combined unless the semantics of the \r
+ combination has been specified. The semantics of control \r
+ combinations, if specified, are generally found in the control \r
+ specification most recently published. When a combination of controls \r
+ is encountered whose semantics are invalid, not specified (or not \r
+ known), the message is considered to be not well-formed, thus the \r
+ operation fails with protocolError. Controls with a criticality of \r
+ FALSE may be ignored in order to arrive at a valid combination. \r
+ Additionally, unless order-dependent semantics are given in a \r
+ specification, the order of a combination of controls in the SEQUENCE \r
+ is ignored. Where the order is to be ignored but cannot be ignored by \r
+ the server, the message is considered not well-formed and the \r
+ operation fails with protocolError. Again, controls with a \r
+ criticality of FALSE may be ignored in order to arrive at a valid \r
+ combination. \r
+ \r
+ This document does not specify any controls. Controls may be \r
+ specified in other documents. Documents detailing control extensions \r
+ are to provide for each control: \r
+ \r
+ - the OBJECT IDENTIFIER assigned to the control, \r
+ \r
+ - direction as to what value the sender should provide for the \r
+ criticality field (note: the semantics of the criticality field \r
+ are defined above should not be altered by the control's \r
+ specification), \r
+ \r
+ - whether the controlValue field is present, and if so, the format \r
+ of its contents, \r
+ \r
+ - the semantics of the control, and \r
+ \r
+ - optionally, semantics regarding the combination of the control \r
+ with other controls. \r
+ \r
+ \r
+4.2. Bind Operation \r
+ \r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 14 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The function of the Bind operation is to allow authentication \r
+ information to be exchanged between the client and server. The Bind \r
+ operation should be thought of as the "authenticate" operation. \r
+ Operational, authentication, and security-related semantics of this \r
+ operation are given in [AuthMeth]. \r
+ \r
+ The Bind request is defined as follows: \r
+ \r
+ BindRequest ::= [APPLICATION 0] SEQUENCE { \r
+ version INTEGER (1 .. 127), \r
+ name LDAPDN, \r
+ authentication AuthenticationChoice } \r
+ \r
+ AuthenticationChoice ::= CHOICE { \r
+ simple [0] OCTET STRING, \r
+ -- 1 and 2 reserved \r
+ sasl [3] SaslCredentials, \r
+ ... } \r
+ \r
+ SaslCredentials ::= SEQUENCE { \r
+ mechanism LDAPString, \r
+ credentials OCTET STRING OPTIONAL } \r
+ \r
+ Fields of the BindRequest are: \r
+ \r
+ - version: A version number indicating the version of the protocol \r
+ to be used at the LDAP message layer. This document describes \r
+ version 3 of the protocol. There is no version negotiation. The \r
+ client sets this field to the version it desires. If the server \r
+ does not support the specified version, it MUST respond with a \r
+ BindResponse where the resultCode is set to protocolError. \r
+ \r
+ - name: If not empty, the name of the Directory object that the \r
+ client wishes to bind as. This field may take on a null value (a \r
+ zero length string) for the purposes of anonymous binds \r
+ ([AuthMeth] Section 5.1) or when using Simple Authentication and \r
+ Security Layer [SASL] authentication ([AuthMeth] Section 5.2). \r
+ Where the server attempts to locate the named object, it SHALL NOT \r
+ perform alias dereferencing. \r
+ \r
+ - authentication: information used in authentication. This type is \r
+ extensible as defined in Section 3.7 of [LDAPIANA]. Servers that \r
+ do not support a choice supplied by a client return a BindResponse \r
+ with the resultCode set to authMethodNotSupported. \r
+ \r
+ Textual passwords (consisting of a character sequence with a known \r
+ character set and encoding) transferred to the server using the \r
+ simple AuthenticationChoice SHALL be transferred as [UTF-8] \r
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text \r
+ passwords as "query" strings by applying the [SASLprep] profile of \r
+ the [Stringprep] algorithm. Passwords consisting of other data \r
+ (such as random octets) MUST NOT be altered. The determination of \r
+ whether a password is textual is a local client matter. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 15 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+4.2.1. Processing of the Bind Request \r
+ \r
+ Before processing a BindRequest, all uncompleted operations MUST \r
+ either complete or be abandoned. The server may either wait for the \r
+ uncompleted operations to complete, or abandon them. The server then \r
+ proceeds to authenticate the client in either a single-step, or \r
+ multi-step Bind process. Each step requires the server to return a \r
+ BindResponse to indicate the status of authentication. \r
+ \r
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs \r
+ until receiving the BindResponse. Similarly, servers SHOULD NOT \r
+ process or respond to requests received while processing a \r
+ BindRequest. \r
+ \r
+ If the client did not bind before sending a request and receives an \r
+ operationsError to that request, it may then send a BindRequest. If \r
+ this also fails or the client chooses not to bind on the existing \r
+ LDAP session, it may terminate the LDAP session, re-establish it and \r
+ begin again by first sending a BindRequest. This will aid in \r
+ interoperating with servers implementing other versions of LDAP. \r
+ \r
+ Clients may send multiple Bind requests to change the authentication \r
+ and/or security associations or to complete a multi-stage Bind \r
+ process. Authentication from earlier binds is subsequently ignored. \r
+ \r
+ For some SASL authentication mechanisms, it may be necessary for the \r
+ client to invoke the BindRequest multiple times ([AuthMeth] Section \r
+ 5.2). Clients MUST NOT invoke operations between two Bind requests \r
+ made as part of a multi-stage Bind. \r
+ \r
+ A client may abort a SASL bind negotiation by sending a BindRequest \r
+ with a different value in the mechanism field of SaslCredentials, or \r
+ an AuthenticationChoice other than sasl. \r
+ \r
+ If the client sends a BindRequest with the sasl mechanism field as an \r
+ empty string, the server MUST return a BindResponse with the \r
+ resultCode set to authMethodNotSupported. This will allow clients to \r
+ abort a negotiation if it wishes to try again with the same SASL \r
+ mechanism. \r
+ \r
+ \r
+4.2.2. Bind Response \r
+ \r
+ The Bind response is defined as follows. \r
+ \r
+ BindResponse ::= [APPLICATION 1] SEQUENCE { \r
+ COMPONENTS OF LDAPResult, \r
+ serverSaslCreds [7] OCTET STRING OPTIONAL } \r
+ \r
+ BindResponse consists simply of an indication from the server of the \r
+ status of the client's request for authentication. \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 16 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ A successful Bind operation is indicated by a BindResponse with a \r
+ resultCode set to success. Otherwise, an appropriate result code is \r
+ set in the BindResponse. For BindResponse, the protocolError result \r
+ code may be used to indicate that the version number supplied by the \r
+ client is unsupported. \r
+ \r
+ If the client receives a BindResponse where the resultCode is set to \r
+ protocolError, it is to assume that the server does not support this \r
+ version of LDAP. While the client may be able proceed with another \r
+ version of this protocol (this may or may not require closing and re-\r
+ establishing the transport connection), how to proceed with another \r
+ version of this protocol is beyond the scope of this document. \r
+ Clients which are unable or unwilling to proceed SHOULD terminate the \r
+ LDAP session. \r
+ \r
+ The serverSaslCreds field is used as part of a SASL-defined bind \r
+ mechanism to allow the client to authenticate the server to which it \r
+ is communicating, or to perform "challenge-response" authentication. \r
+ If the client bound with the simple choice, or the SASL mechanism \r
+ does not require the server to return information to the client, then \r
+ this field SHALL NOT be included in the BindResponse. \r
+ \r
+ \r
+4.3. Unbind Operation \r
+ \r
+ The function of the Unbind operation is to terminate an LDAP session. \r
+ The Unbind operation is not the antithesis of the Bind operation as \r
+ the name implies. The naming of these operations are historical. The \r
+ Unbind operation should be thought of as the "quit" operation. \r
+ \r
+ The Unbind operation is defined as follows: \r
+ \r
+ UnbindRequest ::= [APPLICATION 2] NULL \r
+ \r
+ The client, upon transmission of the UnbindRequest, and the server, \r
+ upon receipt of the UnbindRequest are to gracefully terminate the \r
+ LDAP session as described in Section 5.3. \r
+ \r
+ Uncompleted operations are handled as specified in Section 3.1. \r
+ \r
+ \r
+4.4. Unsolicited Notification \r
+ \r
+ An unsolicited notification is an LDAPMessage sent from the server to \r
+ the client which is not in response to any LDAPMessage received by \r
+ the server. It is used to signal an extraordinary condition in the \r
+ server or in the LDAP session between the client and the server. The \r
+ notification is of an advisory nature, and the server will not expect \r
+ any response to be returned from the client. \r
+ \r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 17 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The unsolicited notification is structured as an LDAPMessage in which \r
+ the messageID is zero and protocolOp is set to the extendedResp \r
+ choice using the ExtendedResponse type (See Section 4.12). The \r
+ responseName field of the ExtendedResponse always contains an LDAPOID \r
+ which is unique for this notification. \r
+ \r
+ One unsolicited notification (Notice of Disconnection) is defined in \r
+ this document. The specification of an unsolicited notification \r
+ consists of: \r
+ \r
+ - the OBJECT IDENTIFIER assigned to the notification (to be \r
+ specified in the responseName, \r
+ \r
+ - the format of the contents of the responseValue (if any), \r
+ \r
+ - the circumstances which will cause the notification to be sent, \r
+ and \r
+ \r
+ - the semantics of the message. \r
+ \r
+ \r
+4.4.1. Notice of Disconnection \r
+ \r
+ This notification may be used by the server to advise the client that \r
+ the server is about to terminate the LDAP session on its own \r
+ initiative. This notification is intended to assist clients in \r
+ distinguishing between an exceptional server condition and a \r
+ transient network failure. Note that this notification is not a \r
+ response to an Unbind requested by the client. Uncompleted operations \r
+ are handled as specified in Section 3.1. \r
+ \r
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field \r
+ is absent, and the resultCode is used to indicate the reason for the \r
+ disconnection. When the strongerAuthRequired resultCode is returned \r
+ with this message, it indicates that the server has detected that an \r
+ established security association between the client and server has \r
+ unexpectedly failed or been compromised. \r
+ \r
+ Upon transmission of the Notice of Disconnection, the server \r
+ gracefully terminates the LDAP session as described in Section 5.3. \r
+ \r
+ \r
+4.5. Search Operation \r
+ \r
+ The Search operation is used to request a server to return, subject \r
+ to access controls and other restrictions, a set of entries matching \r
+ a complex search criterion. This can be used to read attributes from \r
+ a single entry, from entries immediately subordinate to a particular \r
+ entry, or a whole subtree of entries. \r
+ \r
+ \r
+4.5.1. Search Request \r
+ \r
+ The Search request is defined as follows: \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 18 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ SearchRequest ::= [APPLICATION 3] SEQUENCE { \r
+ baseObject LDAPDN, \r
+ scope ENUMERATED { \r
+ baseObject (0), \r
+ singleLevel (1), \r
+ wholeSubtree (2), \r
+ ... }, \r
+ derefAliases ENUMERATED { \r
+ neverDerefAliases (0), \r
+ derefInSearching (1), \r
+ derefFindingBaseObj (2), \r
+ derefAlways (3) }, \r
+ sizeLimit INTEGER (0 .. maxInt), \r
+ timeLimit INTEGER (0 .. maxInt), \r
+ typesOnly BOOLEAN, \r
+ filter Filter, \r
+ attributes AttributeSelection } \r
+ \r
+ AttributeSelection ::= SEQUENCE OF selector LDAPString \r
+ -- The LDAPString is constrained to \r
+ -- <attributeSelector> in Section 4.5.1.7 \r
+ \r
+ Filter ::= CHOICE { \r
+ and [0] SET SIZE (1..MAX) OF filter Filter, \r
+ or [1] SET SIZE (1..MAX) OF filter Filter, \r
+ not [2] Filter, \r
+ equalityMatch [3] AttributeValueAssertion, \r
+ substrings [4] SubstringFilter, \r
+ greaterOrEqual [5] AttributeValueAssertion, \r
+ lessOrEqual [6] AttributeValueAssertion, \r
+ present [7] AttributeDescription, \r
+ approxMatch [8] AttributeValueAssertion, \r
+ extensibleMatch [9] MatchingRuleAssertion, \r
+ ... } \r
+ \r
+ SubstringFilter ::= SEQUENCE { \r
+ type AttributeDescription, \r
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { \r
+ initial [0] AssertionValue, -- can occur at most once \r
+ any [1] AssertionValue, \r
+ final [2] AssertionValue } -- can occur at most once \r
+ } \r
+ \r
+ MatchingRuleAssertion ::= SEQUENCE { \r
+ matchingRule [1] MatchingRuleId OPTIONAL, \r
+ type [2] AttributeDescription OPTIONAL, \r
+ matchValue [3] AssertionValue, \r
+ dnAttributes [4] BOOLEAN DEFAULT FALSE } \r
+ \r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 19 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ Note that an X.500 "list"-like operation can be emulated by the \r
+ client requesting a singleLevel Search operation with a filter \r
+ checking for the presence of the 'objectClass' attribute, and that an \r
+ X.500 "read"-like operation can be emulated by a baseObject Search \r
+ operation with the same filter. A server which provides a gateway to \r
+ X.500 is not required to use the Read or List operations, although it \r
+ may choose to do so, and if it does, it must provide the same \r
+ semantics as the X.500 Search operation. \r
+ \r
+ \r
+4.5.1.1. SearchRequest.baseObject \r
+ \r
+ The name of the base object entry (or possibly the root) relative to \r
+ which the Search is to be performed. \r
+ \r
+ \r
+4.5.1.2. SearchRequest.scope \r
+ \r
+ Specifies the scope of the Search to be performed. The semantics (as \r
+ described in [X.511]) of the defined values of this field are: \r
+ \r
+ baseObject: The scope is constrained to the entry named by \r
+ baseObject. \r
+ \r
+ singleLevel: The scope is constrained to the immediate \r
+ subordinates of the entry named by baseObject. \r
+ \r
+ wholeSubtree: the scope is constrained to the entry named by the \r
+ baseObject, and all its subordinates. \r
+ \r
+ \r
+4.5.1.3. SearchRequest.derefAliases \r
+ \r
+ An indicator as to whether or not alias entries (as defined in \r
+ [Models]) are to be dereferenced during stages of the Search \r
+ operation. \r
+ \r
+ The act of dereferencing an alias includes recursively dereferencing \r
+ aliases which refer to aliases. \r
+ \r
+ Servers MUST detect looping while dereferencing aliases in order to \r
+ prevent denial of service attacks of this nature. \r
+ \r
+ The semantics of the defined values of this field are: \r
+ \r
+ neverDerefAliases: Do not dereference aliases in searching or in \r
+ locating the base object of the Search. \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 20 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ derefInSearching: While searching subordinates of the base object, \r
+ dereference any alias within the search scope. Dereferenced \r
+ objects become the vertices of further search scopes where the \r
+ Search operation is also applied. If the search scope is \r
+ wholeSubtree, the Search continues in the subtree(s) of any \r
+ dereferenced object. If the search scope is singleLevel, the \r
+ search is applied to any dereferenced objects, and is not applied \r
+ to their subordinates. Servers SHOULD eliminate duplicate entries \r
+ that arise due to alias dereferencing while searching. \r
+ \r
+ derefFindingBaseObj: Dereference aliases in locating the base \r
+ object of the Search, but not when searching subordinates of the \r
+ base object. \r
+ \r
+ derefAlways: Dereference aliases both in searching and in locating \r
+ the base object of the Search. \r
+ \r
+ \r
+4.5.1.4. SearchRequest.sizeLimit \r
+ \r
+ A size limit that restricts the maximum number of entries to be \r
+ returned as a result of the Search. A value of zero in this field \r
+ indicates that no client-requested size limit restrictions are in \r
+ effect for the Search. Servers may also enforce a maximum number of \r
+ entries to return. \r
+ \r
+ \r
+4.5.1.5. SearchRequest.timeLimit \r
+ \r
+ A time limit that restricts the maximum time (in seconds) allowed for \r
+ a Search. A value of zero in this field indicates that no client-\r
+ requested time limit restrictions are in effect for the Search. \r
+ Servers may also enforce a maximum time limit for the Search. \r
+ \r
+ \r
+4.5.1.6. SearchRequest.typesOnly \r
+ \r
+ An indicator as to whether Search results are to contain both \r
+ attribute descriptions and values, or just attribute descriptions. \r
+ Setting this field to TRUE causes only attribute descriptions (no \r
+ values) to be returned. Setting this field to FALSE causes both \r
+ attribute descriptions and values to be returned. \r
+ \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 21 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+4.5.1.7. SearchRequest.filter \r
+ \r
+ A filter that defines the conditions that must be fulfilled in order \r
+ for the Search to match a given entry. \r
+ \r
+ The 'and', 'or' and 'not' choices can be used to form combinations of \r
+ filters. At least one filter element MUST be present in an 'and' or \r
+ 'or' choice. The others match against individual attribute values of \r
+ entries in the scope of the Search. (Implementor's note: the 'not' \r
+ filter is an example of a tagged choice in an implicitly-tagged \r
+ module. In BER this is treated as if the tag was explicit.) \r
+ \r
+ A server MUST evaluate filters according to the three-valued logic of \r
+ [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to \r
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates to \r
+ TRUE for a particular entry, then the attributes of that entry are \r
+ returned as part of the Search result (subject to any applicable \r
+ access control restrictions). If the filter evaluates to FALSE or \r
+ Undefined, then the entry is ignored for the Search. \r
+ \r
+ A filter of the "and" choice is TRUE if all the filters in the SET OF \r
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and \r
+ otherwise Undefined. A filter of the "or" choice is FALSE if all of \r
+ the filters in the SET OF evaluate to FALSE, TRUE if at least one \r
+ filter is TRUE, and Undefined otherwise. A filter of the 'not' choice \r
+ is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, \r
+ and Undefined if it is Undefined. \r
+ \r
+ A filter item evaluates to Undefined when the server would not be \r
+ able to determine whether the assertion value matches an entry. \r
+ Examples include: \r
+ \r
+ - An attribute description in an equalityMatch, substrings, \r
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch \r
+ filter is not recognized by the server. \r
+ \r
+ - The attribute type does not define the appropriate matching \r
+ rule. \r
+ \r
+ - A MatchingRuleId in the extensibleMatch is not recognized by \r
+ the server or is not valid for the attribute type. \r
+ \r
+ - The type of filtering requested is not implemented. \r
+ \r
+ - The assertion value is invalid. \r
+ \r
+ For example, if a server did not recognize the attribute type \r
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and \r
+ (shoeSize<=12) would each evaluate to Undefined. \r
+ \r
+ Servers MUST NOT return errors if attribute descriptions or matching \r
+ rule ids are not recognized, assertion values are invalid, or the \r
+ assertion syntax is not supported. More details of filter processing \r
+ are given in Clause 7.8 of [X.511]. \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 22 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ \r
+4.5.1.7.1. SearchRequest.filter.equalityMatch \r
+ \r
+ The matching rule for an equalityMatch filter is defined by the \r
+ EQUALITY matching rule for the attribute type or subtype. The filter \r
+ is TRUE when the EQUALITY rule returns TRUE as applied to the \r
+ attribute or subtype and the asserted value. \r
+ \r
+ \r
+4.5.1.7.2. SearchRequest.filter.substrings \r
+ \r
+ There SHALL be at most one 'initial', and at most one 'final' in the \r
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL \r
+ be the first element of 'substrings'. If 'final' is present, it SHALL \r
+ be the last element of 'substrings'. \r
+ \r
+ The matching rule for an AssertionValue in a substrings filter item \r
+ is defined by the SUBSTR matching rule for the attribute type or \r
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as \r
+ applied to the attribute or subtype and the asserted value. \r
+ \r
+ Note that the AssertionValue in a substrings filter item conforms to \r
+ the assertion syntax of the EQUALITY matching rule for the attribute \r
+ type rather than the assertion syntax of the SUBSTR matching rule for \r
+ the attribute type. Conceptually, the entire SubstringFilter is \r
+ converted into an assertion value of the substrings matching rule \r
+ prior to applying the rule. \r
+ \r
+ \r
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual \r
+ \r
+ The matching rule for a greaterOrEqual filter is defined by the \r
+ ORDERING matching rule for the attribute type or subtype. The filter \r
+ is TRUE when the ORDERING rule returns FALSE as applied to the \r
+ attribute or subtype and the asserted value. \r
+ \r
+ \r
+4.5.1.7.4. SearchRequest.filter.lessOrEqual \r
+ \r
+ The matching rules for a lessOrEqual filter are defined by the \r
+ ORDERING and EQUALITY matching rules for the attribute type or \r
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY rule \r
+ returns TRUE as applied to the attribute or subtype and the asserted \r
+ value. \r
+ \r
+ \r
+4.5.1.7.5. SearchRequest.filter.present \r
+ \r
+ A present filter is TRUE when there is an attribute or subtype of the \r
+ specified attribute description present in an entry, FALSE when no \r
+ attribute or subtype of the specified attribute description is \r
+ present in an entry, and Undefined otherwise. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 23 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+4.5.1.7.6. SearchRequest.filter.approxMatch \r
+ \r
+ An approxMatch filter is TRUE when there is a value of the attribute \r
+ type or subtype for which some locally-defined approximate matching \r
+ algorithm (e.g. spelling variations, phonetic match, etc.) returns \r
+ TRUE. If a value matches for equality, it also satisfies an \r
+ approximate match. If approximate matching is not supported for the \r
+ attribute, this filter item should be treated as an equalityMatch. \r
+ \r
+ \r
+4.5.1.7.7. SearchRequest.filter.extensibleMatch \r
+ \r
+ The fields of the extensibleMatch filter item are evaluated as \r
+ follows: \r
+ \r
+ - If the matchingRule field is absent, the type field MUST be \r
+ present, and an equality match is performed for that type. \r
+ \r
+ - If the type field is absent and the matchingRule is present, the \r
+ matchValue is compared against all attributes in an entry which \r
+ support that matchingRule. \r
+ \r
+ - If the type field is present and the matchingRule is present, the \r
+ matchValue is compared against the specified attribute type and \r
+ its subtypes. \r
+ \r
+ - If the dnAttributes field is set to TRUE, the match is \r
+ additionally applied against all the AttributeValueAssertions in \r
+ an entry's distinguished name, and evaluates to TRUE if there is \r
+ at least one attribute or subtype in the distinguished name for \r
+ which the filter item evaluates to TRUE. The dnAttributes field is \r
+ present to alleviate the need for multiple versions of generic \r
+ matching rules (such as word matching), where one applies to \r
+ entries and another applies to entries and DN attributes as well. \r
+ \r
+ The matchingRule used for evaluation determines the syntax for the \r
+ assertion value. Once the matchingRule and attribute(s) have been \r
+ determined, the filter item evaluates to TRUE if it matches at least \r
+ one attribute type or subtype in the entry, FALSE if it does not \r
+ match any attribute type or subtype in the entry, and Undefined if \r
+ the matchingRule is not recognized, the matchingRule is unsuitable \r
+ for use with the specified type, or the assertionValue is invalid. \r
+ \r
+ \r
+4.5.1.7. SearchRequest.attributes \r
+ \r
+ A selection list of the attributes to be returned from each entry \r
+ which matches the search filter. Attributes which are subtypes of \r
+ listed attributes are implicitly included. LDAPString values of this \r
+ field are constrained to the following Augmented Backus-Naur Form \r
+ ([ABNF]): \r
+ \r
+ attributeSelector = attributedescription / selectorspecial \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 24 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ selectorspecial = noattrs / alluserattrs \r
+ \r
+ noattrs = %x31.2E.31 ; "1.1" \r
+ \r
+ alluserattrs = %x2A ; asterisk ("*") \r
+ \r
+ The <attributedescription> production is defined in Section 2.5 of \r
+ [Models]. \r
+ \r
+ There are three special cases which may appear in the attributes \r
+ selection list: \r
+ \r
+ - an empty list with no attributes, \r
+ \r
+ - a list containing "*" (with zero or more attribute \r
+ descriptions), and \r
+ \r
+ - a list containing only "1.1". \r
+ \r
+ An empty list requests the return of all user attributes. \r
+ \r
+ A list containing "*" requests the return of all user attributes \r
+ in addition to other listed (operational) attributes. \r
+ \r
+ A list containing only the OID "1.1" indicates that no attributes \r
+ are to be returned. If "1.1" is provided with other \r
+ attributeSelector values, the "1.1" attributeSelector is ignored. \r
+ This OID was chosen because it does not (and can not) correspond \r
+ to any attribute in use. \r
+ \r
+ Client implementors should note that even if all user attributes are \r
+ requested, some attributes and/or attribute values of the entry may \r
+ not be included in Search results due to access controls or other \r
+ restrictions. Furthermore, servers will not return operational \r
+ attributes, such as objectClasses or attributeTypes, unless they are \r
+ listed by name. Operational attributes are described in [Models]. \r
+ \r
+ Attributes are returned at most once in an entry. If an attribute \r
+ description is named more than once in the list, the subsequent names \r
+ are ignored. If an attribute description in the list is not \r
+ recognized, it is ignored by the server. \r
+ \r
+ \r
+4.5.2. Search Result \r
+ \r
+ The results of the Search operation are returned as zero or more \r
+ SearchResultEntry and/or SearchResultReference messages, followed by \r
+ a single SearchResultDone message. \r
+ \r
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE { \r
+ objectName LDAPDN, \r
+ attributes PartialAttributeList } \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 25 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ PartialAttributeList ::= SEQUENCE OF \r
+ partialAttribute PartialAttribute \r
+ \r
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE \r
+ SIZE (1..MAX) OF uri URI \r
+ \r
+ SearchResultDone ::= [APPLICATION 5] LDAPResult \r
+ \r
+ Each SearchResultEntry represents an entry found during the Search. \r
+ Each SearchResultReference represents an area not yet explored during \r
+ the Search. The SearchResultEntry and SearchResultReference messages \r
+ may come in any order. Following all the SearchResultReference and \r
+ SearchResultEntry responses, the server returns a SearchResultDone \r
+ response, which contains an indication of success, or detailing any \r
+ errors that have occurred. \r
+ \r
+ Each entry returned in a SearchResultEntry will contain all \r
+ appropriate attributes as specified in the attributes field of the \r
+ Search Request, subject to access control and other administrative \r
+ policy. Note that the PartialAttributeList may hold zero elements. \r
+ This may happen when none of the attributes of an entry were \r
+ requested, or could be returned. Note also that the partialAttribute \r
+ vals set may hold zero elements. This may happen when typesOnly is \r
+ requested, access controls prevent the return of values, or other \r
+ reasons. \r
+ \r
+ Some attributes may be constructed by the server and appear in a \r
+ SearchResultEntry attribute list, although they are not stored \r
+ attributes of an entry. Clients SHOULD NOT assume that all attributes \r
+ can be modified, even if permitted by access control. \r
+ \r
+ If the server's schema defines short names [Models] for an attribute \r
+ type then the server SHOULD use one of those names in attribute \r
+ descriptions for that attribute type (in preference to using the \r
+ <numericoid> [Models] format of the attribute type's object \r
+ identifier). The server SHOULD NOT use the short name if that name is \r
+ known by the server to be ambiguous, or otherwise likely to cause \r
+ interoperability problems. \r
+ \r
+ \r
+4.5.3. Continuation References in the Search Result \r
+ \r
+ If the server was able to locate the entry referred to by the \r
+ baseObject but was unable or unwilling to search one or more non-\r
+ local entries, the server may return one or more \r
+ SearchResultReference messages, each containing a reference to \r
+ another set of servers for continuing the operation. A server MUST \r
+ NOT return any SearchResultReference messages if it has not located \r
+ the baseObject and thus has not searched any entries; in this case it \r
+ would return a SearchResultDone containing either a referral or \r
+ noSuchObject result code (depending on the server's knowledge of the \r
+ entry named in the baseObject). \r
+ \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 26 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ If a server holds a copy or partial copy of the subordinate naming \r
+ context (Section 5 of [Models]), it may use the search filter to \r
+ determine whether or not to return a SearchResultReference response. \r
+ Otherwise SearchResultReference responses are always returned when in \r
+ scope. \r
+ \r
+ The SearchResultReference is of the same data type as the Referral. \r
+ \r
+ If the client wishes to progress the Search, it issues a new Search \r
+ operation for each SearchResultReference that is returned. If \r
+ multiple URIs are present, the client assumes that any supported URI \r
+ may be used to progress the operation. \r
+ \r
+ Clients that follow search continuation references MUST ensure that \r
+ they do not loop between servers. They MUST NOT repeatedly contact \r
+ the same server for the same request with the same parameters. Some \r
+ clients use a counter that is incremented each time search result \r
+ reference handling occurs for an operation, and these kinds of \r
+ clients MUST be able to handle at least ten nested referrals while \r
+ progressing the operation. \r
+ \r
+ Note that the Abandon operation described in Section 4.11 applies \r
+ only to a particular operation sent at the LDAP message layer between \r
+ a client and server. The client must abandon subsequent Search \r
+ operations it wishes to individually. \r
+ \r
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP] \r
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL]. \r
+ \r
+ SearchResultReference values which are LDAP URLs follow these rules: \r
+ \r
+ - The <dn> part of the LDAP URL MUST be present, with the new target \r
+ object name. The client uses this name when following the \r
+ reference. \r
+ \r
+ - Some servers (e.g. participating in distributed indexing) may \r
+ provide a different filter in the LDAP URL. \r
+ \r
+ - If the <filter> part of the LDAP URL is present, the client uses \r
+ this filter in its next request to progress this Search, and if it \r
+ is not present the client uses the same filter as it used for that \r
+ Search. \r
+ \r
+ - If the originating search scope was singleLevel, the <scope> part \r
+ of the LDAP URL will be "base". \r
+ \r
+ - It is RECOMMENDED that the <scope> part be present to avoid \r
+ ambiguity. In the absence of a <scope> part, the scope of the \r
+ original Search request is assumed. \r
+ \r
+ - Other aspects of the new Search request may be the same as or \r
+ different from the Search request which generated the \r
+ SearchResultReference. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 27 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ - The name of an unexplored subtree in a SearchResultReference need \r
+ not be subordinate to the base object. \r
+ \r
+ Other kinds of URIs may be returned. The syntax and semantics of such \r
+ URIs is left to future specifications. Clients may ignore URIs that \r
+ they do not support. \r
+ \r
+ UTF-8 encoded characters appearing in the string representation of a \r
+ DN, search filter, or other fields of the referral value may not be \r
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method \r
+ in [URI]. \r
+ \r
+ \r
+ \r
+4.5.3.1. Examples \r
+ \r
+ For example, suppose the contacted server (hosta) holds the entry \r
+ <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It \r
+ knows that both LDAP servers (hostb) and (hostc) hold \r
+ <OU=People,DC=Example,DC=NET> (one is the master and the other server \r
+ a shadow), and that LDAP-capable server (hostd) holds the subtree \r
+ <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of \r
+ <DC=Example,DC=NET> is requested to the contacted server, it may \r
+ return the following: \r
+ \r
+ SearchResultEntry for DC=Example,DC=NET \r
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET \r
+ SearchResultReference { \r
+ ldap://hostb/OU=People,DC=Example,DC=NET??sub \r
+ ldap://hostc/OU=People,DC=Example,DC=NET??sub } \r
+ SearchResultReference { \r
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub } \r
+ SearchResultDone (success) \r
+ \r
+ Client implementors should note that when following a \r
+ SearchResultReference, additional SearchResultReference may be \r
+ generated. Continuing the example, if the client contacted the server \r
+ (hostb) and issued the Search request for the subtree \r
+ <OU=People,DC=Example,DC=NET>, the server might respond as follows: \r
+ \r
+ SearchResultEntry for OU=People,DC=Example,DC=NET \r
+ SearchResultReference { \r
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub } \r
+ SearchResultReference { \r
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub } \r
+ SearchResultDone (success) \r
+ \r
+ Similarly, if a singleLevel Search of <DC=Example,DC=NET> is \r
+ requested to the contacted server, it may return the following: \r
+ \r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 28 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET \r
+ SearchResultReference { \r
+ ldap://hostb/OU=People,DC=Example,DC=NET??base \r
+ ldap://hostc/OU=People,DC=Example,DC=NET??base } \r
+ SearchResultReference { \r
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??base } \r
+ SearchResultDone (success) \r
+ \r
+ If the contacted server does not hold the base object for the Search, \r
+ but has knowledge of its possible location, then it may return a \r
+ referral to the client. In this case, if the client requests a \r
+ subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a \r
+ SearchResultDone containing a referral. \r
+ \r
+ SearchResultDone (referral) { \r
+ ldap://hostg/DC=Example,DC=ORG??sub } \r
+ \r
+ \r
+4.6. Modify Operation \r
+ \r
+ The Modify operation allows a client to request that a modification \r
+ of an entry be performed on its behalf by a server. The Modify \r
+ Request is defined as follows: \r
+ \r
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE { \r
+ object LDAPDN, \r
+ changes SEQUENCE OF change SEQUENCE { \r
+ operation ENUMERATED { \r
+ add (0), \r
+ delete (1), \r
+ replace (2), \r
+ ... }, \r
+ modification PartialAttribute } } \r
+ \r
+ Fields of the Modify Request are: \r
+ \r
+ - object: The value of this field contains the name of the entry to \r
+ be modified. The server SHALL NOT perform any alias dereferencing \r
+ in determining the object to be modified. \r
+ \r
+ - changes: A list of modifications to be performed on the entry. The \r
+ entire list of modifications MUST be performed in the order they \r
+ are listed as a single atomic operation. While individual \r
+ modifications may violate certain aspects of the directory schema \r
+ (such as the object class definition and DIT content rule), the \r
+ resulting entry after the entire list of modifications is \r
+ performed MUST conform to the requirements of the directory model \r
+ and controlling schema [Models]. \r
+ \r
+ - operation: Used to specify the type of modification being \r
+ performed. Each operation type acts on the following \r
+ modification. The values of this field have the following \r
+ semantics respectively: \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 29 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ add: add values listed to the modification attribute, \r
+ creating the attribute if necessary; \r
+ \r
+ delete: delete values listed from the modification attribute. \r
+ If no values are listed, or if all current values of the \r
+ attribute are listed, the entire attribute is removed; \r
+ \r
+ replace: replace all existing values of the modification \r
+ attribute with the new values listed, creating the attribute \r
+ if it did not already exist. A replace with no value will \r
+ delete the entire attribute if it exists, and is ignored if \r
+ the attribute does not exist. \r
+ \r
+ - modification: A PartialAttribute (which may have an empty SET \r
+ of vals) used to hold the attribute type or attribute type and \r
+ values being modified. \r
+ \r
+ Upon receipt of a Modify Request, the server attempts to perform the \r
+ necessary modifications to the DIT and returns the result in a Modify \r
+ Response, defined as follows: \r
+ \r
+ ModifyResponse ::= [APPLICATION 7] LDAPResult \r
+ \r
+ The server will return to the client a single Modify Response \r
+ indicating either the successful completion of the DIT modification, \r
+ or the reason that the modification failed. Due to the requirement \r
+ for atomicity in applying the list of modifications in the Modify \r
+ Request, the client may expect that no modifications of the DIT have \r
+ been performed if the Modify Response received indicates any sort of \r
+ error, and that all requested modifications have been performed if \r
+ the Modify Response indicates successful completion of the Modify \r
+ operation. Whether the modification was applied or not cannot be \r
+ determined by the client if the Modify Response was not received \r
+ (e.g. the LDAP session was terminated or the Modify operation was \r
+ abandoned). \r
+ \r
+ Servers MUST ensure that entries conform to user and system schema \r
+ rules or other data model constraints. The Modify operation cannot be \r
+ used to remove from an entry any of its distinguished values, i.e. \r
+ those values which form the entry's relative distinguished name. An \r
+ attempt to do so will result in the server returning the \r
+ notAllowedOnRDN result code. The Modify DN operation described in \r
+ Section 4.9 is used to rename an entry. \r
+ \r
+ For attribute types which specify no equality matching, the rules in \r
+ Section 2.5.1 of [Models] are followed. \r
+ \r
+ Note that due to the simplifications made in LDAP, there is not a \r
+ direct mapping of the changes in an LDAP ModifyRequest onto the \r
+ changes of a DAP ModifyEntry operation, and different implementations \r
+ of LDAP-DAP gateways may use different means of representing the \r
+ change. If successful, the final effect of the operations on the \r
+ entry MUST be identical. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 30 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+4.7. Add Operation \r
+ \r
+ The Add operation allows a client to request the addition of an entry \r
+ into the Directory. The Add Request is defined as follows: \r
+ \r
+ AddRequest ::= [APPLICATION 8] SEQUENCE { \r
+ entry LDAPDN, \r
+ attributes AttributeList } \r
+ \r
+ AttributeList ::= SEQUENCE OF attribute Attribute \r
+ \r
+ Fields of the Add Request are: \r
+ \r
+ - entry: the name of the entry to be added. The server SHALL NOT \r
+ dereference any aliases in locating the entry to be added. \r
+ \r
+ - attributes: the list of attributes that, along with those from the \r
+ RDN, make up the content of the entry being added. Clients MAY or \r
+ MAY NOT include the RDN attribute(s) in this list. Clients MUST \r
+ NOT supply NO-USER-MODIFICATION attributes such as the \r
+ createTimestamp or creatorsName attributes, since the server \r
+ maintains these automatically. \r
+ \r
+ Servers MUST ensure that entries conform to user and system schema \r
+ rules or other data model constraints. For attribute types which \r
+ specify no equality matching, the rules in Section 2.5.1 of [Models] \r
+ are followed (this applies to the naming attribute in addition to any \r
+ multi-valued attributes being added). \r
+ \r
+ The entry named in the entry field of the AddRequest MUST NOT exist \r
+ for the AddRequest to succeed. The immediate superior (parent) of an \r
+ object or alias entry to be added MUST exist. For example, if the \r
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the \r
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did \r
+ exist, then the server would return the noSuchObject result code with \r
+ the matchedDN field containing <DC=NET>. \r
+ \r
+ Upon receipt of an Add Request, a server will attempt to add the \r
+ requested entry. The result of the Add attempt will be returned to \r
+ the client in the Add Response, defined as follows: \r
+ \r
+ AddResponse ::= [APPLICATION 9] LDAPResult \r
+ \r
+ A response of success indicates that the new entry has been added to \r
+ the Directory. \r
+ \r
+ \r
+4.8. Delete Operation \r
+ \r
+ The Delete operation allows a client to request the removal of an \r
+ entry from the Directory. The Delete Request is defined as follows: \r
+ \r
+ DelRequest ::= [APPLICATION 10] LDAPDN \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 31 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ The Delete Request consists of the name of the entry to be deleted. \r
+ The server SHALL NOT dereference aliases while resolving the name of \r
+ the target entry to be removed. \r
+ \r
+ Only leaf entries (those with no subordinate entries) can be deleted \r
+ with this operation. \r
+ \r
+ Upon receipt of a Delete Request, a server will attempt to perform \r
+ the entry removal requested and return the result in the Delete \r
+ Response defined as follows: \r
+ \r
+ DelResponse ::= [APPLICATION 11] LDAPResult \r
+ \r
+ \r
+4.9. Modify DN Operation \r
+ \r
+ The Modify DN operation allows a client to change the Relative \r
+ Distinguished Name (RDN) of an entry in the Directory, and/or to move \r
+ a subtree of entries to a new location in the Directory. The Modify \r
+ DN Request is defined as follows: \r
+ \r
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { \r
+ entry LDAPDN, \r
+ newrdn RelativeLDAPDN, \r
+ deleteoldrdn BOOLEAN, \r
+ newSuperior [0] LDAPDN OPTIONAL } \r
+ \r
+ Fields of the Modify DN Request are: \r
+ \r
+ - entry: the name of the entry to be changed. This entry may or may \r
+ not have subordinate entries. \r
+ \r
+ - newrdn: the new RDN of the entry. The value of the old RDN is \r
+ supplied when moving the entry to a new superior without changing \r
+ its RDN. Attribute values of the new RDN not matching any \r
+ attribute value of the entry are added to the entry and an \r
+ appropriate error is returned if this fails. \r
+ \r
+ - deleteoldrdn: a boolean field that controls whether the old RDN \r
+ attribute values are to be retained as attributes of the entry, or \r
+ deleted from the entry. \r
+ \r
+ - newSuperior: if present, this is the name of an existing object \r
+ entry which becomes the immediate superior (parent) of the \r
+ existing entry. \r
+ \r
+ The server SHALL NOT dereference any aliases in locating the objects \r
+ named in entry or newSuperior. \r
+ \r
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform \r
+ the name change and return the result in the Modify DN Response, \r
+ defined as follows: \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 32 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult \r
+ \r
+ For example, if the entry named in the entry field was <cn=John \r
+ Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the \r
+ newSuperior field was absent, then this operation would attempt to \r
+ rename the entry to be <cn=John Cougar Smith,c=US>. If there was \r
+ already an entry with that name, the operation would fail with the \r
+ entryAlreadyExists result code. \r
+ \r
+ Servers MUST ensure that entries conform to user and system schema \r
+ rules or other data model constraints. For attribute types which \r
+ specify no equality matching, the rules in Section 2.5.1 of [Models] \r
+ are followed (this pertains to newrdn and deleteoldrdn). \r
+ \r
+ The object named in newSuperior MUST exist. For example, if the \r
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the \r
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did \r
+ exist, then the server would return the noSuchObject result code with \r
+ the matchedDN field containing <DC=NET>. \r
+ \r
+ If the deleteoldrdn field is TRUE, the attribute values forming the \r
+ old RDN but not the new RDN are deleted from the entry. If the \r
+ deleteoldrdn field is FALSE, the attribute values forming the old RDN \r
+ will be retained as non-distinguished attribute values of the entry. \r
+ \r
+ Note that X.500 restricts the ModifyDN operation to only affect \r
+ entries that are contained within a single server. If the LDAP server \r
+ is mapped onto DAP, then this restriction will apply, and the \r
+ affectsMultipleDSAs result code will be returned if this error \r
+ occurred. In general, clients MUST NOT expect to be able to perform \r
+ arbitrary movements of entries and subtrees between servers or \r
+ between naming contexts. \r
+ \r
+ \r
+4.10. Compare Operation \r
+ \r
+ The Compare operation allows a client to compare an assertion value \r
+ with the values of a particular attribute in a particular entry in \r
+ the Directory. The Compare Request is defined as follows: \r
+ \r
+ CompareRequest ::= [APPLICATION 14] SEQUENCE { \r
+ entry LDAPDN, \r
+ ava AttributeValueAssertion } \r
+ \r
+ Fields of the Compare Request are: \r
+ \r
+ - entry: the name of the entry to be compared. The server SHALL NOT \r
+ dereference any aliases in locating the entry to be compared. \r
+ \r
+ - ava: holds the attribute value assertion to be compared. \r
+ \r
+ Upon receipt of a Compare Request, a server will attempt to perform \r
+ the requested comparison and return the result in the Compare \r
+ Response, defined as follows: \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 33 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ CompareResponse ::= [APPLICATION 15] LDAPResult \r
+ \r
+ The resultCode is set to compareTrue, compareFalse, or an appropriate \r
+ error. compareTrue indicates that the assertion value in the ava \r
+ field matches a value of the attribute or subtype according to the \r
+ attribute's EQUALITY matching rule. compareFalse indicates that the \r
+ assertion value in the ava field and the values of the attribute or \r
+ subtype did not match. Other result codes indicate either that the \r
+ result of the comparison was Undefined (Section 4.5.1), or that some \r
+ error occurred. \r
+ \r
+ Note that some directory systems may establish access controls which \r
+ permit the values of certain attributes (such as userPassword) to be \r
+ compared but not interrogated by other means. \r
+ \r
+ \r
+4.11. Abandon Operation \r
+ \r
+ The function of the Abandon operation is to allow a client to request \r
+ that the server abandon an uncompleted operation. The Abandon Request \r
+ is defined as follows: \r
+ \r
+ AbandonRequest ::= [APPLICATION 16] MessageID \r
+ \r
+ The MessageID is that of an operation which was requested earlier at \r
+ this LDAP message layer. The Abandon request itself has its own \r
+ MessageID. This is distinct from the MessageID of the earlier \r
+ operation being abandoned. \r
+ \r
+ There is no response defined in the Abandon operation. Upon receipt \r
+ of an AbandonRequest, the server MAY abandon the operation identified \r
+ by the MessageID. Since the client cannot tell the difference between \r
+ a successfully abandoned operation and an uncompleted operation, the \r
+ application of the Abandon operation is limited to uses where the \r
+ client does not require an indication of its outcome. \r
+ \r
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned. \r
+ \r
+ In the event that a server receives an Abandon Request on a Search \r
+ operation in the midst of transmitting responses to the Search, that \r
+ server MUST cease transmitting entry responses to the abandoned \r
+ request immediately, and MUST NOT send the SearchResultDone. Of \r
+ course, the server MUST ensure that only properly encoded LDAPMessage \r
+ PDUs are transmitted. \r
+ \r
+ The ability to abandon other (particularly update) operations is at \r
+ the discretion of the server. \r
+ \r
+ Clients should not send Abandon requests for the same operation \r
+ multiple times, and MUST also be prepared to receive results from \r
+ operations it has abandoned (since these may have been in transit \r
+ when the Abandon was requested, or are not able to be abandoned). \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 34 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ Servers MUST discard Abandon requests for message IDs they do not \r
+ recognize, for operations which cannot be abandoned, and for \r
+ operations which have already been abandoned. \r
+ \r
+ \r
+4.12. Extended Operation \r
+ \r
+ The Extended operation allows additional operations to be defined for \r
+ services not already available in the protocol. For example, to Add \r
+ operations to install transport layer security (see Section 4.14). \r
+ \r
+ The Extended operation allows clients to make requests and receive \r
+ responses with predefined syntaxes and semantics. These may be \r
+ defined in RFCs or be private to particular implementations. \r
+ \r
+ Each Extended operation consists of an Extended request and an \r
+ Extended response. \r
+ \r
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE { \r
+ requestName [0] LDAPOID, \r
+ requestValue [1] OCTET STRING OPTIONAL } \r
+ \r
+ The requestName is a dotted-decimal representation of the unique \r
+ OBJECT IDENTIFIER corresponding to the request. The requestValue is \r
+ information in a form defined by that request, encapsulated inside an \r
+ OCTET STRING. \r
+ \r
+ The server will respond to this with an LDAPMessage containing an \r
+ ExtendedResponse. \r
+ \r
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE { \r
+ COMPONENTS OF LDAPResult, \r
+ responseName [10] LDAPOID OPTIONAL, \r
+ responseValue [11] OCTET STRING OPTIONAL } \r
+ \r
+ The responseName field, when present, contains an LDAPOID which is \r
+ unique for this extended operation or response. This field is \r
+ optional (even when the extension specification specifies an LDAPOID \r
+ to be returned in the field). The field will be absent whenever the \r
+ server is unable or unwilling to determine the appropriate LDAPOID to \r
+ return, for instance when the requestName cannot be parsed or its \r
+ value is not recognized. \r
+ \r
+ Where the requestName is not recognized, the server returns \r
+ protocolError (The server may return protocolError in other cases). \r
+ \r
+ The requestValue and responseValue fields contain information \r
+ associated with the operation. The format of these fields is defined \r
+ by the specification of the Extended operation. Implementations MUST \r
+ be prepared to handle arbitrary contents of these fields, including \r
+ zero bytes. Values that are defined in terms of ASN.1 and BER encoded \r
+ according to Section 5.1, also follow the extensibility rules in \r
+ Section 4. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 35 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ Servers list the requestName of Extended Requests they recognize in \r
+ the 'supportedExtension' attribute in the root DSE (Section 5.1 of \r
+ [Models]). \r
+ \r
+ Extended operations may be specified in other documents. The \r
+ specification of an Extended operation consists of: \r
+ \r
+ - the OBJECT IDENTIFIER assigned to the requestName, \r
+ \r
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note \r
+ that the same OBJECT IDENTIFIER may be used for both the \r
+ requestName and responseName), \r
+ \r
+ - the format of the contents of the requestValue and responseValue \r
+ (if any), and \r
+ \r
+ - the semantics of the operation. \r
+ \r
+ \r
+4.13. IntermediateResponse Message \r
+ \r
+ While the Search operation provides a mechanism to return multiple \r
+ response messages for a single Search request, other operations, by \r
+ nature, do not provide for multiple response messages. \r
+ \r
+ The IntermediateResponse message provides a general mechanism for \r
+ defining single-request/multiple-response operations in LDAP. This \r
+ message is intended to be used in conjunction with the Extended \r
+ operation to define new single-request/multiple-response operations \r
+ or in conjunction with a control when extending existing LDAP \r
+ operations in a way that requires them to return Intermediate \r
+ response information. \r
+ \r
+ It is intended that the definitions and descriptions of Extended \r
+ operations and controls that make use of the IntermediateResponse \r
+ message will define the circumstances when an IntermediateResponse \r
+ message can be sent by a server and the associated meaning of an \r
+ IntermediateResponse message sent in a particular circumstance. \r
+ \r
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE { \r
+ responseName [0] LDAPOID OPTIONAL, \r
+ responseValue [1] OCTET STRING OPTIONAL } \r
+ \r
+ IntermediateResponse messages SHALL NOT be returned to the client \r
+ unless the client issues a request that specifically solicits their \r
+ return. This document defines two forms of solicitation: Extended \r
+ operation and request control. IntermediateResponse messages are \r
+ specified in documents describing the manner in which they are \r
+ solicited (i.e. in the Extended operation or request control \r
+ specification that uses them). These specifications include: \r
+ \r
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName, \r
+ \r
+ - the format of the contents of the responseValue (if any), and \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 36 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ - the semantics associated with the IntermediateResponse message. \r
+ \r
+ Extensions that allow the return of multiple types of \r
+ IntermediateResponse messages SHALL identify those types using unique \r
+ responseName values (note that one of these may specify no value). \r
+ \r
+ Sections 4.13.1 and 4.13.2 describe additional requirements on the \r
+ inclusion of responseName and responseValue in IntermediateResponse \r
+ messages. \r
+ \r
+ \r
+4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse \r
+ \r
+ A single-request/multiple-response operation may be defined using a \r
+ single ExtendedRequest message to solicit zero or more \r
+ IntermediateResponse messages of one or more kinds followed by an \r
+ ExtendedResponse message. \r
+ \r
+ \r
+4.13.2. Usage with LDAP Request Controls \r
+ \r
+ A control's semantics may include the return of zero or more \r
+ IntermediateResponse messages prior to returning the final result \r
+ code for the operation. One or more kinds of IntermediateResponse \r
+ messages may be sent in response to a request control. \r
+ \r
+ All IntermediateResponse messages associated with request controls \r
+ SHALL include a responseName. This requirement ensures that the \r
+ client can correctly identify the source of IntermediateResponse \r
+ messages when: \r
+ \r
+ - two or more controls using IntermediateResponse messages are \r
+ included in a request for any LDAP operation or \r
+ \r
+ - one or more controls using IntermediateResponse messages are \r
+ included in a request with an LDAP Extended operation that uses \r
+ IntermediateResponse messages. \r
+ \r
+ \r
+4.14. StartTLS Operation \r
+ \r
+ The Start Transport Layer Security (StartTLS) operation's purpose is \r
+ to initiate installation of a TLS layer. The StartTLS operation is \r
+ defined using the Extended operation mechanism described in Section \r
+ 4.12. \r
+ \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 37 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+4.14.1. StartTLS Request \r
+ \r
+ A client requests TLS establishment by transmitting a StartTLS \r
+ request message to the server. The StartTLS request is defined in \r
+ terms of an ExtendedRequest. The requestName is \r
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always \r
+ absent. \r
+ \r
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer \r
+ following this request until it receives a StartTLS Extended response \r
+ and, in the case of a successful response, completes TLS \r
+ negotiations. \r
+ \r
+ Detected sequencing problems (particularly those detailed in Section \r
+ 3.1.1 of [AuthMeth]) result in the resultCode being set to \r
+ operationsError. \r
+ \r
+ If the server does not support TLS (whether by design or by current \r
+ configuration), it returns with the resultCode set to protocolError \r
+ as described in Section 4.12. \r
+ \r
+ \r
+4.14.2. StartTLS Response \r
+ \r
+ When a StartTLS request is received, servers supporting the operation \r
+ MUST return a StartTLS response message to the requestor. The \r
+ responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12). \r
+ The responseValue is always absent. \r
+ \r
+ If the server is willing and able to negotiate TLS, it returns the \r
+ StartTLS response with the resultCode set to success. Upon client \r
+ receipt of a successful StartTLS response, protocol peers may \r
+ commence with TLS negotiation as discussed in Section 3 of \r
+ [AuthMeth]. \r
+ \r
+ If the server is otherwise unwilling or unable to perform this \r
+ operation, the server is to return an appropriate result code \r
+ indicating the nature of the problem. For example, if the TLS \r
+ subsystem is not presently available, the server may indicate so by \r
+ returning with the resultCode set to unavailable. In cases where a \r
+ non-success result code is returned, the LDAP session is left without \r
+ a TLS layer. \r
+ \r
+ \r
+4.14.3. Removal of the TLS Layer \r
+ \r
+ Either the client or server MAY remove the TLS layer and leave the \r
+ LDAP message layer intact by sending and receiving a TLS closure \r
+ alert. \r
+ \r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 38 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ The initiating protocol peer sends the TLS closure alert and MUST \r
+ wait until it receives a TLS closure alert from the other peer before \r
+ sending further LDAP PDUs. \r
+ \r
+ When a protocol peer receives the initial TLS closure alert, it may \r
+ choose to allow the LDAP message layer to remain intact. In this \r
+ case, it MUST immediately transmit a TLS closure alert. Following \r
+ this, it MAY send and receive LDAP PDUs. \r
+ \r
+ Protocol peers MAY terminate the LDAP session after sending or \r
+ receiving a TLS closure alert. \r
+ \r
+ \r
+5. Protocol Encoding, Connection, and Transfer \r
+ \r
+ This protocol is designed to run over connection-oriented, reliable \r
+ transports, where the data stream is divided into octets (8-bit \r
+ units), with each octet and each bit being significant. \r
+ \r
+ One underlying service, LDAP over TCP, is defined in Section \r
+ 5.2. This service is generally applicable to applications providing \r
+ or consuming X.500-based directory services on the Internet. This \r
+ specification was generally written with the TCP mapping in mind. \r
+ Specifications detailing other mappings may encounter various \r
+ obstacles. \r
+ \r
+ Implementations of LDAP over TCP MUST implement the mapping as \r
+ described in Section 5.2. \r
+ \r
+ This table illustrates the relationship between the different layers \r
+ involved in an exchange between two protocol peers: \r
+ \r
+ +----------------------+ \r
+ | LDAP message layer | \r
+ +----------------------+ > LDAP PDUs \r
+ +----------------------+ < data \r
+ | SASL layer | \r
+ +----------------------+ > SASL-protected data \r
+ +----------------------+ < data \r
+ | TLS layer | \r
+ Application +----------------------+ > TLS-protected data \r
+ ------------+----------------------+ < data \r
+ Transport | transport connection | \r
+ +----------------------+ \r
+ \r
+ \r
+5.1. Protocol Encoding \r
+ \r
+ The protocol elements of LDAP SHALL be encoded for exchange using the \r
+ Basic Encoding Rules [BER] of [ASN.1] with the following \r
+ restrictions: \r
+ \r
+ - Only the definite form of length encoding is used. \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 39 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ - OCTET STRING values are encoded in the primitive form only. \r
+ \r
+ - If the value of a BOOLEAN type is true, the encoding of the value \r
+ octet is set to hex "FF". \r
+ \r
+ - If a value of a type is its default value, it is absent. Only some \r
+ BOOLEAN and INTEGER types have default values in this protocol \r
+ definition. \r
+ \r
+ These restrictions are meant to ease the overhead of encoding and \r
+ decoding certain elements in BER. \r
+ \r
+ These restrictions do not apply to ASN.1 types encapsulated inside of \r
+ OCTET STRING values, such as attribute values, unless otherwise \r
+ stated. \r
+ \r
+ \r
+5.2. Transmission Control Protocol (TCP) \r
+ \r
+ The encoded LDAPMessage PDUs are mapped directly onto the [TCP] \r
+ bytestream using the BER-based encoding described in Section 5.1. It \r
+ is recommended that server implementations running over the TCP \r
+ provide a protocol listener on the Internet Assigned Numbers \r
+ Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may \r
+ instead provide a listener on a different port number. Clients MUST \r
+ support contacting servers on any valid TCP port. \r
+ \r
+ \r
+5.3. Termination of the LDAP session \r
+ \r
+ Termination of the LDAP session is typically initiated by the client \r
+ sending an UnbindRequest (Section 4.3), or by the server sending a \r
+ Notice of Disconnection (Section 4.4.1). In these cases each protocol \r
+ peer gracefully terminates the LDAP session by ceasing exchanges at \r
+ the LDAP message layer, tearing down any SASL layer, tearing down any \r
+ TLS layer, and closing the transport connection. \r
+ \r
+ A protocol peer may determine that the continuation of any \r
+ communication would be pernicious, and in this case may abruptly \r
+ terminate the session by ceasing communication and closing the \r
+ transport connection. \r
+ \r
+ In either case, when the LDAP session is terminated, uncompleted \r
+ operations are handled as specified in Section 3.1. \r
+ \r
+ \r
+6. Security Considerations \r
+ \r
+ This version of the protocol provides facilities for simple \r
+ authentication using a cleartext password, as well as any [SASL] \r
+ mechanism. Installing SASL and/or TLS layers can provide integrity \r
+ and other data security services. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 40 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ It is also permitted that the server can return its credentials to \r
+ the client, if it chooses to do so. \r
+ \r
+ Use of cleartext password is strongly discouraged where the \r
+ underlying transport service cannot guarantee confidentiality and may \r
+ result in disclosure of the password to unauthorized parties. \r
+ \r
+ Servers are encouraged to prevent directory modifications by clients \r
+ that have authenticated anonymously [AuthMeth]. \r
+ \r
+ Security considerations for authentication methods, SASL mechanisms, \r
+ and TLS are described in [AuthMeth]. \r
+ \r
+ It should be noted that SASL authentication exchanges do not provide \r
+ data confidentiality nor integrity protection for the version or name \r
+ fields of the BindRequest nor the resultCode, diagnosticMessage, or \r
+ referral fields of the BindResponse nor of any information contained \r
+ in controls attached to Bind requests or responses. Thus information \r
+ contained in these fields SHOULD NOT be relied on unless otherwise \r
+ protected (such as by establishing protections at the transport \r
+ layer). \r
+ \r
+ Implementors should note that various security factors, including \r
+ authentication and authorization information and data security \r
+ services may change during the course of the LDAP session, or even \r
+ during the performance of a particular operation. For instance, \r
+ credentials could expire, authorization identities or access controls \r
+ could change, or the underlying security layer(s) could be replaced \r
+ or terminated. Implementations should be robust in the handling of \r
+ changing security factors. \r
+ In some cases, it may be appropriate to continue the operation even \r
+ in light of security factor changes. For instance, it may be \r
+ appropriate to continue an Abandon operation regardless of the \r
+ change, or to continue an operation when the change upgraded (or \r
+ maintained) the security factor. In other cases, it may be \r
+ appropriate to fail, or alter the processing of the operation. For \r
+ instance, if confidential protections were removed, it would be \r
+ appropriate to either fail a request to return sensitive data, or \r
+ minimally, to exclude the return of sensitive data. \r
+ \r
+ Implementations which cache attributes and entries obtained via LDAP \r
+ MUST ensure that access controls are maintained if that information \r
+ is to be provided to multiple clients, since servers may have access \r
+ control policies which prevent the return of entries or attributes in \r
+ Search results except to particular authenticated clients. For \r
+ example, caches could serve result information only to the client \r
+ whose request caused it to be in the cache. \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 41 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ Servers may return referrals or Search result references which \r
+ redirect clients to peer servers. It is possible for a rogue \r
+ application to inject such referrals into the data stream in an \r
+ attempt to redirect a client to a rogue server. Clients are advised \r
+ to be aware of this, and possibly reject referrals when \r
+ confidentiality measures are not in place. Clients are advised to \r
+ reject referrals from the StartTLS operation. \r
+ \r
+ The matchedDN and diagnosticMessage fields, as well as some \r
+ resultCode values (e.g., attributeOrValueExists and \r
+ entryAlreadyExists), could disclose the presence or absence of \r
+ specific data in the directory which is subject to access and other \r
+ administrative controls. Server implementations should restrict \r
+ access to protected information equally under both normal and error \r
+ conditions. \r
+ \r
+ Protocol peers MUST be prepared to handle invalid and arbitrary \r
+ length protocol encodings. Invalid protocol encodings include: BER \r
+ encoding exceptions, format string and UTF-8 encoding exceptions, \r
+ overflow exceptions, integer value exceptions, and binary mode on/off \r
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides \r
+ excellent examples of these exceptions and test cases used to \r
+ discover flaws. \r
+ \r
+ In the event that a protocol peer senses an attack which in its \r
+ nature could cause damage due to further communication at any layer \r
+ in the LDAP session, the protocol peer should abruptly terminate the \r
+ LDAP session as described in Section 5.3. \r
+ \r
+ \r
+7. Acknowledgements \r
+ \r
+ This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve \r
+ Kille. RFC 2251 was a product of the IETF ASID Working Group. \r
+ \r
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and \r
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group. \r
+ \r
+ It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga. \r
+ RFC 3771 was an individual submission to the IETF. \r
+ \r
+ This document is a product of the IETF LDAPBIS Working Group. \r
+ Significant contributors of technical review and content include Kurt \r
+ Zeilenga, Steven Legg, and Hallvard Furuseth. \r
+ \r
+ \r
+8. Normative References \r
+ \r
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax \r
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-\r
+ xx.txt, (a work in progress). \r
+ \r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 42 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 \r
+ "Information Technology - Abstract Syntax Notation One \r
+ (ASN.1): Specification of basic notation" \r
+ \r
+ [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection \r
+ Level Security Mechanisms", draft-ietf-ldapbis-authmeth-\r
+ xx.txt, (a work in progress). \r
+ \r
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, \r
+ "Information technology - ASN.1 encoding rules: \r
+ Specification of Basic Encoding Rules (BER), Canonical \r
+ Encoding Rules (CER) and Distinguished Encoding Rules \r
+ (DER)", 2002. \r
+ \r
+ [IP] Postel, J., "Internet Protocol", STD5 and RFC 791, \r
+ September 1981 \r
+ \r
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - \r
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 \r
+ : 1993. \r
+ \r
+ [Keyword] Bradner, S., "Key words for use in RFCs to Indicate \r
+ Requirement Levels", RFC 2119, March 1997. \r
+ \r
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of \r
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a \r
+ work in progress). \r
+ \r
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-\r
+ ldapbis-bcp64-xx.txt, (a work in progress). \r
+ \r
+ [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-\r
+ ldapbis-url-xx.txt, (a work in progress). \r
+ \r
+ [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-\r
+ ietf-ldapbis-models-xx.txt (a work in progress). \r
+ \r
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map", \r
+ draft-ietf-ldapbis-roadmap-xx.txt (a work in progress). \r
+ \r
+ [SASL] Melnikov, A., "Simple Authentication and Security Layer", \r
+ draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress). \r
+ \r
+ [SASLPrep] Zeilenga, K., "Stringprep profile for user names and \r
+ passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in \r
+ progress). \r
+ \r
+ [StringPrep] Hoffman P. and M. Blanchet, "Preparation of \r
+ Internationalized Strings ('stringprep')", draft-hoffman-\r
+ rfc3454bis-xx.txt, a work in progress. \r
+ \r
+ [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching \r
+ Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in \r
+ progress). \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 43 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC \r
+ 793, September 1981 \r
+ \r
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1", \r
+ draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress. \r
+ \r
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version \r
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0" \r
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), \r
+ as amended by the "Unicode Standard Annex #27: Unicode \r
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the \r
+ "Unicode Standard Annex #28: Unicode 3.2" \r
+ (http://www.unicode.org/reports/tr28/). \r
+ \r
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform \r
+ Resource Identifiers (URI): Generic Syntax", RFC 2396, \r
+ August 1998. \r
+ \r
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO \r
+ 10646", STD63 and RFC3629, November 2003. \r
+ \r
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, \r
+ Models and Service", 1993. \r
+ \r
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. \r
+ \r
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service \r
+ Definition", 1993. \r
+ \r
+ \r
+9. Informative References \r
+ \r
+ [Glossary] The Unicode Consortium, "Unicode Glossary", \r
+ <http://www.unicode.org/glossary/>. \r
+ \r
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report \r
+ #17, Character Encoding Model", UTR17, \r
+ <http://www.unicode.org/unicode/reports/tr17/>, August \r
+ 2000. \r
+ \r
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3" \r
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l\r
+ dapv3/> \r
+ \r
+ [PortReg] IANA, "Port Numbers", \r
+ http://www.iana.org/assignments/port-numbers \r
+ \r
+ \r
+10. IANA Considerations \r
+ \r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 44 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ It is requested that the Internet Assigned Numbers Authority (IANA) \r
+ update the LDAP result code registry to indicate that this document \r
+ provides the definitive technical specification for result codes 0-\r
+ 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value \r
+ (strongAuthRequired) has been renamed (to strongerAuthRequired). \r
+ \r
+ It is requested that the IANA update the LDAP Protocol Mechanism \r
+ registry to indicate that this document and [AuthMeth] provides the \r
+ definitive technical specification for the StartTLS \r
+ (1.3.6.1.4.1.1466.20037) Extended operation. \r
+ \r
+ It is requested that the IANA update the occurrence of "RFC XXXX" in \r
+ this section and Appendix B with this RFC number at publication. \r
+ \r
+ It is requested that IANA assign upon Standards Action an LDAP Object \r
+ Identifier [LDAPIANA] to identify the ASN.1 module defined in this \r
+ document. \r
+ \r
+ Subject: Request for LDAP Object Identifier Registration \r
+ Person & email address to contact for further information: \r
+ Jim Sermersheim <jimse@novell.com> \r
+ Specification: RFC XXXX \r
+ Author/Change Controller: IESG \r
+ Comments: \r
+ Identifies the LDAP ASN.1 module \r
+ \r
+ [[Note to RFC Editor: please replace the occurrence of <IANA-\r
+ ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned \r
+ OID.]] \r
+ \r
+ \r
+11. Editor's Address \r
+ \r
+ Jim Sermersheim \r
+ Novell, Inc. \r
+ 1800 South Novell Place \r
+ Provo, Utah 84606, USA \r
+ jimse@novell.com \r
+ +1 801 861-3088 \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 45 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+Appendix A. LDAP Result Codes \r
+ \r
+ This normative appendix details additional considerations regarding \r
+ LDAP result codes and provides a brief, general description of each \r
+ LDAP result code enumerated in Section 4.1.9. \r
+ \r
+ Additional result codes MAY be defined for use with extensions \r
+ [LDAPIANA]. Client implementations SHALL treat any result code which \r
+ they do not recognize as an unknown error condition. \r
+ \r
+ The descriptions provided here do not fully account for result code \r
+ substitutions used to prevent unauthorized disclosures (such as \r
+ substitution of noSuchObject for insufficientAccessRights, or \r
+ invalidCredentials for insufficientAccessRights). \r
+ \r
+ \r
+A.1. Non-Error Result Codes \r
+ \r
+ These result codes (called "non-error" result codes) do not indicate \r
+ an error condition: \r
+ success (0), \r
+ compareFalse (5), \r
+ compareTrue (6), \r
+ referral (10), and \r
+ saslBindInProgress (14). \r
+ \r
+ The success, compareTrue, and compareFalse result codes indicate \r
+ successful completion (and, hence, are referred to as "successful" \r
+ result codes). \r
+ \r
+ The referral and saslBindInProgress result codes indicate the client \r
+ needs to take additional action to complete the operation. \r
+ \r
+ \r
+A.2. Result Codes \r
+ \r
+ Existing LDAP result codes are described as follows: \r
+ \r
+ success (0) \r
+ Indicates the successful completion of an operation. Note: \r
+ this code is not used with the Compare operation. See \r
+ compareFalse (5) and compareTrue (6). \r
+ \r
+ operationsError (1) \r
+ Indicates that the operation is not properly sequenced with \r
+ relation to other operations (of same or different type). \r
+ \r
+ For example, this code is returned if the client attempts to \r
+ StartTLS [TLS] while there are other uncompleted operations \r
+ or if a TLS layer was already installed. \r
+ \r
+ protocolError (2) \r
+ Indicates the server received data which is not well-formed. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 46 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ For Bind operation only, this code is also used to indicate \r
+ that the server does not support the requested protocol \r
+ version. \r
+ \r
+ For Extended operations only, this code is also used to \r
+ indicate that the server does not support (by design or \r
+ configuration) the Extended operation associated with the \r
+ requestName. \r
+ \r
+ For request operations specifying multiple controls, this may \r
+ be used to indicate that the server cannot ignore the order \r
+ of the controls as specified, or that the combination of the \r
+ specified controls is invalid or unspecified. \r
+ \r
+ timeLimitExceeded (3) \r
+ Indicates that the time limit specified by the client was \r
+ exceeded before the operation could be completed. \r
+ \r
+ sizeLimitExceeded (4) \r
+ Indicates that the size limit specified by the client was \r
+ exceeded before the operation could be completed. \r
+ \r
+ compareFalse (5) \r
+ Indicates that the Compare operation has successfully \r
+ completed and the assertion has evaluated to FALSE or \r
+ Undefined. \r
+ \r
+ compareTrue (6) \r
+ Indicates that the Compare operation has successfully \r
+ completed and the assertion has evaluated to TRUE. \r
+ \r
+ authMethodNotSupported (7) \r
+ Indicates that the authentication method or mechanism is not \r
+ supported. \r
+ \r
+ strongerAuthRequired (8) \r
+ Indicates the server requires strong(er) authentication in \r
+ order to complete the operation. \r
+ \r
+ When used with the Notice of Disconnection operation, this \r
+ code indicates that the server has detected that an \r
+ established security association between the client and \r
+ server has unexpectedly failed or been compromised. \r
+ \r
+ referral (10) \r
+ Indicates that a referral needs to be chased to complete the \r
+ operation (see Section 4.1.10). \r
+ \r
+ adminLimitExceeded (11) \r
+ Indicates that an administrative limit has been exceeded. \r
+ \r
+ unavailableCriticalExtension (12) \r
+ Indicates a critical control is unrecognized (see Section \r
+ 4.1.11). \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 47 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ confidentialityRequired (13) \r
+ Indicates that data confidentiality protections are required. \r
+ \r
+ saslBindInProgress (14) \r
+ Indicates the server requires the client to send a new bind \r
+ request, with the same SASL mechanism, to continue the \r
+ authentication process (see Section 4.2). \r
+ \r
+ noSuchAttribute (16) \r
+ Indicates that the named entry does not contain the specified \r
+ attribute or attribute value. \r
+ \r
+ undefinedAttributeType (17) \r
+ Indicates that a request field contains an unrecognized \r
+ attribute description. \r
+ \r
+ inappropriateMatching (18) \r
+ Indicates that an attempt was made (e.g. in an assertion) to \r
+ use a matching rule not defined for the attribute type \r
+ concerned. \r
+ \r
+ constraintViolation (19) \r
+ Indicates that the client supplied an attribute value which \r
+ does not conform to the constraints placed upon it by the \r
+ data model. \r
+ \r
+ For example, this code is returned when multiple values are \r
+ supplied to an attribute which has a SINGLE-VALUE constraint. \r
+ \r
+ attributeOrValueExists (20) \r
+ Indicates that the client supplied an attribute or value to \r
+ be added to an entry, but the attribute or value already \r
+ exists. \r
+ \r
+ invalidAttributeSyntax (21) \r
+ Indicates that a purported attribute value does not conform \r
+ to the syntax of the attribute. \r
+ \r
+ noSuchObject (32) \r
+ Indicates that the object does not exist in the DIT. \r
+ \r
+ aliasProblem (33) \r
+ Indicates that an alias problem has occurred. For example, \r
+ the code may used to indicate an alias has been dereferenced \r
+ which names no object. \r
+ \r
+ invalidDNSyntax (34) \r
+ Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search \r
+ base, target entry, ModifyDN newrdn, etc.) of a request does \r
+ not conform to the required syntax or contains attribute \r
+ values which do not conform to the syntax of the attribute's \r
+ type. \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 48 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ aliasDereferencingProblem (36) \r
+ Indicates that a problem occurred while dereferencing an \r
+ alias. Typically an alias was encountered in a situation \r
+ where it was not allowed or where access was denied. \r
+ \r
+ inappropriateAuthentication (48) \r
+ Indicates the server requires the client which had attempted \r
+ to bind anonymously or without supplying credentials to \r
+ provide some form of credentials. \r
+ \r
+ invalidCredentials (49) \r
+ Indicates that the provided credentials (e.g. the user's name \r
+ and password) are invalid. \r
+ \r
+ insufficientAccessRights (50) \r
+ Indicates that the client does not have sufficient access \r
+ rights to perform the operation. \r
+ \r
+ busy (51) \r
+ Indicates that the server is too busy to service the \r
+ operation. \r
+ \r
+ unavailable (52) \r
+ Indicates that the server is shutting down or a subsystem \r
+ necessary to complete the operation is offline. \r
+ \r
+ unwillingToPerform (53) \r
+ Indicates that the server is unwilling to perform the \r
+ operation. \r
+ \r
+ loopDetect (54) \r
+ Indicates that the server has detected an internal loop (e.g. \r
+ while dereferencing aliases or chaining an operation). \r
+ \r
+ namingViolation (64) \r
+ Indicates that the entry's name violates naming restrictions. \r
+ \r
+ objectClassViolation (65) \r
+ Indicates that the entry violates object class restrictions. \r
+ \r
+ notAllowedOnNonLeaf (66) \r
+ Indicates that the operation is inappropriately acting upon a \r
+ non-leaf entry. \r
+ \r
+ notAllowedOnRDN (67) \r
+ Indicates that the operation is inappropriately attempting to \r
+ remove a value which forms the entry's relative distinguished \r
+ name. \r
+ \r
+ entryAlreadyExists (68) \r
+ Indicates that the request cannot be fulfilled (added, moved, \r
+ or renamed) as the target entry already exists. \r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 49 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ objectClassModsProhibited (69) \r
+ Indicates that an attempt to modify the object class(es) of \r
+ an entry's 'objectClass' attribute is prohibited. \r
+ \r
+ For example, this code is returned when a client attempts to \r
+ modify the structural object class of an entry. \r
+ \r
+ affectsMultipleDSAs (71) \r
+ Indicates that the operation cannot be performed as it would \r
+ affect multiple servers (DSAs). \r
+ \r
+ other (80) \r
+ Indicates the server has encountered an internal error. \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 50 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+Appendix B. Complete ASN.1 Definition \r
+ \r
+ This appendix is normative. \r
+ \r
+ Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-\r
+ ASSIGNED-DIRECTORY-NUMBER>} \r
+ -- Copyright (C) The Internet Society (2005). This version of \r
+ -- this ASN.1 module is part of RFC XXXX; see the RFC itself \r
+ -- for full legal notices. \r
+ DEFINITIONS \r
+ IMPLICIT TAGS \r
+ EXTENSIBILITY IMPLIED ::= \r
+ \r
+ BEGIN \r
+ \r
+ LDAPMessage ::= SEQUENCE { \r
+ messageID MessageID, \r
+ protocolOp CHOICE { \r
+ bindRequest BindRequest, \r
+ bindResponse BindResponse, \r
+ unbindRequest UnbindRequest, \r
+ searchRequest SearchRequest, \r
+ searchResEntry SearchResultEntry, \r
+ searchResDone SearchResultDone, \r
+ searchResRef SearchResultReference, \r
+ modifyRequest ModifyRequest, \r
+ modifyResponse ModifyResponse, \r
+ addRequest AddRequest, \r
+ addResponse AddResponse, \r
+ delRequest DelRequest, \r
+ delResponse DelResponse, \r
+ modDNRequest ModifyDNRequest, \r
+ modDNResponse ModifyDNResponse, \r
+ compareRequest CompareRequest, \r
+ compareResponse CompareResponse, \r
+ abandonRequest AbandonRequest, \r
+ extendedReq ExtendedRequest, \r
+ extendedResp ExtendedResponse, \r
+ ..., \r
+ intermediateResponse IntermediateResponse }, \r
+ controls [0] Controls OPTIONAL } \r
+ \r
+ MessageID ::= INTEGER (0 .. maxInt) \r
+ \r
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- \r
+ \r
+ LDAPString ::= OCTET STRING -- UTF-8 encoded, \r
+ -- [ISO10646] characters \r
+ \r
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models] \r
+ \r
+ LDAPDN ::= LDAPString -- Constrained to <distinguishedName> \r
+ -- [LDAPDN] \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 51 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component> \r
+ -- [LDAPDN] \r
+ \r
+ AttributeDescription ::= LDAPString \r
+ -- Constrained to <attributedescription> \r
+ -- [Models] \r
+ \r
+ AttributeValue ::= OCTET STRING \r
+ \r
+ AttributeValueAssertion ::= SEQUENCE { \r
+ attributeDesc AttributeDescription, \r
+ assertionValue AssertionValue } \r
+ \r
+ AssertionValue ::= OCTET STRING \r
+ \r
+ PartialAttribute ::= SEQUENCE { \r
+ type AttributeDescription, \r
+ vals SET OF value AttributeValue } \r
+ \r
+ Attribute ::= PartialAttribute(WITH COMPONENTS { \r
+ ..., \r
+ vals (SIZE(1..MAX))}) \r
+ \r
+ MatchingRuleId ::= LDAPString \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 52 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ LDAPResult ::= SEQUENCE { \r
+ resultCode ENUMERATED { \r
+ success (0), \r
+ operationsError (1), \r
+ protocolError (2), \r
+ timeLimitExceeded (3), \r
+ sizeLimitExceeded (4), \r
+ compareFalse (5), \r
+ compareTrue (6), \r
+ authMethodNotSupported (7), \r
+ strongerAuthRequired (8), \r
+ -- 9 reserved -- \r
+ referral (10), \r
+ adminLimitExceeded (11), \r
+ unavailableCriticalExtension (12), \r
+ confidentialityRequired (13), \r
+ saslBindInProgress (14), \r
+ noSuchAttribute (16), \r
+ undefinedAttributeType (17), \r
+ inappropriateMatching (18), \r
+ constraintViolation (19), \r
+ attributeOrValueExists (20), \r
+ invalidAttributeSyntax (21), \r
+ -- 22-31 unused -- \r
+ noSuchObject (32), \r
+ aliasProblem (33), \r
+ invalidDNSyntax (34), \r
+ -- 35 reserved for undefined isLeaf -- \r
+ aliasDereferencingProblem (36), \r
+ -- 37-47 unused -- \r
+ inappropriateAuthentication (48), \r
+ invalidCredentials (49), \r
+ insufficientAccessRights (50), \r
+ busy (51), \r
+ unavailable (52), \r
+ unwillingToPerform (53), \r
+ loopDetect (54), \r
+ -- 55-63 unused -- \r
+ namingViolation (64), \r
+ objectClassViolation (65), \r
+ notAllowedOnNonLeaf (66), \r
+ notAllowedOnRDN (67), \r
+ entryAlreadyExists (68), \r
+ objectClassModsProhibited (69), \r
+ -- 70 reserved for CLDAP -- \r
+ affectsMultipleDSAs (71), \r
+ -- 72-79 unused -- \r
+ other (80), \r
+ ... }, \r
+ matchedDN LDAPDN, \r
+ diagnosticMessage LDAPString, \r
+ referral [3] Referral OPTIONAL } \r
+ \r
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 53 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ URI ::= LDAPString -- limited to characters permitted in \r
+ -- URIs \r
+ \r
+ Controls ::= SEQUENCE OF control Control \r
+ \r
+ Control ::= SEQUENCE { \r
+ controlType LDAPOID, \r
+ criticality BOOLEAN DEFAULT FALSE, \r
+ controlValue OCTET STRING OPTIONAL } \r
+ \r
+ BindRequest ::= [APPLICATION 0] SEQUENCE { \r
+ version INTEGER (1 .. 127), \r
+ name LDAPDN, \r
+ authentication AuthenticationChoice } \r
+ \r
+ AuthenticationChoice ::= CHOICE { \r
+ simple [0] OCTET STRING, \r
+ -- 1 and 2 reserved \r
+ sasl [3] SaslCredentials, \r
+ ... } \r
+ \r
+ SaslCredentials ::= SEQUENCE { \r
+ mechanism LDAPString, \r
+ credentials OCTET STRING OPTIONAL } \r
+ \r
+ BindResponse ::= [APPLICATION 1] SEQUENCE { \r
+ COMPONENTS OF LDAPResult, \r
+ serverSaslCreds [7] OCTET STRING OPTIONAL } \r
+ \r
+ UnbindRequest ::= [APPLICATION 2] NULL \r
+ \r
+ SearchRequest ::= [APPLICATION 3] SEQUENCE { \r
+ baseObject LDAPDN, \r
+ scope ENUMERATED { \r
+ baseObject (0), \r
+ singleLevel (1), \r
+ wholeSubtree (2), \r
+ ... }, \r
+ derefAliases ENUMERATED { \r
+ neverDerefAliases (0), \r
+ derefInSearching (1), \r
+ derefFindingBaseObj (2), \r
+ derefAlways (3) }, \r
+ sizeLimit INTEGER (0 .. maxInt), \r
+ timeLimit INTEGER (0 .. maxInt), \r
+ typesOnly BOOLEAN, \r
+ filter Filter, \r
+ attributes AttributeSelection } \r
+ \r
+ AttributeSelection ::= SEQUENCE OF selector LDAPString \r
+ -- The LDAPString is constrained to \r
+ -- <attributeSelector> in Section 4.5.1.7 \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 54 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ Filter ::= CHOICE { \r
+ and [0] SET SIZE (1..MAX) OF filter Filter, \r
+ or [1] SET SIZE (1..MAX) OF filter Filter, \r
+ not [2] Filter, \r
+ equalityMatch [3] AttributeValueAssertion, \r
+ substrings [4] SubstringFilter, \r
+ greaterOrEqual [5] AttributeValueAssertion, \r
+ lessOrEqual [6] AttributeValueAssertion, \r
+ present [7] AttributeDescription, \r
+ approxMatch [8] AttributeValueAssertion, \r
+ extensibleMatch [9] MatchingRuleAssertion, \r
+ ... } \r
+ \r
+ SubstringFilter ::= SEQUENCE { \r
+ type AttributeDescription, \r
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { \r
+ initial [0] AssertionValue, -- can occur at most once \r
+ any [1] AssertionValue, \r
+ final [2] AssertionValue } -- can occur at most once \r
+ } \r
+ \r
+ MatchingRuleAssertion ::= SEQUENCE { \r
+ matchingRule [1] MatchingRuleId OPTIONAL, \r
+ type [2] AttributeDescription OPTIONAL, \r
+ matchValue [3] AssertionValue, \r
+ dnAttributes [4] BOOLEAN DEFAULT FALSE } \r
+ \r
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE { \r
+ objectName LDAPDN, \r
+ attributes PartialAttributeList } \r
+ \r
+ PartialAttributeList ::= SEQUENCE OF \r
+ partialAttribute PartialAttribute \r
+ \r
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE \r
+ SIZE (1..MAX) OF uri URI \r
+ \r
+ SearchResultDone ::= [APPLICATION 5] LDAPResult \r
+ \r
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE { \r
+ object LDAPDN, \r
+ changes SEQUENCE OF change SEQUENCE { \r
+ operation ENUMERATED { \r
+ add (0), \r
+ delete (1), \r
+ replace (2), \r
+ ... }, \r
+ modification PartialAttribute } } \r
+ \r
+ ModifyResponse ::= [APPLICATION 7] LDAPResult \r
+ \r
+ AddRequest ::= [APPLICATION 8] SEQUENCE { \r
+ entry LDAPDN, \r
+ attributes AttributeList } \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 55 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ AttributeList ::= SEQUENCE OF attribute Attribute \r
+ \r
+ AddResponse ::= [APPLICATION 9] LDAPResult \r
+ \r
+ DelRequest ::= [APPLICATION 10] LDAPDN \r
+ \r
+ DelResponse ::= [APPLICATION 11] LDAPResult \r
+ \r
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { \r
+ entry LDAPDN, \r
+ newrdn RelativeLDAPDN, \r
+ deleteoldrdn BOOLEAN, \r
+ newSuperior [0] LDAPDN OPTIONAL } \r
+ \r
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult \r
+ \r
+ CompareRequest ::= [APPLICATION 14] SEQUENCE { \r
+ entry LDAPDN, \r
+ ava AttributeValueAssertion } \r
+ \r
+ CompareResponse ::= [APPLICATION 15] LDAPResult \r
+ \r
+ AbandonRequest ::= [APPLICATION 16] MessageID \r
+ \r
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE { \r
+ requestName [0] LDAPOID, \r
+ requestValue [1] OCTET STRING OPTIONAL } \r
+ \r
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE { \r
+ COMPONENTS OF LDAPResult, \r
+ responseName [10] LDAPOID OPTIONAL, \r
+ responseValue [11] OCTET STRING OPTIONAL } \r
+ \r
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE { \r
+ responseName [0] LDAPOID OPTIONAL, \r
+ responseValue [1] OCTET STRING OPTIONAL } \r
+ \r
+ END \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 56 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+Appendix C. Changes \r
+ \r
+ This appendix is non-normative. \r
+ \r
+ This appendix summarizes substantive changes made to RFC 2251, RFC \r
+ 2830, and RFC 3771. \r
+ \r
+ \r
+C.1. Changes made to RFC 2251: \r
+ \r
+ This section summarizes the substantive changes made to Sections 1, \r
+ 2, 3.1, and 4 through the remainder of RFC 2251. Readers should \r
+ consult [Models] and [AuthMeth] for summaries of changes to other \r
+ sections. \r
+ \r
+ \r
+C.1.1. Section 1 (Status of this Memo) \r
+ \r
+ - Removed IESG note. Post publication of RFC 2251, mandatory LDAP \r
+ authentication mechanisms have been standardized which are \r
+ sufficient to remove this note. See [AuthMeth] for authentication \r
+ mechanisms. \r
+ \r
+ \r
+C.1.2. Section 3.1 (Protocol Model) and others \r
+ \r
+ - Removed notes giving history between LDAP v1, v2 and v3. Instead, \r
+ added sufficient language so that this document can stand on its \r
+ own. \r
+ \r
+ \r
+C.1.3. Section 4 (Elements of Protocol) \r
+ \r
+ - Clarified where the extensibility features of ASN.1 apply to the \r
+ protocol. This change affected various ASN.1 types by the \r
+ inclusion of ellipses (...) to certain elements. \r
+ - Removed the requirement that servers which implement version 3 or \r
+ later MUST provide the 'supportedLDAPVersion' attribute. This \r
+ statement provided no interoperability advantages. \r
+ \r
+ \r
+C.1.4. Section 4.1.1 (Message Envelope) \r
+ \r
+ - There was a mandatory requirement for the server to return a \r
+ Notice of Disconnection and drop the transport connection when a \r
+ PDU is malformed in a certain way. This has been updated such that \r
+ the server SHOULD return the Notice of Disconnection, and MUST \r
+ terminate the LDAP Session. \r
+ \r
+ \r
+C.1.5. Section 4.1.1.1 (Message ID) \r
+ \r
+ - Required that the messageID of requests MUST be non-zero as the \r
+ zero is reserved for Notice of Disconnection. \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 57 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ - Specified when it is and isn't appropriate to return an already \r
+ used message id. RFC 2251 accidentally imposed synchronous server \r
+ behavior in its wording of this. \r
+ \r
+ \r
+C.1.6. Section 4.1.2 (String Types) \r
+ \r
+ - Stated that LDAPOID is constrained to <numericoid> from [Models]. \r
+ \r
+ \r
+C.1.7. Section 4.1.5.1 (Binary Option) and others \r
+ \r
+ - Removed the Binary Option from the specification. There are \r
+ numerous interoperability problems associated with this method of \r
+ alternate attribute type encoding. Work to specify a suitable \r
+ replacement is ongoing. \r
+ \r
+ \r
+C.1.8. Section 4.1.8 (Attribute) \r
+ \r
+ - Combined the definitions of PartialAttribute and Attribute here, \r
+ and defined Attribute in terms of PartialAttribute. \r
+ \r
+ \r
+C.1.9. Section 4.1.10 (Result Message) \r
+ \r
+ - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to \r
+ be sent for non-error results. \r
+ - Moved some language into Appendix A, and refer the reader there. \r
+ - Allowed matchedDN to be present for other result codes than those \r
+ listed in RFC 2251. \r
+ - renamed the code "strongAuthRequired" to "strongerAuthRequired" to \r
+ clarify that this code may often be returned to indicate that a \r
+ stronger authentication is needed to perform a given operation. \r
+ \r
+ \r
+C.1.10. Section 4.1.11 (Referral) \r
+ \r
+ - Defined referrals in terms of URIs rather than URLs. \r
+ - Removed the requirement that all referral URIs MUST be equally \r
+ capable of progressing the operation. The statement was ambiguous \r
+ and provided no instructions on how to carry it out. \r
+ - Added the requirement that clients MUST NOT loop between servers. \r
+ - Clarified the instructions for using LDAPURLs in referrals, and in \r
+ doing so added a recommendation that the scope part be present. \r
+ - Removed imperatives which required clients to use URLs in specific \r
+ ways to progress an operation. These did nothing for \r
+ interoperability. \r
+ \r
+ \r
+C.1.11. Section 4.1.12 (Controls) \r
+ \r
+ - Specified how control values defined in terms of ASN.1 are to be \r
+ encoded. \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 58 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ - Noted that the criticality field is only applied to request \r
+ messages (except UnbindRequest), and must be ignored when present \r
+ on response messages and UnbindRequest. \r
+ - Specified that non-critical controls may be ignored at the \r
+ server's discretion. There was confusion in the original wording \r
+ which led some to believe that recognized controls may not be \r
+ ignored as long as they were associated with a proper request. \r
+ - Added language regarding combinations of controls and the ordering \r
+ of controls on a message. \r
+ - Specified that when the semantics of the combination of controls \r
+ is undefined or unknown, it results in a protocolError. \r
+ - Changed "The server MUST be prepared" to "Implementations MUST be \r
+ prepared" in the eighth paragraph to reflect that both client and \r
+ server implementations must be able to handle this (as both parse \r
+ controls). \r
+ \r
+ \r
+C.1.12. Section 4.2 (Bind Operation) \r
+ \r
+ - Mandated that servers return protocolError when the version is not \r
+ supported. \r
+ - Disambiguated behavior when the simple authentication is used, the \r
+ name is empty and the password is non-empty. \r
+ - Required servers to not dereference aliases for Bind. This was \r
+ added for consistency with other operations and to help ensure \r
+ data consistency. \r
+ - Required that textual passwords be transferred as UTF-8 encoded \r
+ Unicode, and added recommendations on string preparation. This was \r
+ to help ensure interoperability of passwords being sent from \r
+ different clients. \r
+ \r
+ \r
+C.1.13. Section 4.2.1 (Sequencing of the Bind Request) \r
+ \r
+ - This section was largely reorganized for readability and language \r
+ was added to clarify the authentication state of failed and \r
+ abandoned Bind operations. \r
+ - Removed: "If a SASL transfer encryption or integrity mechanism has \r
+ been negotiated, that mechanism does not support the changing of \r
+ credentials from one identity to another, then the client MUST \r
+ instead establish a new connection." \r
+ If there are dependencies between multiple negotiations of a \r
+ particular SASL mechanism, the technical specification for that \r
+ SASL mechanism details how applications are to deal with them. \r
+ LDAP should not require any special handling. \r
+ - Dropped MUST imperative in paragraph 3 to align with [Keywords]. \r
+ - Mandated that clients not send non-Bind operations while a Bind is \r
+ in progress, and suggested that servers not process them if they \r
+ are received. This is needed to ensure proper sequencing of the \r
+ Bind in relationship to other operations. \r
+ \r
+ \r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 59 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+C.1.14. Section 4.2.3 (Bind Response) \r
+ \r
+ - Moved most error-related text to Appendix A, and added text \r
+ regarding certain errors used in conjunction with the Bind \r
+ operation. \r
+ - Prohibited the server from specifying serverSaslCreds when not \r
+ appropriate. \r
+ \r
+ \r
+C.1.15. Section 4.3 (Unbind Operation) \r
+ \r
+ - Specified that both peers are to cease transmission and terminate \r
+ the LDAP session for the Unbind operation. \r
+ \r
+ \r
+C.1.16. Section 4.4 (Unsolicited Notification) \r
+ \r
+ - Added instructions for future specifications of Unsolicited \r
+ Notifications. \r
+ \r
+ \r
+C.1.17. Section 4.5.1 (Search Request) \r
+ \r
+ - SearchRequest attributes is now defined as an AttributeSelection \r
+ type rather than AttributeDescriptionList, and an ABNF is \r
+ provided. \r
+ - SearchRequest attributes may contain duplicate attribute \r
+ descriptions. This was previously prohibited. Now servers are \r
+ instructed to ignore subsequent names when they are duplicated. \r
+ This was relaxed in order to allow different short names and also \r
+ OIDs to be requested for an attribute. \r
+ - The present search filter now evaluates to Undefined when the \r
+ specified attribute is not known to the server. It used to \r
+ evaluate to FALSE, which caused behavior inconsistent with what \r
+ most would expect, especially when the not operator was used. \r
+ - The Filter choice SubstringFilter substrings type is now defined \r
+ with a lower bound of 1. \r
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types \r
+ are now AssertionValue rather than LDAPString. Also, added \r
+ imperatives stating that 'initial' (if present) must be listed \r
+ first, and 'final' (if present) must be listed last. \r
+ - Disambiguated the semantics of the derefAliases choices. There was \r
+ question as to whether derefInSearching applied to the base object \r
+ in a wholeSubtree Search. \r
+ - Added instructions for equalityMatch, substrings, greaterOrEqual, \r
+ lessOrEqual, and approxMatch. \r
+ \r
+ \r
+C.1.18. Section 4.5.2 (Search Result) \r
+ \r
+ - Recommended that servers not use attribute short names when it \r
+ knows they are ambiguous or may cause interoperability problems. \r
+ - Removed all mention of ExtendedResponse due to lack of \r
+ implementation. \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 60 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ \r
+C.1.19. Section 4.5.3 (Continuation References in the Search Result) \r
+ \r
+ - Made changes similar to those made to Section 4.1.11. \r
+ \r
+ \r
+C.1.20. Section 4.5.3.1 (Example) \r
+ \r
+ - Fixed examples to adhere to changes made to Section 4.5.3. \r
+ \r
+ \r
+C.1.21. Section 4.6 (Modify Operation) \r
+ \r
+ - Replaced AttributeTypeAndValues with Attribute as they are \r
+ equivalent. \r
+ - Specified the types of modification changes which might \r
+ temporarily violate schema. Some readers were under the impression \r
+ that any temporary schema violation was allowed. \r
+ \r
+ \r
+C.1.22. Section 4.7 (Add Operation) \r
+ \r
+ - Aligned Add operation with X.511 in that the attributes of the RDN \r
+ are used in conjunction with the listed attributes to create the \r
+ entry. Previously, Add required that the distinguished values be \r
+ present in the listed attributes. \r
+ - Removed requirement that the objectClass attribute MUST be \r
+ specified as some DSE types do not require this attribute. \r
+ Instead, generic wording was added, requiring the added entry to \r
+ adhere to the data model. \r
+ - Removed recommendation regarding placement of objects. This is \r
+ covered in the data model document. \r
+ \r
+ \r
+C.1.23. Section 4.9 (Modify DN Operation) \r
+ \r
+ - Required servers to not dereference aliases for Modify DN. This \r
+ was added for consistency with other operations and to help ensure \r
+ data consistency. \r
+ - Allow Modify DN to fail when moving between naming contexts. \r
+ - Specified what happens when the attributes of the newrdn are not \r
+ present on the entry. \r
+ \r
+ \r
+C.1.24. Section 4.10 (Compare Operation) \r
+ \r
+ - Specified that compareFalse means that the Compare took place and \r
+ the result is false. There was confusion which lead people to \r
+ believe that an Undefined match resulted in compareFalse. \r
+ - Required servers to not dereference aliases for Compare. This was \r
+ added for consistency with other operations and to help ensure \r
+ data consistency. \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 61 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+C.1.25. Section 4.11 (Abandon Operation) \r
+ \r
+ - Explained that since Abandon returns no response, clients should \r
+ not use it if they need to know the outcome. \r
+ - Specified that Abandon and Unbind cannot be abandoned. \r
+ \r
+ \r
+C.1.26. Section 4.12 (Extended Operation) \r
+ \r
+ - Specified how values of Extended operations defined in terms of \r
+ ASN.1 are to be encoded. \r
+ - Added instructions on what Extended operation specifications \r
+ consist of. \r
+ - Added a recommendation that servers advertise supported Extended \r
+ operations. \r
+ \r
+ \r
+C.1.27. Section 5.2 (Transfer Protocols) \r
+ \r
+ - Moved referral-specific instructions into referral-related \r
+ sections. \r
+ \r
+ \r
+C.1.28. Section 7 (Security Considerations) \r
+ \r
+ - Reworded notes regarding SASL not protecting certain aspects of \r
+ the LDAP Bind messages. \r
+ - Noted that Servers are encouraged to prevent directory \r
+ modifications by clients that have authenticated anonymously \r
+ [AuthMeth]. \r
+ - Added a note regarding the possibility of changes to security \r
+ factors (authentication, authorization, data confidentiality). \r
+ - Warned against following referrals that may have been injected in \r
+ the data stream. \r
+ - Noted that servers should protect information equally, whether in \r
+ an error condition or not, and mentioned specifically; matchedDN, \r
+ diagnosticMessage, and resultCodes. \r
+ - Added a note regarding malformed and long encodings. \r
+ \r
+ \r
+C.1.29. Appendix A (Complete ASN.1 Definition) \r
+ \r
+ - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition. \r
+ - Removed AttributeType. It is not used. \r
+ \r
+ \r
+C.2. Changes made to RFC 2830: \r
+ \r
+ This section summarizes the substantive changes made to Sections of \r
+ RFC 2830. Readers should consult [AuthMeth] for summaries of changes \r
+ to other sections. \r
+ \r
+ \r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 62 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+C.2.1. Section 2.3 (Response other than "success") \r
+ \r
+ - Removed wording indicating that referrals can be returned from \r
+ StartTLS. \r
+ - Removed requirement that only a narrow set of result codes can be \r
+ returned. Some result codes are required in certain scenarios, but \r
+ any other may be returned if appropriate. \r
+ - Removed requirement that the ExtendedResponse.responseName MUST be \r
+ present. There are circumstances where this is impossible, and \r
+ requiring this is at odds with language in Section 4.12. \r
+ \r
+ \r
+C.2.1. Section 4 (Closing a TLS Connection) \r
+ \r
+ - Reworded most of this section to align with definitions of the \r
+ LDAP protocol layers. \r
+ - Removed instructions on abrupt closure as this is covered in other \r
+ areas of the document (specifically, Section 5.3) \r
+ \r
+ \r
+C.3. Changes made to RFC 3771: \r
+ \r
+ - Rewrote to fit into this document. In general, semantics were \r
+ preserved. Supporting and background language seen as redundant \r
+ due to its presence in this document was omitted. \r
+ - Specified that Intermediate responses to a request may be of \r
+ different types, and one of the response types may be specified to \r
+ have no response value. \r
+ \r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 63 \f\r
+ Lightweight Directory Access Protocol Version 3 \r
+ \r
+ \r
+ \r
+ \r
+Intellectual Property Statement \r
+ \r
+ The IETF takes no position regarding the validity or scope of any \r
+ Intellectual Property Rights or other rights that might be claimed to \r
+ pertain to the implementation or use of the technology described in \r
+ this document or the extent to which any license under such rights \r
+ might or might not be available; nor does it represent that it has \r
+ made any independent effort to identify any such rights. Information \r
+ on the procedures with respect to rights in RFC documents can be \r
+ found in BCP 78 and BCP 79. \r
+ \r
+ Copies of IPR disclosures made to the IETF Secretariat and any \r
+ assurances of licenses to be made available, or the result of an \r
+ attempt made to obtain a general license or permission for the use of \r
+ such proprietary rights by implementers or users of this \r
+ specification can be obtained from the IETF on-line IPR repository at \r
+ http://www.ietf.org/ipr. \r
+ \r
+ The IETF invites any interested party to bring to its attention any \r
+ copyrights, patents or patent applications, or other proprietary \r
+ rights that may cover technology that may be required to implement \r
+ this standard. Please address the information to the IETF at ietf-\r
+ ipr@ietf.org. \r
+ \r
+Disclaimer of Validity \r
+ \r
+ This document and the information contained herein are provided on an \r
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS \r
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET \r
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, \r
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE \r
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED \r
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. \r
+ \r
+Copyright Statement \r
+ \r
+ Copyright (C) The Internet Society (2005). \r
+ \r
+ This document is subject to the rights, licenses and restrictions \r
+ contained in BCP 78, and except as set forth therein, the authors \r
+ retain all their rights. \r
+ \r
+Acknowledgement \r
+ \r
+ Funding for the RFC Editor function is currently provided by the \r
+ Internet Society. \r
+\r
+\r
+\r
+\r
+\r
+ \r
+Sermersheim Internet-Draft - Expires April 2006 Page 64 \f
\ No newline at end of file
+
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 9 February 2005
+Expires in six months 30 September 2005
LDAP: Internationalized String Preparation
- <draft-ietf-ldapbis-strprep-05.txt>
+ <draft-ietf-ldapbis-strprep-06.txt>
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.
+ 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
+
Zeilenga LDAPprep [Page 1]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
Abstract
Zeilenga LDAPprep [Page 2]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
For instance, the caseIgnoreMatch matching rule may be used to compare
Zeilenga LDAPprep [Page 3]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
b) after applying the Unicode string preparation steps outlined in
Zeilenga LDAPprep [Page 4]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
5) Check bidi
Zeilenga LDAPprep [Page 5]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
Zeilenga LDAPprep [Page 6]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
characters insignificant to the matching rule. This modification
Zeilenga LDAPprep [Page 7]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
2.6.3. telephoneNumber Insignificant Character Handling
Zeilenga LDAPprep [Page 8]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
6. References
[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).
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
6.2. Informative References
Zeilenga LDAPprep [Page 9]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
[X.501] International Telecommunication Union -
Zeilenga LDAPprep [Page 10]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
In absence of substrings matching, the insignificant space handling
Zeilenga LDAPprep [Page 11]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
requirements.
Zeilenga LDAPprep [Page 12]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-05 9 February 2005
+Internet-Draft draft-ietf-ldapbis-strprep-06 30 September 2005
Copies of IPR disclosures made to the IETF Secretariat and any
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.
+ 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
-
-
Zeilenga LDAPprep [Page 13]
\f
-
+
INTERNET-DRAFT Editor: A. Sciberras
Intended Category: Standard Track eB2Bcom
-Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
+Updates: RFC 2247, RFC 2798, RFC 2377 July 11, 2005
Obsoletes: RFC 2256
-
LDAP: Schema for User Applications
- draft-ietf-ldapbis-user-schema-09.txt
+ draft-ietf-ldapbis-user-schema-10.txt
- Copyright (C) The Internet Society (2005). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3978. 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 3979.
+ 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.
+ 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
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
- (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
- editorial comments directly to the editor
+ 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 4 October 2005.
+ This Internet-Draft expires on 11 January 2006.
+
-Copyright Notice
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-Sciberras Expires 4 October 2005 [Page 1]
+Sciberras Expires 11 January 2006 [Page 1]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Abstract
-Sciberras Expires 4 October 2005 [Page 2]
+Sciberras Expires 11 January 2006 [Page 2]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Table of Contents
-Sciberras Expires 4 October 2005 [Page 3]
+Sciberras Expires 11 January 2006 [Page 3]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
- 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
+ 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
-Sciberras Expires 4 October 2005 [Page 4]
+Sciberras Expires 11 January 2006 [Page 4]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
1. Introduction
administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
-1.1 Relationship with other specifications
+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
1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3 General Issues
-Sciberras Expires 4 October 2005 [Page 5]
+Sciberras Expires 11 January 2006 [Page 5]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
-Sciberras Expires 4 October 2005 [Page 6]
+Sciberras Expires 11 January 2006 [Page 6]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Examples: "DE", "AU" and "FR".
-Sciberras Expires 4 October 2005 [Page 7]
+Sciberras Expires 11 January 2006 [Page 7]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.5 'description'
-Sciberras Expires 4 October 2005 [Page 8]
+Sciberras Expires 11 January 2006 [Page 8]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
attribute types with a DN syntax can inherit.
-Sciberras Expires 4 October 2005 [Page 9]
+Sciberras Expires 11 January 2006 [Page 9]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.4.47 NAME 'enhancedSearchGuide'
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
[Syntaxes].
- Examples: "person#(sn$APPROX)#wholeSubtree"
- "organizationalUnit#(ou$SUBSTR)#oneLevel"
+ Examples: "person#(sn$APPROX)#wholeSubtree" and
+ "organizationalUnit#(ou$SUBSTR)#oneLevel".
2.10 'facsimileTelephoneNumber'
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"
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
2.11 'generationQualifier'
( 2.5.4.42 NAME 'givenName'
SUP name )
- Examples: "Andrew", "Charles" and "Joanne"
+ Examples: "Andrew", "Charles" and "Joanne".
-Sciberras Expires 4 October 2005 [Page 10]
+Sciberras Expires 11 January 2006 [Page 10]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.13 'houseIdentifier'
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes].
- Examples: "20" to represent a the house number 20.
+ Examples: "20" to represent the house number 20.
2.14 'initials'
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
[Syntaxes].
- Example: "0198 333 333"
+ Example: "0198 333 333".
-Sciberras Expires 4 October 2005 [Page 11]
+Sciberras Expires 11 January 2006 [Page 11]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.16 'l'
SUP distinguishedName )
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
- "cn=John Xerri,ou=Finance,o=Widget\, Inc" may
+ "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.
-Sciberras Expires 4 October 2005 [Page 12]
+Sciberras Expires 11 January 2006 [Page 12]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.19 'o'
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
+ 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.".
-Sciberras Expires 4 October 2005 [Page 13]
+Sciberras Expires 11 January 2006 [Page 13]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
-Sciberras Expires 4 October 2005 [Page 14]
+Sciberras Expires 11 January 2006 [Page 14]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
at a box on premises of the Postal Service. Each postal box
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"
+ methods, the value would be: "mhs $ telephone".
2.27 'registeredAddress'
-Sciberras Expires 4 October 2005 [Page 15]
+Sciberras Expires 11 January 2006 [Page 15]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.28 'roleOccupant'
1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
- Example: "person#sn$EQ"
+ 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'
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 4 October 2005 [Page 16]
+Sciberras Expires 11 January 2006 [Page 16]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- "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.5.4.4 NAME 'sn'
SUP name )
- Example: "Smith"
+ Example: "Smith".
2.33 'st'
-Sciberras Expires 4 October 2005 [Page 17]
+
+Sciberras Expires 11 January 2006 [Page 17]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.34 'street'
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
[Syntaxes].
- Example: "15 Main St."
+ Example: "15 Main St.".
2.35 'telephoneNumber'
-Sciberras Expires 4 October 2005 [Page 18]
+Sciberras Expires 11 January 2006 [Page 18]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
2.37 'telexNumber'
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
[Syntaxes].
- Example: "12345$023$ABCDE"
+ Example: "12345$023$ABCDE".
2.38 'title'
( 2.5.4.12 NAME 'title'
SUP name )
-
-
Examples: "Vice President", "Software Engineer" and "CEO".
2.39 'uid'
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 4 October 2005 [Page 19]
+Sciberras Expires 11 January 2006 [Page 19]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- 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])
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 [SASLprep], and
+ 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])
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 4 October 2005 [Page 20]
+
+Sciberras Expires 11 January 2006 [Page 20]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- consecutive periods to be valid in the system.
-
2.42 'x121Address'
The 'x121Address' attribute type contains data network addresses as
-Sciberras Expires 4 October 2005 [Page 21]
+
+
+Sciberras Expires 11 January 2006 [Page 21]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3. Object Classes
MAY ( searchGuide $
description ) )
-3.3 'dcObject'
+3.3 'dcObject'
The 'dcObject' object class permits an entry to contains domain
component information. This object class is defined as auxiliary,
-Sciberras Expires 4 October 2005 [Page 22]
+Sciberras Expires 11 January 2006 [Page 22]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3.4 'device'
-Sciberras Expires 4 October 2005 [Page 23]
+Sciberras Expires 11 January 2006 [Page 23]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
cn )
-Sciberras Expires 4 October 2005 [Page 24]
+Sciberras Expires 11 January 2006 [Page 24]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
( 2.5.6.7 NAME 'organizationalPerson'
-Sciberras Expires 4 October 2005 [Page 25]
+Sciberras Expires 11 January 2006 [Page 25]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
3.12 'person'
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )
-3.14 'uidObject'
+3.14 'uidObject'
The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as
-Sciberras Expires 4 October 2005 [Page 26]
+Sciberras Expires 11 January 2006 [Page 26]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
4. IANA Considerations
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
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 4 October 2005 [Page 27]
+Sciberras Expires 11 January 2006 [Page 27]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- 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
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 4 October 2005 [Page 28]
+Sciberras Expires 11 January 2006 [Page 28]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- 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 may
result in disclosure of the password to unauthorized parties.
- Multiple attribute values for the 'userPassword' needs to be used
- with care. Especially reset/deletion of a password by an admin
+ 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.
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' attributer to one
+ 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
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.
+ 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
-Sciberras Expires 4 October 2005 [Page 29]
+
+Sciberras Expires 11 January 2006 [Page 29]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
7. References
"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.
+
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx (a work in
progress)
- [SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
- names and passwords", draft-ietf-sasl-saslprep-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 4 October 2005 [Page 30]
+Sciberras Expires 11 January 2006 [Page 30]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
- ITU-T Recommendation X.121, 1996
[X.509] The Directory: Authentication Framework, ITU-T
Recommendation X.509, 1993
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000
- [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
+ [X.500] ITU-T Recommendations X.5000 (1993) | ISO/IEC
+ 9594-1:1994, Information Technology - Open Systems
+ Interconnection - The Directory: Overview of concepts,
+ models and services.
8. Author's Address
AUSTRALIA
Phone: +61 3 9896 7833
- Email: andrew.sciberras@eb2bcom.com
-Sciberras Expires 4 October 2005 [Page 31]
+Sciberras Expires 11 January 2006 [Page 31]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
+ Email: andrew.sciberras@eb2bcom.com
+
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
-10. Disclaimer of Validity
+10. 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
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.
-
-
-
-
-Sciberras Expires 4 October 2005 [Page 32]
+Sciberras Expires 11 January 2006 [Page 32]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
Appendix A Changes Made Since RFC 2256
-Sciberras Expires 4 October 2005 [Page 33]
+Sciberras Expires 11 January 2006 [Page 33]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
12. Numerous edititorial changes.
-Sciberras Expires 4 October 2005 [Page 34]
+Sciberras Expires 11 January 2006 [Page 34]
\f
-INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+INTERNET-DRAFT LDAP: Schema for User Applications July 11, 2005
30. Spelt out and referenced ABNF on first usage.
-Sciberras Expires 4 October 2005 [Page 35]
+Sciberras Expires 11 January 2006 [Page 35]
\f
-
+
+
+
+
INTERNET-DRAFT S. Legg
-draft-legg-ldap-binary-01.txt Adacel Technologies
-Intended Category: Standards Track 16 June 2004
-Updates: RFC 2251bis
+draft-legg-ldap-binary-03.txt eB2Bcom
+Intended Category: Standards Track 7 June 2005
+Updates: [SYNTAX]
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ 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.
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ 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
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
+ 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@adacel.com.au>.
+ http://www.ietf.org/shadow.html
- This Internet-Draft expires on 16 December 2004.
+ 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 7 December 2005.
Abstract
-Legg Expires 16 December 2004 [Page 1]
+Legg Expires 7 December 2005 [Page 1]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
definition specifies how attribute values conforming to the syntax
-Legg Expires 16 December 2004 [Page 2]
+Legg Expires 7 December 2005 [Page 2]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
Table of Contents
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 10.1. Normative References. . . . . . . . . . . . . . . . . . 6
+ 10.1. Normative References. . . . . . . . . . . . . . . . . . 7
10.2. Informative References. . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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 value
+ 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 [X500] directories, instead of the
- usual LDAP-specific 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
-Legg Expires 16 December 2004 [Page 3]
+Legg Expires 7 December 2005 [Page 3]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
2. Conventions
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.
- Where the binary option is present in an attribute description the
- associated attribute values or assertion value MUST be BER encoded.
- 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.
-
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 same 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.
+ 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 that
- type is not supported.
+ 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 single format of their choosing.
+ any particular attribute value in a format of their choosing.
4. Syntaxes Requiring Binary Transfer
- Certain syntaxes are required to be transferred in the BER encoded
- form. 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
+ 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
-Legg Expires 16 December 2004 [Page 4]
+Legg Expires 7 December 2005 [Page 4]
\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+ 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.
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 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 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.
+ 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.
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 SHALL be
- returned in the binary form.
+Legg Expires 7 December 2005 [Page 5]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
-Legg Expires 16 December 2004 [Page 5]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+ 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
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 server is free to choose whether to return the
- attribute in the binary form.
+ descriptions, then the effect of the request with respect to binary
+ transfer is implementation defined.
8. Security Considerations
the LDAP attribute description option registry [BCP64] as indicated
by the following template:
- Subject: Request for
- LDAP Attribute Description Option Registration
+ 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@adacel.com.au>
+ Steven Legg <steven.legg@eb2bcom.com>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: The existing registration for "binary"
10. References
-10.1. Normative References
- [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
+Legg Expires 7 December 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
-Legg Expires 16 December 2004 [Page 6]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+10.1. Normative References
+ [KEYWORD] 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
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
- June 2004.
+ February 2005.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress, June
- 2004.
+ 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 2004.
+ February 2005.
[SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
Protocol (LDAP): Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
- May 2004.
+ February 2005.
- [PKI] Chadwick, D. and S. Legg, "Internet X.509 Public Key
- Infrastructure Additional LDAP Schema for PKIs and PMIs",
- draft-pkix-ldap-schema-xx.txt, a work in progress, April
- 2002.
+ [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,
+ February 2005.
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information Technology - ASN.1 encoding rules:
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
- [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
- "Information Technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services".
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
-Author's Address
+Legg Expires 7 December 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
-Legg Expires 16 December 2004 [Page 7]
-\f
-INTERNET-DRAFT LDAP: The Binary Encoding Option June 16, 2004
+ "Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services".
+Author's Address
Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
AUSTRALIA
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- Email: steven.legg@adacel.com.au
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg@eb2bcom.com
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.
+ 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
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
+
+
+
+Legg Expires 7 December 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: The Binary Encoding Option June 7, 2005
+
+
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
-Legg Expires 16 December 2004 [Page 8]
-\f
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 7 December 2005 [Page 9]
+\f
-
-Internet-Draft Editor: J. Sermersheim
-Intended Category: Experimental Novell, Inc
-Document: draft-sermersheim-ldap-csn-00.txt Dec 2003
-
-
-
- The LDAP Change Sequence Number Syntax and Matching Rules
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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.
-
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP
- Duplication/Replication/Update Protocols (ldup) mailing list <ietf-
- ldup@imc.org>. Please send editorial comments directly to the editor
- <jimse@novell.com>.
-
-
-Abstract
-
- This document defines a syntax schema element for the Lightweight
- Directory Access Protocol ([LDAP]) which is used to hold a Change
- Sequence Number (CSN). In general, a change sequence number
- represents the place and time that a directory entity was changed. It
- may be used by various attributes for various LDAP replication, and
- synchronization applications.
-
-
-Table of Contents
-
- 1. Introduction....................................................2
- 2. Conventions.....................................................2
- 3. Syntaxes........................................................2
- 3.1 ChangeSequenceNumber Syntax....................................2
- 3.2 UTF8String.....................................................3
- 4. Matching Rules..................................................3
- 4.1 changeSequenceNumberMatch Matching Rule........................3
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 1 \f
- LDAP Change Sequence Number
-
- 4.2 utf8CodePointMatch Matching Rule...............................4
- 4.3 changeSequenceNumberOrderingMatch Matching Rule................4
- 4.4 utf8CodePointOrderingMatch Matching Rule.......................4
- 5. Security Considerations.........................................5
- 6. Acknowledgements................................................5
- 7. Normative References............................................5
- 8. Informative References..........................................6
- 9. IANA Considerations.............................................6
- 10. Editor's Address...............................................6
-
-
-1. Introduction
-
- A number of technologies have been documented, implemented and
- experimented with which in one way or another seek to replicate, or
- synchronize directory data. A common need among these technologies is
- to determine which of two copies of an element represents the latest
- or most authoritative data. Part of meeting this need involves
- associating a change sequence number to an element copy at the time
- of an update to that element. When replication or synchronization
- occurs, the change sequence numbers associated with directory
- elements can be used to decide which element's data will be copied to
- the other element(s).
-
-
-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].
-
- The General Considerations in Section 3.1 of [Syntaxes] apply to the
- syntax definition in this document.
-
- The terms "directory element" and "element" refer to data held in a
- directory and may apply to an attribute value, attribute, entry, or
- any other identifiable directory entity.
-
-
-3. Syntaxes
-
-3.1 ChangeSequenceNumber Syntax
-
- A value of the ChangeSequenceNumber syntax is the time of a change
- along with a replicaID which represents the Directory System Agent
- (DSA) holding the element when it was changed. There are also two
- sequence numbers used to disambiguate directory entities that are
- changed at the same time and place.
-
- The Abstract Syntax Notation One ([ASN.1]) type corresponding to this
- syntax is defined as follows:
-
- ChangeSequenceNumber ::= SEQUENCE {
- time GeneralizedTime,
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 2 \f
- LDAP Change Sequence Number
-
- timeCount INTEGER (0 .. MaxInt),
- replicaID UTF8String,
- changeCount INTEGER (0 .. MaxInt)}
-
- MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- GeneralizedTime is defined in [ASN.1]. Local time without a
- differential SHALL NOT be used.
-
- UTF8String is defined below.
-
- The LDAP-specific encoding of a value of this syntax is the Generic
- String Encoding Rules ([GSER]) encoding of the ASN.1 type.
-
- Example:
- { time "196701160315-0700",
- timeCount 0,
- replicaID "DSA666",
- changeCount 1 }
-
- The following is an LDAP syntax description [RFC2252] suitable for
- publication in the subschema.
-
- ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' )
-
-
-3.2 UTF8String
-
- The UTF8String syntax is used to express a string of characters from
- the [ISO10646] character set (a superset of [Unicode]), 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.
-
- UTF8String::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- The LDAP-specific encoding of a value of this syntax are the UTF-8
- characters themselves.
-
- The following is an LDAP syntax description [RFC2252] suitable for
- publication in the subschema.
-
- ( IANA-ASSIGNED-OID.2 DESC 'UTF8String')
-
-
-4. Matching Rules
-
-
-4.1 changeSequenceNumberMatch Matching Rule
-
- The changeSequenceNumberMatch rule compares an assertion value of the
- ChangeSequenceNumber syntax to a value of a syntax (e.g the
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 3 \f
- LDAP Change Sequence Number
-
- ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
- ChangeSequenceNumber.
-
- The rule evaluates to TRUE if and only if each of the components of
- the two values evaluate to true using the following rules:
- - The time component uses generalizedTimeMatch.
- - The timeCount and changeCount components use integerMatch.
- - The replicaID component uses utf8CodePointMatch.
-
- The following is a LDAP matching rule description [RFC2252] suitable
- for publication in the subschema.
-
- ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch
- SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-4.2 utf8CodePointMatch Matching Rule
-
- The utf8CodePointMatch rule compares an assertion value of the
- UTF8String syntax to a value of a syntax (e.g the UTF8String syntax)
- whose corresponding ASN.1 type is UTF8String. The rule evaluates to
- TRUE if and only if the code points [Unicode] of each of the
- characters is equal.
-
- The following is a LDAP matching rule description [RFC2252] suitable
- for publication in the subschema.
-
- ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch
- SYNTAX IANA-ASSIGNED-OID.2 )
-
-
-4.3 changeSequenceNumberOrderingMatch Matching Rule
-
- The changeSequenceNumberOrderingMatch rule compares the
- ChangeSequenceNumber ordering of an assertion value of the
- ChangeSequenceNumber syntax to a value of a syntax (e.g the
- ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
- ChangeSequenceNumber.
-
- The rule evaluates to TRUE if and only if each of the components of
- the two values evaluate to true using the following rules:
- - The time component uses GeneralizedTimeOrderingMatch.
- - The timeCount and changeCount components use integerOrderingMatch.
- - The replicaID component uses utf8CodePointOrderingMatch.
-
- The following is a LDAP matching rule description [RFC2252] suitable
- for publication in the subschema.
-
- ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch
- SYNTAX SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-4.4 utf8CodePointOrderingMatch Matching Rule
-
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 4 \f
- LDAP Change Sequence Number
-
- The utf8CodePointOrderingMatch rule compares the ordering of an
- assertion value of the UTF8String syntax to a stored value of a
- syntax (e.g the UTF8String syntax) whose corresponding ASN.1 type is
- UTF8String.
-
- The rule evaluates to TRUE if, and only if, in the code point
- collation order, the stored value character string appears earlier
- than the assertion value character string, i.e., the stored value is
- "less than" the assertion value.
-
- The following is a LDAP matching rule description [RFC2252] suitable
- for publication in the subschema.
-
- ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch
- SYNTAX IANA-ASSIGNED-OID.2 )
-
-
-5. Security Considerations
-
-
-6. Acknowledgements
-
-
-7. Normative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [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"
-
- [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
- Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
- progress).
-
- [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt (a work in progress).
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
- : 1993.
-
- [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/).
-
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 5 \f
- LDAP Change Sequence Number
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
-
-8. Informative References
-
-9. IANA Considerations
-
-10. 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 Jun 2004 Page 6 \f
- LDAP Change Sequence Number
-
-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 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 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.
-
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: August 5, 2005 H. Chu
+ Symas Corp.
+ February 2005
+ The LDAP Change Sequence Number
+ draft-sermersheim-ldap-csn-02.txt
-
-Sermersheim Internet-Draft - Expires Jun 2004 Page 7 \f
+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 on August 5, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document defines a syntax schema element for the Lightweight
+ Directory Access Protocol (LDAP) which is used to hold a Change
+ Sequence Number (CSN). In general, a change sequence number
+ represents the place and time that a directory entity was changed.
+ It may be used by various attributes for various LDAP replication,
+ and synchronization applications.
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 1]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+Discussion Forum
+
+ 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(s).
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. ChangeSequenceNumber Syntax . . . . . . . . . . . . . 5
+ 3.2. UTF8String . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. changeSequenceNumberMatch Matching Rule . . . . . . . 7
+ 4.2. utf8CodePointMatch Matching Rule . . . . . . . . . . . 7
+ 4.3. changeSequenceNumberOrderingMatch Matching Rule . . . 7
+ 4.4. utf8CodePointOrderingMatch Matching Rule . . . . . . . 8
+ 5. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.1. entryCSN Attribute . . . . . . . . . . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . 10
+ 7. Normative References . . . . . . . . . . . . . . . . . 10
+ Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 11
+ A.1. LDAP Object Identifier Registrations . . . . . . . . . 11
+ A.2. LDAP Descriptor Registrations . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . 15
+ Intellectual Property and Copyright Statements . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 2]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+1. Introduction
+
+ A number of technologies have been documented, implemented and
+ experimented with which in one way or another seek to replicate, or
+ synchronize directory data. A common need among these technologies
+ is to determine which of two copies of an element represents the
+ latest or most authoritative data. Part of meeting this need
+ involves associating a change sequence number to an element copy at
+ the time of an update to that element. When replication or
+ synchronization occurs, the change sequence numbers associated with
+ directory elements can be used to decide which element's data will be
+ copied to the other element(s).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 3]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+2. Conventions
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+ The General Considerations of [I-D.ietf-ldapbis-syntaxes] apply to
+ the syntax definition in this document.
+
+ The terms "directory element" and "element" refer to data held in a
+ directory and may apply to an attribute value, attribute, entry, or
+ any other identifiable directory entity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 4]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+3. Syntaxes
+
+3.1. ChangeSequenceNumber Syntax
+
+ A value of the ChangeSequenceNumber syntax is the time of a change
+ along with a replicaID which represents the Directory System Agent
+ (DSA) holding the element when it was changed. There are also two
+ sequence numbers used to disambiguate directory entities that are
+ changed at the same time and place.
+
+ The Abstract Syntax Notation One (ASN.1)[X680] type corresponding to
+ this syntax is defined as follows:
+
+ ChangeSequenceNumber ::= SEQUENCE {
+
+ time GeneralizedTime,
+
+ timeCount INTEGER (0 .. MaxInt),
+
+ replicaID UTF8String,
+
+ changeCount INTEGER (0 .. MaxInt)}
+
+ MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ GeneralizedTime is defined in [X680]. Local time without a
+ differential SHALL NOT be used.
+
+ UTF8String is defined below.
+
+ The LDAP-specific encoding of a value of this syntax is the Generic
+ String Encoding Rules (GSER)[RFC3641] encoding of the ASN.1 type.
+
+ Example:
+
+ { time "196701160315-0700",
+
+ timeCount 0,
+
+ replicaID "DSA666",
+
+ changeCount 1 }
+
+ The following is an LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' )
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 5]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+3.2. UTF8String
+
+ The UTF8String syntax is used to express a string of characters from
+ the [ISO.10646-1.1993] character set (a superset of [Unicode]),
+ 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.
+
+ UTF8String::= OCTET STRING -- UTF-8 encoded,
+
+ -- [ISO10646] characters
+
+ The LDAP-specific encoding of a value of this syntax are the UTF-8
+ encoded characters themselves.
+
+ The following is an LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.2 DESC 'UTF8String' )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 6]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+4. Matching Rules
+
+4.1. changeSequenceNumberMatch Matching Rule
+
+ The changeSequenceNumberMatch rule compares an assertion value of the
+ ChangeSequenceNumber syntax to a value of a syntax (e.g the
+ ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
+ ChangeSequenceNumber.
+
+ The rule evaluates to TRUE if and only if each of the components of
+ the two values evaluate to TRUE using the following rules:
+
+ o The time component uses generalizedTimeMatch.
+
+ o The timeCount and changeCount components use integerMatch.
+
+ o The replicaID component uses utf8CodePointMatch.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch SYNTAX IANA-
+ ASSIGNED-OID.1 )
+
+4.2. utf8CodePointMatch Matching Rule
+
+ The utf8CodePointMatch rule compares an assertion value of the
+ UTF8String syntax to a value of a syntax (e.g the UTF8String syntax)
+ whose corresponding ASN.1 type is UTF8String. The rule evaluates to
+ TRUE if and only if the code points [Unicode] of each of the
+ characters is equal.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch SYNTAX IANA-ASSIGNED-
+ OID.2 )
+
+4.3. changeSequenceNumberOrderingMatch Matching Rule
+
+ The changeSequenceNumberOrderingMatch rule compares the
+ ChangeSequenceNumber ordering of an assertion value of the
+ ChangeSequenceNumber syntax to a value of a syntax (e.g the
+ ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
+ ChangeSequenceNumber.
+
+ When evaluating ChangeSequenceNumber values for ordering, the
+ components are evaluated in this order: time, timeCount, replicaID,
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 7]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+ changeCount. If a component evaluates to TRUE using the appropriate
+ ordering matching rule specified below, then the rule evaluates to
+ TRUE. Otherwise if the component evaluates to TRUE using the
+ equality matching rule specified below, the next component is
+ evaluated. Otherwise the changeSequenceNumberOrderingMatch rule
+ evaluates to FALSE or Undefined as appropriate.
+
+ o The time components of the two values are evaluated for ordering
+ using GeneralizedTimeOrderingMatch, and evaluated for equality
+ using GeneralizedTimeMatch.
+
+ o The timeCount and changeCount components of the two values are
+ evaluated for ordering using integerOrderingMatch, and evaluated
+ for equality using integerMatch.
+
+ o The replicaID components of the two values are evaluated for
+ ordering using utf8CodePointOrderingMatch and evaluated for
+ equality using utf8CodePointMatch.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch SYNTAX
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+4.4. utf8CodePointOrderingMatch Matching Rule
+
+ The utf8CodePointOrderingMatch rule compares the ordering of an
+ assertion value of the UTF8String syntax to a stored value of a
+ syntax (e.g. the UTF8String syntax) whose corresponding ASN.1 type is
+ UTF8String.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the stored value character string appears earlier
+ than the assertion value character string, i.e., the stored value is
+ "less than" the assertion value.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch SYNTAX IANA-
+ ASSIGNED-OID.2 )
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 8]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+5. Attributes
+
+5.1. entryCSN Attribute
+
+ The entryCSN operational attribute provides the CSN of the last
+ update applied to the entry.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.7 NAME entryCSN DESC 'CSN of the entry content'
+ EQUALITY changeSequenceNumberMatch ORDERING
+ changeSequenceNumberOrderingMatch SYNTAX IANA-ASSIGNED-OID.1 SINGLE-
+ VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+ Servers MAY assign a CSN to each entry upon its addition to the
+ directory and provide the entry's CSN as the value of the entryCSN
+ operational attribute. If the entryCSN attribute is assigned, the
+ attribute SHOULD be updated upon every update of the entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 9]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+6. Security Considerations
+
+7. Normative References
+
+ [I-D.ietf-ldapbis-syntaxes]
+ Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-11 (work in progress),
+ June 2005.
+
+ [ISO.10646-1.1993]
+ International Organization for Standardization,
+ "Information Technology - Universal Multiple-octet coded
+ Character Set (UCS) - Part 1: Architecture and Basic
+ Multilingual Plane", ISO Standard 10646-1, May 1993.
+
+ [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.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [UTF-8] International Organization for Standardization,
+ "Information Technology - Universal Multiple-octet coded
+ Character Set (UCS) - Amendment 2: UCS Transformation
+ Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
+ October 1996.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard", 2004.
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 10]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+Appendix A. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+A.1. LDAP Object Identifier Registrations
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments:
+
+ Seven delegations will be made under the assigned OID:
+
+ IANA-ASSIGNED-OID.1 ChangeSequenceNumber: LDAP Syntax
+
+ IANA-ASSIGNED-OID.2 UTF8String: LDAP Syntax
+
+ IANA-ASSIGNED-OID.3 changeSequenceNumberMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.4 utf8CodePointMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.5 changeSequenceNumberOrderingMatch: LDAP
+ Matching Rule
+
+ IANA-ASSIGNED-OID.6 utf8CodePointOrderingMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.7 entryCSN: LDAP Attribute Type
+
+A.2. LDAP Descriptor Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 11]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): ChangeSequenceNumber
+
+ Object Identifier: IANA-ASSIGNED-OID.1
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Syntax
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): UTF8String
+
+ Object Identifier: IANA-ASSIGNED-OID.2
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Syntax
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): changeSequenceNumberMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.3
+
+ Person & email address to contact for further information:
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 12]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): utf8CodePointMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.4
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): changeSequenceNumberOrderingMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.5
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 13]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): utf8CodePointOrderingMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.6
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): entryCSN
+
+ Object Identifier: IANA-ASSIGNED-OID.7
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse@novell.com
+
+ Usage: Attribute Type
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Attribute Type
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 14]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ Email: jimse@novell.com
+
+
+ Howard Chu
+ Symas Corp.
+ 18740 Oxnard Street, Suite 313A
+ Tarzana, California 91356
+ USA
+
+ Phone: +1 818 757-7087
+ Email: hyc@symas.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 15]
+\f
+Internet-Draft LDAP CSN February 2005
+
+
+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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 16]
+\f
+
Network Working Group J. Sermersheim
Internet-Draft Novell, Inc
-Expires: April 24, 2005 October 24, 2004
+Expires: August 26, 2005 February 22, 2005
Distributed Procedures for LDAP Operations
- draft-sermersheim-ldap-distproc-01.txt
+ draft-sermersheim-ldap-distproc-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ of Section 3 of RFC 3667. 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
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 24, 2005.
+ This Internet-Draft will expire on August 26, 2005.
Copyright Notice
- Copyright (C) The Internet Society (2004).
+ Copyright (C) The Internet Society (2005).
Abstract
This document provides the data types and procedures used while
- servicing Lightweight Directory Application Protocol (LDAP) user
+ servicing Lightweight Directory Access Protocol (LDAP) user
operations in order to participate in a distributed directory. In
particular, it describes the way in which an LDAP user operation in a
distributed directory environment finds its way to the proper DSA(s)
for servicing.
-Discussion Forum
+Sermersheim Expires August 26, 2005 [Page 1]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 1]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Discussion Forum
+
Technical discussion of this document will take place on the IETF
LDAP Extensions mailing list <ldapext@ietf.org>. Please send
-
-
-Sermersheim Expires April 24, 2005 [Page 2]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 2]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 3]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 3]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 4]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 4]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 5]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 5]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 6]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 6]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 7]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 7]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 8]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 8]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 9]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 9]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 10]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 10]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 11]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 11]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 12]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 12]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 13]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 13]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 14]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 14]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 15]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 15]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 16]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 16]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
Note that due to alias dereferencing, the search scope may expand to
include entries outside of the scope originally specified in the
- search operation.
+ search operation. {TODO: note that an aliased object may be glue
+ which needs to result in any subr or xr above it to be found}
Nssr Note: A DSE of type nssr is only considered to be found
-
-Sermersheim Expires April 24, 2005 [Page 17]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 17]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 18]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 18]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 19]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 19]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 20]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 20]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 21]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 21]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 22]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 22]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 23]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 23]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 24]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 24]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 25]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 25]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 26]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 26]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 27]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 27]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 28]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 28]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 29]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 29]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 30]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 30]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 31]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 31]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 32]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 32]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
This document introduces the ability to return auxiliary data when
returning referrals. Measures should be taken to ensure proper
- protection of this data.
+ protection of his data.
Implementers must ensure that any specified time, size, and
introduced here.
-6 Normative References
+6. Normative References
[LDAP-SUBORD]
Sermersheim, J., "Subordinate Subtree Search Scope for
- LDAP", draft-sermersheim-ldap-subordinate-scope-xx (work
- in progress), July 2004.
+ LDAP",
+ Internet-Draft draft-sermersheim-ldap-subordinate-scope,
+ July 2004.
[RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
-
-Sermersheim Expires April 24, 2005 [Page 33]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 33]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
[RFC3771] Harrison, R. and K. Zeilenga, "The Lightweight Directory
- Access Protocol (LDAP) Intermediate Response Message", RFC
- 3771, April 2004.
+ Access Protocol (LDAP) Intermediate Response Message",
+ RFC 3771, April 2004.
[X500] International Telephone and Telegraph Consultative
Phone: +1 801 861-3088
- EMail: jimse@novell.com
+ Email: jimse@novell.com
-Sermersheim Expires April 24, 2005 [Page 34]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 34]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 35]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 35]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 36]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 36]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 37]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 37]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
-Sermersheim Expires April 24, 2005 [Page 38]
-Internet-Draft Distributed Procedures for LDAP OperationsOctober 2004
+Sermersheim Expires August 26, 2005 [Page 38]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
Copyright Statement
- Copyright (C) The Internet Society (2004). This document is subject
+ 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.
-Sermersheim Expires April 24, 2005 [Page 39]
\ No newline at end of file
+Sermersheim Expires August 26, 2005 [Page 39]
\ No newline at end of file
INTERNET-DRAFT Rob Weltman
-Intended Category: Standards Track Netscape Communications Corp.
- April 2003
+Intended Category: Standards Track Yahoo!, Inc.
+ June 2005
LDAP Proxied Authorization Control
- draft-weltman-ldapv3-proxy-12.txt
+ draft-weltman-ldapv3-proxy-13.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
- Internet-Drafts are working documents of the Internet Task Force
- (IETF), its areas, and its working groups. Note that other groups
- may also distribute working documents as Internet-Drafts.
+ 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
+ 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
+ http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ http://www.ietf.org/shadow.html
Abstract
identity distinct from the authentication identity, where the
authorization identity applies to the whole LDAP session. The Proxy
Authorization Control provides a mechanism for specifying an
- authorization identity on a per operation basis, benefiting clients
- that need to efficiently perform operations on behalf of multiple
- users.
-
-Expires October 2003 [Page 1]
+Expires December 2005 [Page 1]
\f
-PROXIED AUTHORIZATION CONTROL April 2003
+PROXIED AUTHORIZATION CONTROL June 2005
+ authorization identity on a per operation basis, benefiting clients
+ that need to efficiently perform operations on behalf of multiple
+ users.
+
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
used in this document are to be interpreted as described in
[KEYWORDS].
protects clients from submitting a request that is executed with an
unintended authorization identity.
+ Clients MUST include the criticality flag and MUST set it to TRUE.
+ Servers MUST reject any request containing a Proxy Authorization
+ Control without a criticality flag or with the flag set to FALSE with
+ a protocolError error. These requirements protect clients from
+ submitting a request that is executed with an unintended
+ authorization identity.
+
The controlValue SHALL be present and contain either an authzId
[AUTH] representing the authorization identity for the request or
empty if an anonymous association is to be used.
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
+
+Expires December 2005 [Page 2]
+\f
+PROXIED AUTHORIZATION CONTROL June 2005
+
+
4. Implementation Considerations
requester does not have the right to assume the requested identity
for searching the entry, even if the entry is within the scope of a
search request under a base DN which does imply such rights. This
-
-Expires October 2003 [Page 2]
-\f
-PROXIED AUTHORIZATION CONTROL April 2003
-
-
means that fewer results, or no results, may be returned compared to
the case where the proxy authorization identity issued the request
directly. An example of such a case may be a system with fine-grained
7. Copyright
- Copyright (C) The Internet Society (date). All Rights Reserved.
+ 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.
+
+
+Expires December 2005 [Page 3]
+\f
+PROXIED AUTHORIZATION CONTROL June 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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
English.
The limited permissions granted above are perpetual and will not be
-
-Expires October 2003 [Page 3]
-\f
-PROXIED AUTHORIZATION CONTROL April 2003
-
-
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.
-
8. Normative References
[RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997
+
+Expires December 2005 [Page 4]
+\f
+PROXIED AUTHORIZATION CONTROL June 2005
+
+
[RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000
9. Author's Address
Rob Weltman
- Netscape Communications Corp.
- 360 W. Caribbean Drive
+ Yahoo!, Inc
+ 701 First Avenue
Sunnyvale, CA 94089
USA
-
-
-Expires October 2003 [Page 4]
-\f
-PROXIED AUTHORIZATION CONTROL April 2003
-
-
- +1 650 937-3194
- rweltman@netscape.com
+ +1 408 349-5504
+ robw@worldspot.com
10. Acknowledgements
- Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
- Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
- Sermersheim of Novell, and Steven Legg of Adacel have contributed
- with reviews of this document.
+ Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
+ formerly of Sun Microsystems, Inc, Kurt Zeilenga of OpenLDAP
+ Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
+ contributed with reviews of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires October 2003 [Page 5]
+Expires December 2005 [Page 5]
\f
\ No newline at end of file
+
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
-Expires in six months 18 July 2004
+Expires in six months 18 July 2005
+
Requesting Attributes by Object Class in the
Lightweight Directory Access Protocol
- <draft-zeilenga-ldap-adlist-08.txt>
+ <draft-zeilenga-ldap-adlist-11.txt>
Status of this Memo
<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.
+ 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
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>.
+ 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.
+
+ 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
- The Lightweight Directory Access Protocol (LDAP) search operation
Zeilenga Requesting Attributes by Object Class [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+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
- belonging to an object class.
+ that LDAP clients may use to request the return of all attributes of
+ an object class.
-1. Overview
+1. Background and Intended Use
- In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
- search operation [RFC2251] support requesting a sets of attributes.
- This set is determined by a list of attribute descriptions. Two
- special descriptors are defined to request all user attributes ("*")
- [RFC2251] and all operational attributes ("+") [RFC3673]. However,
- there is no convenient mechanism for requesting pre-defined sets of
- attributes.
+ 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
For example, the attribute list of "@country" is equivalent to the
attribute list of 'c', 'searchGuide', 'description', and
- 'objectClass'. This object class and its attributes are described in
- [RFC2256].
-
- This extension is intended to be used where the user is in direct
- control of the parameters of the LDAP search operation, such as when
- entering a LDAP URL [RFC2255] into a web browser.
+ '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
3. Return of all Attributes of an Object Class
- This extension allows object class identifiers is to be provided in
- the attributes field of the LDAP SearchRequest [RFC2251] or other
- request structures who borrow the attributes field and its semantics
Zeilenga Requesting Attributes by Object Class [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
-
-
- (e.g., attributes field in pre/post read controls [READENTRY]). 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) was itself listed.
-
- If the object class identifier is unrecognized, it is be treated an an
- unrecognized attribute description.
-
- This extension redefines the attributes field of the SearchRequest to
- be a DescriptionList described by the following ASN.1 [X.680] data
- type:
-
- DescriptionList ::= SEQUENCE OF Description
- Description ::= LDAPString
-
- The Description is string conforming to the ABNF [RFC2234]:
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
- Description = AttributeDescription | ObjectClassDescription.
- ObjectClassDescription = AtSign ObjectClass *( ";" options )
- AtSign = "@" ; U+0040
- where <AttributeDescription> and <options> productions are as defined
- in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
- identifier, in either <numericoid> or <descr> form [RFC2252], of an
- object class.
-
- <ObjectClassDescription> <options> are provided for extensibility.
- This document only defines semantics of <ObjectClassDescription>s with
- zero options in the attributes field of a SearchRequest. Other uses
- may be defined in future specifications.
+ 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) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
- [RFC3674] attribute in the root DSE. Clients supporting this feature
+ (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.
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
- individually, this shorthand is not believed to raise additional
- security considerations.
-
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP security considerations [RFC3377].
+ 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-08 18 July 2004
+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 [RFC3383] defined in
+ Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
document is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Email: Kurt@OpenLDAP.org
-6. Normative References
+6. References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
+6.1. Normative References
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
+ work in progress.
- [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
Zeilenga Requesting Attributes by Object Class [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
- December 2003.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-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).
+ [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.
-7. Informative References
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
- [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
- December, 1997.
+ [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).
- [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.
+6.2. Informative References
[RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
3673, December 2003.
- [READENTRY] Zeilenga, K., "LDAP Read Entry Controls",
+ [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.
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.
+ 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
-
-Zeilenga Requesting Attributes by Object Class [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-08 18 July 2004
-
-
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Zeilenga Requesting Attributes by Object Class [Page 6]
\f
-
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 July 2004
+Expires in six months 10 February 2005
+
The LDAP Assertion Control
- <draft-zeilenga-ldap-assert-03.txt>
+ <draft-zeilenga-ldap-assert-05.txt>
Status of this Memo
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>.
+ 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.
+
+ 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
- This document defines the Lightweight Directory Access Protocol (LDAP)
- Assertion Control which allows a client to specify that a directory
Zeilenga LDAP Assertion Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+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)
- [RFC3377] assertion control. The assertion control allows the client
+ [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.
+ 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 can be used with the Modify operation [RFC2251] to perform
- atomic "test and set" and "test and clear" operations as the asserted
- condition is evaluated as an integral part the operation. The control
- may be attached to other update operations to support conditional
- addition, deletion, and renaming of objects.
+ 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
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].
+ Section 5.2 of [Protocol].
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
3. The Assertion Control
- The assertion control is an LDAP Control [RFC2251] whose controlType
- is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
- [RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
- There is no corresponding response control.
-
Zeilenga LDAP Assertion Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+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 [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
+ operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
- Unbind operations. It is also inappropriate for the Start TLS
- [RFC2830] operation.
+ 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
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
- [RFC2251]. Hence, no entries or continuations references are returned
- if the assertion fails.
+ [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 [RFC2252] in their root DSE. A server
- MAY choose to advertise this extension only when the client is
- authorized to use it.
+ '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
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
Zeilenga LDAP Assertion Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+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.
- All security considerations for the base operations [RFC2251] to which
- this control is attached to apply, as do general LDAP security
- considerations [RFC3377].
+ 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 [RFC3383] to identify the LDAP Assertion Control defined in
- this document.
+ 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:
5.2 LDAP Protocol Mechanism
- Registration of this protocol mechanism [RFC3383] is requested.
+ Registration of this protocol mechanism [BCP64bis] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
5.3 LDAP Result Code
- Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
+ Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
is requested.
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: assertionFailed
-
Zeilenga LDAP Assertion Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+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
Email: Kurt@OpenLDAP.org
-8. Normative References
+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.
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
-9. Informative References
+8.2. Informative References
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-Intellectual Property Rights
+Zeilenga LDAP Assertion Control [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
- 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
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-Zeilenga LDAP Assertion Control [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-03 18 July 2004
+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
Full Copyright
- Copyright (C) The Internet Society (2004). This document is subject
+ 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 Assertion Control [Page 6]
\f
-
-
-
-
-
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 November 2002
+Expires in six months 19 November 2004
LDAP "Who am I?" Operation
- <draft-zeilenga-ldap-authzid-08.txt>
+ <draft-zeilenga-ldap-authzid-10.txt>
Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
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 Extension Working Group
- mailing list <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
+ 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
+ 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.''
+ 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
+ <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 2002, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
- Please see the Copyright section near the end of this document for
- more information.
+ Please see the Full Copyright section near the end of this document
+ for more information.
Abstract
This specification provides a mechanism for Lightweight Directory
- 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.
Zeilenga LDAP "Who am I?" [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
+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
associated with the user or application entity. The operation is
called the "Who am I?" operation.
- This specification is intended to replace the existing [AUTHCTL]
+ 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 they are
- transferred as part of. 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.
+ 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
- [PROXYCTL] to determine the authorization identity which the server
+ [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.
authzId", respectively.
-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
-
Zeilenga LDAP "Who am I?" [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
+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"
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:kurt@OPENLDAP.ORG" (in response to the example request)
+ 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 6b 75 72 74 40 4f 50 45 4e 4c 44 41 50 2e
- 4f 52 47
+ 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
+ 4e 45 54
3. Operational Semantics
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
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
-
-
-
-Zeilenga LDAP "Who am I?" [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
-
-
operationsError, protocolError, confidentialityRequired,
insufficientAccessRights, busy, unavailable, unwillingToPerform, or
other) and an absent response field.
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.
+ 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
4.1. Proxied Authorization Control
- The Proxied Authorization Control [PROXYCTL] is used by clients to
+ 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
[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
- [PROXYCTL] use.]]
+ [PROXYAUTH] use.]]
5. Security Considerations
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
-
-
-
-Zeilenga LDAP "Who am I?" [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
-
-
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.
+ 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
- This OID 1.3.6.1.4.1.4203.1.11.3 to identify the LDAP "Who Am I?
- extended operation. This OID was assigned [ASSIGN] by OpenLDAP
+ 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 mechansism is requested [RFC3383].
-
- Subject: Request for LDAP Protocol Mechansism Registration
+ 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: RFCxxxx
-
+ Specification: RFC XXXX
Author/Change Controller: IESG
-
Comments: none
7. Acknowledgment
This document borrows from prior work in this area including
- "Authentication Response Control" [AUTHCTL] 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.
+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.
-Zeilenga LDAP "Who am I?" [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
+ 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
- <Kurt@OpenLDAP.org>
+ Email: Kurt@OpenLDAP.org
-9. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+9. References
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
- [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
- "Authentication Methods for LDAP", RFC 2829, June 2000.
- [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
+9.1. Normative References
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
- weltman-ldapv3-proxy-xx.txt (a work in progress).
+ [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.
-10. Informative References
+ [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
+ [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
+ draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
- [AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
- Response Control", draft-weltman-ldapv3-auth-response-
- xx.txt (a work in progress).
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
+9.2. Informative References
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
-Copyright 2002, The Internet Society. All Rights Reserved.
+Zeilenga LDAP "Who am I?" [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-Zeilenga LDAP "Who am I?" [Page 6]
+ (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-08 1 November 2002
-
-
- 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 AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+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 7]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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: Standard Track OpenLDAP Foundation
+Expires in six months 17 July 2005
+
+
+
+ The LDAP Don't Use Copy Control
+ <draft-zeilenga-ldap-dontusecopy-01.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, 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 LDAP Don't Use Copy Control [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Don't Use Copy control extension which allows a client to specify that
+ copied information should not be used in providing service. This
+ control is based upon the X.511 dontUseCopy service control option.
+
+
+1. Background and Intended Usage
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap] Don't Use Copy control extension. The control may be
+ attached to request messages to indicate that copied (replicated or
+ cached) information [X.500] should not be used in providing service.
+ This control is based upon the X.511 [X.511] dontUseCopy service
+ control option.
+
+ The Don't Use Copy control is intended to be used where the client
+ requires the service be provided using original (master) information
+ [X.500].
+
+
+2. Terminology
+
+ 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 Don't Use Copy Control
+
+ The Don't Use Copy control is an LDAP Control [Protocol] whose
+ controlType is IANA-ASSIGNED-OID and controlValue is absent. The
+ criticality may be TRUE or FALSE. There is no corresponding response
+ control.
+
+ The control is appropriate for both LDAP interrogation operations,
+ including Compare and Search operations [Protocol]. It is
+ inappropriate for all other operations, including Abandon, Bind,
+ Delete, Modify, ModifyDN, StartTLS, and Unbind operations [Protocol].
+
+ When the control is attached to an LDAP request, the requested
+ operation MUST NOT be performed on copied information. That is, the
+ requested operation MUST be performed on original information.
+
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+
+
+ If original information for the target or base object of the operation
+ is not available (either locally or through chaining), the server MUST
+ either return a referral directing the client to a server believed to
+ be better able to service the request or return an appropriate result
+ code (e.g., unwillingToPerform).
+
+
+4. Security Considerations
+
+ This control is intended to be provided where providing service using
+ copied information might lead to unexpected application behavior.
+ Designers of directory applications should consider where it is
+ appropriate for clients to provide this control. Designers should
+ consider whether use of copied information, in particular security and
+ policy information, may result insecure behavior.
+
+ 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 Don't Use Copy 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 Don't Use Copy 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: Don't Use Copy Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+
+
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+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.
+
+ [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
+
+ [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).
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 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 Don't Use Copy Control [Page 5]
+\f
+
+
+
+
+
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 17 October 2004
+Expires in six months 10 February 2005
+
LDAP Modify-Increment Extension
- <draft-zeilenga-ldap-incr-00.txt>
+ <draft-zeilenga-ldap-incr-01.txt>
Status of this Memo
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>.
+ 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.
+ 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
- This document describes an extension to the Lightweight Directory
- Access Protocol (LDAP) Modify operation to support an increment
Zeilenga LDAP Modify-Increment Extension [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
+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 Lightwieght Directory Access Protocol [Roadmap] does not currently
+ 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
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 be used with the LDAP assertion control
- [ASSERT] to provide test-and-increment functionality.
+ [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
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 request, e.g., must have INTEGER or
- other incrementable values, and the modification must provide one and
- only value.
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) OID-TBD 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.
-
+ 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-00.txt 17 October 2004
+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
5. IANA Considerations
- Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
- document is requested.
+ 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: OID-TBD
+ Object Identifier: IANA-ASSIGNED-OID
Description: Modify-Increment
Person & email address to contact for further information:
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.
-
-Zeilenga LDAP Modify-Increment Extension [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
+ 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@OpenLDAP.org>
-7. Normative References
+
+
+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.
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-8. Informative References
+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",
+ [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
draft-zeilenga-ldap-readentry-xx.txt, a work in
progress.
- [ASSERT] Zeilenga, K., "LDAP Assertion Control",
+ [Assertion] Zeilenga, K., "LDAP Assertion Control",
draft-zeilenga-ldap-assert-xx.txt, a work in progress.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
-Zeilenga LDAP Modify-Increment Extension [Page 4]
+Zeilenga LDAP Modify-Increment Extension [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-incr-00.txt 17 October 2004
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
Intellectual Property Rights
Full Copyright
- Copyright (C) The Internet Society (2004). This document is subject
+ 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 Modify-Increment Extension [Page 5]
+Zeilenga LDAP Modify-Increment Extension [Page 6]
\f
+
+
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
+Expires in six months 28 October 2005
The LDAP No-Op Control
- <draft-zeilenga-ldap-noop-06.txt>
+ <draft-zeilenga-ldap-noop-07.txt>
Status of this Memo
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.
+ 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
+
Zeilenga LDAP No-Op Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Abstract
[Roadmap] No-Op control extension. The presence of the No-Op control
in an operation request message disables its normal effect upon the
directory which operation would otherwise have. Instead of updating
- the directory and return the normal indication of success, the server
- does not update the directory and indicates so by returning the
+ the directory and returning the normal indication of success, the
+ server does not update the directory and indicates so by returning the
noOperation resultCode (introduced below).
For example, when the No-Op control is present in a LDAP modify
Zeilenga LDAP No-Op Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
2. No-Op Control
reason indicated by the result code. A result code of noOperation
(IANA-ASSIGNED-CODE) indicates that the server discovered no reason
why the operation would fail if submitted without the No-Op control.
+ It is noted that there may be reasons why the operation may fail which
+ are only discoverable when submitting without the No-Op control.
Servers SHOULD indicate their support for this control by providing
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
[Roadmap].
-4. IANA Considerations
-
Zeilenga LDAP No-Op Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+4. IANA Considerations
+
4.1. Object Identifier
It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
Kurt D. Zeilenga
OpenLDAP Foundation
- Email: Kurt@OpenLDAP.org
-
Zeilenga LDAP No-Op Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+
+
+ Email: Kurt@OpenLDAP.org
6. References
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
Zeilenga LDAP No-Op Control [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-06 10 February 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+ 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
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.
+ 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
-
-
-
-
-
Zeilenga LDAP No-Op Control [Page 6]
\f
-
-
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 26 October 2003
+Expires in six months 10 February 2005
+
LDAP Read Entry Controls
- <draft-zeilenga-ldap-readentry-01.txt>
+ <draft-zeilenga-ldap-readentry-04.txt>
1. Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
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
<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
+ 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.''
+ 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>.
+ http://www.ietf.org/1id-abstracts.html
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Please see the Full Copyright section near the end of this document
- for more information.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
-Abstract
+ Please see the Full Copyright section near the end of this document
+ for more information.
- This specification describes controls which can be attached to a
- Lightweight Directory Access Protocol (LDAP) update request to obtain
- copies of the target entry before and/or after the requested update is
- applied.
Zeilenga LDAP Read Entry Controls [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+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 specification describes controls [RFC2251] which can be attached
- to Lightweight Directory Access Protocol (LDAP) [RFC3377] update
- requests to request and return copies of the target entry. One
+ 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
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].
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'
- [RFC2252] attributes, updated by the server as part of the update
+ attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
+ [Models] attributes, updated by the server as part of the update
operation.
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].
+ 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].
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' [RFC2252] in their root DSE.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
-
+ 'supportedControl' [Models] in their root DSE.
- The Pre-Read request control is an LDAP Control [RFC2251] whose
- controlType is IANA-ASSIGNED-OID.1 and controlValue is a BER-encoded
- AttributeDescriptionList [RFC2251]. The criticality may be TRUE or
- FALSE. This control is appropriate for the modifyRequest, delRequest,
- and modDNRequest LDAP messages.
+ 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 the controlValue, an OCTET STRING, contains
- a BER-encoded SearchResultEntry. The criticality may be TRUE or
- FALSE. This control is appropriate for the modifyResponse,
+ 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 AttributeDescriptionList
- indicates which attributes are requested to appear in the copy. There
- are two special AttributeDescriptions which may be included in the
- list, "*" and "+". "*" requests all user attributes. "+" requests
- all operational attributes. If the list is empty, all user attributes
- are requested. If the list contains an unrecognized attribute type,
- that type is simply ignored. If all attribute types are unrecognized,
- no attributes are to be returned. The server is to return a
+ 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.
this control MUST be performed as one atomic action isolated from
other update operations.
- If the update operation fails, no response control is provided.
+ 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
- 'supportedControl' [RFC2252] in their root DSE.
-
- The Post-Read request control is an LDAP Control [RFC2251] whose
- controlType is IANA-ASSIGNED-OID.2 and controlValue, an OCTET STRING,
- contains a BER-encoded AttributeDescriptionList [RFC2251]. 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 controlValue is a BER-encoded
Zeilenga LDAP Read Entry Controls [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+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 AttributeDescriptionList
- indicates which attributes are requested to appear in the copy. There
- are two special AttributeDescriptions which may be included in the
- list, "*" and "+". "*" requests all user attributes. "+" requests
- all operational attributes. If the list is empty, all user attributes
- are requested. If the list contains an unrecognized attribute type,
- that type is simply ignored. If all attribute types are unrecognized,
- no attributes are to be returned. The server is to return a
+ 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.
this control MUST be performed as one atomic action isolated from
other update operations.
- If the update operation fails, no response control is provided.
+ If the update operation fails (in either normal or control
+ processing), no response control is provided.
4. Interaction with other controls
- The Pre- and Post-Read controls may be combined with each other and/or
- with a variety of other controls. When combined with the assertion
- control [ASSERT], the manageDsaIT control [RFC3296], and/or the proxy
- authorization control [PROXYAUTH], the semantics of each control
- included in the combination apply. The Pre- and Post-Read controls
- may be combined with other controls as detailed in other technical
- specifications.
+ 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
control in addition to ensuring the client is authorized to perform
the requested directory update.
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP security considerations [RFC3377].
-6. IANA Considerations
+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
-Zeilenga LDAP Read Entry Controls [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+6. IANA Considerations
- Registration of the following protocol values [RFC3383] is requested.
+ Registration of the following protocol values [BCP64bis] is requested.
6.1. Object Identifier
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
- Comments: none
- in 2
-7. Acknowledgment
- The LDAP Pre- and Post-Read controls are modeled after similar
+Zeilenga LDAP Read Entry Controls [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+ Comments: none
-Zeilenga LDAP Read Entry Controls [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+7. Acknowledgment
+
+ The LDAP Pre-Read and Post-Read controls are modeled after similar
+ capabilities offered in the DAP [X.511].
+
+8. References
- capabilities offered in the DAP [X.511].
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
-8. Normative References
+8.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.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
- Directory Access Protocol (v3): Extension for Transport
- Layer Security", RFC 2830, May 2000.
+ [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.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 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
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).
-
- [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", draft-
- weltman-ldapv3-proxy-xx.txt, a work in progress.
-
- [ASSERT] Zeilenga, K., "LDAP Assertion Control",
- draft-zeilenga-ldap-assert-xx.txt, a work in progress.
-
-
-9. Informative References
-
Zeilenga LDAP Read Entry Controls [Page 6]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-01 26 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
+ 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).
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993).
+
+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
- <Kurt@OpenLDAP.org>
+
+ Email: Kurt@OpenLDAP.org
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
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ 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-01 26 October 2003
-
-
- 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 implmentation 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.
-
-
+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
+
+
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 25 October 2003
+Expires in six months 10 February 2005
LDAP Absolute True and False Filters
- <draft-zeilenga-ldap-t-f-07.txt>
+ <draft-zeilenga-ldap-t-f-10.txt>
Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
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
<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
+ 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.''
+ 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>.
+ 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 (2003). All Rights Reserved.
+ 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)
these filters.
-
-Zeilenga LDAP True & False Filters [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
-
-
1. Background
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
elements in 'and' and 'or' filter sets, the LDAPv2 string
- representation [RFC1960] could not represent empty 'and' and 'or'
- filter sets. Due to this, absolute True or False filters were
- (unfortunately) eliminated from LDAPv3 [RFC3377].
+ 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
- matches by allowing empty 'and' and 'or' in Search filters [RFC2251]
- and extends the filter string representation [RFC2254] to allow empty
- filter lists.
+ 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].
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
- (OID) 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
- [FEATURES] attribute in the root DSE.
+ 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.
-
-
-
-Zeilenga LDAP True & False Filters [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
-
-
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 [RFC3377].
+ general LDAPv3 security considerations [Roadmap].
4. IANA Considerations
- The OID 1.3.6.1.4.1.4203.1.5.3 identifies the feature described above.
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in this
- specification.
-
- Registration of this feature is requested [FEATURES][RFC3383].
+ 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: T/F Filters
+ Description: True/False filters
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
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@OpenLDAP.org>
-6. Normative References
+6. 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.
- [RFC2254] Howes, T., "A String Representation of LDAP Search
- Filters", RFC 2254, December 1997.
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+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.]]
-Zeilenga LDAP True & False Filters [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
+6.1. Normative References
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [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",
- draft-zeilenga-ldap-features-xx.txt, a work in progress.
+ [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
+ December 2003.
-7. Informative References
+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.
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
+ [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
-- 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.
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
+ 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 True & False Filters [Page 4]
+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-07.txt 25 October 2003
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
- 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.
+ 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.
- 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
- 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 implmentation 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 True & False Filters [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP True & False Filters [Page 6]
\f
+
+
-INTERNET-DRAFT Kurt D. Zeilenga
+
+INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 8 February 2004
+Expires in six months 28 October 2005
LDAP Turn Operation
- <draft-zeilenga-ldap-turn-00.txt>
+ <draft-zeilenga-ldap-turn-03.txt>
1. Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
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.
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
+ 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.''
+ 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>.
+ http://www.ietf.org/1id-abstracts.html
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ 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
- 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.
-
-
Zeilenga LDAP Turn Op [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+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) [RFC3377] 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.
+ 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 requiring designing new authentication and other
- security features to support server-initiated LDAP sessions.
+ sessions, this would require the design of new authentication and
+ other security mechanisms to support server-initiated LDAP sessions.
- This document instead 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 be server
- (after reversal).
+ 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 which desire to issue, as LDAP clients, operations
- against the other. This may be useful in replicated environments.
+ 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 used between protocol peers which have
- established a mutual agreement, by means outside of the protocol,
- which requires reversal of client / server roles or both peers to act
- both as client and server.
+ 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.1 of [RFC2251].
-
- 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].
+ Section 5.2 of [Protocol].
2. Turn Operation
- The Turn operation is defined as a LDAP Extended Operation [RFC2251,
- 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
Zeilenga LDAP Turn Op [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
- able to act both as client and server.
+ 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
turnValue ::= SEQUENCE {
mutual BOOLEAN DEFAULT FALSE,
- identifier LDAPString,
+ identifier LDAPString
}
- A TRUE value of the mutual field indicates a request to allow both
- peers to act both as client and server while a FALSE value indicates a
+ 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 (typicallly associated with a mutual agreement for which
- this turn is be executed as part of). This policy identifier is
- called the turn indicator.
+ 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
- response 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.
+ 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. Security Considerations
+3. Authentication
- It is generally recommended that before issuing the Turn operation the
- protocol peers:
+ 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.
- - establish each other identities through appropriate authentication
- mechanism,
- - establish appropriate data integrity, data confidentiality, and
- other protections,
- - establish an LDAP association between the initiating peer and the
- responding peer.
+ 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.
- And upon successful completion of turn:
- - establish an LDAP association in reverse.
- That is, for peer A connecting to peer B listening and where TLS and
+Zeilenga LDAP Turn Op [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-Zeilenga LDAP Turn Op [Page 3]
+ 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-00 8 February 2004
+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.
- SASL/EXTERNAL were to be used, the sequence of operations would be:
+5. Security Considerations
- A->B: StartTLS
- A->B: Bind(SASL,EXTERNAL)
- A->B: Turn
- B->A: Bind(SASL,EXTERNAL)
+ 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.
-4. IANA Considerations
+ 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.
- Registration of the following values [RFC3383] is requested.
+ 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.
-4.1. Object Identifier
+
+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.
Identifies the LDAP Turn Operation
-4.2. LDAP Protocol Mechanism
+6.2. LDAP Protocol Mechanism
It is requested that IANA register the LDAP Protocol Mechanism
described in this document.
Comments: none
-5. Normative References
+7. Author's Address
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ Email: Kurt@OpenLDAP.org
+8. References
-Zeilenga LDAP Turn Op [Page 4]
+ [[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-00 8 February 2004
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
+8.1. Normative References
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [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(1997) (also ISO/IEC 8824-1:1998).
+ 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(1997) (also ISO/IEC
- 8825-1:1998).
+ Encoding Rules (DER)", X.690(2002) (also ISO/IEC
+ 8825-1:2002).
-6. Informative References
+8.2. Informative References
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
+ [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.
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
+ [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.
-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
-
-Zeilenga LDAP Turn Op [Page 5]
+Zeilenga LDAP Turn Op [Page 8]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-turn-00 8 February 2004
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+Intellectual Property Rights
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
+ 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 which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
+ 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). 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.
+ 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 6]
+Zeilenga LDAP Turn Op [Page 9]
\f
-\r
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 25 October 2003
+Expires in six months 18 July 2005
+
The LDAP entryUUID operational attribute
- <draft-zeilenga-ldap-uuid-02.txt>
+ <draft-zeilenga-ldap-uuid-06.txt>
-Status of this Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
+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.
<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
+ 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.''
+ 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>.
+ 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 (2003). All Rights Reserved.
+
+ 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
after renaming.
-
-Zeilenga draft-zeilenga-ldap-uuid-02 [Page 1]
-\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
-
-
1. Background and Intended Use
In X.500 Directory Services [X.501], such as those accessible using
- the the Lightweight Directory Access Protocol (LDAP) [RFC3377], 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.
+ 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 Universally Unique Identifier (UUID) [ISO11578] assigned to
- the object by the server. Clients may use this attribute to
- distinguish objects identified by a distinguished name or to locate an
- object after renaming.
+ 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, the 'entryUUID' attribute type.
+ '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].
- Schema definitions are provided using LDAP description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped) for
- readability.
-
2. UUID Schema Elements
2.1 UUID Syntax
- A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet
- (128-bit) value which identifies an object. The ASN.1 [X.690] type
- UUID is defined to represent UUIDs.
+ 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 [ISO 11578]
+ -- constrained to an UUID [UUIDURN]
- In LDAP, values of the UUID type are encoded using the [ASCII]
- character string representation described in [ISO11578]. For example,
- "597ae2f6-16a6-1027-98f4-d28b5365dc14".
- The following is a LDAP syntax description [RFC2252] suitable for
- publication in the subschema.
-
- ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
+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.
-Zeilenga draft-zeilenga-ldap-uuid-02 [Page 2]
-\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
+ ( 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][RFC2252] 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
+ 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 [RFC2252] suitable
- for publication in the subschema.
+ 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 )
The 'uuidOrderingMatch' matching rule compares an asserted UUID
with a stored UUID for ordering. Its semantics are the same as the
- octetStringOrderingMatch [X.520][RFC2252] 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.
+ '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 [RFC2252] suitable
- for publication in the subschema.
+ The following is a LDAP matching rule description suitable for
+ publication in subschema subentries.
- ( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
+ ( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
It is noted that not all UUID variants have a defined ordering and,
2.4. 'entryUUID' attribute
- The 'entryUUID' operational attribute provides the Universally Unique
- Identifier (UUID) [ISO11578] assigned to the entry.
- The following is a LDAP attribute type description [RFC2252] suitable
- for publication in the subschema.
- ( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
- DESC 'UUID of the entry'
- EQUALITY uuidMatch
- ORDERING uuidOrderingMatch
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
+\f
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
-Zeilenga draft-zeilenga-ldap-uuid-02 [Page 3]
-\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
+ 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 assign a UUID to each entry upon its addition to the
- directory and provide the entry's UUID as the value of the
+ 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
- Servers should ensure that components of UUID values are publicly
- disclosable.
+ 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
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier for use in this technical specification.
+
+
+
+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:
Identifies the UUID schema elements
-4.2. Registration of the uuidMatch descriptor
+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
- It is requested that IANA register upon Standards Action the LDAP
- 'uuidMatch' descriptor.
+
+4.3. 'uuidMatch' Descriptor Registration
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidMatch
Author/Change Controller: IESG
-
-
-Zeilenga draft-zeilenga-ldap-uuid-02 [Page 4]
-\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
-
-
-4.3. Registration of the uuidOrderingMatch descriptor
-
- It is requested that IANA register upon Standards Action the LDAP
- 'uuidOrderingMatch' descriptor.
+4.3. 'uuidOrderingMatch' Descriptor Registration
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidOrderingMatch
Author/Change Controller: IESG
-4.4. Registration of the entryUUID descriptor
+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.
Author/Change Controller: IESG
-5. Acknowledgments
+6. Acknowledgments
This document is based upon discussions in the LDAP Update and
- Duplication Protocols (LDUP) WG. Members of the concluded LDAP
- Extensions (LDAPEXT) Working Group provided review.
+ Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
+ provided review.
-6. Author's Address
+7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+
+ 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.]]
-7. Normative References
+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-02 [Page 5]
-\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
+\f
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, 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.
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
- [ISO11578] International Organization for Standardization,
- "Information technology - Open Systems Interconnection -
- Remote Procedure Call", ISO/IEC 11578:1996.
+ [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.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).
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
-8. Informative References
+8.2. Informative References
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
- [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.
+ [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-02 [Page 6]
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
\f
-INTERNET-DRAFT LDAP entryUUID 25 October 2003
-
-
- 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.
+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 which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
+ 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 (2003). All Rights Reserved.
+ 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 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 implmentation 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 draft-zeilenga-ldap-uuid-02 [Page 7]
+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: Standard Track OpenLDAP Foundation
-Expires in six months 17 October 2004
-Obsoletes: RFC 2252, RFC 2256
-
-
- LDAP X.509 Certificate Schema
- <draft-zeilenga-ldap-x509-00.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] when, in conjunction with this document,
- obsoletes RFC 2252 and RFC 2256 in their entirety.
-
- 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.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 1]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-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 schema definitions 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 made since RFC 2252 and RFC 2256
- include:
- - addition of pkiUser, pkiCA, and deltaCRL classes;
- - updated 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.
-
- 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.
-
-
-2. Syntaxes
-
- This section describes various syntaxes used to transfer certificates
- and related data types in LDAP.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 2]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-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 [Section 7, X.509].
-
- Due to changes made to the ASN.1 definition of a Certificate made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax are to 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 "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 [Section 7.3,
- X.509].
-
- Due to changes made to the ASN.1 definition of a CertificateList made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax are to 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 [Section 11.2.3,
- X.509].
-
- Due to changes made to the ASN.1 definition of an X.509
- CertificatePair made through time, no LDAP-specific encoding is
- defined for this syntax. Values of this syntax are to 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".
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 3]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- 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.508 Supported Algorithm' )
-
- A value of this syntax is an X.509 SupportedAlgorithm [Section 11.2.7,
- X.509].
-
- Due to changes made to the ASN.1 definition of an X.509
- SupportedAlgorithm made through time, no LDAP-specific encoding is
- defined for this syntax. Values of this syntax are to 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 [Section
- 11.3.1, X.509].
-
- The LDAP-specific encoding used for this syntax is described by the
- following ABNF [RFC2234]:
-
- certificateExactAssertion = serialNumber DOLLAR issuer
- serialNumber = number
- issuer = distinguishedName
-
- where <number> and <DOLLAR> are as given in [Models] and
- <distinguishedName> is as given in [LDAPDN].
-
- Example: 10$cn=Example$CA,dc=example,dc=com
-
- Note: DOLLAR ('$') characters may appear in the <issuer> production.
-
-
-2.6. CertificateAssertion
-
- ( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' )
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 4]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- A value of this syntax is an X.509 CertificateAssertion [Section
- 11.3.2, X.509].
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.1 provides an equivalent ABNF grammar for this syntax.
-
-
-2.7. CertificatePairExactAssertion
-
- ( IANA-ASSIGNED-OID.3
- DESC 'X.509 Certificate Pair Exact Assertion' )
-
- A value of this syntax is an X.509 CertificatePairExactAssertion
- [Section 11.3.3, X.509].
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.2 provides an equivalent 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 [Section
- 11.3.4, X.509].
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.3 provides an equivalent 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
- [Section 11.3.5, X.509].
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.4 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 [Section
- 11.3.6, X.509].
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 5]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.5 provides an equivalent 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 [Section 7,
- X.509].
-
- Values of this syntax are to be encoded using GSER [RFC3641].
- Appendix A.6 provides an equivalent 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 Section 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 Section 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
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 6]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- certificate pair syntax as described in Section 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
- certificate pair syntax as described in Section 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 Section 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 Section 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 Section 11.3.7 of [X.509].
-
- ( 2.5.13.40 NAME 'algorithmIdentifier'
- DESC 'X.509 Algorithm Identifier Match'
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 7]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- 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
-
- The userCertificate attribute holds the X.509 certificates issued to
- the user by one or more certificate authorities, as discussed in
- Section 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 Section 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 Section 11.2.3 of [X.509].
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- DESC 'X.509 cross certificate pair'
- EQUALITY certificatePairExactMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 8]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- 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".
-
-
-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
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 9]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- 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 Section 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 Section 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 ) )
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 10]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-5.3. cRLDistributionPoint
-
- This class is used to represent objects which act as CRL distribution
- points, as discussed in Section 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 no hold delta
- revocation lists, as discussed in Section 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 Section 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 Section 6.16 of
- [X.521].
-
- ( 2.5.6.18 NAME 'userSecurityInformation'
- DESC 'X.521 user security information'
- SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 11]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-5.7. certificationAuthority
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in Section 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 which act as
- certificate authorities, as defined in Section 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
-
- The directory administrator is to use the server's access control
- facilities to restrict access as desired.
-
- General LDAP security considerations [Roadmap] apply.
-
-
-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
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 12]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-7.2. Registration of the descriptor
-
- 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 RFC 2252 and RFC
- 2256, both products of the IETF ASID WG.
-
- Additional material was borrowed from prior works by David Chadwick
- and/or Steven Legg to refine LDAP X.509 Schema.
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 13]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
-9. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-10. 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.
-
- [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(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
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 14]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
-
-11. Informative References
-
- [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.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-Appendix A.
-
- This appendix is informative.
-
- This appendix, once written, will provide ABNF [RFC2234] grammars for
- GSER-based LDAP-specific encodings specified in this document. These
- grammars where produced using, and rely on, Common Elements for GSER
- Encodings [RFC3342].
-
-
-
-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
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 15]
-\f
-INTERNET-DRAFT LDAP X.509 Schema 17 October 2004
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-00 [Page 16]
-\f
-
projects / openldap / commitdiff