-
-Internet-Draft Editor: R. Harrison
-Intended Category: Draft Standard Novell, Inc.
-Document: draft-ietf-ldapbis-authmeth-05.txt March 2003
-Obsoletes: RFC 2829, RFC 2830
+INTERNET-DRAFT Editor: R. Harrison
+draft-ietf-ldapbis-authmeth-08.txt Novell, Inc.
+Obsoletes: 2251, 2829, 2830 26 October 2003
+Intended Category: Draft Standard
LDAP: Authentication Methods
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
Abstract
- This document describes LDAPv3 (Lightweight Directory Access
- Protocol v3) authentication methods and connection level security
- mechanisms that are required of all conforming LDAPv3 server
- implementations and makes recommendations for combinations of these
- mechanisms to be used in various deployment circumstances.
+ This document describes authentication methods and connection level
+ security mechanisms of the Lightweight Directory Access Protocol
+ (LDAP).
+
+ This document details the simple Bind authentication method
+ including anonymous, unauthenticated, and plain-text password
+ methods and the SASL (Simple Authentication and Security Layer) Bind
+ authentication method including the use of DIGEST-MD5 and EXTERNAL
+ mechanisms.
- Among the mechanisms described are
-
- - various forms of authentication including anonymous
- authentication, password-based authentication, and certificate
- based authentication
- - the use of SASL mechanisms with LDAPv3
- - the use of TLS (Transport Layer Security) with LDAPv3
-
-Harrison Expires September 2003 [Page 1]
+Harrison Expires April 2004 [Page 1]
\f
- Authentication Methods for LDAPv3
+Internet-Draft LDAP Authentication Methods 7 October 2003
- - the various authentication and authorization states through
- which a connection to an LDAP server may pass and the actions
- that trigger these state changes.
-
-
-1. Conventions Used in this Document
+ This document also details establishment of TLS (Transport Layer
+ Security) using the Start TLS operation.
-1.1. Glossary of Terms
-
- The following terms are used in this document. To aid the reader,
- these terms are defined here.
-
- - "user" represents any application which is an LDAP client using
- the directory to retrieve or store information.
-
- - "LDAP association" is used to distinguish the LDAP-level
- connection from any underlying TLS-level connection that may or
- may not exist.
-
-1.2. Security Terms and Concepts
-
- In general, security terms in this document are used consistently
- with the definitions provided in [RFC2828]. In addition, several
- terms and concepts relating to security, authentication, and
- authorization are presented in Appendix B 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 B before reading the remainder of this document.
-
-1.3. Keywords
+ This document describes various authentication and authorization
+ states through which a connection to an LDAP server may pass and the
+ actions that trigger these state changes.
- 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].
+ This document also prescribes DIGEST-MD5 as LDAP's mandatory-to-
+ implement strong authentication mechanism.
-2. Introduction
+1. Introduction
- This document is an integral part of the LDAP Technical
- Specification [ROADMAP]. This document replaces RFC 2829 and
- portions of RFC 2830. Changes to RFC 2829 are summarized in Appendix
- C and changes to RFC 2830 are summarized in Appendix D.
-
- LDAPv3 is a powerful access protocol for directories. It offers
- means of searching, retrieving and manipulating directory content,
- and ways to access a rich set of security functions.
+ The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
+ powerful access protocol for directories. It offers means of
+ searching, retrieving and manipulating directory content, and ways
+ to access a rich set of security functions.
It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be
a minimum subset of security functions that is common to all
- implementations that claim LDAPv3 conformance.
+ implementations that claim LDAP conformance.
Basic threats to an LDAP directory service include:
-Harrison Expires September 2003 [Page 2]
-\f
- Authentication Methods for LDAPv3
-
-
(1) Unauthorized access to directory data via data-retrieval
operations,
(7) Spoofing of directory: Tricking a client into believing that
information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the client's
- connection.
+ connection. Also, tricking a client into sending privileged
+ information to a hostile entity that appears to be the directory
+ but is not.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3) and (7) are due to hostile agents on the path between
client and server or hostile agents posing as a server.
- The LDAP protocol suite can be protected with the following security
- mechanisms:
+ LDAP can be protected with the following security mechanisms:
+
+
+
+Harrison Expires April 2004 [Page 2]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
- (1) Client authentication by means of the SASL [RFC2222] mechanism
- set, possibly backed by the TLS [RFC2246] credentials exchange
+ (1) Client authentication by means of the Secure Authentication and
+ Security Layer (SASL) [SASL] mechanism set, possibly backed by
+ the Transport Layer Security (TLS) [TLS] credentials exchange
mechanism,
(2) Client authorization by means of access control based on the
requestor's authenticated identity,
- (3) Data integrity protection by means of the TLS protocol or SASL
- mechanisms that provide data integrity services,
+ (3) Data integrity protection by means of TLS or SASL mechanisms
+ with security layers that provide data integrity services,
(4) Data confidentiality protection against snooping by means of the
TLS protocol or SASL mechanisms that provide data
mechanism.
At the moment, imposition of access controls is done by means
- outside the scope of the LDAPv3 protocol.
-
-3. Rationale for LDAPv3 Security Mechanisms
-
-
-
-Harrison Expires September 2003 [Page 3]
-\f
- Authentication Methods for LDAPv3
-
+ outside the scope of LDAP.
+
It seems clear that allowing any implementation, faced with the
above requirements, to simply pick and choose among the possible
alternatives is not a strategy that is likely to lead to
interoperability. In the absence of mandates, clients will be
written that do not support any security function supported by the
- server, or worse, they will support only mechanisms like the LDAPv3
+ server, or worse, they will support only mechanisms like the LDAP
simple bind using clear text passwords that provide inadequate
security for most circumstances.
of user identities for backwards compatibility with non-LDAP-based
authentication services.
- The set of security mechanisms provided in LDAPv3 and described in
+ 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 LDAPv3 implementations and
- deployments. Appendix A 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.
+ Appendix A contains example deployment scenarios that list the
+ mechanisms that might be used to achieve a reasonable level of
+ security in various circumstances.
+
+ This document is an integral part of the LDAP Technical
+ Specification [Roadmap]. This document replaces RFC 2829 and
+ portions of RFC 2830 and RFC 2251.
+
+Harrison Expires April 2004 [Page 3]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+
+2. Conventions Used in this Document
+
+2.1. Glossary of Terms
+
+ The following terms are used in this document. To aid the reader,
+ these terms are defined here.
+
+ - "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).
+
+ - "connection" and "LDAP connection" both refer to the underlying
+ transport protocol connection between two protocol peers.
+
+ - "TLS connection" refers to a TLS-protected LDAP connection.
+
+ - "association" and "LDAP association" both refer to the
+ association of the LDAP connection and its current
+ authentication and authorization state.
+
+2.2. Security Terms and Concepts
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix B 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 B before reading the remainder of this document.
+
+2.3. Keywords
+
+ 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].
-4. Bind Operation
+3. Bind Operation
The Bind operation defined in section 4.2 of [Protocol] allows
authentication information to be exchanged between the client and
- server.
+ server to establish a new LDAP association. The new LDAP association
+ is established upon successful completion of the authentication
+ exchange.
+
+
-4.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind")
+3.1. Implied Anonymous Bind on LDAP Association
- Unlike LDAP version 2, the client need not send a Bind Request in
- the first PDU of the connection. 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. If the server
- requires that the client bind before browsing or modifying the
- directory, the server MAY reject a request other than binding,
- unbinding or an extended request with the "operationsError" result.
+ Prior to the successful completion of a Bind operation and during
+ any subsequent authentication exchange, the session has an anonymous
+
+Harrison Expires April 2004 [Page 4]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ LDAP association. Among other things this implies that the client
+ need not send a Bind Request in the first PDU of the connection. 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. This authentication state on an LDAP association is
+ sometimes referred to as an implied anonymous bind.
+
+3.2. Simple Authentication
+ The simple authentication choice provides minimal facilities for
+ establishing an anonymous association or for establishing an LDAP
+ association based upon credentials consisting of a name (in the form
+ of an [LDAPDN] and a password.
+
+ The simple authentication choice provides two different methods
+ for establishing an anonymous association: anonymous bind and
+ unauthenticated bind (see section 6.1).
-4.2. Simple Authentication
+ The simple authentication choice provides one method for
+ establishing a non-anonymous association: simple password bind.
- The simple authentication option provides minimal authentication
- facilities, with the contents of the authentication field consisting
- only of a cleartext password. Note that the use of cleartext
- passwords is strongly discouraged over open networks when the
- underlying transport service cannot guarantee confidentiality (see
- section 8).
+3.3. SASL Authentication Profile
-4.3. SASL Authentication
+ LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
+ includes native anonymous and plaintext authentication methods, the
+ "ANONYMOUS" [ANONYMOUS] and "PLAIN" [PLAIN] SASL mechanisms are
+ typically not used with LDAP.
-Harrison Expires September 2003 [Page 4]
-\f
- Authentication Methods for LDAPv3
+ 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.
+
+3.3.1. SASL Service Name for LDAP
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a GSSAPI service name.
+
+3.3.2. SASL authentication initiation and protocol exchange
+
+ SASL authentication is initiated via an LDAP bind request
+ ([Protocol] section 4.2) with the following parameters:
- The sasl authentication option allows for any mechanism defined for
- use with SASL [RFC2222] not specifically prohibited by this document
- (see section 4.3.1).
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ may be used to provide an initial client response for
+ mechanisms that are defined to have the client send data first
+ (see [SASL] sections 5 and 6.1).
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+
+Harrison Expires April 2004 [Page 5]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ 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
+ BindRequest multiple times. A challenge is indicated by the server
+ sending a BindResponse with the resultCode set to
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new bind request, with the same sasl mechanism to
+ continue the authentication process.
+
+ To the encapsulating protocol, these challenges and responses are
+ opaque binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field, an OCTET STRING, in a bind response message
+ to transmit each challenge. LDAP clients use the credentials field,
+ an OCTET STRING, in the SaslCredentials sequence of a bind request
+ message to transmit each response. Note that unlike some Internet
+ application 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 bind request with the sasl choice selected SHOULD
NOT send a value in the name field. Servers receiving a bind request
with the sasl choice selected SHALL ignore any value in the name
field.
- The mechanism field in SaslCredentials contains the name of the
- mechanism. The credentials field contains the arbitrary data used
- for authentication, inside an OCTET STRING wrapper. Note that unlike
- some Internet application protocols where SASL is used, LDAP is not
- text-based, thus no Base64 transformations are performed on the
- credentials.
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as
+ an empty string, the server MUST return a BindResponse with
+ authMethodNotSupported as the resultCode. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a bind response in which the resultCode
+ is either success, or an error indication.
+
+ The serverSaslCreds field in the bind response 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.
+
+3.3.3. Octet where negotiated security mechanisms take effect
+
+ When negotiated, SASL security layers take effect following the
+ transmission by the server and reception by the client of the final
+ BindResponse in the exchange.
+
+ Once a SASL security layer providing integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e. at the first octet following the final
+ BindResponse of the bind operation that caused the new layer to take
+ effect).
+
+Harrison Expires April 2004 [Page 6]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+
+3.3.4. Determination of supported SASL mechanisms
- If any SASL-based integrity or confidentiality services are enabled,
- they take effect following the transmission by the server and
- reception by the client of the final BindResponse with a resultCode
- of success.
+ An LDAP client may determine the SASL mechanisms a server supports
+ by performing a search request on the root DSE, requesting the
+ supportedSASLMechanisms attribute. The values of this attribute, if
+ any, list the mechanisms the server supports.
- If a SASL security layer is negotiated, the client MUST discard all
+3.3.5. Rules for using SASL security layers
+
+ If a SASL security layer is negotiated, the client SHOULD discard
information about the server fetched prior to the initiation of the
- SASL negotiation. If the client is configured to support multiple
- SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list
- both before and after the SASL security layer is negotiated. This
- allows the client to detect active attacks that remove supported
- SASL mechanisms from the supportedSASLMechanisms list and allows the
- client to ensure that it is using the best mechanism supported by
- both client and server. (This requirement is a SHOULD to allow for
- environments where the supportedSASLMechanisms list is provided to
- the client through a different trusted source, e.g. as part of a
- digitally signed object.)
-
- The client can request that the server use authentication
- information from a lower layer protocol by using the SASL EXTERNAL
- mechanism (see section 5.2.2.).
-
-4.3.1. Use of ANONYMOUS and PLAIN SASL Mechanisms
-
- As LDAP includes native anonymous and plaintext authentication
- methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
- with LDAP. If an authorization identity of a form different from a
- DN is requested by the client, a data confidentiality mechanism that
- protects the password in transit should be used.
-
-4.3.2. Use of EXTERNAL SASL Mechanism
-
- The "EXTERNAL" SASL mechanism can be used to request the LDAP server
- make use of security credentials exchanged by a lower layer. If a
- TLS session has not been established between the client and server
- prior to making the SASL EXTERNAL Bind request and there is no other
- external source of authentication credentials (e.g. IP-level
-
-Harrison Expires September 2003 [Page 5]
-\f
- Authentication Methods for LDAPv3
-
- security [RFC2401]), or if during the process of establishing the
- TLS session, the server did not request the client's authentication
- credentials, the SASL EXTERNAL bind MUST fail with a resultCode of
- inappropriateAuthentication. Any client authentication and
+ SASL negotiation and not obtained through secure mechanisms.
+
+ If the client is configured to support multiple SASL mechanisms, it
+ SHOULD fetch the supportedSASLmechanisms list both before and after
+ the SASL security layer is negotiated. This allows the client to
+ detect active attacks that remove supported SASL mechanisms from the
+ supportedSASLMechanisms list and allows the client to ensure that it
+ is using the best mechanism supported by both client and server. (In
+ particular, this allows for environments where the
+ supportedSASLMechanisms list is provided to the client through a
+ different trusted source, e.g. as part of a digitally signed
+ object.)
+
+ If a lower level security layer (such as TLS) is negotiated, any
+ SASL security services SHALL be layered on top of such security
+ layers regardless of the order of their negotiation.
+
+3.3.6. Use of EXTERNAL SASL Mechanism
+
+ A client can use the "EXTERNAL" SASL mechanism to request the LDAP
+ server to make use of security credentials exchanged by a lower
+ layer. If authentication credentials have not been established at a
+ lower level (such as by TLS authentication or IP-level security
+ [RFC2401]), the SASL EXTERNAL bind MUST fail with a resultCode of
+ inappropriateAuthentication. Any client authentication and
authorization state of the LDAP association is lost, so the LDAP
association is in an anonymous state after the failure (see
[Protocol] section 4.2.1).
-4.3.3. Other SASL Mechanisms
-
- Other SASL mechanisms may be used with LDAP, but their usage is not
- considered in this document.
-
-4.4. SASL Authorization Identity
-
- The authorization identity is carried as part of the SaslCredentials
- credentials field in the Bind request and response.
+3.4. SASL Authorization Identity
When the "EXTERNAL" SASL mechanism is being negotiated, if the
- credentials field is present, it contains an authorization identity
- of the authzId form described below.
+ SaslCredentials credentials field is present, it contains an
+ authorization identity. Other mechanisms define the location of the
+ authorization identity in the credentials field. In either case, the
+ authorization identity is represented in the authzId form described
+ below.
- Other mechanisms define the location of the authorization identity
- in the credentials field.
-
-4.4.1. Authorization Identity Syntax
+3.4.1. Authorization Identity Syntax
- The authorization identity is a string in the UTF-8 character set,
- corresponding to the following ABNF grammar [RFC2234]:
+ The authorization identity is a string of [UTF-8] encoded [Unicode]
+ characters corresponding to the following ABNF grammar [RFC2234]:
+
+Harrison Expires April 2004 [Page 7]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
; Specific predefined authorization (authz) id schemes are
; defined below -- new schemes may be defined in the future.
userid = utf8string ; syntax unspecified
The dnAuthzId choice allows client applications to assert
- authorization identities in the form of a distinguished name. The
- decision to allow or disallow an authentication identity to have
- access to the requested authorization identity is a matter of local
- policy ([SASL] section 4.2). For this reason there is no requirement
- that the asserted dn be that of an entry in directory.
+ authorization identities in the form of a distinguished name to be
+ matched in accordance with the distinguishedName matching rule
+ [Syntaxes]. The decision to allow or disallow an authentication
+ identity to have access to the requested authorization identity is a
+ matter of local policy ([SASL] section 4.2). For this reason there
+ is no requirement that the asserted dn be that of an entry in
+ directory.
-
-Harrison Expires September 2003 [Page 6]
-\f
- Authentication Methods for LDAPv3
-
The uAuthzId choice allows for compatibility with client
applications that wish to assert an authorization identity to a
local directory but do not have that identity in distinguished name
- form. The format of utf8string is defined as only a sequence of UTF-
- 8 encoded ISO 10646 characters, and further interpretation is
- subject to prior agreement between the client and server.
+ form. The value contained within a uAuthzId MUST be prepared using
+ SASLprep before being compared octet-wise. The format of utf8string
+ is defined as only a sequence of of [UTF-8] encoded [Unicode]
+ characters, and further interpretation is subject to prior agreement
+ between the client and server.
For example, the userid could identify a user of a specific
- directory service, or be a login name or the local-part of an RFC
- 822 email address. In general, a uAuthzId MUST NOT be assumed to be
- globally unique.
+ directory service or be a login name or the local-part of an RFC 822
+ email address. A uAuthzId SHOULD NOT be assumed to be globally
+ unique.
- Additional authorization identity schemes MAY be defined in future
+ Additional authorization identity schemes may be defined in future
versions of this document.
-4.5. SASL Service Name for LDAP
-
- For use with SASL [RFC2222], a protocol must specify a service name
- to be used with various SASL mechanisms, such as GSSAPI. For LDAP,
- the service name is "ldap", which has been registered with the IANA
- as a GSSAPI service name.
-
-4.6. SASL Integrity and Privacy Protections
-
- Any negotiated SASL integrity and privacy protections SHALL start on
- the first octet of the first LDAP PDU following successful
- completion of the SASL bind operation. If lower level security layer
- is negotiated, such as TLS, any SASL security services SHALL be
- layered on top of such security layers regardless of the order of
- their negotiation.
-
-5. Start TLS Operation
+4. Start TLS Operation
The Start Transport Layer Security (StartTLS) operation defined in
- section 4.13 of [Protocol] provides the ability to establish
- Transport Layer Security [RFC2246] on an LDAP association.
+ section 4.13 of [Protocol] provides the ability to establish [TLS]
+ on an LDAP association.
-5.1. Sequencing of the Start TLS Operation
+4.1. Sequencing of the Start TLS Operation
This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into
+
+Harrison Expires April 2004 [Page 8]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
consideration various aspects of the overall security of the LDAP
association including discovery of resultant security level and
assertion of the client's authorization identity.
Note that the precise effects, on a client's authorization identity,
of establishing TLS on an LDAP association are described in detail
- in section 5.5.
+ in section 4.2.
-5.1.1. Requesting to Start TLS on an LDAP Association
+4.1.1. Requesting to Start TLS on an LDAP Connection
The client MAY send the Start TLS extended request at any time after
- establishing an LDAP association, except that in the following cases
- the client MUST NOT send a Start TLS extended request:
-
-Harrison Expires September 2003 [Page 7]
-\f
- Authentication Methods for LDAPv3
-
-
- - if TLS is currently established on the connection, or
- - during a multi-stage SASL negotiation, or
- - if there are any LDAP operations outstanding on the
- connection.
+ establishing an LDAP connection, except:
+
+ - when TLS is currently established on the connection,
+ - when a multi-stage SASL negotiation is in progress on the
+ connection, or
+ - when there are one or more outstanding LDAP operations on the
+ connection.
The result of violating any of these requirements is a resultCode of
- operationsError, as described above in [Protocol] section 14.3.2.2.
+ operationsError, as described in [Protocol] section 4.13.2.2. Client
+ implementers should note that it is possible to receive a resultCode
+ of success for a Start TLS operation that is sent on a connection
+ with outstanding LDAP operations and the server has sufficient time
+ to process them prior to its receiving the Start TLS request.
+ Implementors should ensure that they do not inadvertently depend
+ upon this race condition for proper functioning of their
+ applications.
In particular, there is no requirement that the client have or have
not already performed a Bind operation before sending a Start TLS
other requests, and the server requires the client to establish a
TLS connection before performing a particular request, the server
MUST reject that request by sending a resultCode of
- confidentialityRequired or strongAuthRequired. In response, the
- client MAY send a Start TLS extended request, or it MAY choose to
- close the connection.
+ confidentialityRequired or strongAuthRequired.
-5.1.2. Starting TLS
+4.1.2. Starting TLS
The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. It will return
LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
- server to initiate TLS negotiation [RFC2246].
+ server to initiate [TLS] negotiation.
+
-5.1.3. TLS Version Negotiation
+Harrison Expires April 2004 [Page 9]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+4.1.3. TLS Version Negotiation
Negotiating the version of TLS or SSL to be used is a part of the
- TLS Handshake Protocol, as documented in [RFC2246]. Please refer to
- that document for details.
+ [TLS] Handshake Protocol. Please refer to that document for details.
-5.1.4. Discovery of Resultant Security Level
+4.1.4. Discovery of Resultant Security Level
After a TLS connection is established on an LDAP association, both
parties MUST individually decide whether or not to continue based on
- the privacy level achieved. Ascertaining the TLS connection's
- privacy level is implementation dependent, and accomplished by
+ the security level achieved. Ascertaining the TLS connection's
+ security level is implementation dependent and accomplished by
communicating with one's respective local TLS implementation.
If the client or server decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD gracefully
+ security is not high enough for it to continue, it SHOULD gracefully
close the TLS connection immediately after the TLS negotiation has
- completed (see [Protocol] section 4.13.3.1 and section 5.2.3 below).
-
-Harrison Expires September 2003 [Page 8]
-\f
- Authentication Methods for LDAPv3
+ completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).
+ If the client decides to continue, it may gracefully close the TLS
+ connection and attempt to Start TLS again, it may send an unbind
+ request, or it may send any other LDAP request.
- If the client decides to continue, it MAY attempt to Start TLS
- again, it MAY send an unbind request, or it MAY send any other LDAP
- request.
-
-5.1.5. Assertion of Client's Authorization Identity
-
- The client MAY, upon receipt of a Start TLS response indicating
- success, assert that a specific authorization identity be utilized
- in determining the client's authorization status. The client
- accomplishes this via an LDAP Bind request specifying a SASL
- mechanism of "EXTERNAL" [RFC2222] (see section 5.5.1.2 below).
-
-5.1.6. Server Identity Check
+4.1.5. Server Identity Check
The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's
- Certificate message, in order to prevent man-in-the-middle attacks.
+ Certificate message in order to prevent man-in-the-middle attacks.
Matching is performed according to these rules:
- - The client MUST use the server hostname it used to open the LDAP
- connection as the value to compare against the server name as
- expressed in the server's certificate. The client MUST NOT use
- the any other derived form of name including the server's
- canonical DNS name.
+ - The client MUST use the server 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 the 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
- 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 in any one of the set is
- considered acceptable.
+ 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 in any
+ one of the set is considered acceptable.
If the hostname does not match the dNSName-based identity in the
certificate per the above check, user-oriented clients SHOULD either
- notify the user (clients MAY give the user the opportunity to
+ notify the user (clients may give the user the opportunity to
continue with the connection in any case) or terminate the
+
+Harrison Expires April 2004 [Page 10]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the connection, returning and/or
logging an error indicating that the server's identity is suspect.
Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The
- client MAY need to make use of local policy information.
-
-
-Harrison Expires September 2003 [Page 9]
-\f
- Authentication Methods for LDAPv3
+ client may need to make use of local policy information in making
+ this determination.
-5.1.7. Refresh of Server Capabilities Information
+4.1.6. Refresh of Server Capabilities Information
- Upon TLS session establishment, the client MUST discard all
- information about the server fetched prior to the initiation of the
- TLS negotiation and MUST refresh any cached server capabilities
- information (e.g. from the server's root DSE; see section 3.4 of
- [Protocol]). This is necessary to protect against active-
- intermediary attacks that may have altered any server capabilities
- information retrieved prior to TLS establishment.
+ Upon TLS session establishment, the client SHOULD discard or refresh
+ all information about the server fetched prior to the initiation of
+ the TLS negotiation and not obtained through secure mechanisms. This
+ protects against active-intermediary attacks that may have altered
+ any server capabilities information retrieved prior to TLS
+ establishment.
- The server MAY advertise different capabilities after TLS
+ The server may advertise different capabilities after TLS
establishment. In particular, the value of supportedSASLMechanisms
- MAY be different after TLS has been negotiated (specifically, the
- EXTERNAL mechanism or the proposed PLAIN mechanism are likely to
- only be listed after a TLS negotiation has been performed).
+ may be different after TLS has been negotiated (specifically, the
+ EXTERNAL and [PLAIN] mechanisms are likely to be listed only after a
+ TLS negotiation has been performed).
-5.2. Effects of TLS on a Client's Authorization Identity
+4.2. Effects of TLS on a Client's Authorization Identity
This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP association.
Authorization identities and related concepts are described in
Appendix B.
-5.2.1. Default Effects
+4.2.1. Default Effects
Upon establishment of the TLS session onto the LDAP association, any
previously established authentication and authorization identities
MUST remain in force, including anonymous state. This holds even in
the case where the server requests client authentication via TLS --
e.g. requests the client to supply its certificate during TLS
- negotiation (see [RFC2246]).
+ negotiation.
-5.2.2. Client Assertion of Authorization Identity
+4.2.2. Client Assertion of Authorization Identity
- A client MAY either implicitly request that its LDAP authorization
- identity be derived from its authenticated TLS credentials or it MAY
- explicitly provide an authorization identity and assert that it be
- used in combination with its authenticated TLS credentials. The
- former is known as an implicit assertion, and the latter as an
- explicit assertion.
+ The client MAY, upon receipt of a Start TLS response indicating
+ success, assert that a specific authorization identity be utilized
+ in determining the client's authorization status. The client
+ accomplishes this via an LDAP Bind request specifying a SASL
+ mechanism of "EXTERNAL" [SASL]. A client may either implicitly
+ request that its LDAP authorization identity be derived from its
+
+Harrison Expires April 2004 [Page 11]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ authenticated TLS credentials or it may explicitly provide an
+ authorization identity and assert that it be used in combination
+ with its authenticated TLS credentials. The former is known as an
+ implicit assertion, and the latter as an explicit assertion.
-5.2.2.1. Implicit Assertion
+4.2.2.1. Implicit Assertion
An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL NOT
+ the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL NOT
include the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will
derive the client's authorization identity from the authentication
-
-Harrison Expires September 2003 [Page 10]
-\f
- Authentication Methods for LDAPv3
-
identity supplied in the client's TLS credentials (typically a
public key certificate) according to local policy. The underlying
mechanics of how this is accomplished are implementation specific.
-5.2.2.2. Explicit Assertion
+4.2.2.2. Explicit Assertion
An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL
- include the credentials octet string. This string MUST be
- constructed as documented in section 4.4.1.
+ the "EXTERNAL" mechanism name [SASL] [Protocol] that SHALL include
+ the credentials octet string. This string MUST be constructed as
+ documented in section 3.4.1.
-5.2.2.3. Error Conditions
+ The server MUST verify that the client's authentication identity as
+ supplied in its TLS credentials is permitted to be mapped to the
+ asserted authorization identity. The server MUST reject the Bind
+ operation with an invalidCredentials resultCode in the Bind response
+ if the client is not so authorized.
- For either form of assertion, the server MUST verify that the
- client's authentication identity as supplied in its TLS credentials
- is permitted to be mapped to the asserted authorization identity.
- The server MUST reject the Bind operation with an invalidCredentials
- resultCode in the Bind response if the client is not so authorized.
+4.2.2.3. Error Conditions
Additionally, with either form of assertion, if a TLS session has
not been established between the client and server prior to making
of authentication credentials (e.g. IP-level security [RFC2401]), or
if during the process of establishing the TLS session, the server
did not request the client's authentication credentials, the SASL
- EXTERNAL bind MUST fail with a result code of
+ EXTERNAL bind MUST fail with a resultCode of
inappropriateAuthentication.
After the above Bind operation failures, any client authentication
close_notify message, based on the Bind failure (as it MAY at any
time).
-5.2.3. TLS Connection Closure Effects
+4.2.3. TLS Connection Closure Effects
Closure of the TLS session MUST cause the LDAP association to move
to an anonymous authentication and authorization state regardless of
+
+Harrison Expires April 2004 [Page 12]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
the state established over TLS and regardless of the authentication
and authorization state prior to TLS session establishment.
-6. LDAP Association State Transition Tables
+5. LDAP Association State Transition Tables
To comprehensively diagram the various authentication and TLS states
through which an LDAP association may pass, this section provides a
states through which an LDAP association may pass during the course
of its existence and the actions that cause these changes in state.
-6.1. LDAP Association States
+5.1. LDAP Association States
-
-Harrison Expires September 2003 [Page 11]
-\f
- Authentication Methods for LDAPv3
-
The following table lists the valid LDAP association states and
provides a description of each state. The ID for each state is used
- in the state transition table in section 6.4.
+ in the state transition table in section 5.4.
ID State Description
-- --------------------------------------------------------------
- S1 no Auth ID
- no AuthZ ID
- [TLS: no Creds, OFF]
+ S1 Anonymous
+ no Authentication ID is associated with the LDAP connection
+ no Authorization ID is in force
+ No security layer is in effect.
+ No TLS credentials have been provided
+ TLS: no Creds, OFF]
S2 no Auth ID
no AuthZ ID
[TLS: no Creds, ON]
AuthZ ID= K
[TLS: Creds Auth ID "I", ON]
-6.2. Actions that Affect LDAP Association State
+5.2. Actions that Affect LDAP Association State
The following table lists the actions that can affect the state of
an LDAP association. The ID for each action is used in the state
- transition table in section 6.4.
+ transition table in section 5.4.
+
+
+Harrison Expires April 2004 [Page 13]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
ID Action
-- ------------------------------------------------
A5 Client or Server: send TLS closure alert ([Protocol] section
X)
A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST-
- MD5 password, Kerberos, etc. -û except EXTERNAL [Auth ID "X"
-
-Harrison Expires September 2003 [Page 12]
-\f
- Authentication Methods for LDAPv3
-
+ MD5 password, Kerberos, etc., except EXTERNAL [Auth ID "X"
maps to AuthZ ID "Y"]
A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J"
- [Explicit Assertion (section 5.2.1.2.2)]
+ [Explicit Assertion (section 4.2.1.2.2)]
A8 Client Bind SASL EXTERNAL without credentials [Implicit
- Assertion (section 5.2 .1.2.1)]
+ Assertion (section 4.2.1.2.1)]
+ A9 Client abandons a bind operation or bind operation fails
-6.3. Decisions Used in Making LDAP Association State Changes
+5.3. Decisions Used in Making LDAP Association State Changes
Certain changes in the state of an LDAP association are only allowed
if the server can affirmatively answer a question. These questions
are applied as part of the criteria for allowing or disallowing a
- state change in the state transition table in section 6.4.
+ state change in the state transition table in section 5.4.
ID Decision Question
-- --------------------------------------------------------------
D2 Can a valid AuthZ ID "K" be derived from TLS Credentials Auth
ID "I"?
-6.4. LDAP Association State Transition Table
+5.4. LDAP Association State Transition Table
The LDAP Association table below lists the valid states for an LDAP
association and the actions that could affect them. For any given
State Action State Comment
------- ------------- ----- -----------------------------------
S1 A1 S1
+
+Harrison Expires April 2004 [Page 14]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
S1 A2 S1 Error: Inappropriate authentication
S1 A3 S2
S1 A4 S3
S2 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
-
-Harrison Expires September 2003 [Page 13]
-\f
- Authentication Methods for LDAPv3
-
S2 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S3 A8 and D2=NO S3 Error: InvalidCredentials
S3 A8 and D2=YES S8
S4 A1 S1
- S4 A2 S4 Error: Inappropriate Authentication
+ S4 A2 S1 Error: Inappropriate Authentication
S4 A3 S5
S4 A4 S6
S4 A5 S1
another underlying mechanism such
as IPSec.
S5 A1 S2
- S5 A2 S5 Error: Inappropriate Authentication
+ S5 A2 S2 Error: Inappropriate Authentication
S5 A5 S1
S5 A6 S5
S5 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S6 A1 S3
- S6 A2 S6 Error: Inappropriate Authentication
+ S6 A2 S2 Error: Inappropriate Authentication
+
+Harrison Expires April 2004 [Page 15]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
S6 A5 S1
S6 A6 S6
S6 A7 and D1=NO S6 Error: InvalidCredentials
S6 A7 and D1=YES S7
- S6 A8 and D2=NO S6 Error: InvalidCredentials
+ S6 A8 and D2=NO S3 Error: InvalidCredentials
S6 A8 and D2=YES S8
S7 A1 S3
- S7 A2 S7 Error: Inappropriate Authentication
+ S7 A2 S2 Error: Inappropriate Authentication
S7 A5 S1
S7 A6 S6
S7 A7 S7
S7 A8 and D2=NO S3 Error: InvalidCredentials
S7 A8 and D2=YES S8
S8 A1 S3
- S8 A2 S8 Error: Inappropriate Authentication
+ S8 A2 S2 Error: Inappropriate Authentication
S8 A5 S1
S8 A6 S6
-
-Harrison Expires September 2003 [Page 14]
-\f
- Authentication Methods for LDAPv3
-
S8 A7 and D1=NO S6 Error: InvalidCredentials
S8 A7 and D1=YES S7
S8 A8 S8
+ Any A9 S1 See [Protocol] section 4.2.1.
-7. Anonymous Authentication
+6. Anonymous Authentication
Directory operations that modify entries or access protected
attributes or entries generally require client authentication.
access sensitive information in directory entries.
LDAP implementations MUST support anonymous authentication, as
- defined in section 7.1.
+ defined in section 6.1.
LDAP implementations MAY support anonymous authentication with TLS,
- as defined in section 7.2.
+ as defined in section 6.2.
While there MAY be access control restrictions to prevent access to
directory entries, an LDAP server SHOULD allow an anonymously-bound
by the lower layers or external means to grant or deny access even
to anonymously authenticated clients.
-7.1. Anonymous Authentication Procedure
+6.1. Anonymous Authentication Procedure
- An LDAPv3 client that has not successfully completed a bind
- operation on a connection is anonymously authenticated. See section
- 4.3.3.
+ Prior to successfully completing a Bind operation, the LDAP
+ association is anonymous. See section 3.1.
+
+
+
+Harrison Expires April 2004 [Page 16]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
- An LDAP client MAY also choose to explicitly bind anonymously. A
- client that wishes to do so MUST choose the simple authentication
- option in the Bind Request (see section 4.1) and set the password to
- be of zero length. (This is often done by LDAPv2 clients.) Typically
- the name is also of zero length.
+ An LDAP client may also explicitly establish an anonymous
+ association. A client that wishes to do so MUST choose the simple
+ authentication option in the Bind Request and set the password to be
+ of zero length. (This is often done by LDAPv2 clients.) Typically
+ the name is also of zero length. A bind request where both the name
+ and password are of zero length is said to be an anonymous bind. A
+ bind request where the name, a DN, is of non-zero length, and the
+ password is of zero length is said to be an unauthenticated bind.
+ Both variations produce an anonymous association.
-7.2. Anonymous Authentication and TLS
+6.2. Anonymous Authentication and TLS
An LDAP client MAY use the Start TLS operation (section 5) to
- negotiate the use of TLS security [RFC2246]. If the client has not
- bound beforehand, then until the client uses the EXTERNAL SASL
- mechanism to negotiate the recognition of the client's certificate,
- the client is anonymously authenticated.
+ negotiate the use of [TLS] security. If the client has not bound
+ beforehand, then until the client uses the EXTERNAL SASL mechanism
+ to negotiate the recognition of the client's certificate, the client
+ is anonymously authenticated.
- Recommendations on TLS ciphersuites are given in section 10.
+ Recommendations on TLS ciphersuites are given in section 9.
An LDAP server which requests that clients provide their certificate
during TLS negotiation MAY use a local security policy to determine
-
-
-Harrison Expires September 2003 [Page 15]
-\f
- Authentication Methods for LDAPv3
-
whether to successfully complete TLS negotiation if the client did
not present a certificate which could be validated.
-8. Password-based Authentication
+7. Password-based Authentication
This section discusses various options for performing password-based
- authentication to LDAPv3 compliant servers and the environments
+ authentication to LDAP compliant servers and the environments
suitable for their use.
-8.1. Simple Authentication
+7.1. Simple Authentication
The LDAP "simple" authentication choice is not suitable for
authentication in environments where there is no network or
transport layer confidentiality. LDAP implementations SHOULD support
authentication with the "simple" authentication choice when the
connection is protected against eavesdropping using TLS, as defined
- in section 5. LDAP implementations SHOULD NOT support authentication
+ in section 4. LDAP implementations SHOULD NOT support authentication
with the "simple" authentication choice unless the data on the
connection is protected using TLS or other data confidentiality and
data integrity protection.
-8.2. Digest Authentication
-
- LDAP servers that implement any password-based authentication method
- MUST support authentication with a password using the DIGEST-MD5
- SASL mechanism for password protection.
-
- An LDAP client MAY determine whether the server supports this
- mechanism by performing a search request on the root DSE, requesting
- the supportedSASLMechanisms attribute, and checking whether the
- string "DIGEST-MD5" is present as a value of this attribute.
-
- In the first stage of authentication, when the client is performing
- an "initial authentication" as defined in section 2.1 of [RFC2831],
- the client sends a bind request in which the version number is 3,
- the authentication choice is sasl, the sasl mechanism name is
- "DIGEST-MD5", and the credentials are absent. The client then waits
- for a response from the server to this request.
-
- The server will respond with a bind response in which the resultCode
- is saslBindInProgress, and the serverSaslCreds field is present. The
- contents of this field is a string defined by "digest-challenge" in
- section 2.1.1 of [RFC2831]. The server SHOULD include a realm
- indication and MUST indicate support for UTF-8.
-
- The client will send a bind request with a distinct message id, in
- which the version number is 3, the authentication choice is sasl,
- the sasl mechanism name is "DIGEST-MD5", and the credentials contain
- the string defined by "digest-response" in section 2.1.2 of
- [RFC2831]. The serv-type is "ldap".
-
- The server will respond with a bind response in which the resultCode
- is either success, or an error indication. If the authentication is
- successful and the server does not support subsequent
-
-Harrison Expires September 2003 [Page 16]
-\f
- Authentication Methods for LDAPv3
-
- authentication, then the credentials field is absent. If the
- authentication is successful and the server supports subsequent
- authentication, then the credentials field contains the string
- defined by "response-auth" in section 2.1.3 of [RFC2831]. Support
- for subsequent authentication is OPTIONAL in clients and servers.
+7.2. Digest Authentication
+
+ LDAP servers that implement any authentication method or mechanism
+ (other than simple anonymous bind) MUST implement the SASL
+ DIGEST-MD5 mechanism [DigestAuth].
+
+ Support for subsequent authentication is OPTIONAL in clients and
+ servers.
+
+
+
-8.3. "simple" authentication choice under TLS encryption
+Harrison Expires April 2004 [Page 17]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ Implementors 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 ([DigestAuth section 2.1) which are
+ syntactically simple strings and semsantically 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,
+ o=Ace Industry ", are syntactically allowed, however DIGEST-MD5
+ treats them as simple strings for comparison purposes. To illustrate
+ further, the two DNs "cn=bob, o=Ace Industry" (space between RDNs)
+ and "cn=bob,o=Ace Industry" (no space between RDNs) would be
+ equivalent when being compared semantically as LDAP DNs, however
+ they are not equivalent if they were used to represent username
+ values in DIGEST-MD5 because simple octet-wise comparision semantics
+ are used by DIGEST-MD5.
+
+
+7.3. "simple" authentication choice under TLS encryption
Following the negotiation of an appropriate TLS ciphersuite
- providing connection confidentiality [RFC2246], a client MAY
- authenticate to a directory that supports the simple authentication
- choice by performing a simple bind operation.
+ providing connection confidentiality, a client MAY authenticate to a
+ directory that supports the simple authentication choice by
+ performing a simple bind operation
- The client will use the Start TLS operation [Protocol] to negotiate
- the use of TLS security [RFC2246] on the connection to the LDAP
- server. The client need not have bound to the directory beforehand.
+ Simple authentication with TLS encryption protection is performed as
+ follows:
- For this authentication procedure to be successful, the client and
- server MUST negotiate a ciphersuite which contains a bulk encryption
- algorithm of appropriate strength. Recommendations on cipher suites
- are given in section 10.
+ 1. The client will use the Start TLS operation [Protocol] to
+ negotiate the use of TLS security [TLS] on the connection to
+ the LDAP server. The client need not have bound to the
+ directory beforehand.
+
+ For the subsequent authentication procedure to be performed
+ securely, the client and server MUST negotiate a ciphersuite
+ which contains a bulk encryption algorithm of appropriate
+ strength. Recommendations on cipher suites are given in
+ section 9.
- Following the successful completion of TLS negotiation, the client
- MUST send an LDAP bind request with the version number of 3, the
- name field containing a DN, and the "simple" authentication choice,
- containing a password.
+ 2. Following the successful completion of TLS negotiation, the
+ client MUST send an LDAP bind request with the version number
+ of 3, the name field containing a DN, and the "simple"
+ authentication choice, containing a password.
-8.3.1. "simple" Authentication Choice
+7.3.1. "simple" Authentication Choice
DSAs that map the DN sent in the bind request to a directory entry
with an associated set of one or more passwords will compare the
presented password to the set of passwords associated with that
- entry. If there is a match, then the server will respond with
- resultCode success, otherwise the server will respond with
- resultCode invalidCredentials.
+ entry. If the presented password matches any member of that set,
+ then the server will respond with a success resultCode, otherwise
+ the server will respond with an invalidCredentials resultCode.
-8.4. Other authentication choices with TLS
+
+Harrison Expires April 2004 [Page 18]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+7.4. Other authentication choices with TLS
It is also possible, following the negotiation of TLS, to perform a
SASL authentication that does not involve the exchange of plaintext
negotiate a ciphersuite that provides confidentiality if the only
service required is data integrity.
-9. Certificate-based authentication
+8. Certificate-based authentication
LDAP server implementations SHOULD support authentication via a
- client certificate in TLS, as defined in section 5.2.2.
+ client certificate in TLS, as defined in section 8.1.
-9.1. Certificate-based authentication with TLS
+8.1. Certificate-based authentication with TLS
A user who has a public/private key pair in which the public key has
been signed by a Certification Authority may use this key pair to
authenticate to the directory server if the user's certificate is
-
-Harrison Expires September 2003 [Page 17]
-\f
- Authentication Methods for LDAPv3
-
requested by the server. The user's certificate subject field SHOULD
be the name of the user's directory entry, and the Certification
Authority that issued the user's certificate must be sufficiently
configured to support certificates for which no mapping is required.
The client will use the Start TLS operation [Protocol] to negotiate
- the use of TLS security [RFC2246] on the connection to the LDAP
- server. The client need not have bound to the directory beforehand.
+ the use of TLS security [TLS] on the connection to the LDAP server.
+ The client need not have bound to the directory beforehand.
In the TLS negotiation, the server MUST request a certificate. The
client will provide its certificate to the server, and the server
In deployments that require protection of sensitive data in transit,
the client and server MUST negotiate a ciphersuite that contains a
bulk encryption algorithm of appropriate strength. Recommendations
- of cipher suites are given in section 10.
+ of cipher suites are given in section 9.
The server MUST verify that the client's certificate is valid. The
server will normally check that the certificate is issued by a known
Following the successful completion of TLS negotiation, the client
will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
-10. TLS Ciphersuites
+9. TLS Ciphersuites
+
+Harrison Expires April 2004 [Page 19]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- The following ciphersuites defined in [RFC2246] MUST NOT be used for
+ A client or server that supports TLS MUST support
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
+ offering equivalent or better protection.
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the LDAP
+ connection. Client and server implementers should recognize that
+ some TLS ciphersuites provide no confidentiality protection
+ while other ciphersuites that do provide confidentiality
+ protection may be vulnerable to being cracked using brute force
+ methods, especially in light of ever-increasing CPU speeds that
+ reduce the time needed to successfully mount such attacks.
+
+ Client and server implementers SHOULD carefully consider the
+ value of the password or data being protected versus the level
+ of confidentially protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
+ - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger
+ of a man-in-the-middle attack is tolerable.
+
+9.1. TLS Ciphersuites Recommendations
+
+ As of the writing of this document, the following recommendations
+ regarding TLS ciphersuites are applicable. Because circumstances are
+ 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 [RFC2246] can be cracked
- easily (less than a day of CPU time on a standard CPU in 2000).
- These ciphersuites are NOT RECOMMENDED for use in confidentiality
- protection of passwords or data. Client and server implementers
- SHOULD carefully consider the value of the password or data being
- protected before using these ciphersuites:
+ 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
-Harrison Expires September 2003 [Page 18]
+Harrison Expires April 2004 [Page 20]
\f
- Authentication Methods for LDAPv3
+Internet-Draft LDAP Authentication Methods 7 October 2003
- 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_DES40_CBC_SHA
The following ciphersuites are vulnerable to man-in-the-middle
- attacks, and SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger of a
- man-in-the-middle attack is tolerable:
+ attacks:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
- A client or server that supports TLS MUST support
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
- offering equivalent or better protection.
+
-11. Security Considerations
+10. Security Considerations
Security issues are discussed throughout this memo; the
(unsurprising) conclusion is that mandatory security is important
and that session confidentiality protection is required when
snooping is a problem.
- Servers are encouraged to prevent modifications by anonymous users.
+ Servers are encouraged to prevent modifications by anonymous users.
+
Servers may also wish to minimize denial of service attacks by
timing out idle connections, and returning the unwillingToPerform
- result code rather than performing computationally expensive
+ resultCode rather than performing computationally expensive
operations requested by unauthorized clients.
- Operational experience shows that clients can misuse unauthenticated
- access (simple bind with name but no password). For this reason,
- servers SHOULD by default reject authentication requests that have a
- DN with an empty password with an error of invalidCredentials.
+ The use of cleartext passwords is strongly discouraged over open
+ networks when the underlying transport service cannot guarantee
+ confidentiality.
- Access control SHOULD be applied when reading sensitive information
- or updating directory information.
+ Operational experience shows that clients can misuse unauthenticated
+ access (simple bind with name but no password). For example, a
+ client program might authenticate a user via LDAP and then grant
+ access to information not stored in the directory on the basis of
+ completing a successful bind. Some implementations will return a
+ success response to a simple bind that consists of a user name and
+ an empty password thus leaving the impression that the client has
+ successfully authenticated the identity represented by the user
+ name, when in reality, the directory server has simply performed an
+ anonymous bind. For this reason, servers SHOULD by default reject
+ authentication requests that have a DN with an empty password with
+ an error of invalidCredentials.
+
+ Access control SHOULD always be applied when reading sensitive
+ information or updating directory information.
A connection on which the client has not performed the Start TLS
operation or negotiated a suitable SASL mechanism for connection
+
+
+Harrison Expires April 2004 [Page 21]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
integrity and encryption services is subject to man-in-the-middle
attacks to view and modify information in transit.
-11.1. Start TLS Security Considerations
+10.1. Start TLS Security Considerations
The goals of using the TLS protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide
- for authentication. TLS expressly provides these capabilities, as
- described in [RFC2246].
-
-Harrison Expires September 2003 [Page 19]
-\f
- Authentication Methods for LDAPv3
-
+ for authentication. [TLS] expressly provides these capabilities.
All security gained via use of the Start TLS operation is gained by
the use of TLS itself. The Start TLS operation, on its own, does not
via TLS is required.
Additional security considerations relating to the EXTERNAL
- mechanism to negotiate TLS can be found in [RFC2222] and [RFC2246].
+ mechanism to negotiate TLS can be found in [SASL] and [TLS].
+11. IANA Considerations
-12. Acknowledgements
+ The following IANA considerations apply to this document:
+
+ Please update the GSSAPI service name registry to point to [Roadmap]
+ and this document.
+
+Harrison Expires April 2004 [Page 22]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ [To be completed]
+
+Contributors
+
This document combines information originally contained in RFC 2829
- and RFC 2830. The author acknowledges the work of Harald Tveit
+ 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.
- RFC 2829 and RFC 2830 were products of the IETF LDAPEXT Working
- Group. RFC 2251 was a product of the ASID Working Group.
+Acknowledgements
+
This document is based upon input of the IETF LDAP Revision working
- group. The contributions of its members is greatly appreciated.
+ group. The contributions and suggestions made by its members in
+ shaping the contents and technical accuracy of this document is
+ greatly appreciated.
-13. Normative References
-
-Harrison Expires September 2003 [Page 20]
-\f
- Authentication Methods for LDAPv3
-
+Normative References
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", draft-myers-saslrev-xx.txt, a work in progress.
-
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
- [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as
- a SASL Mechanism", RFC 2831, May 2000.
+ [DigestAuth] Leach, P. C. Newman, and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-
+ xx.txt, a work in progress.
[LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress.
+ [Model] Zeilenga, Kurt D. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress.
- [ROADMAP] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
-14. Informative References
+
+ [SASL] Melnikov, A. (editor), "Simple Authentication and Security
+ Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
+ progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
+ draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 2279, January 1998.
+
+Harrison Expires April 2004 [Page 23]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
- [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
+
+ [Unicode] International Organization for Standardization, "Universal
+ Multiple-Octet Coded Character Set (UCS) - Architecture and
+ Basic Multilingual Plane", ISO/IEC 10646-1 : 1993.
+
+Informative References
+
+ [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga-
+ sasl-anon-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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
-15. Author's Address
+Author's Address
Roger Harrison
Novell, Inc.
+1 801 861 2642
roger_harrison@novell.com
-16. Full Copyright Statement
+Full Copyright Statement
- Copyright (C) The Internet Society (2000). All Rights Reserved.
+ 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
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
-
-Harrison Expires September 2003 [Page 21]
-\f
- Authentication Methods for LDAPv3
-
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
"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
+
+Harrison Expires April 2004 [Page 24]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
sensitive authentication information AND data integrity for all
authentication information.
-
-Harrison Expires September 2003 [Page 22]
-\f
- Authentication Methods for LDAPv3
-
(5) A directory containing sensitive data. This scenario requires
data confidentiality protection AND secure authentication.
An access control policy is a set of rules defining the protection
of resources, generally in terms of the capabilities of persons or
other entities accessing those resources. A common expression of an
+
+Harrison Expires April 2004 [Page 25]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
access control policy is an access control list. Security objects
and mechanisms, such as those described here, enable the expression
of access control policies and their enforcement. Access control
- policies are typically expressed in terms of access control
- attributes as described below.
+ policies are typically expressed in terms of access control factors
+ as described below.
B.2. Access Control Factors
mechanism may constrain the form of authentication identities used
with it.
-Harrison Expires September 2003 [Page 23]
-\f
- Authentication Methods for LDAPv3
-
-
B.4. Authorization Identity
An authorization identity is one kind of access control factor. It
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 [RFC2222].
- 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.
+
+Harrison Expires April 2004 [Page 26]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ 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 C. RFC 2829 Change History
C.0. General Editorial Changes
Version -00
- - Changed other instances of the term LDAP to LDAPv3 where v3 of
- the protocol is implied. Also made all references to LDAPv3 use
- the same wording.
+ - 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.
Version -01
-
-Harrison Expires September 2003 [Page 24]
-\f
- Authentication Methods for LDAPv3
-
- Moved section to an appendix.
C.3. Changes to Section 3
- Changed "Distinguished Name" to "LDAP distinguished name".
C.5. Changes to Section 5
+
+Harrison Expires April 2004 [Page 27]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
Version -00
authentication unless confidentiality and data integrity
mechanisms are in force.
-
-
-Harrison Expires September 2003 [Page 25]
-\f
- Authentication Methods for LDAPv3
-
2. Moved first paragraph of section 6 (beginning with "LDAP
- implementations MUST support authentication with a passwordà")
+ 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
- Added sentence from original section 6 indicating that the
- DIGEST-MD5 SASL mechanism is required for all conforming LDAPv3
+ DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations
C.6.2. Changes to Section 6.2
Version -00
+
+Harrison Expires April 2004 [Page 28]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- Renamed section to 6.3
- Reworded first paragraph to remove reference to user and the
C.8. Changes to section 8.
-
-Harrison Expires September 2003 [Page 26]
-\f
- Authentication Methods for LDAPv3
-
Version -00
- Removed the first paragraph because simple authentication is
for Other Security Services) to bring material on SASL
mechanisms together into one location.
+Harrison Expires April 2004 [Page 29]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+
C.9. Changes to section 9.
Version -00
and server implementers SHOULD" to sentence just prior the
second list of ciphersuites.
-
-
-Harrison Expires September 2003 [Page 27]
-\f
- Authentication Methods for LDAPv3
-
- Added text: "and MAY support other ciphersuites offering
equivalent or better protection," to the last paragraph of the
section.
- Inserted new section 12 that specifies when SASL protections
begin following SASL negotiation, etc. The original section 12
is renumbered to become section 13.
+
+Harrison Expires April 2004 [Page 30]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
Version -01
- All material from section 4.2 of RFC 2251 was moved into this
document.
-
-Harrison Expires September 2003 [Page 28]
-\f
- Authentication Methods for LDAPv3
-
- A new section was created for the Bind Request
- Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
F.1. Changes for draft-ldap-bis-authmeth-02
General
+
+Harrison Expires April 2004 [Page 31]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- Added references to other LDAP standard documents, to sections
within the document, and fixed broken references.
- - General editorial changesùpunctuation, spelling, formatting,
+ - General editorial changes--punctuation, spelling, formatting,
etc.
Section 1.
statement and one that prohibited use of ANONYMOUS and PLAIN
SASL mechanisms.)
-
-Harrison Expires September 2003 [Page 29]
-\f
- Authentication Methods for LDAPv3
-
Section 5.3.6
- Added a.x.bar.com to wildcard matching example on hostname
- Brought security terminology in line with IETF security glossary
throughout the appendix.
+
+Harrison Expires April 2004 [Page 32]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
F.2. Changes for draft-ldap-bis-authmeth-03
General
- 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.
-
-Harrison Expires September 2003 [Page 30]
-\f
- Authentication Methods for LDAPv3
-
Section 11
General
+
+
+Harrison Expires April 2004 [Page 33]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- 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
-
Section 13
-
-Harrison Expires September 2003 [Page 31]
-\f
- Authentication Methods for LDAPv3
-
- Verified all normative references and moved informative
references to a new section 14.
several changes to correct improper usage.
Abstract
+
+
+Harrison Expires April 2004 [Page 34]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- Updated to match current contents of documents. This was needed
due to movement of material on Bind and Start TLS operations to
[Protocol] in this revision.
Section 3.
- - Renamed section to "Rationale for LDAPv3 Security Mechanisms"
- and removed text that did not support this theme. Part of the
+ - 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
mechanisms not explicitly mentioned in this document.
Section 4.4.1.
-
-Harrison Expires September 2003 [Page 32]
-\f
- Authentication Methods for LDAPv3
-
- Added paragraph beginning, "The dnAuthzID choice allows client
applications..." to clarify whether DN form authorization
section.
Section 5.1.7.
+
+Harrison Expires April 2004 [Page 35]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- Wording from section 3 paragraph beginning " If TLS is
negotiated, the client MUST discard all information..." was
- Began changes to incorporate information on deployment scenarios
removed from section 3.
+
+F.5. Changes for draft-ldap-bis-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.
+ - Opened several new issues in Appendix G based on feedback from
+ WG. Some of these have been resolved. Others require further
+ discussion.
+
+ Section 1
+Harrison Expires April 2004 [Page 36]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
-Harrison Expires September 2003 [Page 33]
+
+ - Added additional example of spoofing under threat (7).
+
+ Section 2.1
+
+ - Changed definition of "LDAP association" and added terms,
+ "connection" and "TLS connection" to bring usage in line with
+ [Protocol].
+
+ Section 4.1.6
+
+ - Clarified sentence stating that the client MUST NOT use derived
+ forms of DNS names.
+
+ Section 5.1
+
+ - Began edits to LDAP Association state table to clarify meaning
+ of various states and actions.
+
+ - Added action A9 to cover abandoned bind operation and added
+ appropriate transitions to the state transition table to
+ accommodate it.
+
+ Section 7.2
+
+ - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
+ mechanism is required to implement.
+
+ Section 9
+
+ - 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
+
+ - Added a clarifying example to the consideration regarding misuse
+ of unauthenticated access.
+
+F.6. Changes for draft-ldap-bis-authmeth-07
+
+
+ General
+
+ - Updated external and internal references to accommodate changes
+ in recent drafts.
+
+ - Opened several new issues in Appendix G based on feedback from
+ WG. Some of these have been resolved. Others require further
+ discussion.
+
+ Section 3
+
+
+
+Harrison Expires April 2004 [Page 37]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ - Rewrote much of section 3.3 to mee 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 Start TLS
+ 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.6. Changes for draft-ldap-bis-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
+
+ - Added 1.5 sentences at end of introductory paragraph indicating
+ the effect of the Bind op on the LDAP association.
+
+Harrison Expires April 2004 [Page 38]
\f
- Authentication Methods for LDAPv3
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ 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 negotion 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 larifications 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 Start TLS 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.
+
+ Section 4.1.6
+
+
+Harrison Expires April 2004 [Page 39]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ - 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]
+
Appendix G. Issues to be Resolved
This appendix lists open questions and issues that need to be
Section 2, deployment scenario 2: What is meant by the term "secure
authentication function?"
+
+Harrison Expires April 2004 [Page 40]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
Status: resolved. Based on the idea that a "secure authentication
function" could be provided by TLS, I changed the wording to require
reference is simply too arcane to be left in place. In -03 the text
has been modified to focus on the need to either update password
information in a protected fashion outside of the protocol or to
-
-
-Harrison Expires September 2003 [Page 34]
-\f
- Authentication Methods for LDAPv3
-
update it in session well protected against snooping, and the
reference to /etc/passwd has been removed.
Section 4 paragraph 9 indicates that clients SHOULD check the
supportedSASLMechanisms list both before and after a SASL security
+
+Harrison Expires April 2004 [Page 41]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
layer is negotiated to ensure that they are using the best available
security mechanism supported mutually by the client and server. A
note at the end of the paragraph indicates that this is a SHOULD
G.9.
-
-Harrison Expires September 2003 [Page 35]
-\f
- Authentication Methods for LDAPv3
-
Section 6.3.1 states: "DSAs that map the DN sent in the bind request
to a directory entry with a userPassword attribute will... compare
[each value in the named user's entry]... with the presented
the bind request.
G.11. Meaning of LDAP Association
+
+Harrison Expires April 2004 [Page 42]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
The original RFC 2830 uses the term "LDAP association" in describing
a connection between an LDAP client and server regardless of the
defined in section 6.1."
The thing is for acl it would be nice (though not critical) to be
-
-Harrison Expires September 2003 [Page 36]
-\f
- Authentication Methods for LDAPv3
-
able to default the required authentication level for a subject to a
single "fairly secure" mechanism--if there is no such mandatory
authentication scheme then you cannot do that. (Source: Rob Byrne)
While I'm here...in 2829, I think it would be good to have some
comments or explicit reference to a place where the security
properties of the particular mandatory authentication schemes are
+
+Harrison Expires April 2004 [Page 43]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
outlined. When I say "security properties" I mean stuff like "This
scheme is vulnerable to such and such attacks, is only safe if the
key size is > 50, this hash is widely considered the best, etc...".
members indicate that additional description of each state's meaning
would be helpful.
-
-
-Harrison Expires September 2003 [Page 37]
-\f
- Authentication Methods for LDAPv3
-
G.16. Empty sasl credentials question
I spent some more time looking microscopically at ldap-auth-methods
solution! Wildcard match does not solve this problem. For these
reasons I am inclined to argue for 'SHOULD' instead of
'MUST' in paragraph...
+
+Harrison Expires April 2004 [Page 44]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
Also, The hostname check against the name in the certificate is a
very weak means of preventing man-in-the-middle attacks; the proper
afterward is a SHOULD. This gives server implementations the room to
maneuver as needed.
- G.18. Must SASL DN exist in the directory?
+G.18. Must SASL DN exist in the directory?
If the 'dn:' form of sasl creds is used, is it the intention of the
draft(ers) that this DN must exist in the directory and the client
We already know that if *no* sasl credentials are presented, the DN
or altname in the client certificate may be mapped to a DN in an
implementation-dependent fashion, or indeed to something not in the
-
-Harrison Expires September 2003 [Page 38]
-\f
- Authentication Methods for LDAPv3
-
directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
Hodges)
G.20. Bind states
+
+Harrison Expires April 2004 [Page 45]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
Differences between unauthenticated and anonymous. There are four
states you can get into. One is completely undefined (this is now
explicitly called out in [Protocol]). This text needs to be moved
requests that have a DN with an empty password with an error of
invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
- Status: Resolved. Added to security considerations in û03.
+ Status: Resolved. Added to security considerations in -03.
G.22. Need to move StartTLS protocol information to [Protocol]
Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
they are [Protocol] -11.
-Harrison Expires September 2003 [Page 39]
-\f
- Authentication Methods for LDAPv3
-
-
G.23. Split Normative and Non-normative references into separate
sections.
G.24. What is the authentication state if a Bind operation is
abandoned?
- Status: In process. (11/12/02) This text was suggested to be added
- to [Protocol] -11 to cover what happens if a bind operation is
- abandoned:
+ Status: Resolved.
+
+ (3/24/03) This following text appears in section 4.2.1 of [Protocol]
+ revision -13 to cover what happens if a bind operation is abandoned:
- "If a server receives an Abandon request for a Bind operation, the
- server SHOULD leave the connection in the anonymous state. Clients
- that abandon a Bind operation MUST rebind after abandoning the Bind
- request in order to have a known authentication state on the
- connection."
-
- (11/21/02) Jim Sermersheim prposed the following wording on the
- ldapbis mail list: "Authentication from earlier binds are
- subsequently ignored. A failed or abandoned Bind Operation has the
- effect of leaving the connection in an anonymous state. Clients MUST
- rebind after abandoning a bind operation in order to determine a
- known authentication state."
-
- Once this is resolved in [Protocol] the state table in section 6 of
- [AuthMeth] will need to be updated to reflect the consensus wording.
+ A failed or abandoned Bind Operation has the effect of leaving the
+ connection in an anonymous state. To arrive at a known
+ authentication state after abandoning a bind operation, clients may
+ unbind, rebind, or make use of the BindResponse.
+
+ (6/28/03): The state table in section 6 of [AuthMeth] has been
+ updated to reflect this wording.
G.25. Difference between checking server hostname and server's
canonical DNS name in Server Identity Check?
- Section 5.1.6: I now understand the intent of the check (prevent
+ Section 4.1.6: I now understand the intent of the check (prevent
man-in-the-middle attacks). But what is the subtle difference
between the "server hostname" and the "server's canonical DNS name"?
(Source: Tim Hahn)
+
+Harrison Expires April 2004 [Page 46]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
- Status: In Process. (11/12/02) Sent suggested wording change to this
- paragraph to the ldapbis mail list and also asked for opinion as to
- whether we should discuss the distinction between server DNS
- hostname and server canonical DNS hostname in [AuthMeth].
+ Status: Resolved.
+
+ (11/12/02) Sent suggested wording change to this paragraph to the
+ ldapbis mail list and also asked for opinion as to whether we should
+ discuss the distinction between server DNS hostname and server
+ canonical DNS hostname in [AuthMeth].
(11/21/02): RL Bob Morgan will provide wording that allows
derivations of the name that are provided securely.
-6.26. Server Identity Check using servers located via SRV records
+ (6/28/03): posted to the WG list asking Bob or any other WG member
+ who is knowledgeable about the issues involved to help me with
+ wording or other information I can use to make this change and close
+ the work item.
+
+ (10/08/03): Based on WG list feedback, I've updated this text to
+ read what I judge to be the WG consensus, "The client MUST use the
+ server 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 the user input is to be
+ considered provided by the user only if derived in a secure fashion
+ (e.g., DNSSEC)."
- Section 5.1.6: What should be done if the server was found using SRV
+
+G.26. Server Identity Check using servers located via SRV records
+
+ Section 4.1.6: What should be done if the server was found using SRV
records based on the "locate" draft/RFC? (Source: Tim Hahn).
Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08
specifically calls out how the server identity should be performed
if the server is located using the method defined in that draft.
-
-
-Harrison Expires September 2003 [Page 40]
-\f
- Authentication Methods for LDAPv3
-
This is the right location for this information, and the coverage
appears to be adequate.
G.27 Inconsistency in effect of TLS closure on LDAP association.
- Section 5.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
+ Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
TLS closure alert will leave the LDAP association intact. Contrast
- this with Section 5.5.2 (section 5.2 of RFC2830) that says that the
+ this with Section 4.5.2 (section 5.2 of RFC2830) that says that the
closure of the TLS connection MUST cause the LDAP association to
move to an anonymous authentication.
- Status: in process. (11/12/02) This is actually a [Protocol] issue
+ Status: Resolved. (11/12/02) This is actually a [Protocol] issue
because these sections have now been moved to [Protocol] -11. I have
- proposed the following text for Section 5.4.1 of [AuthMeth] -03
+ proposed the following text for Section 4.4.1 of [AuthMeth] -03
(section 4.13.3.1 of [Protocol]) to resolve this apparent
discrepancy:
"Either the client or server MAY terminate the TLS connection on an
LDAP association by sending a TLS closure alert. The LDAP
connection remains open for further communication after TLS closure
+
+
+Harrison Expires April 2004 [Page 47]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
occurs although the authentication state of the LDAP connection is
- affected (see [AuthMeth] section 5.2.2).
+ affected (see [AuthMeth] section 4.2.2).
(11/21/02): resolution to this is expected in [Protocol] -12
+
+ (06/28/03): [Protocol]-15 clarifies that a TLS closure alert
+ terminates the TLS connection while leaving the LDAP connection
+ intact. The authentication state table in [AuthMeth] specifies the
+ effect on the LDAP association.
G.28 Ordering of external sources of authorization identities
states that the decision to allow or disallow the asserted identity
is based on an implementation defined policy.
-G.29 Rewrite of Section 10, TLS Ciphersuites
+G.29 Rewrite of Section 9, TLS Ciphersuites
This section contains anachronistic references and needs to be
updated/rewritten in a way that provides useful guidance for future
readers in a way that will transcend the passage of time.
+ Status: Resolved. (6/28/03): Rewrote the section to cover the
+ general issues and considerations involved in selecting TLS
+ ciphersuites.
+
G.30 Update to Appendix A, Example Deployment Scenarios
This section needs to be updated to indicate which security
mechanisms and/or combinations of security mechanisms described
elsewhere in the document can provide the types of protections
suggested in this appendix.
-
+
+G.31 Use of PLAIN SASL Mechanism
+
+ At least one LDAP server implementer has found the SASL "PLAIN"
+ mechanism useful in authenticating to legacy systems that do not
+ represent authentication identities as DNs. Section 3.3.1 appears to
+ implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP.
+ Should we allow the use of this mechanism? I.e. is this "SASL"
+ "PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP
+ doesn't define bindings for these mechanism. If SASL "PLAIN" is
+ allowed, the following adjustments will be needed to section 3.3.1:
+ (a) change section heading, (b) remove reference to "PLAIN" in the
+ section, (c) ensure wording of last sentence regarding non-DN
+ AuthZIDs is consistent with rest of the section.
+
+
+Harrison Expires April 2004 [Page 48]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ Status: Resolved.
+
+ (6/28/03): email to WG list stating issue and asking if we should
+ remove the reference to SASL "PLAIN".
+
+ For -07 draft I've generalized the SASL profile in section 3.3 to
+ allow any SASL mechanism.
+
+
+G.32 Clarification on use of SASL mechanisms
+
+ Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
+ mechanisms? They are not defined in RFC2222. If you refer to other
+ SASL mechanisms than those in rfc2222, Maybe you should only list
+ which mechanisms _are_used, instead of which ones are _not. (Source:
+ Hallvard Furuseth)
+
+ I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section
+ (4.2) should
+ be deleted. ANONYMOUS and PLAIN, like in other mechanism,
+ can be used in LDAP if a) supported and b) enabled. I note
+ that they each offer capabilities not found in their simple
+ bind equivalents (and hence are used in some deployments).
+ For example, PLAIN (over TLS) is quite useful when interacting
+ with legacy authentication subsystems. (Source: Kurt Zeilenga)
+
+ Status: Resolved.
+
+ For -07 draft I've generalized the SASL profile in section 3.3 to
+ allow any SASL mechanism.
+
+
+
+G.33 Clarification on use of password protection based on AuthZID form
+
+ Section 3.3.1: "If an authorization identity of a form different
+ from a DN is requested by the client, a mechanism that protects the
+ password in transit SHOULD be used." What has that to do with DNs?
+ A mechanism that protects the password in transit should be used in
+ any case, shouldn't it?
+
+
+G.34 Clarification on use of matching rules in Server Identity Check
+
+ The text in section 4.1.6 isn't explicit on whether all rules apply
+ to both CN and dNSName values. The text should be clear as to which
+ rules apply to which values.... in particular, the wildcard
+ rules. (Source: Kurt Zeilenga)
+
+
+G.35 Requested Additions to Security Considerations
+
+ Requested to mention hostile servers which the user might have been
+ fooled to into contacting. Which mechanisms that are standardized by
+
+Harrison Expires April 2004 [Page 49]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ the LDAP standard do/do not disclose the user's password to the
+ server? (Or to servers doing man-in-the-middle attack? Or is that a
+ stupid question?)
+
+ Requested to mention denial of service attacks.
+
+ Requested list of methods that need/don't need the server to know
+ the user's plaintext password. (I say 'know' instead of 'store'
+ because it could still store the password encrypted, but in a way
+ which it knows how to decrypt.)
+
+ (Source: Hallvard Furuseth)
+
+G.36 Add reference to definition of DIGEST-MD5
+
+ Need a reference to the definition of DIGEST-MD5 SASL mechanism in
+ section 7.2 (Source: Hallvard Furuseth)
+
+ Status: Resolved. A reference to to the DIGEST-MD5 SASL mechanism,
+ [DigestAuth], is included in the -07 revision.
+
+G.37 Clarification on procedure for certificate-based authentication
+
+
+ 8.1. Certificate-based authentication with TLS states: "Following
+ the successful completion of TLS negotiation, the client will send
+ an LDAP bind request with the SASL "EXTERNAL" mechanism." Is this
+ immediately following, or just some time later? Should the wording,
+ "the client will send..." actually read, "the client MUST send..."?
+
+G.38 Effect of StartTLS on authentication state
+
+ Should the server drop all knowledge of connection, i.e. return to
+ anonymous state, if it gets a StartTLS request on a connection that
+ has successfully bound using the simple method?
+
+G.39 Be sure that there is a consideration in [SCHEMA] that discusses
+multiple password values in userPassword
+
+ Allowing multiple values obviously does raise a number of security
+ considerations and these need to be discussed in the document.
+
+ Certainly applications which intend to replace the userPassword with
+ new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). Additionally, server
+ implementations should be encouraged to provide administrative
+ controls which, if enabled, restrict userPassword to one value.
+
+G.40. Clarify need to verify mapping between authentication identity
+and resulting authorization identity on implicit assertion of AuthZID.
+
+ 4.2.2.3. Error Conditions
+
+ "For either form of assertion, the server MUST verify that the
+
+Harrison Expires April 2004 [Page 50]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ client's authentication identity as supplied in its TLS credentials
+ is permitted to be mapped to the asserted authorization identity."
+
+ This makes sense for the explicit assertion case, but seems to be
+ ambiguous for the implicit case.
+ IMHO, the mapping can be done as two steps:
+ a). deriving LDAP authentication identity from TLS credentials; If t
+ this steps fails, EXTERNAL mechanism returns failure.
+ b). verify that the authorization identity is allowed for the
+ derived authentication identity. This is always "noop" for the
+ implicit case.
+ I am not sure that the text is saying this.
+ (Source: Alexey Melnikov email 8/1/2003 5:30:43 PM)
+
+ Status: Resolved in -07. After reading the comments and the text of
+ the draft, I believe that this should be clarified. The local policy
+ used to map the AuthNID to the AuthZID in the implicit case is
+ sufficient and that no additional verification is useful or needed.
+ This text has been moved to apply only to the explicit assertion
+ case.
+
+G.41. Section 7.2 contains unnecessary and misleading detail.
+
+ " I am not sure why this section is required in the document.
+ DIGEST-MD5 is defined in a separate document and there should be
+ nothing magical about its usage in LDAP. If DIGEST-MD5 description
+ creates confusion for LDAP implementors, let's fix the DIGEST-MD5
+ document! Also, this section tries to redefine DIGEST-MD5 behavior,
+ which is explicitly prohibited by the SASL specification."
+ (Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)
+
+ Status: Resolved.
+
+ After reading the comments and the text of the draft plus the
+ related text in draft-ietf-sasl-rfc2831bis-02.txt plus
+ http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
+ 02.txt, I am inclined to agree with Alexey. In -07 I rewrote section
+ 3.3 (SASL mechanisms) to match the profiling requirements
+ rfc2831bis. I then dramatically reduced the material in section 7.2
+ to a bare minimum and let the SASL profile stand on its own.
+
+G.42. Does change for G.41 cause interoperability issue?
+
+ There is one issue with the way the authmeth draft is currently
+ written that changes the SASL DIGEST-MD5 behavior on the way the
+ server responds with the subsequent authentication information .
+ This has been documented in this fashion since RFC 2829 (section
+ 6.1) was originally published and may cause an interoperability
+ issue at this point if it changed to follow the DIGEST-MD5 spec (as
+ it was in -07 of AuthMeth). Take this issue to the list.
+
+ Status: Resolved
+
+
+
+Harrison Expires April 2004 [Page 51]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ (10/08/03) This item was discussed on the WG list between 5/2/03 and
+ 5/9/03. Consensus apppears to support the notion that RFC 2829 was
+ in error and that the semantics of RFC 2831 are correct and should
+ be reflected in authmeth. This is already the case as of the -07
+ draft.
+
+G.43. DIGEST-MD5 Realms recommendations for LDAP
+
+ From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
+ 02.txt: A protocol profile SHOULD provide a guidance how realms are
+ to be constructed and used in the protocol and MAY further restrict
+ its syntax and protocol-specific semantics."
+
+ I don't believe that any such guidance exists within the LDAP TS.
+ The most likely place for this to reside is in the authmeth draft.
+
+ Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):
+
+ "The problem I have with the document is that it references realm
+ without explaining what it is (or at least some examples of valid
+ values). For LDAP, some recommendations should be given. For
+ example:
+ 1). Use a hardcoded string as the realm (one of the implementations
+ I worked on was doing that)
+ 2). Use hostname (realm==host) or domain/cluster name (realm
+ includes multiple hosts).
+ 3). Use a node in DIT above user entry, for example for "cn=Barbara
+ Jensen, ou=Accounting, o=Ace Industry, c=US"
+ and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be
+ "ou=Accounting, o=Ace Industry, c=US"
+ (or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product
+ Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing,
+ o=Ace Industry, c=US".
+
+ Of course other choices are possible.
+
+ Alexey
+
+ To summarize: I'd like authmeth to define a realm name for use with
+ Digest-MD5 that corresponds to LDAP DNs known to this server.
+ Authzid is okay, but perhaps could be better put into context.
+
+
+ John McMeeking (5/12/2003)
+
+G.44. Use of DNs in usernames and realms in DIGEST-MD5
+
+ In reading the discussion on the mailing list, I reach the following
+ conclusions:
+
+ DIGEST-MD5 username and realm are simple strings. The syntax of
+ these strings allows strings that look like DNs in form, however,
+ DIGEST-MD5 treats them a simple strings for comparision purposes.
+ For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent
+
+Harrison Expires April 2004 [Page 52]
+\f
+Internet-Draft LDAP Authentication Methods 7 October 2003
+
+ when being compared semantically as DNs, however, these would be
+ considered two different username values in DIGEST-MD5 because
+ simple octet-wise semantics (rather than DN semantics) are used to
+ compare username values in DIGEST-MD5. Ditto for realm values.
+
+ Status: Resolved.
+
+ In -07 revision I added notes to implementors expressing this issue
+ in section 7.2.
+
+G.45: Open Issue: Is Simple+TLS mandatory to implement?
+
+ Going forward, it would be much better to clarify that simple
+ +TLS is to be used for DN/password credentials and DIGEST-MD5
+ (or PLAIN+TLS) be used for username/password credentials. (Kurt
+ Zeilenga, 5/12/2003)
+
+ I don't believe you can mandate simple/TLS! At the time RFC 2829 was
+ debated, a large number on the WG wanted this. They did not get
+ their way because of the complexity of the solution. It was argued
+ that a password-based method would be better. I think they believed
+ it would still be DN/password, though. (Ron Ramsay, 5/12/2003)
+
+ This was officially opened as an issue by WG co-chair Kurt Zeilenga
+ on 5/12/03. Little direct discussion has occurred since, however
+ there has been significant discussion on the use of DN values as the
+ username for DIGEST-MD5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Harrison Expires September 2003 [Page 41]
+Harrison Expires April 2004 [Page 53]
\f
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 4 May 2003
+Expires in six months 27 October 2003
Obsoletes: 2253
+
LDAP: String Representation of Distinguished Names
- <draft-ietf-ldapbis-dn-10.txt>
+ <draft-ietf-ldapbis-dn-12.txt>
+
Status of Memo
revision, submitted to the RFC Editor as a Standard Track document
replacing RFC 2253. Distribution of this memo is unlimited.
Technical discussion of this document will take place on the IETF LDAP
- Revision (LDAPbis) Working Group mailing list
+ Revision (LDAPBIS) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2003, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
- Please see the Copyright section near the end of this document for
- more information.
-Abstract
- The X.500 Directory uses distinguished names (DNs) as primary keys to
- entries in the directory. This document defines the string
- representation used in the Lightweight Directory Access Protocol
- (LDAP) to transfer distinguished names. The string representation is
Zeilenga LDAP: Distinguished Names [Page 1]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+Abstract
+
+ The X.500 Directory uses distinguished names (DNs) as primary keys to
+ entries in the directory. This document defines the string
+ representation used in the Lightweight Directory Access Protocol
+ (LDAP) to transfer distinguished names. The string representation is
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.
In X.500-based directory systems [X.500], including those accessed
using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
- distinguished names (DNs) are used to unambiguously refer to a
- directory entry [X.501][Models].
+ distinguished names (DNs) are used to unambiguously refer to directory
+ entries [X.501][Models].
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
directory protocols), DNs are encoded using the Basic Encoding Rules
- (BER) [X.690]. In LDAP, DNs are represented in string form.
+ (BER) [X.690]. In LDAP, DNs are represented in the string form
+ described in this document.
It is important to have a common format to be able to unambiguously
represent a distinguished name. The primary goal of this
to have names that are human readable. It is not expected that LDAP
implementations with a human user interface would display these
strings directly to the user, but would most likely be performing
- translations (such as expressing attribute type names in one of the
- local national languages).
+ translations (such as expressing attribute type names in the local
+ national language).
This document defines the string representation of Distinguished Names
used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
from its ASN.1 structured representation to a string, all algorithms
MUST produce strings which adhere to the requirements of Section 3.
+
+
+Zeilenga LDAP: Distinguished Names [Page 2]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+
This document does not define a canonical string representation for
DNs. Comparison of DNs for equality is to be performed in accordance
with the distinguishedNameMatch matching rule [Syntaxes].
This document is an integral part of the LDAP Technical Specification
[Roadmap].
-
-
-Zeilenga LDAP: Distinguished Names [Page 2]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
-
-
This document obsoletes RFC 2253. Changes since RFC 2253 are
summarized in Appendix B.
This section defines the RECOMMENDED algorithm for converting a
distinguished name from an ASN.1 structured representation to an UTF-8
- [RFC2279] encoded Universal Character Set (UCS) [ISO10646] character
+ [UTF-8] encoded Universal Character Set (UCS) [ISO10646] character
string representation. Other documents may describe other algorithms
for converting a distinguished name to a string, but only strings
which conform to the grammar defined in Section 3 MUST be produced by
2.2), starting with the last element of the sequence and moving
backwards toward the first.
- The encodings of adjoining RelativeDistinguishedNames are separated by
- a comma ("," U+002C) character.
-2.2. Converting RelativeDistinguishedName
+Zeilenga LDAP: Distinguished Names [Page 3]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+ The encodings of adjoining RelativeDistinguishedNames are separated by
+ a comma ("," U+002C) character.
-Zeilenga LDAP: Distinguished Names [Page 3]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
-
+2.2. Converting RelativeDistinguishedName
When converting from an ASN.1 RelativeDistinguishedName to a string,
the output consists of the string encodings of each
encoding of the AttributeValue is given in Section 2.4.
If the AttributeType is defined to have a short name and that short
- name is known to be registered [REGISTRY] as identifying the
+ name is known to be registered [REGISTRY][BCP64bis] as identifying the
AttributeType, that short name, a <descr>, is used. Otherwise the
AttributeType is encoded as the dotted-decimal encoding, a
<numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
is defined in [Models].
- Implementations are not expected dynamically update their knowledge of
- registered short names. However, implementations SHOULD provide a
+ Implementations are not expected to dynamically update their knowledge
+ of registered short names. However, implementations SHOULD provide a
mechanism to allow its knowledge of registered short names to be
updated.
desired (see Section 5.2).
Otherwise, if the AttributeValue is of a syntax which has a native
- string encoding, the value is converted first to a UTF-8 encoded UCS
- string according to its syntax specification (see for example Section
- 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
- of the following characters which need escaping, then that string can
- be used as the string representation of the value.
-
Zeilenga LDAP: Distinguished Names [Page 4]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+ string encoding, the value is converted first to a UTF-8 encoded UCS
+ string according to its syntax specification (see for example Section
+ 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
+ of the following characters which need escaping, then that string can
+ be used as the string representation of the value.
- a space (" " U+0020) or number sign ("#" U+0023) occurring at
the beginning of the string;
3. Parsing a String back to a Distinguished Name
The string representation of Distinguished Names is restricted to
- UTF-8 [RFC2279] encoded characters from the Universal Character Set
+ UTF-8 [UTF-8] encoded characters from the Universal Character Set
(UCS) [ISO10646]. The structure of this string representation is
specified using the following Augmented BNF [RFC2234] grammar:
attributeTypeAndValue = attributeType EQUALS attributeValue
- attributeType = descr / numericoid
-
- attributeValue = string / hexstring
-
- ; The UTF-8 string shall not contain NULL, ESC, or
-
Zeilenga LDAP: Distinguished Names [Page 5]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+ attributeType = descr / numericoid
+
+ attributeValue = string / hexstring
+
+ ; The UTF-8 string shall not contain NULL, ESC, or
; one of escaped, shall not start with SHARP or SPACE,
; and shall must not end with SPACE.
string = [ (leadchar / pair)
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
- If in <hexstring> form, a BER representation can be obtained from
- converting each <hexpair> of the <hexstring> to the octet indicated by
- the <hexpair>.
-
- One or more attribute values assertions, separated by <PLUS>, for a
Zeilenga LDAP: Distinguished Names [Page 6]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+ If in <hexstring> form, a BER representation can be obtained from
+ converting each <hexpair> of the <hexstring> to the octet indicated by
+ the <hexpair>.
+
+ One or more attribute values assertions, separated by <PLUS>, for a
relative distinguished name.
Zero or more relative distinguished names, separated by <COMMA>, for a
OU=Sales+CN=J. Smith,DC=example,DC=net
This example shows the method of escaping of a comma in a common
- name:
-
- CN=John Smith\, III,DC=example,DC=net
-
- An example name in which a value contains a carriage return
Zeilenga LDAP: Distinguished Names [Page 7]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+ name:
+
+ CN=John Smith\, III,DC=example,DC=net
+ An example name in which a value contains a carriage return
character:
CN=Before\0dAfter,DC=example,DC=net
- the common name of the object (i.e. a person's full name)
- an email or TCP/IP address
- - its physical location (country, locality, city, street address)
- - organizational attributes (such as department name or affiliation)
-
- Most countries have privacy laws regarding the publication of
- information about people.
Zeilenga LDAP: Distinguished Names [Page 8]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or affiliation)
+
+ Most countries have privacy laws regarding the publication of
+ information about people.
5.2. Use of Distinguished Names in Security Applications
8. Normative References
- [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993).
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", X.680, 1994.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119).
- [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+Zeilenga LDAP: Distinguished Names [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-Zeilenga LDAP: Distinguished Names [Page 9]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- Specifications: ABNF", RFC 2234, November 1997.
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
+ progress.
- [Models] K. Zeilenga (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
- [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
- [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-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] K. Dally (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1 : 1993.
+ [ISO10646] International Organization for Standardization,
+ "Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane", ISO/IEC
+ 10646-1 : 1993.
+ [REGISTRY] IANA, Object Identifier Descriptors Registry,
+ <http://www.iana.org/...>.
9. Informative References
- [X.500] "The Directory -- overview of concepts, models and
- services," ITU-T Rec. X.500(1993).
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
- [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", X.690,
- 1994.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
- [RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
+Zeilenga LDAP: Distinguished Names [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
-Appendix A. Presentation Issues
- This appendix is provided for informational purposes only, it is not a
- normative part of this specification.
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
+ ietf-ldapbis-bcp64-xx.txt, a work in progress.
-Zeilenga LDAP: Distinguished Names [Page 10]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+Appendix A. Presentation Issues
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of this specification.
The string representation described in this document is not intended
to be presented to humans without translation. However, at times it
demonstrated in the final example of Section 4).
When a DN string is displayed in free form text, it is often necessary
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+
to distinguish the DN string from surrounding text. While this is
often done with white space (as demonstrated in Section 4), it is
noted that DN strings may end with white space. Careful readers of
so it has been line-wrapped for readability. The extra white
space is to be removed before the DN string is used in LDAP.
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 11]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
-
-
It is not advised to insert white space otherwise as it may not be
obvious to the user which white space is part of the DN string and
which white space was added for readability.
The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed.
- - Clarified (in Section 1), that this document does not define a
+ - Clarified (in Section 1) that this document does not define a
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+
canonical string representation.
+ - Revised specification (in Section 2) to allow short names of any
+ registered attribute type to appear in string representations of
+ DNs instead of being restricted to a "published table". Remove
+ "as an example" language. Added statement (in Section 3) allowing
+ recognition of additional names but require recognization of those
+ names in the published table. The table is now published in
+ Section 3.
- Replaced specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4)
with a statement (in Section 3) allowing recognition of
alternative string representations.
- - Clarified (in Section 2.3) that the "published" table of names
- which may be appear in DNs is the table which Section 2.3
- provides. Remove "as an example" language. Noted this table is
- not extensible. Added statement (in Section 3) allowing
- recognition of additional names. Added security considerations
- (Section 5.3) regarding the use of other names.
- Updated Section 2.3 to indicate attribute type name strings are
case insensitive.
- Updated Section 2.4 to allow hex pair escaping of all characters
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
+ In addition, numerous editorial changes were made.
-Zeilenga LDAP: Distinguished Names [Page 12]
+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
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 13]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
+
+
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
- In addition, numerous editorial changes were made.
+Full Copyright
-Copyright 2003, The Internet Society. All Rights Reserved.
+ 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
+ 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
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,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Zeilenga LDAP: Distinguished Names [Page 13]
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 14]
\f
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2254 T. Howes
-Expires: 28 August 2003 Opsware, Inc.
- 28 February 2003
+Expires: 25 April 2004 Opsware, Inc.
+ 25 October 2003
LDAP: String Representation of Search Filters
- <draft-ietf-ldapbis-filter-04.txt>
+ <draft-ietf-ldapbis-filter-05.txt>
Smith & Howes Intended Category: Standards Track [Page 1]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
3. Table of Contents
8. Security Considerations........................................7
9. Normative References...........................................7
10. Informative References.........................................8
-11. Acknowledgments................................................8
-12. Authors' Address...............................................8
-13. Full Copyright Statement.......................................9
-14. Appendix A: Changes Since RFC 2254.............................9
-14.1. Technical Changes...........................................9
-14.2. Editorial Changes...........................................10
-15. Appendix B: Changes Since Previous Document Revision...........11
-15.1. Technical Changes...........................................11
-15.2. Editorial Changes...........................................11
+11. Intellectual Property Rights...................................8
+12. Acknowledgments................................................8
+13. Authors' Address...............................................8
+14. Full Copyright Statement.......................................9
+15. Appendix A: Changes Since RFC 2254.............................9
+15.1. Technical Changes...........................................10
+15.2. Editorial Changes...........................................10
+16. Appendix B: Changes Since Previous Document Revision...........11
+16.1. Technical Changes...........................................12
+16.2. Editorial Changes...........................................12
4. Introduction
-
Smith & Howes Intended Category: Standards Track [Page 2]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
Filter ::= CHOICE {
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- ISO 10646 characters
- where the LDAPString above is limited to the UTF-8 encoding [RFC2279]
+ where the LDAPString above is limited to the UTF-8 encoding [UTF-8]
of the ISO 10646 character set [ISO10646]. The AttributeDescription
is a string representation of the attribute description and is
defined in [Protocol]. The AttributeValue and AssertionValue OCTET
Smith & Howes Intended Category: Standards Track [Page 3]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
STRING have the form defined in [Syntaxes]. The Filter is encoded
extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
/ [dnattrs] matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
- present = attr EQUALS ASTERIX
+ present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
- any = ASTERIX *(assertionvalue ASTERIX)
+ any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
- ; RPAREN, ASTERIX, and ESC.
+ ; RPAREN, ASTERISK, and ESC.
Smith & Howes Intended Category: Standards Track [Page 4]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
- ASTERIX = %x2A ; asterix ("*")
+ ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
As indicated by the valueencoding rule, implementations MUST escape
all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a
- search filter. Since RFC 2254 does not clearly define the term
- "string representation" (and in particular does mention that the
- string representation of an LDAP search filter is a string of UTF-8
- encoded ISO 10646-1 characters) implementations SHOULD accept as
- input strings that include invalid UTF-8 octet sequences.
+ search filter. Implementations SHOULD accept as input a string that
+ includes invalid UTF-8 octet sequences. This is necessary because RFC
+ 2254 did not clearly define the term "string representation" (and in
+ particular did not mention that the string representation of an LDAP
+ search filter is a string of UTF-8 encoded ISO 10646-1 characters).
7. Examples
Smith & Howes Intended Category: Standards Track [Page 5]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
(!(cn=Tim Howes))
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:dn:2.4.6.8.10:=Dino)
- (:=Fred Flintstone)
The first example shows use of the matching rule "1.2.3.4.5".
The fifth example is a filter that should be applied to any attribute
supporting the matching rule given (since the attr has been omitted).
- The sixth example is also a filter that should be applied to any
- attribute supporting the matching rule given. Attributes supporting
- the matching rule contained in the DN should also be considered.
-
- The seventh and final example is a filter that should be applied to
- any attribute (since both the attr and matching rule have been
- omitted).
+ The sixth and final example is also a filter that should be applied
+ to any attribute supporting the matching rule given. Attributes
+ supporting the matching rule contained in the DN should also be
+ considered.
The following examples illustrate the use of the escaping mechanism.
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in an assertion value, preventing it from being interpreted as a
+
Smith & Howes Intended Category: Standards Track [Page 6]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
- The first example shows the use of the escaping mechanism to
- represent parenthesis characters. The second shows how to represent a
- "*" in an assertion value, preventing it from being interpreted as a
substring indicator. The third illustrates the escaping of the
backslash character.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
Smith & Howes Intended Category: Standards Track [Page 7]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
-
-
- [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx.txt, a work in progress.
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ draft-yergeau-rfc2279bis-xx.txt, a work in progress.
10. Informative References
None.
-
-11. Acknowledgments
+11. 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.
+
+12. Acknowledgments
This document replaces RFC 2254 by Tim Howes. Changes included in
this revised specification are based upon discussions among the
acknowledged.
-12. Authors' Address
+13. Authors' Address
Mark Smith, Editor
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
+
+
Netscape Communications Corp.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
+1 650 937-3477
- mcs@netscape.com
+ MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
+1 408 744-7509
howes@opsware.com
+14. Full Copyright Statement
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ 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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-14. Appendix A: Changes Since RFC 2254
+15. Appendix A: Changes Since RFC 2254
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
+
-14.1. Technical Changes
+15.1. Technical Changes
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
precisely reference productions from the [Models] and [Protocol]
documents.
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
-
-
Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences.
of a clear definition of "string representation."
-14.2. Editorial Changes
+15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
- "Table of Contents" section: added.
+ "Table of Contents" and "Intellectual Property Rights" sections:
+ added.
- Copyright: updated the year.
+ Copyright: updated per latest IETF guidelines.
"Abstract" section: separated from introductory material.
"Introduction" section: new section; separated from the Abstract.
Updated second paragraph to indicate that RFC 2254 is replaced by
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
+
+
this document (instead of RFC 1960). Added reference to the [Roadmap]
document.
escaped is replaced by a backslash and two hex digits, which
represent a single octet.
- "Examples" section: added five additional examples: (seeAlso=),
- (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), (:=Fred Flintstone),
- and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
+ "Examples" section: added four additional examples: (seeAlso=),
+ (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
+ (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value".
"Security Considerations" section: added references to [Protocol] and
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
-
-
[AuthMeth].
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added entries for [ISO10646], [RFC2119], [AuthMeth],
- [Models], and [Roadmap] and updated UTF-8 reference to RFC 2279.
- Replaced RFC 822 reference with a reference to RFC 2234.
+ [Models], and [Roadmap] and updated the UTF-8 reference. Replaced
+ RFC 822 reference with a reference to RFC 2234.
"Informative References" section: added for clarity.
added.
-15. Appendix B: Changes Since Previous Document Revision
+16. Appendix B: Changes Since Previous Document Revision
- This appendix lists all changes relative to the last published
- revision, draft-ietf-ldapbis-filter-03.txt. Note that when
+ This appendix lists all changes relative to the previously published
+ revision, draft-ietf-ldapbis-filter-04.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
- reviewed draft-ietf-ldapbis-filter-03.txt. This section will be
+ reviewed draft-ietf-ldapbis-filter-04.txt. This section will be
removed before this document is published as an RFC.
-15.1. Technical Changes
-
- "String Search Filter Definition" section: Added statement that the
- string representation is a string of UTF-8 encoded ISO 10646-1
- characters and statement about expected behavior in light of RFC
- 2254's lack of a clear definition of "string representation."
-
- "String Search Filter Definition" section: Revised all of the ABNF to
- use common productions from [Models]. Revised the "normal"
- production to restrict filter strings to valid UTF-8 sequences.
-
-
-15.2. Editorial Changes
-
- "Status of this Memo" section: updated boilerplate to match current
- I-D guidelines.
-
- "Examples" section: removed ;binary from an example.
- "LDAP Search Filter Definition " section: updated section references
Smith & Howes Intended Category: Standards Track [Page 11]
\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
-
-
- to match current LDAPBis drafts. Made minor changes to the ASN.1 so
- it exactly matches that used in the Protocol document (added
- comments).
-
- "Normative References" section: added references to [ISO10646],
- [RFC2119] and [Models].
-
- "Informative References" section: added for clarity.
-
- Updated copyright year to 2003.
-
-
-This Internet Draft expires on 28 August 2003.
-
-
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
+16.1. Technical Changes
+ "Examples" section: Removed the (:=Fred Flintstone) example which is
+ not allowed by the protocol.
+16.2. Editorial Changes
+ "String Search Filter Definition" section: Revised the last two
+ sentences in this section to improve clarity (the updated text now
+ begins with the text "Implementations SHOULD accept as input a string
+ that includes...."
+ Replaced all occurrences of "asterix" with the correctly spelled
+ "asterisk."
+ "Normative References" section: changed UTF-8 reference to point to
+ the UTF-8 Internet Draft.
+ "Intellectual Property Rights" section: added.
+ Author's Addresses section: New email address for Mark Smith.
+ "Full Copyright Statement" section: updated text to match latest IETF
+ guidelines.
+This Internet Draft expires on 25 April 2004.
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 March 2003
+Expires in six months 27 October 2003
Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models
- <draft-ietf-ldapbis-models-07.txt>
+ <draft-ietf-ldapbis-models-09.txt>
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2003, The Internet Society. All Rights Reserved. Please
- see the Copyright section near the end of this document for more
- information.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
Abstract
-
Zeilenga LDAP Models [Page 1]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Table of Contents
Table of Contents 2
1. Introduction 3
1.1. Relationship to Other LDAP Specifications
- 1.2. Relationship to ITU Specifications
- 1.3. Conventions 4
+ 1.2. Relationship to X.501 4
+ 1.3. Conventions
1.4. Common ABNF Productions
2. Model of Directory User Information 6
- 2.1. The Directory Information Tree
- 2.2. Naming of Entries 7
+ 2.1. The Directory Information Tree 7
+ 2.2. Naming of Entries
2.3. Structure of an Entry 8
- 2.4. Object Classes
+ 2.4. Object Classes 9
2.5. Attribute Descriptions 11
2.6. Alias Entries 15
- 3. Directory Administrative and Operational Information 16
+ 3. Directory Administrative and Operational Information 17
3.1. Subtrees
- 3.2. Subentries 17
- 3.3. The 'objectClass' attribute
- 3.4. Operational attributes 18
- 4. Directory Schema 20
- 4.1. Schema Definitions 21
- 4.2. Subschema Subentries 30
+ 3.2. Subentries
+ 3.3. The 'objectClass' attribute 18
+ 3.4. Operational attributes
+ 4. Directory Schema 21
+ 4.1. Schema Definitions 22
+ 4.2. Subschema Subentries 31
4.3. 'extensibleObject' 34
- 4.4. Subschema Discovery
+ 4.4. Subschema Discovery 35
5. DSA (Server) Informational Model
- 5.1. Server-specific Data Requirements 35
- 6. Other Considerations 38
+ 5.1. Server-specific Data Requirements 36
+ 6. Other Considerations 39
6.1. Preservation of User Information
6.2. Short Names
- 6.3. Cache and Shadowing 39
- 7. Implementation Guidelines 40
+ 6.3. Cache and Shadowing 40
+ 7. Implementation Guidelines
7.1. Server Guidelines
- 7.2. Client Guidelines
- 8. Security Considerations 41
+ 7.2. Client Guidelines 41
+ 8. Security Considerations
9. IANA Considerations
10. Acknowledgments 42
11. Author's Address
- 12. References
+ 12. References 43
12.1. Normative References
- 12.2. Informative References 43
+ 12.2. Informative References 44
Appendix A. Changes
A.1 Changes to RFC 2251 44
A.2 Changes to RFC 2252 46
- A.3 Changes to RFC 2256 47
- Copyright
+ A.3 Changes to RFC 2256 48
+ Intellectual Property Rights
Zeilenga LDAP Models [Page 2]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+
+ Full Copyright 49
1. Introduction
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these
- sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
- [AuthMeth], and [Roadmap] documents.
-
Zeilenga LDAP Models [Page 3]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+ sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
+ [AuthMeth], and [Roadmap] documents.
+
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
summaries changes to these sections. The remainder of RFC 2252 is
- obsoleted by [Syntaxes] and [Schema].
+ obsoleted by [Syntaxes].
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of
1.2. Relationship to X.501
This document includes material, with and without adaptation, from the
- [X.501]. Due to the adaptation, the material included in this
- document takes precedence.
+ [X.501]. The material in this document takes precedence over that in
+ [X.501].
1.3. Conventions
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
- HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
-
- SP = 1*SPACE ; one or more " "
Zeilenga LDAP Models [Page 4]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+ HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
+ SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
; Any UTF-8 character
UTF8 = UTF1 / UTFMB
- UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
+ UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
- UTF2 = %xC0-DF 1(UTF0)
- UTF3 = %xE0-EF 2(UTF0)
- UTF4 = %xF0-F7 3(UTF0)
- UTF5 = %xF8-FB 4(UTF0)
- UTF6 = %xFC-FD 5(UTF0)
+ UTF2 = %xC2-DF UTF0
+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+ %xF4 %x80-8F 2(UTF0)
; Any octet
OCTET = %x00-FF
- Object identifiers are represented in LDAP using a dot-decimal format
- conforming to the ABNF:
+ Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
+ decimal format conforming to the ABNF:
numericoid = number *( DOT number )
Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and
- conform to the ABNF:
-
- descr = keystring
Zeilenga LDAP Models [Page 5]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+ conform to the ABNF:
+
+ descr = keystring
Where either an object identifier or a short name may be specified,
the following production is used:
provides alternative naming. A subentry holds administrative and/or
operational information.
- The set of entries representing the DIB are organized hierarchically
- in a tree structure known as the Directory Information Tree (DIT).
-
-
Zeilenga LDAP Models [Page 6]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree
Section 2.2 discusses naming of entries.
immediate subordinates of the entry's immediate superior (i.e., all
siblings).
- The following are example string representations of RDNs [LDAPDN]:
-
-
Zeilenga LDAP Models [Page 7]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+ The following are example string representations of RDNs [LDAPDN]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
-
Zeilenga LDAP Models [Page 8]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Two values are considered equivalent if they would match according to
Zeilenga LDAP Models [Page 9]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
allowed to be present in entries belonging to the class. As an entry
Zeilenga LDAP Models [Page 10]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Structural object classes are related to associated entries:
Zeilenga LDAP Models [Page 11]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2.5.1) and a set of zero or more attribute options (see Section
Zeilenga LDAP Models [Page 12]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
syntax of its supertype. An attribute type cannot be a subtype of an
Not all options can be associated with attributes held in the
directory. Tagging options can be.
- Not all options can be use in conjunction with all attribute types.
+ Not all options can be used in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
conforming to the <option> production defined in Section 2.5 of this
document.
- Procedures for registering options are detailed in BCP 64 [RFC3383].
+ Procedures for registering options are detailed in BCP 64 [BCP64bis].
2.5.2.1. Tagging Options
Zeilenga LDAP Models [Page 13]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
An attribute description with N tagging options is considered a direct
Zeilenga LDAP Models [Page 14]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
precisely one attribute description. The description is indicated
Zeilenga LDAP Models [Page 15]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
NOTE - The name within the 'aliasedObjectName' is said to be
Zeilenga LDAP Models [Page 16]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.4.1 NAME 'aliasedObjectName'
Zeilenga LDAP Models [Page 17]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
subentry (e.g., 'subschema' for subschema subentries) to mimic the
all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a' is
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
- 'x-b' to added (if is not already present).
+ 'x-b' to be implicitly added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent a
superclasses of remaining 'objectClass' values from being deleted.
Zeilenga LDAP Models [Page 18]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g.
- 'createTimeStamp') as well as operational attributes which hold values
+ 'createTimestamp') as well as operational attributes which hold values
administrated by the user (e.g. 'ditContentRules').
A DSA-shared operational attribute is used to represent information of
Zeilenga LDAP Models [Page 19]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
Zeilenga LDAP Models [Page 20]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.18.2 NAME 'modifyTimestamp'
Zeilenga LDAP Models [Page 21]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
structural object classes of the entries;
Zeilenga LDAP Models [Page 22]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
qdstring = SQUOTE dstring SQUOTE
Zeilenga LDAP Models [Page 23]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
- [ SP "SUP" SP oid ] ; subtype
+ [ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
Zeilenga LDAP Models [Page 24]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
Zeilenga LDAP Models [Page 25]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Attribute Type Description. This bound is not part of the syntax name
Zeilenga LDAP Models [Page 26]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
MatchingRuleUseDescription = LPAREN WSP
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to string of Universal Character Set (UCS)
- [ISO10646] characters in UTF-8 [RFC2279] form.
+ [ISO10646] characters in UTF-8 [UTF-8] form.
Each LDAP syntax is identified by an object identifier (OID).
Zeilenga LDAP Models [Page 27]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
For DIT entries of a particular structural object class, a DIT content
Zeilenga LDAP Models [Page 28]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is the object identifier of the structural object class
Zeilenga LDAP Models [Page 29]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
where:
Zeilenga LDAP Models [Page 30]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is object identifier which identifies this name form;
Zeilenga LDAP Models [Page 31]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Subschema is held in (sub)entries belonging to the subschema auxiliary
Zeilenga LDAP Models [Page 32]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
4.2.3. 'matchingRules'
Zeilenga LDAP Models [Page 33]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
Zeilenga LDAP Models [Page 34]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Note that not all servers will implement this object class, and those
Zeilenga LDAP Models [Page 35]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
5.1. Server-specific Data Requirements
- supportedLDAPVersion: LDAP versions supported; and
- - supportedSASLMechanisms: recognized SASL mechnanisms.
+ - supportedSASLMechanisms: recognized Simple Authentication and
+ Security Layers (SASL) [SASL] mechanisms.
The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL
Section 4.4.
-5.1.1. 'altServer'
Zeilenga LDAP Models [Page 36]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+5.1.1. 'altServer'
+
The 'altServer' attribute lists URLs referring to alternative servers
which may be contacted when this server becomes unavailable. If the
server does not know of any other servers which could be used this
Object identifiers identifying response controls need not be listed.
Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [RFC3383].
-
- ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
Zeilenga LDAP Models [Page 37]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
extended operation need not be listed.
Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [RFC3383].
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
- [RFC2222] which the server recognizes. The contents of this attribute
Zeilenga LDAP Models [Page 38]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+ [RFC2222] which the server recognizes. The contents of this attribute
may depend on the current session state. If the server does not
support any SASL mechanisms this attribute will not be present.
Implementations MUST be prepared that the same short name might be
used in a subschema to refer to the different kinds of schema
- elements. That is, there might be an object class 'x-fubar' and an
Zeilenga LDAP Models [Page 39]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+ elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema.
Implementations MUST be prepared that the same short name might be
in different subschemas.
Procedures for registering short names (descriptors) are detailed in
- BCP 64 [RFC3383bis].
-
- [[The remainder of this subsection will be included a subsequent
- revision of RFC 3383.]]
-
- To avoid interoperability problems, the following additional
- considerations are stated:
-
- Descriptors used to identify various schema elements SHOULD be
- registered unless in private-use name space (e.g., they begin with
- "x-"). Descriptors defined in RFCs MUST be registered.
-
- While the protocol allows the same descriptor to refer to
- different object identifiers in certain cases and the registry
- supports multiple registrations of the same descriptor (each
- indicating a different kind of schema element and different object
- identifier), multiple registrations of the same descriptor are to
- be avoided. All such registration requests require Expert Review.
+ BCP 64 [BCP64bis].
6.3. Cache and Shadowing
the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema].
-
-
-
-Zeilenga LDAP Models [Page 40]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
-
-
Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints.
Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema
+
+
+
+Zeilenga LDAP Models [Page 40]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+
(sub)entries.
9. IANA Considerations
-
-
-
-Zeilenga LDAP Models [Page 41]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
-
-
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated the following
template:
The following descriptors (short names) should be updated to refer
to RFC XXXX.
+
+
+Zeilenga LDAP Models [Page 41]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
10. Acknowledgments
-
-
-Zeilenga LDAP Models [Page 42]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
-
-
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
- This document is a product of the IETF LDAPBIS Working Group.
+ This document is a product of the IETF LDAP Revison (LDAPBIS) Working
+ Group.
11. Author's Address
E-mail: <kurt@openldap.org>
+
+Zeilenga LDAP Models [Page 42]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
+
12. References
12.1. Normative References
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2119] S. Bradner, "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.
- [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
+ ietf-ldapbis-bcp64-xx.txt, a work in progress.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
- [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [Protocol] J. Sermersheim (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.
- [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
- [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress.
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+ Security Layer (SASL)",
+ draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-Zeilenga LDAP Models [Page 43]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
- [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
- of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
- work in progress.
- [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
+Zeilenga LDAP Models [Page 43]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+ progress.
- [Schema] K. Dally (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
+ [ISO10646] International Organization for Standardization,
+ "Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane", ISO/IEC
+ 10646-1 : 1993.
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
- : 1993.
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
- [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", 1994.
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
12.2. Informative References
+
Zeilenga LDAP Models [Page 44]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
A.1.1 Section 3.2 of RFC 2251
Changes:
- Clarify that attributes of the root DSE are subject to "other
- restrictions" in addition to acccess controls.
+ restrictions" in addition to access controls.
- Clarify that only recognized extended requests need to be enumerated
'supportedExtension'.
Zeilenga LDAP Models [Page 45]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
- Remove inconsistent text regarding handling of the
Zeilenga LDAP Models [Page 46]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
specification "descr is the syntactic representation of an object
Zeilenga LDAP Models [Page 47]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
interacts with precluded attributes.
document.
-Copyright 2003, The Internet Society. 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.
+Intellectual Property Rights
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
+ 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.
- 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,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ 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.
Zeilenga LDAP Models [Page 48]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
-
-
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
+INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
+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.
-
Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-13.txt Mar 2003
-Obsoletes: RFC 2251
+Document: draft-ietf-ldapbis-protocol-19.txt Dec 2003
+Obsoletes: RFC 2251, 2830
LDAP: The Protocol
Abstract
This document describes the protocol elements, along with their
- semantics and encodings, for 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).
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
Table of Contents
- 1. Introduction.....................................................2
- 2. Conventions......................................................3
- 3. Protocol Model...................................................3
- 4. Elements of Protocol.............................................3
- 4.1. Common Elements................................................4
- 4.1.1. Message Envelope.............................................4
- 4.1.2. String Types.................................................6
- 4.1.3. Distinguished Name and Relative Distinguished Name...........6
+ 1. Introduction....................................................2
+ 1.1. Relationship to Obsolete Specifications.......................3
+ 2. Conventions.....................................................3
+ 3. Protocol Model..................................................3
+ 4. Elements of Protocol............................................4
+ 4.1. Common Elements...............................................4
+ 4.1.1. Message Envelope............................................4
+ 4.1.2. String Types................................................6
-Sermersheim Internet-Draft - Expires Sep 2003 Page 1 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 1 \f
Lightweight Directory Access Protocol Version 3
- 4.1.4. Attribute Descriptions.......................................6
- 4.1.5. Attribute Value..............................................7
- 4.1.6. Attribute Value Assertion....................................7
- 4.1.7. Attribute....................................................7
- 4.1.8. Matching Rule Identifier.....................................8
- 4.1.9. Result Message...............................................8
- 4.1.10. Referral...................................................10
- 4.1.11. Controls...................................................11
- 4.2. Bind Operation................................................12
- 4.3. Unbind Operation..............................................14
- 4.4. Unsolicited Notification......................................15
- 4.5. Search Operation..............................................16
- 4.6. Modify Operation..............................................23
- 4.7. Add Operation.................................................24
- 4.8. Delete Operation..............................................25
- 4.9. Modify DN Operation...........................................26
- 4.10. Compare Operation............................................27
- 4.11. Abandon Operation............................................28
- 4.12. Extended Operation...........................................28
- 4.13. Start TLS Operation..........................................29
- 5. Protocol Element Encodings and Transfer.........................31
- 5.1. Protocol Encoding.............................................31
- 5.2. Transfer Protocols............................................31
- 6. Implementation Guidelines.......................................32
- 6.1. Server Implementations........................................32
- 6.2. Client Implementations........................................32
- 7. Security Considerations.........................................32
- 8. Acknowledgements................................................33
- 9. Normative References............................................33
- 10. Editor's Address...............................................34
- Appendix A - LDAP Result Codes.....................................35
- A.1 Non-Error Result Codes.........................................35
- A.2 Error Result Codes.............................................35
- A.3 Classes and Precedence of Error Result Codes...................35
- Appendix C - Change History........................................46
- C.1 Changes made to RFC 2251:......................................46
- C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:............46
- C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:............47
- C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:............47
- C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:............49
- C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:............51
- C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:............51
- C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:............52
- C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:............55
- C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt:...........55
- C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt:...........55
- C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt:...........55
- C.13 Changes made to draft-ietf-ldapbis-protocol-11.txt:...........56
- C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt:...........56
- Appendix D - Outstanding Work Items................................56
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........6
+ 4.1.4. Attribute Descriptions......................................7
+ 4.1.5. Attribute Value.............................................7
+ 4.1.6. Attribute Value Assertion...................................7
+ 4.1.7. Attribute and PartialAttribute..............................8
+ 4.1.8. Matching Rule Identifier....................................8
+ 4.1.9. Result Message..............................................8
+ 4.1.10. Referral..................................................10
+ 4.1.11. Controls..................................................11
+ 4.2. Bind Operation...............................................12
+ 4.3. Unbind Operation.............................................15
+ 4.4. Unsolicited Notification.....................................16
+ 4.5. Search Operation.............................................17
+ 4.6. Modify Operation.............................................25
+ 4.7. Add Operation................................................26
+ 4.8. Delete Operation.............................................27
+ 4.9. Modify DN Operation..........................................28
+ 4.10. Compare Operation...........................................29
+ 4.11. Abandon Operation...........................................30
+ 4.12. Extended Operation..........................................30
+ 4.13. StartTLS Operation..........................................31
+ 5. Protocol Element Encodings and Transfer........................33
+ 5.1. Protocol Encoding............................................34
+ 5.2. Transfer Protocols...........................................34
+ 6. Security Considerations........................................34
+ 7. Acknowledgements...............................................36
+ 8. Normative References...........................................36
+ 9. Informative References.........................................37
+ 10. IANA Considerations...........................................37
+ 11. Editor's Address..............................................38
+ Appendix A - LDAP Result Codes....................................39
+ A.1 Non-Error Result Codes........................................39
+ A.2 Result Codes..................................................39
+ Appendix B - Complete ASN.1 Definition............................43
+ Appendix C - Changes..............................................48
+ C.1 Changes made to made to RFC 2251:.............................48
+ C.2 Changes made to made to RFC 2830:.............................53
1. Introduction
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 2 \f
- Lightweight Directory Access Protocol Version 3
-
The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. A Directory user, which may be a human
+ 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 Lightweight Directory
- Access Protocol, along with their semantics. Following the
- description of protocol elements, it describes the way in which the
- protocol is encoded and transferred.
+ 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.
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 2 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+1.1. Relationship to Obsolete Specifications
This document is an integral part of the LDAP Technical Specification
- [Roadmap].
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes all of RFC 2251 except the following:
+ 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].
+ Section 3.3 is obsoleted by [Roadmap].
+ Sections 4.2.1 (portions), and 4.2.2 are obsoleted by [AuthMeth].
- This document replaces RFC 2251. Appendix C holds a detailed log of
- changes to RFC 2251. Prior to Working Group Last Call, this appendix
- will be distilled to a summary of changes to RFC 2251.
+ Appendix C.1 summarizes substantive changes to the remaining
+ sections.
+
+ This document also obsoletes RFC 2830, Sections 2 and 4 in entirety.
+ The remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2
+ summarizes substantive changes to the remaining sections.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
- to be interpreted as described in [RFC2119].
+ to be interpreted as described in [Keyword].
+
+ The terms "connection" and "LDAP connection" both refer to the
+ underlying transport protocol connection between two protocol peers.
+
+ The term "TLS connection" refers to a TLS-protected LDAP connection.
+
+ The terms "association" and "LDAP association" both refer to the
+ association of the LDAP connection and its current authentication and
+ authorization state.
3. Protocol Model
performing protocol operations against servers. In this model, a
client transmits a protocol request describing the operation to be
performed to a server. The server is then responsible for performing
- the necessary operation(s) in the directory. Upon completion of the
- operation(s), the server returns a response containing any results or
- errors to the requesting client.
+ the necessary operation(s) in the Directory. Upon completion of the
+ operation(s), the server returns a response containing an appropriate
+ result code to the requesting client.
- Note that although servers are required to return responses whenever
- such responses are defined in the protocol, there is no requirement
- for synchronous behavior on the part of either clients or servers.
+ Although servers are required to return responses whenever such
+ responses are defined in the protocol, there is no requirement for
+ synchronous behavior on the part of either clients or servers.
Requests and responses for multiple operations may be exchanged
between a client and server in any order, provided the client
eventually receives a response for every request that requires one.
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 3 \f
+ Lightweight Directory Access Protocol Version 3
+
- Note that the core protocol operations defined in this document can
- be mapped to a subset of the X.500(1997) directory abstract service.
- However there is not a one-to-one mapping between LDAP protocol
- operations and DAP operations. Server implementations acting as a
- gateway to X.500 directories may need to make multiple DAP requests.
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service. However
+ there is not a one-to-one mapping between LDAP protocol 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.
4. Elements of Protocol
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 3 \f
- Lightweight Directory Access Protocol Version 3
-
- The LDAP protocol is described using Abstract Syntax Notation 1
- (ASN.1) [X.680], and is transferred using a subset of ASN.1 Basic
- Encoding Rules [X.690]. Section 5.1 specifies how the protocol is
+ The LDAP 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.1 specifies how the protocol elements are
encoded and transferred.
In order to support future Standards Track extensions to this
protocol, extensibility is implied where it is allowed (per ASN.1).
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 ignore trailing
- SEQUENCE elements whose tags they do not recognize.
+ implied extensibility, clients and servers MUST (unless otherwise
+ specified) ignore trailing SEQUENCE components whose tags they do not
+ recognize.
Changes to the LDAP 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 bind request,
- described in section 4.2. If a client has not sent a bind, the server
+ 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 determine the protocol versions a server supports by
- reading the supportedLDAPVersion attribute from the root DSE
- [Models]. Servers which implement version 3 or later MUST provide
- this attribute.
+ reading the supportedLDAPVersion attribute from the root DSE (DSA-
+ Specific Entry) [Models].
4.1. Common Elements
- This section describes the LDAPMessage envelope PDU (Protocol Data
- Unit) format, as well as data type definitions, which are used in the
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
protocol operations.
as follows:
LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
-Sermersheim Internet-Draft - Expires Sep 2003 Page 4 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 4 \f
Lightweight Directory Access Protocol Version 3
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse,
- ... },
- controls [0] Controls OPTIONAL }
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ... },
+ controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
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 MAY return the Notice of Disconnection
- described in section 4.4.1, with resultCode protocolError, and MUST
- immediately close the connection.
+ 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 close the connection.
In other cases where the client or server cannot parse a PDU, it
SHOULD abruptly close the connection where further communication
implementations MUST return an appropriate response to the request,
with the resultCode set to protocolError.
- The ASN.1 type Controls is defined in section 4.1.11.
+ The ASN.1 type Controls is defined in Section 4.1.11.
4.1.1.1. Message ID
messageID value of the corresponding request LDAPMessage.
The message ID of a request MUST have a non-zero value different from
- the values of any other requests outstanding in the LDAP session of
- which this message is a part. The zero value is reserved for the
+ the values of any other requests outstanding in the LDAP association
+ of which this message is a part. The zero value is reserved for the
unsolicited notification message.
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 5 \f
+ Lightweight Directory Access Protocol Version 3
+
Typical clients increment a counter for each request.
A client MUST NOT send a request with the same message ID as an
- earlier request on the same connection unless it can be determined
- that the server is no longer servicing the earlier request. Otherwise
- the behavior is undefined. For operations that do not return
- responses (unbind, abandon, and abandoned operations), the client
- SHOULD assume the operation is in progress until a subsequent bind
- request completes.
+ earlier request on the same LDAP association unless it can be
+ determined that the server is no longer servicing the earlier
+ request. Otherwise the behavior is undefined. For operations that do
+ not return responses (unbind, abandon, and abandoned operations), the
+ client SHOULD assume the operation is in progress until a subsequent
+ bind request completes.
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 5 \f
- Lightweight Directory Access Protocol Version 3
-
4.1.2. String Types
The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as OCTET STRING types, the
- [ISO10646] character set (a superset of Unicode) is used, encoded
- following the UTF-8 algorithm [RFC2279]. Note that in the UTF-8
- algorithm characters which are the same as ASCII (0x0000 through
- 0x007F) are represented as that same ASCII character in a single
- byte. The other byte values are used to form a variable-length
- encoding of an arbitrary character.
+ 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,
- -- ISO 10646 characters
+ -- [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.3 of [Models].
+ <numericoid> given in Section 1.3 of [Models].
- LDAPOID ::= OCTET STRING -- Constrained to numericoid [Models]
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
For example,
4.1.3. Distinguished Name and Relative Distinguished Name
- An LDAPDN and a RelativeLDAPDN are respectively defined to be the
- representation of a distinguished-name and a relative-distinguished-
- name after encoding according to the specification in [LDAPDN].
+ 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]
- LDAPDN ::= LDAPString
- -- Constrained to distinguishedName [LDAPDN]
+ 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]
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 6 \f
+ Lightweight Directory Access Protocol Version 3
+
4.1.4. Attribute Descriptions
The definition and encoding rules for attribute descriptions are
is an attribute type and zero or more options.
AttributeDescription ::= LDAPString
- -- Constrained to attributedescription
- -- [Models]
+ -- Constrained to <attributedescription>
+ -- [Models]
- An AttributeDescriptionList describes a list of 0 or more attribute
- descriptions. (A list of zero elements has special significance in
- the Search request.)
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 6 \f
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
4.1.5. Attribute Value
A field of type AttributeValue is an OCTET STRING containing an
- encoded attribute value data type. The value is encoded according to
- its LDAP-specific encoding definition. The LDAP-specific encoding
- definitions for different syntaxes and attribute types may be found
- in other documents, and in particular [Syntaxes].
+ 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
photographs).
Attributes may be defined which have arbitrary and non-printable
- syntax. Implementations MUST NOT display nor attempt to decode as
- ASN.1, a value if its syntax is not known. The implementation may
- attempt to discover the subschema of the source entry, and retrieve
- the values of attributeTypes from it.
+ syntax. Implementations MUST NOT display nor attempt to decode a
+ 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 NOT send attribute values in a request that are not
valid according to the syntax defined for the attributes.
4.1.6. Attribute Value Assertion
The AttributeValueAssertion type definition is similar to the one in
- the X.500 directory standards. It contains an attribute description
+ the X.500 Directory standards. It contains an attribute description
and a matching rule assertion value suitable for that type.
AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
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
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 7 \f
+ Lightweight Directory Access Protocol Version 3
+
the value syntax. See objectIdentiferFirstComponentMatch in
[Syntaxes] for an example.
-4.1.7. Attribute
+4.1.7. Attribute and PartialAttribute
- An attribute consists of an attribute description and one or more
- values of that attribute description. (Though attributes MUST have at
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 7 \f
- Lightweight Directory Access Protocol Version 3
-
- least one value when stored, due to access control restrictions the
- set may be empty when transferred from the server to the client. This
- is described in section 4.5.2, concerning the PartialAttributeList
- type.)
+ Attributes and partial attributes consist of an attribute description
+ and values of that attribute description. A PartialAttribute allows
+ zero values, while Attribute requires at least one value.
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
- Each attribute value is distinct in the set (no duplicates). The set
- of attribute values is unordered. Implementations MUST NOT reply upon
- any apparent ordering being repeatable.
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+ Each attribute value is distinct in the set (no duplicates). 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 4.1.3 of [Models]. A matching rule is
identified in the LDAP protocol by the printable representation of
- either its numericoid, or one of its short name descriptors, e.g.
- "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
+ either its <numericoid>, or one of its short name descriptors
+ [Models], e.g. "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
MatchingRuleId ::= LDAPString
-
- Servers which support matching rules for use in the extensibleMatch
- search filter MUST list the matching rules they implement in
- subschema entries, using the matchingRules attributes. The server
- SHOULD also list there, using the matchingRuleUse attribute, the
- attribute types with which each matching rule can be used. More
- information is given in section 4.5 of [Syntaxes].
-
+
4.1.9. Result Message
of a protocol operation request.
LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
-Sermersheim Internet-Draft - Expires Sep 2003 Page 8 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 8 \f
Lightweight Directory Access Protocol Version 3
- 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),
- ... },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- The result codes enumeration is extensible as defined in Section 3.5
- of [LDAPIANA]. The meanings of the result codes are given in Appendix
- A.
+ 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),
+ ... },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ The resultCode enumeration is extensible as defined in Section 3.5 of
+ [LDAPIANA]. The meanings of the 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-
avoided) diagnostic message. As this diagnostic message is not
standardized, implementations MUST NOT rely on the values returned.
If the server chooses not to return a textual diagnostic, the
- diagnosticMessage field of the LDAPResult type MUST contain a zero
- length string.
+ diagnosticMessage field MUST be empty.
- For certain result codes (typically, but not restricted to
- noSuchObject, aliasProblem, invalidDNSyntax and
-Sermersheim Internet-Draft - Expires Sep 2003 Page 9 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 9 \f
Lightweight Directory Access Protocol Version 3
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax and
aliasDereferencingProblem), the matchedDN field is set to the name of
- the lowest entry (object or alias) in the directory that was matched.
+ the lowest entry (object or alias) in the Directory that was matched.
If no aliases were dereferenced while attempting to locate the entry,
this will be a truncated form of the name provided, or if aliases
- were dereferenced, of the resulting name, as defined in section 12.5
- of [X.511]. The matchedDN field contains a zero length string with
- all other result codes.
+ were dereferenced, of the resulting name, as defined in Section 12.5
+ of [X.511]. Otherwise the matchedDN field is empty.
4.1.10. Referral
The referral result code indicates that the contacted server does not
hold the target entry of the request. The referral field is present
- in an LDAPResult if the LDAPResult.resultCode field value is
- referral, and absent with all other result codes. It contains 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 URL MUST be present in the
- Referral.
+ in an LDAPResult if the resultCode field value is 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
+ continuation references, described in Section 4.5.3, are returned
when the search scope spans multiple naming contexts, and several
different servers would need to be contacted to complete the
operation.
- Referral ::= SEQUENCE OF LDAPURL -- one or more
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
- LDAPURL ::= LDAPString -- limited to characters permitted in
- -- URLs
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
If the client wishes to progress the operation, it MUST follow the
- referral by contacting one of the servers. If multiple URLs are
- present, the client assumes that any URL may be used to progress the
+ referral by contacting one of the services. If multiple URIs are
+ present, the client assumes that any URI may be used to progress the
operation.
- URLs for servers implementing the LDAP protocol are written according
- to [LDAPURL]. If an alias was dereferenced, the <dn> part of the URL
- MUST be present, with the new target object name. If the <dn> part is
- present, the client MUST use this name in its next request to
- progress the operation, and if it is not present the client will use
- the same name as in the original request. Some servers (e.g.
- participating in distributed indexing) may provide a different filter
- in a referral for a search operation. If the filter part of the URL
- is present in an LDAPURL, the client MUST use this filter in its next
- request to progress this search, and if it is not present the client
- MUST use the same filter as it used for that search. Other aspects of
- the new request may be the same or different as the request which
- generated the referral.
+ 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 target entry name, scope and filter.
+ 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 between the root and a
+ leaf entry.
-
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ When an LDAP URL is used, the following instructions are followed:
+ - If an alias was dereferenced, the <dn> part of the URL MUST be
+ present, with the new target object name. Note that UTF-8
+ characters appearing in a DN or search filter may not be legal
-Sermersheim Internet-Draft - Expires Sep 2003 Page 10 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 10 \f
Lightweight Directory Access Protocol Version 3
- Note that UTF-8 characters appearing in a DN or search filter may not
- be legal for URLs (e.g. spaces) and MUST be escaped using the %
- method in [RFC2396].
-
- Other kinds of URLs may be returned, so long as the operation could
- be performed using that protocol.
+ for URLs (e.g. spaces) and MUST be escaped using the % method in
+ [URI].
+ - It is RECOMMENDED that the <dn> part be present to avoid
+ ambiguity.
+ - If the <dn> part is present, the client MUST use this name in
+ its next request to progress the operation, and if it is not
+ present the client will use the same name as in the original
+ request.
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a search
+ operation.
+ - If the <filter> part of the LDAP URL is present, the client MUST
+ use this filter in its next request to progress this search, and
+ if it is not present the client MUST use the same filter as it
+ used for that search.
+ - 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 ignore URIs that they
+ do not support.
4.1.11. Controls
message. A control only alters the semantics of the message it is
attached to.
- Controls ::= SEQUENCE OF Control
+ Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
- The controlType field MUST be a UTF-8 encoded dotted-decimal
+ The controlType field is the UTF-8 encoded dotted-decimal
representation of an OBJECT IDENTIFIER which uniquely identifies the
- control. This prevents conflicts between control names.
+ control, or the request control and its paired response control. This
+ prevents conflicts between control names.
The criticality field is either TRUE or FALSE and only applies to
request messages that have a corresponding response message. For all
other messages (such as abandonRequest, unbindRequest and all
- response messages), the criticality field is treated as FALSE.
+ response messages), the criticality field SHOULD be FALSE.
If the server recognizes the control type and it is appropriate for
the operation, the server will make use of the control when
performing the operation.
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 11 \f
+ Lightweight Directory Access Protocol Version 3
+
If the server does not recognize the control type or it is not
appropriate for the operation, and the criticality field is TRUE, the
- server MUST NOT perform the operation, and MUST instead return the
- resultCode unavailableCriticalExtension.
+ server MUST NOT perform the operation, and for operations that have a
+ response, MUST set the resultCode to unavailableCriticalExtension.
If the control is unrecognized or inappropriate but the criticality
field is FALSE, the server MUST ignore the control.
The controlValue contains any information associated with the
- control, and its format is defined for 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.
+ control. 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. controlValues that are defined in terms of ASN.1 and BER
+ encoded according to Section 5.1, also follow the extensibility rules
+ in Section 4.
+
+ Servers list the controlType of all request controls they recognize
+ in the supportedControl attribute [Models] in the root DSE.
+
+ 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. In the absence of combination
+ semantics, the behavior of the operation is undefined.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored.
This document does not specify any controls. Controls may be
specified in other documents. The specification of a control consists
- the OBJECT IDENTIFIER assigned to the control,
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 11 \f
- Lightweight Directory Access Protocol Version 3
-
- - whether the control is always noncritical, always critical, or
- critical at the client's option,
+ - whether the control is always non critical, always critical, or
+ optionally critical,
- - the format of the controlValue contents of the control,
+ - whether there is information associated with the control, and if
+ so, the format of the controlValue contents,
- - the semantics of the control,
+ - the semantics of the control, and
- - and optionally, semantics regarding the combination of the control
+ - optionally, semantics regarding the combination of the control
with other controls.
- Servers list the controlType of all request controls they recognize
- in the supportedControl attribute [Models] in the root DSE.
-
- 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. In the absence of combination
- semantics, the behavior of the operation is undefined.
- Additionally, the order of a combination of controls in the SEQUENCE
- is ignored unless the control specification(s) describe(s)
- combination semantics.
-
4.2. Bind Operation
The function of the Bind Operation is to allow authentication
- information to be exchanged between the client and server. Prior to
- the first BindRequest, the implied identity is anonymous. Refer to
- [AuthMeth] for the authentication-related semantics of this
- operation.
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Authentication and security-related semantics of this operation are
+ given in [AuthMeth].
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 12 \f
+ Lightweight Directory Access Protocol Version 3
+
The Bind Request is defined as follows:
BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
Parameters of the Bind Request are:
- version: A version number indicating the version of the protocol
- to be used in this protocol session. This document describes
+ to be used in this protocol association. This document describes
version 3 of the LDAP protocol. Note that there is no version
- negotiation, and the client just sets this parameter to the
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 12 \f
- Lightweight Directory Access Protocol Version 3
-
- version it desires. If the server does not support the specified
- version, it responds with protocolError in the resultCode field of
- the BindResponse.
+ negotiation. The client sets this parameter to the version it
+ desires. If the server does not support the specified version, it
+ MUST respond with protocolError in the resultCode field of the
+ BindResponse.
- - name: The name of the directory object that the client wishes to
+ - name: The name of the Directory object that the client wishes to
bind as. This field may take on a null value (a zero length
- string) for the purposes of anonymous binds ([AuthMeth] section 7)
- or when using SASL authentication ([AuthMeth] section 4.3). Server
- behavior is undefined when the name is a null value, simple
- authentication is used, and a password is specified. The server
- SHOULD NOT perform any alias dereferencing in determining the
- object to bind as.
+ string) for the purposes of anonymous binds ([AuthMeth] Section 7)
+ or when using Simple Authentication and Security Layer [SASL]
+ authentication ([AuthMeth] Section 4.3). Server behavior is
+ undefined when the name is a null value, simple authentication is
+ used, and a password is specified. The server SHALL NOT perform
+ alias dereferencing in determining the object to bind as.
- authentication: information used to authenticate the name, if any,
provided in the Bind Request. This type is extensible as defined
in Section 3.6 of [LDAPIANA]. Servers that do not support a choice
supplied by a client will return authMethodNotSupported in the
- result code of the BindResponse.
+ resultCode field of the BindResponse.
+ The simple form of an AuthenticationChoice specifies a simple
+ password to be used for authentication.
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) SHALL be transferred as [UTF-8]
+ encoded [Unicode]. The determination of whether a password is
+ textual is a local client matter.
+ Prior to transfer, clients SHOULD prepare text passwords by
+ applying the [SASLprep] profile of the [Stringprep] algorithm.
+ Passwords consisting of other data (such as random octets) MUST
+ NOT be altered.
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 13 \f
+ Lightweight Directory Access Protocol Version 3
+
Authorization is the use of this authentication information when
performing operations. Authorization MAY be affected by factors
- outside of the LDAP Bind Request, such as lower layer security
- services.
+ outside of the LDAP Bind Request, such as those provided by lower
+ layer security services.
4.2.1. Processing of the Bind Request
- Upon receipt of a BindRequest, the server MUST ensure there are no
- outstanding operations in progress on the connection (This simplifies
- server implementation). 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.
+ Before processing a BindResponse, all outstanding operations MUST
+ either complete or be abandoned. The server may either wait for the
+ outstanding 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.
If the client did not bind before sending a request and receives an
- operationsError, it may then send a Bind Request. If this also fails
- or the client chooses not to bind on the existing connection, it may
- close the connection, reopen it and begin again by first sending a
- PDU with a Bind Request. This will aid in interoperating with servers
- implementing other versions of LDAP.
-
- Clients MAY send multiple Bind Requests on a connection to change
- their credentials. Authentication from earlier binds is subsequently
- ignored. A failed or abandoned Bind Operation has the effect of
- leaving the connection in an anonymous state. To arrive at a known
- authentication state after abandoning a bind operation, clients may
- unbind, rebind, or make use of the BindResponse. If a SASL transfer
- encryption or integrity mechanism has been negotiated, and that
- mechanism does not support the changing of credentials from one
- identity to another, then the client MUST instead establish a new
- connection.
+ operationsError to that request, it may then send a Bind Request. If
+ this also fails or the client chooses not to bind on the existing
+ connection, it may close the connection, reopen it and begin again by
+ first sending a PDU with a Bind Request. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+ Clients may send multiple Bind Requests on a connection to change 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. This is indicated by
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 13 \f
- Lightweight Directory Access Protocol Version 3
-
the server sending a BindResponse with the resultCode set to
saslBindInProgress. This indicates that the server requires the
client to send a new bind request, with the same sasl mechanism, to
abort a negotiation if it wishes to try again with the same SASL
mechanism.
+ A failed Bind Operation has the effect of leaving the connection in
+ an anonymous state. An abandoned Bind operation also has the effect
+ of leaving the connection in an anonymous state when (and if) the
+ server processes the abandonment of the bind. Client implementers
+ should note that the client has no way of being sure when (or if) an
+ abandon request succeeds, therefore, to arrive at a known
+ authentication state after abandoning a bind operation, clients may
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 14 \f
+ Lightweight Directory Access Protocol Version 3
+
+ either unbind (which results in the underlying connection being
+ closed) or by issuing a bind request and then examining the
+ BindResponse returned by the server.
4.2.2. Bind Response
status of the client's request for authentication.
A successful bind operation is indicated by a BindResponse with a
- resultCode set to success (0). Otherwise, an appropriate resultCode
- is set in the BindResponse. For bind, the protocolError (2)
- resultCode may be used to indicate that the version number supplied
- by the client is unsupported.
-
- If the server does not support the client's requested protocol
- version, it MUST set the resultCode to protocolError.
-
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For bind, 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 response where the resultCode
- was protocolError, it MUST close the connection as the server will be
- unwilling to accept further operations. (This is for compatibility
- with earlier versions of LDAP, in which the bind was always the first
- operation, and there was no negotiation.)
+ field is protocolError, it MUST close the connection as the server
+ will be unwilling to accept further operations. (This is for
+ compatibility with earlier versions of LDAP, in which the bind was
+ always the first operation, and there was no negotiation.)
The serverSaslCreds are used as part of a SASL-defined bind mechanism
to allow the client to authenticate the server to which it is
communicating, or to perform "challenge-response" authentication. If
the client bound with the simple choice, or the SASL mechanism does
not require the server to return information to the client, then this
- field is not to be included in the result.
+ field SHALL NOT be included in the BindResponse.
4.3. Unbind Operation
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 14 \f
- Lightweight Directory Access Protocol Version 3
-
- The function of the Unbind Operation is to terminate a protocol
- session. The Unbind Operation is defined as follows:
+ The function of the Unbind Operation is to terminate an LDAP
+ association and connection. The Unbind operation is not the
+ antithesis of the Bind operation as the name implies. The naming of
+ these operations is historical. The Unbind operation should be
+ thought of as the "quit" operation.
+
+ The Unbind Operation is defined as follows:
UnbindRequest ::= [APPLICATION 2] NULL
- The Unbind Operation has no response defined. Upon transmission of an
- UnbindRequest, a protocol client MUST assume that the protocol
- session is terminated. Upon receipt of an UnbindRequest, a protocol
- server MUST assume that the requesting client has terminated the
- session and that all outstanding requests may be discarded, and MUST
- close the connection.
+ The Unbind Operation has no response defined. Upon transmission of
+ the UnbindRequest, each protocol peer is to consider the LDAP
+ association terminated, MUST cease transmission of messages to the
+ other peer, and MUST close the connection. Any outstanding operations
+ on the server are, when possible, abandoned, and when not possible,
+ completed without transmission of the response.
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 15 \f
+ Lightweight Directory Access Protocol Version 3
+
4.4. Unsolicited Notification
any response to be returned from the client.
The unsolicited notification is structured as an LDAPMessage in which
- the messageID is 0 and protocolOp is of the extendedResp form. The
- responseName field of the ExtendedResponse is present. The LDAPOID
- value MUST be unique for this notification, and not be used in any
- other situation.
+ the messageID is zero and protocolOp is of the extendedResp form. 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.
+ 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 (if any) of the responseValue,
+
+ - the circumstances which will cause the notification to be
+ returned, and
+
+ - the semantics of the operation.
4.4.1. Notice of Disconnection
the server is about to close the connection due to an error
condition. Note that this notification is NOT a response to an unbind
requested by the client: the server MUST follow the procedures of
- section 4.3. This notification is intended to assist clients in
+ Section 4.3. This notification is intended to assist clients in
distinguishing between an error condition and a transient network
failure. As with a connection close due to network failure, the
client MUST NOT assume that any outstanding requests which modified
- the directory have succeeded or failed.
+ the Directory have succeeded or failed.
The responseName is 1.3.6.1.4.1.1466.20036, the response field is
absent, and the resultCode is used to indicate the reason for the
disconnection.
- The following resultCode values are to be used in this notification:
+ The following result codes have these meanings when used in this
+ notification:
- protocolError: The server has received data from the client in
which the LDAPMessage structure could not be parsed.
+ - strongAuthRequired: The server has detected that an established
+ security association between the client and server has
-Sermersheim Internet-Draft - Expires Sep 2003 Page 15 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 16 \f
Lightweight Directory Access Protocol Version 3
- - strongAuthRequired: The server has detected that an established
- underlying security association protecting communication between
- the client and server has unexpectedly failed or been compromised.
+ unexpectedly failed or been compromised, or that the server now
+ requires the client to authenticate using a strong(er) mechanism.
- unavailable: This server will stop accepting new connections and
operations on all existing connections, and be unavailable for an
extended period of time. The client may make use of an alternative
server.
- After sending this notice, the server MUST close the connection.
- After receiving this notice, the client MUST NOT transmit any further
- on the connection, and may abruptly close the connection.
+ Upon transmission of the UnbindRequest, each protocol peer is to
+ consider the LDAP association terminated, MUST cease transmission of
+ messages to the other peer, and MUST close the connection.
4.5. Search Operation
- The Search Operation allows a client to request that a search be
- performed on its behalf by a server. This can be used to read
- attributes from a single entry, from entries immediately below a
- particular entry, or a whole subtree of entries.
+ 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:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
+ 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 selection LDAPString
+ -- constrained to <attributeSelection> below
Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF Filter,
- or [1] SET SIZE (1..MAX) OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
+ 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,
-Sermersheim Internet-Draft - Expires Sep 2003 Page 16 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 17 \f
Lightweight Directory Access Protocol Version 3
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- at least one must be present,
- -- initial and final can occur at most once
- substrings SEQUENCE OF CHOICE {
- initial [0] AssertionValue,
- any [1] AssertionValue,
- final [2] AssertionValue } }
+ type AttributeDescription,
+ -- at least one must be present,
+ -- initial and final can occur at most once
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
Parameters of the Search Request are:
- - baseObject: An LDAPDN that is the base object entry relative to
- which the search is to be performed.
+ - baseObject: The name of the base object entry relative to which
+ the search is to be performed.
+
+ - scope: Specifies the scope of the search to be performed. The
+ semantics (as described in [X.511]) of the possible values of this
+ field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ oneLevel: 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.
- - scope: An indicator of the scope of the search to be performed.
- The semantics of the possible values of this field are identical
- to the semantics of the scope field in the X.511 Search Operation.
- derefAliases: An indicator as to how alias objects (as defined in
- X.501) are to be handled in searching. The semantics of the
+ [X.501]) are to be handled in searching. The semantics of the
possible values of this field are:
- neverDerefAliases: do not dereference aliases in searching
- or in locating the base object of the search;
-
- derefInSearching: dereference aliases in subordinates of
- the base object in searching, but not in locating the base
- object of the search;
-
- derefFindingBaseObj: dereference aliases in locating the
+ neverDerefAliases: Do not dereference aliases in searching
+ or in locating the base object of the search.
+
+ derefInSearching: While searching, dereference any alias
+ object subordinate to the base object which is also in the
+ search scope. The filter is applied to the dereferenced
+ object(s). If the search scope is wholeSubtree, the search
+ continues in the subtree of any dereferenced object.
+ Aliases in that subtree are also dereferenced. Servers
+ SHOULD detect looping in this process to prevent denial of
+ service attacks and duplicate entries.
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 18 \f
+ Lightweight Directory Access Protocol Version 3
+
+ derefFindingBaseObj: Dereference aliases in locating the
base object of the search, but not when searching
- subordinates of the base object;
+ subordinates of the base object.
- derefAlways: dereference aliases both in searching and in
+ derefAlways: Dereference aliases both in searching and in
locating the base object of the search.
- sizeLimit: A size limit that restricts the maximum number of
- entries to be returned as a result of the search. A value of 0 in
- this field indicates that no client-requested size limit
+ 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 enforce a
maximum number of entries to return.
- timeLimit: A time limit that restricts the maximum time (in
- seconds) allowed for a search. A value of 0 in this field
+ 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.
+ effect for the search. Servers may enforce a maximum time limit
+ for the search.
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 17 \f
- Lightweight Directory Access Protocol Version 3
-
- - typesOnly: An indicator as to whether search results will contain
- both attribute descriptions and values, or just attribute
+ - 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
if the tag was explicit.)
A server MUST evaluate filters according to the three-valued logic
- of X.511 (1993) section 7.8.1. In summary, a filter is evaluated
+ of X.511 (1993) Section 7.8.1. In summary, a filter is evaluated
to either "TRUE", "FALSE" or "Undefined". If the filter evaluates
to TRUE for a particular entry, then the attributes of that entry
are returned as part of the search result (subject to any
is TRUE, and Undefined if it is Undefined.
The present match evaluates to TRUE where there is an attribute or
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 19 \f
+ Lightweight Directory Access Protocol Version 3
+
subtype of the specified attribute description present in an
entry, and FALSE otherwise (including a presence test with an
unrecognized attribute description.)
The matching rule for equalityMatch filter items is defined by the
EQUALITY matching rule for the attribute type.
- The matching rule and assertion syntax for AssertionValues in a
- substrings filter item is defined by the SUBSTR matching rule for
- the attribute type.
+ The matching rule for AssertionValues in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type.
+ Note that the AssertionValue in a substrings filter item MUST
+ conform 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. The entire SubstringFilter
+ is converted into an assertion value of the substrings matching
+ rule prior to applying the rule.
The matching rule for greaterOrEqual and lessOrEqual filter items
is defined by the ORDERING matching rule for the attribute type.
- The matching rule for approxMatch filter items is implementation-
- defined. If approximate matching is not supported by the server,
- the filter item should be treated as an equalityMatch.
+ The approxMatch evaluates to TRUE when there is a value of the
+ attribute or subtype for which some locally-defined approximate
+ matching algorithm (e.g. spelling variations, phonetic match,
+ etc.) returns TRUE. If an item matches for equality, it also
+ satisfies an approximate match. If approximate matching is not
+ supported, this filter item should be treated as an equalityMatch.
+
+ An extensibleMatch is evaluated as follows:
+
- The extensibleMatch is new in this version of LDAP. If the
+ 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. The matchingRule determines the
+ syntax for the assertion value. The filter item evaluates to
+ TRUE if it matches with at least one attribute in the entry,
+ FALSE if it does not match any attribute in the entry, and
+ Undefined if the matchingRule is not recognized or the
+ assertionValue is invalid.
+
+
+ If the type field is present and the matchingRule is present,
+ the matchValue is compared against entry attributes of the
+ specified type. In this case, the matchingRule MUST be one
+ suitable for use with the specified type (see [Syntaxes]),
+ otherwise the filter item is undefined.
+
+
+ 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 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
+
-Sermersheim Internet-Draft - Expires Sep 2003 Page 18 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 20 \f
Lightweight Directory Access Protocol Version 3
- matchingRule field is absent, the type field MUST be present, and
- the equality match is performed for that type. If the type field
- is absent and matchingRule is present, the matchValue is compared
- against all attributes in an entry which support that
- matchingRule, and the matchingRule determines the syntax for the
- assertion value (the filter item evaluates to TRUE if it matches
- with at least one attribute in the entry, FALSE if it does not
- match any attribute in the entry, and Undefined if the
- matchingRule is not recognized or the assertionValue cannot be
- parsed.) If the type field is present and matchingRule is present,
- the matchingRule MUST be one permitted for use with that type,
- otherwise the filter item is undefined. If the dnAttributes field
- is set to TRUE, the match is applied against all the
- AttributeValueAssertions in an entry's distinguished name as well,
- and also evaluates to TRUE if there is at least one attribute in
- the distinguished name for which the filter item evaluates to
- TRUE. (Editors note: The dnAttributes field is present so that
- there does not need to be multiple versions of generic matching
- rules such as for word matching, one to apply to entries and
- another to apply to entries and dn attributes as well).
-
+ another applies to entries and dn attributes as well.
+
A filter item evaluates to Undefined when the server would not be
able to determine whether the assertion value matches an entry. If
an attribute description in an equalityMatch, substrings,
greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter
is not recognized by the server, a matching rule id in the
extensibleMatch is not recognized by the server, the assertion
- value cannot be parsed, or the type of filtering requested is not
+ value is invalid, or the type of filtering requested is not
implemented, then the filter is Undefined. Thus for example if a
server did not recognize the attribute type shoeSize, a filter of
(shoeSize=*) would evaluate to FALSE, and the filters
Undefined.
Servers MUST NOT return errors if attribute descriptions or
- matching rule ids are not recognized, or assertion values cannot
- be parsed. More details of filter processing are given in section
- 7.8 of [X.511].
+ 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 Section 7.8 of [X.511].
- attributes: A list of the attributes to be returned from each
- entry which matches the search filter. There are two special
- values which may be used: an empty list with no attributes, and
- the attribute description string "*". Both of these signify that
- all user attributes are to be returned. (The "*" allows the client
- to request all user attributes in addition to any specified
- operational attributes).
-
- Attributes MUST be named at most once in the list, and are
+ entry which matches the search filter. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ [(ABNF)]:
+
+ attributeSelection = noattrs /
+ *( attributedescription / specialattr )
+
+ noattrs = %x31 %x2E %x31 ; "1.1"
+
+ specialattr = ASTERISK
+
+ ASTERISK = %x2A ; asterisk ("*")
+
+ <attributedescription> is defined in Section 2.5 of [Models].
+
+ There are two special values which may be used: an empty list with
+ no attributes, and the attribute description string "*". Both of
+ these signify that all user attributes are to be returned. (The
+ "*" allows the client to request all user attributes in addition
+ to any specified operational attributes). 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 MUST NOT be named more than once in the list, and are
returned at most once in an entry. If there are attribute
descriptions in the list which are not recognized, they are
ignored by the server.
- If the client does not want any attributes returned, it can
- specify a list containing only the attribute with OID "1.1". This
-Sermersheim Internet-Draft - Expires Sep 2003 Page 19 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 21 \f
Lightweight Directory Access Protocol Version 3
- OID was chosen arbitrarily and does not correspond to any
+ If the client does not want any attributes returned, it can
+ specify a list containing only the attribute with OID "1.1". This
+ OID was chosen 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 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, since there may be extremely large number of values for
- certain operational attributes. (A list of operational attributes
- for use in LDAP is given in [Syntaxes].)
Note that an X.500 "list"-like operation can be emulated by the
client requesting a one-level LDAP search operation with a filter
4.5.2. Search Result
- The results of the search attempted by the server upon receipt of a
- Search Request are returned in Search Responses, which are LDAP
- messages containing either SearchResultEntry, SearchResultReference,
- or SearchResultDone data types.
+ The results of the search operation are returned as zero or more
+ searchResultEntry messages, zero or more SearchResultReference
+ messages, followed by a single searchResultDone message.
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
+ objectName LDAPDN,
+ attributes PartialAttributeList }
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
- -- implementors should note that the PartialAttributeList may
- -- have zero elements (if none of the attributes of that entry
- -- were requested, or could be returned), and that the vals set
- -- may also have zero elements (if types only was requested, or
- -- all values were excluded from the result.)
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+ -- 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.
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
- -- at least one LDAPURL element must be present
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
SearchResultDone ::= [APPLICATION 5] LDAPResult
- Upon receipt of a Search Request, a server will perform the necessary
- search of the DIT.
-
- If the LDAP session is operating over a connection-oriented transport
- such as TCP, the server will return to the client a sequence of
- responses in separate LDAP messages. There may be zero or more
- responses containing SearchResultEntry, one for each entry found
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 20 \f
- Lightweight Directory Access Protocol Version 3
-
- during the search. There may also be zero or more responses
- containing SearchResultReference, one for each area not explored by
- this server during the search. The SearchResultEntry and
- SearchResultReference PDUs may come in any order. Following all the
- SearchResultReference responses and all SearchResultEntry responses
- to be returned by the server, the server will return a response
- containing the SearchResultDone, which contains an indication of
- success, or detailing any errors that have occurred.
+ Each SearchResultEntry represents an entry found during the search.
+ Each SearchResultReference represents an area not yet explored during
+ the search. The SearchResultEntry and SearchResultReference PDUs 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
Some attributes may be constructed by the server and appear in a
SearchResultEntry attribute list, although they are not stored
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 22 \f
+ Lightweight Directory Access Protocol Version 3
+
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 a textual name for an attribute type,
- it MUST use a textual name for attributes of that attribute type by
- specifying one of the textual names as the value of the attribute
- type. Otherwise, the server uses the object identifier for the
- attribute type by specifying the object identifier, in ldapOID form,
- as the value of attribute type.
+ 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 to search all the entries in the scope at
- and under the baseObject, the server may return one or more
+ and subordinate to the baseObject, the server may return one or more
SearchResultReference entries, each containing a reference to another
set of servers for continuing the operation. A server MUST NOT return
any SearchResultReference if it has not located the baseObject and
thus has not searched any entries; in this case it would return a
- SearchResultDone containing a referral resultCode.
+ SearchResultDone containing a referral result code.
If a server holds a copy or partial copy of the subordinate naming
context, 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.
- URLs for servers implementing the LDAP protocol are written according
- to [LDAPURL]. The <dn> part MUST be present in the URL, with the new
- target object name. The client MUST use this name in its next
- request. Some servers (e.g. part of a distributed index exchange
- system) may provide a different filter in the URLs of the
- SearchResultReference. If the filter part of the URL is present in an
- LDAP URL, the client MUST use the new filter in its next request to
- progress the search, and if the filter part is absent the client will
- use again the same filter. If the originating search scope was
- singleLevel, the scope part of the URL will be baseObject. Other
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 21 \f
- Lightweight Directory Access Protocol Version 3
-
- aspects of the new search request may be the same or different as the
- search which generated the continuation references.
- Other kinds of URLs may be returned so long as the operation could be
- performed using that protocol.
+ The SearchResultReference is of the same data type as the Referral.
- The name of an unexplored subtree in a SearchResultReference need not
- be subordinate to the base object.
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
- In order to complete the search, the client MUST issue a new search
+ In order to complete the search, the client issues a new search
operation for each SearchResultReference that is returned. Note that
- the abandon operation described in section 4.11 applies only to a
- particular operation sent on a connection between a client and
- server, and if the client has multiple outstanding search operations,
- it MUST abandon each operation individually.
-
+ the abandon operation described in Section 4.11 applies only to a
+ particular operation sent on an association between a client and
+ server. The client must abandon subsequent search operations it
+ wishes to individually.
+
+ 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 target entry name,
+ scope and filter. 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
+ search result references between the root and a leaf entry.
+
+ When an LDAP URL is used, the following instructions are followed:
+ - The <dn> part of the URL MUST be present, with the new target
+ object name. The client MUST use this name when following the
+ referral. Note that UTF-8 characters appearing in a DN or search
+ filter may not be legal for URLs (e.g. spaces) and MUST be
+ escaped using the % method in [URI].
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 23 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - It is RECOMMENDED that the <dn> part be present to avoid
+ ambiguity.
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in a URL of a SearchResultReference.
+ - If the <filter> part of the URL is present, the client MUST use
+ this filter in its next request to progress this search, and if
+ it is not present the client MUST use the same filter as it used
+ for that search.
+ - If the originating search scope was singleLevel, the <scope>
+ part of the URL will be "base".
+ - 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 search request may be the same as or
+ different from the search request which generated the
+ SearchResultReference.
+ - The name of an unexplored subtree in a SearchResultReference
+ need not be subordinate to the base object.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients ignore URIs that they
+ do not support.
+
4.5.3.1. Example
SearchResultEntry for DC=Example,DC=NET
SearchResultEntry for CN=Manager,DC=Example,DC=NET
SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET
- ldap://hostc/OU=People,DC=Example,DC=NET
- }
+ 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
- }
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
SearchResultDone (success)
Client implementors should note that when following a
SearchResultEntry for OU=People,DC=Example,DC=NET
SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET
- }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET
- }
- SearchResultDone (success)
-
-
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
-Sermersheim Internet-Draft - Expires Sep 2003 Page 22 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 24 \f
Lightweight Directory Access Protocol Version 3
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
If the contacted server does not hold the base object for the search,
then it will return a referral to the client. For example, if the
client requests a subtree search of "DC=Example,DC=ORG" to hosta, the
server may return only a SearchResultDone containing a referral.
SearchResultDone (referral) {
- ldap://hostg/DC=Example,DC=ORG??sub
- }
+ ldap://hostg/DC=Example,DC=ORG??sub }
4.6. Modify Operation
Request is defined as follows:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification PartialAttribute } }
+
Parameters of the Modify Request are:
- - object: The object to be modified. The value of this field
- contains the DN of the entry to be modified. The server will not
- perform any alias dereferencing in determining the object to be
- modified.
+ - object: The name of the object to be modified. The value of this
+ field contains the DN of the entry to be modified. The server
+ SHALL NOT perform any alias dereferencing in determining the
+ object to be modified.
- - modification: A list of modifications to be performed on the
- entry. The entire list of entry modifications MUST be performed in
- the order they are listed, as a single atomic operation. While
- individual modifications may violate the directory schema, the
+ - 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
- schema. The values that may be taken on by the 'operation' field
- in each modification construct have the following semantics
- respectively:
+ schema.
- add: add values listed to the given attribute, creating the
- attribute if necessary;
+ - 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:
- delete: delete values listed from the given attribute,
- removing the entire attribute if no values are listed, or
- if all current values of the attribute are listed for
- deletion;
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary;
+ delete: delete values listed from the modification
+ attribute, removing the entire attribute if no values are
-Sermersheim Internet-Draft - Expires Sep 2003 Page 23 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 25 \f
Lightweight Directory Access Protocol Version 3
- replace: replace all existing values of the given attribute
- with the new values listed, creating the attribute if it
- did not already exist. A replace with no value will delete
- the entire attribute if it exists, and is ignored if the
- attribute does not exist.
+ listed, or if all current values of the attribute are
+ listed for deletion;
- The result of the modification attempted by the server upon receipt
- of a Modify Request is returned in a Modify Response, defined as
- follows:
+ 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.
- ModifyResponse ::= [APPLICATION 7] LDAPResult
+ - 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:
- Upon receipt of a Modify Request, a server will perform the necessary
- modifications to the DIT.
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
The server will return to the client a single Modify Response
indicating either the successful completion of the DIT modification,
the DIT have been performed if the Modify Response received indicates
any sort of error, and that all requested modifications have been
performed if the Modify Response indicates successful completion of
- the Modify Operation. If the connection fails, whether the
- modification occurred or not is indeterminate.
+ the Modify Operation. If the association changes or the connection
+ fails, whether the modification occurred or not is indeterminate.
The Modify Operation cannot be used to remove from an entry any of
- its distinguished values, those values which form the entry's
+ 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 error notAllowedOnRDN. The Modify DN Operation
- described in section 4.9 is used to rename an entry.
+ server returning the notAllowedOnRDN result code. The Modify DN
+ Operation described in Section 4.9 is used to rename an entry.
Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the modifications in an LDAP ModifyRequest onto the
- EntryModifications of a DAP ModifyEntry operation, and different
- implementations of LDAP-DAP gateways may use different means of
- representing the change. If successful, the final effect of the
- operations on the entry MUST be identical.
+ 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.
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:
+ into the Directory. The Add Request is defined as follows:
AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ entry LDAPDN,
+ attributes AttributeList }
- Parameters of the Add Request are:
+ AttributeList ::= SEQUENCE OF attribute Attribute
-Sermersheim Internet-Draft - Expires Sep 2003 Page 24 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 26 \f
Lightweight Directory Access Protocol Version 3
- - entry: the Distinguished Name of the entry to be added. Note that
- the server will not dereference any aliases in locating the entry
- to be added.
+ Parameters of the Add Request are:
+
+ - entry: the name of the entry to be added. Note that the server
+ SHALL NOT dereference any aliases in locating the entry to be
+ added.
- attributes: the list of attributes that make up the content of the
entry being added. Clients MUST include distinguished values
since the server maintains these automatically.
The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The parent of the object and alias
- entries 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 error noSuchObject with the matchedDN field containing
- "DC=NET". If the parent entry exists but is not in a naming context
- held by the server, the server SHOULD return a referral to the server
- holding the parent entry.
+ 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". If the parent entry exists
+ but is not in a naming context held by the server, the server SHOULD
+ return a referral to the server holding the parent entry.
Server implementations SHOULD NOT restrict where entries can be
- located in the directory unless DIT structure rules are in place.
- Some servers MAY allow the administrator to restrict the classes of
- entries which can be added to the directory.
+ located in the Directory unless DIT structure rules are in place.
+ Some servers allow the administrator to restrict the classes of
+ entries which can be added to the Directory.
Upon receipt of an Add Request, a server will attempt to add the
requested entry. The result of the add attempt will be returned to
AddResponse ::= [APPLICATION 9] LDAPResult
A response of success indicates that the new entry is present in the
- directory.
+ 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:
+ entry from the Directory. The Delete Request is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
- The Delete Request consists of the Distinguished Name of the entry to
- be deleted. Note that the server will not dereference aliases while
- resolving the name of the target entry to be removed, and that only
- leaf entries (those with no subordinate entries) can be deleted with
- this operation.
+ The 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.
- The result of the delete attempted by the server upon receipt of a
- Delete Request is returned in the Delete Response, defined as
- follows:
-Sermersheim Internet-Draft - Expires Sep 2003 Page 25 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 27 \f
Lightweight Directory Access Protocol Version 3
+ 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
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested. The result of the delete attempt will be
- returned to the client in the Delete Response.
-
4.9. Modify DN Operation
- The Modify DN Operation allows a client to change the leftmost (least
- significant) component of the name of an entry in the directory,
- and/or to move a subtree of entries to a new location in the
- directory. The Modify DN Request is defined as follows:
+ 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 }
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
Parameters of the Modify DN Request are:
- - entry: the Distinguished Name of the entry to be changed. This
- entry may or may not have subordinate entries. Note that the
- server will not dereference any aliases in locating the entry to
- be changed.
+ - entry: the name of the entry to be changed. This entry may or may
+ not have subordinate entries. Note that the server SHALL NOT
+ dereference any aliases in locating the entry to be changed.
- - newrdn: the RDN that will form the leftmost component of the new
- name of the entry.
+ - newrdn: the new RDN of the entry.
- deleteoldrdn: a boolean parameter that controls whether the old
RDN attribute values are to be retained as attributes of the
entry, or deleted from the entry.
- - newSuperior: if present, this is the Distinguished Name of an
- existing object entry which becomes the immediate superior of the
+ - newSuperior: if present, this is the name of an existing object
+ entry which becomes the immediate superior (parent) of the
existing entry.
- The result of the name change attempted by the server upon receipt of
- a Modify DN Request is returned in the Modify DN Response, defined as
- follows:
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change and return the result in the Modify DN Response,
+ defined as follows:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
- Upon receipt of a ModifyDNRequest, a server will attempt to perform
- the name change. The result of the name change attempt will be
- returned to the client in the Modify DN Response.
-
For example, if the entry named in the "entry" parameter was "cn=John
Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the
newSuperior parameter was absent, then this operation would 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.
+
+ 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".
-Sermersheim Internet-Draft - Expires Sep 2003 Page 26 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 28 \f
Lightweight Directory Access Protocol Version 3
- already an entry with that name, the operation would fail with error
- code entryAlreadyExists.
-
+
If the deleteoldrdn parameter is TRUE, the values forming the old RDN
are deleted from the entry. If the deleteoldrdn parameter is FALSE,
the values forming the old RDN will be retained as non-distinguished
- attribute values of the entry. The server may not perform the
- operation and return an error code if the setting of the deleteoldrdn
+ attribute values of the entry. The server MUST fail the operation and
+ return an error in the result code if the setting of the deleteoldrdn
parameter would cause a schema inconsistency in the entry.
Note that X.500 restricts the ModifyDN operation to only affect
entries that are contained within a single server. If the LDAP server
is mapped onto DAP, then this restriction will apply, and the
- resultCode affectsMultipleDSAs will be returned if this error
- occurred. In general clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers.
+ 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
- provided with an entry in the directory. The Compare Request is
+ provided with an entry in the Directory. The Compare Request is
defined as follows:
CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
+ entry LDAPDN,
+ ava AttributeValueAssertion }
Parameters of the Compare Request are:
- - entry: the name of the entry to be compared with. Note that the
- server SHOULD NOT dereference any aliases in locating the entry to
- be compared with.
+ - entry: the name of the entry to be compared. Note that the server
+ SHALL NOT dereference any aliases in locating the entry to be
+ compared.
- ava: the assertion with which an attribute in the entry is to be
compared.
- The result of the compare attempted by the server upon receipt of a
- Compare Request is returned in the Compare Response, defined as
- follows:
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison using the EQUALITY matching rule for the
+ attribute type and return the result in the Compare Response, defined
+ as follows:
CompareResponse ::= [APPLICATION 15] LDAPResult
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison using the EQUALITY matching rule for the
- attribute type. The result of the comparison will be returned to the
- client in the Compare Response. Note that errors and the result of
- comparison are all returned in the same construct.
+ In the event that the attribute or subtype is not present in the
+ entry, the resultCode field is set to noSuchAttribute. If the
+ attribute is unknown, the resultCode is set to
+ undefinedAttributeType. Note that errors and the result of comparison
+ are all returned in the same construct.
Note that some directory systems may establish access controls which
permit the values of certain attributes (such as userPassword) to be
-Sermersheim Internet-Draft - Expires Sep 2003 Page 27 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 29 \f
Lightweight Directory Access Protocol Version 3
4.11. Abandon Operation
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID MUST be that of an operation which was requested
- earlier in this connection. The abandon request itself has its own
- message id. This is distinct from the id of the earlier operation
+ earlier in this LDAP association. The abandon request itself has its
+ own message id. This is distinct from the id of the earlier operation
being abandoned.
- There is no response defined in the Abandon Operation. Upon
- transmission of an Abandon Operation, the server MAY abandon the
- operation identified by the Message ID in the Abandon Request.
- Operation responses are not sent for successfully abandoned
- operations. Clients can determine that an operation has been
- abandoned by performing a subsequent bind operation.
+ There is no response defined in the Abandon operation. Upon receipt
+ of an AbandonRequest, the server MAY abandon the operation identified
+ by the MessageID. Operation responses are not sent for successfully
+ abandoned operations, thus the application of the Abandon operation
+ is limited to uses where the client does not require an indication of
+ its outcome.
Abandon and Unbind operations cannot be abandoned. The ability to
abandon other (particularly update) operations is at the discretion
4.12. Extended Operation
- An extension mechanism has been added in this version of LDAP, in
- order to allow additional operations to be defined for services not
- available elsewhere in this protocol, for instance digitally signed
- operations and results.
+ 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.13).
The extended operation allows clients to make requests and receive
responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations. Each
- request MUST have a unique OBJECT IDENTIFIER assigned to it.
+ 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 {
-Sermersheim Internet-Draft - Expires Sep 2003 Page 28 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 30 \f
Lightweight Directory Access Protocol Version 3
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
- The requestName is a dotted-decimal representation of the OBJECT
- IDENTIFIER corresponding to the request. The requestValue is
+ 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.
ExtendedResponse.
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
+ 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 requestName is not recognized by the server, the server MUST
+ NOT provide a responseName nor a responseValue and MUST return a
+ resultCode of 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.
+
+ It is RECOMMENDED that servers list the requestName of extended
+ operations they support in the supportedExtension attribute [Models]
+ of the root DSE.
+
+ Extended operations may be specified in other documents. The
+ specification of an extended operation consists of:
+
+ - the OBJECT IDENTIFIER assigned to the requestName (and possibly
+ responseName),
- If the server does not recognize the request name, it MUST return
- only the response fields from LDAPResult, containing the
- protocolError result code.
+ - the format of the contents of the requestValue and responseValue
+ (if any),
-4.13. Start TLS Operation
+ - the semantics of the operation,
+
+4.13. StartTLS Operation
+
+
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 31 \f
+ Lightweight Directory Access Protocol Version 3
+
The Start Transport Layer Security (StartTLS) operation provides the
- ability to establish Transport Layer Security [RFC2246] on an LDAP
- connection.
+ ability to establish Transport Layer Security ([TLS]) on an LDAP
+ connection. The StartTLS operation is defined using the extended
+ operation mechanism described in Section 4.12.
-4.13.1. Start TLS Request
+4.13.1. StartTLS Request
- A client requests TLS establishment by transmitting a Start TLS
- request PDU to the server. The Start TLS request is defined in terms
+ A client requests TLS establishment by transmitting a StartTLS
+ request PDU 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 absent.
+ and the requestValue field is always absent.
The client MUST NOT send any PDUs on this connection following this
- request until it receives a Start TLS extended response.
+ request until it receives a StartTLS extended response.
-4.13.2. Start TLS Response
+4.13.2. StartTLS Response
- When a Start TLS request is made, servers supporting the operation
- MUST return a Start TLS response PDU to the requestor. The Start TLS
+ When a StartTLS request is made, servers supporting the operation
+ MUST return a StartTLS response PDU to the requestor. The StartTLS
response responseName is also "1.3.6.1.4.1.1466.20037", and the
response field is absent.
The server MUST set the resultCode field to either success or one of
- the other values outlined in section 4.13.2.2.
+ the other values outlined in Section 4.13.2.2.
4.13.2.1. "Success" Response
- If the Start TLS Response contains a resultCode of success, this
+ If the StartTLS Response contains a result code of success, this
indicates that the server is willing and able to negotiate TLS. Refer
- to section 5.3 of [AuthMeth] for details.
+ to Section 5.3 of [AuthMeth] for details.
4.13.2.2. Response other than "success"
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 29 \f
- Lightweight Directory Access Protocol Version 3
-
- If the ExtendedResponse contains a resultCode other than success,
+ If the ExtendedResponse contains a result code other than success,
this indicates that the server is unwilling or unable to negotiate
- TLS.
-
- If the Start TLS extended request was not successful, the resultCode
- will be one of:
-
- operationsError (operations sequencing incorrect; e.g. TLS already
- established)
+ TLS. The following result codes have these meanings for this
+ operation:
- protocolError (TLS not supported or incorrect PDU structure)
+ - operationsError: operations sequencing incorrect; e.g. TLS is
+ already established.
- referral (this server doesn't do TLS, try this one)
+ - protocolError: TLS is not supported or incorrect PDU structure.
- unavailable (e.g. some major problem with TLS, or server is
- shutting down)
+ - unavailable: Some major problem with TLS, or the server is
+ shutting down.
The server MUST return operationsError if the client violates any of
- the Start TLS extended operation sequencing requirements described in
- section 5.3 of [AuthMeth].
+ the StartTLS extended operation sequencing requirements described in
+ Section 5.3 of [AuthMeth].
If the server does not support TLS (whether by design or by current
- configuration), it MUST set the resultCode to protocolError, or to
- referral. The server MUST include an actual referral value in the
- LDAP Result if it returns a resultCode of referral. The client's
- current session is unaffected if the server does not support TLS. The
- client MAY proceed with any LDAP operation, or it MAY close the
- connection.
+ configuration), it MUST set the resultCode field to protocolError.
+ The client's current association is unaffected if the server does not
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 32 \f
+ Lightweight Directory Access Protocol Version 3
+
+ support TLS. The client may proceed with any LDAP operation, or it
+ may close the connection.
The server MUST return unavailable if it supports TLS but cannot
establish a TLS connection for some reason, e.g. the certificate
server not responding, it cannot contact its TLS implementation, or
- if the server is in process of shutting down. The client MAY retry
- the StartTLS operation, or it MAY proceed with any other LDAP
- operation, or it MAY close the connection.
+ if the server is in process of shutting down. The client may retry
+ the StartTLS operation, or it may proceed with any other LDAP
+ operation, or it may close the LDAP connection.
4.13.3. Closing a TLS Connection
- Two forms of TLS connection closure--graceful and abrupt--are
+ Two forms of TLS connection closure -- graceful and abrupt -- are
supported.
4.13.3.1. Graceful Closure
Either the client or server MAY terminate the TLS connection and
- leave the LDAP session intact by sending a TLS closure alert.
+ leave the LDAP connection intact by sending and receiving a TLS
+ closure alert.
- Before sending a TLS closure alert, the client MUST either wait for
- any outstanding LDAP operations to complete, or explicitly abandon
- them.
+ The initiating protocol peer sends the TLS closure alert. If it
+ wishes to leave the LDAP connection intact, it then MUST cease to
+ send further PDUs and MUST ignore any received PDUs until it receives
+ a TLS closure alert from the other peer.
- After the initiator of a close has sent a TLS closure alert, it MUST
- discard any TLS messages until it has received a TLS closure alert
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 30 \f
- Lightweight Directory Access Protocol Version 3
-
- from the other party. It will cease to send TLS Record Protocol
- PDUs, and following the receipt of the alert, MAY send and receive
- LDAP PDUs.
+ Once the initiating protocol peer receives a TLS closure alert from
+ the other peer it MAY send and receive LDAP PDUs.
- The other party, if it receives a TLS closure alert, MUST immediately
- transmit a TLS closure alert. It will subsequently cease to send TLS
- Record Protocol PDUs, and MAY send and receive LDAP PDUs.
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the underlying LDAP connection intact. In this case,
+ it MUST immediately transmit a TLS closure alert. Following this, it
+ MAY send and receive LDAP PDUs.
+
+ Protocol peers MAY drop the underlying LDAP connection after sending
+ or receiving a TLS closure alert.
+
+ After the TLS connection has been closed, the server MUST NOT send
+ responses to any request message received before the TLS closure.
+ Thus, clients wishing to receive responses to messages sent while the
+ TLS connection is intact MUST wait for those message responses before
+ sending the TLS closure alert.
4.13.3.2. Abrupt Closure
Either the client or server MAY abruptly close the TLS connection by
dropping the underlying transfer protocol connection. In this
circumstance, a server MAY send the client a Notice of Disconnection
- before dropping the underlying connection.
+ before dropping the underlying LDAP connection.
5. Protocol Element Encodings and Transfer
- One underlying service is defined here. Clients and servers SHOULD
- implement the mapping of LDAP over TCP described in 5.2.1.
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 33 \f
+ Lightweight Directory Access Protocol Version 3
+
+ One underlying service, LDAP over TCP, is defined here. This service
+ is generally applicable to applications providing or consuming X.500-
+ based directory services on the Internet.
+ Implementations of LDAP over TCP MUST implement the mapping as
+ described in Section 5.2.1
+
5.1. Protocol Encoding
- The protocol elements of LDAP are encoded for exchange using the
- Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. However, due to
- the high overhead involved in using certain elements of the BER, the
- following additional restrictions are placed on BER-encodings of LDAP
- protocol elements:
+ The protocol elements of LDAP SHALL be encoded for exchange using the
+ Basic Encoding Rules [BER] of [ASN.1] with the following
+ restrictions:
- (1) Only the definite form of length encoding will be used.
+ (1) Only the definite form of length encoding is used.
- (2) OCTET STRING values will be encoded in the primitive form only.
+ (2) OCTET STRING values are encoded in the primitive form only.
- (3) If the value of a BOOLEAN type is true, the encoding MUST have
- its contents octets set to hex "FF".
+ (3) If the value of a BOOLEAN type is true, the encoding of the
+ value octet is set to hex "FF".
- (4) If a value of a type is its default value, it MUST be absent.
- Only some BOOLEAN and INTEGER types have default values in this
+ (4) 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
- noted.
+ stated.
5.2. Transfer Protocols
stream.
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 31 \f
- Lightweight Directory Access Protocol Version 3
-
5.2.1. 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
+ 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 assigned port, 389. Servers may
instead provide a listener on a different port number. Clients MUST
support contacting servers on any valid TCP port.
-6. Implementation Guidelines
-
-
-6.1. Server Implementations
-
- The server MUST be capable of recognizing all the mandatory attribute
- type names and implement the syntaxes specified in [Syntaxes].
- Servers MAY also recognize additional attribute type names.
-
+6. Security Considerations
-6.2. Client Implementations
-
- Clients that follow referrals or 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
- target entry name, scope and filter. 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 a DIT with at least
- ten layers of naming contexts between the root and a leaf entry.
-
- In the absence of prior agreements with servers, clients SHOULD NOT
- assume that servers support any particular schemas beyond those
- referenced in section 6.1. Different schemas can have different
- attribute types with the same names. The client can retrieve the
- subschema entries referenced by the subschemaSubentry attribute in
- the entries held by the server.
-
-
-7. Security Considerations
-
- When used with a connection-oriented transport, this version of the
- protocol provides facilities for simple authentication using a
- cleartext password, as well as any SASL mechanism [RFC2222]. SASL
- allows for integrity and privacy services to be negotiated.
+ This version of the protocol provides facilities for simple
+ authentication using a cleartext password, as well as any [SASL]
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 34 \f
+ Lightweight Directory Access Protocol Version 3
+
+ mechanism. SASL allows for integrity and privacy services to be
+ negotiated.
It is also permitted that the server can return its credentials to
the client, if it chooses to do so.
underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties.
- When used with SASL, it should be noted that the name field of the
- BindRequest is not protected against modification. Thus if the
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 32 \f
- Lightweight Directory Access Protocol Version 3
-
- distinguished name of the client (an LDAPDN) is agreed through the
- negotiation of the credentials, it takes precedence over any value in
- the unprotected name field.
+ Servers are encouraged to prevent directory modifications by clients
+ that have authenticated anonymously [AuthMeth].
+
+ Requirements of 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 bind request nor the resultCode, diagnosticMessage, or
+ referral fields of the bind response nor of any information contained
+ in controls attached to bind request 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).
+
+ Server implementors should plan for the possibility of an identity
+ associated with an LDAP connection being deleted, renamed, or
+ modified, and take appropriate actions to prevent insecure side
+ effects. Likewise, server implementors should plan for the
+ possibility of an associated identity's credentials becoming invalid,
+ or an identities privileges being changed. The way in which these
+ issues are addressed are application
+ and/or implementation specific.
Implementations which cache attributes and entries obtained via LDAP
MUST ensure that access controls are maintained if that information
such referrals into the data stream in an attempt to redirect a
client to a rogue server. Protocol clients are advised to be aware of
this, and possibly reject referrals when confidentiality measures are
- in place. Protocol clients are advised to ignore referrals from the
- Start TLS operation.
+ not in place. Protocol clients are advised to reject referrals from
+ the StartTLS operation.
+
+ Protocol peers MUST be prepared to handle invalid and arbitrary
+ length protocol encodings. A number of LDAP security advisories are
+ available through [CERT].
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 35 \f
+ Lightweight Directory Access Protocol Version 3
+
-8. Acknowledgements
+7. Acknowledgements
- This document is an update to RFC 2251, by Mark Wahl, Tim Howes, and
- Steve Kille. Their work along with the input of individuals of the
- IETF LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully
+ This document updates RFC 2251 by Mark Wahl, Tim Howes, and Steve
+ Kille. It also updates RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. Their work along with the input of individuals of the IETF
+ ASID, LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully
acknowledged.
-9. Normative References
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt (a work in
- progress).
+8. Normative References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
- Information Technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation
+ [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"
- [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules:
- Basic, Canonical, and Distinguished Encoding Rules", 1994.
+ [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
+ Level Security Mechanisms ", draft-ietf-ldapbis-authmeth-
+ xx.txt, (a work in progress).
- [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
- ldapbis-xx.txt (a work in progress).
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+ [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
+ September 1981
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
+
+ [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
+ work in progress).
+
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
+ ldapbis-bcp64-xx.txt, (a work in progress).
+
+ [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
+ ldapbis-url-xx.txt, (a work in progress).
+
+ [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt (a work in progress).
+
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
-Sermersheim Internet-Draft - Expires Sep 2003 Page 33 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 36 \f
Lightweight Directory Access Protocol Version 3
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of Unicode
- and ISO 10646", RFC 2279, January 1998.
+ [SASL] Melnikov, A., "Simple Authentication and Security Layer",
+ draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
- models-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).
- [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-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
- [Syntaxes] K. Dally (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
- syntaxes-xx.txt, (a work in progress).
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
+ draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [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 Unicode
+ and ISO 10646", STD63 and RFC3629.
+
+ [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.
- [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
- [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods",
- draft-ietf-ldapbis-authmeth-xx.txt, (a work in progress).
+9. Informative References
- [RFC2222] Meyers, J., "Simple Authentication and Security Layer",
- RFC 2222, October 1997.
+ [CERT] the CERT(R) Center, (http://www.cert.org)
+10. IANA Considerations
+
+
+
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 37 \f
+ Lightweight Directory Access Protocol Version 3
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the occurrence of "RFC XXXX" in Appendix B with this RFC
+ number at publication.
-10. Editor's Address
+11. Editor's Address
Jim Sermersheim
Novell, Inc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Sep 2003 Page 34 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 38 \f
Lightweight Directory Access Protocol Version 3
Appendix A - LDAP Result Codes
LDAP result codes and provides a brief, general description of each
LDAP result code enumerated in Section 4.1.10.
- Additional result codes MAY be defined for use with extensions.
- Client implementations SHALL treat any result code which they do not
- recognize as an unknown error condition.
+ 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.
A.1 Non-Error Result Codes
+
These result codes (called "non-error" result codes) do not indicate
an error condition:
- success(0),
- compareTrue(6),
- compareFalse(7),
- referral(10), and
- saslBindInProgress(14).
-
- The success(0), compareTrue(6), and compare(7) result codes indicate
- successful completion (and, hence, are called to as "successful"
+ success (0),
+ compareTrue (6),
+ compareFalse (7),
+ referral (10), and
+ saslBindInProgress (14).
+
+ The success, compareTrue, and compare result codes indicate
+ successful completion (and, hence, are referred to as "successful"
result codes).
- The referral(10) and saslBindInProgress(14) indicate the client is
- required to take additional action to complete the operation
+ The referral and saslBindInProgress result codes indicate the client
+ is required to take additional action to complete the operation
-A.2 Error Result Codes
-
-A.3 Classes and Precedence of Error Result Codes
-
- Result codes that indicate error conditions (and, hence, are called
- "error" result codes) fall into 6 classes. The following list
- specifies the precedence of error classes to be used when more than
- one error is detected [X511]:
- 1) Name Errors (codes 32 - 34, 36)
- - a problem related to a name (DN or RDN),
- 2) Update Errors (codes 64 - 69, 71)
- - a problem related to an update operation,
- 3) Attribute Errors (codes 16 - 21)
- - a problem related to a supplied attribute,
- 4) Security Errors (codes 8, 13, 48 - 50)
- - a security related problem,
- 5) Service Problem (codes 3, 4, 7, 11, 12, 51 - 54, 80)
- - a problem related to the provision of the service, and
- 6) Protocol Problem (codes 1, 2)
- - a problem related to protocol structure or semantics.
-
- If the server detects multiple errors simultaneously, the server
- SHOULD report the error with the highest precedence.
+A.2 Result Codes
Existing LDAP result codes are described as follows:
success (0)
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 35 \f
- Lightweight Directory Access Protocol Version 3
-
-
- Indicates successful completion of an operation.
-
- This result code is normally not returned by the compare
- operation, see compareFalse (5) and compareTrue (6). It is
- possible that a future extension mechanism would allow this
- to be returned by a compare operation.
-
+ Indicates the successful completion of an operation. Note:
+ this code is not used with the compare operation. See
+ compareTrue (5) and compareFalse (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
- Start TLS [RFC2246] while there are other operations
+ StartTLS [RFC2246] while there are other operations
outstanding or if TLS was already established.
-
-
protocolError (2)
-
Indicates the server received data which has incorrect
structure.
- For bind operation only, the code may be resulted to indicate
- the server does not support the requested protocol version.
+ For bind operation only, this code is also used to indicate
+ that the server does not support the requested protocol
+ version.
-
timeLimitExceeded (3)
-
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 39 \f
+ Lightweight Directory Access Protocol Version 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 operation successfully completes and the
- assertion has evaluated to FALSE.
-
- This result code is normally only returned by the compare
- operation.
-
+ Indicates that the compare operation has successfully
+ completed and the assertion has evaluated to FALSE.
compareTrue (6)
-
- Indicates that the operation successfully completes and the
- assertion has evaluated to TRUE.
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 36 \f
- Lightweight Directory Access Protocol Version 3
-
-
- This result code is normally only returned by the compare
- operation.
-
+ 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.
-
strongAuthRequired (8)
-
- Except when returned in a Notice of Disconnect (see section
- 4.4.1), this indicates that the server requires the client to
- authentication using a strong(er) mechanism.
-
+ Indicates that the server has detected that an established
+ security association between the client and server has
+ unexpectedly failed or been compromised, or that the server
+ now requires the client to authenticate using a strong(er)
+ mechanism.
referral (10)
-
Indicates that a referral needs to be chased to complete the
- operation (see section 4.1.11).
-
+ operation (see Section 4.1.11).
adminLimitExceeded (11)
-
Indicates that an administrative limit has been exceeded.
-
unavailableCriticalExtension (12)
-
- Indicates that server cannot perform a critical extension
- (see section 4.1.12).
-
+ Indicates that the server is unable or unwilling to perform a
+ critical extension (see Section 4.1.12).
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).
-
+ 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)
-Sermersheim Internet-Draft - Expires Sep 2003 Page 37 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 40 \f
Lightweight Directory Access Protocol Version 3
-
- Indicates that a request field contains an undefined
- attribute type.
-
-
- inappropriateMatching (18)
-
- Indicates that a request cannot be completed due to an
- inappropriate matching.
-
+ Indicates that an attempt was made, e.g. in a filter, 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 constraints placed upon it by the data
- model.
-
- For example, this code is returned when the multiple values
- are supplied to an attribute which has a SINGLE-VALUE
- constraint.
+ 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 already exists.
-
+ 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. Typically an
- alias has been dereferenced which names no object.
-
+ 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 a LDAPDN or RelativeLDAPDN field (e.g. search
+ 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 Sep 2003 Page 38 \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,
-
+ provide some form of credentials.
invalidCredentials (49)
-
- Indicates the supplied password or SASL credentials are
- invalid.
-
+ 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 busy.
-
+
+Sermersheim Internet-Draft - Expires Jun 2004 Page 41 \f
+ Lightweight Directory Access Protocol Version 3
+
+ 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.
-
namingViolation (64)
-
- Indicates that the entry name violates naming restrictions.
+ Indicates that the entry's name violates naming restrictions.
objectClassViolation (65)
-
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 39 \f
- Lightweight Directory Access Protocol Version 3
-
Indicates that the entry violates object class restrictions.
-
notAllowedOnNonLeaf (66)
-
- Indicates that operation is inappropriately acting upon a
+ 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 added fulfilled as the
- entry already exists.
-
+ Indicates that the request cannot be fulfilled (added, moved,
+ or renamed) as the target entry already exists.
objectClassModsProhibited (69)
+ Indicates that an attempt to modify the object class(es) of
+ an entry's objectClass attribute is prohibited.
- Indicates that the attempt to modify the object class(es) of
- an entry objectClass attribute is prohibited.
-
- For example, this code is returned when a when a client
- attempts to modify the structural object class of an entry.
-
+ 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 completed as it
affects multiple servers (DSAs).
-
other (80)
-
Indicates the server has encountered an internal error.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 40 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 42 \f
Lightweight Directory Access Protocol Version 3
- Appendix B - Complete ASN.1 Definition
+Appendix B - Complete ASN.1 Definition
This appendix is normative.
- Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
+ Lightweight-Directory-Access-Protocol-V3
+ -- Copyright (C) The Internet Society (2003). 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,
- ... },
- controls [0] Controls OPTIONAL }
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ... },
+ controls [0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
- LDAPOID ::= OCTET STRING -- Constrained to numericoid [Models]
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
AttributeDescription ::= LDAPString
- -- Constrained to attributedescription
- -- [Models]
-
- AttributeDescriptionList ::= SEQUENCE OF
-Sermersheim Internet-Draft - Expires Sep 2003 Page 41 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 43 \f
Lightweight Directory Access Protocol Version 3
- AttributeDescription
+ -- Constrained to <attributedescription>
+ -- [Models]
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
MatchingRuleId ::= LDAPString
LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (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 --
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (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),
-Sermersheim Internet-Draft - Expires Sep 2003 Page 42 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 44 \f
Lightweight Directory Access Protocol Version 3
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE OF LDAPURL
-
- LDAPURL ::= LDAPString -- limited to characters permitted in
- -- URLs
-
- Controls ::= SEQUENCE OF Control
+ 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),
+ ... },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ Controls ::= SEQUENCE OF control Control
Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
UnbindRequest ::= [APPLICATION 2] NULL
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
-Sermersheim Internet-Draft - Expires Sep 2003 Page 43 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 45 \f
Lightweight Directory Access Protocol Version 3
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
+ 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 selection LDAPString
Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF Filter,
- or [1] SET SIZE (1..MAX) OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
+ 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,
- -- at least one must be present,
- -- initial and final can occur at most once
- substrings SEQUENCE OF CHOICE {
- initial [0] AssertionValue,
- any [1] AssertionValue,
- final [2] AssertionValue } }
+ type AttributeDescription,
+ -- at least one must be present,
+ -- initial and final can occur at most once
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
+ objectName LDAPDN,
+ attributes PartialAttributeList }
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
-Sermersheim Internet-Draft - Expires Sep 2003 Page 44 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 46 \f
Lightweight Directory Access Protocol Version 3
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
+ SIZE (1..MAX) OF uri URI
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ 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 }
+ entry LDAPDN,
+ attributes AttributeList }
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
+ AttributeList ::= SEQUENCE OF attribute Attribute
AddResponse ::= [APPLICATION 9] LDAPResult
DelResponse ::= [APPLICATION 11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
+ entry LDAPDN,
+ ava AttributeValueAssertion }
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
END
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 45 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 47 \f
Lightweight Directory Access Protocol Version 3
-Appendix C - Change History
- <Note to RFC editor: This section is to be removed prior to RFC
- publication>
-
-C.1 Changes made to RFC 2251:
+Appendix C - Changes
-C.1.1 Editorial
-
- - Bibliography References: Changed all bibliography references to
- use a long name form for readability.
- - Changed occurrences of "unsupportedCriticalExtension"
- "unavailableCriticalExtension"
- - Fixed a small number of misspellings (mostly dropped letters).
-
-C.1.2 Section 1
-
- - Removed IESG note.
-
-C.1.3 Section 9
+ This appendix is non-normative.
- - Added references to RFCs 1823, 2234, 2829 and 2830.
+ This appendix summarizes substantive changes made to RFC 2251 and RFC
+ 2830.
-
-C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:
-C.2.1 Section 4.1.6
+C.1 Changes made to made to RFC 2251:
- - In the first paragraph, clarified what the contents of an
- AttributeValue are. There was confusion regarding whether or not
- an AttributeValue that is BER encoded (due to the "binary" option)
- is to be wrapped in an extra OCTET STRING.
- - To the first paragraph, added wording that doesn't restrict other
- transfer encoding specifiers from being used. The previous wording
- only allowed for the string encoding and the ;binary encoding.
- - To the first paragraph, added a statement restricting multiple
- options that specify transfer encoding from being present. This
- was never specified in the previous version and was seen as a
- potential interoperability problem.
- - Added a third paragraph stating that the ;binary option is
- currently the only option defined that specifies the transfer
- encoding. This is for completeness.
+ 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.2.2 Section 4.1.7
- - Generalized the second paragraph to read "If an option specifying
- the transfer encoding is present in attributeDesc, the
- AssertionValue is encoded as specified by the option...".
- Previously, only the ;binary option was mentioned.
+C.1.1 Section 1
-C.2.3 Sections 4.2, 4.9, 4.10
+ - 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.
- - Added alias dereferencing specifications. In the case of modDN,
- followed precedent set on other update operations (... alias is
- not dereferenced...) In the case of bind and compare stated that
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 46 \f
- Lightweight Directory Access Protocol Version 3
-
- servers SHOULD NOT dereference aliases. Specifications were added
- because they were missing from the previous version and caused
- interoperability problems. Concessions were made for bind and
- compare (neither should have ever allowed alias dereferencing) by
- using SHOULD NOT language, due to the behavior of some existing
- implementations.
-C.2.4 Sections 4.5 and Appendix A
+C.1.2 Section 3.1 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.
- - Changed SubstringFilter.substrings.initial, any, and all from
- LDAPString to AssertionValue. This was causing an incompatibility
- with X.500 and confusion among other TS RFCs.
+C.1.3 Section 4
-C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:
+ - Clarified where the extensibility features of ASN.1 apply to the
+ protocol. This change also affected various ASN.1 types.
+ - Removed the requirement that servers which implement version 3 or
+ later MUST provide the supportedLDAPVersion attribute. This
+ statement provided no interoperability advantages.
-C.3.1 Section 3.4
-
- - Reworded text surrounding subschemaSubentry to reflect that it is
- a single-valued attribute that holds the schema for the root DSE.
- Also noted that if the server masters entries that use differing
- schema, each entry's subschemaSubentry attribute must be
- interrogated. This may change as further fine-tuning is done to
- the data model.
-
-C.3.2 Section 4.1.12
-
- - Specified that the criticality field is only used for requests and
- not for unbind or abandon. Noted that it is ignored for all other
- operations.
-
-C.3.3 Section 4.2
-
- - Noted that Server behavior is undefined when the name is a null
- value, simple authentication is used, and a password is specified.
-
-C.3.4 Section 4.2.(various)
-
- - Changed "unauthenticated" to "anonymous" and "DN" and "LDAPDN" to
- "name"
-
-C.3.5 Section 4.2.2
-
- - Changed "there is no authentication or encryption being performed
- by a lower layer" to "the underlying transport service cannot
- guarantee confidentiality"
-
-C.3.6 Section 4.5.2
-
- - Removed all mention of ExtendedResponse due to lack of
- implementation.
-
-C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 47 \f
- Lightweight Directory Access Protocol Version 3
-
-C.4.1 Section 4
-
- - Removed "typically" from "and is typically transferred" in the
- first paragraph. We know of no (and can conceive of no) case where
- this isn't true.
- - Added "Section 5.1 specifies how the LDAP protocol is encoded." To
- the first paragraph. Added this cross reference for readability.
- - Changed "version 3 " to "version 3 or later" in the second
- paragraph. This was added to clarify the original intent.
- - Changed "protocol version" to "protocol versions" in the third
- paragraph. This attribute is multi-valued with the intent of
- holding all supported versions, not just one.
-
-C.4.2 Section 4.1.8
-
- - Changed "when transferred in protocol" to "when transferred from
- the server to the client" in the first paragraph. This is to
- clarify that this behavior only happens when attributes are being
- sent from the server.
-
-C.4.3 Section 4.1.10
-
- - Changed "servers will return responses containing fields of type
- LDAPResult" to "servers will return responses of LDAPResult or
- responses containing the components of LDAPResponse". This
- statement was incorrect and at odds with the ASN.1. The fix here
- reflects the original intent.
- - Dropped '--new' from result codes ASN.1. This simplification in
- comments just reduces unneeded verbiage.
-
-C.4.4 Section 4.1.11
-
- - Changed "It contains a reference to another server (or set of
- servers)" to "It contains one or more references to one or more
- servers or services" in the first paragraph. This reflects the
- original intent and clarifies that the URL may point to non-LDAP
- services.
-
-C.4.5 Section 4.1.12
-
- - 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.4.6 Section 4.4
-
- - Changed "One unsolicited notification is defined" to "One
- unsolicited notification (Notice of Disconnection) is defined" in
- the third paragraph. For clarity and readability.
+C.1.4 Section 4.1.1
-C.4.7 Section 4.5.1
-
+ - There was a mandatory requirement for the server to return a
+ Notice of Disconnection and drop the connection when a PDU is
+ malformed in a certain way. This has been clarified such that the
+ server SHOULD return the Notice of Disconnection, and MUST drop
+ the connection.
+
+
+C.1.5 Section 4.1.1.1
+
+ - Clarified that the messageID of requests MUST be non-zero.
+
-Sermersheim Internet-Draft - Expires Sep 2003 Page 48 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 48 \f
Lightweight Directory Access Protocol Version 3
- - Changed "checking for the existence of the objectClass attribute"
- to "checking for the presence of the objectClass attribute" in the
- last paragraph. This was done as a measure of consistency (we use
- the terms present and presence rather than exists and existence in
- search filters).
+ - Clarified 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.4.8 Section 4.5.3
-
- - Changed "outstanding search operations to different servers," to
- "outstanding search operations" in the fifth paragraph as they may
- be to the same server. This is a point of clarification.
-C.4.9 Section 4.6
-
- - Changed "clients MUST NOT attempt to delete" to "clients MUST NOT
- attempt to add or delete" in the second to last paragraph.
- - Change "using the "delete" form" to "using the "add" or "delete"
- form" in the second to last paragraph.
+C.1.6 Section 4.1.2
-C.4.10 Section 4.7
-
- - Changed "Clients MUST NOT supply the createTimestamp or
- creatorsName attributes, since these will be generated
- automatically by the server." to "Clients MUST NOT supply NO-USER-
- MODIFICATION attributes such as createTimestamp or creatorsName
- attributes, since these are provided by the server." in the
- definition of the attributes field. This tightens the language to
- reflect the original intent and to not leave a hole in which one
- could interpret the two attributes mentioned as the only non-
- writable attributes.
+ - Stated that LDAPOID is constrained to <numericoid> from [Models].
-C.4.11 Section 4.11
-
- - Changed "has been" to "will be" in the fourth paragraph. This
- clarifies that the server will (not has) abandon the operation.
-
-C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:
-
-C.5.1 Section 3.2.1
-
- - Changed "An attribute is a type with one or more associated
- values. The attribute type is identified by a short descriptive
- name and an OID (object identifier). The attribute type governs
- whether there can be more than one value of an attribute of that
- type in an entry, the syntax to which the values must conform, the
- kinds of matching which can be performed on values of that
- attribute, and other functions." to " An attribute is a
- description (a type and zero or more options) with one or more
- associated values. The attribute type governs whether the
- attribute can have multiple values, the syntax and matching rules
- used to construct and compare values of that attribute, and other
- functions. Options indicate modes of transfer and other
-
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 49 \f
- Lightweight Directory Access Protocol Version 3
-
- functions.". This points out that an attribute consists of both
- the type and options.
-
-C.5.2 Section 4
-
- - Changed "Section 5.1 specifies the encoding rules for the LDAP
- protocol" to "Section 5.1 specifies how the protocol is encoded
- and transferred."
-
-C.5.3 Section 4.1.2
-
- - Added ABNF for the textual representation of LDAPOID. Previously,
- there was no formal BNF for this construct.
-
-C.5.4 Section 4.1.4
-
- - Changed "This identifier may be written as decimal digits with
- components separated by periods, e.g. "2.5.4.10"" to "may be
- written as defined by ldapOID in section 4.1.2" in the second
- paragraph. This was done because we now have a formal BNF
- definition of an oid.
-
-C.5.5 Section 4.1.5
-
- - Changed the BNF for AttributeDescription to ABNF. This was done
- for readability and consistency (no functional changes involved).
- - Changed "Options present in an AttributeDescription are never
- mutually exclusive." to "Options MAY be mutually exclusive. An
- AttributeDescription with mutually exclusive options is treated as
- an undefined attribute type." for clarity. It is generally
- understood that this is the original intent, but the wording could
- be easily misinterpreted.
- - Changed "Any option could be associated with any AttributeType,
- although not all combinations may be supported by a server." to
- "Though any option or set of options could be associated with any
- AttributeType, the server support for certain combinations may be
- restricted by attribute type, syntaxes, or other factors.". This
- is to clarify the meaning of 'combination' (it applies both to
- combination of attribute type and options, and combination of
- options). It also gives examples of *why* they might be
- unsupported.
-
-C.5.6 Section 4.1.11
-
- - Changed the wording regarding 'equally capable' referrals to "If
- multiple URLs are present, the client assumes that any URL may be
- used to progress the operation.". The previous language implied
- that the server MUST enforce rules that it was practically
- incapable of. The new language highlights the original intent--
- that is, that any of the referrals may be used to progress the
- operation, there is no inherent 'weighting' mechanism.
-
-C.5.7 Section 4.5.1 and Appendix A
-
+C.1.7 Section 4.1.5.1
+
+ - 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.6
+
+ - Removed references to the "binary" encoding as it has been removed
+ from the specification.
+
+
+C.1.9 Section 4.1.7
+
+ - Removed references to the "binary" encoding as it has been removed
+ from the specification.
+
+
+C.1.10 Section 4.1.8
+
+ - Combined the definitions of PartialAttribute and Attribute here,
+ and defined Attribute in terms of PartialAttribute.
+
+
+C.1.11 Section 4.1.10
+
+ - 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.
+
+
+C.1.12 Section 4.1.11
+
+ - 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.
-Sermersheim Internet-Draft - Expires Sep 2003 Page 50 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 49 \f
Lightweight Directory Access Protocol Version 3
- - Added the comment "-- initial and final can occur at most once",
- to clarify this restriction.
-
-C.5.8 Section 5.1
-
- - Changed heading from "Mapping Onto BER-based Transport Services"
- to "Protocol Encoding".
-
-C.5.9 Section 5.2.1
-
- - Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs"
- to point out that the PDUs are encoded before being streamed to
- TCP.
-
-C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:
-
-C.6.1 Section 4.5.1 and Appendix A
- - Changed the ASN.1 for the and and or choices of Filter to have a
- lower range of 1. This was an omission in the original ASN.1
-
-C.6.2 Various
-
- - Fixed various typo's
-C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:
-
-C.7.1 Section 3.2.1
+C.1.13 Section 4.1.12
- - Added "(as defined in Section 12.4.1 of [X.501])" to the fifth
- paragraph when talking about "operational attributes". This is
- because the term "operational attributes" is never defined.
- Alternately, we could drag a definition into the spec, for now,
- I'm just pointing to the reference in X.501.
-
-C.7.2 Section 4.1.5
-
- - Changed "And is also case insensitive" to "The entire
- AttributeDescription is case insensitive". This is to clarify
- whether we're talking about the entire attribute description, or
- just the options.
-
- - Expounded on the definition of attribute description options. This
- doc now specifies a difference between transfer and tagging
- options and describes the semantics of each, and how and when
- subtyping rules apply. Now allow options to be transmitted in any
- order but disallow any ordering semantics to be implied. These
- changes are the result of ongoing input from an engineering team
- designed to deal with ambiguity issues surrounding attribute
- options.
-
-C.7.3 Sections 4.1.5.1 and 4.1.6
-
-
+ - Specified how control values defined in terms of ASN.1 are to be
+ encoded.
+ - Added language regarding combinations of controls on a message.
+ - 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.14 Section 4.2
+
+ - Mandated that servers return protocolError when the version is not
+ supported.
+ - Clarified 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.15 Section 4.2.1
+
+ - 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."
+ Each SASL negotiation is, generally, independent of other SASL
+ negotiations. If there were dependencies between multiple
+ negotiations of a particular mechanism, the mechanism technical
+ specification should detail how applications are to deal with
+ them. LDAP should not require any special handling. And if an LDAP
+ client had used such a mechanism, it would have the option of
+ using another mechanism.
+ - Dropped MUST imperative in paragraph 3 to align with [Keywords].
+
+
+C.1.16 Section 4.2.3
+
+ - 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.
-Sermersheim Internet-Draft - Expires Sep 2003 Page 51 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 50 \f
Lightweight Directory Access Protocol Version 3
- - Refer to non "binary" transfer encodings as "native encoding"
- rather than "string" encoding to clarify and avoid confusion.
-C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:
-C.8.1 Title
-
- - Changed to "LDAP: The Protocol" to be consisted with other working
- group documents
-
-C.8.2 Abstract
-
- - Moved above TOC to conform to new guidelines
-
- - Reworded to make consistent with other WG documents.
-
- - Moved 2119 conventions to "Conventions" section
-
-C.8.3 Introduction
-
- - Created to conform to new guidelines
-
-C.8.4 Models
+C.1.17 Section 4.3
+
+ - Required both peers to cease transmission and close the connection
+ for the unbind operation.
- - Removed section. There is only one model in this document
- (Protocol Model)
-C.8.5 Protocol Model
+C.1.18 Section 4.4
+
+ - Added instructions for future specifications of Unsolicited
+ Notifications.
- - Removed antiquated paragraph: "In keeping with the goal of easing
- the costs associated with use of the directory, it is an objective
- of this protocol to minimize the complexity of clients so as to
- facilitate widespread deployment of applications capable of using
- the directory."
- - Removed antiquated paragraph concerning LDAP v1 and v2 and
- referrals.
+C.1.19 Section 4.5.1
+
+ - SearchRequest attributes is now defined as an AttributeSelection
+ type rather than AttributeDescriptionList.
+ - The Filter choices 'and' and 'or', and the SubstringFilter
+ substrings types are now defined with a lower bound of 1.
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types
+ are now AssertionValue rather than LDAPString.
+ - Clarified the semantics of the derefAliases choices.
+ - Added instructions for equalityMatch, substrings, greaterOrEqual,
+ lessOrEqual, and approxMatch.
-C.8.6 Data Model
- - Removed Section 3.2 and subsections. These have been moved to
- [Models]
+C.1.20 Section 4.5.2
+
+ - Recommended that servers not use attribute short names when it
+ knows they are ambiguous or may cause interoperability problems.
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
-C.8.7 Relationship to X.500
- - Removed section. It has been moved to [Roadmap]
+C.1.21 Section 4.5.3
+
+ - Made changes similar to those made to Section 4.1.11.
-C.8.8 Server Specific Data Requirements
- - Removed section. It has been moved to [Models]
+C.1.22 Section 4.5.3.1
+
+ - Fixed examples to adhere to changes made to Section 4.5.3.
-C.8.9 Elements of Protocol
+C.1.23 Section 4.6
+
+ - Removed restriction that required an equality match filter in
+ order to perform value delete modifications. It is sufficiently
+ documented that in absence of an equality matching rule, octet
+ equality is used.
+ - Replaced AttributeTypeAndValues with Attribute as they are
+ equivalent.
-Sermersheim Internet-Draft - Expires Sep 2003 Page 52 \f
- Lightweight Directory Access Protocol Version 3
-
- - Added "Section 5.1 specifies how the protocol is encoded and
- transferred." to the end of the first paragraph for reference.
-
- - Reworded notes about extensibility, and now talk about implied
- extensibility and the use of ellipses in the ASN.1
-
- - Removed references to LDAPv2 in third and fourth paragraphs.
-
-C.8.10 Message ID
-
- - Reworded second paragraph to "The message ID of a request MUST
- have a non-zero value different from the values of any other
- requests outstanding in the LDAP session of which this message is
- a part. The zero value is reserved for the unsolicited
- notification message." (Added notes about non-zero and the zero
- value).
-
-C.8.11 String Types
-
- - Removed ABNF for LDAPOID and added "Although an LDAPOID is encoded
- as an OCTET STRING, values are limited to the definition of
- numericoid given in Section 1.3 of [Models]."
-
-C.8.12 Distinguished Name and Relative Distinguished Name
-
- - Removed ABNF and referred to [Models] and [LDAPDN] where this is
- defined.
-
-C.8.13 Attribute Type
-
- - Removed sections. It's now in the [Models] doc.
-
-C.8.14 Attribute Description
-
- - Removed ABNF and aligned section with [Models]
-
- - Moved AttributeDescriptionList here.
-
-C.8.15 Transfer Options
-
- - Added section and consumed much of old options language (while
- aligning with [Models]
-
-C.8.16 Binary Transfer Option
-
- - Clarified intent regarding exactly what is to be BER encoded.
-
- - Clarified that clients must not expect ;binary when not asking for
- it (;binary, as opposed to ber encoded data).
-
-
-C.8.17 Attribute
-
- - Use the term "attribute description" in lieu of "type"
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 53 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 51 \f
Lightweight Directory Access Protocol Version 3
+ - Clarified what type of modification changes might temporarily
+ violate schema.
- - Clarified the fact that clients cannot rely on any apparent
- ordering of attribute values.
-
-C.8.18 LDAPResult
-
- - To resultCode, added ellipses "..." to the enumeration to indicate
- extensibility. and added a note, pointing to [LDAPIANA]
-
- - Removed error groupings ad refer to Appendix A.
-
-C.8.19 Bind Operation
-
- - Added "Prior to the BindRequest, the implied identity is
- anonymous. Refer to [AuthMeth] for the authentication-related
- semantics of this operation." to the first paragraph.
-
- - Added ellipses "..." to AuthenticationChoice and added a note
- "This type is extensible as defined in Section 3.6 of [LDAPIANA].
- Servers that do not support a choice supplied by a client will
- return authMethodNotSupported in the result code of the
- BindResponse."
-
- - Simplified text regarding how the server handles unknown versions.
- Removed references to LDAPv2
-
-C.8.20 Sequencing of the Bind Request
-
- - Aligned with [AuthMeth] In particular, paragraphs 4 and 6 were
- removed, while a portion of 4 was retained (see C.8.9)
-
-C.8.21 Authentication and other Security Service
-
- - Section was removed. Now in [AuthMeth]
-
-C.8.22 Continuation References in the Search Result
-
- - Added "If the originating search scope was singleLevel, the scope
- part of the URL will be baseObject."
-
-C.8.23 Security Considerations
-
- - Removed reference to LDAPv2
-C.8.24 Result Codes
-
- - Added as normative appendix A
-
-C.8.25 ASN.1
-
- - Added EXTENSIBILITY IMPLIED
-
- - Added a number of comments holding referenced to [Models] and
- [ISO10646].
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 54 \f
- Lightweight Directory Access Protocol Version 3
-
-
- - Removed AttributeType. It is not used.
-
-
-C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:
-
- - Removed all mention of transfer encodings and the binary attribute
- option
-
- - Further alignment with [Models].
-
- - Added extensibility ellipsis to protocol op choice
-
- - In 4.1.1, clarified when connections may be dropped due to
- malformed PDUs
-
- - Specified which matching rules and syntaxes are used for various
- filter items
+C.1.24 Section 4.9
-C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt:
-
-C.10.1 Section 4.1.1.1:
-
- - Clarified when it is and isn't appropriate to return an already
- used message id.
-
-C.10.2 Section 4.1.11:
-
- - Clarified that a control only applies to the message it's attached
- to.
-
- - Explained that the criticality field is only applicable to certain
- request messages.
-
- - Added language regarding the combination of controls.
+ - 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.
-C.10.3 Section 4.11:
-
- - Explained that Abandon and Unbind cannot be abandoned, and
- illustrated how to determine whether an operation has been
- abandoned.
+C.1.25 Section 4.10
-C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt:
+ - Clarified the semantics of Compare when the attribute is not
+ present and when it is unknown.
+ - Required servers to not dereference aliases for compare. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
- - Fixed formatting
+C.1.26 Section 4.11
-C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt:
-
-C.12.1 Section 4.1.4:
+ - Explained that since abandon returns no response, clients hould
+ not use it if they need to know the outcome.
+ - Specified that Abandon and Unbind cannot be abandoned.
- - Removed second paragraph as this language exists in MODELS
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 55 \f
- Lightweight Directory Access Protocol Version 3
-
-C.12.2 Section 4.2.1:
-
- - Replaced fourth paragraph. It was accidentally removed in an
- earlier edit.
+C.1.27 Section 4.12
-C.12.2 Section 4.13:
-
- - Added section describing the StartTLS operation (moved from
- authmeth)
+ - 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.13 Changes made to draft-ietf-ldapbis-protocol-11.txt:
-
-C.13.1 Section 4.1.9
- - Changed "errorMessage" to "diagnosticMessage". Simply to indicate
- that the field may be non-empty even if a non-error resultCode is
- present.
+C.1.28 Section 5.2
-C.13.2 Section 4.2:
-
- - Reconciled language in "name" definition with [AuthMeth]
-
-C.13.3 Section 4.2.1
-
- - Renamed to "Processing of the Bind Request", and moved some text
- from 4.2 into this section.
-
- - Rearranged paragraphs to flow better.
-
- - Specified that (as well as failed) an abandoned bind operation
- will leave the connection in an anonymous state.
-
-C.13.4 Section 4.5.3
-
- - Generalized the second paragraph which cited indexing and
- searchreferralreferences.
+ - Moved referral-specific instructions into referral-related
+ sections.
-C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt:
-
- - Reworked bind errors.
- - General clarifications and edits
-
-Appendix D - Outstanding Work Items
-D.0 General
- - Integrate notational consistency agreements WG will discuss
- notation consistency. Once agreement happens, reconcile draft.
-
- - Reconcile problems with [Models]. Section 3.2 was wholly removed.
- There were some protocol semantics in that section that need to be
- brought back. Specifically, there was the notion of the server
- implicitly adding objectclass superclasses when a value is added.
-
-D.1 Make result code usage consistent.
+C.1.29 Section 7
+
+ - Reworded notes regarding SASL not protecting certain aspects of
+ the LDAP bind PDU.
+ - Noted that Servers are encouraged to prevent directory
+ modifications by clients that have authenticated anonymously
+ [AuthMeth].
+ - Added a note regarding the scenario where an identity is changed
+ (deleted, privileges or credentials modified, etc.).
+
-Sermersheim Internet-Draft - Expires Sep 2003 Page 56 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 52 \f
Lightweight Directory Access Protocol Version 3
+ - Warned against following referrals that may have been injected in
+ the data stream.
+ - Added a note regarding malformed and long encodings.
- - While there is a result code appendix, ensure it speaks of result
- codes in a general sense, and only highlight specific result codes
- in the context of an operation when that operation ties more
- specific meanings to that result code.
-
-
-D.2 Verify references.
-
- - Many referenced documents have changed. Ensure references and
- section numbers are correct.
-
-D.3 Usage of Naming Context
- - Make sure occurrences of "namingcontext" and "naming context" are
- consistent with [Models]. Use in section 6.2 should be reworked.
- It's layers of indirection that matter, not number of contexts.
- (That is, referrals can be returned for a number of reasons (cross
- reference, superior, subordinate, busy, not master, etc.)
-
- Other uses are fine.
+C.1.30 Appendix A
-D.4 Review 2119 usage
-
-
-D.5 Reconcile with I-D Nits
-
+ - Added "EXTESIBILITY IMPLIED" to ASN.1 definition.
+ - Removed AttributeType. It is not used.
-D.23 Section 4.5.3
-
- - A server MUST NOT return any SearchResultReference if it has not
- located the baseObject and thus has not searched any entries; in
- this case it would return a SearchResultDone containing a referral
- resultCode.
-
- - Add "Similarly, a server MUST NOT return a SearchResultReference
- when the scope of the search is baseObject. If a client receives
- such a SearchResultReference it MUST interpret is as a protocol
- error and MUST NOT follow it." to the first paragraph.
- The technical specification doesn't have to describe how a
- protocol peer should react when its partner violates an absolute.
- OR return noSuchObject.
+C.2 Changes made to made to RFC 2830:
- - Add "If the scope part of the LDAP URL is present, the client MUST
- use the new scope in its next request to progress the search. If
- the scope part is absent the client MUST use subtree scope to
- complete subtree searches and base scope to complete one level
- searches." to the third paragraph.
+ This section summarizes the substantive changes made to Sections of
+ RFC 2830. Readers should consult [AuthMeth] for summaries of changes
+ to other sections.
-D.25 Section 4.6
-
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 57 \f
- Lightweight Directory Access Protocol Version 3
-
- - Resolve the meaning of "and is ignored if the attribute does not
- exist". See "modify: "non-existent attribute"" on the list. Not
- sure if there's really an issue here. Will look at archive
-
-D.27 Section 4.10
-
- - Specify what happens when the attr is missing vs. attr isn't in
- schema. Also what happens if there's no equality matching rule.
- noSuchAttribute, undefinedAttributeType, inappropriateMatching
-
-D.30 Section 5.1
-
- - Add "control and extended operation values" to last paragraph. See
- "LBER (BER Restrictions)" on list.
-
-D.32 Section 6.1
-
- - Add "that are used by those attributes" to the first paragraph.
- - Add "Servers which support update operations MUST, and other
- servers SHOULD, support strong authentication mechanisms described
- in [RFC2829]." as a second paragraph. Likely should just say
- Requirements of authentication methods, SASL mechanisms, and TLS
- are described in [AUTHMETH]." (also apply to next two below)
- - Add "Servers which provide access to sensitive information MUST,
- and other servers SHOULD support privacy protections such as those
- described in [RFC2829] and [RFC2830]." as a third paragraph.
+C.2.1 Section 2.3
+
+ - Removed wording indicating that referrals can be returned from
+ StartTLS
-D.33 Section 7
- - Add "Servers which support update operations MUST, and other
- servers SHOULD, support strong authentication mechanisms described
- in [RFC2829]." as a fourth paragraph.
- - Add "In order to automatically follow referrals, clients may need
- to hold authentication secrets. This poses significant privacy and
- security concerns and SHOULD be avoided." as a sixth paragraph.
- There are concerns with "automatic" chasing regardless of which,
- if any, authentication method/mechanism is used.
+C.2.1 Section 4.13.3.1
- - Add notes regarding DoS attack found by CERT advisories.
+ - Reworded most of this section and added the requirement that after
+ the TLS connection has been closed, the server MUST NOT send
+ responses to any request message received before the TLS closure.
-D.34 Appendix C
- - C.9. Explain why we removed ;binary, and what clients can do to
- get around potential problems (likely refer to an I-D)
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Sermersheim Internet-Draft - Expires Sep 2003 Page 58 \f
+Sermersheim Internet-Draft - Expires Jun 2004 Page 53 \f
Lightweight Directory Access Protocol Version 3
- Full Copyright Statement
+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 (2002). All Rights Reserved.
+ 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Sep 2003 Page 59 \f
\ No newline at end of file
+Sermersheim Internet-Draft - Expires Jun 2004 Page 54 \f
+
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 March 2003
+Expires in six months 30 June 2003
Obsoletes: RFC 2251-2256, 2829-2830, 3377
LDAP: Technical Specification Road Map
- <draft-ietf-ldapbis-roadmap-02.txt>
+ <draft-ietf-ldapbis-roadmap-03.txt>
Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2003, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
Zeilenga LDAP: TS Road Map [Page 1]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
Conventions
LDAP: String Representation of Distinguished Names [LDAPDN],
LDAP: String Representation of Search Filters [Filters],
LDAP: Uniform Resource Locator [LDAPURL],
- LDAP: Syntaxes [Syntaxes], and
+ LDAP: Syntaxes and Matching Rules [Syntaxes],
+ LDAP: Internationalized String Preparation [LDAPprep], and
LDAP: User Schema [Schema].
The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
this document but may be defined in some future document(s).
IANA (Internet Assigned Numbers Authority) considerations for LDAP
- described in BCP 64 [RFC3383] apply fully to this revision of the LDAP
- technical specification.
+ described in BCP 64 [BCP64bis] apply fully to this revision of the
+ LDAP technical specification.
2. Relationship to X.500
This technical specification defines LDAP in terms of [X.500] as an
X.500 access mechanism. An LDAP server MUST act in accordance with
- X.500(1993) series of International Telephone Union (ITU)
- Recommendations when providing the service. However, it is not
- required that an LDAP server make use of any X.500 protocols in
- providing this service, e.g. LDAP can be mapped onto any other
- directory system so long as the X.500 data and service models
+ X.500(1993) series of International Telecommunication Union - Telecom
+ Standardization (ITU-T) Recommendations when providing the service.
+ However, it is not required that an LDAP server make use of any X.500
+ protocols in providing this service, e.g. LDAP can be mapped onto any
+ other directory system so long as the X.500 data and service models
[X.501][X.511] as used in LDAP is not violated in the LDAP interface.
-
Zeilenga LDAP: TS Road Map [Page 2]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
This technical specification explicitly incorporates portions of
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251 and portions of RFC 2252.
[AuthMeth] replaces RFC 2829, RFC 2830, and portions of RFC 2251.
- [Syntax] replaces the majority of RFC 2252 and portions of RFC 2256.
+ [Syntaxes] replaces the majority of RFC 2252 and portions of RFC 2256.
[Schema] replaces the majority of RFC 2256. [LDAPDN] replaces RFC
2253. [Filters] replaces RFC 2254. [LDAPURL] replaces RFC 2255.
+ [LDAPprep] is new to this revision of the LDAP technical
+ specification.
+
Each document of this specification contains appendices summarizing
changes to all sections of the specifications they replace. Appendix
A.1 of this document details changes made to RFC 3377. Appendix A.2
E-mail: <kurt@openldap.org>
-7. References
-
-
Zeilenga LDAP: TS Road Map [Page 3]
\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
+
+7. References
7.1. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC3383] K. Zeilenga, "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.
- [Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress.
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
- [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-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.
- [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress.
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
- [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
- of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
- work in progress.
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
- [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-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] K. Dally (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
+ [LDAPprep] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strpro-xx.txt, a work
+ in progress.
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+ [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] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
-7.2. Informative References
- None.
+Zeilenga LDAP: TS Road Map [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
+ [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).
-Zeilenga LDAP: TS Road Map [Page 4]
-\f
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+
+7.2. Informative References
+
+ None.
Appendix A. Changes to Previous Documents
- This appendix outlines changes this document makes relative
- to the documents it replaces (in whole or in part).
+ This appendix outlines changes this document makes relative to the
+ documents it replaces (in whole or in part).
Appendix A.1. Changes to RFC 3377
- This document is nearly a complete rewrite of RFC 3377 as
- much of the material of RFC 3377 is no longer applicable.
- These changes include defining the terms "LDAP" and
- "LDAPv3" to refer to this revision of the technical
- specification.
+ This document is nearly a complete rewrite of RFC 3377 as much of the
+ material of RFC 3377 is no longer applicable. The changes include
+ redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
+ the technical specification.
Appendix A.2. Changes to Section 3.3 of RFC 2251
- The section was modified slightly (the word "document" was
- replaced with "technical specification") to clarify that it
- applies to the entire LDAP technical specification.
+ The section was modified slightly (the word "document" was replaced
+ with "technical specification") to clarify that it applies to the
+ entire LDAP technical specification.
+
-Copyright 2003, The Internet Society. All Rights Reserved.
+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
+
+
+
+Zeilenga LDAP: TS Road Map [Page 5]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
+
+
+ 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.
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
+ 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
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,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Zeilenga LDAP: TS Road Map [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 6]
\f
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 26 May 2003
+Expires in six months 27 October 2003
LDAP: Internationalized String Preparation
- <draft-ietf-ldapbis-strprep-00.txt>
+ <draft-ietf-ldapbis-strprep-02.txt>
Status of this Memo
Abstract
The previous Lightweight Directory Access Protocol (LDAP) technical
- specifications did not precisely define how string matching is to be
- performed. This lead to a number of usability and interoperability
- problems. This document defines string preparation algorithms for
- matching rules defined for use in LDAP.
+ specifications did not precisely define how character string matching
+ is to be performed. This lead to a number of usability and
+ interoperability problems. This document defines string preparation
+ algorithms for character-based matching rules defined for use in LDAP.
Zeilenga LDAPprep [Page 1]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
Conventions
Zeilenga LDAPprep [Page 2]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
The caseIgnoreMatch matching rule [X.520], for example, is simply
(Zs) property as a space, and another implementation may view any
character with the whitespace (WS) category as a space.
- The lack of precise specification for string matching has led to
- significant interoperability problems. When used in certificate chain
- validation, security vulnerabilities can arise. To address these
- problems, this document defines precise algorithms for preparing
- strings for matching.
+ The lack of precise specification for character string matching has
+ led to significant interoperability problems. When used in
+ certificate chain validation, security vulnerabilities can arise. To
+ address these problems, this document defines precise algorithms for
+ preparing character strings for matching.
1.3. Relationship to "stringprep"
- The string preparation algorithms described in this document are based
- upon the "stringprep" approach [RFC3454]. In "stringprep", presented
- and stored values are first prepared for comparison and so that a
- character-by-character comparison yields the "correct" result.
+ The character string preparation algorithms described in this document
+ are based upon the "stringprep" approach [StringPrep]. In
+ "stringprep", presented and stored values are first prepared for
+ comparison and so that a character-by-character comparison yields the
+ "correct" result.
- The approach used here is a refinement of the "stringprep" [RFC3454]
- approach. Each algorithm involves two additional preparation steps.
+ The approach used here is a refinement of the "stringprep"
+ [StringPrep] approach. Each algorithm involves two additional
+ preparation steps.
a) prior to applying the Unicode string preparation steps outlined in
"stringprep", the string is transcoded to Unicode;
"stringprep", characters insignificant to the matching rules are
removed.
- Hence, preparation of strings for X.500 matching involves the
- following steps:
+ Hence, preparation of character strings for X.500 matching involves
+ the following steps:
1) Transcode
2) Map
3) Normalize
4) Prohibit
5) Check Bidi (Bidirectional)
- 6) Insignificant Character Removal
-
Zeilenga LDAPprep [Page 3]
\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+ 6) Insignificant Character Removal
+
These steps are described in Section 2.
[Roadmap] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety.
- This document details new LDAP internationalized string preparation
- algorithms used by [Syntaxes] and possible other technical
+ This document details new LDAP internationalized character string
+ preparation algorithms used by [Syntaxes] and possible other technical
specifications defining LDAP syntaxes and/or matching rules.
LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
As such, there is a strong desire for alignment between LDAP and X.500
- syntax and semantics. The string preparation algorithms described in
- this document are based upon "Internationalized String Matching Rules
- for X.500" [XMATCH] proposal to ITU/ISO Joint Study Group 2.
+ syntax and semantics. The character string preparation algorithms
+ described in this document are based upon "Internationalized String
+ Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
+ Group 2.
2. String Preparation
The following six-step process SHALL be applied to each presented and
- attribute value in preparation for string match rule evaluation.
+ attribute value in preparation for character string matching rule
+ evaluation.
1) Transcode
2) Map
5) Check bidi
6) Insignificant Character Removal
- Failure in any step is be cause the assertion to be Undefined.
+ Failure in any step causes the assertion to evaluate to Undefined.
+
+ This process is intended to act upon non-empty character strings. If
+ the string to prepare is empty, this process is not applied and the
+ assertion is evaluated to Undefined.
The character repertoire of this process is Unicode 3.2 [Unicode].
+
+
+
+Zeilenga LDAPprep [Page 4]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
2.1. Transcode
Each non-Unicode string value is transcoded to Unicode.
PrintableString [X.680] value are transcoded directly to Unicode.
-
-
-Zeilenga LDAPprep [Page 4]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
UniversalString, UTF8String, and bmpString [X.680] values need not be
transcoded as they are Unicode-based strings (in the case of
bmpString, a subset of Unicode).
- If the implementation is unable or unwilling to perform the
- transcoding as described above, or the transcoding fails, this step
- fails and the assertion is evaluated to Undefined.
-
- The transcoded string is the output string.
+ The output is the transcoded string.
2.2. Map
Zp) are mapped to SPACE (U+0020).
For case ignore, numeric, and stored prefix string matching rules,
- characters are case folded per B.2 of [RFC3454].
+ characters are case folded per B.2 of [StringPrep].
+
+ The output is the mapped string.
2.3. Normalize
The input string is be normalized to Unicode Form KC (compatibility
- composed) as described in [UAX15].
+ composed) as described in [UAX15]. The output is the normalized
+ string.
-2.4. Prohibit
- All Unassigned, Private Use, and non-character code points are
- prohibited. Surrogate codes (U+D800-DFFFF) are prohibited.
- The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
- The first code point of a string is prohibited from being a combining
+Zeilenga LDAPprep [Page 5]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+2.4. Prohibit
-Zeilenga LDAPprep [Page 5]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+ All Unassigned code points are prohibited. Unassigned code points are
+ listed in Table A.1 of [StringPrep].
+ Private Use (U+E000-F8FF, F0000-FFFFD, 100000-10FFFD) code points are
+ prohibited.
- character.
+ All non-character code points (U+FDD0-FDEF, FFFE-FFFF, 1FFFE-1FFFF,
+ 2FFFE-2FFFF, 3FFFE-3FFFF, 4FFFE-4FFFF, 5FFFE-5FFFF, 6FFFE-6FFFF,
+ 7FFFE-7FFFF, 8FFFE-8FFFF, 9FFFE-9FFFF, AFFFE-AFFFF, BFFFE-BFFFF,
+ CFFFE-CFFFF, DFFFE-DFFFF, EFFFE-EFFFF, FFFFE-FFFFF, 10FFFE-10FFFF) are
+ prohibited.
- Empty strings are prohibited.
+ Surrogate codes (U+D800-DFFFF) are prohibited.
- The step fails and the assertion is evaluated to Undefined if the
- input string contains any prohibited code point. The output string is
- the input string.
+ The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+ The first code point of a string is prohibited from being a combining
+ character.
+
+ The step fails if the input string contains any prohibited code point.
+ The output is the input string.
2.5. Check bidi
- There are no bidirectional restrictions. The output string is the
- input string.
+ There are no bidirectional restrictions. The output is the input
+ string.
2.5. Insignificant Character Removal
removed. The characters to be removed differ from matching rule to
matching rule.
- Section 2.6.1 applies to case ignore and exact string matching.
- Section 2.6.2 applies to numericString matching.
- Section 2.6.3 applies to telephoneNumber matching
+ Section 2.5.1 applies to case ignore and exact string matching.
+ Section 2.5.2 applies to numericString matching.
+ Section 2.5.3 applies to telephoneNumber matching
-2.6.1. Insignificant Space Removal
+2.5.1. Insignificant Space Removal
For the purposes of this section, a space is defined to be the SPACE
(U+0020) code point followed by no combining marks.
NOTE - The previous steps ensure that the string cannot contain any
+
+
+
+Zeilenga LDAPprep [Page 6]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
code points in the separator class, other than SPACE (U+0020).
- The following spaces are regarded as not significant and are to be
- removed:
+ If the input string consists entirely of spaces or is empty, the
+ output is a string consisting of exactly one space (e.g. " ").
+
+ Otherwise, the following spaces are removed:
- leading spaces (i.e. those preceding the first character that is
not a space);
- trailing spaces (i.e. those following the last character that is
- multiple consecutive spaces (these are taken as equivalent to a
single space character).
- A string consisting entirely of spaces is equivalent to a string
- containing exactly one space.
-
For example, removal of spaces from the Form KC string:
"<SPACE><SPACE>foo<SPACE><SPACE>bar<SPACE><SPACE>"
-
-
-
-Zeilenga LDAPprep [Page 6]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
would result in the output string:
"foo<SPACE>bar"
and the Form KC string:
"<SPACE>".
-2.6.2. numericString Insignificant Character Removal
+2.5.2. numericString Insignificant Character Removal
For the purposes of this section, a space is defined to be the SPACE
(U+0020) code point followed by no combining marks.
- All spaces are regarded as not significant and are to be removed.
+ All spaces are regarded as not significant. If the input string
+ consists entirely of spaces or is empty, the output is a string
+ consisting of exactly one space (e.g. " "). Otherwise, all spaces are
+ to be removed.
For example, removal of spaces from the Form KC string:
- "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" would result in
- the output string:
+ "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+ would result in the output string:
"123456"
and the Form KC string:
"<SPACE><SPACE><SPACE>"
- would result in an empty output string.
+ would result in the output string:
+ "<SPACE>".
-2.6.3. telephoneNumber Insignificant Character Removal
+2.5.3. telephoneNumber Insignificant Character Removal
For the purposes of this section, a hyphen is defined to be
HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+
+
+
+Zeilenga LDAPprep [Page 7]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
(U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
combining marks and a space is defined to be the SPACE (U+0020) code
point followed by no combining marks.
- All hyphens and spaces are regarded as not significant and are to be
+ All hyphens and spaces are considered insignificant. If the string
+ contains only spaces and hyphens or is empty, then the output is a
+ string consisting of one space. Otherwise, all hyphens and spaces are
removed.
+ For example, removal of hyphens and spaces from the Form KC string:
+ "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<HYPHEN><HYPHEN><HYPHEN>"
+ would result in the output string:
+ "<SPACE>".
+
3. Security Considerations
- "Preparation for International Strings ('stringprep')" [RFC3454]
+ "Preparation for International Strings ('stringprep')" [StringPrep]
security considerations generally apply to the algorithms described
here.
Appendix A and B of this document were authored by Howard Chu
<hyc@symas.com> of Symas Corporation (based upon information provided
-
-
-
-Zeilenga LDAPprep [Page 7]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
in RFC 1345).
The approach used in this document is based upon design principles and
algorithms described in "Preparation of Internationalized Strings
- ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
+ ('stringprep')" [StringPrep] by Paul Hoffman and Marc Blanchet. Some
additional guidance was drawn from Unicode Technical Standards,
Technical Reports, and Notes.
+ This document is a product of the IETF LDAP Revision (LDAPBIS) Working
+ Group.
+
6. Author's Address
Kurt Zeilenga
+
+
+
+Zeilenga LDAPprep [Page 8]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
E-mail: <kurt@openldap.org>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", RFC 3454,
- December 2002.
-
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
+ [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')",
+ draft-hoffman-rfc3454bis-xx.txt, a work in progress.
+
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
-
-Zeilenga LDAPprep [Page 8]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
[UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
Unicode Normalization Forms, Version 3.2.0".
<http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
Character Sets for the International Teletex Service",
T.61, 1988.
+
+
+
+Zeilenga LDAPprep [Page 9]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
7.2. Informative References
[X.500] International Telecommunication Union -
2000.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
- for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt a
+ for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
work in progress.
[RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
Appendix A. Teletex (T.61) to Unicode
-
-
-
-Zeilenga LDAPprep [Page 9]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
This appendix defines an algorithm for transcoding [T.61] characters
to [Unicode] characters for use in string preparation for LDAP
- matching rules. This appendix is a normative.
+ matching rules. This appendix is normative.
The transcoding algorithm is derived from the T.61-8bit definition
provided in [RFC1345]. With a few exceptions, the T.61 character
The codes from x80 to x9f are also equivalent to the corresponding
Unicode code points. This is specified for completeness only, as
+
+
+
+Zeilenga LDAPprep [Page 10]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
these codes are control characters, and will be mapped to nothing in
the LDAP String Preparation Mapping step.
Undefined matching result. For diagnostic purposes, this algorithm
does not fail for undefined input codes. Instead, undefined codes in
the input are mapped to the Unicode REPLACEMENT CHARACTER (U+FFFD).
- As the LDAP String Preparation Probhibit step disallows the
- REPLACEMENT CHARACTER from appearing in its output, this transcoding
- yields the desired effect.
+ As the LDAP String Preparation Prohibit step disallows the REPLACEMENT
+ CHARACTER from appearing in its output, this transcoding yields the
+ desired effect.
Note: RFC 1345 listed the non-spacing accent codepoints as residing in
the range starting at (U+E000). In the current Unicode
e8| 0141 | 00d8 | 0152 | 00ba | 00de | 0166 | 014a | 0149 |
f0| 0138 | 00e6 | 0111 | 00f0 | 0127 | 0131 | 0133 | 0140 |
f8| 0142 | 00f8 | 0153 | 00df | 00fe | 0167 | 014b | ?? |
-
-
-
-Zeilenga LDAPprep [Page 10]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
--+------+------+------+------+------+------+------+------+
Table A.1: Mapping of 8-bit T.61 codes to Unicode
Appendix B. Additional Teletex (T.61) to Unicode Tables
+
+
+Zeilenga LDAPprep [Page 11]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
All of the accented characters in T.61 have a corresponding code point
in Unicode. For the sake of completeness, the combined character
codes are presented in the following tables. This is informational
only; for matching purposes it is sufficient to map the non-spacing
accent and exchange the order of the character pair as specified in
- Appendix A.
+ Appendix A. This appendix is informative.
B.1. Combinations with SPACE
40| ?? | 00c0 | ?? | ?? | ?? | 00c8 | ?? | ?? |
48| ?? | 00cc | ?? | ?? | ?? | ?? | 01f8 | 00d2 |
50| ?? | ?? | ?? | ?? | ?? | 00d9 | ?? | 1e80 |
-
-
-
-Zeilenga LDAPprep [Page 11]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
58| ?? | 1ef2 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e0 | ?? | ?? | ?? | 00e8 | ?? | ?? |
68| ?? | 00ec | ?? | ?? | ?? | ?? | 01f9 | 00f2 |
C, L, N, R, S, and Z. Unicode also defines G, K, M, P, and W. All of
these combinations are present in Table B.3.
+
+
+
+Zeilenga LDAPprep [Page 12]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c1 | ?? | 0106 | ?? | 00c9 | ?? | 01f4 |
Table B.4: Mapping of T.61 Circumflex Accent Combinations
-
-
-Zeilenga LDAPprep [Page 12]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
B.5. Combinations for xc4: (Tilde)
T.61 has predefined characters for combinations with A, I, O, U, and
58| ?? | 1ef8 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e3 | ?? | ?? | ?? | 1ebd | ?? | ?? |
68| ?? | 0129 | ?? | ?? | ?? | ?? | 00f1 | 00f5 |
+
+
+
+Zeilenga LDAPprep [Page 13]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
70| ?? | ?? | ?? | ?? | ?? | 0169 | 1e7d | ?? |
78| ?? | 1ef9 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
Unicode also defines E, I, and O. All of these combinations are
present in Table B.7.
-
-
-
-Zeilenga LDAPprep [Page 13]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0102 | ?? | ?? | ?? | 0114 | ?? | 011e |
Table B.7: Mapping of T.61 Breve Accent Combinations
+
+
+
+Zeilenga LDAPprep [Page 14]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
B.8. Combinations for xc7: (Dot Above)
T.61 has predefined characters for C, E, G, I, and Z. Unicode also
58| 1e8c | 0178 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e4 | ?? | ?? | ?? | 00eb | ?? | ?? |
68| 1e27 | 00ef | ?? | ?? | ?? | ?? | ?? | 00f6 |
-
-
-
-Zeilenga LDAPprep [Page 14]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
70| ?? | ?? | ?? | ?? | 1e97 | 00fc | ?? | 1e85 |
78| 1e8d | 00ff | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c5 | ?? | ?? | ?? | ?? | ?? | ?? |
+
+
+
+Zeilenga LDAPprep [Page 15]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
50| ?? | ?? | ?? | ?? | ?? | 016e | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
B.12. Combinations for xcd: (Double Acute Accent)
T.61 has predefined characters for O, and U. These combinations are
-
-
-
-Zeilenga LDAPprep [Page 15]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
present in Table B.12.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
B.13. Combinations for xce: (Ogonek)
+
+
+
+Zeilenga LDAPprep [Page 16]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
T.61 has predefined characters for A, E, I, and U. Unicode also
defines the combination for O. All of these combinations are present
in Table B.13.
68| 021f | 01d0 | 01f0 | 01e9 | 013e | ?? | 0148 | 01d2 |
70| ?? | ?? | 0159 | 0161 | 0165 | 01d4 | ?? | ?? |
78| ?? | ?? | 017e | ?? | ?? | ?? | ?? | ?? |
-
-
-
-Zeilenga LDAPprep [Page 16]
-\f
-Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
-
-
--+------+------+------+------+------+------+------+------+
Table B.14: Mapping of T.61 Caron Accent Combinations
-
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
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
+
+
+
+Zeilenga LDAPprep [Page 17]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
+
+
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
-Zeilenga LDAPprep [Page 17]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAPprep [Page 18]
\f
INTERNET-DRAFT S. Legg, Editor
-draft-ietf-ldapbis-syntaxes-05.txt Adacel Technologies
-Intended Category: Standard Track K. Dally
+draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies
+Intended Category: Standards Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
- 27 February 2003
+ 27 October 2003
LDAP: Syntaxes and Matching Rules
send editorial comments directly to the editor
<steven.legg@adacel.com.au>.
- This Internet-Draft expires on 27 August 2003.
+ This Internet-Draft expires on 27 April 2004.
Abstract
-Legg & Dally Expires 27 August 2003 [Page 1]
+Legg & Dally Expires 27 April 2004 [Page 1]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
protocol, has a defined syntax which constrains the structure and
-Legg & Dally Expires 27 August 2003 [Page 2]
+Legg & Dally Expires 27 April 2004 [Page 2]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
-1. Table of Contents
-
- 1. Table of Contents ............................................. 3
- 2. Introduction .................................................. 4
- 3. Conventions ................................................... 5
- 4. Syntaxes ...................................................... 5
- 4.1 General Considerations .................................... 5
- 4.2 Common Definitions ........................................ 6
- 4.3 Syntax Definitions ........................................ 7
- 4.3.1 Attribute Type Description ........................... 7
- 4.3.2 Bit String ........................................... 7
- 4.3.3 Boolean .............................................. 8
- 4.3.4 Country String ....................................... 8
- 4.3.5 Delivery Method ...................................... 9
- 4.3.6 Directory String ..................................... 9
- 4.3.7 DIT Content Rule Description ......................... 10
- 4.3.8 DIT Structure Rule Description ....................... 11
- 4.3.9 DN ................................................... 11
- 4.3.10 Enhanced Guide ...................................... 12
- 4.3.11 Facsimile Telephone Number .......................... 13
- 4.3.12 Fax ................................................. 13
- 4.3.13 Generalized Time .................................... 14
- 4.3.14 Guide ............................................... 15
- 4.3.15 IA5 String .......................................... 15
- 4.3.16 Integer ............................................. 16
- 4.3.17 JPEG ................................................ 16
- 4.3.18 LDAP Syntax Description ............................. 16
- 4.3.19 Matching Rule Description ........................... 17
- 4.3.20 Matching Rule Use Description ....................... 17
- 4.3.21 Name and Optional UID ............................... 18
- 4.3.22 Name Form Description ............................... 18
- 4.3.23 Numeric String ...................................... 19
- 4.3.24 Object Class Description ............................ 19
- 4.3.25 Octet String ........................................ 20
- 4.3.26 OID ................................................. 20
- 4.3.27 Other Mailbox ....................................... 21
- 4.3.28 Postal Address ...................................... 21
- 4.3.29 Printable String .................................... 22
- 4.3.30 Substring Assertion ................................. 23
- 4.3.31 Telephone Number .................................... 23
- 4.3.32 Teletex Terminal Identifier ......................... 24
- 4.3.33 Telex Number ........................................ 25
- 4.3.34 UTC Time ............................................ 25
- 5. Matching Rules ................................................ 26
- 5.1 General Considerations .................................... 26
- 5.2 Matching Rule Definitions ................................. 28
- 5.2.1 bitStringMatch ....................................... 28
- 5.2.2 caseExactIA5Match .................................... 28
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 3]
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
+ 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6
+ 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
+ 3.3.1. Attribute Type Description . . . . . . . . . . . 7
+ 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7
+ 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
+ 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
+ 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
+ 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
+ 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
+ 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
+ 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
+ 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
+ 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
+ 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
+ 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15
+ 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15
+ 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
+ 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16
+ 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
+ 3.3.20. Matching Rule Use Description. . . . . . . . . . 17
+ 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
+ 3.3.22. Name Form Description. . . . . . . . . . . . . . 18
+ 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
+ 3.3.24. Object Class Description . . . . . . . . . . . . 19
+ 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19
+ 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
+ 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20
+ 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
+ 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
+ 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
+ 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
+ 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
+ 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24
+ 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
+ 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27
+ 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27
+ 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28
+ 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 3]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
- 5.2.3 caseIgnoreIA5Match ................................... 29
- 5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29
- 5.2.5 caseIgnoreListMatch .................................. 29
- 5.2.6 caseIgnoreListSubstringsMatch ........................ 30
- 5.2.7 caseIgnoreMatch ...................................... 31
- 5.2.8 caseIgnoreOrderingMatch .............................. 31
- 5.2.9 caseIgnoreSubstringsMatch ............................ 32
- 5.2.10 distinguishedNameMatch .............................. 32
- 5.2.11 generalizedTimeMatch ................................ 33
- 5.2.12 generalizedTimeOrderingMatch ........................ 33
- 5.2.13 integerFirstComponentMatch .......................... 34
- 5.2.14 integerMatch ........................................ 34
- 5.2.15 numericStringMatch .................................. 34
- 5.2.16 numericStringSubstringsMatch ........................ 35
- 5.2.17 objectIdentifierFirstComponentMatch ................. 35
- 5.2.18 objectIdentifierMatch ............................... 36
- 5.2.19 octetStringMatch .................................... 36
- 5.2.20 telephoneNumberMatch ................................ 37
- 5.2.21 telephoneNumberSubstringsMatch ...................... 37
- 5.2.22 uniqueMemberMatch ................................... 38
- 6. Security Considerations ....................................... 38
- 7. Acknowledgements .............................................. 39
- 8. IANA Considerations ........................................... 39
- 9. Normative References .......................................... 40
- 10. Informative References ....................................... 42
- 11. Authors' Addresses ........................................... 42
- 12. Copyright Notice ............................................. 43
- Appendix A. Summary of Syntax Object Identifiers ................. 43
- Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 44
-
-
-2. Introduction
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
+ 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29
+ 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29
+ 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30
+ 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 31
+ 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31
+ 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 32
+ 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32
+ 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33
+ 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33
+ 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 34
+ 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34
+ 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 35
+ 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35
+ 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 36
+ 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36
+ 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37
+ 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37
+ 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 38
+ 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 39
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 42
+ 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43
+ 10. Intellectual Property Notice . . . . . . . . . . . . . . . . . 44
+ Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 44
+ Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 45
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
+
+1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP], and whose values may be transfered in the
- LDAP protocol [PROT], has a defined syntax (i.e. data type) which
+ LDAP protocol [PROT], has a defined syntax (i.e., data type) which
constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined
Readers are advised to familiarize themselves with the Directory
Information Models [MODELS] before reading the rest of this document.
- Section 4 provides definitions for the base set of LDAP syntaxes.
- Section 5 provides definitions for the base set of matching rules for
+ Section 3 provides definitions for the base set of LDAP syntaxes.
+ Section 4 provides definitions for the base set of matching rules for
-Legg & Dally Expires 27 August 2003 [Page 4]
+Legg & Dally Expires 27 April 2004 [Page 4]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
LDAP.
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
The remainder of RFC 2252 is obsoleted by this document. Sections 6
- and 8 of RFC 2256 are obsoleted by this document. The changes from
- RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this
- document.
+ and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
+ remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].
+ A number of schema elements which were included in the previous
+ revision of the LDAP technical specification are not included in this
+ revision of LDAP. Public Key Infrastructure schema elements are now
+ specified in [LDAP-PKI]. Unless reintroduced in future technical
+ specifications, the remainder are to be considered Historic.
-3. Conventions
+ The changes from RFC 2252 and RFC 2256 are described in Appendix B of
+ this document.
+
+2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [KEYWORD].
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [KEYWORD].
Syntax definitions are written according to the <SyntaxDescription>
ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
specified in [MODELS], except that the syntax and matching rule
definitions provided in this document are line-wrapped for
readability. When such definitions are transfered as attribute
- values in the LDAP protocol (e.g. as values of the ldapSyntaxes and
+ values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
matchingRules attributes [MODELS] respectively) then those values
would not contain line breaks.
-
-4. Syntaxes
+3. Syntaxes
Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute
Syntaxes that are required for directory operation, or that are in
common use, are specified in this section. Servers SHOULD recognize
- all the syntaxes listed in this document, but are NOT REQUIRED to
+ all the syntaxes listed in this document, but are not required to
otherwise support them, and MAY recognise or support other syntaxes.
However, the definition of additional arbitrary syntaxes is
- discouraged since it will hinder interoperability. Client and server
- implementations typically do not have the ability to dynamically
- recognize new syntaxes.
-
-4.1 General Considerations
+Legg & Dally Expires 27 April 2004 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-Legg & Dally Expires 27 August 2003 [Page 5]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+ discouraged since it will hinder interoperability. Client and server
+ implementations typically do not have the ability to dynamically
+ recognize new syntaxes.
+3.1. General Considerations
The description of each syntax specifies how attribute or assertion
values conforming to the syntax are to be represented when transfered
in the LDAP protocol [PROT]. This representation is referred to as
the LDAP-specific encoding to distinguish it from other methods of
- encoding attribute values (e.g. the BER encoding [BER] used by X.500
- [X.500] directories).
+ encoding attribute values (e.g., the Basic Encoding Rules (BER)
+ encoding [BER] used by X.500 [X.500] directories).
The LDAP-specific encoding of a given attribute syntax always
produces octet-aligned values. To the greatest extent possible,
that can be displayed with little or no translation by clients
implementing LDAP. However, clients MUST NOT assume that the
LDAP-specific encoding of a value of an unrecognized syntax is a
- human-readable character string. There are a few cases (e.g. the
+ human-readable character string. There are a few cases (e.g., the
JPEG syntax) when it is not reasonable to produce a human-readable
representation.
the attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet since
- UTF-8 [UTF-8] is a variable-length encoding. Therefore a 64
- character string may be more than 64 octets in length.
-
+ UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
+ string may be more than 64 octets in length.
-4.2 Common Definitions
+3.2. Common Definitions
The following ABNF rules are used in a number of the syntax
- definitions in Section 4.3.
-
- PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
- PLUS / COMMA / HYPHEN / DOT / EQUALS /
- SLASH / COLON / QUESTION / SPACE
- PrintableString = 1*PrintableCharacter
+ definitions in Section 3.3.
-Legg & Dally Expires 27 August 2003 [Page 6]
+Legg & Dally Expires 27 April 2004 [Page 6]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+ PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
+ PLUS / COMMA / HYPHEN / DOT / EQUALS /
+ SLASH / COLON / QUESTION / SPACE
+ PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; N.B. allows upper and lower case
<COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
[MODELS].
+3.3. Syntax Definitions
-4.3 Syntax Definitions
-
-4.3.1 Attribute Type Description
+3.3.1. Attribute Type Description
A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this
This syntax corresponds to the AttributeTypeDescription ASN.1 type
from [X.501].
-
-4.3.2 Bit String
+3.3.2. Bit String
A value of the Bit String syntax is a sequence of binary digits. The
LDAP-specific encoding of a value of this syntax is defined by the
following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
- binary-digit = "0" / "1"
-
-Legg & Dally Expires 27 August 2003 [Page 7]
+Legg & Dally Expires 27 April 2004 [Page 7]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+ binary-digit = "0" / "1"
The <SQUOTE> rule is defined in [MODELS].
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
-
-4.3.3 Boolean
+3.3.3. Boolean
A value of the Boolean syntax is one of the Boolean values, true or
false. The LDAP-specific encoding of a value of this syntax is
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
-
-4.3.4 Country String
+3.3.4. Country String
A value of the Country String syntax is one of the two-character
codes from ISO 3166 [ISO3166] for representing a country. The
CountryString = 2(PrintableCharacter)
- The <PrintableCharacter> rule is defined in Section 4.2.
+ The <PrintableCharacter> rule is defined in Section 3.2.
Examples:
US
-Legg & Dally Expires 27 August 2003 [Page 8]
+Legg & Dally Expires 27 April 2004 [Page 8]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- PrintableString (SIZE (2)) -- IS 3166 codes only
+ PrintableString (SIZE (2)) -- ISO 3166 codes only
-4.3.5 Delivery Method
+3.3.5. Delivery Method
A value of the Delivery Method syntax is a sequence of items that
indicate, in preference order, the service(s) by which an entity is
videotex-delivery (8),
telephone-delivery (9) }
-
-4.3.6 Directory String
+3.3.6. Directory String
A value of the Directory String syntax is a string of one or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero length character string is not permitted. The LDAP-specific
- encoding of a value of this syntax is the UTF-8 encoding [UTF-8] of
+ encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8
+ The <UTF8> rule is defined in [MODELS].
+
-Legg & Dally Expires 27 August 2003 [Page 9]
+Legg & Dally Expires 27 April 2004 [Page 9]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- The <UTF8> rule is defined in [MODELS].
Example:
This is a value of Directory String containing #!%#@.
and code points not presently assigned to any character.
Attribute type definitions using the Directory String syntax should
- not restrict the format of Directory String values, e.g. by requiring
- that the character string conforms to specific patterns described by
- ABNF. A new syntax should be defined in such cases.
+ not restrict the format of Directory String values, e.g., by
+ requiring that the character string conforms to specific patterns
+ described by ABNF. A new syntax should be defined in such cases.
The LDAP definition for the Directory String syntax is:
LDAP-specific encoding the characters must be converted from the
character encoding of the chosen alternative into the UTF-8 encoding.
-
-4.3.7 DIT Content Rule Description
+3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition
- of a DIT content rule. The LDAP-specific encoding of a value of this
- syntax is defined by the <DITContentRuleDescription> rule in
- [MODELS].
+ of a DIT (Directory Information Tree) content rule. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ <DITContentRuleDescription> rule in [MODELS].
Example:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
+ Note: a line break has been added for readability - it is not part of
+ the value.
+
-Legg & Dally Expires 27 August 2003 [Page 10]
+Legg & Dally Expires 27 April 2004 [Page 10]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- Note: a line break has been added for readability - it is not part of
- the value.
The LDAP definition for the DIT Content Rule Description syntax is:
This syntax corresponds to the DITContentRuleDescription ASN.1 type
from [X.501].
-
-4.3.8 DIT Structure Rule Description
+3.3.8. DIT Structure Rule Description
A value of the DIT Structure Rule Description syntax is the
definition of a DIT structure rule. The LDAP-specific encoding of a
This syntax corresponds to the DITStructureRuleDescription ASN.1 type
from [X.501].
+3.3.9. DN
-4.3.9 DN
-
- A value of the DN syntax is the (purported) distinguished name of an
- entry [MODELS]. The LDAP-specific encoding of a value of this syntax
- is defined by the <distinguishedName> rule in [LDAPDN].
+ A value of the DN syntax is the (purported) distinguished name (DN)
+ of an entry [MODELS]. The LDAP-specific encoding of a value of this
+ syntax is defined by the <distinguishedName> rule in [LDAPDN].
Examples (from [LDAPDN]):
UID=jsmith,DC=example,DC=net
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+ The DN syntax corresponds to the DistinguishedName ASN.1 type from
+ [X.501]. Note that a BER encoded distinguished name (as used by
+ X.500) re-encoded into the LDAP-specific encoding is not necessarily
+ reversible to the original BER encoding since the chosen string type
+
-Legg & Dally Expires 27 August 2003 [Page 11]
+Legg & Dally Expires 27 April 2004 [Page 11]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- The DN syntax corresponds to the DistinguishedName ASN.1 type from
- [X.501]. Note that a BER encoded distinguished name (as used by
- X.500) re-encoded into the LDAP-specific encoding is not necessarily
- reversible to the original BER encoding since the chosen string type
in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name
- (see Section 4.3.6).
-
+ (see Section 3.3.6).
-4.3.10 Enhanced Guide
+3.3.10. Enhanced Guide
A value of the Enhanced Guide syntax suggests criteria, which consist
of combinations of attribute types and filter operators, to be used
Example:
+ person#(sn$EQ)#oneLevel
+
+ The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
+ from [X.520]. The EnhancedGuide type references the Criteria ASN.1
+ type, also from [X.520]. The <true> rule above represents an empty
-Legg & Dally Expires 27 August 2003 [Page 12]
+Legg & Dally Expires 27 April 2004 [Page 12]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- person#(sn$EQ)#oneLevel
- The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
- from [X.520]. The EnhancedGuide type references the Criteria ASN.1
- type, also from [X.520]. The <true> rule above represents an empty
"and" expression in a value of the Criteria type. The <false> rule
above represents an empty "or" expression in a value of the Criteria
type.
-
-4.3.11 Facsimile Telephone Number
+3.3.11. Facsimile Telephone Number
A value of the Facsimile Telephone Number syntax is a subscriber
number of a facsimile device on the public switched telephone
The <telephone-number> is a string of printable characters that
complies with the internationally agreed format for representing
international telephone numbers [E.123]. The <PrintableString> rule
- is defined in Section 4.2. The <DOLLAR> rule is defined in [MODELS].
+ is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
The LDAP definition for the Facsimile Telephone Number syntax is:
The Facsimile Telephone Number syntax corresponds to the
FacsimileTelephoneNumber ASN.1 type from [X.520].
-
-4.3.12 Fax
+3.3.12. Fax
A value of the Fax syntax is an image which is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
The LDAP definition for the Fax syntax is:
-
-
-Legg & Dally Expires 27 August 2003 [Page 13]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
The ASN.1 type corresponding to the Fax syntax is defined as follows,
assuming EXPLICIT TAGS:
Fax ::= CHOICE {
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
g3-facsimile [3] G3FacsimileBodyPart
}
The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
-
-4.3.13 Generalized Time
+3.3.13. Generalized Time
A value of the Generalized Time syntax is a character string
representing a date and time. The LDAP-specific encoding of a value
/ ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
- second = %x30-35 %x30-39 ; "00" to "59"
+ second = ( %x30-35 %x30-39 ) ; "00" to "59"
+ / ( %x36 %x30 ) ; "60" (a leap second)
GeneralizedTime = century year month day hour
[ minute [ second ] ] [ fraction ]
the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>.
-
-
-Legg & Dally Expires 27 August 2003 [Page 14]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
Examples:
199412161032Z
199412160532-0500
Both example values represent the same coordinated universal time:
- 40:32 am, December 16, 1994.
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
+ 10:32 AM, December 16, 1994.
The LDAP definition for the Generalized Time syntax is:
[ASN.1], with the constraint that local time without a differential
SHALL NOT be used.
-
-4.3.14 Guide
+3.3.14. Guide
A value of the Guide syntax suggests criteria, which consist of
combinations of attribute types and filter operators, to be used in
Guide = [ object-class SHARP ] criteria
The <object-class> and <criteria> rules are defined in Section
- 4.3.10. The <SHARP> rule is defined in [MODELS].
+ 3.3.10. The <SHARP> rule is defined in [MODELS].
The LDAP definition for the Guide syntax is:
The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
-
-4.3.15 IA5 String
+3.3.15. IA5 String
A value of the IA5 String syntax is a string of zero, one or more
characters from International Alphabet 5 (IA5) [T.50], the
international version of the ASCII character set. The LDAP-specific
encoding of a value of this syntax is the unconverted string of
- characters, which conforms to the <IA5String> rule in Section 4.2.
+ characters, which conforms to the <IA5String> rule in Section 3.2.
The LDAP definition for the IA5 String syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+ This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
-Legg & Dally Expires 27 August 2003 [Page 15]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+3.3.16. Integer
- ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
- This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
+Legg & Dally Expires 27 April 2004 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-4.3.16 Integer
A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is
character string "1321"). The encoding is defined by the following
ABNF:
- Integer = [ HYPHEN ] number
+ Integer = ( HYPHEN LDIGIT *DIGIT ) / number
- The <HYPHEN> and <number> rules are defined in [MODELS].
+ The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
+ [MODELS].
The LDAP definition for the Integer syntax is:
This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
-
-4.3.17 JPEG
+3.3.17. JPEG
A value of the JPEG syntax is an image in the JPEG File Interchange
Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
{ -- contents octets are an image in the --
-- JPEG File Interchange Format -- })
-
-4.3.18 LDAP Syntax Description
+3.3.18. LDAP Syntax Description
A value of the LDAP Syntax Description syntax is the description of
an LDAP syntax. The LDAP-specific encoding of a value of this syntax
is defined by the <SyntaxDescription> rule in [MODELS].
-
-
-Legg & Dally Expires 27 August 2003 [Page 16]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
The LDAP definition for the LDAP Syntax Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
The above LDAP definition for the LDAP Syntax Description syntax is
itself a legal value of the LDAP Syntax Description syntax.
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS:
The value of ub-schema (an integer) is implementation defined. A
non-normative definition appears in [X.520].
-
-4.3.19 Matching Rule Description
+3.3.19. Matching Rule Description
A value of the Matching Rule Description syntax is the definition of
a matching rule. The LDAP-specific encoding of a value of this
This syntax corresponds to the MatchingRuleDescription ASN.1 type
from [X.501].
-
-4.3.20 Matching Rule Use Description
+3.3.20. Matching Rule Use Description
A value of the Matching Rule Use Description syntax indicates the
attribute types to which a matching rule may be applied in an
a value of this syntax is defined by the <MatchingRuleUseDescription>
rule in [MODELS].
-
-
-Legg & Dally Expires 27 August 2003 [Page 17]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) )
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
from [X.501].
-
-4.3.21 Name and Optional UID
+3.3.21. Name and Optional UID
A value of the Name and Optional UID syntax is the distinguished name
[MODELS] of an entity optionally accompanied by a unique identifier
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
- The <BitString> rule is defined in Section 4.3.2. The
+ The <BitString> rule is defined in Section 3.3.2. The
<distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
defined in [MODELS].
This syntax corresponds to the NameAndOptionalUID ASN.1 type from
[X.520].
-
-4.3.22 Name Form Description
+3.3.22. Name Form Description
A value of the Name Form Description syntax is the definition of a
name form, which regulates how entries may be named. The
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 18]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
LDAP-specific encoding of a value of this syntax is defined by the
<NameFormDescription> rule in [MODELS].
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
This syntax corresponds to the NameFormDescription ASN.1 type from
[X.501].
-
-4.3.23 Numeric String
+3.3.23. Numeric String
A value of the Numeric String syntax is a sequence of one or more
numerals and spaces. The LDAP-specific encoding of a value of this
This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
-
-4.3.24 Object Class Description
+3.3.24. Object Class Description
A value of the Object Class Description syntax is the definition of
an object class. The LDAP-specific encoding of a value of this
Note: a line break has been added for readability - it is not part of
the syntax.
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 19]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
The LDAP definition for the Object Class Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
This syntax corresponds to the ObjectClassDescription ASN.1 type from
[X.501].
-
-4.3.25 Octet String
+3.3.25. Octet String
A value of the Octet String syntax is a sequence of zero, one or more
arbitrary octets. The LDAP-specific encoding of a value of this
syntax is the unconverted sequence of octets, which conforms to the
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
following ABNF:
OctetString = *OCTET
This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
-
-4.3.26 OID
+3.3.26. OID
A value of the OID syntax is an object identifier; a sequence of two
or more non-negative integers that uniquely identify some object or
This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
[ASN.1].
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 20]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
-4.3.27 Other Mailbox
+3.3.27. Other Mailbox
A value of the Other Mailbox syntax identifies an electronic mailbox,
in a particular named mail system. The LDAP-specific encoding of a
The <mailbox-type> rule represents the type of mail system in which
the mailbox resides, for example "MCIMail", and <mailbox> is the
actual mailbox in the mail system described by <mailbox-type>. The
- <PrintableString> and <IA5String> rules are defined in Section 4.2.
+ <PrintableString> and <IA5String> rules are defined in Section 3.2.
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 20]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
The <DOLLAR> rule is defined in [MODELS].
The LDAP definition for the Other Mailbox syntax is:
mailbox IA5String
}
-
-4.3.28 Postal Address
+3.3.28. Postal Address
A value of the Postal Address syntax is a sequence of strings of one
or more arbitrary UCS characters, which form an address in a physical
/ %x5D-7F
/ UTFMB
- Each character string (i.e. <line>) of a postal address value is
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 21]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
- encoded as a UTF-8 [UTF-8] string except that "\" and "$" characters,
+ Each character string (i.e., <line>) of a postal address value is
+ encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
if they occur in the string, are escaped by a "\" character followed
by the two hexadecimal digit code for the character. The <HEX-DIGIT>
- rule is defined in Section 4.2. The <DOLLAR> and <UTFMB> rules are
+ rule is defined in Section 3.2. The <DOLLAR> and <UTFMB> rules are
defined in [MODELS].
Many servers limit the postal address to no more than six lines of no
The LDAP definition for the Postal Address syntax is:
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 21]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
- i.e.
+ i.e.,
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }
The values of ub-postal-line and ub-postal-string (both integers) are
implementation defined. Non-normative definitions appear in [X.520].
+3.3.29. Printable String
-4.3.29 Printable String
-
- A value of the Printable String syntax is a string of latin
- alphabetic, numeric, and (limited) punctuation characters as
- specified by the <PrintableCharacter> rule in Section 4.2.
+ A value of the Printable String syntax is a string of one or more
+ latin alphabetic, numeric, and selected punctuation characters as
+ specified by the <PrintableCharacter> rule in Section 3.2.
The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the
- <PrintableString> rule in Section 4.2.
+ <PrintableString> rule in Section 3.2.
Example:
This is a PrintableString.
This syntax corresponds to the PrintableString ASN.1 type from
[ASN.1].
-
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 22]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
-4.3.30 Substring Assertion
+3.3.30. Substring Assertion
A value of the Substring Assertion syntax is a sequence of zero, one
or more character substrings used as an argument for substring
- extensible matching of character string attribute values, i.e. as the
- matchValue of a MatchingRuleAssertion [PROT]. Each substring is a
- string of one or more arbitrary characters from the Universal
+ extensible matching of character string attribute values, i.e., as
+ the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
+ a string of one or more arbitrary characters from the Universal
Character Set (UCS) [UCS]. A zero length substring is not permitted.
The LDAP-specific encoding of a value of this syntax is defined by
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
ASTERISK = %x2A ; asterisk ("*")
substring = 1*substring-character
/ UTFMB
Each <substring> of a Substring Assertion value is encoded as a UTF-8
- [UTF-8] string, except that "\" and "*" characters, if they occur in
+ [UTF8] string, except that "\" and "*" characters, if they occur in
the substring, are escaped by a "\" character followed by the two
hexadecimal digit code for the character.
This syntax corresponds to the SubstringAssertion ASN.1 type from
[X.520].
-
-4.3.31 Telephone Number
+3.3.31. Telephone Number
A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 23]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
representing international telephone numbers [E.123].
The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the
- <PrintableString> rule in Section 4.2.
+ <PrintableString> rule in Section 3.2.
Example: +1 512 315 0280
PrintableString (SIZE(1..ub-telephone-number))
The value of ub-telephone-number (an integer) is implementation
- defined. A non-normative definition appears in [X.520].
-4.3.32 Teletex Terminal Identifier
+
+Legg & Dally Expires 27 April 2004 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
+ defined. A non-normative definition appears in [X.520].
+
+3.3.32. Teletex Terminal Identifier
A value of this syntax specifies the identifier and (optionally)
parameters of a teletex terminal.
/ (%x5C "5C") ; escaped "\"
/ %x5D-FF
- The <PrintableString> and <COLON> rules are defined in Section 4.2.
+ The <PrintableString> and <COLON> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS].
The LDAP definition for the Teletex Terminal Identifier syntax is:
( 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Teletex Terminal Identifier' )
-
-
-Legg & Dally Expires 27 August 2003 [Page 24]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
from [X.520].
-
-4.3.33 Telex Number
+3.3.33. Telex Number
A value of the Telex Number syntax specifies the telex number,
country code and answerback code of a telex terminal.
country-code = PrintableString
answerback = PrintableString
- The <PrintableString> rule is defined in Section 4.2. The <DOLLAR>
+ The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 24]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
rule is defined in [MODELS].
The LDAP definition for the Telex Number syntax is:
This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
-
-4.3.34 UTC Time
+3.3.34. UTC Time
A value of the UTC Time syntax is a character string representing a
date and time to a precision of one minute or one second. The year
u-differential = ( MINUS / PLUS ) hour minute
The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
- rules are defined in Section
4.3.13. The <PLUS> rule is defined in
+ rules are defined in Section
3.3.13. The <PLUS> rule is defined in
[MODELS].
The time value represents coordinated universal time if the "Z" form
of <u-time-zone> is used, otherwise the value represents a local
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 25]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
time. In the latter case, if <u-differential> is provided then
coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be
The UTC Time syntax corresponds to the UTCTime ASN.1 type from
[ASN.1].
-
-5. Matching Rules
+4. Matching Rules
Matching rules are used by directory implementations to compare
attribute values against assertion values when performing Search and
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
Compare operations [PROT]. They are also used when comparing a
purported distinguished name [MODELS] with the name of an entry.
When modifying entries, matching rules are used to identify values to
Matching rules that are required for directory operation, or that are
in common use, are specified in this section.
-5.1 General Considerations
+4.1. General Considerations
A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
may be applied. Note that the AssertionValue in a SubstringFilter
[PROT] MUST conform to the assertion syntax of the equality matching
rule for the attribute type rather than the assertion syntax of the
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 26]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
substrings matching rule for the attribute type. The entire
SubstringFilter is converted into an assertion value of the
substrings matching rule prior to applying the rule.
corresponding ASN.1 type of a candidate attribute syntax must
satisfy. These conditions are also satisfied if the corresponding
ASN.1 type is a tagged or constrained derivative of the ASN.1 type
- explicitly mentioned in the rule description (i.e. ASN.1 tags and
+ explicitly mentioned in the rule description (i.e., ASN.1 tags and
constraints are ignored in checking applicability), or an alternative
reference notation for the explicitly mentioned type. Each rule
description lists as examples of applicable attribute syntaxes, the
The description of each matching rule indicates whether the rule is
suitable for use as the equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
attribute type definition [MODELS].
Each matching rule is uniquely identified with an object identifier.
If a change is desirable then a new matching rule with a different
object identifier should be defined instead.
- Servers SHOULD implement all the matching rules in Section 5.2.
+ Servers SHOULD implement all the matching rules in Section 4.2.
Servers MAY implement additional matching rules.
Servers which implement the extensibleMatch filter SHOULD allow the
- matching rules listed in Section 5.2 to be used in the
+ matching rules listed in Section 4.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion
syntax of the matching rule is the same as the value syntax of the
(in an extensibleMatch filter) of selected matching rules to
nominated attribute types.
+4.2. Matching Rule Definitions
+ When evaluating the numericStringMatch, numericStringSubstringsMatch,
+ caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
+ caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
+ caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
+ telephoneNumberMatch and telephoneNumberSubstringsMatch matching
+ rules the assertion value and attribute value are prepared according
+ to the string preparation algorithms [PREP] for LDAP before being
+ compared. The Transcode, Normalize, Prohibit and Check bidi steps
+ are the same for each of the matching rules. However, the Map and
+ Insignificant Character Removal steps depends on the specific rule,
+ as detailed in the description of these matching rules in the
+ sections that follow.
-Legg & Dally Expires 27 August 2003 [Page 27]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+4.2.1. bitStringMatch
+ The bitStringMatch rule compares an assertion value of the Bit String
+ syntax to an attribute value of a syntax (e.g., the Bit String
+ syntax) whose corresponding ASN.1 type is BIT STRING.
-5.2 Matching Rule Definitions
-
- When evaluating the caseExactIA5Match, caseIgnoreIA5Match,
- caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch,
- caseIgnoreListSubstringsMatch, caseIgnoreMatch,
- caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules
- multiple adjoining whitespace characters are treated the same as an
- individual space, and leading and trailing whitespace is ignored.
-5.2.1 bitStringMatch
+Legg & Dally Expires 27 April 2004 [Page 27]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- The bitStringMatch rule compares an assertion value of the Bit String
- syntax to an attribute value of a syntax (e.g. the Bit String syntax)
- whose corresponding ASN.1 type is BIT STRING.
If the corresponding ASN.1 type of the attribute syntax does not have
a named bit list (which is the case for the Bit String syntax) then
The bitStringMatch rule is an equality matching rule.
-
-5.2.2 caseExactIA5Match
+4.2.2. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String.
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of characters and corresponding
- characters are the same. Letter case is significant in the
- comparison.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Removal is applied in the Insignificant Character
+ Removal step.
The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+ The caseExactIA5Match rule is an equality matching rule.
+4.2.3. caseIgnoreIA5Match
-Legg & Dally Expires 27 August 2003 [Page 28]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+ The caseIgnoreIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
- The caseExactIA5Match rule is an equality matching rule.
+Legg & Dally Expires 27 April 2004 [Page 28]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-5.2.3 caseIgnoreIA5Match
- The caseIgnoreIA5Match rule compares an assertion value of the IA5
- String syntax to an attribute value of a syntax (e.g the IA5 String
- syntax) whose corresponding ASN.1 type is IA5String.
+ string have the same number of characters and corresponding
+ characters have the same code point.
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of characters and corresponding
- characters are the same, ignoring the case of letters.
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Removal is applied in the Insignificant Character
+ Removal step.
The LDAP definition for the caseIgnoreIA5Match rule is:
The caseIgnoreIA5Match rule is an equality matching rule.
-
-5.2.4 caseIgnoreIA5SubstringsMatch
+4.2.4. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
- The rule evaluates to TRUE if and only if the substrings of the
- assertion value match disjoint portions of the attribute value in the
- order of the substrings in the assertion value, and an <initial>
- substring, if present, matches the beginning of the attribute value,
- and a <final> substring, if present, matches the end of the attribute
- value. A substring matches a portion of the attribute value if
- corresponding characters are the same, ignoring the case of letters.
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Removal is applied in the Insignificant
+ Character Removal step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
-
-5.2.5 caseIgnoreListMatch
+4.2.5. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a
- sequence of strings to an attribute value of a syntax (e.g. the
+ sequence of strings to an attribute value of a syntax (e.g., the
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
+ OF the DirectoryString ASN.1 type.
-Legg & Dally Expires 27 August 2003 [Page 29]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+Legg & Dally Expires 27 April 2004 [Page 29]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value have the same number of strings and corresponding
SEQUENCE OF DirectoryString {ub-match}
- i.e. different from the corresponding type for the Postal Address
+ i.e., different from the corresponding type for the Postal Address
syntax. The choice of the Postal Address syntax for the assertion
syntax of the caseIgnoreListMatch in LDAP should not be seen as
limiting the matching rule to only apply to attributes with the
The caseIgnoreListMatch rule is an equality matching rule.
-
-5.2.6 caseIgnoreListSubstringsMatch
+4.2.6. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
- (e.g. the Postal Address syntax) whose corresponding ASN.1 type is a
+ (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
SEQUENCE OF the DirectoryString ASN.1 type.
The rule evaluates to TRUE if and only if the assertion value
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+ The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
-Legg & Dally Expires 27 August 2003 [Page 30]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
- The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+Legg & Dally Expires 27 April 2004 [Page 30]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-5.2.7 caseIgnoreMatch
+4.2.7. caseIgnoreMatch
The caseIgnoreMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g. the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the
- alternative string types of DirectoryString, e.g. PrintableString
+ alternative string types of DirectoryString, e.g., PrintableString
(the other alternatives do not correspond to any syntax defined in
this document).
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of characters and corresponding
- characters are the same, ignoring the case of letters.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Removal is applied in the Insignificant Character
+ Removal step.
The LDAP definition for the caseIgnoreMatch rule is:
The caseIgnoreMatch rule is an equality matching rule.
-
-5.2.8 caseIgnoreOrderingMatch
+4.2.8. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the
- Directory String syntax to an attribute value of a syntax (e.g. the
+ Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if, and only if, in the normal collation
- order for the attribute syntax after lower-case letters in both the
- attribute and assertion values have been replaced by their upper-case
- equivalents, the attribute value appears earlier than the assertion
- value, i.e. the attribute value is "less than" the assertion value.
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
- The collation order for values of the DirectoryString syntax is
- implementation-defined. [Editor's note: this will be specified by a
- stringprep profile before final publication.]
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Removal is applied in the Insignificant Character
+ Removal step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
-Legg & Dally Expires 27 August 2003 [Page 31]
+Legg & Dally Expires 27 April 2004 [Page 31]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule.
-
-5.2.9 caseIgnoreSubstringsMatch
+4.2.9. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the
- Substring Assertion syntax to an attribute value of a syntax (e.g.
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if and only if the substrings of the
- assertion value match disjoint portions of the attribute value in the
- order of the substrings in the assertion value, and an <initial>
- substring, if present, matches the beginning of the attribute value,
- and a <final> substring, if present, matches the end of the attribute
- value. A substring matches a portion of the attribute value if
- corresponding characters are the same, ignoring the case of letters.
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Removal is applied in the Insignificant
+ Character Removal step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
-
-5.2.10 distinguishedNameMatch
+4.2.10. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN
- syntax to an attribute value of a syntax (e.g. the DN syntax) whose
+ syntax to an attribute value of a syntax (e.g., the DN syntax) whose
corresponding ASN.1 type is DistinguishedName.
The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of RDNs and corresponding RDNs
- (by position) are the same. An RDN of the assertion value is the
- same as an RDN of the attribute value if and only if they have the
- same number of attribute value assertions (AVAs) and each AVA of the
- first RDN is the same as the AVA of the second RDN with the same
- attribute type. The order of the AVAs is not significant. Also note
- that a particular attribute type may appear in at most one AVA in an
- RDN. Two AVAs with the same attribute type are the same if their
- values are equal according to the equality matching rule of the
- attribute type. If one or more of the AVA comparisons evaluate to
- Undefined and the remaining AVA comparisons return TRUE then the
- distinguishedNameMatch rule evaluates to Undefined.
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 32]
+ assertion value have the same number of relative distinguished names
+ and corresponding relative distinguished names (by position) are the
+ same. A relative distinguished name (RDN) of the assertion value is
+ the same as an RDN of the attribute value if and only if they have
+ the same number of attribute value assertions and each attribute
+ value assertion (AVA) of the first RDN is the same as the AVA of the
+ second RDN with the same attribute type. The order of the AVAs is
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 32]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+ not significant. Also note that a particular attribute type may
+ appear in at most one AVA in an RDN. Two AVAs with the same
+ attribute type are the same if their values are equal according to
+ the equality matching rule of the attribute type. If one or more of
+ the AVA comparisons evaluate to Undefined and the remaining AVA
+ comparisons return TRUE then the distinguishedNameMatch rule
+ evaluates to Undefined.
+
The LDAP definition for the distinguishedNameMatch rule is:
( 2.5.13.1 NAME 'distinguishedNameMatch'
The distinguishedNameMatch rule is an equality matching rule.
-
-5.2.11 generalizedTimeMatch
+4.2.11. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the
Generalized Time syntax to an attribute value of a syntax (e.g the
The generalizedTimeMatch rule is an equality matching rule.
+4.2.12. generalizedTimeOrderingMatch
-5.2.12 generalizedTimeOrderingMatch
-
- The generalizedTimeMatch rule compares the time ordering of an
- assertion value of the Generalized Time syntax to an attribute value
- of a syntax (e.g the Generalized Time syntax) whose corresponding
- ASN.1 type is GeneralizedTime.
+ The generalizedTimeOrderingMatch rule compares the time ordering of
+ an assertion value of the Generalized Time syntax to an attribute
+ value of a syntax (e.g the Generalized Time syntax) whose
+ corresponding ASN.1 type is GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value
represents a universal coordinated time which is earlier than the
The LDAP definition for the generalizedTimeOrderingMatch rule is:
- ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- The generalizedTimeOrderingMatch rule is an ordering matching rule.
+Legg & Dally Expires 27 April 2004 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-Legg & Dally Expires 27 August 2003 [Page 33]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+ The generalizedTimeOrderingMatch rule is an ordering matching rule.
-5.2.13 integerFirstComponentMatch
+4.2.13. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of
the Integer syntax to an attribute value of a syntax (e.g the DIT
from an attribute value by taking the first component of that
attribute value.
-
-5.2.14 integerMatch
+4.2.14. integerMatch
The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g the Integer syntax)
The integerMatch rule is an equality matching rule.
-5.2.15 numericStringMatch
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 34]
+Legg & Dally Expires 27 April 2004 [Page 34]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+4.2.15. numericStringMatch
+
The numericStringMatch rule compares an assertion value of the
Numeric String syntax to an attribute value of a syntax (e.g the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value are the same string of numerals, ignoring any space
- characters.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Removal is applied in the
+ Insignificant Character Removal step.
The LDAP definition for the numericStringMatch matching rule is:
The numericStringMatch rule is an equality matching rule.
-
-5.2.16 numericStringSubstringsMatch
+4.2.16. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
- The rule evaluates to TRUE if and only if the substrings of the
- assertion value match disjoint portions of the attribute value in the
- order of the substrings in the assertion value, and an <initial>
- substring, if present, matches the beginning of the attribute value,
- and a <final> substring, if present, matches the end of the attribute
- value. A substring matches a portion of the attribute value if
- corresponding characters are the same, ignoring any space characters.
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Removal is applied in the
+ Insignificant Character Removal step.
+
+ The LDAP definition for the numericStringSubstringsMatch matching
+ rule is:
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 35]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule.
-
-5.2.17 objectIdentifierFirstComponentMatch
+4.2.17. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g the
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the OBJECT IDENTIFIER ASN.1 type.
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 35]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
value can be derived from an attribute value by taking the first
component of that attribute value.
-
-5.2.18 objectIdentifierMatch
+4.2.18. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g the OID syntax) whose
<numericoid> form of <oid> or implicitly in the <descr> form (see
[MODELS]).
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 36]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
If an LDAP client supplies an assertion value in the <descr> form,
and the chosen descriptor is not recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined.
The objectIdentifierMatch rule is an equality matching rule.
-
-5.2.19 octetStringMatch
-
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 36]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+4.2.19. octetStringMatch
The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g the Octet String
The octetStringMatch rule is an equality matching rule.
-
-5.2.20 telephoneNumberMatch
+4.2.20. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of characters and corresponding
- characters are the same, ignoring the case of letters, and ignoring
- space and `-' characters.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ telephoneNumber Insignificant Character Removal is applied in the
+ Insignificant Character Removal step.
The LDAP definition for the telephoneNumberMatch matching rule is:
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 37]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
The telephoneNumberMatch rule is an equality matching rule.
-
-5.2.21 telephoneNumberSubstringsMatch
+4.2.21. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
(e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
- The rule evaluates to TRUE if and only if the substrings of the
- assertion value match disjoint portions of the attribute value in the
- order of the substrings in the assertion value, and an <initial>
- substring, if present, matches the beginning of the attribute value,
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 37]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
- and a <final> substring, if present, matches the end of the attribute
- value. A substring matches a portion of the attribute value if
- corresponding characters are the same, ignoring the case of letters,
- and ignoring space and `-' characters.
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only telephoneNumber Insignificant Character Removal is applied
+ in the Insignificant Character Removal step.
The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is:
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
-
-5.2.22 uniqueMemberMatch
+4.2.22. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the
absent from the attribute value or matches the <BitString> component
of the assertion value according to the bitStringMatch rule.
+
+
+Legg & Dally Expires 27 April 2004 [Page 38]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
The LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch'
The uniqueMemberMatch rule is an equality matching rule.
-
-6. Security Considerations
+5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this
document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other
- encoding (e.g. BER) and back into the LDAP-specific encoding will not
- necessarily reproduce exactly the original octets of the
+ encoding (e.g., BER) and back into the LDAP-specific encoding will
+ not necessarily reproduce exactly the original octets of the
LDAP-specific encoding. Therefore an LDAP-specific encoding should
not be used where a canonical encoding is required.
Furthermore, the LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory String and DN
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 38]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
- syntaxes to be reconstructed, e.g. a transformation from DER to
- LDAP-specific encoding and back to DER may not reproduce the original
+ syntaxes to be reconstructed, e.g., a transformation from a
+ Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
+ encoding and back to a DER encoding may not reproduce the original
DER encoding. Therefore LDAP-specific encodings should not be used
- where reversibility to DER is needed, e.g. for the verification of
+ where reversibility to DER is needed, e.g., for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should
be used.
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
-
-7. Acknowledgements
+6. Acknowledgements
This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T.
Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working
The authors wish to thank J. Sermersheim and K. Zeilenga for their
significant contribution to this revision.
-
-8. IANA Considerations
+7. IANA Considerations
The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP descriptors registry as indicated by the following
+ the LDAP descriptors registry [BCP64] as indicated by the following
templates:
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 39]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
bitStringMatch M 2.5.13.16
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 39]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
caseIgnoreListMatch M 2.5.13.11
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
uniqueMemberMatch M 2.5.13.23
The descriptor for the object identifier 2.5.13.0 was incorrectly
- registered as objectIdentifiersMatch (extraneous `s') in RFC 3383.
+ registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
It should be changed to the following with a reference to RFC
XXXX.
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 40]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
Person & email address to contact for further information:
Steven Legg <steven.legg@adacel.com.au>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
+8. References
-9. Normative References
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 40]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
+8.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
+ [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
+ progress, June 2003.
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC
- 3383, September 2002.
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress, August 2002.
+ in progress, June 2003.
[PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
- protocol-xx.txt, a work in progress, December 2002.
+ protocol-xx.txt, a work in progress, September 2003.
[E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988.
document transmission - Terminal Equipment and Protocols
for Telematic Services, ITU-T Recommendation T.4, 1993
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 41]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
[T.50] International Reference Alphabet (IRA) (Formerly
International Alphabet No. 5 or IA5) Information
Technology - 7-Bit Coded Character Set for Information
Information Technology - Open Systems Interconnection -
The Directory: Selected attribute types
- [ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
- Information Technology - Abstract Syntax Notation One
+ [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation
[ISO3166] ISO 3166, "Codes for the representation of names of
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 41]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
countries".
[UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992.
+ [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
+ June 2003.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt, a work in progress, June 2003.
+
+ [PREP] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
+ progress, June 2003.
-10. Informative References
+8.2. Informative References
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
+
+
+Legg & Dally Expires 27 April 2004 [Page 42]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
+ [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
+ ietf-ldapbis-user-schema-xx.txt, a work in progress, June
+ 2003.
+
+ [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
+ PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
+ progress, July 2002.
+
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services
- [BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
- Information Technology - ASN.1 encoding rules:
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
-
-11. Authors' Addresses
+9. Authors' Addresses
Steven Legg
Adacel Technologies Ltd.
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
Email: steven.legg@adacel.com.au
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 42]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
Kathy Dally
The MITRE Corp.
7515 Colshire Dr., ms-W650
Email: kdally@mitre.org
-12. Copyright Notice
-
- 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.
+Legg & Dally Expires 27 April 2004 [Page 43]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
+10. Intellectual Property Notice
+
+ 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.
Appendix A. Summary of Syntax Object Identifiers
Syntax OBJECT IDENTIFIER
==============================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 43]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean 1.3.6.1.4.1.1466.115.121.1.7
Country String 1.3.6.1.4.1.1466.115.121.1.11
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 44]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
-
Appendix B. Changes from RFC 2252 & RFC 2256
This annex lists the significant differences between this
and revised. Changes to the parts of these sections moved to
[MODELS] are detailed in [MODELS].
-
-
-Legg & Dally Expires 27 August 2003 [Page 44]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
3. BNF descriptions of syntax formats have been replaced by ABNF
[ABNF] specifications.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
use of a backslash quoting mechanism to escape separator symbols
- has been removed. The escaping mechanism is now explicitly
+ has been removed. The escaping mechanism is now explicitly
represented in the ABNF for the syntaxes where this provision
applies.
7. The set of characters allowed in a <PrintableString> (formerly
<printablestring>) has been corrected to align with the
+
+
+
+Legg & Dally Expires 27 April 2004 [Page 45]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
PrintableString ASN.1 type in [ASN.1]. Specifically, the double
quote character has been removed and the single quote character
and equals sign have been added.
transfer encoding.
13. All discussion of transfer options, including the ";binary"
- option, has been removed. All imperatives regarding binary
+ option, has been removed. All imperatives regarding binary
transfer of values have been removed.
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
-
-
-
-Legg & Dally Expires 27 August 2003 [Page 45]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal
20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity.
+
+
+Legg & Dally Expires 27 April 2004 [Page 46]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+
+
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification,
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added.
- 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreListSubstringsMatch,
- caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching
- rules have been added to the list of matching rules for which the
- provisions for handling leading, trailing and multiple adjoining
- whitespace characters apply. This is consistent with the
- definitions of these matching rules in X.500. The
- telephoneNumberMatch rule has been removed from the list since it
- completely ignores all space characters.
+ 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
+ caseIgnoreSubstringsMatch matching rules have been added to the
+ list of matching rules for which the provisions for handling
+ leading, trailing and multiple adjoining whitespace characters
+ apply (now through string preparation). This is consistent with
+ the definitions of these matching rules in X.500. The
+ caseIgnoreIA5SubstringsMatch rule has also been added to the
+ list.
26. The specification of the octetStringMatch matching rule from RFC
2256 has been added to this document.
-
-
-Legg & Dally Expires 27 August 2003 [Page 46]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
-
-
27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity.
30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added to this document.
+ 31. String preparation algorithms have been applied to the character
+ string matching rules.
+Full Copyright Statement
+Legg & Dally Expires 27 April 2004 [Page 47]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Legg & Dally Expires 27 August 2003 [Page 47]
+Legg & Dally Expires 27 April 2004 [Page 48]
\f
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2255 Tim Howes
-Expires: 28 August 2003 Opsware, Inc.
+Expires: 25 April 2004 Opsware, Inc.
- 28 February 2003
+ 25 October 2003
LDAP: Uniform Resource Locator
- <draft-ietf-ldapbis-url-03.txt>
+ <draft-ietf-ldapbis-url-04.txt>
Smith & Howes Intended Category: Standards Track [Page 1]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
3. Table of Contents
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................2
+5.1. Escaping Using the Method.................................4
6. Defaults for Fields of the LDAP URL............................5
-7. Examples.......................................................5
-8. Security Considerations........................................7
-9. Acknowledgements...............................................8
-10. Normative References...........................................9
-11. Informative References.........................................9
-12. Authors' Address...............................................9
-13. Full Copyright Statement.......................................10
-14. Appendix A: Changes Since RFC 2255.............................10
-14.1. Technical Changes...........................................10
-14.2. Editorial Changes...........................................11
-15. Appendix B: Changes Since Previous Document Revision...........13
-15.1. Technical Changes...........................................13
-15.2. Editorial Changes...........................................13
+7. Examples.......................................................6
+8. Security Considerations........................................8
+9. Normative References...........................................8
+10. Informative References.........................................9
+11. Intellectual Property Rights...................................9
+12. Acknowledgements...............................................10
+13. Authors' Address...............................................10
+14. Full Copyright Statement.......................................11
+15. Appendix A: Changes Since RFC 2255.............................11
+15.1. Technical Changes...........................................11
+15.2. Editorial Changes...........................................12
+16. Appendix B: Changes Since Previous Document Revision...........13
+16.1. Technical Changes...........................................14
+16.2. Editorial Changes...........................................14
4. Introduction
5. URL Definition
An LDAP URL begins with the protocol prefix "ldap" and is defined by
- the following grammar, following the ABNF notation defined in
- [RFC2234].
Smith & Howes Intended Category: Standards Track [Page 2]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+ the following grammar, following the ABNF notation defined in
+ [RFC2234].
+
ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
[QUESTION [attributes] [QUESTION [scope]
[QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
hostport = <hostport from Section 3.2.2 of [RFC2396]>
- ; as updated by [RFC2732] to allow IPv6 literal addresses
+ ; as updated by [RFC2732] to allow IPv6 literal addresses
dn = <distinguishedName from Section 3 of [LDAPDN]>
+ ; see the "Escaping Using the % Method" section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
- / ASTERIX
+ / ASTERISK
+ ; see the "Escaping Using the % Method" section below.
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
+ ; see the "Escaping Using the % Method" section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
+ ; see the "Escaping Using the % Method" section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
- oiddescr = <name from section 3.3 of [LDAPIANA]>
+ oiddescr = <name from section 3.3 of [RFC3383]>
EXCLAMATION = %x21 ; exclamation mark ("!")
- ASTERIX = %x2A ; asterix ("*")
+ ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/")
The scope construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base"
- for a base object search, "one" for a one-level search, or "sub" for
- a subtree search.
-
- The filter is used to specify the search filter to apply to entries
- within the specified scope during the search. It has the format
- specified in [Filters].
-
Smith & Howes Intended Category: Standards Track [Page 3]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search.
+
+ The filter is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [Filters].
+
The extensions construct provides the LDAP URL with an extensibility
mechanism, allowing the capabilities of the URL to be extended in the
future. Extensions are a simple comma-separated list of type=value
The extension type (extype) MAY be specified using the oid form
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
of the oiddesc form SHOULD be restricted to registered object
- identifier descriptive names. See [LDAPIANA] for registration
- details and usage guidelines for descriptive names.
+ identifier descriptive names. See [RFC3383] for registration details
+ and usage guidelines for descriptive names.
No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more
extensions.
+5.1. Escaping Using the % Method
+
A generated LDAP URL MUST consist only of the restricted set of
characters included in the uric production that is defined in section
2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
- strings as input. An octet MUST be escaped using the % method
- described in section 2.4 of [RFC2396] in any of these situations:
+ strings [UTF-8] as input. An octet MUST be escaped using the %
+ method described in section 2.4 of [RFC2396] in any of these
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
+ situations:
The octet is not in the reserved set defined in section 2.2 of
[RFC2396] or in the unreserved set defined in section 2.3 of
It is a comma character ',' that occurs inside an extension value.
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
-
-
6. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the
If extensions is omitted, no extensions are assumed.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
7. Examples
The following are some example LDAP URLs using the format defined
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
-
-
Both of these URLs correspond to a base object search of the
"o=University of Michigan,c=US" entry using a filter of
"(objectclass=*)", requesting all attributes.
the LDAP entry named "o=Question?,c=US" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'.
- ldap://ldap2.example.com/o=Question%3f,c=US?mail
- The next example illustrates the interaction between the LDAP string
- representation of filters quoting mechanism and URL quoting
- mechanisms.
- ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
- The filter in this example uses the LDAP escaping mechanism of \ to
- encode three zero or null bytes in the value. In LDAP, the filter
- would be written as (int=\00\00\00\04). Because the \ character must
- be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
-
- The next example illustrates the interaction between the LDAP string
+Smith & Howes Intended Category: Standards Track [Page 6]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+ ldap://ldap2.example.com/o=Question%3f,c=US?mail
-Smith & Howes Intended Category: Standards Track [Page 6]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+ The next example illustrates the interaction between the LDAP string
+ representation of filters quoting mechanism and URL quoting
+ mechanisms.
+ ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
+ IP The filter in this example uses the LDAP escaping mechanism of \
+ to encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (four-octet=\00\00\00\04). Because the \
+ character must be escaped in a URL, the \'s are escaped as %5c in the
+ URL encoding.
+ The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
the e-bindname extension.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
8. Security Considerations
General URL security considerations discussed in [RFC2396] are
with this policy. If a client chooses to reuse an existing
connection when resolving one or more LDAP URL, it MUST ensure that
the connection is compatible with the URL and that no security
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 7]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
-
-
policies are violated.
Sending authentication information, no matter the mechanism, may
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
-9. Acknowledgements
-
- The LDAP URL format was originally defined at the University of
- Michigan. This material is based upon work supported by the National
- Science Foundation under Grant No. NCR-9416667. The support of both
- the University of Michigan and the National Science Foundation is
- gratefully acknowledged.
+9. Normative References
- This document is an update to RFC 2255 by Tim Howes and Mark Smith.
- Changes included in this revised specification are based upon
- discussions among the authors, discussions within the LDAP (v3)
- Revision Working Group (ldapbis), and discussions within other IETF
- Working Groups. The contributions of individuals in these working
- groups is gratefully acknowledged. Several people in particular have
- made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
- Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
- thanks for their contributions.
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Smith & Howes Intended Category: Standards Track [Page 8]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
-10. Normative References
-
- [LDAPDN] Zeilenga, K. (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-iana-xx.txt, a work in progress.
-
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
- progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to
- Indicate Requirement Levels," RFC 2119, BCP 14, March 1997.
+ progress.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels," RFC 2119, BCP 14, March 1997.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
-
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", RFC 3383, September 2002.
+
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-11. Informative References
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ draft-yergeau-rfc2279bis-xx.txt, a work in progress.
+
+10. Informative References
None.
-12. Authors' Address
+11. Intellectual Property Rights
- Mark Smith, Editor
- Netscape Communications Corp.
- 360 W. Caribbean Drive
- Sunnyvale, CA 94089
- USA
- +1 650 937-3477
+ 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
Smith & Howes Intended Category: Standards Track [Page 9]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
+ 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.
+
+12. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+ This document is an update to RFC 2255 by Tim Howes and Mark Smith.
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged. Several people in particular have
+ made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
+ Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+ thanks for their contributions.
+13. Authors' Address
- mcs@netscape.com
+ Mark Smith, Editor
+ Netscape Communications Corp.
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
+ USA
+ +1 650 937-3477
+ MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
Sunnyvale, CA 94085
USA
+1 408 744-7509
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
howes@opsware.com
-13. Full Copyright Statement
+14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+15. Appendix A: Changes Since RFC 2255
-14. Appendix A: Changes Since RFC 2255
-
-14.1. Technical Changes
+15.1. Technical Changes
The following technical changes were made to the contents of the "URL
Definition" section:
Revised all of the ABNF to use common productions from [Models].
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
-
-
Added note and references to [RFC2732] to allow literal IPv6
addresses inside the hostport portion of the URL.
- Added missing ASTERIX as an alternative for the attrdesc part of the
+ Added missing ASTERISK as an alternative for the attrdesc part of the
URL. It is believed that existing implementations of RFC 2255
already support this.
Added angle brackets around free-form prose in the "dn", "hostport",
"attrdesc", "filter", and "exvalue" rules.
+
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
Changed the ABNF for ldapurl to group the dn component with the
preceding slash.
Changed the extype rule to be an LDAPOID from [Protocol] or an OID
- description from [LDAPIANA].
+ description from [RFC3383].
- Changed the text about extension types so it references [LDAPIANA].
+ Changed the text about extension types so it references [RFC3383].
Reordered rules to more closely follow the order the elements appear
in the URL.
"Bindname Extension": removed due to lack of known implementations.
-14.2. Editorial Changes
+15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
"URL Definition" section: removed second copy of ldapurl grammar and
following two paragraphs (editorial error in RFC 2255). Fixed line
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 11]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
-
-
break within '!' sequence. Reworded last paragraph to clarify which
characters must be URL escaped. Added text to indicate that LDAP
URLs are used for references and referrals. Added text that refers
"URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 12]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
+
+
to indicate that use of security services is encouraged and that they
SHOULD be used when updates are involved. Removed "dn" from
discussion of authentication methods. Added note that the client MAY
example.net hostnames. Added missing '?' to the LDAP URL example
whose filter contains three null bytes. Removed space after one
comma within a DN. Revised the bindname example to use e-bindname.
- Added an example that demonstrates the interaction between DN
- escaping and URL escaping. Added some examples to show URL
- equivalence with respect to the dn portion of the URL.
+ Changed the name of an attribute used in one example from "int" to
+ "four-octet" to avoid potential confusion. Added an example that
+ demonstrates the interaction between DN escaping and URL escaping.
+ Added some examples to show URL equivalence with respect to the dn
+ portion of the URL.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added references to RFCs 2234 and 2829. Updated RFC 1738
- references to the appropriate sections within RFC 2396. Updated the
- references to refer to LDAPBis WG documents. Removed the reference to
- the LDAP Attribute Syntaxes document and added references to the LDAP
- IANA and Roadmap documents.
+ document. Added references to RFCs 2234, 2829, and 3383. Updated
+ RFC 1738 references to the appropriate sections within RFC 2396.
+ Updated the references to refer to LDAPBis WG documents. Removed the
+ reference to the LDAP Attribute Syntaxes document and added a
+ reference to the Roadmap document.
"Informative References" section: added for clarity.
Copyright: updated the year.
+16. Appendix B: Changes Since Previous Document Revision
+ This appendix lists all changes relative to the previously published
+ revision, draft-ietf-ldapbis-url-03.txt. Note that when appropriate
+ these changes are also included in Appendix A, but are also included
+ here for the benefit of the people who have already reviewed draft-
+ ietf-ldapbis-url-03.txt. This section will be removed before this
+ document is published as an RFC.
-Smith & Howes Intended Category: Standards Track [Page 12]
+
+Smith & Howes Intended Category: Standards Track [Page 13]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
-15. Appendix B: Changes Since Previous Document Revision
+16.1. Technical Changes
- This appendix lists all changes relative to the last published
- revision, draft-ietf-ldapbis-url-02.txt. Note that when appropriate
- these changes are also included in Appendix A, but are also included
- here for the benefit of the people who have already reviewed draft-
- ietf-ldapbis-url-02.txt. This section will be removed before this
- document is published as an RFC.
+ None.
-15.1. Technical Changes
+16.2. Editorial Changes
- "URL Definition" section: revised all of the ABNF to use common
- productions from [Models] and added note and references to [RFC2732]
- to allow literal IPv6 addresses inside the hostport portion of the
- URL.
+ "URL Definition" section: added comments in the ABNF to point the
+ reader to the "Escaping Using the % Method" section, which was
+ changed into a section of its own to highlight the importance of
+ escaping the URL components correctly.
+ "Examples" section: changed the name of an attribute used in one
+ example from "int" to "four-octet" to avoid potential confusion.
-15.2. Editorial Changes
+ Replaced all occurrences of "asterix" with the correctly spelled
+ "asterisk."
- "Status of this Memo" section: updated boilerplate to match current
- I-D guidelines.
+ "Normative References" section: changed UTF-8 reference to point to
+ the UTF-8 Internet Draft; replace [LDAPIANA] Internet Draft reference
+ with a reference to RFC 3383.
- "URL Definition" section: replaced misleading phrase "MAY define
- other extensions" with "MAY define one or more extensions" (this
- document no longer defines any extensions). Rewrote the last
- paragraph of this section to more clearly describe the escaping rules
- and to reference [RFC2396] accurately.
+ "Intellectual Property Rights" section: added.
- "Examples" section: added an example that demonstrates the
- interaction between DN escaping and URL escaping and clarified the
- text that introduces the LDAP filter escaping interaction example.
+ Author's Addresses section: New email address for Mark Smith.
- "Acknowledgements" section: added Hallvard Furuseth.
+ "Full Copyright Statement" section: updated text to match latest IETF
+ guidelines.
- "Normative References" section: added a reference to [RFC2732].
- "Informative References" section: added for clarity.
+This Internet Draft expires on 25 April 2004.
- Copyright: updated the year to 2003.
- "Authors' Address" section: updated Tim's contact information.
- Appendix A: added an older editorial change that was accidently
- overlooked (Changed document title to include "LDAP:" prefix).
-This Internet Draft expires on 28 August 2003.
-Smith & Howes Intended Category: Standards Track [Page 13]
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 14]
\f
INTERNET-DRAFT K. Dally, Editor
Intended Category: Standard Track The MITRE Corp.
-Expires: October 2003 April 2003
-Updates: RFC 2247
+Expires: December 2003 June 2003
+Updates: RFC 2247, RFC 2798
Obsoletes: RFC 2256
- LDAP: User Schema
- <draft-ietf-ldapbis-user-schema-05>
+ LDAP: Schema for User Applications
+ <draft-ietf-ldapbis-user-schema-06>
Status of this Memo
Abstract
- This document is a integral part of the LDAP technical specification
- [ROADMAP]. It provides an overview of attribute types and object
- classes intended for use by LDAP directory clients for many
- directory services, such as, White Pages. Originally specified the
- ISO/IEC 9594 and X.500 documents, these objects are widely used as a
+ This document is a integral part of the Lightweight Directory Access
+ Protocol (LDAP) technical specification [ROADMAP]. It provides a
+ technical specification of attribute types and object classes
+ intended for use by LDAP directory clients for many directory
+ services, such as, White Pages. These objects are widely used as a
basis for the schema in many LDAP directories. This document does
not cover attributes used for the administration of directory
servers, nor does it include directory objects defined for specific
uses in other documents.
-Dally Expires October 2003 [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Dally Expires December 2003 [Page 1]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- Table of Contents
+ Table of Contents
Status of this Memo 1
2.3 cn 6
2.4 dc 6
2.5 description 6
- 2.6 destinationIndicator 6
+ 2.6 destinationIndicator 7
2.7 distinguishedName 7
2.8 dnQualifier 7
- 2.9 enhancedSearchGuide 7
- 2.10 facsimileTelephoneNumber 7
+ 2.9 enhancedSearchGuide 8
+ 2.10 facsimileTelephoneNumber 8
2.11 generationQualifier 8
2.12 givenName 8
- 2.13 houseIdentifier 8
- 2.14 initials 8
- 2.15 internationalISDNNumber 8
+ 2.13 houseIdentifier 9
+ 2.14 initials 9
+ 2.15 internationalISDNNumber 9
2.16 l 9
- 2.17 member 9
- 2.18 name 9
- 2.19 o 9
- 2.20 ou 9
- 2.21 owner 10
- 2.22 physicalDeliveryOfficeName 10
- 2.23 postalAddress 10
- 2.24 postalCode 10
- 2.25 postOfficeBox 10
- 2.26 preferredDeliveryMethod 11
- 2.27 registeredAddress 11
- 2.28 roleOccupant 11
- 2.29 searchGuide 11
- 2.30 seeAlso 12
- 2.31 serialNumber 12
- 2.32 sn 12
- 2.33 st 12
- 2.34 street 12
- 2.35 telephoneNumber 12
+ 2.17 member 10
+ 2.18 name 10
+ 2.19 o 10
+ 2.20 ou 10
+ 2.21 owner 11
+ 2.22 physicalDeliveryOfficeName 11
+ 2.23 postalAddress 11
+ 2.24 postalCode 11
+ 2.25 postOfficeBox 12
+ 2.26 preferredDeliveryMethod 12
+ 2.27 registeredAddress 12
+ 2.28 roleOccupant 13
+ 2.29 searchGuide 13
+ 2.30 seeAlso 13
+ 2.31 serialNumber 13
+ 2.32 sn 14
+ 2.33 st 14
+ 2.34 street 14
+ 2.35 telephoneNumber 14
-Dally Expires October 2003 [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Dally Expires December 2003 [Page 2]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- 2.36 teletexTerminalIdentifier 13
- 2.37 telexNumber 13
- 2.38 title 13
- 2.39 uniqueMember 13
- 2.40 userPassword 14
- 2.41 x121Address 14
- 2.42 x500UniqueIdentifier 14
+ 2.36 teletexTerminalIdentifier 14
+ 2.37 telexNumber 15
+ 2.38 title 15
+ 2.39 uid 15
+ 2.40 uniqueMember 15
+ 2.41 userPassword 16
+ 2.42 x121Address 16
+ 2.43 x500UniqueIdentifier 16
-3. Object Classes 15
- 3.1 applicationProcess 15
- 3.2 country 15
- 3.3 device 15
- 3.4 domain 15
- 3.5 groupOfNames 16
- 3.6 groupOfUniqueNames 16
- 3.7 locality 17
- 3.8 organization 17
- 3.9 organizationalPerson 17
- 3.10 organizationalRole 18
- 3.11 organizationalUnit 18
- 3.12 person 18
- 3.13 residentialPerson 19
+3. Object Classes 17
+ 3.1 applicationProcess 17
+ 3.2 country 17
+ 3.3 device 17
+ 3.4 groupOfNames 18
+ 3.5 groupOfUniqueNames 18
+ 3.6 locality 18
+ 3.7 organization 19
+ 3.8 organizationalPerson 19
+ 3.9 organizationalRole 19
+ 3.10 organizationalUnit 20
+ 3.11 person 20
+ 3.12 residentialPerson 20
-4. IANA Considerations 19
+4. IANA Considerations 21
-5. Security Considerations 19
+5. Security Considerations 22
-6. Acknowledgements 19
+6. Acknowledgements 23
-7. References 20
- 7.1 Normative 20
- 7.2 Informative 20
+7. References 23
+ 7.1 Normative 23
+ 7.2 Informative 24
-8. Author's Address 21
+8. Author's Address 25
-9. Full Copyright Statement 21
+9. Full Copyright Statement 25
-Dally Expires October 2003 [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2002
+Dally Expires December 2003 [Page 3]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2002
1. Introduction
This document provides an overview of attribute types and object
- classes intended for use by LDAP directory clients for many
- directory services, such as, White Pages. Originally specified in
- the ISO/IEC 9594 and X.500 documents, these objects are widely used
- as a basis for the schema in many LDAP directories. This document
- does not cover attributes used for the administration of directory
- servers, nor does it include directory objects defined for specific
- uses in other documents.
+ classes intended for use by Lightweight Directory Access Protocol
+ directory clients for many directory services, such as, White Pages.
+ Originally specified in the X.500 [X.500] documents, these objects
+ are widely used as a basis for the schema in many LDAP
+ directories. This document does not cover attributes used for the
+ administration of directory servers, nor does it include directory
+ objects defined for specific uses in other documents.
1.1 Situation
This document is a integral part of the LDAP technical specification
[ROADMAP] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety. In terms of RFC 2256,
- Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes].
- Sections 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models].
- The remainder of RFC 2256 is obsoleted by this document. Sections
- 3.4 and 4.4 of this document supercede the technical specifications
- for the 'dc' attribute type and 'domain' object class found in
- RFC 2247. The remainder of RFC 2247 remains in force.
+ Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections
+ 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The
+ remainder of RFC 2256 is obsoleted by this document. Section 3.4 of
+ this document supercedes the technical specification for the 'dc'
+ attribute type found in RFC 2247.[editor's note: Substitute
+ replacement RFC at time of publication.] The remainder of RFC 2247
+ remains in force.
+
+ This document updates RFC 2798 by replacing the informative
+ description of the 'uid' attribute type, with the definitive
+ description provided in Section 2.39 of this document.
A number of schema elements which were included in the previous
revision of the LDAP Technical Specification are not included in this
-
-
-
-
-
-Dally Expires October 2003 [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Dally Expires December 2003 [Page 4]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
1.4 Source
The schema definitions in this document are based on those found in
- the X.500-series [X.520] and [X.521] and RFC 2247 [RFC2247],
- specifically:
+ the X.500-series [X.520] and [X.521], RFC 2798 [RFC2798] and
+ RFC 2247 [RFC2247], specifically:
+
+ Sections Source
+ ============ ==================
+ 2.1 - 2.3 X.520 [X.520]
+ 2.4 RFC 2247 [RFC2247]
+ 2.5 - 2.38 X.520 [X.520]
+ 2.39 RFC 2798 [2798]
+ 2.40 - 2.43 X.520 [X.520]
+ 3.1 - 3.12 X.521 [X.521]
- Sections Source
- ============ ==================
- 2.1 - 2.3 X.520 [X.520]
- 2.4 RFC 2247 [RFC2247]
- 2.5 - 2.42 X.520 [X.520]
- 3.1 - 3.3 X.521 [X.521]
- 3.4 RFC 2247 [RFC2247]
- 3.5 - 3.13 X.521 [X.521]
+ However, the descriptions in this document SHALL be considered
+ definitive for use in LDAP.
-2. Attribute Types
+2. Attribute Types
The Attribute Types contained in this section hold user information.
There is no requirement that servers implement the following
- Attribute Types:
+ attribute types:
- searchGuide
- teletexTerminalIdentifier
+ searchGuide
+ teletexTerminalIdentifier
In fact, their use is greatly discouraged.
An LDAP server implementation SHOULD recognize the rest of the
- Attribute Types described in this section.
+ attribute types described in this section.
2.1 businessCategory
- This Attribute Type describes the kind of business performed by
- an organization.
+ The businessCategory attribute type describes the kinds of business
+ performed by an organization (e.g., "banking", "transportation").
+ Each kind is one value of this multi-valued attribute.
( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.2 c
- This is the X.520 [X.520] countryName Attribute Type, which contains
- a two-letter ISO 3166 [ISO3166]country code.
-
- ( 2.5.4.6 NAME 'c'
- SUP name
- SINGLE-VALUE )
+ The c (countryName) attribute type contains a two-letter ISO 3166
+ [ISO3166] country code (e.g., "DE"). (Source: X.520)
+Dally Expires December 2003 [Page 5]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-Dally Expires October 2003 [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SINGLE-VALUE )
2.3 cn
- This is the X.520 [X.520] commonName Attribute Type, which contains
- a name of an object. If the object corresponds to a person, it is
- typically the person's full name.
+ The cn (commonName) attribute type contains names of an object
+ (e.g., "Martin K Smith", "Marty Smith", "printer12"). Each name is
+ one value of this multi-valued attribute. If the object corresponds
+ to a person, it is typically the person's full name.
+ (Source: X.520)
( 2.5.4.3 NAME 'cn'
SUP name )
2.4 dc
- The dc (short for domainComponent) attribute type is defined as
- follows:
+ The dc (short for domainComponent) attribute type is a string
+ holding one component, a <label> [RFC1034}, of a DNS domain name
+ (e.g., "example" or "com", but not "example.com"). The encoding of
+ IA5String for use in LDAP is simply the characters of the string
+ itself. The equality matching rule is case insensitive, as is
+ today's DNS.
( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
- The value of this attribute is a string holding one component of a
- DNS domain name. The encoding of IA5String for use in LDAP is simply
- the characters of the string itself. The equality matching rule is
- case insensitive, as is today's DNS.
+ 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String
+ syntax [Syntaxes].
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the label 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.5 description
- This Attribute Type contains a human-readable description of
- the object.
+ The description attribute type contains human-readable descriptive
+ phrases about the object (e.g., "a color printer", "Maintenance is
+ done every Monday, at 1pm."). Each description is one value of this
+ multi-valued attribute.
( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
-
- The SYNTAX oid indicates the Directory String syntax.
-2.6 destinationIndicator
-
- This attribute is used for the telegram service.
-
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
- The SYNTAX oid indicates the Printable String syntax.
+Dally Expires December 2003 [Page 6]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
+2.6 destinationIndicator
+ The destinationIndicator attribute type contains country and city
+ strings, associated with the object (the addressee), needed to
+ provide the Public Telegram Service. Each string is one value of
+ this multi-valued attribute. The strings are composed in accordance
+ with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
-Dally Expires October 2003 [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String
+ syntax [Syntaxes].
2.7 distinguishedName
- This Attribute Type is not used as the name of the object itself,
- but it is instead a base type from which attributes with DN syntax
- inherit.
+ The distinguishedName attribute type is the attribute supertype from
+ which attribute types with DN syntax inherit, instead of containing
+ values which name the object itself. The attribute type is
+ multi-valued.
It is unlikely that values of this type itself will occur in an
entry. LDAP server implementations which do not support attribute
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
- The SYNTAX oid indicates the DN syntax.
+ 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
2.8 dnQualifier
- The dnQualifier Attribute Type specifies disambiguating information
- to add to the relative distinguished name of an entry. It is
- intended for use when merging data from multiple sources in order to
- prevent conflicts between entries which would otherwise have the same
- name. It is recommended that the value of the dnQualifier attribute
- be the same for all entries from a particular source.
+ The dnQualifier attribute type contains disambiguating information
+ strings to add to the relative distinguished name of an entry. The
+ information is intended for use when merging data from multiple
+ sources in order to prevent conflicts between entries which would
+ otherwise have the same name. Each string is one value of this
+ multi-valued attribute. It is recommended that a value of the
+ dnQualifier attribute be the same for all entries from a
+ particular source.
+
+
+
+Dally Expires December 2003 [Page 7]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
( 2.5.4.46 NAME 'dnQualifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
- The SYNTAX oid indicates the Printable String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String
+ syntax [Syntaxes].
2.9 enhancedSearchGuide
- This attribute is for use by X.500 clients in constructing search
- filters.
+ The enhancedSearchGuide attribute type contains sets of information
+ for use by directory clients in constructing search filters. Each
+ set is one value of this multi-valued attribute.
( 2.5.4.47 NAME 'enhancedSearchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
- The SYNTAX oid indicates the Enhanced Guide syntax.
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide
+ syntax [Syntaxes].
2.10 facsimileTelephoneNumber
- A value of this Attribute Type is a telephone number for a facsimile
- terminal (and, optionally, its parameters).
+ The facsimileTelephoneNumber attribute type contains telephone
+ numbers (and, optionally, the parameters) for facsimile terrminals.
+ Each telephone number is one value of this multi-valued attribute.
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
-
-
-Dally Expires October 2003 [Page 7]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
- The SYNTAX oid indicates the Facsimile Telephone Number syntax.
+ 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+ Number syntax [Syntaxes].
2.11 generationQualifier
- The generationQualifier Attribute Type contains the part of a
- person's name which typically is the suffix, as in "IIIrd".
+ The generationQualifier attribute type contains name strings that
+ are the part of a person's name which typically is the suffix, as in
+ "IIIrd" or "3rd". Each string is one value of this multi-valued
+ attribute.
( 2.5.4.44 NAME 'generationQualifier'
SUP name )
2.12 givenName
- The givenName Attribute Type is used to hold the part of a person's
- name which is not their surname nor middle name.
+ The givenName attribute type contains name strings that are the part
+ of a person's name which is not their surname. Each string is one
+ value of this multi-valued attribute.
( 2.5.4.42 NAME 'givenName'
SUP name )
+
+
+Dally Expires December 2003 [Page 8]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
2.13 houseIdentifier
- This Attribute Type is used to identify a building within a location.
+ The houseIdentifier attribute type contains identifiers for a
+ building within a location. Each identifier is one value of this
+ multi-valued attribute.
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.14 initials
- The initials Attribute Type contains the initials of some or all of
- an individuals names, except the surname(s).
+ The initials attribute type contains strings of initials of some or
+ all of an individual's names, except the surname(s)
+ (e.g., "K. A.", "K"). Each string is one value of this multi-valued
+ attribute.
- ( 2.5.4.43 NAME 'initials'
+ ( 2.5.4.43 NAME 'initials'
SUP name )
2.15 internationalISDNNumber
- A value of this Attribute Type is an ISDN address, as defined in
- ITU Recommendation E.164 [E.164].
+ The internationalISDNNumber attribute type contains ISDN addresses,
+ as defined in ITU Recommendation E.164 [E.164]. Each address is one
+ value of this multi-valued attribute.
( 2.5.4.25 NAME 'internationalISDNNumber'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) i
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String
+ syntax [Syntaxes].
- The SYNTAX oid indicates the Numeric String syntax.
+2.16 l
+ The l (localityName) attribute type contains names of a locality or
+ place, such as a city, county or other geographic region (e.g.,
+ "Geneva"). Each name is one value of this multi-valued attribute.
+ (Source: X.520)
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
-Dally Expires October 2003 [Page 8]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-2.16 l
- This is the X.520 [X.520] localityName Attribute Type, which
- contains the name of a locality or place, such as a city, county or
- other geographic region.
+Dally Expires December 2003 [Page 9]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- ( 2.5.4.7 NAME 'l'
- SUP name )
2.17 member
- A value of this Attribute Type is the Distinguished Name of an
- object that is on a list or in a group.
+ The member attribute type contains the Distinguished Names of
+ objects that are on a list or in a group. Each name is one value of
+ this multi-valued attribute.
( 2.5.4.31 NAME 'member'
SUP distinguishedName )
2.18 name
- The name Attribute Type is the attribute supertype from which string
- Attribute Types typically used for naming may be formed. It is
- unlikely that values of this type itself will occur in an entry.
- LDAP server implementations which do not support attribute subtyping
- need not recognize this attribute in requests. Client
+ The name attribute type is the attribute supertype from which
+ attributes with the name syntax inherit. Such attributes are
+ typically used for naming. The attribute type is multi-valued.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.19 o
- This is the X.520 [X.520] organizationName Attribute Type, which
- contains the name of an organization.
+ The o (organizationName) attribute type contains the names of an
+ organization (e.g., "IETF", "Internet Engineering Task Force").
+ Each name is one value of this multi-valued attribute.
+ (Source: X.520)
( 2.5.4.10 NAME 'o'
SUP name )
2.20 ou
- This is the X.520 [X.520] organizationalUnitName Attribute Type,
- which contains the name of an organizational unit.
+ The ou (organizationalUnitName) attribute type contains the names of
+ an organizational unit (e.g., "Application Area", "LDAPbis WG").
+ Each name is one value of this multi-valued attribute.
+ (Source: X.520)
- ( 2.5.4.11 NAME 'ou'
+ ( 2.5.4.11 NAME 'ou'
SUP name )
-Dally Expires October 2003 [Page 9]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+Dally Expires December 2003 [Page 10]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
2.21 owner
- A value of this Attribute Type is the Distinguished Name of an
- object that has an ownership responsibility for the object that
- is owned.
+ The owner attribute type contains the Distinguished Names of objects
+ that have an ownership responsibility for the object that is owned.
+ (e.g., The list object, "cn=All Employees, ou=Mailing List,
+ o=Widget, Inc.", is owned by the role object, "cn=ou=Human Resources
+ Director, ou=employee, o=Widget, Inc.") Each name is one value of
+ this multi-valued attribute.
- ( 2.5.4.32 NAME 'owner'
+ ( 2.5.4.32 NAME 'owner'
SUP distinguishedName )
2.22 physicalDeliveryOfficeName
- This attribute contains the name that a Postal Service uses to
- identify a post office.
+ The physicalDeliveryOfficeName attribute type contains names that a
+ Postal Service uses to identify a post office (e.g., "Bremerhaven,
+ Main", "Bremerhaven, Bonnstrasse").
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.23 postalAddress
- This attribute contains an address used by a Postal Service to
- perform services for the object.
+ The postalAddress attribute type contains addresses used by a Postal
+ Service to perform services for the object (e.g., "15 Main St.,
+ Ottawa, Canada"). Each address is one value of this multi-valued
+ attribute.
( 2.5.4.16 NAME 'postalAddress'
EQUALITY caseIgnoreListMatch
SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.41 )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
- The SYNTAX oid indicates the Postal Address syntax.
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address
+ syntax [Syntaxes].
2.24 postalCode
- This attribute contains a code used by a Postal Service to identify
- a postal service zone, such as the southern quadrant of a city.
+ The postalCode attribute type contains codes used by a Postal
+ Service to identify a postal service zones, such as the southern
+ quadrant of a city (e.g., "22180"). Each code is one value of this
+ multi-valued attribute.
( 2.5.4.17 NAME 'postalCode'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
-2.25 postOfficeBox
-
- This attribute contains the number that a Postal Service uses when a
- customer arranges to receive mail at a box on premises of the Postal
- Service.
+Dally Expires December 2003 [Page 11]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
+2.25 postOfficeBox
-Dally Expires October 2003 [Page 10]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ The postOfficeBox attribute type contains numbers that a Postal
+ Service uses when a customer arranges to receive mail at a box on
+ premises of the Postal Service (e.g., "Box 45"). Each number is one
+ value of this multi-valued attribute.
( 2.5.4.18 NAME 'postOfficeBox'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.26 preferredDeliveryMethod
- This attribute contains an indication of the preferred method of
- getting a message to the object.
+ The preferredDeliveryMethod attribute type contains an indication of
+ the preferred method of getting a message to the object. For example,
+ if mhs-delivery is preferred over telephone-delivery, which is
+ preferred over all other methods, the value of the value would
+ be {1, 9}.
( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.14
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
SINGLE-VALUE )
- The SYNTAX oid indicates the Delivery Method syntax.
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method
+ syntax [Syntaxes].
2.27 registeredAddress
- This attribute holds a postal address suitable for reception of
- telegrams or expedited documents, where it is necessary to have the
- recipient accept delivery.
+ The registeredAddress attribute type contains postal addresses
+ suitable for reception of telegrams or expedited documents, where it
+ is necessary to have the recipient accept delivery (e.g.,
+ "Receptionist, Widget Inc., 15 Main St., Ottawa, Canada"). Each
+ address is one value of this multi-valued attribute.
( 2.5.4.26 NAME 'registeredAddress'
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
- The SYNTAX oid indicates the Postal Address syntax.
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address
+ syntax [Syntaxes].
-2.28 roleOccupant
- A value of this Attribute Type is the Distinguished Name of an
- object (normally a person) that fulfills the responsibilities of a
- role object.
- ( 2.5.4.33 NAME 'roleOccupant'
- SUP distinguishedName )
-2.29 searchGuide
- This Attribute Type is for use by clients in constructing search
- filters. It is superseded by enhancedSearchGuide, described above
- in section 2.9.
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) ; Guide
+Dally Expires December 2003 [Page 12]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-The SYNTAX oid indicates the Guide syntax.
+2.28 roleOccupant
+ The roleOccupant attribute type contains the Distinguished Names of
+ objects(normally people) that fulfill the responsibilities of a role
+ object. For example, the role object, "cn=Human Resources Director,
+ ou=Position, o=Widget, Inc.", is fulfilled by two people whose
+ object names are "cn=Mary Smith, ou=employee, o=Widget, Inc." and
+ "cn=James Brown, ou=employee, o=Widget, Inc." Each name is one
+ value of this multi-valued attribute.
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+2.29 searchGuide
+ The searchGuide attribute type contains sets of information for use
+ by clients in constructing search filters. It is superseded by
+ enhancedSearchGuide, described above in section 2.9.
-Dally Expires October 2003 [Page 11]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+ 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
2.30 seeAlso
- A value of this Attribute Type is the Distinguished Name of an
- object that is related to the subject object.
+ The seeAlso attribute type contains Distinguished Names of objects
+ that are related to the subject object. For 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.". Each name is one value of this
+ multi-valued attribute.
- ( 2.5.4.34 NAME 'seeAlso'
+ ( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName )
2.31 serialNumber
- This attribute contains the serial number of a device.
+ The serialNumber attribute type contains the serial numbers of
+ devices (e.g., "WI-3005". Each number is one value of this
+ multi-valued attribute.
- ( 2.5.4.5 NAME 'serialNumber'
+ ( 2.5.4.5 NAME 'serialNumber'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String
+ syntax [Syntaxes].
+
+
+
+
+Dally Expires December 2003 [Page 13]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- The SYNTAX oid indicates the Printable String syntax.
2.32 sn
- This is the X.520 [X.520] surname Attribute Type, which contains the
- family name of a person.
+ The sn (surname)attribute type contains name strings for the family
+ names of a person (e.g., "Smith"). Each string is one value of this
+ multi-valued attribute. (Source: X.520)
( 2.5.4.4 NAME 'sn'
SUP name )
2.33 st
- This is the X.520 [X.520] stateOrProvinceName attribute, which
- contains the full name of a state or province.
+ The st (stateOrProvinceName) attribute type contains the full names
+ of states or provinces, (e.g. "California"). Each name is one value
+ of this multi-valued attribute.
( 2.5.4.8 NAME 'st'
SUP name )
2.34 street
- This is the X.520 [X.520] streetAddress attribute, which contains the
- physical address of the object to which the entry corresponds, such
- as an address for package delivery.
+ The street (streetAddress) attribute type contains physical
+ addresses of the object to which the entry corresponds, such as an
+ address for package delivery. Each address is one value of this
+ multi-valued attribute.
( 2.5.4.9 NAME 'street'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
2.35 telephoneNumber
- A value of this Attribute Type is a telephone number complying with
- ITU Recommendation E.123 [E.123].
-
-
-Dally Expires October 2003 [Page 12]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
+ The telephoneNumber attribute type contains telephone numbers
+ complying with ITU Recommendation E.123 [E.123]
+ (e.g., 1 234 567 8901) Each number is one value of this
+ multi-valued attribute.
( 2.5.4.20 NAME 'telephoneNumber'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
- The SYNTAX oid indicates the Telephone Number syntax.
+ 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number
+ syntax [Syntaxes].
2.36 teletexTerminalIdentifier
The withdrawal of Rec. F.200 has resulted in the withdrawal of this
attribute.
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
- The SYNTAX oid indicates the Teletex Terminal Identifier syntax.
+Dally Expires December 2003 [Page 14]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
2.37 telexNumber
- A value of this Attribute Type is a telex number, country code, and
- answerback code of a telex terminal.
+ The telexNumber attribute type contains sets of strings which are a
+ telex number, country code, and answerback code of a telex
+ terminal. Each set is one value of this multi-valued attribute.
( 2.5.4.21 NAME 'telexNumber'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
- The SYNTAX oid indicates the Telex Number syntax.
+ 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number
+ syntax [Syntaxes].
2.38 title
This attribute contains the title, such as "Vice President", of a
- person in their organizational context. The "personalTitle"
- attribute would be used for a person's title independent of their
- job function.
+ person in their organizational context.
( 2.5.4.12 NAME 'title'
SUP name )
-2.39 uniqueMember
+2.39 uid
- A value of this Attribute Type is the Distinguished Name of an
- object that is on a list or in a group, where the Relative
- Distinguished Name of the object includes a value that distinguishs
- between objects when a distinguished name has been reused.
+ The uid attribute type contains computer system login names
+ associated with the object. (Source: RFC 1274,
+ RFC 2798). Each name is one value of this multi-valued attribute.
+
+ ( 0.9.2342.19200300.100.1.1
+ NAME 'uid'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
+ syntax [Syntaxes].
+
+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 distinguishs
+ between objects when a distinguished name has been reused. For
+ example, if "ou=1st Battalion, o=Defense, c=US" is a battalion that
+ was disbanded, establishing a new battalion with the "same" name
+ would have a uid value added, resulting in
+ "ou=1st Battalion#'010101', o=Defense, c=US".
( 2.5.4.50 NAME 'uniqueMember'
EQUALITY uniqueMemberMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-The SYNTAX oid indicates the Name and Optional UID syntax.
-
-
+Dally Expires December 2003 [Page 15]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-Dally Expires October 2003 [Page 13]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
+ syntax [Syntaxes].
+2.41 userPassword
-2.40 userPassword
+ The userPassword attribute type contains character strings that are
+ known only to the user and the system to which the user has access.
+ Each string is one value of this multi-valued attribute.
- A value of this Attribute Type is a character string that is known
- only to the user and the system to which the user has access.
+ The application SHOULD prepare textual strings used as passwords by
+ transcoding them to Unicode, applying SASLprep [SASLprep], and
+ encoding as UTF-8.
( 2.5.4.35 NAME 'userPassword'
EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
- The SYNTAX oid indicates the Octet String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String
+ syntax [Syntaxes].
Passwords are stored using an Octet String syntax and are not
encrypted. Transfer of cleartext passwords is strongly discouraged
confidentiality and may result in disclosure of the password to
unauthorized parties.
-2.41 x121Address
+ An example of a need for multiple values in the userPassword
+ attribute is an environment where every month the user was expected
+ to use a different password generated by some automated system.
+ During transitional periods, like say 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.
- A value of this Attribute Type is a data network address as defined
- by ITU Recommendation X.121 [X.121].
+2.42 x121Address
+
+ The x121Address attribute type contains data network addresses
+ (e.g., 36111222333444555) as defined by ITU Recommendation X.121
+ [X.121]. Each address is one value of this multi-valued attribute.
( 2.5.4.24 NAME 'x121Address'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
-
- The SYNTAX oid indicates the Numeric String syntax.
-
-2.42 x500UniqueIdentifier
-
- The x500UniqueIdentifier Attribute Type is used to distinguish
- between objects when a distinguished name has been reused. In X.520
- [X.520], this Attribute Type is called uniqueIdentifier. This is a
- different Attribute Type from both the "uid" and "uniqueIdentifier"
- Attribute Types.
-
- ( 2.5.4.45 NAME 'x500UniqueIdentifier'
- EQUALITY bitStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- The SYNTAX oid indicates the Bit String syntax.
-
-
-
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String
+ syntax [Syntaxes].
+2.43 x500UniqueIdentifier
+ The x500UniqueIdentifier attribute type contains binary strings that
+ are used to distinguish between objects when a distinguished name
+ has been reused. Each string is one value of this multi-valued
+Dally Expires December 2003 [Page 16]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ attribute. In X.520 [X.520], this attribute type is called
+ uniqueIdentifier. This is a different attribute type from both the
+ "uid" and "uniqueIdentifier" attribute types.
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-Dally Expires October 2003 [Page 14]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String
+ syntax [Syntaxes].
3. Object Classes
LDAP servers SHOULD recognize all the Object Classes listed here as
- values of the objectClass attribute.
+ values of the objectClass attribute (see [Models]).
3.1 applicationProcess
- The applicationProcess Object Class definition is the basis of an
+ The applicationProcess object class definition is the basis of an
entry which represents an application executing in a computer system.
( 2.5.6.11 NAME 'applicationProcess'
3.2 country
- The country Object Class definition is the basis of an entry which
+ The country object class definition is the basis of an entry which
represents a country.
( 2.5.6.2 NAME 'country'
3.3 device
- The device Object Class is the basis of an entry which represents
- an appliance or computer or network element.
+ The device object class is the basis of an entry which represents an
+ appliance or computer or network element.
( 2.5.6.14 NAME 'device'
SUP top
STRUCTURAL
MUST cn
+
+
+Dally Expires December 2003 [Page 17]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
MAY ( serialNumber $
seeAlso $
owner $
l $
description ) )
-3.4 domain
+3.4 groupOfNames
- The domain Object Class is the basis of an entry which represents a
- portion of a network, as organized by DNS.
-
-
-Dally Expires October 2003 [Page 15]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- ( 0.9.2342.19200300.100.4.13 NAME 'domain'
- SUP top
- STRUCTURAL
- MUST dc
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description $ o $
- associatedName ) )
-
- An example entry would be:
-
- dn: dc=tcp,dc=critical-angle,dc=com
- objectClass: top
- objectClass: domain
- dc: tcp
- description: a placeholder entry used with SRV records
-
-3.5 groupOfNames
-
- The groupOfNames Object Class is the basis of an entry which
+ The groupOfNames object class is the basis of an entry which
represents a set of named objects including information related to
the purpose or maintenance of the set.
SUP top
STRUCTURAL
MUST ( member $
- cn )
+ cn )
MAY ( businessCategory $
seeAlso $
owner $
o $
description ) )
-3.6 groupOfUniqueNames
+3.5 groupOfUniqueNames
- The groupOfUniqueNames Object Class is the same as the groupOfNames
+ The groupOfUniqueNames object class is the same as the groupOfNames
object class except that the object names are not repeated or
reassigned within a set scope.
SUP top
STRUCTURAL
MUST ( uniqueMember $
- cn )
+ cn )
MAY ( businessCategory $
seeAlso $
-
-
-Dally Expires October 2003 [Page 16]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
owner $
ou $
o $
description ) )
-3.7 locality
+3.6 locality
- The locality Object Class is the basis of an entry which
- represents a place in the physical world.
+ The locality object class is the basis of an entry which represents
+ a place in the physical world.
( 2.5.6.3 NAME 'locality'
SUP top
STRUCTURAL
+
+
+Dally Expires December 2003 [Page 18]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
MAY ( street $
seeAlso $
searchGuide $
l $
description ) )
-3.8 organization
+3.7 organization
- The organization Object Class is the basis of an entry which
+ The organization object class is the basis of an entry which
represents a structured group of people.
( 2.5.6.4 NAME 'organization'
postalAddress $ physicalDeliveryOfficeName $ st $
l $ description ) )
-3.9 organizationalPerson
+3.8 organizationalPerson
- The organizationalPerson Object Class is the basis of an entry which
+ The organizationalPerson object class is the basis of an entry which
represents a person in relation to an organization.
( 2.5.6.7 NAME 'organizationalPerson'
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l ) )
+3.9 organizationalRole
-Dally Expires October 2003 [Page 17]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
-3.10 organizationalRole
-
- The organizationalRole Object Class is the basis of an entry which
+ The organizationalRole object class is the basis of an entry which
represents a job or function or position in an organization.
( 2.5.6.8 NAME 'organizationalRole'
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
+
+
+Dally Expires December 2003 [Page 19]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
internationaliSDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
-3.11 organizationalUnit
+3.10 organizationalUnit
- The organizationalUnit Object Class is the basis of an entry which
+ The organizationalUnit object class is the basis of an entry which
represents a piece of an organization.
( 2.5.6.5 NAME 'organizationalUnit'
telephoneNumber $ teletexTerminalIdentifier $ telexNumber $
userPassword $ x121Address ) )
-3.12 person
+3.11 person
- The person Object Class is the basis of an entry which represents a
+ The person object class is the basis of an entry which represents a
human being.
( 2.5.6.6 NAME 'person'
SUP top
STRUCTURAL
MUST ( sn $
- cn )
+ cn )
MAY ( userPassword $
telephoneNumber $
seeAlso $
description ) )
+3.12 residentialPerson
-
-
-
-
-Dally Expires October 2003 [Page 18]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
-3.13 residentialPerson
-
- The residentialPerson Object Class is the basis of an entry which
+ The residentialPerson object class is the basis of an entry which
includes a person's residence in the representation of the person.
( 2.5.6.10 NAME 'residentialPerson'
STRUCTURAL
MUST l
MAY ( businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $
- preferredDeliveryMethod $ street $ postOfficeBox $
- postalCode $ postalAddress $ physicalDeliveryOfficeName $
- st $ l ) )
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ preferredDeliveryMethod $ street $ postOfficeBox $
+
+
+
+Dally Expires December 2003 [Page 20]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ st $ l ) )
4. IANA Considerations
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
- Kathy Dally <kdally@mitre.org>
- Usage: (A = Attribute Type, O = Object Class) see comment
- Specification: RFC XXXX
+ Kathy Dally <kdally@mitre.org>
+ Usage: (A = attribute type, O = Object Class) see comment
+ Specification: RFC XXXX [editor's note: The RFC number will be
+ the one assigned to this document.
Author/Change Controller: IESG
-
-
-Dally Expires October 2003 [Page 19]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- Comments:
- The following descriptors (short names) should be updated to
- refer to RFC XXXX.
-
- NAME Type OID
- ------------------------ ---- ----------------------------
- applicationProcess O 2.5.6.11
- businessCategory A 2.5.4.15
- c A 2.5.4.6
- cn A 2.5.4.3
- country O 2.5.6.2
- dc A 0.9.2342.19200300.100.1.25
- description A 2.5.4.13
- destinationIndicator A 2.5.4.27
- device O 2.5.6.14
- distinguishedName A 2.5.4.49
- dnQualifier A 2.5.4.46
- domain O 0.9.2342.19200300.100.4.13
- enhancedSearchGuide A 2.5.4.47
- facsimileTelephoneNumber A 2.5.4.23
- generationQualifier A 2.5.4.44
- givenName A 2.5.4.42
- groupOfNames O 2.5.6.9
- groupOfUniqueNames O 2.5.6.17
- houseIdentifier A 2.5.4.51
- initials A 2.5.4.43
- internationalISDNNumber A 2.5.4.25
- l A 2.5.4.7
- locality O 2.5.6.3
- member A 2.5.4.31
- name A 2.5.4.41
- o A 2.5.4.10
- organization O 2.5.6.4
- organizationalPerson O 2.5.6.7
- organizationalRole O 2.5.6.8
- organizationalUnit O 2.5.6.5
- ou A 2.5.4.11
- owner A 2.5.4.32
- person O 2.5.6.6
- physicalDeliveryOfficeName A 2.5.4.19
- postalAddress A 2.5.4.16
- postalCode A 2.5.4.17
- postOfficeBox A 2.5.4.18
- preferredDeliveryMethod A 2.5.4.28
- registeredAddress A 2.5.4.26
- residentialPerson O 2.5.6.10
- roleOccupant A 2.5.4.33
- searchGuide A 2.5.4.14
- seeAlso A 2.5.4.34
- serialNumber A 2.5.4.5
- sn A 2.5.4.4
-
-
-Dally Expires October 2003 [Page 20]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- st A 2.5.4.8
- street A 2.5.4.9
- telephoneNumber A 2.5.4.20
- teletexTerminalIdentifier A 2.5.4.22
- telexNumber A 2.5.4.21
- title A 2.5.4.12
- uniqueMember A 2.5.4.50
- userPassword A 2.5.4.35
- x121Address A 2.5.4.24
- x500UniqueIdentifier A 2.5.4.45
+ Comments
+ In the LDAP descriptors registry, the following descriptors (short
+ names) should be updated to refer to RFC XXXX [editor's note: This
+ document].
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ applicationProcess O 2.5.6.11
+ businessCategory A 2.5.4.15
+ c A 2.5.4.6
+ cn A 2.5.4.3
+ country O 2.5.6.2
+ dc A 0.9.2342.19200300.100.1.25
+ description A 2.5.4.13
+ destinationIndicator A 2.5.4.27
+ device O 2.5.6.14
+ distinguishedName A 2.5.4.49
+ dnQualifier A 2.5.4.46
+ enhancedSearchGuide A 2.5.4.47
+ facsimileTelephoneNumber A 2.5.4.23
+ generationQualifier A 2.5.4.44
+ givenName A 2.5.4.42
+ groupOfNames O 2.5.6.9
+ groupOfUniqueNames O 2.5.6.17
+ houseIdentifier A 2.5.4.51
+ initials A 2.5.4.43
+ internationalISDNNumber A 2.5.4.25
+ l A 2.5.4.7
+ locality O 2.5.6.3
+ member A 2.5.4.31
+ name A 2.5.4.41
+ o A 2.5.4.10
+
+
+Dally Expires December 2003 [Page 21]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ organization O 2.5.6.4
+ organizationalPerson O 2.5.6.7
+ organizationalRole O 2.5.6.8
+ organizationalUnit O 2.5.6.5
+ ou A 2.5.4.11
+ owner A 2.5.4.32
+ person O 2.5.6.6
+ physicalDeliveryOfficeName A 2.5.4.19
+ postalAddress A 2.5.4.16
+ postalCode A 2.5.4.17
+ postOfficeBox A 2.5.4.18
+ preferredDeliveryMethod A 2.5.4.28
+ registeredAddress A 2.5.4.26
+ residentialPerson O 2.5.6.10
+ roleOccupant A 2.5.4.33
+ searchGuide A 2.5.4.14
+ seeAlso A 2.5.4.34
+ serialNumber A 2.5.4.5
+ sn A 2.5.4.4
+ st A 2.5.4.8
+ street A 2.5.4.9
+ telephoneNumber A 2.5.4.20
+ teletexTerminalIdentifier A 2.5.4.22
+ telexNumber A 2.5.4.21
+ title A 2.5.4.12
+ uid A 0.9.2342.19200300.100.1.1
+ uniqueMember A 2.5.4.50
+ userPassword A 2.5.4.35
+ x121Address A 2.5.4.24
+ x500UniqueIdentifier A 2.5.4.45
5. Security Considerations
underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties.
- It is required that strong authentication be performed in order to
- modify directory entries using LDAP.
+ Multiple attribute values for the userPassword needs to be used with
+ care. Especially reset/deletion of a password by an admin without
+ knowing the old user password gets tricky or impossible if multiple
+ values for different applications are present.
+
+ Certainly, applications which intend to replace the userPassword
+ value(s) with new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). Additionally, server
+
+
+
+Dally Expires December 2003 [Page 22]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ implementations are encouraged to provide administrative controls
+ which, if enabled, restrict the userPassword attributer to one value.
+
+ Note that when used for authentication purposes [AuthMeth], the user
+ need only prove knowledge of one of the values, not all of
+ the values.
6. Acknowledgements
The definitions, on which this document is based, have been developed
by committees for telecommunications and international standards.
- No new attribute definitions have been added.
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
product of the IETF ASID Working Group.
+ The dc attribute type definition in this document supercedes the
+ specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad,
+ R. Huber, and S. Sataluri.
+
+ The uid attribute type definition in this document supercedes the
+ specification of the userid in RFC 1274 by P. Barker and S. Kille
+ and of the uid in RFC 2798 by M. Smith.
+
This document is based upon input of the IETF LDAPBIS working group.
The author wishes to thank S. Legg and K. Zeilenga for their
significant contribution to this update.
[E.164] The international public telecommunication numbering plan,
ITU-T Recommendation E.164, 1997
-
-
-Dally Expires October 2003 [Page 21]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
[ISO3166] ISO 3166, "Codes for the representation of names of
countries".
- [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
- PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in
- progress)
-
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
models-xx (a work in progress)
+ [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, November 1987
+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
- [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002
+
+
+
+Dally Expires December 2003 [Page 23]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ [RFC3490] Faltstrom P., Hoffman P., Costello A. "Internationalizing
+ Domain Names in Applications (IDNA)", RFC 3490, March 2003
...[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx (a work in progress)
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-xx (a work in progress)
+ [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
7.2 Informative
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
- Sataluri, S., "Using Domains in LDAP/X.500 Distinguished Names",
- RFC 2247, January 1998
-
-
+ [AUTHMETH] Harrison R., "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms", draft-ietf-
+ ldapbis-authmeth-xx (a work in progress)
+ [F.1] Operational Provisions For The International Public Telegram
+ Service Transmission System, CCITT Recommmendation F.1, 1992
+ [F.31] Telegram Retransmission System, CCITT Recommendation
+ F.31, 1988
+ [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
+ PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in
+ progress)
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
+ Sataluri, S., "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998
+ [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002
+ [SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
+ names and passwords", draft-ietf-sasl-saslprep-xx (a
+ work in progress)
+ [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
-Dally Expires October 2003 [Page 22]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Dally Expires December 2003 [Page 24]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
8. Author's Address
Kathy Dally
The MITRE Corp.
- 1575 Colshire Dr., H300
+ 7515 Colshire Dr., H300
McLean VA 22102
USA
-Dally Expires October 2003 [Page 23]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+Dally Expires December 2003 [Page 25]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
Appendix A Changes RFC 2256
This appendix lists the changes that have been made from RFC 2256 to
this I-D.
- 1. Revised the Status of this Memo.
+ 1. Replaced the document title.
2. Removed the IESG Note.
3. Dependencies on RFC 1274 have been eliminated.
- 4. Added a Security Considerations section, requiring strong
- authentication in order to modify directory entries.
+ 4. Added a Security Considerations section.
5. Deleted the conformance requirement for subschema object
classes in favor of a statement in [Syntaxes].
- 6. Added a Table of Contents.
-
- 7. Added explanations to many attributes.
+ 6. Added explanations to many attribute types and to each object
+ class.
- 8. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
(moved to [Syntaxes]).
- 9. Reordered Section 3, Attributes, and Section 4, Object
- Classes, alphabetically.
-
- 10. Added an explanation for each object class.
-
- 11. Removed the certificate-related Attribute Types:
+ 8. Removed the certificate-related attribute types:
authorityRevocationList,
cACertificate,
certificateRevocationList,
strongAuthenticationUser, and
userSecurityInformation
- Noted that they are covered in PKIX WG documents.
+ LDAP PKI is now discussed in [LDAP-PKI].
+
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
+
+ 10. Deleted the aliasedObjectName and objectClass attribute
+ type definitions. Deleted the alias and top object class
+ definitions. They are included in [Models].
+
+ 11. Added the 'dc' attribute type from RFC 2247.
+
+
+
+
+Dally Expires December 2003 [Page 26]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+
+
+ 12. Added an IANA Considerations section.
+
+ 13. Numerous edititorial changes.
+
+
+
+
- 12. Removed the dmdName Attribute Type and dmd Object Class
- because they are not in the version of X.500 which
- is referenced.
-Dally Expires October 2003 [Page 24]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-......13. Deleted the 'aliasedObjectName' and 'objectClass' attribute
- type definitions. They are included in [Models].
- 14. Deleted the 'alias' and 'top' object class definitions. They
- are included in [Models].
- 15. Replaced the document title.
- 16. Added the 'dc' attribute and the 'domain' object class from
- RFC 2247.
- 17. Deleted the 'knowledgeInformation', 'presentationAddress',
- 'protocolInformation', and 'supportedApplicationContext'
- attributes.
- 18. Deleted the 'applicationEntity' and 'dSA' object classes.
- 19. Added an IANA Considerations section.
-Dally Expires October 2003 [Page 25]
+Dally Expires December 2003 [Page 27]
+++ /dev/null
-
-
-Internet Draft R. Megginson, Editor
-Document: <draft-ietf-ldup-lcup-03.txt> M. Smith
-Category: Proposed Standard Netscape
- Communications Corp.
- O. Natkovich
- Yahoo
- J. Parham
- Microsoft Corporation
- June 2002
-
-
- LDAP Client Update Protocol
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [1].
-
- 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.
-
-1. Abstract
-
- This document defines the LDAP Client Update Protocol (LCUP). The
- protocol is intended to allow an LDAP client to synchronize with the
- content of a directory information tree (DIT) stored by an LDAP
- server and to be notified about the changes to that content.
-
-
-2. Conventions used in this document
-
- In the protocol flow definition, the notation C->S and S->C
- specifies the direction of the data flow from the client to the
- server and from the server to the client respectively.
-
- 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
- [KEYWORDS].
-
-
-3. Overview
-
-\f
-
-
- The LCUP protocol is intended to allow LDAP clients to synchronize
- with the content stored by LDAP servers.
-
- The problem areas addressed by the protocol include:
-
- - mobile clients that maintain a local read-only copy of the
- directory data. While off-line, the client uses the local copy of
- the data. When the client connects to the network, it
- synchronizes with the current directory content and can be
- optionally notified about the changes that occur while it is on-
- line. For example, a mail client can maintain a local copy of the
- corporate address book that it synchronizes with the master copy
- whenever the client gets connected to the corporate network.
-
- - applications intending to synchronize heterogeneous data stores.
- A meta directory application, for instance, would periodically
- retrieve a list of modified entries from the directory, construct
- the changes and apply them to a foreign data store.
-
- - clients that need to take certain actions when a directory entry
- is modified. For instance, an electronic mail repository may want
- to perform a "create mailbox" task when a new person entry is
- added to an LDAP directory and a "delete mailbox" task when a
- person entry is removed.
-
- The problem areas not being considered:
-
- - directory server to directory server synchronization. The IETF is
- developing a LDAP replication protocol, called [LDUP], which is
- specifically designed to address this problem area.
-
- There are currently several protocols in use for LDAP client server
- synchronization. While each protocol addresses the needs of a
- particular group of clients (e.g., on-line clients or off-line
- clients) none satisfies the requirements of all clients in the
- target group. For instance, a mobile client that was off-line and
- wants to become up to date with the server and stay up to date while
- connected can't be easily supported by any of the existing
- protocols.
-
- Several features of the protocol distinguish it from LDUP
- replication. LCUP is designed such that the server does not need to
- maintain state information on behalf of the client. The clients are
- responsible for storing the information about how up to date they
- are with respect to the server's content. LCUP design avoids the
- need for LCUP-specific update agreements to be made between client
- and server prior to LCUP use. The client decides when and from where
- to retrieve the changes. LCUP design requires clients to initiate
- the update session and "pull" the changes from server.
-
- LCUP operations are subject to administrative and access
- control policies enforced by the server.
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 2
-\f
-
-
- A part of the DIT which is enabled for LCUP is referred to as an
- LCUP Context. A server may support one or more LCUP Contexts.
-
-4. Protocol Specification
-
- This section describes the protocol elements and the protocol flow.
-
-4.1 Universally Unique Identifiers
-
- Distinguished names can change, so are therefore unreliable
- as identifiers. The server SHOULD assign a Universally Unique
- Identifier (or UUID for short) to each entry as it is created. This
- identifier will be stored as an operational attribute of the entry,
- named `entryUUID'. The entryUUID attribute is single valued. A
- consistent algorithm for generating such universally unique
- identifiers may be standardized at some point in the future.
- The definition of the entryUUID attribute type, written using the
- BNF form of AttributeDescription described in RFC 2252 [RFC2252] is:
-
- ( OID-To-Be-Specified
- NAME `entryUUID'
- DESC `universally unique entry identifier'
- EQUALITY caseIgnoreMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
-4.2 LCUP Cookie Value
-
- The LCUP protocol uses a cookie to hold the state of the client's
- data with respect to the server's data. The LCUP Cookie is a value
- of the following ASN.1 type:
-
- LCUPCookie ::= SEQUENCE {
- scheme LDAPOID,
- value OCTET STRING OPTIONAL
- }
-
- scheme - this is the OID which identifies the format of the value.
- The scheme OID, like all object identifiers, MUST be unique for a
- given cookie scheme. The cookie value may be opaque or it may be
- exposed to LCUP clients. For cookie schemes that expose their
- value, the preferred form of documentation is an RFC. It is
- expected that there will be one or more standards track cookie
- schemes where the value format is exposed and described in detail.
-
- value - this is the actual data describing the state of the
- client's data. This value may be opaque, or its value may have
- some well-known format, depending on the scheme. The cookie value
- MUST be included except when a client has no stored state; i.e.,
- when the client is requesting a full synchronization. When the
- server sends back a cookie, the cookie value MUST be present.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 3
-\f
-
-
- Further uses of the LCUP Cookie value are described below.
-
-4.3 Additional LDAP Result Codes defined by LCUP
-
- The LDAP result code names and numbers defined in the following
- table are to be replaced with IANA assigned result code names and
- numbers per draft-ietf-ldapbis-iana-xx.txt.
-
- lcupResourcesExhausted (TBD) the server is running out of
- resources
- lcupSecurityViolation (TBD) the client is suspected of malicious
- actions
- lcupInvalidCookie (TBD) invalid cookie was supplied by the
- client - both/either the scheme
- and/or the value part was invalid
- lcupUnsupportedScheme (TBD) The scheme part of the cookie is a
- valid OID but is not supported by
- this server
- lcupClientDisconnect (TBD) client requested search termination
- using the LDAP Cancel extended
- operation request [CANCEL]
- lcupReloadRequired (TBD) indicates that client data needs to
- be reinitialized. This reason is
- returned if the server does not
- contain sufficient information to
- synchronize the client or if the
- server's data was reloaded since the
- last synchronization session
-
- The uses of these codes are described below.
-
-4.4 Client Update Control Value
-
- A client initiates a synchronization session with a server by
- attaching a clientUpdate control to an LDAP searchRequest message.
- The client SHOULD specify entryUUID in the attributes list in the
- searchRequest message. The search specification determines the part
- of the directory information tree (DIT) the client wishes to
- synchronize with, the set of attributes it is interested in and the
- amount of data the client is willing to receive. The clientUpdate
- control contains the client's synchronization specification. The
- controlType field for the clientUpdate control is
- ClientUpdateControlOID (to be assigned). The controlValue is an
- OCTET STRING, whose contents are the bytes of the BER encoding of
- the following:
-
-
-
-
-
-
-
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 4
-\f
-
-
- ClientUpdateControlValue ::= SEQUENCE {
- updateType ENUMERATED {
- synchronizeOnly (0),
- synchronizeAndPersist (1),
- persistOnly (2) },
- sendCookieInterval INTEGER OPTIONAL,
- cookie LCUPCookie OPTIONAL
- }
-
- updateType - specifies the type of update requested by the client
-
- synchronizeOnly - the server sends all the data needed to
- synchronize the client with the server, then closes the
- connection
-
- synchronizeAndPersist - the server sends all the data needed to
- synchronize the client with the server, then leaves open the
- connection, sending to the client any new added, modified, or
- deleted entries that satisfy the search criteria.
-
- persistOnly - the server does not synchronize the data with the
- client but leaves open the connection and sends over any new
- added, modified, or deleted entries that satisfy the search
- criteria.
-
- sendCookieInterval û (optional) the server SHOULD send the cookie
- back in the entryUpdate control value for every
- sendCookieInterval number of SearchResultEntry PDUs returned to
- the client. For example, if the value is 5, the server SHOULD
- send the cookie back in the entryUpdate control value for every 5
- search results returned to the client. If this value is absent,
- zero or less than zero, the server chooses the interval.
-
- cookie - a value that represents the current state of the client's
- data. If a cookie is provided, the server MUST use the enclosed
- scheme throughout the duration of the LCUP session or until an
- LCUP context boundary is crossed, since a new cookie may be
- required in that case. If the value or scheme part of the cookie
- is invalid, the server MUST return immediately with a
- SearchResultDone message with the resultCode set to the value of
- lcupInvalidCookie. If the scheme part of the cookie is a valid
- OID, but is not supported, the server MUST return immediately
- with a SearchResultDone message with the resultCode set to the
- value of lcupUnsupportedScheme.
-
- If the cookie is omitted, the server MAY use any scheme it
- supports.
-
-4.5 Entry Update Control Value
-
- In response to the client's synchronization request, the server
- returns one or more SearchResultEntry PDU that fits the client's
- specification. Each SearchResultEntry PDU also contains an
- entryUpdateControl that describes the LCUP state of the returned
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 5
-\f
-
-
- entry. To represent a deleted entry, the server attaches an
- entryUpdate control to the corresponding SearchResultEntry. The
- SearchResultEntry corresponding to a deleted entry MUST contain a
- valid DN and SHOULD contain a valid UUID but, to reduce the amount
- of data sent to the client, it SHOULD not contain any other
- attributes.
-
- Furthermore, the server may elect to periodically return to the
- client the cookie that represents the state of the client's data.
- This information is useful in case the client crashes or gets
- disconnected. The client MAY specify how often to receive the cookie
- by the use of the sendCookieInterval in the clientUpdate control
- value (see above). If the client does not specify a value, the
- server will determine the interval.
-
- The controlType field for the entryUpdate control is
- EntryUpdateControlOID (to be assigned). The controlValue is an
- OCTET STRING, whose contents are the bytes of the BER encoding of
- the following:
-
- EntryUpdateControlValue ::= SEQUENCE {
- stateUpdate BOOLEAN,
- entryDeleted BOOLEAN,
- cookie LCUPCookie OPTIONAL
-
- }
-
- stateUpdate - if set to TRUE, indicates that the entry to which the
- control is attached contains no changes and it is sent only to
- communicate to the client the new cookie. In this case, the
- entryDeleted field MUST be ignored and the cookie field MUST
- contain the updated cookie. This feature allows updating the
- client's cookie when there are no changes that effect the
- client's data store. Note that the control MUST be attached to a
- valid SearchResultEntry, which should contain a valid LDAPDN in
- the objectName field, and MAY contain an entryUUID attribute, but
- SHOULD NOT contain any other attributes. The server MAY send the
- entry named by the baseObject from the client's search request.
-
- entryDeleted - if set to TRUE, indicates that the entry to which
- the control is attached was deleted. The server MAY also set
- this to TRUE if the entry has left the client's search result
- set. As far as the client is concerned, a deleted entry is no
- different than an entry that has left the result set.
-
- cookie - the LCUP cookie value that represents the current state of
- the client's data.
-
-4.6 Client Update Done Control Value
-
- When the server has finished processing the client's request, it
- attaches a clientUpdateDone control to the SearchResultDone message
- and sends it to the client. However, if the SearchResultDone message
- contains a resultCode that is not success or lcupClientDisconnect,
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 6
-\f
-
-
- the clientUpdateDone control MAY be omitted. The controlType field
- for the clientUpdateDone control is ClientUpdateDoneControlOID (to
- be assigned). The controlValue is an OCTET STRING, whose contents
- are the bytes of the BER encoding of the following:
-
- ClientUpdateDoneControlValue ::= SEQUENCE {
- cookie LCUPCookie OPTIONAL
- }
-
- cookie - the LCUP cookie value that represents the current state of
- the client's data. Although this value is OPTIONAL, it MUST be set
- in the ClientUpdateDoneControlValue if the SearchResultDone
- resultCode is success or lcupClientDisconnect. This provides a
- good "checksum" of what the server thinks the state of the client
- is. If some error occurred, either an LDAP search error (e.g.
- insufficientAccessRights) or an LCUP error (e.g.
- lcupUnsupportedScheme), the cookie MAY be omitted.
-
- If server resources become tight, the server can terminate one or
- more search operations by sending a SearchResultDone message to the
- client(s) with a resultCode of lcupResourcesExhausted. Unless the
- client sets the updateType field to persistOnly, the server attaches
- a clientUpdateDone control that contains the cookie that corresponds
- to the current state of the client's data. A server set policy is
- used to decide which searches to terminate. This can also be used as
- a security mechanism to disconnect clients that are suspected of
- malicious actions, but if the server can infer that the client is
- malicious, the server should return lcupSecurityViolation instead.
-
-4.7 Client Initiated Termination
-
- If the client needs to terminate the synchronization process and it
- wishes to obtain the cookie that represents the current state of its
- data, it issues an LDAP Cancel operation [CANCEL]. The server
- responds immediately with a LDAP Cancel response [CANCEL]. The
- server MAY send any pending SearchResultEntry PDUs if the server
- cannot easily abort or remove those search results from its outgoing
- queue. The server SHOULD send as few of these remaining
- SearchResultEntry PDUs as possible. Finally, the server sends the
- message SearchResultDone with the clientUpdateDone control attached.
-
- If the client is not interested in the state information, it can
- simply abandon the search operation or disconnect from the server.
-
-4.8 Protocol Flow
-
- The client server interaction can proceed in three different ways
- depending on the client's requirements. Protocol flows beginning
- with an asterisk (*) are optional or conditional.
-
- If the client's intent is not to synchronize data but to trigger
- actions in response to directory modifications, the protocol
- proceeds as follows:
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 7
-\f
-
-
- C->S Sends a search operation with a clientUpdate control attached.
- The search specification determines the part of the DIT the
- client wishes to synchronize with and the set of attributes it
- is interested in. The updateType field of the control value
- should be set to persistOnly.
- *S->C If there is an error (invalid search scope, invalid cookie)
- the server returns the appropriate error codes and terminates
- the request (SearchResultDone message with optional
- clientUpdateDone control)
- S->C Sends change notification to the client for each change to the
- data within the client's search specification. Each
- SearchResultEntry may have an entryUpdate control attached.
- *S->C If the server starts to run out of resources or the client is
- suspected of malicious actions, the server SHOULD terminate
- the search operation by sending to the client a
- SearchResultDone message with optional clientUpdateDone
- control attached. The resultCode in the SearchResultDone
- mesasge SHOULD be set to lcupResourcesExhausted or
- lcupSecurityViolation depending on the reason for termination.
- *C->S If the client receives lcupResourcesExhausted error from the
- server, it MUST wait for a while before attempting another
- synchronization session with the server. It is RECOMMENDED
- that clients use an exponential backoff strategy.
- C->S The client terminates the search. The client can do this by
- abandoning the search operation, disconnecting from the
- server, or by sending an LDAP Cancel operation.
- *S->C If the server receives the LDAP Cancel op, it will immediately
- send back the LDAP Cancel response
- *S->C If the server sent the LDAP Cancel response, the server MAY
- send any pending SearchResultEntry PDUs in its outgoing queue
- *S->C If the server sent the LDAP Cancel response, after the server
- sends the response and any pending SearchResultEntry PDUs, the
- server sends the SearchResultDone message with the
- clientUpdateDone control attached. The resultCode in the
- SearchResultDone message will be either lcupClientDisconnect
- or some LDAP error code (not success).
- S->C Stops sending changes to the client and closes the connection.
-
- If the client's intent is to synchronize with the server and then
- disconnect, the protocol proceeds as follows:
-
- C->S Sends a search operation with the clientUpdate control
- attached. The search specification determines the part of the
- DIT the client wishes to synchronize with, the set of
- attributes it is interested in and the amount of data the
- client is willing to receive. If this is the initial
- synchronization session, the client either does not provide a
- cookie or provides a cookie with no value; otherwise, the
- cookie field of the control is set to the cookie received from
- the server at the end of the last synchronization session. If
- the scheme field of the cookie was provided, the server MUST
- use that scheme throughout the duration of the LCUP session or
- until an LCUP boundary is crossed, since the server will
- usually require a different cookie in that case anyway. (Note
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 8
-\f
-
-
- that the client can synchronize with different servers during
- different synchronization sessions.) The updateType field of
- the control value is set to synchronizeOnly.
- *S->C If there is an error (invalid search scope, invalid cookie)
- the server returns the appropriate error codes and terminates
- the request (SearchResultDone message with optional
- clientUpdateDone control)
- *S->C If no cookie is specified in the clientUpdate control, or if
- the value field of the cookie is empty, the server sends all
- data that matches the client's search specification followed
- by the SearchResultDone message with a clientUpdateDone
- control attached. The control contains the cookie that
- corresponds to the current state of the client's data. If
- synchronization was successful, the resultCode in the
- SearchResultDone message should be success.
- *S->C If an invalid cookie is specified, the server sends the
- SearchResultDone message with the resultCode set to
- lcupInvalidCookie.
- *S->C If a valid cookie is specified and the data that matches the
- search specification has been reloaded or the server does not
- contain enough state information to synchronize the client,
- the server sends a SearchResultDone message with the
- resultCode set to lcupReloadRequired.
- *S->C If the cookie is valid and the client is up to date, the
- server sends a success response to the client.
- S->C If the cookie is valid and there is data to be sent, the
- server sends the modified entries to the client. Each
- SearchResultEntry contains the attributes requested by the
- client in the search specification regardless of whether they
- were modified. An entryUpdate control with the entryDeleted
- field set to TRUE MUST be attached to every deleted entry. The
- server may also periodically attach an entryUpdate control to
- the entries sent to the client to indicate the current state
- of the client's data. In that case, the cookie field of the
- control represents the state of the client's data including
- the entry to which the control is attached. Once all the
- changes are sent successfully, the server sends a
- SearchResultDone with the clientUpdateDone control attached.
- The control contains the cookie that represents the current
- state of the client's data. The resultCode in the
- SearchResultDone message is set to success. If the resultCode
- is not success, the server may OPTIONALLY attach the
- clientUpdateDone control to the SearchResultDone message.
- The client stores the cookie received from the server until
- the next synchronization session.
- *C->S If the resultCode in the SearchResultDone message is set
- lcupReloadRequired, the client clears its data store and
- repeats the synchronization process by sending the search
- operation with clientUpdate control that contains no cookie,
- or that contains a cookie with no value field.
-
- If the client's intent is to be synchronized with the server and
- stay notified about data modifications, the protocol proceeds as
- follows:
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 9
-\f
-
-
-
- C->S The client behaves exactly as in the previous case except it
- sets the updateType field in the control value to
- synchronizeAndPersist.
- S->C The server behaves exactly as in the previous case except the
- connection is kept open after the initial set of changes is
- sent to the client. A SearchResultDone message is not sent to
- the client; instead, the server keeps sending changes to the
- client.
- *S->C If the server starts to run out of resources or the client is
- suspected of malicious actions, the server SHOULD terminate
- the search operation by sending to the client a
- SearchResultDone message with the resultCode set to
- lcupResourcesExhausted or lcupSecurityViolation depending on
- the reason for termination.
- *C->S If the client receives lcupResourcesExhausted error from the
- server, it MUST wait for a while before attempting another
- synchronization session with the server. We recommend
- exponential backoff strategy.
- C->S Sends an LDAP Cancel operation to the server to terminate the
- synchronization session.
- S->C Responds with an LDAP Cancel response, followed optionally by
- SearchResultEntry PDUs, followed by a SearchResultDone with
- the clientUpdateDone control optionally attached. If the
- control is present, it contains the cookie that represents the
- current state of the client's data. The value of the
- resultCode in the SearchResultDone message will be either
- lcupClientDisconnect or some other LDAPResult resultCode (not
- success). The control may not be present if some error
- occurred.
-
-4.9 Size and Time Limits
-
- The search request size or the time limits can only be imposed for
- non-persistent operations, those that set the updateType field of
- the ClientUpdateControlValue to synchronizeOnly (for the entire
- operation) or synchronizeAndPersist (for the initial synchronization
- phase only). All other operations MUST set both limits to 0. The
- server SHOULD ignore the limits set for persistent operations.
-
-4.10 Changes vs. Operations
-
- A server that supports UUIDs SHOULD communicate a modifyDN
- operation by sending the client the current form of the entry (with
- its new DN) along with an entryUUID attribute. A server that does
- not support UUIDs SHOULD communicate a modifyDN operation by sending
- the client a deletion for the previous DN followed by an entry for
- the new DN. Note that for servers that do not support UUIDs, no
- guarantees are made about the correctness of the client state in the
- presence of modifyDN operations.
-
- Communicating modifyDN operations by sending a delete of the old DN
- followed by an entry with the new DN makes it impossible for an LCUP
- client to distinguish between a modifyDN operation, which is one
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 10
-\f
-
-
- atomic operation, and an delete operation followed by an add of a
- new entry. The loss of information about atomicity may cause
- problems for some LCUP clients. For example, when an entry is
- renamed, a client that manages resources such as a person's mailbox
- might delete the mailbox and everything in it instead of merely
- changing the name associated with the mailbox.
-
- Also note that regardless of how a modifyDN operation is
- communicated to the client, if the client state shows that the
- object that underwent the modifyDN operation was the root of a
- subtree, the client MUST infer that the DNs of all objects in the
- subtree have changed such that they reflect the new DN of the
- subtree root.
-
-4.11 Operations on the Same Connection
-
- It is permissible for the client to issue other LDAP operations on
- the connection used by the protocol. Since each LDAP
- request/response carries a message id there will be no ambiguity
- about which PDU belongs to which operation. By sharing the
- connection among multiple operations, the server will be able to
- conserve its resources.
-
-4.12 Interactions with Other LDAP Search and Response Controls
-
- LCUP defines neither restrictions nor guarantees about the ability
- to use the LDAP client update control defined in this document in
- conjunction with other LDAP controls, except for the following: A
- server MAY ignore non-critical controls supplied with the LCUP
- control. A server MAY ignore the LCUP control if it is non-critical
- and it is supplied with other critical controls. If a server
- receives a critical LCUP control with another critical control, and
- the server does not support both controls at the same time, the
- server SHOULD return unavailableCriticalExtension.
-
-5. Additional Features
-
- There are several features present in other protocols or considered
- useful by clients that are currently not included in the protocol
- primarily because they are difficult to implement on the server.
- These features are briefly discussed in this section. This section
- is intended to open a discussion on the merits of including and
- approaches to implementing these features.
-
-5.1 Triggered Search Change Type
-
- This feature is present in the Triggered Search specification. A
- flag is attached to each entry returned to the client indicating the
- reason why this entry is returned. The possible reasons from the
- draft are
- "- notChange: the entry existed in the directory and matched the
- search at the time the operation is being performed,
- - enteredSet: the entry entered the result,
- - leftSet: the entry left the result,
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 11
-\f
-
-
- - modified: the entry was part of the result set, was modified or
- renamed, and still is in the result set."
-
- The leftSet feature is particularly useful because it indicates to
- the client that an entry is no longer within the client's search
- specification and the client can remove the associated data from its
- data store. Ironically, this feature is the hardest to implement on
- the server because the server does not keep track of the client's
- state and has no easy way of telling which entries moved out of
- scope between synchronization sessions with the client.
-
- A compromise could be reached by only providing this feature for the
- operations that occur while the client is connected to the server.
- This is easier to accomplish because the decision about the change
- type can be made based only on the change without need for any
- historical information. This, however, would add complexity to the
- protocol.
-
-5.2 Persistent Search Change Type
-
- This feature is present in the Persistent Search specification.
- Persistent search has the notion of changeTypes. The client
- specifies which type of updates will cause entries to be returned,
- and optionally whether the server tags each returned entry with the
- type of change that caused that entry to be returned.
-
- For LCUP, the intention is full synchronization, not partial. Each
- entry returned by an LCUP search will have some change associated
- with it that may concern the client. The client may have to have a
- local index of entries by DN or UUID to determine if the entry has
- been added or just modified. It is easy for clients to determine if
- the entry has been deleted because the entryDeleted value of the
- entryUpdateControl will be TRUE.
-
-5.3 Sending Changes
-
- Some earlier synchronization protocols sent the client(s) only the
- modified attributes of the entry rather than the entire entry. While
- this approach can significantly reduce the amount of data returned
- to the client, it has several disadvantages. First, unless a
- separate mechanism (like the change type described above) is used to
- notify the client about entries moving into the search scope,
- sending only the changes can result in the client having an
- incomplete version of the data. Let's consider an example. An
- attribute of an entry is modified. As a result of the change, the
- entry enters the scope of the client's search. If only the changes
- are sent, the client would never see the initial data of the entry.
- Second, this feature is hard to implement since the server might not
- contain sufficient information to construct the changes based solely
- on the server's state and the client's cookie. On the other hand,
- this feature can be easily implemented by the client assuming that
- the client has the previous version of the data and can perform
- value by value comparisons.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 12
-\f
-
-
-5.4 Data Size Limits
-
- Some earlier synchronization protocols allowed clients to control
- the amount of data sent to them in the search response. This feature
- was intended to allow clients with limited resources to process
- synchronization data in batches. However, an LDAP search operation
- already provides the means for the client to specify the size limit
- by setting the sizeLimit field in the SearchRequest to the maximum
- number of entries the client is willing to receive. While the
- granularity is not the same, the assumption is that regular LDAP
- clients that can deal with the limitations of the LDAP protocol will
- implement LCUP.
-
-5.5 Data Ordering
-
- Some earlier synchronization protocols allowed a client to specify
- that parent entries should be sent before the children for add
- operations and children entries sent before their parents during
- delete operations. This ordering helps clients to maintain a
- hierarchical view of the data in their data store. While possibly
- useful, this feature is relatively hard to implement and is
- expensive to perform.
-
-6. Client Side Considerations
-
- Clients SHOULD always specify entryUUID in the SearchRequest
- attribute list.
-
- The cookie received from the server after a synchronization session
- can only be used with the same or more restrictive search
- specification than the search that generated the cookie. The server
- will reject the search operation with a cookie that does not satisfy
- this condition. This is because the client can end up with an
- incomplete data store otherwise. A more restrictive search
- specification is the one that generates a subset of the data
- produced by the original search specification.
-
- Because an LCUP client specifies the area of the tree with which it
- wishes to synchronize through the standard LDAP search
- specification, the client can be returned noSuchObject error if the
- root of the synchronization area was renamed between the
- synchronization sessions or during a synchronization session. If
- this condition occurs, the client can attempt to locate the root by
- using the root's UUID saved in client's local data store. It then
- can repeat the synchronization request using the new search base. In
- general, a client can detect that an entry was renamed and apply the
- changes received to the right entry by using the UUID rather than DN
- based addressing.
-
- Each active persistent operation requires that an open TCP
- connection be maintained between an LDAP client and an LDAP server
- that might not otherwise be kept open. Therefore, client
- implementors are encouraged to avoid using persistent operations for
- non-essential tasks and to close idle LDAP connections as soon as
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 13
-\f
-
-
- practical. The server may close connections if server resources
- become tight.
-
- The client MAY receive a continuation reference
- (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search
- request spans multiple parts of the DIT, some of which may require a
- different LCUP cookie, some of which may not even be managed by
- LCUP. The client SHOULD maintain a cache of the LDAP URLs returned
- in the continuation references and the cookies associated with them.
- The client is responsible for performing another LCUP search to
- follow the references, and SHOULD use the cookie corresponding to
- the LDAP URL for that reference (if it has a cookie).
-
- The client may receive a referral (Referral [RFC2251 SECTION
- 4.1.11]) when the search base is a subordinate reference, and this
- will end the operation.
-
- For alias dereferencing, the server will behave as if the client had
- requested neverDerefAliases or derefFindingBaseObj as the
- derefAliases field in the search request [RFC2251, Section 4.5.1].
- If the client specifies a value other than neverDerefAliases or
- derefFindingBaseObj, the server will return protocolError to the
- client.
-
- Changes to data (e.g., that might affect the LCUP client's filter or
- scope) or meta-data (e.g., that might affect the client's read
- access) may affect the presence of entries in the search set.
- Servers MAY notify LCUP clients of changes to the search set that
- result from such changes, but an LCUP client MUST NOT assume that
- such notification will occur. Therefore, in the case where a client
- is maintaining a cache of entries using LCUP, the data held by the
- client may be a superset or a subset of the entries that would be
- returned by a new search request. For example, if access control
- meta information is changed to deny access to particular entries in
- the search result set, and the access control information is outside
- of the search scope (e.g., in a parent entry), the client may have
- entries stored locally which are no longer part of its desired
- search set. Similarly, if entries are added to the search result
- set due to changes in meta-data, the client's cache of entries may
- not include these entries.
-
- Some clients may wish to perform an initial synchronization in order
- to prime a cache or establish a baseline set of entries, then look
- for changes after that. The recommended way to do this is to first
- issue an LCUP search with the updateType field of the clientUpdate
- control value set to synchronizeOnly, then after that search
- successfully completes, immediately issue an LCUP search with the
- updateType field of the clientUpdate control value set to
- synchronizeAndPersist.
-
- Some clients may have unreliable connections, for example, a
- wireless device or a WAN connection. These clients may want to
- insure that the cookie is returned often in the entryUpdate control
- value, so that if they have to reconnect, they do not have to
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 14
-\f
-
-
- process many redundant entries. These clients should set the
- sendCookieInterval in the clientUpdate control value to a low
- number, perhaps even 1. Also, some clients may have a limited
- bandwidth connection, and may not want to receive the cookie very
- often, or even at all (however, the cookie is always sent back in
- the clientUpdateDone control value upon successful completion).
- These clients should set the sendCookieInterval in the clientUpdate
- control value to a high number.
-
-7. Server Implementation Considerations
-
- Servers SHOULD support UUIDs. Otherwise, it will be very difficult
- to support modifyDN operations. Adding support for UUIDs should be
- seen as a necessary component of LCUP.
-
- By design, the protocol supports multiple cookie schemes. This is
- to allow different implementations the flexibility of storing any
- information applicable to their environment. A reasonable
- implementation for an LDUP compliant server would be to use the
- Replica Update Vector (RUV). For each master, RUV contains the
- largest CSN seen from this master. In addition, the RUV implemented
- by some directory servers (not yet in LDUP) contains replica
- generation - an opaque string that identifies the replica's data
- store. The replica generation value changes whenever the replica's
- data is reloaded. Replica generation is intended to signal the
- replication/synchronization peers that the replica's data was
- reloaded and that all other replicas need to be reinitialized. RUV
- satisfies the three most important properties of the cookie: (1) it
- uniquely identifies the state of client's data, (2) it can be used
- to synchronize with multiple servers, and (3) it can be used to
- detect that the server's data was reloaded.
-
- A server may support one or more LCUP cookie schemes. It is
- expected that schemes will be published along with their OIDs as
- RFCs. If a client initiates an LCUP session with a particular
- scheme, the server MUST use that same scheme throughout the LCUP
- session, or until an LCUP context boundary is crossed, in which case
- the server will usually require a different cookie anyway.
-
- In addition, the cookie must contain enough information to allow the
- server to determine whether the cookie can be safely used with the
- search specification it is attached to. As discussed earlier in the
- document, the cookie can only be used with the search specification
- that is equally or more restrictive than the one for which the
- cookie was generated.
-
- An implementation must make sure that it can correctly update the
- client's cookie when there is a size limit imposed on the search
- results by either the client's request or by the server's
- configuration. If RUV is used as the cookie, entries last modified
- by a particular master must be sent to the client in the order of
- their last modified CSN. This ordering guarantees that the RUV can
- be updated after each entry is sent.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 15
-\f
-
-
- The server's DIT may be partitioned into different sections which
- may have different cookies associated with them. For example, some
- servers may use some sort of replication mechanism to support LCUP.
- If so, the DIT may be partitioned into multiple replicas. A client
- may send an LCUP search request that spans multiple replicas. Some
- parts of the DIT spanned by the search request scope may be managed
- by LCUP and some may not. A part of the DIT which is enabled for
- LCUP is referred to as an LCUP Context. The server SHOULD send a
- SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
- for a returned entry changes. The server SHOULD return all entries
- for a particular LCUP Context before returning a reference to other
- LCUP Contexts or non-LCUP enabled parts of the DIT, in order to
- minimize the processing burden on the clients. The LDAP URL(s)
- returned MUST contain the DN(s) of the base of another section of
- the DIT (however the server implementation has partitioned the DIT).
- The client will then issue another LCUP search using the LDAP URL
- returned. Each section of the DIT MAY require a different cookie
- value, so the client SHOULD maintain a cache, mapping the different
- LDAP URL values to different cookies. If the cookie changes, the
- scheme may change as well, but the cookie scheme MUST be the same
- within a given LCUP Context.
-
- An implementation SHOULD notify the client about all entries deleted
- from the search set since the client's last session, but an LCUP
- client MUST NOT assume that such notification will occur. For
- example, the server might not notify the client of the deletion of
- an object if the object left the search set following the client's
- last synchronization and prior to the object's deletion. An LDUP
- compliant implementation can achieve this through the use of entry
- tombstones. The implementation should avoid aggressive tombstone
- purging since lack of tombstones would cause client's data to be
- reloaded. We suggest that only the tombstone content be removed
- during the regular trimming cycle while tombstones themselves are
- discarded much less frequently.
-
- The specification makes no guarantees about how soon a server should
- send notification of a changed entry to the client when the
- connection between the client and the server is kept open. This is
- intentional as any specific maximum delay would be impossible to
- meet in a distributed directory service implementation. Server
- implementors are encouraged to minimize the delay before sending
- notifications to ensure that clients' needs for timeliness of change
- notification are met.
-
- Implementors of servers that support the mechanism described in this
- document should ensure that their implementation scales well as the
- number of active persistent operations and the number of changes
- made in the directory increases. Server implementors are also
- encouraged to support a large number of client connections if they
- need to support large numbers of persistent operations.
-
-8. Synchronizing Heterogeneous Data Stores
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 16
-\f
-
-
- Clients, like a meta directory join engine, synchronizing multiple
- writable data stores will only work correctly if each piece of
- information is single mastered (for instance, only by an LDUP
- compliant directory). This is because different systems have
- different notions of time and different update resolution
- procedures. As a result, a change applied on one system can be
- discarded by the other, thus preventing the data stores from
- converging.
-
-9. Security Considerations
-
- In some situations, it may be important to prevent general exposure
- of information about changes that occur in an LDAP server.
- Therefore, servers that implement the mechanism described in this
- document SHOULD provide a means to enforce access control on the
- entries returned and MAY also provide specific access control
- mechanisms to control the use of the controls and extended
- operations defined in this document.
-
- As with normal LDAP search requests, a malicious client can initiate
- a large number of persistent search requests in an attempt to
- consume all available server resources and deny service to
- legitimate clients. The protocol provides the means to stop
- malicious clients by disconnecting them from the server. The servers
- that implement the mechanism SHOULD provide the means to detect the
- malicious clients. In addition, the servers SHOULD provide the means
- to limit the number of resources that can be consumed by a single
- client.
-
- Access control on the data can be modified in such a way that the
- data is no longer visible to the client. The specification does not
- specify how the server should handle this condition. Moreover, data
- consistency is not guaranteed if access control is changed from a
- more restrictive to a less restrictive one. This is because access
- control can be considered as an additional filter on the search
- specification and the protocol does not support going from a more to
- a less restrictive search specification. See Client Side
- Considerations Section for more detailed explanation of the problem.
-
-10. Normative References
-
- [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory
- Access Protocol", RFC 2251, December 1997.
-
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
-
- [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation",
- draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 17
-\f
-
-
-11. Acknowledgements
-
- The LCUP protocol is based in part on the Persistent Search Change
- Notification Mechanism defined by Mark Smith, Gordon Good, Tim
- Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined
- by Mark Wahl, and the LDAP Control for Directory Synchronization
- defined by Michael Armijo.
-
-12. Author's Addresses
-
- Rich Megginson
- Netscape Communications Corp.
- 901 San Antonio Rd.
- Palo Alto, CA 94303-4900
- Mail Stop SCA17 - 201
- Phone: +1 505 797-7762
- Email: richm@netscape.com
-
- Olga Natkovich
- Yahoo, Inc.
- 701 First Ave.
- Sunnyvale, CA 94089
- Phone: +1 408 349-6153
- Email: olgan@yahoo-inc.com
-
- Mark Smith
- Netscape Communications Corp.
- 901 San Antonio Rd.
- Palo Alto, CA 94303-4900
- Mail Stop SCA17 - 201
- Phone: +1 650 937-3477
- Email: mcs@netscape.com
-
- Jeff Parham
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
- Phone: +1 425 882-8080
- Email: jeffparh@microsoft.com
-
-13. Full Copyright Statement
- "Copyright (C) The Internet Society (date). 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
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 18
-\f
-
-
- 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.
-
-14. Appendix A - Summary of Changes
-
- Changes new to version 03:
-
- Emphasized the use of UUIDs throughout the document. Implementers
- are strongly encouraged to use UUIDs as a necessary component of
- the protocol.
-
- Removed the LCUP Cancel extended operation in favor of the new
- LDAP Cancel operation [CANCEL].
-
- Got rid of the lcupSuccess result code. All result codes will be
- added to the IANA LDAP result code registry as part of the LDAP
- standard. Also removed the result code and text from the client
- update done control value.
-
- Changed any and all wording suggesting an LCUP Context is related
- to a naming context. New text says an LCUP Context is a part of
- the DIT that supports LCUP, and that a server may have one or more
- LCUP Contexts.
-
- Removed Old Section 4.2: lcupCookieScheme
- We decided that LCUP did not need a discovery mechanism. The
- controls and extended operations will be published in the root DSE
- as per the LDAP standards.
-
- Changed references to "Unique Identifier" to either "Universally
- Unique Identifier" or "UUID".
-
- Added this text to section 6 "Client Side Considerations":
- "- The client may receive a referral (Referral [RFC2251 SECTION
- 4.1.11]) when the search base is a subordinate reference, and
- this will end the operation."
-
- Added a note to section 6 "Client Side Considerations" about how
- to establish a baseline set of entries or entry cache.
-
- Added the field sendCookieInterval to the clientUpdate control
- value.
-
- Added a note to section 6 "Client Side Considerations" explaining
- possible uses of the sendCookieInterval.
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 19
-\f
-
-
-
- Changes new to version 02:
-
- Section 4.2: The lcupCookieScheme operational attribute MUST be
- present in the root DSE, and MAY be present in entries. Each
- value of the attribute in the root DSE will be a list of OIDs of
- cookie schemes followed by the DN of the LCUP context which
- supports the schemes. The attribute value in the DIT entries will
- be the list of OIDs followed by the DN of the LCUP context.
-
- section 4.5 - the entry uuid is now MAY instead of MUST - if
- implementers do not wish to identify entries by a unique ID other
- than DN (which may not be unique), then so be it. For returned
- SearchResultEntry PDUs other than deleted entries, the client MAY
- request that the Unique Identifier attribute be returned by
- specifying it in the attribute list to be returned by the search
- request.
-
- section 4.5 - added "or the base DN of the client's search
- request." to the phrase. "The server MAY send the entry at the
- root of the client's tree, or the base DN of the client's search
- request." I think this clarifies which entry the client may
- search for.
-
- section 4.6 - the clientUpdateDone control is now optional for
- error conditions. Also, the cookie value of the control is now
- optional for lcup error conditions (e.g. not lcupSuccess or
- lcupClientDisconnect).
-
- Added section 4.12 - Interactions with Other LDAP Search and
- Response Controls
-
- Added blurb about alias dereferencing back to section 6:
- "For alias dereferencing, the server will behave as if the client
- had requested neverDerefAliases or derefFindingBaseObj as the
- derefAliases field in the search request [RFC2251, Section 4.5.1].
- If the client specifies a value other than neverDerefAliases or
- derefFindingBaseObj, the server will return protocolError to the
- client."
-
- Changed this in section 6:
- Because an LCUP client specifies the area of the tree with which
- it wishes to synchronize through the standard LDAP search
- specification, the client can be returned noSuchObject error if
- the root of the synchronization area was renamed between the
- synchronization sessions "or during a synchronization session"
-
- Changes new to version 01:
-
- The opaque cookie has been split into two parts - a scheme which
- is an OID, and a value. The value may or may not have a format
- known to the client, depending on the specified scheme. Section
- 4.2 describes the new cookie format and defines the LCUP Cookie
- Value.
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 20
-\f
-
-
-
- Added new section 4.3 - the lcupCookieScheme operational
- attribute.
-
- Changes new to version 00:
-
- Added the definition for Unique Identifier (basically copied from
- the LDUP model doc http://search.ietf.org/internet-drafts/draft-
- ietf-ldup-model-06.txt. I needed to add the definition here
- because LCUP needs a Unique Identifier but should not be dependent
- on LDUP.
-
- Removed all normative references to LDUP. I've left the
- implementation suggestions that refer to LDUP, but LCUP should not
- be dependent on LDUP.
-
- Cleaned up the protocol flows.
-
- Removed this text from section 4.8: "Clients MUST NOT issue
- multiple synchronization requests on the same connection. This is
- because the protocol includes an extended operation and it would
- be impossible to decide which synchronization session it belongs
- to." - This is no longer true, since the extended operation now
- includes the message ID of the search request.
-
- "Client Side Consideration" section - the client will never
- receive a referral or continuation reference
-
- Added section 12. Acknowledgements
-
- Removed normative references to documents not depended on.
-
- Removed explicit references to software vendors.
-
- Section 4.1 - Changed ClientUpdateControlValue to remove the
- keepConnection and changesOnly fields and replace them with
- updateType which is an ENUMERATED with three values:
- synchronizeOnly, synchronizeAndPersist, and persistOnly.
-
- Section 4.2 - The EntryUpdateControlValue fields stateUpdate and
- entryDeleted no longer have DEFAULT values, they must be specified
- - this eliminates any potential ambiguity.
-
- Added this text to the description of the entryDeleted field
- (section 4.2): "The server SHOULD also set this to TRUE if the
- entry has left the clients search result set. As far as the client
- is concerned, a deleted entry is no different than an entry which
- has left the result set."
- Section 4.2 - Added an explanation of the concept and requirement
- for the Unique Identifier.
-
- Section 4.4 - Added to the extended operation a request value
- containing the message id of the operation to stop.
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 21
-\f
-
-
- Updated contact information for Olga.
-
- Removed Michael Armijo and added Jeff Parham as an author.
-
- Changes new to previous version:
-
- "Authors" section - added Rich Megginson as the new editor.
-
- "Client Side Consideration" section - added a note and a question
- concerning referral and continuation reference handling.
-
- "Client Update Control Value" section (4.1) - clarified the meaning
- of keepConnection and added a table summarizing the effects of
- different values of keepConnection and changesOnly.
-
- "Stop Client Update Request and Response" - added section 4.4
- describing this extended operation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Megginson, et. al. Proposed Standard - Expires: December 2002 22
-\f
\ No newline at end of file
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
-Expires in six months 20 December 2002
+Expires in six months 26 October 2003
LDAP: Requesting Attributes by Object Class
- <draft-zeilenga-ldap-adlist-04.txt>
+ <draft-zeilenga-ldap-adlist-06.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions 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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
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 (2003). 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
Zeilenga Requesting Attributes by Object Class [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
1. Overview
[RFC2256].
This extension is intended to be used where the user is in direct
- control of the parameters of the LDAP search operation.
+ control of the parameters of the LDAP search operation, such as when
+ entering a LDAP URL [RFC2255] into a web browser.
+
+
+2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
-2. Return of all Attributes of an Object Class
+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]. For each
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+
+
be a DescriptionList described by the following ASN.1 [X.680] data
type:
The Description is string conforming to the ABNF [RFC2234]:
-
-
-Zeilenga Requesting Attributes by Object Class [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
-
-
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = "+" ObjectClass *( ";" options )
zero options in the attributes field of a SearchRequest. Other uses
may be defined in future specifications.
- Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
- [FEATURES] attribute in the root DSE.
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
+ [FEATURES] attribute in the root DSE. Clients supporting this feature
+ SHOULD NOT use the feature unless they have knowledge the server
+ supports it.
3. Security Considerations
4. IANA Considerations
- This OID 1.3.6.1.4.1.4203.1.11.2 to identify the LDAP "OC AD List?
- feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under
- its IANA-assigned private enterprise allocation [PRIVATE], for use in
- this specification.
+ The OID 1.3.6.1.4.1.4203.1.11.2 is used to identify the LDAP "OC AD
+ List" feature. 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 per BCP 64
+ Registration of this protocol mechanism is requested per BCP 64
[RFC3383].
- Subject: Request for LDAP Protocol Mechansism Registration
+
+
+Zeilenga Requesting Attributes by Object Class [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.5.2
Description: OC AD Lists
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
- Specification: RFCxxxx
+ Specification: RFC XXXX
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
-
-Zeilenga Requesting Attributes by Object Class [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
-
-
5. Author's Address
Kurt D. Zeilenga
6. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
- [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
- draft-zeilenga-ldap-features-xx.txt (a work in progress).
+ [FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt, a work in progress.
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", X.680, 1994.
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
7. Informative References
- [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
- September 2002.
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
+Zeilenga Requesting Attributes by Object Class [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December, 1997.
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
+ use with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
-Zeilenga Requesting Attributes by Object Class [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
+Full Copyright
-Copyright 2002, The Internet Society. All Rights Reserved.
+ 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
+ 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
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,
- 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.
-
-
-
-
-
-
-
-
-
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 11 May 2003
+Expires in six months 25 October 2003
The LDAP Assertion Control
- <draft-zeilenga-ldap-assert-00.txt>
+ <draft-zeilenga-ldap-assert-01.txt>
Status of this Memo
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 Working Group mailing list <ldapext@ietf.org>. Please send
- editorial comments directly to the author <Kurt@OpenLDAP.org>.
+ Extensions mailing list <ldapext@ietf.org>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
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 the assertion when applied to
- the target entry of the operation. It can be used to construct "test
- and set" and "test and clear" operations.
+ 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.
Zeilenga LDAP Assertion Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
1. Overview
This document defines the Lightweight Directory Access Protocol (LDAP)
[RFC3377] assertion control. The assertion control allows the client
- to specify a condition which allows the operation to be processed
- normally only when true. Otherwise the operation fails.
+ to specify a condition which must be true for the operation to be
+ processed normally. Otherwise the operation fails.
The control can be used with the Modify operation [RFC2251] to perform
- atomic "test and set" and "test and clear" operations as the the
- asserted condition is evaluated as an integral part the operation.
- The control may be attached to other update operations to support
- conditional add, delete, and renaming of objects.
+ 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 add,
+ delete, and renaming of objects.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
2. Terminology
- Protocol elements are described using ASN.1 [X.680]. 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].
+ 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].
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent (i.e., a directory server).
+ DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
- Servers implementing this technical specification SHOULD publish
- IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute
- [RFC2252] in their root DSE.
-
+ The control is appropriate for both LDAP interrogation and update
+ operations [RFC2251] 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.
Zeilenga LDAP Assertion Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
- The control is appropriate for both LDAP interrogation and update
- operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
- (rename), and Search. It is not appropriate for Abandon, Bind nor
- Unbind operations. Nor is it appropriate for the Start TLS [RFC2830]
- operation.
-
When the control is attached to an LDAP request, the processing of the
request is conditional on the evaluation of the Filter as applied
against the target of the operation. If the Filter evaluates to TRUE,
then the request is processed normally. If the Filter evaluates to
- FALSE, then assertionFailed (IANA-ASSIGNED-CODE) resultCode is
- returned and no further processing is performed.
+ FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
+ resultCode is returned and no further processing is performed.
For Add, Compare, and ModifyDN the target is indicated by the entry
field in the request. For Modify, the target is indicated by the
type. For the Compare operation and all update operations, the
evaluation of the assertion MUST be performed as an integral part of
the operation. That is, the evaluation of the assertion and the
- normal processing SHALL be done as one atomic action.
+ normal processing of the operation SHALL be done as one atomic action.
For search operation, the target is indicated by the baseObject field
and the evaluation is done after "finding" but before "searching"
[RFC2251]. Hence, if the evaluation fails, no entries or
continuations references are returned.
+ 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.
+
Other documents may specify how this control applies to other LDAP
- operations. In doing so, they must how the target entry is
+ operations. In doing so, they must state how the target entry is
determined.
-3. Security Considerations
+4. Security Considerations
- The filter may, like other values of the request, contain sensitive
- information. When so, this information should be appropriately
- protected.
+ The filter may, like other components of the request, contain
+ sensitive information. When so, this information should be
+ appropriately protected.
As with any general assertion mechanism, the mechanism can be used to
determine directory content. Hence, the mechanism SHOULD be subject
Zeilenga LDAP Assertion Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
-4. IANA Considerations
+5. IANA Considerations
-4.1. Object Identifier
+5.1. Object Identifier
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier [RFC3383] to identify the LDAP Assertion Control
- defined in this document.
+ It is requested that IANA assign upon Standards Action an LDAP Object
+ Identifier [RFC3383] 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:
Comments:
Identifies the LDAP Assertion Control
-4.2 LDAP Protocol Mechanism
+5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [RFC3383] is requested.
Comments: none
-4.3 LDAP Result Code
+5.3 LDAP Result Code
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
is requested.
Comments: none
-5. Acknowledgments
+6. Acknowledgments
The assertion control concept is attributed to Morteza Ansari.
Zeilenga LDAP Assertion Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
-6. Author's Address
+7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
-7. Normative References
+8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
September 2002.
-8. Informative References
+9. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
Zeilenga LDAP Assertion Control [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
copyrights, patents or patent applications, or other proprietary
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 1 November 2002
LDAP "Who am I?" Operation
- <draft-zeilenga-ldap-authzid-06.txt>
+ <draft-zeilenga-ldap-authzid-08.txt>
Status of this Memo
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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ mailing list <ldapext@ietf.org>. Please send editorial comments
+ directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Zeilenga LDAP "Who am I?" [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
Conventions
1. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
- (LDAP) [RFC2251] extended operation which clients can use to obtain
- the primary authorization identity in its primary form which the
- server has associated with the user or application entity.
-
- Servers often associate multiple authorization identities with the
- client and each authorization identity may be represented by multiple
- authzId [RFC2829] strings. This operation requests and returns the
- authzId the server considers to be primary. In the specification, the
- term "the authorization identity" and "the authzid" are to generally
- read as "the primary authorization identity" and the "the primary
- authzid", respectively.
+ (LDAP) [RFC3377] operation which clients can use to obtain the primary
+ authorization identity in its primary form which the server has
+ associated with the user or application entity. The operation is
+ called the "Who am I?" operation.
This specification is intended to replace the existing [AUTHCTL]
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 prior to the Bind operation, it is often desirable to only 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.
+ 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
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
- The LDAP "Who am I?" operation is named after the UNIX whoami(1)
- command. The whoami(1) command displays the effective user id.
+ Servers often associate multiple authorization identities with the
+ client and each authorization identity may be represented by multiple
+ authzId [RFC2829] strings. This operation requests and returns the
+ authzId the server considers to be primary. In the specification, the
+ term "the authorization identity" and "the authzId" are generally to
+ be read as "the primary authorization identity" and the "the primary
+ authzId", respectively.
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-06 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
- [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"
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
2.1. The whoami Request
example, a whoami request could be encoded as the sequence of octets
(in hex):
+ 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
+ 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
+
2.2. The whoami Response
The whoami response is an ExtendedResponse where the responseName
- field is absent and, if present, the response field is empty or an
+ 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:kurt@OPENLDAP.ORG" (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
3. Operational Semantics
- The function of the "Who am I?" operation is to request that the
- server returns the authorization identity it currently associates with
- the client. The client requests this authorization identity by
- issuing a whoami Request. The server responds to this request with a
- whoami Response.
+ The "Who am I?" operation provides a mechanism, a whoami Request, for
+ the client to request that the server returns the authorization
+ identity it currently associates with the client and provides a
+ mechanism, a whoami Response, for the server to respond to that
+ request.
If the server is willing and able to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with a success resultCode. If the server is treating
- the client as an anonymous entity, the response field is empty.
- Otherwise the server is to provide the authzId [RFC2829] representing
- the authorization identity it currently associates with the client in
- the response field.
+ the client as an anonymous entity, the response field is present but
+ empty. Otherwise the server provides the authzId [RFC2829]
+ representing the authorization identity it currently associates with
+ the client in the response field.
If the server is unwilling or unable to provide the authorization
identity it associates with the client, the server SHALL return a
whoami Response with an appropriate non-success resultCode (such as
- operationsError, protocolError, confidentialityRequired,
- insufficientAccessRights, busy, unavailable, unwillingToPerform, or
- other) and an absent response field.
-
Zeilenga LDAP "Who am I?" [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
As described in [RFC2251] and [RFC2829], an LDAP session has an
"anonymous" association until the client has been successfully
authenticated using the Bind operation. Clients MUST NOT invoke the
4. Extending the "Who am I?" operation with controls
Future specifications may extend the "Who am I?" operation using the
- control mechanism. When extended by controls, the "Who am I?"
- operation requests and returns the authorization identity the server
- associates with the client in a particular context indicated by the
- controls.
+ control mechanism [RFC2251]. When extended by controls, the "Who am
+ I?" operation requests and returns the authorization identity the
+ server associates with the client in a particular context indicated by
+ the controls.
4.1. Proxied Authorization Control
it associates with the assumed identity.
When a Proxied Authorization Control is be attached to the "Who Am I?"
- operation, the operation requests the return of the authzid the server
+ 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
Identities associated with users may be sensitive information. When
so, security layers [RFC2829][RFC2830] should be established to
- protect this information. This mechanism is specifically designed to
- allow security layers established by a Bind operation to protect the
- integrity and/or confidentiality of the authorization identity.
-
Zeilenga LDAP "Who am I?" [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+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.
- As with any other extended operations, general LDAP considerations
- apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
+ As with any other extended operations, general LDAP security
+ considerations [RFC3377] apply.
6. IANA Considerations
- No IANA assignments are requested.
+ 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
+ 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
+
+ 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
+
+ Author/Change Controller: IESG
- This document uses the 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 Foundation under its IANA assigned private enterprise
- allocation [PRIVATE] for use in this specification.
+ Comments: none
7. Acknowledgment
"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-08 1 November 2002
+
8. Author's Address
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
-
-Zeilenga LDAP "Who am I?" [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
-
-
10. Informative References
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
Copyright 2002, The Internet Society. All Rights Reserved.
+
+
+
+Zeilenga LDAP "Who am I?" [Page 6]
+\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
-Zeilenga LDAP "Who am I?" [Page 6]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 7]
\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 3 May 2003
+Expires in six months 25 October 2003
- LDAP Cancel Extended Operation
- <draft-zeilenga-ldap-cancel-08.txt>
+ LDAP Cancel Operation
+ <draft-zeilenga-ldap-cancel-10.txt>
1. Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP 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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2003, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
Zeilenga LDAP Cancel [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
-Conventions
+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].
+
+ 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].
- Protocol elements are described using ASN.1 [X.680]. 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].
-
1. Background and Intent of Use
X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
operation which does have a response and also requires the abandoned
- operation to return a response indicating it was canceled. The Cancel
- operation is modeled after the DAP Abandon operation.
+ operation to return a response indicating it was canceled. The LDAP
+ Cancel operation is modeled after the DAP Abandon operation.
- The Cancel operation SHOULD be used instead of the LDAP Abandon
+ The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operation may be used to cancel both interrogation and update
operations.
2.1. Cancel Request
- The Cancel request is an ExtendedRequest with the requestName field
- containing the IANA-0IGNED-OID and a requestValue field which contains
-
Zeilenga LDAP Cancel [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
- a BER-encoded cancelRequestValue value. The cancelID field contains
- the message id associated with the operation to be canceled.
+ The Cancel request is an ExtendedRequest with the requestName field
+ containing the IANA-ASSIGNED-OID and a requestValue field which
+ contains a BER-encoded cancelRequestValue value. The cancelID field
+ contains the message id associated with the operation to be canceled.
2.2. Cancel Response
cancel an outstanding operation issued within the same session.
The client requests the cancelation of an outstanding operation by
- issuing a Cancel Response with a cancelID with the message id
- identifying the outstanding operation. The Cancel Request itself has
- a distinct message id. Clients SHOULD NOT request cancelation of an
- operation multiple times.
+ issuing a Cancel Response with a cancelID set to the message id of the
+ outstanding operation. The Cancel Request itself has a distinct
+ message id. Clients SHOULD NOT request cancelation of an operation
+ multiple times.
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
knowledge of the operation requested to be canceled.
The cannotCancel resultCode is returned if the identified operation
- does not support cancelation or the cancel operation could not be
- performed. The following classes of operations are not cancelable:
Zeilenga LDAP Cancel [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
+ does not support cancelation or the cancel operation could not be
+ performed. The following classes of operations are not cancelable:
+
- operations which have no response,
- - operations which associate or disassociate authentication and/or
+ - operations which create, alter, or destroy authentication and/or
authorization associations,
- - operations which establish or tear-down security services, and
+ - operations which establish, alter, or tear-down security services,
+ and
- operations which abandon or cancel other operations.
The tooLate resultCode is returned to indicate that it is too late to
cancel the outstanding operation. For example, the server may return
tooLate for a request to cancel an outstanding modify operation which
- as already commited updates to the underlying datastore.
+ as already committed updates to the underlying data store.
Servers SHOULD indicate their support for this extended operation by
- providing IANA-ASSIGNED-OID as a value of the supportedExtension
+ providing IANA-ASSIGNED-OID as a value of the 'supportedExtension'
attribute type in their root DSE. A server MAY choose to advertise
- this extension only when the client is authorized to use this
- operation.
+ this extension only when the client is authorized to use it.
4. Security Considerations
- This operation is intended to allow a user to cancel operations they
- previously issued. No user should be allowed to cancel an operation
- issued by another user.
+ This operation is intended to allow user to cancel operations they
+ previously issued during the current LDAP association. In certain
+ cases, such as when the Proxy Authorization Control is in use,
+ different outstanding operations may be processed under different LDAP
+ associations. Servers MUST NOT allow a user to cancel an operation
+ belonging to another user.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
Registration of the following values [RFC3383] is requested.
-5.1. Object Identifier
-
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier to identify the LDAP Cancel Extended Operation as
- defined in this document.
-
Zeilenga LDAP Cancel [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
+
+5.1. Object Identifier
- The following registration template is suggested:
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier to identify the LDAP Cancel Operation as defined in
+ this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXXX
+ Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
- Identifies the LDAP Cancel Extended Operation
+ Identifies the LDAP Cancel Operation
5.2. LDAP Protocol Mechanism
It is requested that IANA register upon Standards Action the LDAP
Protocol Mechanism described in this document.
- Subject: Request for LDAP Protocol Mechansism Registration
+ Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
- Description: LDAP Cancel Extended Operation
+ Description: LDAP Cancel Operation
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
in 2
Result Code Name: noSuchOperation
Result Code Name: tooLate
Result Code Name: cannotCancel
- Specification: RFCXXXX
+ Specification: RFC XXXX
Author/Change Controller: IESG
Comments: request four consecutive result codes be assigned
-6. Acknowledgment
-
- The LDAP Cancel operation is modeled after the X.511 DAP Abandon
-
Zeilenga LDAP Cancel [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
+
+6. Acknowledgment
+ The LDAP Cancel operation is modeled after the X.511 DAP Abandon
operation.
7. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
- [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
+ [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
- (v3): Technical Specification", RFC 3377, September 2002.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
- of Basic Notation", X.680, 1994.
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
- [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", X.690, 1994.
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
8. Informative References
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
- September 2002.
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
- [X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
- 1993.
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993).
9. Author's Address
Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-Copyright 2003, The Internet Society. 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
Zeilenga LDAP Cancel [Page 6]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
-
-
- 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,
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
+ OpenLDAP Foundation
+ <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.
+ 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 Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 1 March 2002
+Expires in six months 9 December 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
- draft-zeilenga-ldap-rfc2596-01.txt
+ draft-zeilenga-ldap-rfc2596-04.txt
Status of Memo
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
- (LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
- editorial comments directly to the document editor
- <Kurt@OpenLDAP.org>.
+ (LDAPext) mailing list <ldapext@ietf.org>. Please send editorial
+ comments directly to the document editor <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
+
Zeilenga Language Tags and Ranges in LDAP [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Conventions
1. Background and Intended Use
- The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
This document describes how language tags and ranges [RFC3066] are
carried in LDAP and are to be interpreted by LDAP implementations.
- All implementations MUST be prepared to accept language tags and
- ranges in the LDAP protocol.
+ All LDAP implementations MUST be prepared to accept language tags and
+ ranges.
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
Appendix B discusses differences from X.500(1997) "contexts"
mechanism.
- Appendix A and B are provided for information purposes and are not a
- normative part of this specification.
+ Appendix A and B are provided for informational purposes only.
The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
1.1. Language Tags
Section 2 of BCP 47 [RFC3066] describes the language tag format which
- is used in LDAP. Briefly, it is a string of ASCII alphabetic
- characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
- Language tags are case insensitive. For example, the language tag
- "en-us" is the same as "EN-US".
+ is used in LDAP. Briefly, it is a string of ASCII letters and
+ hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags
+ are case insensitive. That is, the language tag "en-us" is the same
+ as "EN-US".
Section 2 of this document details use of language tags in LDAP.
1.2. Language Ranges
+ Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Zeilenga Language Tags and Ranges in LDAP [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
- Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Language ranges are used to specify sets of language tags.
- A language range matches a language tag if it exactly equals the tag,
- or if it exactly equals a prefix of the tag such that the first
- character following the prefix is "-". The special tag "*" matches
- all tags.
+ A language range matches a language tag if it is exactly equal to the
+ tag, or if it is exactly equal to a prefix of the tag such that the
+ first character following the prefix is "-". That is, the language
+ range "de" matches the language tags "de" and "de-CH" but not "den".
+ The special language range "*" matches all language tags.
- Due to restrictions upon option naming in LDAP, this document uses a
- different language range syntax. However, the semantics of language
- ranges in LDAP is consistent with BCP 47.
+ Due to attribute description option naming restrictions in LDAP, this
+ document defines a different language range syntax. However, the
+ semantics of language ranges in LDAP is consistent with BCP 47.
Section 3 of this document details use of language ranges in LDAP.
1.3. Attribute Descriptions
- This section provides an overview of attributes in LDAP. LDAP
- attributes are defined in [Models].
+ This section provides an overview of attribute descriptions in LDAP.
+ LDAP attributes and attribute descriptions are defined in [RFC2251].
An attribute consists of a type, a set of zero or more associated
tagging options, and a set of one or more values. The type and the
options are combined into the AttributeDescription.
AttributeDescriptions can also contain options which are not part of
- the attribute, but indicate some other function such as the transfer
- encoding.
+ the attribute, but indicate some other function (such as range
+ assertion or transfer encoding).
- An attribute with one or more tagging options is a direct subtype of
- each attribute of the same with all but one of the tagging options.
- If the attribute's type is a direct subtype of some other type, then
- the attribute is also a direct subtype of the attribute whose
- description consists of the the supertype and all of the tagging
- options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
- CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
-
- If the attribute description contains an unrecognized option, the
- attribute description is treated as an unrecognized attribute type.
-
- As language tags are intended to stored with the attribute, they are
- to treated as tagging options as described in Section 2. Language
- range are used only to match against language ranges and are not
- stored with the attribute. They are not treated tagging options (nor
- as transfer options), but as described in Section 3.
+ An AttributeDescription with one or more tagging options is a direct
+ subtype of each AttributeDescription of the same type with all but one
+ of the tagging options. If the AttributeDescription's type is a
+ direct subtype of some other type, then the AttributeDescription is
+ also a direct subtype of the AttributeDescription which consists of
+ the supertype and all of the tagging options. That is,
+ "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and
+ "name;x-bar;x-foo". Note that "CN" is a subtype of "name".
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
language tags in performing operations.
Servers which support storing attributes with language tag options in
the Directory Information Tree (DIT) SHOULD allow any attribute type
it recognizes that has the Directory String, IA5 String, or other
- textual string syntax to have language tag options associated with it.
- Servers MAY allow language options to be associated with other
+ textual string syntaxes to have language tag options associated with
+ it. Servers MAY allow language options to be associated with other
attributes types.
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
Clients SHOULD NOT assume servers are capable of storing attributes
with language tags in the directory.
2.1. Language Tag Options
A language tag option associates a natural language with values of an
- attribute. An attribute description MAY contain multiple language tag
- options. An entry MAY contain multiple attributes with same attribute
+ attribute. An attribute description may contain multiple language tag
+ options. An entry may contain multiple attributes with same attribute
type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
DIGIT = %x30-39 ; 0-9
- A language tag option is a tagging option [Models]. A language tag
- option has no effect on the syntax of the attribute's values nor their
- transfer encoding.
-
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
+ A language tag option is a tagging option. A language tag option has
+ no effect on the syntax of the attribute's values nor their transfer
+ encoding.
Examples of valid AttributeDescription:
description;x-foobar
CN
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
Notes: The last two have no language tag options. The x-foobar option
is fictious and used for example purposes.
type or its subtypes and contains each of the presented (and possibly
other) options is to be matched.
- Thus for example a filter of an equality match of type
+ Thus, for example, a filter of an equality match of type
"name;lang-en-US" and assertion value "Billy Ray", against the
- following directory entry
+ following directory entry:
dn: SN=Ray,DC=example,DC=com
- objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
+ objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
- (Note that "CN" and "SN" are subtypes of "name".)
+ Note that "CN" and "SN" are subtypes of "name".
It is noted that providing a language tag option in a search filter
AttributeDescription will filter out desirable values where the tag
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
option will not match as such it is an unrecognized attribute type.
No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
attribute type and the assertion value need match the value in the
directory.
- Thus for example a filter of an equality match of type "name" and
- assertion value "Billy Ray", against the following directory entry
+ Thus, for example, a filter of an equality match of type "name" and
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
- dn: SN=Ray,DC=example,DC=net
- objectclass: top DOES NOT MATCH (wrong type)
+
+ assertion value "Billy Ray", against the following directory entry:
+
+ dn: SN=Ray,DC=example,DC=com
objectclass: person DOES NOT MATCH (wrong type)
+ objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
2.3. Requested Attributes in Search
- Clients can provide language tag options in AttributeDescription in
- the requested attribute list in a search request.
+ Clients can provide language tag options in each AttributeDescription
+ in the requested attribute list in a search request.
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
- the same attribute type or its subtype and the provided language tags
- options are to be returned. Thus if a client requests just the
- attribute "name;lang-en", the server would return "name;lang-en" and
+ the same attribute type or its subtype and contains each of the
+ presented (and possibly other) language tag options are to be
+ returned. Thus if a client requests just the attribute
+ "name;lang-en", the server would return "name;lang-en" and
"CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
Clients can provide in the attribute list multiple
- AttributeDescription which have the same base attribute type but
- different options. For example a client could provide both
+ AttributeDescriptions which have the same base attribute type but
+ different options. For example, a client could provide both
"name;lang-en" and "name;lang-fr", and this would permit an attribute
with either language tag option to be returned. Note there would be
no need to provide both "name" and "name;lang-en" since all subtypes
include language tag options are to be ignored, just as if they were
unknown attribute types.
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
For example, if the client requests a "description" attribute, and a
matching entry contains the following attributes:
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
objectclass: top
objectclass: organization
O: Software GmbH
- description: software
+ description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
- postalAddress: Berlin 8001 Germany
- postalAddress;lang-de: Berlin 8001 Deutschland
The server would return:
- description: software
+ description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
with an equality match, as described in Section 2.2. If there is no
- attribute in the entry with the same subtype and language tag options,
- the noSuchAttributeType error will be returned.
+ attribute in the entry with the same attribute type or its subtype and
+ and contains each of the presented (or possibly other) language tag
+ options, the noSuchAttributeType error will be returned.
- Thus for example a compare request of type "name" and assertion value
- "Johann", against an entry containing the following attributes:
+ Thus, for example, a compare request of type "name" and assertion
+ value "Johann", against an entry containing the following attributes:
objectclass: top
objectclass: person
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
2.5. Add Operation
Clients can provide language options in AttributeDescription in
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
attributes of a new entry to be created.
A client can provide multiple attributes with the same attribute type
and value, so long as each attribute has a different set of language
tag options.
- For example, the following is a legal request.
+ For example, the following is a valid request:
dn: CN=John Smith,DC=example,DC=com
- objectclass: top
- objectclass: person
objectclass: residentialPerson
- name: John Smith
CN: John Smith
CN;lang-en: John Smith
SN: Smith
- SN;lang-en;lang-en-US: Smith
+ SN;lang-en: Smith
streetAddress: 1 University Street
- streetAddress;lang-en: 1 University Street
+ streetAddress;lang-en-US: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
any language tag option, then no language tag option is to be
provided.
3. Use of Language Ranges in LDAP
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
- This production and those it imports from [RFC2234] are provided here
- for convenience:
-
- Language-Tag = Primary-subtag *( "-" Subtag )
-
- Primary-subtag = 1*8ALPHA
-
- Subtag = 1*8(ALPHA / DIGIT)
-
- ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
-
- DIGIT = %x30-39 ; 0-9
+ This production and those it imports from [RFC2234] are provided in
+ Section 2.1 for convenience.
- A language range option matches a language tag option if language
+ A language range option matches a language tag option if the language
range option less the trailing "-" matches exactly the language tag or
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
Examples of valid AttributeDescription containing language range
options:
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 9]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
givenName;lang-en-
CN;lang-
+ SN;lang-de-;lang-gem-
O;lang-x-;x-foobar
A language range option is not a tagging option. Attributes cannot be
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
- which they allow to stored with language tags.
+ type which they allow to be stored with language tags.
3.1. Search Filter
If a language range option is present in an AttributeDescription in an
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
- Thus for example a filter of an equality match of type "name;lang-en-"
- and assertion value "Billy Ray", against the following directory entry
+ Thus, for example, a filter of an equality match of type
+ "name;lang-en-" and assertion value "Billy Ray", against the following
+ directory entry:
dn: SN=Ray,DC=example,DC=com
- objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
+ objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
- (Note that "CN" and "SN" are subtypes of "name".)
+ Note that "CN" and "SN" are subtypes of "name".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language range
evaluate to FALSE and all other assertions to Undefined.
-
-Zeilenga Language Tags and Ranges in LDAP [Page 10]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
3.2. Requested Attributes in Search
- Clients can provide language range options in AttributeDescription in
- the requested attribute list in a search request.
+ Clients can provide language range options in each
+ AttributeDescription in the requested attribute list in a search
+ request.
If a language range option is provided in an attribute description,
then only attributes in a directory entry whose attribute descriptions
nor "name;lang-fr".
Clients can provide in the attribute list multiple
- AttributeDescription which have the same base attribute type but
+ AttributeDescriptions which have the same base attribute type but
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
different options. For example a client could provide both
"name;lang-en-" and "name;lang-fr-", and this would permit an
attribute whose type was name or subtype of name and with a language
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
- Thus for example a compare request of type "name;lang-" and assertion
- value "Johann", against the entry with the following attributes:
+ Thus, for example, a compare request of type "name;lang-" and
+ assertion value "Johann", against the entry with the following
+ attributes:
objectclass: top
objectclass: person
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 11]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
4. Discovering Language Option Support
A server SHOULD indicate that it supports storing attributes with
- language tag options in the DIT by publishing OID.TDB as a value of
- the supportedFeatures [FEATURES] attribute in the root DSE.
+ language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
+ as a value of the "supportedFeatures" [FEATURES] attribute in the root
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
+ DSE.
A server SHOULD indicate that it supports language range matching of
attributes with language tag options stored in the DIT by publishing
- OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
- the root DSE.
+ 1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures"
+ [FEATURES] attribute in the root DSE.
A server MAY restrict use of language tag options to a subset of the
attribute types it recognizes. This document does not define a
fulfill the user's language needed. These options are not known to
raise specific security considerations. However, the reader should
consider general directory security issues detailed in the LDAP
- technical specification [Roadmap].
+ technical specification [RFC3377].
-6. Acknowledgments
+6. IANA Considerations
- This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
- RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
+ The OIDs 1.3.6.1.4.1.4203.1.5.4 and 1.3.6.1.4.1.4203.1.5.5 identify
+ the features described above. These OIDs were assigned [ASSIGN] by
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
- This document borrows from a number of IETF documents including BCP
- 47.
+ Registration of these protocol mechanisms [RFC3383] is requested.
+ Subject: Request for LDAP Protocol Mechanism Registration
-7. Normative References
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.4
+ Description: Language Tag Options
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.5
+ Description: Language Range Options
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+ Usage: Feature
+
+ Specification: RFCxxxx
+
+ Author/Change Controller: IESG
Zeilenga Language Tags and Ranges in LDAP [Page 12]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
+ Comments: none
+7. Acknowledgments
+
+ This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
+ RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
+ This document also borrows from a number of IETF documents including
+ BCP 47 by H. Alvestrand.
+
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
+ [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
+ [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
- [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress.
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
-8. Informative References
+9. Informative References
+
+ [X.501] ITU, "The Directory: Models", ITU-T Recommendation X.501,
+ 1997.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [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.
+
+
+
- [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
+
+Zeilenga Language Tags and Ranges in LDAP [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Appendix A. Differences from RFC 2596
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
- c) LDAP supports language ranges.
+ c) LDAP supports language ranges (new in this revision).
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
-
-Zeilenga Language Tags and Ranges in LDAP [Page 13]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-
-
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
"AS IS" basis and THE AUTHORS, 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
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 14]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
+
+
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Zeilenga Language Tags and Ranges in LDAP [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 15]
\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 3 May 2003
+Expires in six months 25 October 2003
LDAP Absolute True and False Filters
- <draft-zeilenga-ldap-t-f-05.txt>
+ <draft-zeilenga-ldap-t-f-07.txt>
Status of this Memo
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions 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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2003, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
Zeilenga LDAP True & False Filters [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
-1. Background and Intended Use
+1. Background
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
True and False assertions. An 'and' filter with zero elements always
specific Entries (DSEs) which do not necessarily have 'objectClass'
attributes. That is, where "(objectClass=*)" may evaluate to False.
- While LDAPv2 [RFC1777] 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].
+ 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].
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.
+ 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].
False. This filter is represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
- attribute in the root DSE.
+ (OID) 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
+ [FEATURES] attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
-3. Security Considerations
-
- The (re)introduction of absolute True and False filters is not
- believed to raise any new security considerations.
Zeilenga LDAP True & False Filters [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
+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].
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
- Specification: RFCxxxx
+ Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
6. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
- RFC 2254, December 1997.
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
+ [RFC2254] Howes, T., "A String Representation of LDAP Search
+ Filters", RFC 2254, December 1997.
- [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
- draft-zeilenga-ldap-features-xx.txt (a work in progress).
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Zeilenga LDAP True & False Filters [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
+
+
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt, a work in progress.
7. Informative References
- [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol", RFC 1777, March 1995.
+ [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.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [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.
+
- [RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
- RFC 1960, June 1996.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
+Intellectual Property Rights
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
+ 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
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
+Zeilenga LDAP True & False Filters [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
+
+
+ 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.
+
-Copyright 2003, The Internet Society. All Rights Reserved.
+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 implementation may be prepared, copied, published and
+ 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
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,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Zeilenga LDAP True & False Filters [Page 4]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP True & False Filters [Page 5]
\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
-Obsoletes: RFC 1274
-Updates: RFC 2798
-
-
- LDAPv3: A Collection of User Schema
- <draft-zeilenga-ldap-user-schema-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.
-
- 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 Directory Interest mailing list
- <directory@apps.ietf.org>. Please send editorial comments directly to
- the author <Kurt@OpenLDAP.org>.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright 2002, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-Abstract
-
- This document provides a collection of user schema elements for use
- with LDAP (Lightweight Directory Access Protocol) from both ITU-T
- Recommendations for the X.500 Directory and COSINE and Internet X.500
- pilot projects.
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 1]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
-Conventions
-
- Schema definitions are provided using LDAPv3 description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped) for
- readability.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-Table of Contents (to be expanded by editor)
-
- Status of this Memo 1
- Abstract
- Conventions 2
- Table of Contents
- 1. Background and Intended Use 3
- 2. Matching Rules
- 2.1. booleanMatch 4
- 2.2. caseExactMatch
- 2.3. caseExactOrderingMatch
- 2.4. caseExactSubstringsMatch
- 2.5. caseIgnoreListSubstringsMatch
- 2.6. directoryStringFirstComponentMatch 5
- 2.7. integerOrderingMatch
- 2.8. keywordMatch
- 2.9. numericStringOrderingMatch 6
- 2.10. octetStringOrderingMatch
- 2.11. storedPrefixMatch
- 2.12. wordMatch 7
- 3. Attribute Types
- 3.1. associatedDomain
- 3.2. associatedName
- 3.3. buildingName
- 3.3. co 8
- 3.5. documentAuthor
- 3.6. documentIdentifier
- 3.7. documentLocation
- 3.8. documentPublisher 9
- 3.9. documentTitle
- 3.10. documentVersion
- 3.11. drink
- 3.12. homePhone 10
- 3.13. homePostalAddress
- 3.14. host
- 3.16. info
- 3.17. mail 11
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 2]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- 3.18. manager
- 3.19. mobile
- 3.20. organizationalStatus
- 3.21. otherMailbox 12
- 3.22. pager
- 3.23. personalTitle
- 3.24. roomNumber 13
- 3.25. secretary
- 3.26. uid
- 3.27. uniqueIdentifier
- 3.28. userClass 14
- 4. Object Classes
- 4.1. account
- 4.2. document 15
- 4.3. documentSeries
- 4.4. domainRelatedObject
- 4.5. friendlyCountry
- 4.6. rFC822LocalPart 16
- 4.7. room
- 4.8. simpleSecurityObject
- 5. Security Considerations 17
- 6. IANA Considerations
- 7. Acknowledgments 19
- 8. Author's Address
- 9. Normative References
- 10. Informative References
- Full Copyright 20
-
-
-1. Background and Intended Use
-
- This document provides descriptions [RFC2252] of user schema for use
- with LDAP [LDAPTS] collected from numerous sources.
-
- This document includes a summary of select schema introduced for the
- COSINE and Internet X.500 pilot projects [RFC1274]. This document
- obsoletes RFC 1274.
-
- This document includes a summary of X.500 user schema [X.520] not
- previously specified for use with LDAP. Some of these items were
- described in the inetOrgPerson [RFC2798] schema. This document
- supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
- RFC 2798.
-
-
-2. Matching Rules
-
- This section introduces LDAP matching rules based upon descriptions of
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 3]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- their X.500 counterparts.
-
-
-2.1. booleanMatch
-
- BooleanMatch compares for equality a asserted Boolean value with an
- attribute value of BOOLEAN syntax. The rule returns TRUE if and only
- if the values are the same, i.e. both are TRUE or both are FALSE.
- (Source: X.520)
-
- ( 2.5.13.13 NAME 'booleanMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
-
-
-2.2. caseExactMatch
-
- CaseExactMatch compares for equality the asserted value with an
- attribute value of DirectoryString syntax. The rule is identical to
- the caseIgnoreMatch [RFC2252] rule except that case is not ignored.
- (Source: X.520)
-
- ( 2.5.13.5 NAME 'caseExactMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-2.3. caseExactOrderingMatch
-
- CaseExactOrderingMatch compares the collation order of the asserted
- string with an attribute value of DirectoryString syntax. The rule is
- identical to the caseIgnoreOrderingMatch [RFC2252] rule except that
- letters are not folded. (Source: X.520)
-
- ( 2.5.13.6 NAME 'caseExactOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-2.4. caseExactSubstringsMatch
-
- CaseExactSubstringsMatch determines whether the asserted value(s) are
- substrings of an attribute value of DirectoryString syntax. The rule
- is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except
- that case is not ignored. (Source: X.520)
-
- ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-
-2.5. caseIgnoreListSubstringsMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 4]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- CaseIgnoreListSubstringMatch compares the asserted substring with an
- attribute value which is a sequence of DirectoryStrings, but where the
- case (upper or lower) is not significant for comparison purposes. The
- asserted value matches a stored value if and only if the asserted
- value matches the string formed by concatenating the strings of the
- stored value. This matching is done according to the
- caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
- initial, any, or final values of the asserted value are considered to
- match a substring of the concatenated string which spans more than one
- of the strings of the stored value. (Source: X.520)
-
- ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-
-2.6. directoryStringFirstComponentMatch
-
- DirectoryStringFirstComponentMatch compares for equality the asserted
- DirectoryString value with an attribute value of type SEQUENCE whose
- first component is mandatory and of type DirectoryString. The rule
- returns TRUE if and only if the attribute value has a first component
- whose value matches the asserted DirectoryString using the rules of
- caseIgnoreMatch [RFC2252]. A value of the assertion syntax is derived
- from a value of the attribute syntax by using the value of the first
- component of the SEQUENCE. (Source: X.520)
-
- ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-2.7. integerOrderingMatch
-
- The integerOrderingMatch rule compares the ordering of the asserted
- integer with an attribute value of Integer syntax. The rule returns
- True if the attribute value is less than the asserted value. (Source:
- X.520)
-
- ( 2.5.13.15 NAME 'integerOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
-
-2.8. keywordMatch
-
- The keywordMatch rule compares the asserted string with keywords in an
- attribute value of DirectoryString syntax. The rule returns TRUE if
- and only if the asserted value matches any keyword in the attribute
- value. The identification of keywords in an attribute value and of
- the exactness of match are both implementation specific. (Source:
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 5]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- X.520)
-
- ( 2.5.13.32 NAME 'keywordMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-2.9. numericStringOrderingMatch
-
- NumericStringOrderingMatch compares the collation order of the
- asserted string with an attribute value of NumericString syntax. The
- rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except
- that all space characters are skipped during comparison (case is
- irrelevant as characters are numeric). (Source: X.520)
-
- ( 2.5.13.9 NAME 'numericStringOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
-
-2.10. octetStringOrderingMatch
-
- OctetStringOrderingMatch compares the collation order of the asserted
- octet string with an attribute value of OCTET STRING syntax. The rule
- compares octet strings from first octet to last octet, and from the
- most significant bit to the least significant bit within the octet.
- The first occurrence of a different bit determines the ordering of the
- strings. A zero bit precedes a one bit. If the strings are identical
- but contain different numbers of octets, the shorter string precedes
- the longer string. (Source: X.520)
-
- ( 2.5.13.18 NAME 'octetStringOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
-
-2.11. storedPrefixMatch
-
- StoredPrefixMatch determines whether an attribute value, whose syntax
- is DirectoryString, is a prefix (i.e. initial substring) of the
- asserted value, without regard to the case (upper or lower) of the
- strings. The rule returns TRUE if and only if the attribute value is
- an initial substring of the asserted value with corresponding
- characters identical except possibly with regard to case. (Source:
- X.520)
-
- ( 2.5.13.41 NAME 'storedPrefixMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- Note: This rule can be used, for example, to compare values in the
- Directory which are telephone area codes with a purported value
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 6]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- which is a telephone number.
-
-
-2.12. wordMatch
-
- The wordMatch rule compares the asserted string with words in an
- attribute value of DirectoryString syntax. The rule returns TRUE if
- and only if the asserted word matches any word in the attribute value.
- Individual word matching is as for the caseIgnoreMatch [RFC2252]
- matching rule. The precise definition of a "word" is implementation
- specific. (Source: X.520)
-
- ( 2.5.13.32 NAME 'wordMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-3. Attribute Types
-
- This section details attribute types for use in LDAP.
-
-
-3.1. associatedDomain
-
- The associatedDomain attribute type specifies a DNS domain [RFC1034]
- which is associated with an object. For example, the entry in the DIT
- with a distinguished name "DC=example,DC=com" might have an associated
- domain of "example.com". (Source: RFC 1274)
-
- ( 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 )
-
-
-3.2. associatedName
-
- The associatedName attribute type specifies an entry in the
- organizational DIT associated with a DNS domain [RFC1034]. (Source:
- RFC 1274)
-
- ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-
-3.3. buildingName
-
- The buildingName attribute type specifies the name of the building
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 7]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- where an organization or organizational unit is based. (Source: RFC
- 1274)
-
- ( 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} )
-
-
-3.3. co
-
- The co (Friendly Country Name) attribute type specifies names of
- countries in human readable format. It is commonly used in
- conjunction with the c (Country Name) [RFC2256] attribute type (which
- restricted to one of the two-letter codes defined in [ISO3166]).
- (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.43
- NAME ( 'co' 'friendlyCountryName' )
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-3.5. documentAuthor
-
- The documentAuthor attribute type specifies the distinguished name of
- the author of a document. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-
-3.6. documentIdentifier
-
- The documentIdentifier attribute type specifies a unique identifier
- for a document. (Source: RFC 1274)
-
- ( 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} )
-
-
-3.7. documentLocation
-
- The documentLocation attribute type specifies the location of the
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 8]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- document original. (Source: RFC 1274)
-
- ( 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} )
-
-
-3.8. documentPublisher
-
- The documentPublisher attribute is the person and/or organization that
- published a document. (Source: RFC 1274)
-
- ( 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 )
-
-
-3.9. documentTitle
-
- The documentTitle attribute type specifies the title of a document.
- (Source: RFC 1274)
-
- ( 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} )
-
-
-3.10. documentVersion
-
- The documentVersion attribute type specifies the version number of a
- document. (Source: RFC 1274)
-
- ( 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} )
-
-
-3.11. drink
-
- The drink (Favourite Drink) attribute type specifies the favorite
- drink of an object (or person). (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
- EQUALITY caseIgnoreMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 9]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-3.12. homePhone
-
- The homePhone (Home Telephone Number) attribute type specifies a home
- telephone number (e.g., "+44 71 123 4567") associated with a person.
- (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.20
- NAME ( 'homePhone' 'homeTelephoneNumber' )
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
-
-3.13. homePostalAddress
-
- The homePostalAddress attribute type specifies a home postal address
- for an object. This SHOULD be limited to up to 6 lines of 30
- characters each. (Source: RFC 1274)
-
- ( 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 )
-
-
-3.14. host
-
- The host attribute type specifies a host computer. (Source: RFC 1274)
-
- ( 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} )
-
-
-3.16. info
-
- The info (Information) attribute type specifies any general
- information pertinent to an object. It is RECOMMENDED that specific
- usage of this attribute type is avoided, and that specific
- requirements are met by other (possibly additional) attribute types.
- Note that the description attribute type [RFC2256] is available for
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 10]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- specifying descriptive information pertinent to an object. (Source:
- RFC 1274)
-
- ( 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} )
-
-
-3.17. mail
-
- The mail (rfc822mailbox) attribute type holds an the electronic mail
- address in [RFC822] form (e.g.: user@example.com). Note that this
- attribute SHOULD NOT be used to hold non-Internet addresses. (Source:
- RFC 1274)
-
-
- ( 0.9.2342.19200300.100.1.3
- NAME ( 'mail' 'rfc822Mailbox' )
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
-
-
-3.18. manager
-
- The Manager attribute type specifies the manager of an object
- represented by an entry. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.10
- NAME 'manager'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-
-3.19. mobile
-
- The mobile (Mobile Telephone Number) attribute type specifies a mobile
- telephone number (e.g., "+44 71 123 4567") associated with a person.
- (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.41
- NAME ( 'mobile' 'mobileTelephoneNumber' )
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 11]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
-3.20. organizationalStatus
-
- The organizationalStatus attribute type specifies a category by which
- a person is often referred to in an organization. Examples of usage
- in academia might include undergraduate student, researcher, lecturer,
- etc.
-
- A Directory administrator SHOULD consider carefully the distinctions
- between this and the title and userClass attributes. (Source: RFC
- 1274)
-
- ( 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} )
-
-
-3.21. otherMailbox
-
- The otherMailbox attribute type specifies values for electronic
- mailbox types other than X.400 and RFC822. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.22
- NAME 'otherMailbox'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )
-
-
-3.22. pager
-
- The pager (Pager Telephone Number) attribute type specifies a pager
- telephone number (e.g., "+44 71 123 4567") for an object. (Source:
- RFC 1274)
-
- ( 0.9.2342.19200300.100.1.42
- NAME ( 'pager' 'pagerTelephoneNumber' )
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
-
-3.23. personalTitle
-
- The personalTitle attribute type specifies a personal title for a
- person. Examples of personal titles are "Frau", "Dr", "Herr", and
- "Prof". (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.40
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 12]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- NAME 'personalTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-3.24. roomNumber
-
- The roomNumber attribute type specifies the room number of an object.
- Note that the cn (commonName) attribute type SHOULD be used for naming
- room objects. (Source: RFC 1274)
-
- ( 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} )
-
-
-3.25. secretary
-
- The secretary attribute type specifies the secretary of a person. The
- attribute value for Secretary is a distinguished name. (Source: RFC
- 1274)
-
- ( 0.9.2342.19200300.100.1.21
- NAME 'secretary'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-
-3.26. uid
-
- The uid (userid) attribute type specifies a computer system login
- name. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.1.1
- NAME ( 'uid' 'userid' )
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-3.27. uniqueIdentifier
-
- The Unique Identifier attribute type specifies a "unique identifier"
- for an object represented in the Directory. The domain within which
- the identifier is unique, and the exact semantics of the identifier,
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 13]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- 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. An attribute value for uniqueIdentifier is a
- directoryString. (Source: RFC 1274)
-
- ( 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} )
-
- Note: X.520 describes an attribute also called 'uniqueIdentifier'
- (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
- [RFC2256]. The attribute detailed here ought not be confused
- with x500UniqueIdentifier.
-
-
-3.28. userClass
-
- The userClass attribute type specifies a category of computer user.
- The semantics placed on this attribute are for local interpretation.
- Examples of current usage od this attribute in academia are
- undergraduate student, researcher, lecturer, etc. Note that the
- organizationalStatus attribute type is now often be preferred as it
- makes no distinction between computer users and others. (Source: RFC
- 1274)
-
- ( 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} )
-
-
-4. Object Classes
-
- This section details object classes for use in LDAP.
-
-
-4.1. account
-
- The account object class is used to define entries representing
- computer accounts. The uid (userid) attribute SHOULD be used for
- naming entries of this object class. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.5
- NAME 'account'
- SUP top STRUCTURAL
- MUST uid
- MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 14]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
-4.2. document
-
- The document object class is used to define entries which represent
- documents. (Source: RFC 1274)
-
- ( 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 ) )
-
-
-4.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). (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.9
- NAME 'documentSeries'
- SUP top STRUCTURAL
- MUST cn
- MAY ( description $ l $ o $ ou $ seeAlso $
- telephonenumber ) )
-
-
-4.4. 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. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.17
- NAME 'domainRelatedObject'
- SUP top AUXILIARY
- MUST associatedDomain )
-
-
-4.5. friendlyCountry
-
- The friendlyCountry object class is used to define country entries in
- the DIT. The object class is used to allow friendlier naming of
- countries than that allowed by the object class country [RFC2256].
- (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.18
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 15]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- NAME 'friendlyCountry'
- SUP country STRUCTURAL
- MUST co )
-
-
-4.6. rFC822LocalPart
-
- The rFC822LocalPart object class is used to define entries which
- represent the local part of [RFC822] mail addresses. This treats this
- part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.14
- NAME 'rFC822localPart'
- SUP domain STRUCTURAL
- MAY ( cn $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $
- physicalDeliveryOfficeName $ postalAddress $
- postalCode $ postOfficeBox $ preferredDeliveryMethod $
- registeredAddress $ seeAlso $ sn $ street $
- telephoneNumber $ teletexTerminalIdentifier $
- telexNumber $ x121Address ) )
-
-
-4.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. (Source: RFC 1274)
-
- ( 0.9.2342.19200300.100.4.7 NAME 'room'
- SUP top STRUCTURAL
- MUST cn
- MAY ( roomNumber $ description $
- seeAlso $ telephoneNumber ) )
-
-
-4.8. simpleSecurityObject
-
- The simpleSecurityObject object class is used to require an entry to
- have a userPassword attribute when the entry's structural object class
- does not require (or allow) the userPassword attribute. (Source: RFC
- 1274)
-
-
- ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
- SUP top AUXILIARY
- MUST userPassword )
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 16]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- Note: Security considerations related to the use of simple
- authentication mechanisms in LDAP are discussed in RFC 2829
- [RFC2829].
-
-
-5. Security Considerations
-
- General LDAP security considerations [LDAPTS] is applicable to the use
- of this schema. Additional considerations are noted above where
- appropriate.
-
-
-6. IANA Considerations
-
- It is requested that IANA update the LDAP descriptors registry as
- indicated the following template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see comment
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors should be added:
-
- NAME Type OID
- ------------------------ ---- ---------
- booleanMatch M 2.5.13.13
- caseExactMatch M 2.5.13.5
- caseExactOrderingMatch M 2.5.13.6
- caseExactSubstringsMatch M 2.5.13.7
- caseIgnoreListSubstringsMatch M 2.5.13.12
- directoryStringFirstComponentMatch M 2.5.13.31
- integerOrderingMatch M 2.5.13.15
- keywordMatch M 2.5.13.32
- numericStringOrderingMatch M 2.5.13.9
- octetStringOrderingMatch M 2.5.13.18
- storedPrefixMatch M 2.5.13.41
- wordMatch M 2.5.13.32
-
- The following descriptors should be updated to refer to RFC XXXX.
-
- NAME Type OID
- ------------------------ ---- --------------------------
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 17]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- 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
- 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
- otherMailbox A 0.9.2342.19200300.100.1.22
- 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
- uid A 0.9.2342.19200300.100.1.1
- uniqueIdentifier A 0.9.2342.19200300.100.1.44
- userClass A 0.9.2342.19200300.100.1.8
- userId A 0.9.2342.19200300.100.1.1
-
- where Type A is Attribute, Type O is ObjectClass, and Type M
- is Matching Rule.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 18]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
- This document make no OID assignments, it only associates LDAP schema
- descriptions with existing elements of X.500 schema.
-
-
-7. Acknowledgments
-
- This document borrows from a number of IETF documents including RFC
- 1274 by Paul Barker and Steve Kille. This document also borrows from
- a number of ITU documents including X.520.
-
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-9. Normative References
-
- [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
- messages", STD 11 (also RFC 822), August 1982.
-
- [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
- STD 13 (also RFC 1034), November 1987.
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
- "Using Domains in LDAP/X.500 Distinguished Names", January
- 1998.
-
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
-
- [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
- (v3): Technical Specification", draft-ietf-ldapbis-
- ldapv3-ts-00.txt.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 19]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-
-
-10. Informative References
-
- [ISO3166] International Standards Organization, "Codes for the
- representation of names of countries", ISO 3166.
-
- [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
- November 1991.
-
- [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
- April 2000.
-
- [X.520] International Telephone Union, "The Directory: Selected
- Attribute Types", X.520, 1997.
-
-
-Full Copyright
-
- Copyright 2002, The Internet Society. 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 AUTHORS, 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.
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 20]
-\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 11 May 2003
+Expires in six months 25 October 2003
The LDAP entryUUID operational attribute
- <draft-zeilenga-ldap-uuid-00.txt>
+ <draft-zeilenga-ldap-uuid-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 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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 1]
+Zeilenga draft-zeilenga-ldap-uuid-02 [Page 1]
\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
+INTERNET-DRAFT LDAP entryUUID 25 October 2003
1. Background and Intended Use
DN which previously identified another (now renamed or deleted)
object.
- This document describes the 'entryUUID' operational attribute 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.
+ 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.
This document defines the UUID syntax, the 'uuidMatch' and
'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
2.1 UUID Syntax
- A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet value
- which identifies object. The ASN.1 [X.690] type UUID is defined to
- represent UUIDs.
+ 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.
- UUID ::= OCTET STRING{16} -- constrained to an UUID [ISO 11578]
+ UUID ::= OCTET STRING (SIZE(16))
+ -- constrained to an UUID [ISO 11578]
- In LDAP, values of the UUID are encoded using the string
- representation described in [ISO11578]. For example,
- 597ae2f6-16a6-1027-98f4-d28b5365dc14.
+ 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".
- ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
+ The following is a LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+ ( 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 octetStringMatch
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 2]
+Zeilenga draft-zeilenga-ldap-uuid-02 [Page 2]
\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
+INTERNET-DRAFT LDAP entryUUID 25 October 2003
- [X.520][RFC2252].
+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
+ representation.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
2.3 'uuidOrderingMatch' Matching Rule
The 'uuidOrderingMatch' matching rule compares an asserted UUID
- with a stored UUID for ordering. Its semantics are the same as
- octetStringOrderingMatch [X.520][RFC2252].
+ 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.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
+ It is noted that not all UUID variants have a defined ordering and,
+ even where so, servers are not obligated to assign UUIDs in any
+ particular order. This matching rule is provided for completeness.
+
2.4. 'entryUUID' attribute
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-02 [Page 3]
+\f
+INTERNET-DRAFT LDAP entryUUID 25 October 2003
+
+
SYNTAX IANA-ASSIGNED-OID.1
SINGLE-VALUE
NO-USER-MODIFICATION
4.1. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 3]
-\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
-
-
Object Identifier for use in this technical specification.
Subject: Request for LDAP OID Registration
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
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): entryUUID
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 4]
-\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
-
-
Object Identifier: IANA-ASSIGNED-OID.4
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
5. Acknowledgments
This document is based upon discussions in the LDAP Update and
- Duplication Protocols (LDUP) WG.
+ Duplication Protocols (LDUP) WG. Members of the concluded LDAP
+ Extensions (LDAPEXT) Working Group provided review.
6. Author's Address
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+
+Zeilenga draft-zeilenga-ldap-uuid-02 [Page 5]
+\f
+INTERNET-DRAFT LDAP entryUUID 25 October 2003
+
+
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
ISO/IEC 9594-6:1994).
[X.680] International Telecommunication Union -
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 5]
-\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
-
-
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
- [UUIDinfo] The Open Group, "Universally Unique Identifier" section
- of "CDE 1.1: Remote Procedure Calls",
- <http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>,
- April 1997.
+ [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.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-02 [Page 6]
+\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
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
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 6]
-\f
-INTERNET-DRAFT LDAP entryUUID 11 May 2003
-
-
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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-00 [Page 7]
+Zeilenga draft-zeilenga-ldap-uuid-02 [Page 7]
\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
- OpenLDAP Foundation
-Expires in six months 1 October 2002
-
-
-
- LDAP (Alternative) Virtual List View Operation
- <draft-zeilenga-ldapext-vlv-00.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 offered to IETF LDAPEXT WG as an alternative to
- draft-ietf-ldapext-ldapv3-vlv-xx.txt.
-
- 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 Working Group mailing
- list <ldapext@ietf.org>. Please send editorial comments directly to
- the author <Kurt@OpenLDAP.org>.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright 2002, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-
-
-
-
-
-
-Zeilenga LDAP Virtual List View [Page 1]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
-Abstract
-
- This document describes an LDAP (Lightweight Directory Access
- Protocol) Virtual List View (VLV) operation. The operation allows the
- client to obtain portion (the view) of an ordered set (the list) of
- entries visible through a virtual window. The client can reissue the
- operation with different criteria to obtain a different view of the
- list. Clients may use this operation to page, scroll, or browse
- directory content.
-
- The VLV operation is defined as a set of LDAP controls which extend
- the Search operation. The VLV controls may be used in conjunction
- with a number of other search controls, such as the Server Side
- Sorting of Search Results (RFC 2891) control.
-
-
-1. Overview
-
- A "virtual list" is a graphical user interface (GUI) technique
- employed where a list containing a large number of entries need to be
- displayed. A window containing a small number of list entries are
- visible. This window can be relocated such that another set of list
- entries are visible. The set of entries visible through the window is
- the view.
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] Virtual
- List View (VLV) operation allows a client to obtain the set of entries
- of an ordered list visible through a window from a server. The set of
- entries are selected based on search criteria. In absence of a
- control specifying a particular order, the order is determined by the
- server. The position and size of the window is determined by
- parameters of the VLV request control.
-
- The VLV operation is defined as an extended Search operation. The VLV
- operation is state-less.
-
- Appendix A. discusses how a client can use VLV operations to provide a
- GUI to page, scroll, and browse directory content.
-
-
-1.1. Relationship to other LDAP extensions
-
- The VLV operation may be used with
-
- - Duplicate Entry Control [DUPENT],
- - ManageDsaIT Control [RFC3296],
- - Matched Values Control [MATCHED],
- - Server-Side Sorting Control [RFC2891], and
-
-
-
-Zeilenga LDAP Virtual List View [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- - Subentries Control [SUBENTRY].
-
- as described in Section 5. The VLV operation may be used with other
- LDAP extensions as detailed in other documents.
-
- This document provides a standardized mechanism for scrolling, paging,
- and browsing DIT content. It is intended to replace Scrolling View
- Browsing [SVB] and the the Simple Paged Results Manipulation [RFC2696]
- control extensions.
-
-
-1.2. Comparison to Scrolling View Browsing
-
- This document was originally offered as an alternative to the
- Scrolling View Browsing (SVB) [SVB] approach. While both SVB and VLV
- are upon a Virtual View List metaphor, they differ in many ways. This
- section highlights a few of the differences.
-
- SVB was designed to work in static environments. Small DIT changes
- between related SVB operations can yield astonishing results. For
- example, an SVB operation intended to page the view down, may jump
- over entries or an SVB operation intended to scroll a view up can
- actually return entries which are below the current view. This is
- because SVB relies on the ordinal position of entries in the list to
- be stable.
-
- VLV addresses this problem by selecting the target entry which the
- view is centered about by DN. An VLV intended to page down the view,
- selects the next page based upon the position of a particular entry.
- Likewise for scrolling. Even where the target entry is modified (and
- hence now appears next to other entries in the list), the client can,
- by requesting overlapping entries, determine whether the returned view
- is adjacent to the previous view or not. Based upon intended result,
- the client can choose to display this view to the user or request
- another view centered about other entries in the previous view.
-
- SVB provides a mechanism allowing selection of the target entry by its
- offset from the head of the list, but not the tail of the list. VLV
- provides selection by offsets from the head or the tail.
-
- SVB provides a "type down" selection mechanism limited to the list
- primary sort key. VLV provides a "type down" selection mechanism
- which allows selection by all of the sort keys.
-
- SVB requires that entries be sorted using the Server-Side Sorting
- Control [RFC2891]. VLV only requires that the list be ordered by a
- deterministic algorithm. VLV allows, but does not require, a
- particular ordering algorithm to be requested.
-
-
-
-Zeilenga LDAP Virtual List View [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
-1.3. Terminology and Conventions
-
- The term "list" (of entries) refers to an ordered set of entries by a
- deterministic algorithm. The list may contain both returnable and
- non-returnable entries.
-
- The term "returnable entry" refers to an entry which the server is
- willing and able to return. A "non-returnable entry" refers to an
- entry which the server is unwilling or unable to return.
-
- The term "target" refers to the entry used to position the window.
-
- The term "view" refers to the portion of a list of entries visible
- through a window.
-
- The term "window" refers to the criteria for selecting the portion of
- the list to be viewed.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. Protocol Elements
-
- Protocol elements are described using ASN.1 [X.680]. The term
- "BER-encoded" means the element is to be encoded using the Basic
- Encoding Rules [X.690] per Section 5.1 of [RFC2251].
-
-
-2.1. VLV Request Control
-
- The VLV Request Control is an LDAPControl [RFC2251] whose controlType
- is the "IANA-ASSIGNED-OID.1", criticality is True or False (the
- DEFAULT), and the controlValue, an OCTET STRING, contains a
- BER-encoded value of the vlvRequestValue data type:
-
- target ::= SEQUENCE {
- tSelect CHOICE {
- tName [0] LDAPDN,
- tFraction [1] SEQUENCE {
- tNumerator INTEGER,
- -- constrained to (0..tDenominator))
- tDenominator INTEGER (1..maxint)
- },
- tOffset [2] INTEGER (0..maxint),
- tTypeDown [3] SEQUENCE OF AssertionValue
- -- contains at least one AssertionValue
-
-
-
-Zeilenga LDAP Virtual List View [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- ...
- },
- tReverse BOOLEAN DEFAULT False
- -- for tTypeDown, tReverse is constrained to False
- }
-
- window ::= SEQUENCE {
- wOffset INTEGER,
- wCount INTEGER (0..maxInt)
- wReverse BOOLEAN DEFAULT False
- }
-
- vlvRequestValue ::= SEQUENCE {
- COMPONENTS OF target
- COMPONENTS OF window
- }
-
- The VLV Request Control is applicable to the SearchRequest message.
-
-
-2.2. VLV Target Response Control
-
- The VLV Target Response Control is an LDAPControl [RFC2251] whose
- controlType is the "IANA-ASSIGNED-OID.2", criticality is False (the
- DEFAULT), and the controlValue is absent.
-
- The VLV Target Response Control is applicable to the SearchResultEntry
- message.
-
-
-2.3. VLV Done Response Control
-
- The VLV Done Response Control is an LDAPControl [RFC2251] whose
- controlType is the "IANA-ASSIGNED-OID.3", criticality is False (the
- DEFAULT), and the controlValue is absent.
-
- The VLV Done Response Control is applicable to the SearchResultDone
- message.
-
-
-2.4. VLV Result Codes
-
- Implementations of this specification SHALL recognize the following
- additional resultCode [RFC2251] values:
-
- vlvTargetInvalid (IANA-ASSIGNED-1)
- vlvTargetNotFound (IANA-ASSIGNED-2)
- vlvWindowInvalid (IANA-ASSIGNED-3)
-
-
-
-Zeilenga LDAP Virtual List View [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
-3. The VLV Operation
-
- The VLV operation is defined as an extension to the Search operation.
- The operation is initiated by the client sending a VLV request
- message, a SearchRequest which includes a VLV Request Control. In
- response to this request, the server returns zero or more
- SearchResultEntry messages, one of which may include the VLV Target
- Control. The operation is completed by the server returning a VLV
- done response message, a SearchResultDone message which includes VLV
- Response Done Control.
-
- No searchResultReference messages are returned in response to a VLV
- Request. Continuation references are discussed further in Section
- 4.1.
-
- In the VLV request message, fields of searchRequest structure specify
- the list of entries. The searchRequest fields have the same semantics
- as defined in Section 4.5.1 of [RFC2251]. The fields of the VLV
- Request Control specify the desired target as well as the window.
-
-
-3.1. Target Selection
-
- The target may be select from the list by multiple means.
-
-
-3.1.1. Target Selection by DN
-
- The target tName choice allows selection of the target by
- distinguished name (DN). If the provided LDAPDN is not a valid string
- representation [RFC2253] of a DN, vlvTargetInvalid is returned. If
- the entry named cannot be found, is not in the list, or is not
- returnable, vlvTargetNotFound is returned.
-
- When the request is accompanied by a Duplicate Entry control [DUPENT],
- tReverse=False indicates that first duplicate of the entry in the list
- is the target and tReverse=True indicates that last duplicate of the
- entry in the list is the target. If a Duplicate Entry control was not
- provided, tReverse is ignored.
-
-
-3.1.2. Target Selection by Offset
-
- The target tOffset choice selects the target based on ordinal position
- in the list. When tReverse is False (DEFAULT), a tOffset value of N
- selects the first returnable entry whose ordinal position is greater
- than N. When tReverse is True, a tOffset value of N selects the last
- returnable entry in a list of size M whose ordinal position is less
-
-
-
-Zeilenga LDAP Virtual List View [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- than or equal to the value M-N. For example, in a list of 100
- entries:
-
- <tOffset=0,tReverse=False> selects the first returnable entry;
-
- <tOffset=0,tReverse=True> selects the first returnable entry;
-
- <tOffset=10,tReverse=True> selects the first returnable entry
- whose ordinal position is greater than 10;
-
- <tOffset=5,tReverse=True> selects the last returnable entry whose
- ordinal position is less than or equal to 95 (100-5).
-
- If the value of tOffset is greater than or equal to the size of the
- list, vlvTargetInvalid is returned. If no entry meets the criteria,
- vlvTargetNotFound is returned.
-
-
-3.1.2. Target Selection by Fraction
-
- The target tFraction choice selects the target based on proportional
- position of entries on the list. The target is the first returnable
- entry whose ordinal position is closest to quantity 0.5 plus product
- of the size of the list, less one, and the quotient of the value
- tNumerator divided by the value of tDenominator. That is, the target
- is the returnable entry of whose ordinal position in a list of N
- entries is closest to
-
- (0.5 + (N - 1) * (tNumerator / tDenominator))).
-
- Where the two closest returnable entries are equally close, the entry
- which appears later in the list is targeted.
-
- For a list of any size:
-
- <tNumerator=0,tDenominator=1> selects the first returnable entry;
- and
- <tNumerator=1,tDenominator=1> selects the last returnable entry;
-
- For a list of size 100:
- <tNumerator=1,tDenominator=2> selects the returnable entry closest
- to 51 (e.g., the returnable entry closest to the middle);
- <tNumerator=2,tDenominator=3> selects the returnable entry closest
- to 65.49.
-
- For a list of size 101:
- <tNumerator=1,tDenominator=2> selects the returnable entry closest
- to 50.5 (e.g., the returnable entry closest to the middle);
-
-
-
-Zeilenga LDAP Virtual List View [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- <tNumerator=2,tDenominator=3> selects the returnable entry closest
- to 67.2.
-
- If the list is empty or contains no returnable entries,
- vlvTargetNotFound is returned. If tReverse is True, protocolError is
- returned.
-
-
-3.1.3. Target Selection by Type Down
-
- The target tTypeDown choice selects the target whose based upon "type
- down" criteria.
-
- The first tTypeDown AssertionValue is associated with the first sort
- key. The second AssertionValue is associated with the second key.
- And so on.
-
- If there are more AssertionValues than keys, protocolError is
- returned. If there are more keys than AssertionValues, only the keys
- which have associated AssertionValues are used.
-
- If tReverse is True, protocolError is returned.
-
- To select the target, the set of returnable entries whose least
- attribute value for the first key is equal to the first AssertionValue
- is determined. If the set contains one entry, that entry is the
- target. If this set is empty, the first returnable greater than the
- AssertionValue is the target. If none, vlvTargetNotFound is returned.
- If the set contains multiple entries, additional key and
- AssertionValue pairs are used in turn as detailed in the next
- paragraph. If there are no additional pairs, the target is the first
- entry in the set.
-
- Using the next key and AssertionValue, a subset of the set (from the
- preceding step) whose least attribute value for the key is equal to
- the AssertionValue is determined. If the set contains one entry, that
- entry is the target. If this subset is empty, first entry in the set
- greater than the AssertionValue is the target. If none, the first
- returnable entry entry greater than the first AssertionValue is the
- target. In none, vlvTargetNotFound is returned. If the set contains
- multiple entries, then this step is repeated with the next key and
- AssertionValue pair. If there are no additional pairs, the target is
- the first entry in the subset.
-
- For example, consider a list sorted by list sorted first by 'sn', then
- by 'givenName', and then by 'initials' and a target criteria of
- <tTypeDown={"James", "J"}>. First, the set of returnable entries
- whose least value of 'sn' is "James" is determined. Second, assuming
-
-
-
-Zeilenga LDAP Virtual List View [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- the set is non-empty, the subset of this set whose least value of
- 'givenName' is "J" is determined. If the subset is non-empty, the
- first entry of the subset is the target (as there are no further key /
- AssertionValue pairs). If this subset is empty then, the target is
- the first entry in the set which has a 'givenName' greater than "J".
- If none, then the target is the first entry in the list which contains
- a 'sn' value greater than 'James'.
-
-
-3.2. View Selection and Return
-
- If wCount is 0, the view is empty and no entries are returned.
- Otherwise, the window is positioned relative to the target entry to
- determine the view.
-
- The positioning index is the value of wOffset plus the ordinal
- position of the target entry. If this index is less than 1, the first
- entry of the list is first entry of the view. If the index is greater
- than the size of the list, the last entry in the list is the first
- entry in the view. Otherwise, the entry whose ordinal position in the
- list is equal to this index is the first entry of the view.
-
- If the entry at the positioning index is returnable, it is returned
- first and wCount is reduced by one.
-
- If wReverse=False, the next wCount returnable entries from the
- position index towards the tail of the list are in the view and are
- returned in increase ordinal order.
-
- If wReverse=True, the next wCount returnable entries from the position
- index towards the head of the list are in the view and are returned in
- decreasing ordinal order.
-
- If the target entry is within view, it is returned with a Virtual
- Target Response control.
-
-
-3.3. Done Response Message
-
- The VLV Done Response message is returned on completion of the VLV
- operation.
-
-
-4. Other considerations
-
-4.1. Continuation References
-
- As indicated above, no searchResultReference messages are returned in
-
-
-
-Zeilenga LDAP Virtual List View [Page 9]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- response to a VLV Request.
-
- Where the content contains references to other servers, the server MAY
- obtain entries from these others in order to fulfill the VLV request.
- Otherwise, the server SHALL ignore these references.
-
-
-4.2. Changes to content between VLV operations
-
- While individual entries tend to change infrequently, changes to a
- list of entries is likely change frequently. For example, if the
- average entry changes once per (8 hour) work day, a list of 28,800
- entries will change approximately once per second during the work day.
-
- The client SHOULD NOT assume the directory content is static.
-
-
-4.3. Changes to content during a VLV operation
-
- Server implementations which allows directory content to change (due
- to other operations) during processing of the VLV operation, need to
- take special care to ensure the operation behaves in a consistent
- manner.
-
- During the processing of the VLV operation, an entry is modified in a
- manner which changes in a manner which affects it position in the
- list. If only the old position is in the view, the server MUST either
- return the old entry in the old position or not return the entry. If
- only the new position is in the view, the server MUST either return
- new entry in the new position or not return the entry. If both
- positions are in the view, the server MUST either return the old entry
- in the old position, the new entry in the new position, or not return
- the entry.
-
- If the target entry is modified, then the server MUST select all
- returned entries based upon the old position of the target entry or
- select all returned entries based upon the new entry.
-
-
-5. Interaction with Other Controls
-
- The VLV operation may be used with
-
- - Duplicate Entry Control [DUPENT],
- - ManageDsaIT Control [RFC3296],
- - Matched Values Control [MATCHED],
- - Server-Side Sorting Control [RFC2891], and
- - Subentries Control [SUBENTRY].
-
-
-
-Zeilenga LDAP Virtual List View [Page 10]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- as described below. The VLV operation may be used with other LDAP
- extensions as detailed in other documents.
-
-
-5.1. Server-Side Sorting Control
-
- VLV operations provide a view into an ordered list. When the Server-
- Side Sorting Control (SSS) [RFC2891] indicates the particular sorting
- algorithm to be used to determining the order of entries in the list.
- Where the sorting algorithm allows for two or more entries to be
- presented in any order, the server MUST choose the order which these
- entries appear in the list by a deterministic algorithm.
-
- That is, if the Sort Control indicates the list is to sorted by their
- CN values and two or more entries have the same CN value, the server
- is not free to return the entries in randomly selected order.
-
-
-5.2. Duplicate Entry Control
-
- It is often desirable to include an entry which has multiple values
- for the sort key(s) in the list multiple times, once for each value of
- a sort key. For example, when constructing a list of entries by
- ordered by common name (CN), it is often desirable for the entry to
- appear in the list under each CN value. The Duplicate Entry Control
- provides a mechanism by which the "client requests that the server
- return separate entries for each value held in the specified
- attribute(s)" [DUPENT].
-
- When used with the VLV Operation, the Duplicate Entry Control
- logically applies to entries before list ordering. That is, each
- duplicate entry is ordered independently in respect to other entries
- (duplicates or not) in the list.
-
- A particular ordering algorithm may be specified by use of a sorting
- control.
-
-
-5.3. Matched Values Control
-
- The Matched Values control is "used to return a subset of attribute
- values from an entry, specifically, only those values that match a
- "values return" filter" [MATCHED].
-
- When used with the VLV Operation, the Matched Values control logically
- applies to entries before list ordering. That is, entries are to
- ordered based only upon a subset of attribute values selected by the
- Matched Values control. Other values are eliminated.
-
-
-
-Zeilenga LDAP Virtual List View [Page 11]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- Matched Values control SHOULD precede other controls are specified
- which affect the number and ordering entries in the list.
-
-
-5.4. ManageDsaIT control
-
- As when used with other operations, the ManageDsaIT control [RFC3296]
- causes referral and other special objects to be treated as normal
- objects with respect to the VLV Operation and other controls. That
- is, the referral and other special objects appear in the list if they
- were normal objects.
-
-
-5.5. Subentries control
-
- The Subentries control is used with the search operation "to control
- the visibility of entries and subentries which are within scope"
- [SUBENTRY]. When used with the VLV Operation, the subentries control
- and other factors (search scope, filter, etc.) is used to determining
- whether an entry or subentry in the list is returnable or not.
-
-
-6. Security Considerations
-
- Significant resources (CPU, memory, etc.) may be required at the
- server to process a VLV Operation, especially where the VLV Operation
- has been extended by Server-Side Sorting, Duplicate Entry, and other
- controls. Servers SHOULD provide administrative controls to limit the
- rate and/or kinds of VLV operations which can be submitted by
- authorized users.
-
- A single VLV operation does not directly disclose the size of the
- list. However, by issuing multiple VLV operations, an authorized
- client can determine the size of the list.
-
-
-7. IANA Considerations
-
- Registration of the following values is requested [RFC3383].
-
-
-7.1. Object Identifiers
-
- 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
- suggested:
-
-
-
-
-Zeilenga LDAP Virtual List View [Page 12]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments:
- Three delegations will be made under the assigned OID:
-
- IANA-ASSIGNED-OID.1 VLV Request Control
- IANA-ASSIGNED-OID.2 VLV Target Response Control
- IANA-ASSIGNED-OID.3 VLV Done Response Control
-
-
-7.2. LDAP Protocol Mechanism
-
- It is requested that IANA register upon Standards Action the LDAP
- protocol mechanism described in this document. The following
- registration template is suggested:
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID.1
- Description: VLV Request Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFCxxxx
- Author/Change Controller: IESG
- Comments: none
- in 2
-
-
-7.3. LDAP Result Codes
-
- It is requested that IANA register upon Standards Action the LDAP
- result codes:
-
- vlvTargetInvalid (IANA-ASSIGNED-1)
- vlvTargetNotFound (IANA-ASSIGNED-2)
- vlvWindowInvalid (IANA-ASSIGNED-3)
-
- The following registration template is suggested:
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: vlvTargetInvalid
- Result Code Name: vlvTargetNotFound
- Result Code Name: vlvWindowInvalid
-
-
-
-Zeilenga LDAP Virtual List View [Page 13]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments: request consecutive result codes be assigned
-
-
-8. Normative References
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished
- Names", RFC 2253, December 1997.
-
- [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
-
- [RFC2891] T. Howes, M. Wahl, A. Anantha, "LDAP Control Extension for
- Server Side Sorting of Search Results", RFC 2891, August
- 2000
-
- [RFC3296] K. Zeilenga, "Named Subordinate References in Lightweight
- Directory Access Protocol (LDAP) Directories", RFC 3296,
- July 2002.
-
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
- (v3): Technical Specification", RFC 3377, September 2002.
-
- [DUPENT] J. Sermersheim. "LDAP Control for a Duplicate Entry
- Representation of Search Results",
- draft-ietf-ldapext-ldapv3-dupent-xx.txt (a work in
- progress).
-
- [MATCHED] D. Chadwick, "Returning Matched Values with LDAPv3",
- draft-ietf-ldapext-matchedval-xx.txt (a work in progress).
-
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
- of Basic Notation", X.680, 1994.
-
- [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", X.690, 1994.
-
-
-9. Informative References
-
-
-
-Zeilenga LDAP Virtual List View [Page 14]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
-
- [SVB] D. Bozeman, J. Sermersheim, A. Kashi, "LDAP Extensions for
- Scrolling View Browsing of Search Results", draft-ietf-
- ldapext-ldapv3-vlv-08.txt (a work in progress).
-
-
-10. Acknowledgment
-
- This work benefited from prior work in this area, especially the
- paging and scrolling work done in IETF ASID and LDAPEXT working
- groups.
-
- This borrows significantly (both concepts and text) from the "LDAP
- Extensions for Scrolling View Browsing of Search Results" [SVB]
- Internet-Draft written by Dave Boreham, Jim Sermersheim, and Asaf
- Kashi.
-
-
-11. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-Appendix A. Using the VLV Operation
-
- This informative appendix discusses how the VLV operation can be used
- to page, scroll, and browse directory content.
-
- For the purposes of this discussion, let's assume we want to implement
- an address book application which allows the user to page, scroll, and
- browse address information held in an LDAP-accessible directory system
- using inetOrgPerson [RFC2798] schema.
-
- Say this application has a widget which is capable of displaying 10
- rows of information. In each row, we'll display the values of
- 'displayName' and 'mail' attributes of an entry.
-
- Aside from the usual search parameters (baseObject, scope, filter), we
- likely also want to sort the entries. So, initially, we'll provide a
- sort control which requests values be sorted by displayName.
-
-A.1. Widget Initialization
-
- There are multiple VLV operations which might be used to initialize
- the widget. To initialize the widget with the first 10 entries of the
-
-
-
-Zeilenga LDAP Virtual List View [Page 15]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- list, the VLV request <tOffset=0, tReverse=False, wOffset=0,
- wCount=10, wReverse=False> can be used. To initialize the widget with
- the middle 10 entries, the VLV request <tNumerator=1, tDenominator=2,
- tReverse=False, wOffset=-5, wCount=10, wReverse=False> can be used.
- To initialize the widget to the last 10 entries, the VLV request
- <tNumerator=1, tDenominator=1, tReverse=False, wOffset=-9, wCount=10,
- wReverse=False> can be used.
-
- However, as the last 10 entries of in the list may not be returnable,
- it may be more appropriate to request <tNumerator=1, tDenominator=1,
- tReverse=False, wOffset=0, wCount=10, wReverse=True> instead. Note
- that since wReverse is selected, the last entry is returned first.
-
- The widget can also be initialized to the entries surrounding a known
- DN by sending the request <tName="cn=kdz,dc=example,dc=com",
- tReverse=False, wOffset=-5, wCount=10, wReverse=False>.
-
- The widget can also be initialized based upon "typedown" criteria.
- Typedown is discussed in A.4.
-
-
-A.2. Slider navigation
-
- Most list widgets allow based upon proportional positioning of a
- slider. Our widget reports the slider's position as the percentage
- the area above the slider position to the total slider area. When it
- is repositioned, the application can request <tNumerator=percent,
- tDenominator=100, tReverse=False, wOffset=-5, wCount=10,
- wReverse=False> when percent is less than or equal to 50 and
- <tNumerator=percent, tDenominator=100, tReverse=False, wOffset=5,
- wCount=10, wReverse=True> when percent is less than or equal to 50.
- Because the list may contain non-returnable entries, we reverse the
- window as we approach the tail of the list. When wReverse is True,
- the last entry is returned first.
-
-
-A.3. Page navigation
-
- Most list widgets provide page up/down controls.
-
- When page down is selected, the application can request <tName=last,
- tReverse=False, wOffset=0, wCount=10, wReverse=False> where last is
- the name of the entry presently at the bottom of the current widget
- view. The server will then return a new view in forward order. When
- inserted into the widget, the target will appear at the top of the
- current widget view.
-
- When page up is selected, the application can request <tName=first,
-
-
-
-Zeilenga LDAP Virtual List View [Page 16]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- tReverse=False, wOffset=0, wCount=10, wReverse=Reverse> where first is
- the name of the entry presently at the top of the current view. The
- server will then return a new view in reverse order with the named
- entry returned first. When inserted into the widget, the target will
- appear at the bottom the current widget view.
-
- If the page up/down VLV operation returns vlvTargetNotFound, the
- application can reissue the page up/down VLV operation with the name
- of the entry nearest the top/bottom of the present widget view.
-
- It is noted that when named entry is modified prior to issuing of the
- VLV operation in a manner which affects its position in the list, the
- view will follow the named entry.
-
-
-A.4. Type down navigation
-
- Type down navigation can be used to navigate the list.
-
- The list is sorted by 'displayName'. When the user types in a partial
- or complete value, the application can use this value to present the
- 10 values at are below the value.
-
- So, for example, the user inputs "K", the application can request
- <tTypeDown="K", tReverse=False, wOffset=0, wCount=10, wReverse>.
- Desiring further typedown, the user inputs "Kurt" and the application
- requests <tTypeDown="Kurt", tReverse=False, wOffset=0, wCount=10,
- wReverse>. Etc.
-
-
-Copyright 2002, The Internet Society. 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.
-
-
-
-
-Zeilenga LDAP Virtual List View [Page 17]
-\f
-INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
-
-
- 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,
- 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 Virtual List View [Page 18]
-\f
projects / openldap / commitdiff