INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-13.txt Novell, Inc.
-Obsoletes: 2829, 2830 October, 2004
+draft-ietf-ldapbis-authmeth-14.txt Novell, Inc.
+Obsoletes: 2829, 2830 February, 2005
Intended Category: Draft Standard
-
LDAP: Authentication Methods
and
Connection Level Security Mechanisms
-
Status of this Memo
-
By submitting this Internet-Draft, I accept the provisions of
Section 4 of RFC 3667. By submitting this Internet-Draft, I certify
that any applicable patent or other IPR claims of which I am aware
have been disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
-
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
editorial comments directly to the author
<roger_harrison@novell.com>.
-
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
-
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
-
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
-
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
-
Copyright Notice
-
Copyright (C) The Internet Society (2004). All Rights Reserved.
-
Abstract
-
-Harrison Expires April 2005 [Page 1]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
+Harrison Expires August 2005 [Page 1]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
This document describes authentication methods and connection level
security mechanisms of the Lightweight Directory Access Protocol
(LDAP).
-
This document details establishment of TLS (Transport Layer
Security) using the StartTLS operation.
-
This document details the simple Bind authentication method
including anonymous, unauthenticated, and plain-text password
mechanisms and the SASL (Simple Authentication and Security Layer)
Bind authentication method including DIGEST-MD5 and EXTERNAL
mechanisms.
-
This document discusses various authentication and authorization
states through which a connection to an LDAP server may pass and the
actions that trigger these state changes.
-
Table of Contents
-
1. Introduction.....................................................3
1.1. Relationship to Other Documents................................5
- 1.2. Conventions Used in this Document..............................6
- 1.2.1. Glossary of Terms............................................6
- 1.2.2. Security Terms and Concepts..................................6
- 1.2.3. Keywords.....................................................6
+ 1.2. Conventions....................................................5
2. Implementation Requirements......................................6
3. StartTLS Operation...............................................7
3.1. Sequencing of the StartTLS Operation...........................7
3.1.2. StartTLS Response............................................8
3.1.3. TLS Version Negotiation......................................8
3.1.4. Client Certificate...........................................8
- 3.1.5. Discovery of Resultant Security Level........................9
+ 3.1.5. Discovery of Resultant Security Level........................8
3.1.6. Server Identity Check........................................9
- 3.1.7. Refresh of Server Capabilities Information..................10
+ 3.1.7. Refresh of Server Capabilities Information...................9
3.2. Effects of TLS on a Client's Authorization Identity...........10
- 3.2.1. TLS Connection Establishment Effects........................10
- 3.2.2. Client Assertion of Authorization Identity..................10
- 3.2.3. TLS Connection Closure Effects..............................10
- 3.3. TLS Ciphersuites..............................................11
- 3.3.1. TLS Ciphersuites Recommendations............................11
- 4. Associations....................................................12
- 4.1. Anonymous Association on Unbound Connections..................12
+ 3.3. TLS Ciphersuites..............................................10
+ 3.3.1. TLS Ciphersuites Recommendations............................10
+ 4. Associations....................................................11
+ 4.1. Anonymous Association on Unbound Connections..................11
4.2. Anonymous Association After Failed Bind.......................12
4.3. Invalidated Associations......................................12
- 5. Bind Operation..................................................13
- 5.1. Simple Authentication Choice..................................13
- 5.2. SASL Authentication Choice....................................13
+ 5. Bind Operation..................................................12
+ 5.1. Simple Authentication Choice..................................12
+ 5.2. SASL Authentication Choice....................................12
6. Anonymous Authentication Mechanism of Simple Bind...............13
7. Unauthenticated Authentication Mechanism of Simple Bind.........13
-
-
-
-Harrison Expires April 2005 [Page 2]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- 8. Simple Authentication Mechanism of Simple Bind .................14
- 9. SASL Protocol Profile...........................................15
- 9.1. SASL Service Name for LDAP....................................15
- 9.2. SASL Authentication Initiation and Protocol Exchange..........15
- 9.3. Octet Where Negotiated Security Mechanisms Take Effect........16
- 9.4. Determination of Supported SASL Mechanisms....................16
- 9.5. Rules for Using SASL Security Layers..........................17
- 9.6 Support for Multiple Authentications...........................17
- 10. SASL EXTERNAL Authentication Mechanism.........................17
- 10.1. Implicit Assertion...........................................17
- 10.2. Explicit Assertion...........................................18
- 10.3. SASL Authorization Identity..................................18
- 10.4. SASL Authorization Identity Syntax...........................18
- 11. SASL DIGEST-MD5 Authentication Mechanism.......................19
- 12. Security Considerations........................................19
- 12.1. General LDAP Security Considerations.........................19
- 12.1.1. Password-related Security Considerations...................20
+ 8. Simple Authentication Mechanism of Simple Bind .................13
+ 9. SASL Protocol Profile...........................................14
+ 9.1. SASL Service Name for LDAP....................................14
+ 9.2. SASL Authentication Initiation and Protocol Exchange..........14
+ 9.3. Octet Where Negotiated Security Mechanisms Take Effect........15
+ 9.4. Determination of Supported SASL Mechanisms....................15
+
+
+Harrison Expires August 2005 [Page 2]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
+ 9.5. Rules for Using SASL Layers...................................16
+ 9.6 Support for Multiple Authentications...........................16
+ 9.7. SASL Authorization Identities.................................16
+ 10. SASL DIGEST-MD5 Authentication Mechanism.......................17
+ 11. SASL EXTERNAL Authentication Mechanism.........................17
+ 11.1. Implicit Assertion...........................................18
+ 11.2. Explicit Assertion...........................................18
+ 12. Security Considerations........................................18
+ 12.1. General LDAP Security Considerations.........................18
+ 12.1.1. Password-related Security Considerations...................19
12.2. StartTLS Security Considerations.............................20
- 12.3. Unauthenticated Mechanism Security Considerations............21
+ 12.3. Unauthenticated Mechanism Security Considerations............20
12.4. Simple Mechanism Security Considerations.....................21
12.5. SASL DIGEST-MD5 Mechanism Security Considerations............21
- 12.6. Related Security Considerations..............................22
- 13. IANA Considerations............................................22
- Acknowledgments....................................................22
- Normative References...............................................22
+ 12.6. Related Security Considerations..............................21
+ 13. IANA Considerations............................................21
+ Acknowledgments....................................................21
+ Normative References...............................................21
Informative References.............................................23
- Author's Address...................................................24
- Appendix A. Association State Transition Tables....................24
- A.1. Association States............................................24
- A.2. Actions that Affect Association State.........................25
- A.3. Decisions Used in Making Association State Changes............25
- A.4. Association State Transition Table............................25
- Appendix B. Authentication and Authorization Concepts..............26
- B.1. Access Control Policy.........................................26
- B.2. Access Control Factors........................................26
- B.3. Authentication, Credentials, Identity.........................27
- B.4. Authorization Identity........................................27
- Appendix C. RFC 2829 Change History................................27
- Appendix D. RFC 2830 Change History................................31
- Appendix E. RFC 2251 Change History................................32
- Appendix F. Change History to Combined Document....................32
- Added implementation requirement that server implementations ......45
+ Author's Address...................................................23
+ Appendix A. Association State Transition Tables....................23
+ A.1. Association States............................................23
+ A.2. Actions that Affect Association State.........................24
+ A.3. Association State Transition Table............................24
+ Appendix B. Authentication and Authorization Concepts..............25
+ B.1. Access Control Policy.........................................25
+ B.2. Access Control Factors........................................25
+ B.3. Authentication, Credentials, Identity.........................25
+ B.4. Authorization Identity........................................25
+ Appendix C. RFC 2829 Change History................................26
+ Appendix D. RFC 2830 Change History................................30
+ Appendix E. RFC 2251 Change History................................30
+ Appendix F. Change History to Combined Document....................31
Intellectual Property Rights.......................................45
-
1. Introduction
-
The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
powerful protocol for accessing directories. It offers means of
-
-
-
-
-Harrison Expires April 2005 [Page 3]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
searching, retrieving and manipulating directory content, and ways
to access a rich set of security functions.
-
It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be
a minimum subset of security functions that is common to all
implementations that claim LDAP conformance.
-
Basic threats to an LDAP directory service include:
- (1) Unauthorized access to directory data via data-retrieval
- operations,
-
- (2) Unauthorized access to directory data by monitoring others'
- access,
+Harrison Expires August 2005 [Page 3]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- (3) Unauthorized access to reusable client authentication
- information by monitoring others' access,
+ (1) Unauthorized access to directory data via data-retrieval
+ operations.
+ (2) Unauthorized access to directory data by monitoring others'
+ access.
- (4) Unauthorized modification of directory data,
+ (3) Unauthorized access to reusable client authentication
+ information by monitoring others' access.
+ (4) Unauthorized modification of directory data.
(5) Unauthorized modification of configuration information,
-
(6) Denial of Service: Use of resources (commonly in excess) in a
- manner intended to deny service to others,
-
+ manner intended to deny service to others.
(7) Spoofing: Tricking a user or client into believing that
information came from the directory when in fact it did not,
information to a hostile entity that appears to be the directory
server but is not. Tricking a directory server into believing
that information came from a particular client when in fact it
- came from a hostile entity, and
-
+ came from a hostile entity.
(8) Hijacking: An attacker seizes control of an established protocol
session.
-
Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
(2) and (3) are passive attacks.
-
Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3), (7) and (8) are due to hostile agents on the path between
client and server or hostile agents posing as a server, e.g. IP
spoofing.
-
-
LDAP offers the following security mechanisms:
-
(1) Authentication by means of the Bind operation. The Bind
operation provides a simple method which supports anonymous,
- unauthenticated, and authenticated with password mechanisms, and
+ unauthenticated, and authenticated-with-password mechanisms, and
the Secure Authentication and Security Layer (SASL) method which
supports a wide variety of authentication mechanisms,
-
-Harrison Expires April 2005 [Page 4]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
(2) Mechanisms to support vendor-specific access control facilities
(LDAP does not offer a standard access control facility)
-
(3) Data integrity protection by means of security layers in TLS or
SASL mechanisms,
-
(4) Data confidentiality protection by means of security layers in
TLS or SASL mechanisms,
+
+Harrison Expires August 2005 [Page 4]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
(5) Server resource usage limitation by means of administrative
limits configured on the server, and
-
(6) Server authentication by means of the TLS protocol or SASL
- mechanism.
-
+ mechanisms.
LDAP may also be protected by means outside the LDAP protocol, e.g.
with IP-level security [RFC2401].
-
At the moment, imposition of access controls is done by means
outside the scope of LDAP.
-
Considering the above requirements, experience has shown that simply
allowing implementations to pick and choose among the possible
alternatives is not a strategy that leads to interoperability. In
they will support only clear text passwords that provide inadequate
security for most circumstances.
-
It is desirable to allow clients to authenticate using a variety of
mechanisms including mechanisms where identities are represented as
distinguished names [X.501] [Models] in string form [LDAPDN] or are
implement mechanism for establishing transport-layer security
services.
-
The set of security mechanisms provided in LDAP and described in
this document is intended to meet the security needs for a wide
range of deployment scenarios and still provide a high degree of
mechanisms that might be used to achieve a reasonable level of
security in various circumstances.
-
1.1. Relationship to Other Documents
-
This document is an integral part of the LDAP Technical
Specification [Roadmap].
-
This document obsoletes RFC 2829.
-
-Harrison Expires April 2005 [Page 5]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document.
+1.2. Conventions
-1.2. Conventions Used in this Document
-
-
-1.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).
+ 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].
- - "connection" refers to the underlying transport protocol
- connection used to carry the protocol exchange.
+Harrison Expires August 2005 [Page 5]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- - "TLS connection" refers to an LDAP connection with TLS
- protection [TLS].
+ The term "user" represents any human or application entity which is
+ accessing the directory using a directory client. A directory
+ client (or client) is also known as a directory user agent (DUA).
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as
+ associations established by these services.
- - "association" refers to the association that exists between the
- connection to its current authorization state. As a shorthand,
- an association with an authorization state of <state> can be
- referred to as a "<state> association", e.g. an association with
- an anonymous authorization state is an anonymous association.
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
-1.2.2. Security Terms and Concepts
+ The term "LDAP message layer" refers to the LDAP Message (PDU)
+ services used in providing directory services, as well as
+ associations established by these services.
+ The term "association" refers to the association that exists between
+ the transport connection and its current authorization state. As a
+ shorthand, an association with an authorization state of <state> can
+ be referred to as a "<state> association", e.g. an association with
+ an anonymous authorization state is an anonymous association.
In general, security terms in this document are used consistently
with the definitions provided in [RFC2828]. In addition, several
unfamiliar with security-related concepts are encouraged to review
Appendix C before reading the remainder of this document.
-
-1.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].
-
-
2. Implementation Requirements
-
LDAP server implementations MUST support the anonymous
- authentication mechanism of simple bind (as discussed in Section 6).
-
+ authentication mechanism of simple bind (section 6).
LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of simple bind MUST
- support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (as
- detailed in section 11). DIGEST-MD5 is a reasonably strong
-
-
-Harrison Expires April 2005 [Page 6]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
+ support the DIGEST-MD5 [DIGEST-MD5] mechanism of SASL bind (section
+ 10). DIGEST-MD5 is a reasonably strong authentication mechanism
+ that provides (mandatory-to-implement) data security (data integrity
+ and data confidentiality) services.
- authentication mechanism that provides (mandatory-to-implement) data
- security (data integrity and data confidentiality) services.
+ LDAP implementations SHOULD support the simple (DN and password)
+ authentication mechanism of simple bind (section 8).
+ Implementations that support this authentication mechanism MUST be
+ capable of protecting using TLS as established by the StartTLS
+ operation (section 3), SHOULD disallow the use of this
+Harrison Expires August 2005 [Page 6]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- LDAP impementations SHOULD support the simple (DN and password)
- authentication mechanism of simple bind (as detailed in section 8).
- Implementations that support this mechanism MUST be capable of
- protecting it by establishment of TLS (as discussed in section 3) or
- other suitable suitable data confidentiality and data integrity
- protection (e.g. IPSec).
-
+ authentication mechanism by default when suitable data security
+ services are not in place, and MAY provide other suitable data
+ security services for use with this authentication mechanism.
Implementations MAY support additional authentication mechanisms.
Some of these mechanisms are discussed below.
-
LDAP server implementations SHOULD support client assertion of
authorization identity via the SASL EXTERNAL mechanism (sections
3.2.2 and 9).
-
- LDAP server implementations SHOULD support the StartTLS operation,
- and server implementations that do support the StartTLS operation
- MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
+ LDAP server implementations SHOULD support the StartTLS operation
+ (section 3), and server implementations that do support the StartTLS
+ operation MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+ ciphersuite.
3. StartTLS Operation
-
The Start Transport Layer Security (StartTLS) operation defined in
section 4.14 of [Protocol] provides the ability to establish TLS
[TLS] on an LDAP connection.
-
The goals of using the TLS [TLS] protocol with LDAP are to ensure
data confidentiality and integrity, and to optionally provide for
authentication. TLS expressly provides these capabilities, although
the authentication services of TLS are available to LDAP only in
combination with the SASL EXTERNAL authentication method (see
- section 10), and then only if the SASL EXTERNAL implementation
+ section 11), and then only if the SASL EXTERNAL implementation
chooses to make use of the TLS credentials.
-
3.1. Sequencing of the StartTLS Operation
-
This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into
consideration various aspects of the association including discovery
of resultant security level and assertion of the client's
authorization identity.
-
3.1.1. StartTLS Request
-
A client may send the StartTLS extended request at any time after
establishing an LDAP connection, except:
-
- when TLS is currently established on the connection,
- when a multi-stage SASL negotiation is in progress on the
connection, or
- when it has not yet received responses for all operation
requests previously issued on the connection.
-
-
-Harrison Expires April 2005 [Page 7]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
As described in [Protocol] Section 4.14.2.2, a (detected) violation
of any of these requirements results in a return of the
operationsError resultCode.
+
+Harrison Expires August 2005 [Page 7]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
Client implementers should ensure that they strictly follow these
operation sequencing requirements to prevent interoperability
issues. Operational experience has shown that violating these
these requirements due to server hardware speed, network latencies,
etc.
-
There is no general requirement that the client have or have not
already performed a Bind operation (section 4) before sending a
StartTLS operation request.
-
- If the client did not establish a TLS connection before sending a
- request and the server requires the client to establish a TLS
- connection before performing that request, the server MUST reject
- that request by sending a resultCode of confidentialityRequired.
-
-
3.1.2. StartTLS Response
-
The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS.
-
- It will return a resultCode other than success (documented in
+ It will return a resultCode other than success (as documented in
[Protocol] section 4.13.2.2) if it is unwilling or unable to do so.
The state of the association is unaffected if a non-success
resultCode is returned.
-
In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
- server to initiate [TLS] negotiation.
-
+ server during TLS negotiation.
3.1.3. TLS Version Negotiation
-
Negotiating the version of TLS to be used is a part of the TLS
Handshake Protocol [TLS]. Please refer to that document for details.
-
3.1.4. Client Certificate
-
If an LDAP server requests a client to provide its certificate
during TLS negotiation and the client does not present a suitable
certificate (e.g. one that can be validated), the server may use a
local security policy to determine whether to successfully complete
- TLS negotiation.
-
-
- If the client provides a certificate that can be validated,
- information in the certificate may be used by the server in
- establishing the client's authorization identity by use of the SASL
- EXTERNAL mechanism as discussed in Section 9.
-
-
-Harrison Expires April 2005 [Page 8]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
+ TLS negotiation.
+ If a client that has provided a suitable certificate subsequently
+ binds using the SASL EXTERNAL authentication mechanism (section 9),
+ information in the certificate may be used by the server to
+ establish the client's authorization identity.
3.1.5. Discovery of Resultant Security Level
-
- After a TLS connection is established on an LDAP connection, both
+ After a TLS layer is established on a transport connection, both
parties are to individually decide whether or not to continue based
on the security level achieved. The procedure for ascertaining the
- TLS connection's security level is implementation dependent.
+ TLS layer's security level is implementation dependent.
+
+
+Harrison Expires August 2005 [Page 8]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
If the client or server decides that the security level is not high
- enough for it to continue, it SHOULD gracefully close the TLS
+ enough for it to continue, it SHOULD gracefully remove the TLS
connection immediately after the TLS negotiation has completed (see
[Protocol] section 4.13.3.1 and section 3.2.3 below). The client
- may then close the connection, attempt to StartTLS again, send an
- unbind request, or send any other LDAP request.
-
+ may then close the transport connection, attempt to StartTLS again,
+ send an unbind request, or send any other LDAP request.
3.1.6. Server Identity Check
-
The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's
Certificate message in order to prevent man-in-the-middle attacks.
-
Matching is performed according to these rules:
-
- The client MUST use the server name provided by the user (or
other trusted entity) as the value to compare against the server
name as expressed in the server's certificate. A hostname
derived from user input is to be considered provided by the user
only if derived in a secure fashion (e.g., DNSSEC).
-
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
-
- The string values to be compared MUST be prepared according to
the rules described in [Matching].
-
- 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
+ certificate (e.g. more than one dNSName name), a match with 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
- continue with the connection in any case) or terminate the
+ continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect.
- Automated clients SHOULD close the connection, returning and/or
- logging an error indicating that the server's identity is suspect.
-
-
-
-
-Harrison Expires April 2005 [Page 9]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
+ Automated clients SHOULD close the connection and then return
+ and/or log 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
+ is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
-
3.1.7. Refresh of Server Capabilities Information
- Upon TLS session establishment, the client SHOULD discard or refresh
+
+Harrison Expires August 2005 [Page 9]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
+ Upon installing a TLS layer, the client SHOULD discard or refresh
all information about the server it obtained prior to the initiation
of the TLS negotiation and not obtained through secure mechanisms.
This protects against man-in-the-middle attacks that may have
altered any server capabilities information retrieved prior to TLS
- establishment.
-
+ layer installation.
- 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
+ The server may advertise different capabilities after installing a
+ TLS layer. In particular, the value of supportedSASLMechanisms may
+ be different after a TLS layer has been installed (specifically, the
EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
- after a TLS negotiation has been performed).
-
+ after a TLS layer has been installed).
3.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 connection.
- The default effects are described first, and next the facilities for
- client assertion of authorization identity are discussed including
- error conditions. Finally, the effects of closing the TLS connection
- are described.
-
-
- Authorization identities and related concepts are described in
- Appendix B.
-
-
-3.2.1. TLS Connection Establishment Effects
-
-
- The decision to keep or invalidate the established state of the
- association (section 4.3) after TLS connection establishment is a
- matter of local server policy.
-
-
-3.2.2. Client Assertion of Authorization Identity
-
-
- After successfully establishing a TLS session, a client may request
- that its certificate exchanged during the TLS establishment be
- utilized to determine the authorization identity of the association.
- The client accomplishes this via an LDAP Bind request specifying a
- SASL mechanism of EXTERNAL [SASL] (section 10).
-
-
-3.2.3. TLS Connection Closure Effects
-
-
The decision to keep or invalidate the established state of the
- association after TLS closure is a matter of local server policy.
-
+ association (section 4.3) after TLS layer installation or removal is
+ a matter of local server policy.
3.3. TLS Ciphersuites
-
-
-Harrison Expires April 2005 [Page 10]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
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
+ protection for passwords and other data sent over the transport
connection. Client and server implementers should recognize that
some TLS ciphersuites provide no confidentiality protection
while other ciphersuites that do provide confidentiality
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
+ - 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.
-
3.3.1. TLS Ciphersuites Recommendations
-
[[TODO: Kurt will have someone from security to look at this and
will propose how to handle discussion of specific TLS ciphersuites
in this draft.]]
-
As of the writing of this document, the following recommendations
regarding TLS ciphersuites are applicable. Because circumstances are
+
+Harrison Expires August 2005 [Page 10]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
constantly changing, this list must not be considered exhaustive,
but is hoped that it will serve as a useful starting point for
implementers.
-
The following ciphersuites defined in [TLS] MUST NOT be used for
confidentiality protection of passwords or data:
-
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
-
The following ciphersuites defined in [TLS] can be cracked easily
(less than a day of CPU time on a standard CPU in 2000) and are NOT
RECOMMENDED for use in confidentiality protection of passwords or
data:
-
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
-
-
-Harrison Expires April 2005 [Page 11]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
-
The following ciphersuites are vulnerable to man-in-the-middle
attacks:
-
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
-
4. Associations
-
Every LDAP connection has an associated authorization state referred
to as the "association". The Bind operation defined in section 4.2
of [Protocol] and discussed further in section 5 below allows
information to be exchanged between the client and server to change
the authorization state of the association.
-
4.1. Anonymous Association on Unbound Connections
-
Prior to the successful completion of a Bind operation and during
any subsequent authentication exchange, the association has an
anonymous authorization state. Among other things this implies that
- the client need not send a Bind Request in the first PDU of the
- connection. The client may send any operation request prior to
+ the client need not send a Bind Request in the first PDU of the LDAP
+ message layer. The client may send any operation request prior to
binding, and the server MUST treat it as if it had been performed
after an anonymous bind operation (section 6). This association
state is sometimes referred to as an implied anonymous bind.
-4.2. Anonymous Association After Failed Bind
+Harrison Expires August 2005 [Page 11]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+4.2. Anonymous Association After Failed Bind
Upon receipt of a Bind request, the association is moved to an
anonymous state and only upon successful completion of the
moved to an authenticated state. Thus, a failed Bind operation
produces an anonymous association.
-
4.3. Invalidated Associations
-
The server may move the association to an invalidated state at any
time, e.g. if an established security layer between the client and
- server has unexpectedly failed or been compromised. While the
- connection has an invalid association, the server may reject any
+ server has unexpectedly failed or been compromised. While the LDAP
+ session has an invalidated association, the server may reject any
operation request other than Bind, Unbind, and StartTLS by
- responding with a resultCode of strongAuthRequired to indicate that
- the server requires stronger authentication before it will attempt
- to perform the requested operation. In practice, this means that the
- client needs to bind to(re)establish a suitably strong authorization
-
-
-
-
-Harrison Expires April 2005 [Page 12]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- state on the association before the server will attempt to perform
- the requested operation.
-
+ responding with a resultCode of strongerAuthRequired to indicate
+ that the server requires stronger authentication before it will
+ attempt to perform the requested operation. In practice, this means
+ that the client needs to bind to(re)establish a suitably strong
+ authorization state on the association before the server will
+ attempt to perform the requested operation.
5. Bind Operation
-
The Bind operation ([Protocol] section 4.2) allows authentication
information to be exchanged between the client and server to
establish a new authorization state on the association.
-
The Bind request typically specifies the desired authentication
identity. Some Bind mechanisms also allow the client to specify the
authorization identity. If the authorization identity is not
specified, the server derives it from the authentication identity in
an implementation-specific manner.
-
If the authorization identity is specified the server MUST verify
that the client's authentication identity is permitted to assume
(e.g. proxy for) the asserted authorization identity. The server
MUST reject the Bind operation with an invalidCredentials resultCode
in the Bind response if the client is not so authorized.
-
5.1. Simple Authentication Choice
-
The simple authentication choice of the Bind Operation provides
three authentication mechanisms:
+ 1. An anonymous authentication mechanism (section 6),
- 1. an anonymous authentication mechanism (section 6),
-
+ 2. An unauthenticated authentication mechanism (section 7), and
- 2. an unauthenticated authentication mechanism (section 7), and
-
-
- 3. a simple authentication mechanism using credentials consisting
+ 3. A simple authentication mechanism using credentials consisting
of a name (in the form of an LDAP distinguished name [LDAPDN])
and a password (section 8).
-
5.2. SASL Authentication Choice
+Harrison Expires August 2005 [Page 12]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
The sasl authentication choice of the Bind Operation provides
facilities for using any SASL mechanism (sections 9-11) including
authentication mechanisms and other services (e.g. data security
services).
-
6. Anonymous Authentication Mechanism of Simple Bind
-
An LDAP client may use the anonymous authentication mechanism of the
simple Bind choice to explicitly establish an anonymous association
- by sending a Bind request with a name value of zero length and with
- the simple authentication choice containing a password value of zero
- length.
-
+ by sending a Bind request with a name value of zero length and
+ specifying the simple authentication choice containing a password
+ value of zero length.
7. Unauthenticated Authentication Mechanism of Simple Bind
-
An LDAP client may use the unauthenticated authentication mechanism
of the simple Bind choice to establish an anonymous association by
sending a Bind request with a name value, a distinguished name in
-
-
-Harrison Expires April 2005 [Page 13]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- LDAP string form [LDAPDN], of non-zero length, and specifying the
- the simple authentication choice containing a password value of zero
+ LDAP string form [LDAPDN] of non-zero length, and specifying the the
+ simple authentication choice containing a password value of zero
length.
-
Unauthenticated binds can have significant security issues (see
section 12.3). Servers SHOULD by default reject unauthenticated bind
requests with a resultCode of invalidCredentials, and clients may
need to actively detect situations where they would unintentionally
make an unauthenticated bind request.
-
8. Simple Authentication Mechanism of Simple Bind
-
An LDAP client may use the simple authentication mechanism of the
simple Bind choice to establish an authenticated association by
sending a Bind request with a name value, a distinguished name in
- LDAP string form [LDAPDN], and specifying the simple authentication
- choice containing an OCTET STRING password value of non-zero length.
-
+ LDAP string form [LDAPDN] of non-zero length, and specifying the
+ simple authentication choice containing an OCTET STRING password
+ value of non-zero length.
Servers that map the DN sent in the bind request to a directory
entry with an associated set of one or more passwords used with this
- mechanism, will compare the presented password to that set of
+ mechanism will compare the presented password to that set of
passwords. The presented password is considered valid if it matches
any member of this set.
-
- If the DN is syntactically invalid, the server returns the
- invalidDNSyntax result code. If the DN is syntactically correct but
- not valid for purposes of authentication, or the password is not
+ A resultCode of invalidDNSyntax indicates that the DN sent in the
+ name value is syntactically invalid. A resultCode of
+ invalidCredentials indicates that the DN is syntactically correct
+ but not valid for purposes of authentication, or the password is not
valid for the DN, or the server otherwise considers the credentials
- to be invalid, the server returns the invalidCredentials result
- code. The server is only to return the success result code when the
- credentials are valid and the server is willing to provide service
- to the entity these credentials identify.
+ to be invalidA resultCode of success indicates that the credentials
+ are valid and the server is willing to provide service to the entity
+ these credentials identify.
+
+
+Harrison Expires August 2005 [Page 13]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
Server behavior is undefined for bind requests specifying the simple
authentication mechanism with a zero-length name value and a
password value of non-zero length.
-
-
The simple authentication mechanism of simple bind is not suitable
for authentication in environments where there is no network or
- transport layer confidentiality. LDAP implementations SHALL NOT
- support this mechanism unless they are capable of protecting it by
- establishment of TLS (as discussed in section 3) or other suitable
- data confidentiality and data integrity protection(e.g. IPSec). LDAP
- implementations SHOULD support authentication with the "simple"
- authentication choice when the connection is protected against
- eavesdropping using TLS, as defined in section 3. 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.
-
+ transport layer confidentiality.x
9. SASL Protocol Profile
-
-
-Harrison Expires April 2005 [Page 14]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
includes native anonymous and simple (plain text) authentication
methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms
are typically not used with LDAP.
-
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.
-
9.1. SASL Service Name for LDAP
-
The SASL service name for LDAP is "ldap", which has been registered
with the IANA as a SASL service name.
-
9.2. SASL Authentication Initiation and Protocol Exchange
-
- SASL authentication is initiated via an LDAP bind request
+ SASL authentication is initiated via an LDAP Bind request
([Protocol] section 4.2) with the following parameters:
-
- The version is 3.
- The AuthenticationChoice is sasl.
- The mechanism element of the SaslCredentials sequence contains
mechanisms that are defined to have the client send data first
(see [SASL] sections 5 and 5.1).
-
In general, a SASL authentication protocol exchange consists of a
series of server challenges and client responses, the contents of
which are specific to and defined by the SASL mechanism. Thus for
some SASL authentication mechanisms, it may be necessary for the
client to respond to one or more server challenges by invoking the
- BindRequest multiple times. A challenge is indicated by the server
- sending a BindResponse with the resultCode set to
+ Bind operation multiple times. A challenge is indicated by the
+ server sending a BindResponse PDU with the resultCode set to
saslBindInProgress. This indicates that the server requires the
- client to send a new bind request with the same sasl mechanism to
+ client to send a new BindRequest PDU with the same sasl mechanism to
continue the authentication process.
-
- To the LDAP protocol, these challenges and responses are opaque
+ To LDAP message layer, these challenges and responses are opaque
binary tokens of arbitrary length. LDAP servers use the
- serverSaslCreds field, an OCTET STRING, in a 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
- protocols where SASL is used, LDAP is not text-based, thus no Base64
- transformations are performed on these challenge and response values.
+ serverSaslCreds field, an OCTET STRING, in a BindResponse PDU
+ message to transmit each challenge. LDAP clients use the credentials
+
+Harrison Expires August 2005 [Page 14]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ field, an OCTET STRING, in the SaslCredentials sequence of a
+ BindRequest PDU message to transmit each response. Note that unlike
+ some Internet protocols where SASL is used, LDAP is not text based,
+ thus no Base64 transformations are performed on these challenge and
+ response values.
- Clients sending a bind request with the sasl choice selected SHOULD
+ Clients sending a BindRequest with the sasl choice selected SHOULD
send an zero-length value in the name field. Servers receiving a
bind request with the sasl choice selected SHALL ignore any value in
the name field.
-
-
-Harrison Expires April 2005 [Page 15]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
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
+ an empty string, the server MUST return a BindResponse with a
+ resultCode of authMethodNotSupported. This will allow the client to
abort a negotiation if it wishes to try again with the same SASL
mechanism.
The server indicates completion of the SASL challenge-response
- exchange by responding with a bind response in which the resultCode
- is either success, or an error indication.
-
+ exchange by responding with a BindResponse in which the resultCode
+ is not saslBindInProgress (either success or another error
+ indication).
The serverSaslCreds field in the BindResponse can be used to include
an optional challenge with a success notification for mechanisms
SHALL omit the serverSaslCreds field (rather than including the
field with a zero-length value).
-
9.3. Octet Where Negotiated Security Mechanisms Take Effect
+ SASL layers take effect following the transmission by the server and
+ reception by the client of the final successful BindResponse in the
+ exchange.
- SASL security layers take effect following the transmission by the
- server and reception by the client of the final successful
- BindResponse in the exchange.
-
-
- Once a SASL security layer providing data integrity or
- confidentiality services takes effect, the layer remains in effect
- until a new layer is installed (i.e. at the first octet following
- the final BindResponse of the bind operation that caused the new
- layer to take effect). Thus, an established SASL security layer is
- not affected by a failed or non-SASL Bind.
-
+ Once a SASL layer providing data integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e. at the first octet following the final
+ BindResponse of the bind operation that caused the new layer to take
+ effect). Thus, an established SASL layer is not affected by a
+ failed or non-SASL Bind.
9.4. Determination of Supported SASL Mechanisms
-
Clients may determine the SASL mechanisms a server supports by
reading the supportedSASLMechanisms attribute from the root DSE
(DSA-Specific Entry) ([Models] section 5.1). The values of this
attribute, if any, list the mechanisms the server supports in the
- current LDAP session state. LDAP servers SHOULD allow an
- anonymously-bound client to retrieve the supportedSASLMechanisms
- attribute of the root DSE.
+Harrison Expires August 2005 [Page 15]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- Because SASL mechanisms provide critical security functions, clients
+ current LDAP session state. LDAP servers SHOULD allow a client with
+ an anonymous association to retrieve the supportedSASLMechanisms
+ attribute of the root DSE.
+
+ Because SASL mechanisms provide critical security functions, clients
and servers should be configurable to specify what mechanisms are
acceptable and allow only those mechanisms to be used. Both clients
and servers must confirm that the negotiated security level meets
their requirements before proceeding to use the connection.
+9.5. Rules for Using SASL Layers
-9.5. Rules for Using SASL Security Layers
-
-
-
-
-Harrison Expires April 2005 [Page 16]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- If a SASL security layer is negotiated, the client SHOULD discard
- information about the server it obtained prior to the initiation of
- the SASL negotiation and not obtained through secure mechanisms.
-
-
- If a lower level security layer (such as TLS) is negotiated, any
- SASL security services SHALL be layered on top of such security
- layers regardless of the order of their negotiation. In all other
- respects, SASL security services and other security layers act
- independently, e.g. if both TLS and SASL security service are in
- effect then removing the SASL security service does not affect the
- continuing service of TLS and vice versa.
+ If a SASL layer is installed, the client SHOULD discard information
+ about the server it obtained prior to the initiation of the SASL
+ negotiation and not obtained through secure mechanisms.
+ If a lower level security layer (such as TLS) is installed, any SASL
+ layer SHALL be layered on top of such security layers regardless of
+ the order of their negotiation. In all other respects, the SASL
+ layer and other security layers act independently, e.g. if both a
+ TLS layer and a SASL layer are in effect then removing the SASL
+ layer does not affect the continuing service of the TLS layer and
+ vice versa.
9.6 Support for Multiple Authentications
-
LDAP supports multiple SASL authentications as defined in [SASL]
section 6.3.
+9.7. SASL Authorization Identities
-10. SASL EXTERNAL Authentication Mechanism
-
-
- A client can use the SASL EXTERNAL [SASL] mechanism to request the
- LDAP server to authenticate and establish a resulting authorization
- identity using security credentials exchanged by a lower security
- layer (such as by TLS authentication or IP-level security
- [RFC2401]).
-
-
- The authorization identity used to determine the state of the
- association is derived from the security credentials in an
- implementation-specific manner. If the client's authentication
- credentials have not been established at a lower security layer, the
- SASL EXTERNAL bind MUST fail with a resultCode of
- inappropriateAuthentication. Although this situation has the effect
- of leaving the association in an anonymous state (section 5), the
- state of any established security layer is unaffected.
-
-
- A client may either implicitly request that its authorization
- identity be derived from its authentication credentials exchanged at
- a lower security layer or it may explicitly provide an authorization
- identity and assert that it be used in combination with those
- authentication credentials. The former is known as an implicit
- assertion, and the latter as an explicit assertion.
-
-
-10.1. Implicit Assertion
-
-
- An implicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that does not include the optional credentials octet
- string (found within the SaslCredentials sequence in the Bind
- Request). The server will derive the client's authorization identity
- from the authentication identity supplied by the security layer
- (e.g., a public key certificate used during TLS establishment)
- according to local policy. The underlying mechanics of how this is
- accomplished are implementation specific.
-
-
-10.2. Explicit Assertion
-
-
-Harrison Expires April 2005 [Page 17]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
- An explicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that includes the credentials octet string. This
- string MUST be constructed as documented in section 10.4.
-
-
-10.3. SASL Authorization Identity
-
-
- When the EXTERNAL SASL mechanism is being negotiated, if the
- 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.
-
-
-10.4. SASL Authorization Identity Syntax
-
-
- The authorization identity is a string of UTF-8 [RFC3629] encoded
- [Unicode] characters corresponding to the following ABNF [RFC2234]
- grammar:
-
+ Some SASL mechanisms allow clients to request a desired
+ authorization identity for the association. The decision to allow or
+ disallow the current authentication identity to have access to the
+ requested authorization identity is a matter of local policy ([SASL]
+ section 4.2). The authorization identity is a string of UTF-8
+ [RFC3629] encoded [Unicode] characters corresponding to the
+ following ABNF [RFC2234] grammar:
authzId ::= dnAuthzId / uAuthzId
-
DNCOLON ::= %x64 %x6e %x3a ; "dn:"
UCOLON ::= %x75 %x3a ; "u:"
-
; distinguished-name-based authz id.
dnAuthzId ::= DNCOLON distinguishedName
-
; unspecified authorization id, UTF-8 encoded.
uAuthzId ::= UCOLON userid
userid ::= *UTF8 ; syntax unspecified
-
where the <distinguishedName> production is defined in section 3 of
- [LDAPDN] and <UTF8> production is defined in section 1.3 of [Models].
+ [LDAPDN] and the <UTF8> production is defined in section 1.3 of
+ [Models].
+
+Harrison Expires August 2005 [Page 16]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
In order to support additional specific authorization identity
forms, future updates to this specification may add new choices
supporting other forms of the authzId production.
-
The dnAuthzId choice is used to assert authorization identities in
the form of a distinguished name to be matched in accordance with
- the distinguishedNameMatch matching rule [Syntaxes]. 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 the directory.
-
+ the distinguishedNameMatch matching rule [Syntaxes]. There is no
+ requirement that the asserted distinguishedName value be that of an
+ entry in the directory.
The uAuthzId choice allows clients to assert an authorization
identity that is not in distinguished name form. The format of
userid is defined as only a sequence of UTF-8 [RFC3629] encoded
[Unicode] characters, and any further interpretation is a local
- matter. To compare uAuthzID values, each uAuthzID value MUST be
-
-
-
-Harrison Expires April 2005 [Page 18]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- prepared using [SASLPrep] and then the two values are compared
- octet-wise.
-
-
- For example, the userid could identify a user of a specific
+ matter. For example, the userid could identify a user of a specific
directory service, be a login name, or be an email address. A
- uAuthzId SHOULD NOT be assumed to be globally unique.
-
+ uAuthzId SHOULD NOT be assumed to be globally unique. To compare
+ uAuthzID values, each uAuthzID value MUST be prepared using
+ [SASLPrep] and then the two values are compared octet-wise.
-11. SASL DIGEST-MD5 Authentication Mechanism
+10. SASL DIGEST-MD5 Authentication Mechanism
-
- LDAP servers that implement any authentication method or mechanism
- other than simple anonymous bind MUST implement the SASL
- DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
+ The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks.
DIGEST-MD5 also provides data integrity and data confidentiality
capabilities.
-
Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
OPTIONAL in clients and servers.
-
Implementers must take care to ensure that they maintain the
semantics of the DIGEST-MD5 specification even when handling data
that has different semantics in the LDAP protocol.
being compared semantically as LDAP DNs because the cn attribute is
defined to be case insensitive, however the two values are not
equivalent if they represent username values in DIGEST-MD5 because
- [SASLPrep] semantics are used by DIGEST-MD5.
+ [SASLPrep] semantics are used by DIGEST-MD5.
+11. SASL EXTERNAL Authentication Mechanism
-12. Security Considerations
+ A client can use the SASL EXTERNAL [SASL] mechanism to request the
+ LDAP server to authenticate and establish a resulting authorization
+Harrison Expires August 2005 [Page 17]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
+ identity using security credentials exchanged by a lower security
+ layer (such as by TLS authentication or IP-level security
+ [RFC2401]).
+
+ The authorization identity used to determine the resulting
+ association is derived from the security credentials in an
+ implementation-specific manner. If the client's authentication
+ credentials have not been established at a lower security layer, the
+ SASL EXTERNAL bind MUST fail with a resultCode of
+ inappropriateAuthentication. Although this situation has the effect
+ of leaving the association in an anonymous state (section 5), the
+ state of any installed security layer is unaffected.
+
+ A client may either request that its authorization identity be
+ automatically derived from its authentication credentials exchanged
+ at a lower security layer or it may explicitly provide an
+ authorization identity desired for the association. The former is
+ known as an implicit assertion, and the latter as an explicit
+ assertion.
+
+11.1. Implicit Assertion
+
+ An implicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that does not include the optional credentials field
+ (found within the SaslCredentials sequence in the BindRequest). The
+ server will derive the client's authorization identity from the
+ authentication identity supplied by a security layer (e.g., a public
+ key certificate used during TLS layer installation) according to
+ local policy. The underlying mechanics of how this is accomplished
+ are implementation specific.
+
+11.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that includes the credentials field (found within the
+ SaslCredentials sequence in the BindRequest). The value of the
+ credentials field, an octet string, is the asserted authorization
+ identity and MUST be constructed as documented in section 9.7.
+
+12. Security Considerations
Security issues are discussed throughout this document. The
unsurprising conclusion is that security is an integral and
necessary part of LDAP. This section discusses a number of LDAP-
related security considerations.
-
12.1. General LDAP Security Considerations
-
LDAP itself provides no security or protection from accessing or
updating the directory by other means than through the LDAP
protocol, e.g. from inspection by database administrators. Access
- control SHOULD always be applied when reading sensitive information
- or updating directory information.
-
-
-Harrison Expires April 2005 [Page 19]
-Internet-Draft LDAP Authentication Methods 25 October 2004
+Harrison Expires August 2005 [Page 18]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ control SHOULD always be applied when reading sensitive information
+ or updating directory information.
Servers can minimize denial of service attacks by providing the
ability to configure and enforce administrative limits on
unwillingToPerform resultCode rather than performing computationally
expensive operations requested by unauthorized clients.
-
A connection on which the client has not established connection
integrity and privacy services (e.g via StartTLS, IPSec or a
suitable SASL mechanism) is subject to man-in-the-middle attacks to
view and modify information in transit. Client and server
- implementors SHOULD take measures to protect confidential data from
- these attacks by using data protection services as discussed in this
- document.
-
+ implementors SHOULD take measures to protect confidential data in
+ the LDAP session from these attacks by using data protection
+ services as discussed in this document. Clients and servers should
+ provide the ability to be configured to require these protections.
+ A resultCode of confidentialityRequired indicates that the server
+ requires establishment of (stronger) data confidentiality protection
+ in order to perform the requested operation.
12.1.1. Password-related Security Considerations
-
LDAP allows multi-valued password attributes. In systems where
entries are expected to have one and only one password,
administrative controls should be provided to enforce this behavior.
-
The use of clear text passwords and other unprotected authentication
credentials is strongly discouraged over open networks when the
- underlying transport service cannot guarantee confidentiality.
-
+ underlying transport service cannot guarantee confidentiality. LDAP
+ implementations SHOULD NOT support authentication methods using
+ cleartext passwords and other unprotected authentication credentials
+ unless the data on the connection is protected using TLS or other
+ data confidentiality and data integrity protection.
The transmission of passwords in the clear--typically for
authentication or modification--poses a significant security risk.
negotiating transport or session layer data confidentiality services
before transmitting password values.
-
To mitigate the security risks associated with the transfer of
passwords, a server implementation that supports any password-based
authentication mechanism that transmits passwords in the clear MUST
support a policy mechanism that at the time of authentication or
password modification, requires:
-
- A StartTLS encryption layer has been successfully negotiated.
-
+ A TLS layer has been successfully installed.
OR
-
Some other data confidentiality mechanism that protects the
password value from snooping has been provided.
+Harrison Expires August 2005 [Page 19]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- OR
+ OR
The server returns a resultCode of confidentialityRequired for
the operation (i.e. simple bind with password value, SASL bind
including a userPassword value, etc.), even if the password
value is correct.
-
12.2. StartTLS Security Considerations
-
-
-Harrison Expires April 2005 [Page 20]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
-
All security gained via use of the StartTLS operation is gained by
the use of TLS itself. The StartTLS operation, on its own, does not
provide any additional security.
-
The level of security provided though the use of TLS depends
directly on both the quality of the TLS implementation used and the
style of usage of that implementation. Additionally, a man-in-the-
supportedExtension attribute of the root DSE. Both parties SHOULD
independently ascertain and consent to the security level achieved
once TLS is established and before beginning use of the TLS
- connection. For example, the security level of the TLS connection
- might have been negotiated down to plaintext.
-
+ connection. For example, the security level of the TLS layer might
+ have been negotiated down to plaintext.
- Clients SHOULD by default either warn the user when the security
+ Clients SHOULD by default either warn the user when the security
level achieved does not provide an acceptable level of data
confidentiality and/or data integrity protection, or be configured
to refuse to proceed without an acceptable level of security.
-
Server implementors SHOULD allow server administrators to elect
whether and when data confidentiality and integrity are required, as
well as elect whether authentication of the client during the TLS
handshake is required.
-
Implementers should be aware of and understand TLS security
considerations as discussed in the TLS specification [TLS].
-
12.3. Unauthenticated Mechanism Security Considerations
-
Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of simple bind
(see section 7). For example, a client program might make a
implementations may return a success response to an unauthenticated
bind request thus leaving the client with the impression that the
server has successfully authenticated the identity represented by
- the user name, when in effect, an anonymous association has been
+ the user name when in reality, an anonymous association has been
established. Clients that use the results from a simple bind
operation to make authorization decisions should actively detect
unauthenticated bind requests (by verifying that the supplied
password is not empty) and react appropriately.
-12.4. Simple Mechanism Security Considerations
+Harrison Expires August 2005 [Page 20]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+12.4. Simple Mechanism Security Considerations
The simple authentication mechanism of simple bind discloses the
password to the server, which is an inherent security risk. There
are other mechanisms such as DIGEST-MD5 that do not disclose
password to server.
-
12.5. SASL DIGEST-MD5 Mechanism Security Considerations
-
-
-Harrison Expires April 2005 [Page 21]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
The SASL DIGEST-MD5 mechanism is prone to the qop substitution
attack, as discussed in 3.6 of [DIGEST-MD5]. The qop substitution
attack can be mitigated (as discussed in 3.6 of [DIGEST-MD5]).
-
The SASL DIGEST-MD5 mechanism [DIGEST-MD5] provides client
authentication with protection against passive eavesdropping attacks
but does not provide protection against man-in-the-middle attacks.
-
Implementers should be aware of and understand DIGEST-MD5 security
considerations as discussed in the DIGEST-MD5 specification [DIGEST-
MD5].
-
12.6. Related Security Considerations
-
Additional security considerations relating to the various
authentication methods and mechanisms discussed in this document
- apply and can be found in [SASL], [SASLPrep], [StringPrep] and
+ apply and can be found in [SASL], [SASLPrep], [StringPrep] and
[RFC3629].
-
13. IANA Considerations
-
The following IANA considerations apply to this document:
-
It is requested that the IANA update the LDAP Protocol Mechanism
registry to indicate that this document and [Protocol] provide the
definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) extended operation.
-
[[TODO: add any missing IANA Considerations.]]
-
Acknowledgments
-
This document combines information originally contained in RFC 2829
and RFC 2830. The editor acknowledges the work of Harald Tveit
Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
and Mark Wahl, each of whom authored one or more of these documents.
-
This document is based upon input of the IETF LDAP Revision working
group. The contributions and suggestions made by its members in
shaping the contents and technical accuracy of this document is
greatly appreciated.
-
Normative References
+
+Harrison Expires August 2005 [Page 21]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
-
[DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", draft-ietf-sasl-
rfc2831bis-xx.txt, a work in progress.
-
-
-Harrison Expires April 2005 [Page 22]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
-
[LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
Representation of Distinguished Names", draft-ietf-
ldapbis-dn-xx.txt, a work in progress.
-
[Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
in PKIX Certificates", draft-hoffman-pkix-stringmatch-
xx.txt, a work in progress.
-
[Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
Information Models", draft-ietf-ldapbis-models-xx.txt,
a work in progress.
-
[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress.
-
[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
[SASL] Melnikov, A. (editor), "Simple Authentication and
Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
xx.txt, a work in progress.
-
[SASLPrep] Zeilenga, K., "Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
progress).
-
[StringPrep] M. Blanchet, "Preparation of Internationalized Strings
('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
work in progress.
-
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
progress.
-
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
+
+Harrison Expires August 2005 [Page 22]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
[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-
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
Informative References
-
-
-Harrison Expires April 2005 [Page 23]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
[ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-
zeilenga-sasl-anon-xx.txt, a work in progress.
-
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
-
[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
sasl-plain-xx.txt, a work in progress.
-
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
-
Author's Address
-
Roger Harrison
Novell, Inc.
1800 S. Novell Place
+1 801 861 2642
roger_harrison@novell.com
-
Appendix A. Association State Transition Tables
-
This section provides a state transition table to represent a state
diagram for the various authentication states through which an
association may pass during the course of its existence and the
actions that cause these changes in state.
-
This section is based entirely on information found in this document
and other documents that are part of the LDAP Technical
Specification [Roadmap]. As such, it is strictly informational in
nature.
-
A.1. Association States
-
The following table lists the valid association states and provides
a description of each state. The ID for each state is used in the
- state transition table in section A.4.
-
+ state transition table in section A.3.
- ID State Description
+ ID Association State Description
-- --------------------------------------------------------------
+
+
+Harrison Expires August 2005 [Page 23]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
S1 Anonymous
no Authentication ID is associated with the LDAP connection
no Authorization ID is in force
S2 Authenticated
Authentication ID = I
Authorization ID = X
- S3 Authenticated SASL EXTERNAL, implicit authorization ID
- Authentication ID = J
- Authorization ID = Y
-
-
-
-
-Harrison Expires April 2005 [Page 24]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- S4 Authenticated SASL EXTERNAL, explicit authorization ID Z
- Authentication ID = J
- Authorization ID = Z
- S5 Invalidated
-
+ S3 Invalidated
A.2. Actions that Affect Association State
-
The following table lists the actions that can affect the
authentication and authorization state of an association. The ID for
- each action is used in the state transition table in section A.4.
-
+ each action is used in the state transition table in section A.3.
ID Action
-- --------------------------------------------------------------
A1 Client bind request fails
A2 Client successfully performs anonymous simple bind or
unauthenticated simple bind
- A3 Client successfully performs simple bind with name and password
- OR SASL bind with any mechanism except EXTERNAL using an
- authentication ID = I that maps to authorization ID X
- A4 Client Binds SASL EXTERNAL with implicit assertion of
- authorization ID (section 9.1). The current authentication ID
- maps to authorization ID = Y.
- A5 Client Binds SASL EXTERNAL with explicit assertion of
- authorization ID = Z (section 9.2).
- A6 Client StartTLS request fails
- A7 Client StartTLS request succeeds
- A8 Client or Server: graceful TLS removal
- A9 Server decides to invalidate current association state
-
-
-A.3. Decisions Used in Making Association State Changes
-
-
- Certain changes in the authentication and authorization state of an
- 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 transition in the state transition
- table in section A.4.
-
-
- ID Decision Question
- -- --------------------------------------------------------------
- D1 Are lower-layer credentials available?
- D2 Can lower-layer credentials for Auth ID "K" be mapped to
- asserted AuthZID "L"?
-
-
-A.4. Association State Transition Table
-
+ A3 Client successfully binds producing an authentication ID of I.
+ Authentication ID I maps to authorization ID X. Depending on
+ the bind mechanism and associated parameters authorization ID X
+ was either derived from authentication ID I or was explicitly
+ requested as part of the bind operation.
+ A4 Client StartTLS request fails
+ A5 Client StartTLS request succeeds
+ A6 Client or Server: graceful TLS layer removal
+ A7 Server decides to invalidate current association state
+
+A.3. Association State Transition Table
The Association table below lists the the actions that could affect
the authorization state of an association and the resulting state of
an association after a given action occurs.
-
S1, the initial state for the state machine described in this table,
is the association state when an LDAP connection is initially
established.
+ Next State
+ Action Comment
+ ---------------- --------------- -------------------------------
+ A1 S1 Section 4
+ A2 S1 Sections 6 and 7
+ A3 S2
+ A4 no change [Protocol] section 4.14.2.2
+ A5 no change or S3* [Protocol] section 4.14.2.1
+ A6 no change or S3* [Protocol] section 4.14.3.1
+ A7 S3
+ * The server may invalidate the association after installing or
+ removing a TLS layer (section 3.2).
-Harrison Expires April 2005 [Page 25]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Next State
- Action Comment
- ------------------ ----------- --------------------------------
- A1 S1 Section 4
- A2 S1 Sections 6 & 7
- A3 S2 Sections 8, 9
- A4, S1 Failed bind, section 10.1
- D1=no
- A4, S3
- D1=yes
- A5, S1 Failed bind, section 10.2
- D1=no
- A5, S1 Failed bind, section 10.2
- D1=yes,
- D2=no
- A5, S4
- D1=yes, D2=yes
- A6 no change* [Protocol] section 4.14.2.2
- A7 no change* [Protocol] section 4.14.2.1
- A8 S1 [Protocol] section 4.14.3.1
- A9 S5
-
-
- * The server may invalidate the association after TLS
- establishment or closure (section 3.2).
+Harrison Expires August 2005 [Page 24]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
Appendix B. Authentication and Authorization Concepts
-
This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security
approaches are utilized in client authentication and authorization.
-
B.1. Access Control Policy
-
An access control policy is a set of rules defining the protection
of resources, generally in terms of the capabilities of persons or
other entities accessing those resources. Security objects and
mechanisms, such as those described here, enable the expression of
access control policies and their enforcement.
-
B.2. Access Control Factors
-
A request, when it is being processed by a server, may be associated
with a wide variety of security-related factors (section 4.2 of
[Protocol]). The server uses these factors to determine whether and
associated with the connection via which the request is transmitted,
others (e.g. time of day) may be "environmental".
-
Access control policies are expressed in terms of access control
factors. E.g., a request having ACFs i,j,k can perform operation Y
-
-
-Harrison Expires April 2005 [Page 26]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
on resource Z. The set of ACFs that a server makes available for
such expressions is implementation-specific.
-
B.3. Authentication, Credentials, Identity
-
Authentication credentials are the evidence supplied by one party to
another, asserting the identity of the supplying party (e.g. a user)
who is attempting to establish a new association state with the
the identity they assert. An authentication identity is the name
presented in a credential.
-
There are many forms of authentication credentials -- the form used
depends upon the particular authentication mechanism negotiated by
the parties. For example: X.509 certificates, Kerberos tickets,
mechanism may constrain the form of authentication identities used
with it.
-
B.4. Authorization Identity
-
An authorization identity is one kind of access control factor. It
is the name of the user or other entity that requests that
operations be performed. Access control policies are often expressed
+
+
+Harrison Expires August 2005 [Page 25]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
in terms of authorization identities; e.g., entity X can perform
operation Y on resource Z.
-
The authorization identity bound to an association is often exactly
the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization
authorization identity from the authentication credentials supplied
by a client is performed in an implementation-specific manner.
-
Appendix C. RFC 2829 Change History
-
This appendix lists the changes made to the text of RFC 2829 in
preparing this document.
-
C.0. General Editorial Changes
Version -00
-
- Changed other instances of the term LDAP to LDAP where v3 of the
protocol is implied. Also made all references to LDAP use the
same wording.
-
-
-Harrison Expires April 2005 [Page 27]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Miscellaneous grammatical changes to improve readability.
-
- Made capitalization in section headings consistent.
-
Version -01
-
- Changed title to reflect inclusion of material from RFC 2830 and
2251.
-
C.1. Changes to Section 1
-
Version -01
-
- Moved conventions used in document to a separate section.
-
C.2. Changes to Section 2
-
Version -01
-
- Moved section to an appendix.
-
C.3. Changes to Section 3
-
Version -01
- - Moved section to an appendix.
+Harrison Expires August 2005 [Page 26]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ - Moved section to an appendix.
C.4 Changes to Section 4
-
Version -00
-
- Changed "Distinguished Name" to "LDAP distinguished name".
-
C.5. Changes to Section 5
-
Version -00
-
- Added the following sentence: "Servers SHOULD NOT allow clients
with anonymous authentication to modify directory entries or
access sensitive information in directory entries."
-
C.5.1. Changes to Section 5.1
-
Version -00
-
- Replaced the text describing the procedure for performing an
anonymous bind (protocol) with a reference to section 4.2 of RFC
2251 (the protocol spec).
-
Version -01
-
- Brought text describing procedure for performing an anonymous
bind from section 4.2 of RFC 2251 bis. This text will be
removed from the draft standard version of that document.
-
-Harrison Expires April 2005 [Page 28]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
C.6. Changes to Section 6.
-
Version -00
-
Reorganized text in section 6.1 as follows:
-
1. Added a new section (6.1) titled "Simple Authentication" and
moved one of two introductory paragraphs for section 6 into
section 6.1. Added sentences to the paragraph indicating:
-
a. simple authentication is not suitable for environments where
confidentiality is not available.
-
b. LDAP implementations SHOULD NOT support simple
authentication unless confidentiality and data integrity
mechanisms are in force.
-
2. Moved first paragraph of section 6 (beginning with "LDAP
implementations MUST support authentication with a password...")
to section on Digest Authentication (Now section 6.2).
-
C.6.1. Changes to Section 6.1.
-
Version -00 Renamed section to 6.2
+Harrison Expires August 2005 [Page 27]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Added sentence from original section 6 indicating that the
DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations
-
C.6.2. Changes to Section 6.2
-
Version -00
-
- Renamed section to 6.3
-
- Reworded first paragraph to remove reference to user and the
userPassword password attribute Made the first paragraph more
general by simply saying that if a directory supports simple
following negotiation of a TLS ciphersuite that supports
confidentiality.
-
- Replaced "the name of the user's entry" with "a DN" since not
all bind operations are performed on behalf of a "user."
-
- Added Section 6.3.1 heading just prior to paragraph 5.
-
- Paragraph 5: replaced "The server" with "DSAs that map the DN
sent in the bind request to a directory entry with a
userPassword attribute."
-
C.6.3. Changes to section 6.3.
-
-
-Harrison Expires April 2005 [Page 29]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
Version -00
-
- Renamed to section 6.4.
-
C.7. Changes to section 7.
-
none
-
C.7.1. Changes to section 7.1.
-
Version -00
-
- Clarified the entity issuing a certificate by moving the phrase
"to have issued the certificate" immediately after
"Certification Authority."
-
C.8. Changes to section 8.
-
Version -00
-
- Removed the first paragraph because simple authentication is
covered explicitly in section 6.
-
- Added section 8.1. heading just prior to second paragraph.
- - Added section 8.2. heading just prior to third paragraph.
+Harrison Expires August 2005 [Page 28]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ - Added section 8.2. heading just prior to third paragraph.
- Added section 8.3. heading just prior to fourth paragraph.
-
Version -01
-
- Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
for Other Security Services) to bring material on SASL
mechanisms together into one location.
-
C.9. Changes to section 9.
-
Version -00
-
- Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
mechanism."
-
- Added section 9.1. heading.
-
- Modified a comment in the ABNF from "unspecified userid" to
"unspecified authz id".
-
- Deleted sentence, "A utf8string is defined to be the UTF-8
encoding of one or more ISO 10646 characters," because it is
redundant.
-
- Added section 9.1.1. heading.
-
- Added section 9.1.2. heading.
-
-Harrison Expires April 2005 [Page 30]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
-
Version -01
-
- Moved entire section 9 to become section 3.5 so that it would be
with other SASL material.
-
C.10. Changes to Section 10.
-
Version -00
-
- Updated reference to cracking from a week of CPU time in 1997 to
be a day of CPU time in 2000.
-
- Added text: "These ciphersuites are NOT RECOMMENDED for use...
and server implementers SHOULD" to sentence just prior the
second list of ciphersuites.
-
- Added text: "and MAY support other ciphersuites offering
equivalent or better protection," to the last paragraph of the
section.
-
C.11. Changes to Section 11.
-
Version -01
- - Moved to section 3.6 to be with other SASL material.
+Harrison Expires August 2005 [Page 29]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ - Moved to section 3.6 to be with other SASL material.
C.12. Changes to Section 12.
-
Version -00
-
- Inserted new section 12 that specifies when SASL protections
begin following SASL negotiation, etc. The original section 12
is renumbered to become section 13.
-
Version -01
-
- Moved to section 3.7 to be with other SASL material.
-
C.13. Changes to Section 13 (original section 12).
-
None
-
Appendix D. RFC 2830 Change History
-
This appendix lists the changes made to the text of RFC 2830 in
preparing this document.
-
D.0. General Editorial Changes
-
- Material showing the PDUs for the StartTLS response was broken
out into a new section.
-
-
-
-Harrison Expires April 2005 [Page 31]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- The wording of the definition of the StartTLS request and
StartTLS response was changed to make them parallel. NO changes
were made to the ASN.1 definition or the associated values of
the parameters.
-
- A separate section heading for graceful TLS closure was added
for parallelism with section on abrupt TLS closure.
-
Appendix E. RFC 2251 Change History
-
This appendix lists the changes made to the text of RFC 2251 in
preparing this document.
-
E.0. General Editorial Changes
-
- All material from section 4.2 of RFC 2251 was moved into this
document.
-
- A new section was created for the Bind Request
-
- Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
after the section on the Bind Response for parallelism with the
presentation of the StartTLS operations. The section was also
subdivided to explicitly call out the various effects being
described within it.
+
+Harrison Expires August 2005 [Page 30]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- All SASL profile information from RFC 2829 was brought within
the discussion of the Bind operation (primarily sections 4.4 -
4.7).
-
Appendix F. Change History to Combined Document
-
F.1. Changes for draft-ldap-bis-authmeth-02
-
General
-
- Added references to other LDAP standard documents, to sections
within the document, and fixed broken references.
-
- General editorial changes--punctuation, spelling, formatting,
etc.
-
Section 1.
-
- Added glossary of terms and added sub-section headings
-
Section 2.
-
- Clarified security mechanisms 3, 4, & 5 and brought language in
line with IETF security glossary.
-
Section 3.
-
-
-
-Harrison Expires April 2005 [Page 32]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Brought language in requirement (3) in line with security
glossary.
-
- Clarified that information fetched prior to initiation of TLS
negotiation must be discarded
-
-Clarified that information fetched prior to initiation of SASL
negotiation must be discarded
-
- Rewrote paragraph on SASL negotiation requirements to clarify
intent
-
Section 4.4.
-
- Added stipulation that sasl choice allows for any SASL mechanism
not prohibited by this document. (Resolved conflict between this
statement and one that prohibited use of ANONYMOUS and PLAIN
SASL mechanisms.)
-
Section 5.3.6
-
- Added a.x.bar.com to wildcard matching example on hostname check.
-
Section 6
+
+
+Harrison Expires August 2005 [Page 31]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Added Association State Transition Tables to show the various
states through which an association may pass along with the
actions and decisions required to traverse from state to state.
-
Appendix A
-
- Brought security terminology in line with IETF security glossary
throughout the appendix.
-
F.2. Changes for draft-ldapbis-authmeth-03
-
General
-
- Added introductory notes and changed title of document and
references to conform to WG chair suggestions for the overall
technical specification.
-
- Several issues--H.13, H.14, H.16, H.17--were resolved without
requiring changes to the document.
-
Section 3
-
- Removed reference to /etc/passwd file and associated text.
-
Section 4
-
- Removed sections 4.1, 4.2 and parts of section 4.3. This
information was being duplicated in the protocol specification
and will now reside there permanently.
-
-
-Harrison Expires April 2005 [Page 33]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
Section 4.2
-
- changed words, "not recommended" to "strongly discouraged"
-
Section 4.3
-
- Based on ldapbis WG discussion at IETF52 two sentences were
added indicating that clients SHOULD NOT send a DN value when
binding with the sasl choice and servers SHALL ignore any value
received in this circumstance.
-
-
Section 8.3.1
-
- Generalized the language of this section to not refer to any
specific password attribute or to refer to the directory entry
as a "user" entry.
-
Section 11
-
- Added security consideration regarding misuse of unauthenticated
access.
-
- Added security consideration requiring access control to be
applied only to authenticated users and recommending it be
+
+Harrison Expires August 2005 [Page 32]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
applied when reading sensitive information or updating directory
information.
-
F.3. Changes for draft-ldapbis-authmeth-04
-
General
-
- Changed references to use [RFCnnnn] format wherever possible.
(References to works in progress still use [name] format.)
- Various edits to correct typos and bring field names, etc. in
line with specification in [Protocol] draft.
-
- Several issues--H.13, H.14, H.16, H.17--were resolved without
requiring changes to the document.
-
Section 4.4.1.
-
- Changed ABNF grammar to use productions that are like those in
the model draft.
-
Section 5
-
- Removed sections 5.1, 5.2, and 5.4 that will be added to
[Protocol]. Renumbered sections to accommodate this change.
-
-
Section 6
-
-
-
-Harrison Expires April 2005 [Page 34]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Reviewed Association State table for completeness and accuracy.
Renumbered actions A3, , and A5 to be A5, A3, and A4
respectively. Re-ordered several lines in the table to ensure
was missing and valid. Added actions A7 and A8 placeholders to
states S1, S2, S4 and S5 pending resolution of issue H.28.
-
Section 11
-
- Modified security consideration (originally added in -03)
requiring access control to be applied only to authenticated
users. This seems nonsensical because anonymous users may have
-
Section 13
-
- Verified all normative references and moved informative
references to a new section 14.
-
F.4. Changes for draft-ldapbis-authmeth-05
-
General
-
- General editory changes to fix punctuation, spelling, line
length issues, etc.
+
+Harrison Expires August 2005 [Page 33]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Verified and updated intra- and inter-document references
throughout.
- Document-wide review for proper usage of RFC 2119 keywords with
several changes to correct improper usage.
-
Abstract
- Updated to match current contents of documents. This was needed
due to movement of material on Bind and StartTLS operations to
[Protocol] in this revision.
-
Section 3.
-
- Renamed section to "Rationale for LDAP Security Mechanisms" and
removed text that did not support this theme. Part of the
motivation for this change was to remove the implication of the
other text found in the section that everything in the section
was a requirement
-
- Information from several removed paragraphs that describe
deployment scenarios will be added Appendix A in the next
revision of the draft.
-
- Paragraph beginning, " If TLS is negotiated, the client MUST
discard all information..." was moved to section 5.1.7 and
integrated with related material there.
-
-
-Harrison Expires April 2005 [Page 35]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Paragraph beginning, "If a SASL security layer is negotiated..."
was moved to section 4.2
-
Section 4.l.
-
- Changed wording of first paragraph to clarify meaning.
-
Section 4.2.
- Added paragraph from section 3 of -04 beginning, "If a SASL
security layer is negotiated..."
-
Section 4.3.3.
- Renamed to "Other SASL Mechanisms" and completely rewrote the
section (one sentence) to generalize the treatment of SASL
mechanisms not explicitly mentioned in this document.
-
Section 4.4.1.
-
- Added paragraph beginning, "The dnAuthzID choice allows client
applications..." to clarify whether DN form authorization
identities have to also have a corresponding directory entry.
This change was based on editor's perception of WG consensus.
-
- Made minor clarifying edits in the paragraph beginning, "The
uAuthzID choice allows for compatibility..."
- Section 5.1.1.
+Harrison Expires August 2005 [Page 34]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+ Section 5.1.1.
- Made minor clarifying edits in the last paragraph of the
section.
-
Section 5.1.7.
-
- Wording from section 3 paragraph beginning " If TLS is
negotiated, the client MUST discard all information..." was
moved to this section and integrated with existing text.
-
Section 5.2.
-
- Changed usage of "TLS connection" to "TLS session" throughout.
-
- Removed empty section 5.2.1 and renumbered sections it had
previously contained.
-
Section 8.
-
- Added introductory paragraph at beginning of section.
+ Section 8.1.
- Section 8.1.
-
-
- - Changed term "data privacy" to "data confidentiality" to be
- consistent with usage in rest of document.
-
-
- Section 8.2.
-
-
-Harrison Expires April 2005 [Page 36]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
+ - Changed term "data privacy" to "data confidentiality" to be
+ consistent with usage in rest of document.
+ Section 8.2.
- Changed first paragraph to require implementations that
implement *password-based* authentication to implement and
support DIGEST-MD5 SASL authentication.
-
Section 11.
-
- First paragraph: changed "session encryption" to "session
confidentiality protection" to be consistent with usage in rest
of document.
-
Appendix B.
-
- Began changes to incorporate information on deployment scenarios
removed from section 3.
-
F.5. Changes for draft-ldapbis-authmeth-06
-
General
-
- Combined Section 2 (Introduction) and Section 3 (Motivation) and
moved Introduction to section 1. All following sections numbers
were decremented by one as result.
-
- Edits to fix typos, I-D nits, etc.
+Harrison Expires August 2005 [Page 35]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further
discussion.
-
Section 1
-
- Added additional example of spoofing under threat (7).
-
Section 2.1
-
- Changed definition of "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 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.
-
-
-Harrison Expires April 2005 [Page 37]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
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-ldapbis-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.
+Harrison Expires August 2005 [Page 36]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- Section 3
+ Section 3
- Rewrote much of section 3.3 to meet the SASL profile
requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
-
- Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
bring in line with WG consensus.
-
Section 4
-
- Note to implementers in section 4.1.1 based on operational
experience.
-
- Clarification on client continuing by performing a StartTLS with
TLS already established in section 4.1.4.
-
- Moved verification of mapping of client's authentication ID to
asserted authorization ID to apply only to explicit assertion.
The local policy in place for implicit assertion is adequate.
-
Section 7
-
- Removed most of section 7.2 as the information is now covered
adequately via the new SASL profile in section 3.3. Added note
to implementors regarding the treatment of username and realm
values in DIGEST-MD5.
-
-
-Harrison Expires April 2005 [Page 38]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Section 7.3. Minor clarifications in wording.
-
- Section 7.3.1. Clarification that a match of the presented value
to any member of the set of stored passwords constitutes a
successful authentication.
-
F.7. Changes for draft-ldapbis-authmeth-08
-
General
-
- Changed usage from LDAPv3 to LDAP for usage consistency across
LDAP technical specification.
-
- Fixed a number of usage nits for consistency and to bring doc in
conformance with publication guidelines.
-
Abstract
-
- Significant cleanup and rewording of abstract based on WG
feedback.
-
Section 2.1
-
- New definition of user.
-
Section 3
+Harrison Expires August 2005 [Page 37]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Added 1.5 sentences at end of introductory paragraph indicating
the effect of the Bind op on the association.
-
Section 3.1
-
- Retitled section and clarified wording
-
Section 3.2
-
- Clarified that simple authentication choice provides three types
of authentication: anonymous, unauthenticated, and simple
password.
-
Section 3.3.3
-
- New wording clarifying when negotiated security mechanisms take
effect.
-
Section 3.3.5
-
- Changed requirement to discard information about server fetched
prior to SASL negotiation from MUST to SHOULD to allow for
information obtained through secure mechanisms.
-
Section 3.3.6
-
-
-
-Harrison Expires April 2005 [Page 39]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Simplified wording of first paragraph based on suggestion from
WG.
-
Section 3.4
-
- Minor clarifications in wording.
-
Section 3.4.1
-
- Minor clarifications in wording in first sentence.
- Explicitly called out that the DN value in the dnAuthzID form is
to be matched using DN matching rules.
- Clarified requirement on assuming global uniqueness by changing
a "generally... MUST" wording to "SHOULD".
-
Section 4.1.1
-
- Simplified wording describing conditions when StartTLS cannot be
sent.
- Simplified wording in note to implementers regarding race
condition with outstanding LDAP operations on connection.
-
Section 4.1.5
-
- Removed section and moved relevant text to section 4.2.2.
+Harrison Expires August 2005 [Page 38]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
- Section 4.1.6
+ Section 4.1.6
- Renumbered to 4.1.5.
- Updated server identity check rules for server's name based on
WG list discussion.
-
Section 4.1.7
-
- Renumbered to 4.1.6
- Changed requirement to discard information about server fetched
prior to TLS negotion from MUST to SHOULD to allow for
information obtained through secure mechanisms.
-
Section 6.1
-
- Clarified wording.
- Added definition of anonymous and unauthenticated binds.
-
Section 10
-
- Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication
channels.
-
Section 11
-
-
-Harrison Expires April 2005 [Page 40]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth]
-
F.8. Changes for draft-ldapbis-authmeth-09
-
General
-
- Updated section references within document
- Changed reference tags to match other docs in LDAP TS
- Used non-quoted names for all SASL mechanisms
-
Abstract
-
- Inspected keyword usage and removed several improper usages.
-
- Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
implement mechanism. This is covered elsewhere in document.
-
- Moved section 5, authentication state table, of -08 draft to
section 8 of -09 and completely rewrote it.
-
Section 1
-
- Reworded sentence beginning, "It is also desirable to allow
authentication methods to carry identities based on existing,
non-LDAP DN-forms..."
+
+
+Harrison Expires August 2005 [Page 39]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Clarified relationship of this document to other documents in
the LDAP TS.
-
Section 3.3.5
-
- Removed paragraph beginning,"If the client is configured to
support multiple SASL mechanisms..." because the actions
specified in the paragraph do not provide the protections
server should allow specification of acceptable mechanisms and
only allow those mechanisms to be used.
-
- Clarified independent behavior when TLS and SASL security layers
are both in force (e.g. one being removed doesn't affect the
other).
-
Section 3.3.6
-
- Moved most of section 4.2.2, Client Assertion of Authorization
Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
-
Section 3.3.6.4
-
- Moved some normative comments into text body.
-
Section 4.1.2
-
-
-
-Harrison Expires April 2005 [Page 41]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Non success resultCode values are valid if server is *unwilling*
or unable to negotiate TLS.
-
Section 4.2.1
-
- Rewrote entire section based on WG feedback.
-
Section 4.2.2
-
- Moved most of this section to 3.3.6 for better document flow.
-
Section 4.2.3
-
- Rewrote entire section based on WG feedback.
-
Section 5.1
-
- Moved imperative language regarding unauthenticated access from
security considerations to here.
-
Section 6
-
- Added several paragraphs regarding the risks of transmitting
passwords in the clear and requiring server implementations to
provide a specific configuration that reduces these risks.
-
Section 6.2
+Harrison Expires August 2005 [Page 40]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Added sentence describing protections provided by DIGEST-MD5
method.
- Changed DNs in exmple to be dc=example,dc=com.
-
Section 10
-
- Updated consideration on use of cleartext passwords to include
other unprotected authentication credentials
- Substantial rework of consideration on misuse of unauthenticated
bind.
-
F.9. Changes for draft-ldapbis-authmeth-10
-
- Reorganized content of sections 3-9 to improve document flow and
reduce redundancy.
- Resolved issue of effect of Start TLS and TLS closure on
- Moved authentication state table to appendix and relettered
appendices.
-
F.10. Changes for draft-ldapbis-authmeth-11
-
-
-Harrison Expires April 2005 [Page 42]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
General
-
- Many editorial changes throughout to clarify wording and better
express intent, primarily based on suggestions from WG mail
list.
document, e.g. "Anonymous Authentication Mechanism of the Simple
Bind Choice".
-
Section 1
-
- Editorial changes to add clarity.
- Moved section 2 of authmeth -09 into section 1
-
Section 2
-
- New section outlining implementation requirements.
-
Section 3.1.1
-
- Editorial clarification on need for following operation
sequencing requirements.
-
Section 3.1.4
+
+
+Harrison Expires August 2005 [Page 41]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- New section added to describe use of client certificates with
StartTLS. Incorporates material moved from other sections of
authmeth -09.
-
Section 4
- New section added to discuss associations. Related material was
moved from various other sections of authmeth -09 and
incorporated into this new section.
-
Section 5
-
- Added several paragraphs regarding transmission and derivation
of authentication and authorization identities using the Bind
operation.
-
Section 8
-
- Clarified rules for determining valid credentials and situations
where invalidCredentials result is to be returned.
-
Section 14
-
- Added three security considerations based on WG feedback.
-
Appendix A
-
- Simplfied state tables by removing two unnecessary actions from
the actions table, and removing the current state column of the
-
-
-
-Harrison Expires April 2005 [Page 43]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
state transition table. Updated references to authmeth and
[Protocol].
-
F.11. Changes for draft-ldapbis-authmeth-12
-
General
-
- Changed refererences from Start TLS to StartTLS.
- Removed Appendix B: Example Deployment Scenarios
- Removed Appendix H as all issues listed in the appendix are now
resolved.
-
Section 2
-
- Added implementation requirement that server implementations
that SUPPORT StartTLS MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
Section 3.1.2
-
- Added wording clarifying that a client's association is
unaffected if a non-success resultCode is returned in the
StartTLS response.
-
Section 9.2
+Harrison Expires August 2005 [Page 42]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Final paragraph of this section details requirements for
serverSaslCreds field when no challenge value is sent.
-
Section 10
-
- Clarified language on uAuthzID usage.
-
Section 12
-
- Moved entire section into security considerations. New section
number is 12.1.1.
- Reorganized security considerations by topic.
- Added several security considerations based on WG feedback.
-
Section 13
-
- Moved section to become section 3.3.
-
F.12. Changes for draft-ldapbis-authmeth-13
-
General
-
- General edits for clarity and to remove errors.
- Reworded definition of association (section 1.2) and reworked
usage of association throughout document. Current semantics:
every connection has an association with the same lifetime as
the connection, and that association passes through various
authorization states.
-
-
-Harrison Expires April 2005 [Page 44]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
- Made usage of data confidentiality consistent throughout
document.
-
Section 1
- Reworded mechanisms 3 and 4 for more parallelism.
- - Changed language on rationale for required mechansisms from
+ - Changed language on rationale for required mechanisms from
future to past tense.
-
Section 2
- Clarified that implementations may support any additional
authentication mechanism, not just mechanisms associated with
simple and SASL bind choices.
-
Section 3
- Moved paragraph explaining goals for using TLS with LDAP from
security considerations to here.
-
Section 4.3
- Reworked text to better explain meaning of strongAuthRequired
- result code when for invalidated associations.
-
+ resultCode when for invalidated associations.
Section 8
- Clarified action when simple bind request has a DN with invalid
syntax.
-
Section 12.1
+
+Harrison Expires August 2005 [Page 43]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
- Added ability to configure and enforce administrative service
limits as a way to protect against denial of service attacks.
-
Section 12.2
- Clarified that this security consideration relates to performing
client authentication during the TLS handshake and not to
subsequent SASL EXTERNAL authentication.
-
Appendix A
- Updated tables by collapsing identical states and actions. Also
added an invalidated association state and accompanying actions.
-Added implementation requirement that server implementations
+F.13. Changes for draft-ldapbis-authmeth-14
-Intellectual Property Rights
+ General
+
+ - Moved to standardized LDAP TS terms: transport connection, TLS
+ layer, SASL layer, and LDAP message layer. Reworked usage of
+ terminology throughout document to conform to latest usage.
+ - Changed language on resultCode values to be less prescriptive
+ and more descriptive.
+
+ Section 1
+ - Changed format and definitions of terms to parallel latest
+ revision of [Protocol].
+
+ Section 2
+ - Updated implementation requirements for protecting LDAP simple
+ bind mechanism to conform to WG consensus.
+
+ Section 3.1.1
+ - Moved last paragraph to security considerations and made
+ generalized discussion of use of confidentialityRequired
+ resultCode general for all data confidentiality services not
+ just TLS.
+
+ Section 3.1.4
+ ûRewrote last paragraph to clarify that SASL EXTERNAL is a
+ client action when server uses certificate information to
+ derive authorization ID.
+ Section 3.2
+ ûCollapsed three subsections into a single subsection. Removed
+ text that implied that the TLS credentials were the only lower
+ layer credentials that are used by SASL EXTERNAL in determining
+ authentication ID and authorization ID.
+
+ Section 8
+ - Removed most of last paragraph that was redundant with
+ implementation requirements in section 2.
+
+ Section 10
+
+Harrison Expires August 2005 [Page 44]
+\f
+Internet-Draft LDAP Authentication Methods February 2005
+
+ - Changed to SASL DIGEST-MD5 (was section 11 in -13 revision)
+
+ Section 11
+ - Changed to SASL EXTERNAL (was section 10 in -13 revision). Moved
+ discussion of SASL authorization identities to Section 9.7.
+ Clarified language around implicit and explicit assertion of
+ authroization identities.
+
+ Appendix A
+ - Further collapsed identical states and actions continuing work
+ in previous revisions.
+
+Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
-
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
-
-
-Harrison Expires April 2005 [Page 45]
-Internet-Draft LDAP Authentication Methods 25 October 2004
-
-
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
-
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
-
Full Copyright Statement
-
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
-
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison Expires April 2005 [Page 46]
\ No newline at end of file
+Harrison Expires August 2005 [Page 45]
+\f
--- /dev/null
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: BCP OpenLDAP Foundation
+Expires in six months 21 February 2005
+Obsoletes: RFC 3383
+
+
+ IANA Considerations for LDAP
+ <draft-ietf-ldapbis-bcp64-05.txt>
+
+
+
+Status of Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Best Current Practice
+ document. This document is intended to replace RFC 3383.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ (LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send
+ editorial comments directly to the document editor
+ <Kurt@OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 1]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of Lightweight Directory Access Protocol (LDAP). The document also
+ provides guidelines to Internet Assigned Numbers Authority (IANA)
+ describing conditions under which new values can be assigned.
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an
+ extensible protocol. LDAP supports:
+
+ - addition of new operations,
+ - extension of existing operations, and
+ - extensible schema.
+
+ This document details procedures for registering values of used to
+ unambiguously identify extensible elements of the protocol including:
+
+ - LDAP message types;
+ - LDAP extended operations and controls;
+ - LDAP result codes;
+ - LDAP authentication methods;
+ - LDAP attribute description options; and
+ - Object Identifier descriptors.
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+ This document replaces RFC 3383.
+
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 2]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+2.2. Requirement Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this case, "the specification" as used by BCP 14 refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [RFC2234]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ LDIGIT = %x31-39 ; "1"-"9"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ HYPHEN = %x2D ; "-"
+ DOT = %x2E ; "."
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ keychar = ALPHA / DIGIT / HYPHEN
+ leadkeychar = ALPHA
+ keystring = leadkeychar *keychar
+
+ A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
+ Unicode [Unicode] restricted to the <keystring> production.
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value which can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registrations described.
+
+ LDAP values specified in RFCs MUST be registered. Other LDAP values,
+ expecting those in private-use name spaces, SHOULD be registered.
+ RFCs SHOULD NOT reference, use, or otherwise recongize unregistered
+ LDAP values.
+
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
+ elements SHOULD state who delegated the OIDs for its use.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 3]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ For IETF developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
+ by others, any properly delegated OID can be used, including those
+ under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+ Enterprise Numbers" (1.3.6.1.4.1.x).
+
+ Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+ Review with Specification Required. Only one OID per specification
+ will be assigned. The specification MAY then assign any number of
+ OIDs within this arc without further coordination with IANA.
+
+ Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+ IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
+ assignment of Internet Private Enterprise Numbers is detailed in STD
+ 16 [RFC1155].
+
+ To avoid interoperability problems between early implementations of a
+ "work in progress" and implementations of the published specification
+ (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+ progress" and early implementations. OIDs under the Internet
+ Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+ Practices for IANA assignment of these Internet Experimental numbers
+ is detailed in STD 16 [RFC1155].
+
+
+3.2 Protocol Mechanisms
+
+ LDAP provides a number of Root DSE attributes for discovery of
+ protocol mechanisms identified by OIDs, including the
+ supportedControl, supportedExtension, and supportedFeatures
+ attributes [Models],
+
+ A registry of OIDs used for discover of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ Protocol Mechanisms are registered on a First Come First Served
+ basis.
+
+
+3.3 LDAP Syntaxes
+
+ This registry provides a listing of LDAP syntaxes [Models]. Each
+ LDAP syntax is identified by an object identifier (OID). This
+ registry is provided to allow implementors and others to locate the
+ technical specification describing a particular LDAP Syntax.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ LDAP Syntaxes are registered on a First Come First Served with
+ Specification Required basis.
+
+ Note: unlike object classes, attribute types and various other kinds
+ of schema elements, descriptors are not used in LDAP to identify LDAP
+ Syntaxes.
+
+
+3.4. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify select protocol
+ extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
+ extensions, and other objects.
+
+ While the protocol allows the same descriptor to refer to different
+ object identifiers in certain cases and the registry supports
+ multiple registrations of the same descriptor (each indicating a
+ different kind of schema element and different object identifier),
+ multiple registrations of the same descriptor are to be avoided. All
+ such registration requests require Expert Review.
+
+ Descriptors are restricted to strings of UTF-8 encoded Unicode
+ characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case-insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form (e.g.,
+ 1.1.0.23.40) conforming to the ABNF:
+
+ numericoid = number 1*( DOT number )
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A value ending with a hyphen ("-") reserves all descriptors which
+ start with that value. For example, the registration of the option
+ "descrFamily-" reserves all options which start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 5]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+ The registrant need not "own" the OID being named.
+
+ The OID name space is managed by The ISO/IEC Joint Technical
+ Committee 1 - Subcommittee 6.
+
+
+3.5. AttributeDescription Options
+
+ An AttributeDescription [Models] can contain zero or more options
+ specifying additional semantics. An option SHALL be restricted to a
+ string UTF-8 encoded Unicode characters limited by the following
+ ABNF:
+
+ option = keystring
+
+ Options are case-insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names which
+ start with the name. For example, the registration of the option
+ "optionFamily-" reserves all options which start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.6. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [Protocol]. The protocolOp CHOICE indicates the type of message
+ encapsulated. Each message type consists of an ASN.1 identifier in
+ the form of a keyword and a non-negative choice number. The choice
+ number is combined with the class (APPLICATION) and data type
+ (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 6]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ encoding. The choice numbers for existing protocol messages are
+ implicit in the protocol's ASN.1 defined in [Protocol].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages which reduces, but does not
+ eliminate, the need to add new message types.
+
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [Protocol]. Each authentication choice consists of an ASN.1
+ identifier in the form of a keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet,
+ LIMITED USE - method is appropriate for limited use,
+ OBSOLETE - method has been deprecated or otherwise found to
+ be inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of class OBSOLETE cannot be
+ registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports Simple Authentication and Security Layers [SASL]
+ as an authentication choice. SASL is an extensible
+ authentication framework.
+
+
+3.8. LDAP Result Codes
+
+ LDAP result messages carry an resultCode enumerated value to indicate
+ the outcome of the operation [Protocol]. Each result code consists
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 7]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ of a ASN.1 identifier in the form of a keyword and a non-negative
+ integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+
+3.9. LDAP Search Scope
+
+ LDAP SearchRequest messages carry a scope enumerated value to
+ indicate the extend of search within the DIT [Protocol] Each search
+ value consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New scope integers in the range 0-1023 require Standards Action to be
+ registered. New scope integers in the range 1024-4095 require Expert
+ Review with Specification Required. New scope integers in the range
+ 4096-16383 will be registered on a First Come First Served basis.
+ Keywords associated with integers in the range 0-4095 SHALL NOT start
+ with "e-" or "x-". Keywords associated with integers in the range
+ 4096-16383 SHALL start with "e-". Values greater than or equal to
+ 16384 and keywords starting with "x-" are for Private Use and cannot
+ be registered.
+
+
+3.10. LDAP Filter Choice
+
+ LDAP filters are used in making assertions against an object
+ represented in the directory [Protocol]. The Filter CHOICE indicates
+ a type of assertion. Each Filter CHOICE consists of an ASN.1
+ identifier in the form of a keyword and a non-negative choice number.
+ The choice number is combined with the class (APPLICATION) and data
+ type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+ message's encoding.
+
+ Note: LDAP provides the extensibleMatching choice which reduces, but
+ does not eliminate, the need to add new filter choices.
+
+
+3.11. LDAP ModifyRequest Operation Type
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 8]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ The LDAP ModifyRequest carries a sequence of modification operations
+ [Protocol]. Each kind (e.g., add, delete, replace) of operation is
+ consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New operation type integers in the range 0-1023 require Standards
+ Action to be registered. New operation type integers in the range
+ 1024-4095 require Expert Review with Specification Required. New
+ operation type integers in the range 4096-16383 will be registered on
+ a First Come First Served basis. Keywords associated with integers
+ in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
+ associated with integers in the range 4096-16383 SHALL start with
+ "e-". Values greater than or equal to 16384 and keywords starting
+ with "x-" are for Private Use and cannot be registered.
+
+
+3.12. LDAP authzId Prefixes
+
+ Authorization Identities in LDAP are strings conforming to the
+ <authzId> production [AuthMeth]. This production is extensible.
+ Each new specific authorization form is identified by a prefix string
+ conforming to the following ABNF:
+
+ prefix = keystring COLON
+ COLON = %x3A ; COLON (":" U+003A)
+
+ Prefixes are case-insensitive.
+
+ While the protocol places no maximum length restriction upon prefix
+ strings, they should be short. Prefixes longer than 12 characters
+ may be viewed as too long to register.
+
+ Prefixes beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Prefixes beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other prefixes require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.13. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well known attributes was used in the LDAPv2
+ string representation of a distinguished name [RFC1779]. LDAPv2 is
+ now Historic [RFC3494].
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section
+ 3.2] (which have a different syntax than directory system names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
+ all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory@apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone may
+ subscribe to this list by sending a request to
+ <directory-request@apps.ietf.org>. During the review, objections may
+ be raised by anyone (including the Expert) on the list. After
+ completion of the review, the Expert, based upon public comments,
+ SHALL either approve the request and forward it to the IESG OR deny
+ the request. In either case, the Expert SHALL promptly notify the
+ requester of the action. Actions of the Expert may be appealed
+ [RFC2026]. The Expert is appointed by Applications Area Director(s).
+ The requester is viewed as the owner of values registered under
+ Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana@iana.org>. The
+ requester is viewed as the owner of values registered under First
+ Come First Served.
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademarks issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ revise the I-D to use registered values.
+
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on their web site: <http://www.iana.org/>.
+
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the owner is not unable or unwilling to make necessary updates,
+ the IESG MAY assume ownership in order to update the registration.
+
+
+5.3. Comments
+
+ For cases where others (anyone other than the owner) have significant
+ objections to the claims in a registration and the owner does not
+ agree to change the registration, comments MAY be attached to a
+ registration upon Expert Review. For registrations owned by the
+ IESG, the objections SHOULD be addressed by initiating a request for
+ Expert Review.
+
+ The form to these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+
+6. Security Considerations
+
+ The security considerations detailed in BCP 26 [RFC2434] are
+ generally applicable to this document. Additional security
+ considerations specific to each name space are discussed in Section 3
+ where appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [Roadmap].
+
+
+7. Acknowledgment
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group (WG). This document is a revision of RFC 3383, also a
+ product of the LDAPBIS WG.
+
+ This document includes text borrowed from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+ Harald Alvestrand.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt@OpenLDAP.org
+
+
+9. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+9.1. Normative References
+
+ [RFC1155] Rose, M. and K. McCloghrie, "Structure and
+ Identification of Management Information for TCP/IP-
+ based Internets", STD 16 (also RFC 1155), May 1990.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9 (also RFC 2026), October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26 (also RFC
+ 2434), October 1998.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+9.2. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+ Security Layer (SASL)",
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 13]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names.
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values. Note that more than one value may be requested by
+ extending the template by listing multiple values, or through use of
+ tables.
+
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension or Feature or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 14]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+A.3. LDAP Syntax Registration Template
+
+ Subject: Request for LDAP Syntax Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.4. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of administrative role, attribute type, matching rule,
+ name form, object class, URL extension, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.5. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 15]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.6. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 16]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Search Scope Registration Template
+
+ Subject: Request for LDAP Search Scope Registration
+
+ Search Scope Name:
+
+ Filter Scope String:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.9. LDAP Filter Choice Registration Template
+
+ Subject: Request for LDAP Filter Choice Registration
+
+ Filter Choice Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 17]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+A.10. LDAP ModifyRequest Operation Registration Template
+
+ Subject: Request for LDAP ModifyRequest Operation Registration
+
+ ModifyRequest Operation Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+Appendix B. Changes since RFC 3383
+
+ This informative appendix provides a summary of changes made since RFC
+ 3383.
+
+ - Object Identifier Descriptors practices were updated to require
+ all descriptors defined in RFCs to be registered and
+ recommending all other descriptors (excepting those in
+ private-use name space) be registered. Additionally, all
+ requests for multiple registrations of the same descriptor are
+ now subject to Expert Review.
+
+ - Protocol Mechanisms practices were updated to include values of
+ the 'supportedFeatures' attribute type.
+
+ - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+ operation, and authzId prefixes registries were added.
+ [[Initial values provided in Appendix C. This Appendix is to be
+ removed by the RFC Editor before publication as an RFC.]]
+
+ - References to RFCs comprising the LDAP technical specifications
+ have been updated to latest revisions.
+
+ - References to ISO 10646 have been replaced with [Unicode].
+
+ - The "Assigned Values" appendix providing initial registry values
+ was removed.
+
+ - Numerous editorial changes were made.
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 18]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+Appendix C. Initial Values for new registries
+
+ This appendix provides initial values for new registries.
+
+
+C.1. LDAP Syntaxes
+
+ Object Identifier Syntax Owner Reference
+ ----------------------------- -------------------------- ----- ---
+ 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
+
+
+C.2. LDAP Search Scopes
+
+ Name URLString Value Owner Reference
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 19]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ ---------------- --------- ----- ----- -------------------
+ baseObject base 0 IESG [Protocol][LDAPURL]
+ singleLevel one 1 IESG [Protocol][LDAPURL]
+ wholeSubtree sub 2 IESG [Protocol][LDAPURL]
+
+
+C.3. LDAP Filter Choices
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ and 0 IESG [Protocol]
+ or 1 IESG [Protocol]
+ not 2 IESG [Protocol]
+ equalityMatch 3 IESG [Protocol]
+ substrings 4 IESG [Protocol]
+ greaterOrEqual 5 IESG [Protocol]
+ lessOrEqual 6 IESG [Protocol]
+ present 7 IESG [Protocol]
+ approxMatch 8 IESG [Protocol]
+ extensibleMatch 9 IESG [Protocol]
+
+
+C.4. LDAP ModifyRequest Operations
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ add 0 IESG [Protocol]
+ delete 1 IESG [Protocol]
+ replace 2 IESG [Protocol]
+
+
+C.5. LDAP authzId prefixes
+
+ Name Prefix Owner Reference
+ ---------------- ------ ----- ---------
+ dnAuthzId dn: IESG [AuthMeth]
+ uAuthzId u: IESG [AuthMeth]
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 20]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-05.txt 21 February 2005
+
+
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 21]
+\f
+
+
+
+
+
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 24 October 2004
-Obsoletes: 2253
-
+Expires in six months 10 February 2005
+Obsoletes: RFC 2253
LDAP: String Representation of Distinguished Names
- <draft-ietf-ldapbis-dn-15.txt>
-
+ <draft-ietf-ldapbis-dn-16.txt>
Status of Memo
-
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document
replacing RFC 2253. Distribution of this memo is unlimited.
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
-
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
-
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
-
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
-
The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
+ http://www.ietf.org/1id-abstracts.html
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
-
-
-
Zeilenga LDAP: Distinguished Names [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Abstract
-
The X.500 Directory uses distinguished names (DNs) as primary keys to
entries in the directory. This document defines the string
representation used in the Lightweight Directory Access Protocol
names, while being able to represent any distinguished name.
-
1. Background and Intended Usage
-
In X.500-based directory systems [X.500], including those accessed
using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
distinguished names (DNs) are used to unambiguously refer to directory
entries [X.501][Models].
-
The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
directory protocols), DNs are encoded using the Basic Encoding Rules
(BER) [X.690]. In LDAP, DNs are represented in the string form
described in this document.
-
It is important to have a common format to be able to unambiguously
represent a distinguished name. The primary goal of this
specification is ease of encoding and decoding. A secondary goal is
translations (such as expressing attribute type names in the local
national language).
-
This document defines the string representation of Distinguished Names
used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
algorithm for converting a DN from its ASN.1 structured representation
to a string. Section 3 details how to convert a DN from a string to a
ASN.1 structured representation.
-
While other documents may define other algorithms for converting a DN
from its ASN.1 structured representation to a string, all algorithms
MUST produce strings which adhere to the requirements of Section 3.
-
This document does not define a canonical string representation for
DNs. Comparison of DNs for equality is to be performed in accordance
with the distinguishedNameMatch matching rule [Syntaxes].
-
- This document is an integral part of the LDAP Technical Specification
- [Roadmap]. This document obsoletes RFC 2253. Changes since RFC 2253
-
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
Zeilenga LDAP: Distinguished Names [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
- are summarized in Appendix B.
+ specification, RFC 3377, in its entirety. This document obsoletes RFC
+ 2253. Changes since RFC 2253 are summarized in Appendix B.
This specification assumes familiarity with X.500 [X.500] and the
concept of Distinguished Name [X.501][Models].
-
1.1. Conventions
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
-
Character names in this document use the notation for code points and
names from the Unicode Standard [Unicode]. For example, the letter
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
Note: a glossary of terms used in Unicode can be found in [Glossary].
Information on the Unicode character encoding model can be found in
[CharModel].
-
2. Converting DistinguishedName from ASN.1 to a String
-
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
name. The following is a variant provided for discussion purposes.
-
DistinguishedName ::= RDNSequence
-
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
-
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
-
This section defines the RECOMMENDED algorithm for converting a
distinguished name from an ASN.1 structured representation to an UTF-8
[RFC3629] encoded Unicode [Unicode] character string representation.
implementations.
-
2.1. Converting the RDNSequence
-
-
Zeilenga LDAP: Distinguished Names [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
If the RDNSequence is an empty sequence, the result is the empty or
zero length string.
-
Otherwise, the output consists of the string encodings of each
RelativeDistinguishedName in the RDNSequence (according to Section
2.2), starting with the last element of the sequence and moving
backwards toward the first.
-
The encodings of adjoining RelativeDistinguishedNames are separated by
a comma (',' U+002C) character.
-
2.2. Converting RelativeDistinguishedName
-
When converting from an ASN.1 RelativeDistinguishedName to a string,
the output consists of the string encodings of each
AttributeTypeAndValue (according to Section 2.3), in any order.
-
Where there is a multi-valued RDN, the outputs from adjoining
AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
character.
-
2.3. Converting AttributeTypeAndValue
-
The AttributeTypeAndValue is encoded as the string representation of
the AttributeType, followed by an equals sign ('=' U+003D) character,
followed by the string representation of the AttributeValue. The
encoding of the AttributeValue is given in Section 2.4.
-
- If the AttributeType is defined to have a short name and that short
- name is known to be registered [REGISTRY][BCP64bis] as identifying the
- AttributeType, that short name, a <descr>, is used. Otherwise the
- AttributeType is encoded as the dotted-decimal encoding, a
- <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
- is defined in [Models].
-
+ If the AttributeType is defined to have a short name (descriptor)
+ [Models] and that short name is known to be registered
+ [REGISTRY][BCP64bis] as identifying the AttributeType, that short
+ name, a <descr>, is used. Otherwise the AttributeType is encoded as
+ the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+ The <descr> and <numericoid> is defined in [Models].
Implementations are not expected to dynamically update their knowledge
of registered short names. However, implementations SHOULD provide a
updated.
-
2.4. Converting an AttributeValue from ASN.1 to a String
-
If the AttributeType is of the dotted-decimal form, the AttributeValue
is represented by an number sign ('#' U+0023) character followed by
the hexadecimal encoding of each of the octets of the BER encoding of
-
Zeilenga LDAP: Distinguished Names [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
the X.500 AttributeValue. This form is also used when the syntax of
form may also be used in other cases, such as when a reversible string
representation is desired (see Section 5.2).
-
Otherwise, if the AttributeValue is of a syntax which has a
LDAP-specific string encoding, the value is converted first to a UTF-8
encoded Unicode string according to its syntax specification (see
escaping, then that string can be used as the string representation of
the value.
-
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at
the beginning of the string;
-
- a space (' ' U+0020) character occurring at the end of the
string;
-
- one of the characters '"', '+', ',', ';', '<', '>', or '\'
(U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
respectively);
-
- the null (U+0000) character.
-
Other characters may be escaped.
-
Each octet of the character to be escaped is replaced by a backslash
and two hex digits, which form a single octet in the code of the
character. Alternatively, if and only if the character to be escaped
is one of
-
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C respectively)
-
- it can be prefixed by a backslash ('\' U+0005C).
-
+ it can be prefixed by a backslash ('\' U+005C).
Examples of the escaping mechanism are shown in Section 4.
-
3. Parsing a String back to a Distinguished Name
-
The string representation of Distinguished Names is restricted to
UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
of this string representation is specified using the following
-
Zeilenga LDAP: Distinguished Names [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
Augmented BNF [RFC2234] grammar:
-
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
attributeType = descr / numericoid
attributeValue = string / hexstring
-
; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL.
string = [ ( leadchar / pair ) [ *( stringchar / pair )
( trailchar / pair ) ] ]
-
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
-
trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
-
stringchar = SUTF1 / UTFMB
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
-
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*hexpair
hexpair = HEX HEX
-
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
<EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
<SPACE>, <SHARP>, <UTFMB> are defined in [Models].
-
Each <attributeType>, either a <descr> or a <numericoid>, refers to an
attribute type of an attribute value assertion (AVA). The
<attributeType> is followed by a <EQUALS> and an <attributeValue>.
The <attributeValue> is either in <string> or <hexstring> form.
-
If in <string> form, a LDAP string representation asserted value can
be obtained by replacing (left-to-right, non-recursively) each <pair>
appearing in the <string> as follows:
-
Zeilenga LDAP: Distinguished Names [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
-
If in <hexstring> form, a BER representation can be obtained from
converting each <hexpair> of the <hexstring> to the octet indicated by
the <hexpair>.
-
One or more attribute values assertions, separated by <PLUS>, for a
relative distinguished name.
-
Zero or more relative distinguished names, separated by <COMMA>, for a
distinguished name.
-
Implementations MUST recognize AttributeType name strings
(descriptors) listed in the following table, but MAY recognize other
name strings.
-
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
-
Implementations MAY recognize other DN string representations (such as
that described in RFC 1779). However, as there is no requirement that
alternative DN string representations to be recognized (and, if so,
with Section 2 of this document.
-
4. Examples
-
This notation is designed to be convenient for common forms of name.
This section gives a few examples of distinguished names written using
this notation. First is a name containing three relative
distinguished names (RDNs):
-
UID=jsmith,DC=example,DC=net
-
Here is an example name containing three RDNs, in which the first RDN
is multi-valued:
-
OU=Sales+CN=J. Smith,DC=example,DC=net
-
Zeilenga LDAP: Distinguished Names [Page 7]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
This example shows the method of escaping of a special characters
appearing in a common name:
-
CN=James \"Jim\" Smith\, III,DC=example,DC=net
-
The following shows the method for encoding a value which contains a
carriage return character:
-
CN=Before\0dAfter,DC=example,DC=net
-
In this RDN example, the type in the RDN is unrecognized, and the
value is the BER encoding of an OCTET STRING containing two octets
0x48 and 0x69.
-
1.3.6.1.4.1.1466.0=#04024869
-
Finally, this example shows an RDN whose commonName value consisting
of 5 letters:
-
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
-
could be encoded in printable ASCII (useful for debugging purposes)
as:
-
CN=Lu\C4\8Di\C4\87
-
5. Security Considerations
-
The following security considerations are specific to the handling of
distinguished names. LDAP security considerations are discussed in
[Protocol] and other documents comprising the LDAP Technical
Specification [Roadmap].
-
5.1. Disclosure
-
Distinguished Names typically consist of descriptive information about
the entries they name, which can be people, organizations, devices or
other real-world objects. This frequently includes some of the
-
Zeilenga LDAP: Distinguished Names [Page 8]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
- the common name of the object (i.e. a person's full name)
- 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.
-
+ In some cases, such information can be considered sensitive. In many
+ countries, privacy laws exist which prohibit disclosure of certain
+ kinds of descriptive information (e.g., email addresses). Hence,
+ servers implementors are encouraged to support DIT structural rules
+ and name forms [Models] as these provide a mechanism for
+ administrators to select appropriate naming attributes for entries.
+ Administrators are encouraged to use these mechanisms, access
+ controls, and other administrative controls which may be available to
+ restrict use of attributes containing sensitive information in naming
+ of entries. Additionally, use of authentication and data security
+ services in LDAP [AuthMeth][Protocol] should be considered.
5.2. Use of Distinguished Names in Security Applications
-
The transformations of an AttributeValue value from its X.501 form to
an LDAP string representation are not always reversible back to the
same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
form. An example of a situation which requires the DER form of a
distinguished name is the verification of an X.509 certificate.
-
For example, a distinguished name consisting of one RDN with one AVA,
in which the type is commonName and the value is of the TeletexString
choice with the letters 'Sam' would be represented in LDAP as the
still 'Sam' but of the PrintableString choice would have the same
representation <CN=Sam>.
-
Applications which require the reconstruction of the DER form of the
value SHOULD NOT use the string representation of attribute syntaxes
when converting a distinguished name to the LDAP format. Instead,
U+0023) as described in the first paragraph of Section 2.4.
-
6. Acknowledgment
-
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
-
This document is a product of the IETF LDAPBIS Working Group.
-7. Document Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-
-8. References
+Zeilenga LDAP: Distinguished Names [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+7. Document Editor's Address
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
-Zeilenga LDAP: Distinguished Names [Page 9]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
+ Email: Kurt@OpenLDAP.org
+8. References
[[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
8.1. Normative References
-
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
-
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003.
-
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
-
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
-
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 10]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
-
progress.
-
[REGISTRY] IANA, Object Identifier Descriptors Registry,
<http://www.iana.org/...>.
-
8.2. Informative References
-
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
-
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
-
[X.690] International Telecommunication Union -
Telecommunication Standardization Sector, "Specification
of ASN.1 encoding rules: Basic Encoding Rules (BER),
Encoding Rules (DER)", X.690(1997) (also ISO/IEC
8825-1:1998).
-
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
-
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August
2000.
-
[Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>.
-Appendix A. Presentation Issues
+Zeilenga LDAP: Distinguished Names [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+Appendix A. Presentation Issues
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
-
The string representation described in this document is not intended
to be presented to humans without translation. However, at times it
may be desirable to present non-translated DN strings to users. This
section discusses presentation issues associated with non-translated
DN strings. Presentation of translated DN strings issues are not
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 11]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
-
discussed in this appendix. Transcoding issues are also not discussed
in this appendix.
-
This appendix provides guidance for applications presenting DN strings
to users. This section is not comprehensive, it does not discuss all
presentation issues which implementors may face.
-
Not all user interfaces are capable of displaying the full set of
Unicode characters. Some Unicode characters are not displayable.
-
It is recommended that human interfaces use the optional hex pair
escaping mechanism (Section 2.3) to produce a string representation
suitable for display to the user. For example, an application can
characters appearing in the AttributeValue's string representation (as
demonstrated in the final example of Section 4).
-
When a DN string is displayed in free form text, it is often necessary
to distinguish the DN string from surrounding text. While this is
often done with white space (as demonstrated in Section 4), it is
be noted to the user that the wrapping '<' and '>' characters are not
part of the DN string.
-
DN strings can be quite long. It is often desirable to line-wrap
overly long DN strings in presentations. Line wrapping should be done
by inserting white space after the RDN separator character or, if
the user that the inserted white space is not part of the DN string
and is to be removed before use in LDAP. For example,
-
The following DN string is long:
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
so it has been line-wrapped for readability. The extra white
space is to be removed before the DN string is used in LDAP.
-
It is not advised to insert white space otherwise as it may not be
obvious to the user which white space is part of the DN string and
which white space was added for readability.
-
Another alternative is to use the LDAP Data Interchange Format (LDIF)
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 12]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
-
[RFC2849]. For example,
-
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
objectClass: person
-
Appendix B. Changes made since RFC 2253
-
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
-
The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed.
- Replaced all references to ISO 10646-1 with [Unicode].
- Updated Section 2.4 to allow hex pair escaping of all characters
and clarified escaping for when multiple octet UTF-8 encodings are
present. Indicated that null (U+0000) character is to be escaped.
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 13]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
Indicated that equals sign ('=' U+003D) character may be escaped
as '\='.
- Rewrote Section 3 to use ABNF as defined in RFC 2234.
+ do not require escaping of non-leading number sign ('#' U+0023)
characters,
+ allow space (' ' U+0020) to escaped as '\ ',
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 13]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
-
+ require hex escaping of null (U+0000) characters, and
+ removed LDAPv2-only constructs.
- Updated Section 3 to describe how to parse elements of the
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
-
In addition, numerous editorial changes were made.
-
Intellectual Property Rights
-
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
-
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
-
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
-Full Copyright
+
+Zeilenga LDAP: Distinguished Names [Page 14]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
- Copyright (C) The Internet Society (2004). This document is subject
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
-
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 14]
-INTERNET-DRAFT draft-ietf-ldapbis-dn-15.txt 24 October 2004
-
-
-
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+Zeilenga LDAP: Distinguished Names [Page 15]
+\f
-
-
-
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 15]
\ No newline at end of file
-
-
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2254 T. Howes
-Expires: 24 April 2005 Opsware, Inc.
- 24 October 2004
+Expires: 16 May 2005 Opsware, Inc.
+ 16 November 2004
LDAP: String Representation of Search Filters
- <draft-ietf-ldapbis-filter-08.txt>
+ <draft-ietf-ldapbis-filter-09.txt>
Smith & Howes Intended Category: Standards Track [Page 1]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Abstract
LDAP search filters are transmitted in the LDAP protocol using a
binary representation that is appropriate for use on the network.
This document defines a human-readable string representation of LDAP
- search filters that is appropriate for use in LDAP URLs and in other
- applications.
+ search filters that is appropriate for use in LDAP URLs [LDAPURL] and
+ in other applications.
Table of Contents
7. Normative References...........................................7
8. Informative References.........................................8
9. Acknowledgments................................................8
-10. Authors' Addresses.............................................8
+10. Authors' Addresses.............................................9
11. Appendix A: Changes Since RFC 2254.............................9
11.1. Technical Changes...........................................9
11.2. Editorial Changes...........................................10
12. Appendix B: Changes Since Previous Document Revision...........11
-12.1. Editorial Changes...........................................11
-13. Intellectual Property Rights...................................11
-14. Full Copyright.................................................12
+12.1. Technical Changes...........................................11
+12.2. Editorial Changes...........................................12
+ Intellectual Property Rights...................................12
+ Full Copyright.................................................13
1. Introduction
- The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a
network representation of a search filter transmitted to an LDAP
server. Some applications may find it useful to have a common way of
representing these search filters in a human-readable form; LDAP URLs
possible LDAP version 3 search filters, including extended match
filters.
- This document is an integral part of the LDAP Technical Specification
- [Roadmap].
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
- This document replaces RFC 2254. Changes to RFC 2254 are summarized
- in Appendix A.
Smith & Howes Intended Category: Standards Track [Page 2]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ This document replaces RFC 2254. Changes to RFC 2254 are summarized
+ in Appendix A.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2. LDAP Search Filter Definition
- An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
+ An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
follows:
Filter ::= CHOICE {
AttributeValue ::= OCTET STRING
- MatchingRuleId ::= LDAPString
-
- AssertionValue ::= OCTET STRING
Smith & Howes Intended Category: Standards Track [Page 3]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ MatchingRuleId ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
- The AttributeDescription is a string representation of the attribute
- description and is defined in [Protocol]. The AttributeValue and
- AssertionValue OCTET STRING have the form defined in [Syntaxes]. The
- Filter is encoded for transmission over a network using the Basic
- Encoding Rules (BER) defined in [X.690], with simplifications
- described in [Protocol].
+ The AttributeDescription, as defined in [Protocol], is a string
+ representation of the attribute description that is discussed in
+ [Models]. The AttributeValue and AssertionValue OCTET STRING have
+ the form defined in [Syntaxes]. The Filter is encoded for
+ transmission over a network using the Basic Encoding Rules (BER)
+ defined in [X.690], with simplifications described in [Protocol].
3. String Search Filter Definition
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
- extensible = attr [dnattrs]
- [matchingrule] COLON EQUALS assertionvalue
- / [dnattrs]
- matchingrule COLON EQUALS assertionvalue
- / COLON EQUALS assertionvalue
+ extensible = ( attr [dnattrs]
+ [matchingrule] COLON EQUALS assertionvalue )
+ / ( [dnattrs]
+ matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
; Section 2.5 of [Models].
- dnattrs = COLON "dn"
- matchingrule = COLON oid
- assertionvalue = valueencoding
Smith & Howes Intended Category: Standards Track [Page 4]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+ dnattrs = COLON "dn"
+ matchingrule = COLON oid
+ assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue>
; from Section 4.1.6 of [Protocol].
valueencoding = 0*(normal / escaped)
For AssertionValues that contain UTF-8 character data, each octet of
the character to be escaped is replaced by a backslash and two hex
- digits, which form a single octet in the code of the character.
-
- For example, the filter checking whether the "cn" attribute contained
- a value with the character "*" anywhere in it would be represented as
+ digits, which form a single octet in the code of the character. For
+ example, the filter checking whether the "cn" attribute contained a
+ value with the character "*" anywhere in it would be represented as
"(cn=*\2a*)".
- As indicated by the valueencoding rule, implementations MUST escape
+ As indicated by the <valueencoding> rule, implementations MUST escape
all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a
search filter. Implementations SHOULD accept as input strings that
are not valid UTF-8 strings. This is necessary because RFC 2254 did
- not clearly define the term "string representation" (and in
- particular did not mention that the string representation of an LDAP
Smith & Howes Intended Category: Standards Track [Page 5]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+ not clearly define the term "string representation" (and in
+ particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8 encoded Unicode characters).
4. Examples
The following examples illustrate the use of extensible matching.
- (cn:1.2.3.4.5:=Fred Flintstone)
+ (cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
- (:dn:2.4.6.8.10:=Dino)
+ (:DN:2.4.6.8.10:=Dino)
- The first example shows use of the matching rule "1.2.3.4.5".
+ The first example shows use of the matching rule "caseExactMatch."
The second example demonstrates use of a MatchingRuleAssertion form
without a matchingRule.
The third example illustrates the use of the ":oid" notation to
- indicate that matching rule "2.4.6.8.10" should be used when making
- comparisons, and that the attributes of an entry's distinguished name
- should be considered part of the entry when evaluating the match
- (indicated by the use of ":dn").
+ indicate that matching rule identified by the OID "2.4.6.8.10" should
+ be used when making comparisons, and that the attributes of an
+ entry's distinguished name should be considered part of the entry
+ when evaluating the match (indicated by the use of ":dn").
The fourth example denotes an equality match, except that DN
components should be considered part of the entry when doing the
match.
The fifth example is a filter that should be applied to any attribute
- supporting the matching rule given (since the attr has been omitted).
+ supporting the matching rule given (since the <attr> has been
+ omitted).
The sixth and final example is also a filter that should be applied
to any attribute supporting the matching rule given. Attributes
supporting the matching rule contained in the DN should also be
considered.
- The following examples illustrate the use of the escaping mechanism.
-
- (o=Parens R Us \28for all your parenthetical needs\29)
Smith & Howes Intended Category: Standards Track [Page 6]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ The following examples illustrate the use of the escaping mechanism.
+ (o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
substring indicator. The third illustrates the escaping of the
backslash character.
- The fourth example shows a filter searching for the four-byte value
- 0x00000004, illustrating the use of the escaping mechanism to
+ The fourth example shows a filter searching for the four octet value
+ 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
represent arbitrary data, including NUL characters.
The fifth example illustrates the use of the escaping mechanism to
- represent various non-ASCII UTF-8 characters.
+ represent various non-ASCII UTF-8 characters. Specifically, there are
+ 5 characters in the <assertionvalue> portion of this example: LATIN
+ CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
+ LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
+ LATIN SMALL LETTER C WITH ACUTE (U+0107).
The sixth and final example demonstrates assertion of a BER encoded
value.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress.
-[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+Smith & Howes Intended Category: Standards Track [Page 7]
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-Smith & Howes Intended Category: Standards Track [Page 7]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
(http://www.unicode.org/reports/tr27/) and by the "Unicode
Standard Annex #28: Unicode 3.2."
+8. Informative References
+
+[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
Distinguished Encoding Rules, ITU-T Recommendation X.690,
1994.
-8. Informative References
+9. Acknowledgments
- None.
+ This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
+ of the IETF ASID Working Group.
-9. Acknowledgments
+ 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.
- This document replaces RFC 2254 by Tim Howes. Changes included in
- this revised specification are based upon discussions among the
- authors, discussions within the LDAP (v3) Revision Working Group
- (ldapbis), and discussions within other IETF Working Groups. The
- contributions of individuals in these working groups is gratefully
- acknowledged.
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
10. Authors' Addresses
Saline, MI 48176
USA
+1 734 944-2856
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
-
-
mcs@pearlcrescent.com
"simple", "extensible", and "substring" ("initial", "any", and
"final") rules. This matches a change made in [Syntaxes].
+ Added "(" and ")" around the components of the <extensible>
+ subproductions for clarity.
+
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
precisely reference productions from the [Models] and [Protocol]
documents.
"String Search Filter Definition" section: replaced "greater" and
"less" with "greaterorequal" and "lessorequal" to avoid confusion.
- Introduced the "valueencoding" and associated "normal" and "escaped"
- rules to reduce the dependence on descriptive text. The "normal"
- production restricts filter strings to valid UTF-8 sequences.
- Added a third option to the "extensible" production to allow creation
- of a MatchingRuleAssertion that only has a matchValue.
- Added a statement about expected behavior in light of RFC 2254's lack
- of a clear definition of "string representation."
+Smith & Howes Intended Category: Standards Track [Page 9]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+ Introduced the "valueencoding" and associated "normal" and "escaped"
+ rules to reduce the dependence on descriptive text. The "normal"
+ production restricts filter strings to valid UTF-8 sequences.
+ Added a statement about expected behavior in light of RFC 2254's lack
+ of a clear definition of "string representation."
-Smith & Howes Intended Category: Standards Track [Page 9]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
11.2. Editorial Changes
this document (instead of RFC 1960). Added reference to the [Roadmap]
document.
- "LDAP Search Filter Definition" section: made corrections to the
- LDAPv3 search filter ABNF so it matches that used in [Protocol].
+ "LDAP Search Filter Definition" section: made corrections to the LDAP
+ search filter ABNF so it matches that used in [Protocol].
Clarified the definition of 'value' (now 'assertionvalue') to take
into account the fact that it is not precisely an AttributeAssertion
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value". Corrected the description of this
- example: (sn:dn:2.4.6.8.10:=Barney Rubble).
+ example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
+ in the first extensible match example with "caseExactMatch" to
+ demonstrate use of the descriptive form. Used "DN" (uppercase) in
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ the last extensible match example to remind the reader to treat the
+ <dnattrs> production as case insensitive. Reworded the description
+ of the fourth escaping mechanism example to avoid making assumptions
+ about byte order. Added text to the fifth escaping mechanism example
+ to spell out what the non-ASCII characters are in Unicode terms.
"Security Considerations" section: added references to [Protocol] and
[AuthMeth].
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
-
-
- "Informative References" section: added for clarity.
+ "Informative References" section: (new section) moved [X.690] to this
+ section. Added a reference to [LDAPURL].
"Acknowledgments" section: added.
"Appendix B: Changes Since Previous Document Revision" section:
added.
+ Surrounded the names of all ABNF productions with "<" and ">" where
+ they are used in descriptive text.
+
+ Replaced all occurrences of "LDAPv3" with "LDAP."
+
12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-filter-07.txt. Note that when
+ revision, draft-ietf-ldapbis-filter-08.txt. Note that when
appropriate these changes are also included in Appendix A, but are
also included here for the benefit of the people who have already
- reviewed draft-ietf-ldapbis-filter-07.txt. This section will be
+ reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
removed before this document is published as an RFC.
-12.1. Editorial Changes
+12.1. Technical Changes
- "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
- paragraph with the version that says "each author" instead of "I."
+ Removed the third option from the "extensible" production that
+ allowed creation of a MatchingRuleAssertion that only had a
+ matchValue (disallowed By [Protocol]). Added "(" and ")" around the
+ components of the <extensible> subproductions for clarity.
- "Status of this Memo" section: added 2 paragraphs that were
- accidently removed from the -07 revision (one begins with "The list
- of current Internet-Drafts..." and the other begins with "The list of
- Internet-Draft Shadow Directories...."
-13. Intellectual Property Rights
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+12.2. Editorial Changes
+
+ "Introduction" section: referenced [Roadmap] upon first use of LDAP
+ and expanded the paragraph that begins "This document is an integral
+ part of the LDAP technical specification..." to match the text used
+ in [Protocol].
+
+ "LDAP Search Filter Definition" section: reworded the last paragraph
+ for clarity.
+
+ "Examples" section: Replaced the numeric OID in the first extensible
+ match example with "caseExactMatch" to demonstrate use of the
+ descriptive form. Used "DN" (uppercase) in the last extensible match
+ example to remind the reader to treat the <dnattrs> production as
+ case insensitive. Reworded the description of the fourth escaping
+ mechanism example to avoid making assumptions about byte order.
+ Added text to the fifth escaping mechanism example to spell out what
+ the non-ASCII characters are in Unicode terms.
+
+ References: added [LDAPURL] and moved [X.690] to "Informative
+ References."
+
+ "Acknowledgements" section: added the sentence "RFC 2254 was a
+ product of the IETF ASID Working Group."
+
+ Changed these two sections to unnumbered ones: "Intellectual Property
+ Rights" and "Full Copyright."
+
+ Surrounded the names of all ABNF productions with "<" and ">" where
+ they are used in descriptive text.
+
+ Replaced all occurrences of "LDAPv3" with "LDAP."
+
+
+Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-Smith & Howes Intended Category: Standards Track [Page 11]
-\f
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 24 October 2004
+Smith & Howes Intended Category: Standards Track [Page 12]
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
-14. Full Copyright
+Full Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-This Internet Draft expires on 24 April 2005.
-
-
-
+This Internet Draft expires on 16 May 2005.
-
-Smith & Howes Intended Category: Standards Track [Page 12]
-\f
-
+Smith & Howes Intended Category: Standards Track [Page 13]
\ No newline at end of file
+
+
+
+
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 24 October 2004
-Obsoletes: RFC 2251, RFC 2252, RFC 2256
-
+Expires in six months 21 February 2005
+Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
LDAP: Directory Information Models
- <draft-ietf-ldapbis-models-12.txt>
-
+ <draft-ietf-ldapbis-models-14.txt>
Status of this Memo
-
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the editor <Kurt@OpenLDAP.org>.
-
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
-
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
-
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
-
The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
+ http://www.ietf.org/1id-abstracts.html
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
-
-
-
Zeilenga LDAP Models [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
Abstract
-
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP.
-
Table of Contents
-
Status of this Memo 1
Abstract 2
Table of Contents
2.3. Naming of Entries 8
2.4. Object Classes 9
2.5. Attribute Descriptions 12
- 2.6. Alias Entries 15
+ 2.6. Alias Entries 16
3. Directory Administrative and Operational Information 17
3.1. Subtrees
- 3.2. Subentries
- 3.3. The 'objectClass' attribute 18
+ 3.2. Subentries 18
+ 3.3. The 'objectClass' attribute
3.4. Operational attributes 19
- 4. Directory Schema 20
+ 4. Directory Schema 22
4.1. Schema Definitions 23
- 4.2. Subschema Subentries 30
+ 4.2. Subschema Subentries 32
4.3. 'extensibleObject' 35
- 4.4. Subschema Discovery
- 5. DSA (Server) Informational Model 36
- 5.1. Server-specific Data Requirements
- 6. Other Considerations 39
- 6.1. Preservation of User Information 40
+ 4.4. Subschema Discovery 36
+ 5. DSA (Server) Informational Model
+ 5.1. Server-specific Data Requirements 37
+ 6. Other Considerations 40
+ 6.1. Preservation of User Information 41
6.2. Short Names
- 6.3. Cache and Shadowing 41
- 7. Implementation Guidelines
+ 6.3. Cache and Shadowing
+ 7. Implementation Guidelines 42
7.1. Server Guidelines
7.2. Client Guidelines
- 8. Security Considerations 42
+ 8. Security Considerations 43
9. IANA Considerations
- 10. Acknowledgments 43
+ 10. Acknowledgments 44
11. Editor's Address
- 12. References 44
-
+ 12. References
Zeilenga LDAP Models [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
- 12.1. Normative References
- 12.2. Informative References 45
+ 12.1. Normative References 45
+ 12.2. Informative References
Appendix A. Changes
- Intellectual Property Rights 50
+ Intellectual Property Rights 51
Full Copyright
-
1. Introduction
-
This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[Roadmap].
-
The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory is
collectively known as the Directory Information Base (DIB). A
servers (or Directory System Agents (DSA)). A server holds a fragment
of the DIB.
-
The DIB contains two classes of information:
-
1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information.
-
2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational
Information.
-
These two models, referred to as the generic Directory Information
Models, describe how information is represented in the Directory.
These generic models provide a framework for other information models.
Section 4 discusses the subschema information model and subschema
discovery. Section 5 discusses the DSA (Server) Informational Model.
-
Other X.500 information models, such as access control distribution
knowledge, and replication knowledge information models, may be
adapted for use in LDAP. Specification of how these models apply to
LDAP is left to future documents.
-
1.1. Relationship to Other LDAP Specifications
-
This document is a integral part of the LDAP technical specification
[Roadmap] which obsoletes the previously defined LDAP technical
-
Zeilenga LDAP Models [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
specification, RFC 3377, in its entirety.
-
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
- portions of sections 4 and 6. Appendix A.1 summaries changes to these
- sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
- [AuthMeth], and [Roadmap] documents.
-
+ portions of sections 4 and 6. Appendix A.1 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [Protocol], [AuthMeth], and [Roadmap] documents.
This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
- summaries changes to these sections. The remainder of RFC 2252 is
+ summarizes changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes].
-
This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of
RFC 2256 is obsoleted by [Schema] and [Syntaxes].
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
1.2. Relationship to X.501
-
This document includes material, with and without adaptation, from
- [X.501]. The material in this document takes precedence over that in
- [X.501].
-
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
1.3. Conventions
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
-
Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these definitions are specified in [Syntaxes].
-
1.4. Common ABNF Productions
-
A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following
common productions:
-
keystring = leadkeychar *keychar
leadkeychar = ALPHA
- keychar = ALPHA / DIGIT / HYPHEN
- number = DIGIT / ( LDIGIT 1*DIGIT )
-
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
-
Zeilenga LDAP Models [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ keychar = ALPHA / DIGIT / HYPHEN
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
-
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
-
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
-
; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
-
OCTET = %x00-FF ; Any octet (8-bit data unit)
-
Object identifiers (OIDs) [X.680] are represented in LDAP using a
dot-decimal format conforming to the ABNF:
- numericoid = number 1*( DOT number )
-
-
- Short names, also known as descriptors, are used as more readable
- aliases for object identifiers. Short names are case insensitive and
-
-
Zeilenga LDAP Models [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ numericoid = number 1*( DOT number )
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
conform to the ABNF:
-
descr = keystring
-
Where either an object identifier or a short name may be specified,
the following production is used:
-
oid = descr / numericoid
-
While the <descr> form is generally preferred when the usage is
restricted to short names referring to object identifiers which
identify like kinds of objects (e.g., attribute type descriptions,
identify multiple kinds of objects or when an unambiguous short name
(descriptor) is not available.
-
Implementations SHOULD treat short names (descriptors) used in an
ambiguous manner (as discussed above) as unrecognized.
-
Short Names (descriptors) are discussed further in Section 6.2.
-
2. Model of Directory User Information
-
As [X.501] states:
-
The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named).
-
An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object belongs
to at least one class. An object class may be a subclass of other
the superclasses. There may be subclasses of subclasses, etc., to
an arbitrary depth.
-
A directory entry, a named collection of information, is the basic
unit of information held in the Directory. There are multiple kinds
of directory entries.
-
An object entry represents a particular object. An alias entry
- provides alternative naming. A subentry holds administrative and/or
- operational information.
-
-
- The set of entries representing the DIB are organized hierarchically
-
Zeilenga LDAP Models [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+ The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT).
-
Section 2.1 describes the Directory Information Tree
Section 2.2 discusses the structure of entries.
Section 2.3 discusses naming of entries.
Section 2.6 discusses alias entries.
-
2.1. The Directory Information Tree
-
As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information
Tree (DIT). Specifically, a tree where vertices are the entries.
-
The arcs between vertices define relations between entries. If an arc
exists from X to Y, then the entry at X is the immediate superior of Y
and Y is the immediate subordinate of X. An entry's superiors are the
entry's immediate superior and its superiors. An entry's subordinates
are all of its immediate subordinates and their subordinates.
-
Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships
between objects.
-
Note: An entry's immediate superior is also known as the entry's
parent and an entry's immediate subordinate is also known as the
entry's child. Entries which have the same parent are known as
siblings.
-
2.2. Structure of an Entry
-
An entry consists of a set of attributes which hold information about
the object which the entry represents. Some attributes represent user
information and are called user attributes. Other attributes
represent operational and/or administrative information and are called
operational attributes.
-
An attribute is an attribute description (a type and zero or more
options) with one or more associated values. An attribute is often
referred to by its attribute description. For example, the
- 'givenName' attribute is the attribute which consists of the attribute
- description 'givenName' (the 'givenName' attribute type [Schema] and
- zero options) and one or more associated values.
-
-
Zeilenga LDAP Models [Page 7]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+ 'givenName' attribute is the attribute which consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [Schema] and
+ zero options) and one or more associated values.
The attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. Options indicate
subtypes and other functions.
-
Attribute values conform to the defined syntax of the attribute type.
-
No two values of an attribute may be equivalent. Two values are
- considered equivalent only if they would match according to the
- equality matching rule of the attribute type. If the attribute type
+ considered equivalent if and only if they would match according to the
+ equality matching rule of the attribute type or, if the attribute type
is defined with no equality matching rule, two values are equivalent
if and only if they are identical. (See 2.5.1 for other
restrictions.)
-
For example, a 'givenName' attribute can have more than one value,
they must be Directory Strings, and they are case insensitive. A
'givenName' attribute cannot hold both "John" and "JOHN" as these are
equivalent values per the equality matching rule of the attribute
type.
+ Additionally, no attribute is to have a value which is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string which includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
When an attribute is used for naming of the entry, one and only one
value of the attribute is used in forming the Relative Distinguished
Name. This value is known as a distinguished value.
-
2.3. Naming of Entries
-
2.3.1. Relative Distinguished Names
-
Each entry is named relative to its immediate superior. This relative
name, known as its Relative Distinguished Name (RDN) [X.501], is
composed of an unordered set of one or more attribute value assertions
attribute value. These AVAs are chosen to match attribute values
(each a distinguished value) of the entry.
-
An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all
- siblings).
- The following are examples of string representations of RDNs [LDAPDN]:
+Zeilenga LDAP Models [Page 8]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ siblings).
+
+ The following are examples of string representations of RDNs [LDAPDN]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
-
The last is an example of a multi-valued RDN. That is, an RDN
composed of multiple AVAs.
-
-
-Zeilenga LDAP Models [Page 8]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
2.3.2. Distinguished Names
-
An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are examples of string representations of DNs
[LDAPDN]:
-
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
-
2.3.3. Alias Names
-
An alias, or alias name, is "an name for an object, provided by the
use of alias entries" [X.501]. Alias entries are described in Section
2.6.
-
2.4. Object Classes
-
An object class is "an identified family of objects (or conceivable
objects) which share certain characteristics" [X.501].
-
As defined in [X.501]:
-
Object classes are used in the Directory for a number of purposes:
-
- describing and categorising objects and the entries that
correspond to these objects;
-
- where appropriate, controlling the operation of the Directory;
-
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
+
+
+Zeilenga LDAP Models [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
-
- identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority.
-
An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process
2.4.1). An ordered set of superclasses up to the most superior
object class of an object class is its superclass chain.
-
-
-
-Zeilenga LDAP Models [Page 9]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance.
-
Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes
allowed to be present in entries belonging to the class. As an entry
attribute allowed by its superclass as being required. If an
attribute is a member of both sets, it is required to be present.
-
Each object class is defined to be one of three kinds of object
classes: Abstract, Structural, or Auxiliary.
-
Each object class is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
-
2.4.1. Abstract Object Classes
-
An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to an abstract object class
unless it belongs to a structural or auxiliary class which inherits
from that abstract class.
-
Abstract object classes can not derive from structural nor auxiliary
object classes.
-
All structural object classes derive (directly or indirectly) from the
'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'.
+
+
+Zeilenga LDAP Models [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The following is the object class definition (see Section 4.1.1) for
the 'top' object class:
-
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
All entries belong to the 'top' abstract object class.
-
2.4.2. Structural Object Classes
-
As stated in [X.501]:
-
An object class defined for use in the structural specification of
-
-
-
-
-Zeilenga LDAP Models [Page 10]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names
of the objects for compliant entries.
-
An object or alias entry is characterised by precisely one
structural object class superclass chain which has a single
structural object class as the most subordinate object class.
This structural object class is referred to as the structural
object class of the entry.
-
Structural object classes are related to associated entries:
-
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
-
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
-
- the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an
entry.
-
The structural object class of an entry shall not be changed.
-
Each structural object class is a (direct or indirect) subclass of the
'top' abstract object class.
-
Structural object classes cannot subclass auxiliary object classes.
-
Each entry is said to belong to its structural object class as well as
all classes in its structural object class's superclass chain.
-2.4.3. Auxiliary Object Classes
+Zeilenga LDAP Models [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.4.3. Auxiliary Object Classes
+
Auxiliary object classes are used to augment the characteristics of
entries. They are commonly used to augment the sets of attributes
required and allowed to be present in an entry. They can be used to
describe entries or classes of entries.
-
Auxiliary object classes cannot subclass structural object classes.
-
An entry can belong to any subset of the set of auxiliary object
classes allowed by the DIT content rule associated with the structural
object class of the entry. If no DIT content rule is associated with
the structural object class of the entry, the entry cannot belong to
-
-
-
-
-Zeilenga LDAP Models [Page 11]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
any auxiliary object class.
-
The set of auxiliary object classes which an entry belongs to can
change over time.
-
2.5. Attribute Descriptions
-
An attribute description is composed of an attribute type (see Section
2.5.1) and a set of zero or more attribute options (see Section
2.5.2).
-
An attribute description is represented by the ABNF:
-
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
-
where <attributetype> identifies the attribute type and each <option>
identifies an attribute option. Both <attributetype> and <option>
productions are case insensitive. The order in which <option>s appear
is irrelevant. That is, any two <attributedescription>s which consist
of the same <attributetype> and same set of <option>s are equivalent.
-
Examples of valid attribute descriptions:
-
2.5.4.0
cn;lang-de;lang-en
owner
-
An attribute description with an unrecognized attribute type is to be
treated as unrecognized. Servers SHALL treat an attribute description
with an unrecognized attribute option as unrecognized. Clients MAY
treat an unrecognized attribute option as a tagging option (see
- Section 2.5.2.1).
- All attributes of an entry must have distinct attribute descriptions.
+Zeilenga LDAP Models [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-2.5.1. Attribute Types
+ Section 2.5.2.1).
+ All attributes of an entry must have distinct attribute descriptions.
+
+
+2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions.
-
If no equality matching is specified for the attribute type:
- the attribute (of the type) cannot be used for naming;
-
-
-
-
-Zeilenga LDAP Models [Page 12]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
- when adding the attribute (or replacing all values), no two values
may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be
- attribute value assertions (such as matching in search filters and
comparisons) using values of such a type cannot be performed.
-
- Otherwise, the equality matching rule is to be used for the purposes
- of evaluating attribute value assertions concerning the attribute
- type.
-
+ Otherwise, the specified equality matching rule is to be used for the
+ purposes of evaluating attribute value assertions concerning the
+ attribute type. The specified equality rule is to be transitive and
+ commutative.
The attribute type indicates whether the attribute is a user attribute
or an operational attribute. If operational, the attribute type
modifiable by users or not. Operational attributes are discussed in
Section 3.4.
-
An attribute type (a subtype) may derive from a more generic attribute
type (a direct supertype). The following restrictions apply to
subtyping:
- a subtype must be collective [RFC3671] if its supertype is
collective.
-
An attribute description consisting of a subtype and no options is
said to be the direct description subtype of the attribute description
consisting of the subtype's direct supertype and no options.
-
Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
-2.5.2. Attribute Options
+Zeilenga LDAP Models [Page 13]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.5.2. Attribute Options
+
There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options.
-
Not all options can be associated with attributes held in the
directory. Tagging options can be.
-
Not all options can be used in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
-
An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
-
-
-
-
-Zeilenga LDAP Models [Page 13]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
"x-foo" and "x-bar" are mutually exclusive, is to be treated as
unrecognized.
-
Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to
tagging options. In particular, these documents must detail whether
values, and how new kinds of options are treated in attribute
description hierarchies.
-
Options are represented as short case insensitive textual strings
conforming to the <option> production defined in Section 2.5 of this
document.
-
Procedures for registering options are detailed in BCP 64 [BCP64bis].
-
2.5.2.1. Tagging Options
-
Attributes held in the directory can have attribute descriptions with
any number of tagging options. Tagging options are never mutually
exclusive.
-
An attribute description with N tagging options is a direct
(description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute
-2.5.3. Attribute Description Hierarchies
+
+Zeilenga LDAP Models [Page 14]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+2.5.3. Attribute Description Hierarchies
+
An attribute description can be the direct subtype of zero or more
other attribute descriptions as indicated by attribute type subtyping
(as described in Section 2.5.1) or attribute tagging option subtyping
(as described in Section 2.5.2.1). These subtyping relationships are
used to form hierarchies of attribute descriptions and attributes.
-
As adapted from [X.501]:
-
Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific
-
-
-
-
-Zeilenga LDAP Models [Page 14]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
attribute description (a direct reference to the attribute) or by
a more generic attribute description (an indirect reference).
-
Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the
more generalized. Searching for, or retrieving attributes and
the more specialized descriptions as well as for the quoted
description.
-
Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are
available. An attribute value shall always be returned as a value
of its own attribute description.
-
All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user
modification of entry content.
-
An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
-
For the purpose of subschema administration of the entry, a
specification that an attribute is required is fulfilled if the entry
contains a value of an attribute description belonging to an attribute
is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
'name'). Likewise, an entry may contain a value of an attribute
+
+
+
+Zeilenga LDAP Models [Page 15]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
description belonging to an attribute hierarchy where the attribute
type of that description is either explicitly included in the
definition of an object class to which the entry belongs or allowed by
'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
name").
-
For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative model,
all of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions.
-
-
-
-Zeilenga LDAP Models [Page 15]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
2.6. Alias Entries
-
As adapted from [X.501]:
-
An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of
alias entries.
-
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500]), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
-
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
-
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
-
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
-
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
-
Every alias entry shall belong to the 'alias' object class.
-
An entry with the 'alias' object class must also belong to an object
+
+
+
+Zeilenga LDAP Models [Page 16]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
class (or classes), or be governed by a DIT content rule, which allows
suitable naming attributes to be present.
-
Example:
dn: cn=bar,dc=example,dc=com
objectClass: top
aliasedObjectName: cn=foo,dc=example,dc=com
-
2.6.1. 'alias' object class
-
-
-
-
-Zeilenga LDAP Models [Page 16]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
Alias entries belong to the 'alias' object class.
-
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
-
2.6.2. 'aliasedObjectName' attribute type
-
The 'aliasedObjectName' attribute holds the name of the entry an alias
points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500.
-
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
-
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
3. Directory Administrative and Operational Information
-
This section discusses select aspects of the X.500 Directory
Administrative and Operational Information model [X.501]. LDAP
implementations MAY support other aspects of this model.
-
3.1. Subtrees
-
As defined in [X.501]:
-
A subtree is a collection of object and alias entries situated at
+
+
+
+Zeilenga LDAP Models [Page 17]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
the vertices of a tree. Subtrees do not contain subentries. The
prefix sub, in subtree, emphasizes that the base (or root) vertex
of this tree is usually subordinate to the root of the DIT.
-
A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For
replicated area are bounded by a naming context.
-
3.2. Subentries
-
A subentry is a "special sort of entry, known by the Directory, used
-
-
-
-
-Zeilenga LDAP Models [Page 17]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
to hold information associated with a subtree or subtree refinement"
[X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is
detailed in [RFC3672].
-
The term "(sub)entry" in this specification indicates that servers
implementing X.500(93) models are, in accordance with X.500(93) as
described in [RFC3672], to use a subentry and that other servers are
all subentries are named with 'cn').
-
3.3. The 'objectClass' attribute
-
Each entry in the DIT has an 'objectClass' attribute.
-
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
-
The 'objectClass' attribute specifies the object classes of an entry,
which (among other things) is used in conjunction with the controlling
schema to determine the permitted attributes of an entry. Values of
this attribute can be modified by clients, but the 'objectClass'
attribute cannot be removed.
-
Servers which follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry from
+
+
+
+Zeilenga LDAP Models [Page 18]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
being changed. That is, one cannot change a 'person' into a
'country'.
-
When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a' is
a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
'x-b' to be implicitly added (if is not already present).
-
Servers SHALL restrict modifications of this attribute to prevent
superclasses of remaining 'objectClass' values from being deleted.
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
an attempt to delete only 'x-b' from the 'objectClass' attribute is an
-
-
-
-
-Zeilenga LDAP Models [Page 18]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
error.
-
3.4. Operational attributes
-
Some attributes, termed operational attributes, are used or maintained
by servers for administrative and operational purposes. As stated in
[X.501]: "There are three varieties of operational attributes:
Directory operational attributes, DSA-shared operational attributes,
and DSA-specific operational attributes."
-
A directory operational attribute is used to represent operational
and/or administrative information in the Directory Information Model.
This includes operational attributes maintained by the server (e.g.
'createTimestamp') as well as operational attributes which hold values
administrated by the user (e.g. 'ditContentRules').
-
A DSA-shared operational attribute is used to represent information of
the DSA Information Model which is shared between DSAs.
-
A DSA-specific operational attribute is used to represent information
of the DSA Information Model which is specific to the DSA (though, in
some cases, may be derived from information shared between DSAs)
(e.g., 'namingContexts').
-
The DSA Information Model operational attributes are detailed in
[X.501].
-
Operational attributes are not normally visible. They are not
returned in search results unless explicitly requested by name.
-
Not all operational attributes are user modifiable.
-
Entries may contain, among others, the following operational
- attributes:
+
+Zeilenga LDAP Models [Page 19]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ attributes:
+
- creatorsName: the Distinguished Name of the user who added this
entry to the directory,
-
- createTimestamp: the time this entry was added to the directory,
-
- modifiersName: the Distinguished Name of the user who last
modified this entry, and
-
- modifyTimestamp: the time this entry was last modified.
-
Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
'modifiersName', and 'modifyTimestamp' attributes for all entries of
-
-
-
-
-Zeilenga LDAP Models [Page 19]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
the DIT.
-
3.4.1. 'creatorsName'
-
This attribute appears in entries which were added using the protocol
(e.g., using the Add operation). The value is the distinguished name
of the creator.
-
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
3.4.2. 'createTimestamp'
-
This attribute appears in entries which were added using the protocol
(e.g., using the Add operation). The value is the time the entry was
added.
-
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
- are defined in [Syntaxes].
-3.4.3. 'modifiersName'
+Zeilenga LDAP Models [Page 20]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ are defined in [Syntaxes].
+3.4.3. 'modifiersName'
+
This attribute appears in entries which have been modified using the
protocol (e.g., using Modify operation). The value is the
distinguished name of the last modifier.
-
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
-
-
-Zeilenga LDAP Models [Page 20]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
3.4.4. 'modifyTimestamp'
-
This attribute appears in entries which have been modified using the
protocol (e.g., using the Modify operation). The value is the time
the entry was last modified.
-
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
are defined in [Syntaxes].
-
3.4.5. 'structuralObjectClass'
-
This attribute indicates the structural object class of the entry.
-
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
- (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
-3.4.6. 'governingStructureRule'
+Zeilenga LDAP Models [Page 21]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
- This attribute indicates the structure rule governing the entry.
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
+
+
+3.4.6. 'governingStructureRule'
+ This attribute indicates the structure rule governing the entry.
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
-
The 'integerMatch' matching rule and INTEGER
(1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
-
-
-Zeilenga LDAP Models [Page 21]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
4. Directory Schema
-
As defined in [X.501]:
-
The Directory Schema is a set of definitions and constraints
concerning the structure of the DIT, the possible ways entries are
named, the information that can be held in an entry, the
of the information and the ways in which values of attributes may
be matched in attribute value and matching rule assertions.
-
NOTE 1 - The schema enables the Directory system to, for example:
-
- prevent the creation of subordinate entries of the wrong
object-class (e.g. a country as a subordinate of a person);
-
- prevent the addition of attribute-types to an entry
inappropriate to the object-class (e.g. a serial number to a
person's entry);
-
- prevent the addition of an attribute value of a syntax not
matching that defined for the attribute-type (e.g. a printable
string to a bit string).
-
Formally, the Directory Schema comprises a set of:
-
a) Name Form definitions that define primitive naming relations
for structural object classes;
-
b) DIT Structure Rule definitions that define the names that
+
+
+
+Zeilenga LDAP Models [Page 22]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
entries may have and the ways in which the entries may be
related to one another in the DIT;
-
c) DIT Content Rule definitions that extend the specification of
allowable attributes for entries beyond those indicated by the
structural object classes of the entries;
-
d) Object Class definitions that define the basic set of mandatory
and optional attributes that shall be present, and may be
present, respectively, in an entry of a given class, and which
indicate the kind of object class that is being defined;
-
e) Attribute Type definitions that identify the object identifier
by which an attribute is known, its syntax, associated matching
rules, whether it is an operational attribute and if so its
type, whether it is a collective attribute, whether it is
permitted to have multiple values and whether or not it is
-
-
-
-
-Zeilenga LDAP Models [Page 22]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
derived from another attribute type;
-
f) Matching Rule definitions that define matching rules.
-
And in LDAP:
-
g) LDAP Syntax definitions that define encodings used in LDAP.
-
4.1. Schema Definitions
-
Schema definitions in this section are described using ABNF and rely
on the common productions specified in Section 1.2 as well as these:
-
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
-
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
-
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
-
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
-
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+Zeilenga LDAP Models [Page 23]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
-
; Any UTF-8 encoded Unicode character
; except %x27 ("'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
-
; Any ASCII character except %x27 ("'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
-
Schema definitions in this section also share a number of common
terms.
-
The NAME field provides a set of short names (descriptors) which are
to be used as aliases for the OID.
-
-
-
-
-Zeilenga LDAP Models [Page 23]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
The DESC field optionally allows a descriptive string to be provided
by the directory administrator and/or implementor. While
specifications may suggest a descriptive string, there is no
requirement that the suggested (or any) descriptive string be used.
-
The OBSOLETE field, if present, indicates the element is not active.
-
Implementors should note that future versions of this document may
expand these definitions to include additional terms. Terms whose
identifier begins with "X-" are reserved for private experiments, and
are followed by <SP> and <qdstrings> tokens.
-
4.1.1. Object Class Definitions
-
Object Class definitions are written according to the ABNF:
-
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
-
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
-
where:
<numericoid> is object identifier assigned to this object class;
+
+
+
+Zeilenga LDAP Models [Page 24]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
NAME <qdescrs> are short names (descriptors) identifying this object
class;
DESC <qdstring> is a short descriptive string;
<extensions> describe extensions.
-
4.1.2. Attribute Types
-
Attribute Type definitions are written according to the ABNF:
-
-
-
-
-Zeilenga LDAP Models [Page 24]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
-
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
-
where:
<numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this
ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
+
+
+
+Zeilenga LDAP Models [Page 25]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
SINGLE-VALUE indicates attributes of this type are restricted to a
single value;
COLLECTIVE indicates this attribute type is collective
USAGE indicates the application of this attribute type; and
<extensions> describe extensions.
-
Each attribute type description must contain at least one of the SUP
or SYNTAX fields. If no SYNTAX field is provided, the attribute type
description takes its value from the supertype.
-
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
fields, if not specified, take their value from the supertype.
-
-
-
-
-Zeilenga LDAP Models [Page 25]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
Usage of userApplications, the default, indicates that attributes of
this type represent user information. That is, they are user
attributes.
-
A usage of directoryOperation, distributedOperation, or dSAOperation
indicates that attributes of this type represent operational and/or
administrative information. That is, they are operational attributes.
-
directoryOperation usage indicates that the attribute of this type is
a directory operational attribute. distributedOperation usage
indicates that the attribute of this DSA-shared usage operational
attribute. dSAOperation usage indicates that the attribute of this
type is a DSA-specific operational attribute.
-
COLLECTIVE requires usage userApplications. Use of collective
attribute types in LDAP is discussed in [RFC3671].
-
NO-USER-MODIFICATION requires an operational usage.
-
Note that the <AttributeTypeDescription> does not list the matching
rules which can be used with that attribute type in an extensibleMatch
search filter [Protocol]. This is done using the 'matchingRuleUse'
attribute described in Section 4.1.4.
-
This document refines the schema description of X.501 by requiring
that the SYNTAX field in an <AttributeTypeDescription> be a string
representation of an object identifier for the LDAP string syntax
definition with an optional indication of the suggested minimum bound
of a value of this attribute.
-
A suggested minimum upper bound on the number of characters in a value
with a string-based syntax, or the number of bytes in a value for all
+
+
+
+Zeilenga LDAP Models [Page 26]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax's OBJECT IDENTIFIER in an
Attribute Type Description. This bound is not part of the syntax name
since UTF-8 [RFC3629] is a variable-length encoding.
-
4.1.3. Matching Rules
-
Matching rules are used in performance of attribute value assertions,
such as in performance of a Compare operation. They are also used in
evaluation of a Search filters, in determining which individual values
are be added or deleted during performance of a Modify operation, and
-
-
-
-
-Zeilenga LDAP Models [Page 26]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
used in comparison of distinguished names.
-
Each matching rule is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
-
Matching rule definitions are written according to the ABNF:
-
MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions
-
where:
<numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names (descriptors) identifying this
<extensions> describe extensions.
-
4.1.4. Matching Rule Uses
+ A matching rule use lists the attribute types which are suitable for
+ use with an extensibleMatch search filter.
- A matching rule use lists the attributes which are suitable for use
- with an extensibleMatch search filter.
+ Matching rule use descriptions are written according to the following
- Matching rule use descriptions are written according to the following
- ABNF:
+Zeilenga LDAP Models [Page 27]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ ABNF:
MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions
-
where:
<numericoid> is the object identifier of the matching rule
associated with this matching rule use description;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule use;
DESC <qdstring> is a short descriptive string;
-
-
-
-
-Zeilenga LDAP Models [Page 27]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule applies
to; and
<extensions> describe extensions.
-
4.1.5. LDAP Syntaxes
-
LDAP Syntaxes of (attribute and assertion) values are described in
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
known as the LDAP-specific encoding. Commonly, the LDAP-specific
encoding is constrained to a string of Unicode [Unicode] characters in
UTF-8 [RFC3629] form.
-
Each LDAP syntax is identified by an object identifier (OID).
-
LDAP syntax definitions are written according to the ABNF:
-
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions
-
where:
<numericoid> is the object identifier assigned to this LDAP syntax;
DESC <qdstring> is a short descriptive string; and
<extensions> describe extensions.
-
4.1.6. DIT Content Rules
-
A DIT content rule is a "rule governing the content of entries of a
- particular structural object class" [X.501].
+
+Zeilenga LDAP Models [Page 28]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ particular structural object class" [X.501].
+
For DIT entries of a particular structural object class, a DIT content
rule specifies which auxiliary object classes the entries are allowed
to belong to and which additional attributes (by type) are required,
allowed or not allowed to appear in the entries.
-
The list of precluded attributes cannot include any attribute listed
as mandatory in the rule, the structural object class, or any of the
allowed auxiliary object classes.
-
Each content rule is identified by the object identifier, as well as
any short names (descriptors), of the structural object class it
applies to.
-
An entry may only belong to auxiliary object classes listed in the
-
-
-
-
-Zeilenga LDAP Models [Page 28]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
governing content rule.
-
An entry must contain all attributes required by the object classes
the entry belongs to as well as all attributes required by the
governing content rule.
-
An entry may contain any non-precluded attributes allowed by the
object classes the entry belongs to as well as all attributes allowed
by the governing content rule.
-
An entry cannot include any attribute precluded by the governing
content rule.
-
An entry is governed by (if present and active in the subschema) the
DIT content rule which applies to the structural object class of the
entry (see Section 2.4.2). If no active rule is present for the
system schema). DIT content rules for superclasses of the structural
object class of an entry are not applicable to that entry.
-
DIT content rule descriptions are written according to the ABNF:
-
DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
- extensions WSP RPAREN ; extensions
+
+Zeilenga LDAP Models [Page 29]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ extensions WSP RPAREN ; extensions
+
where:
<numericoid> is the object identifier of the structural object class
associated with this DIT content rule;
<extensions> describe extensions.
-
-
-
-Zeilenga LDAP Models [Page 29]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
4.1.7. DIT Structure Rules and Name Forms
-
It is sometimes desirable to regulate where object and alias entries
can be placed in the DIT and how they can be named based upon their
structural object class.
-
4.1.7.1. DIT Structure Rules
-
A DIT structure rule is a "rule governing the structure of the DIT by
specifying a permitted superior to subordinate entry relationship. A
structure rule relates a name form, and therefore a structural object
DIT as subordinates to entries governed by the indicated superior
structure rules" [X.501].
-
DIT structure rule descriptions are written according to the ABNF:
-
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
-
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
+
+Zeilenga LDAP Models [Page 30]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
where:
<ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
SUP identifies superior rules (by rule id); and
<extensions> describe extensions.
-
If no superior rules are identified, the DIT structure rule applies
to an autonomous administrative point (e.g. the root vertex of the
subtree controlled by the subschema) [X.501].
-
-
-
-
-Zeilenga LDAP Models [Page 30]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
4.1.7.2. Name Forms
-
A name form "specifies a permissible RDN for entries of a particular
structural object class. A name form identifies a named object
class and one or more attribute types to be used for naming (i.e.
for the RDN). Name forms are primitive pieces of specification
used in the definition of DIT structure rules" [X.501].
-
Each name form indicates the structural object class to be named,
a set of required attribute types, and a set of allowed attribute
types. A particular attribute type cannot be in both sets.
-
Entries governed by the form must be named using a value from each
required attribute type and zero or more values from the allowed
attribute types.
-
Each name form is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
-
Name form descriptions are written according to the ABNF:
-
NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
-
where:
+
+
+
+Zeilenga LDAP Models [Page 31]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
<numericoid> is object identifier which identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name
form;
naming attributes for this name form; and
<extensions> describe extensions.
-
All attribute types in the required ("MUST") and allowed ("MAY") lists
shall be different.
-
4.2. Subschema Subentries
-
-
-
-
-Zeilenga LDAP Models [Page 31]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree.
-
Servers which follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
and so these are not ordinary object entries but subentries (see
Section 3.2). LDAP clients SHOULD NOT assume that servers implement
any of the other aspects of X.500 subschema.
-
Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501].
-
A server which masters entries and permits clients to modify these
entries SHALL implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in
and object classes which are permitted to be present. It is strongly
RECOMMENDED that all other servers implement this as well.
-
The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry.
-
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
NO-USER-MODIFICATION SINGLE-VALUE
USAGE directoryOperation )
-
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+Zeilenga LDAP Models [Page 32]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Subschema is held in (sub)entries belonging to the subschema auxiliary
object class.
-
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
-
The 'ldapSyntaxes' operational attribute may also be present in
subschema entries.
-
Servers MAY provide additional attributes (described in other
documents) in subschema (sub)entries.
-
Servers SHOULD provide the attributes 'createTimestamp' and
-
-
-
-
-Zeilenga LDAP Models [Page 32]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
'modifyTimestamp' in subschema (sub)entries, in order to allow clients
to maintain their caches of schema information.
-
The following subsections provide attribute type definitions for each
of schema definition attribute types.
-
4.2.1. 'objectClasses'
-
This attribute holds definitions of object classes.
-
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
defined in [Syntaxes].
-
4.2.2. 'attributeTypes'
-
This attribute holds definitions of attribute types.
-
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
defined in [Syntaxes].
-4.2.3. 'matchingRules'
+Zeilenga LDAP Models [Page 33]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
- This attribute holds definitions of matching rules.
+4.2.3. 'matchingRules'
+ This attribute holds definitions of matching rules.
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
defined in [Syntaxes].
-
-
-
-Zeilenga LDAP Models [Page 33]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
4.2.4 'matchingRuleUse'
-
This attribute holds definitions of matching rule uses.
-
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
defined in [Syntaxes].
-
4.2.5. 'ldapSyntaxes'
-
This attribute holds definitions of LDAP syntaxes.
-
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
in [Syntaxes].
-
4.2.6. 'dITContentRules'
-
This attribute lists DIT Content Rules which are present in the
subschema.
-
( 2.5.21.2 NAME 'dITContentRules'
+
+
+
+Zeilenga LDAP Models [Page 34]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
defined in [Syntaxes].
-
4.2.7. 'dITStructureRules'
-
This attribute lists DIT Structure Rules which are present in the
subschema.
-
-
-
-
-Zeilenga LDAP Models [Page 34]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
-
The 'integerFirstComponentMatch' matching rule and the
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
defined in [Syntaxes].
-
4.2.8 'nameForms'
-
This attribute lists Name Forms which are in force.
-
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
-
The 'objectIdentifierFirstComponentMatch' matching rule and the
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
in [Syntaxes].
-
4.3. 'extensibleObject' object class
-
The 'extensibleObject' auxiliary object class allows entries that
belong to it to hold any user attribute. The set of allowed attribute
types of this object class is implicitly the set of all attribute
types of userApplications usage.
-
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
+
+
+Zeilenga LDAP Models [Page 35]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The mandatory attributes of the other object classes of this entry are
still required to be present and any precluded attributes are still
not allowed to be present.
-
4.4. Subschema Discovery
-
To discover the DN of the subschema (sub)entry holding the subschema
controlling a particular entry, a client reads that entry's
'subschemaSubentry' operational attribute. To read schema attributes
from the subschema (sub)entry, clients MUST issue a Search operation
[Protocol] where baseObject is the DN of the subschema (sub)entry,
scope is baseObject, filter is "(objectClass=subschema)" [Filters],
-
-
-
-
-Zeilenga LDAP Models [Page 35]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
and attributes field lists the names of the desired schema attributes
(as they are operational). Note: the "(objectClass=subschema)" filter
allows LDAP servers which gateway to X.500 to detect that subentry
information is being requested.
-
Clients SHOULD NOT assume a published subschema is complete nor assume
the server supports all of the schema elements it publishes nor assume
the server does not support an unpublished element.
-
5. DSA (Server) Informational Model
-
The LDAP protocol assumes there are one or more servers which jointly
provide access to a Directory Information Tree (DIT). The server
holding the original information is called the "master" (for that
information). Servers which hold copies of the original information
are referred to as "shadowing" or "caching" servers.
-
As defined in [X.501]:
-
context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex.
-
and:
-
naming context: A subtree of entries held in a single master DSA.
-
That is, a naming context is the largest collection of entries,
starting at an entry that is mastered by a particular server, and
including all its subordinates and their subordinates, down to the
is the name of the initial entry.
+
+
+Zeilenga LDAP Models [Page 36]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
The root of the DIT is a DSA-specific Entry (DSE) and not part of any
naming context (or any subtree); each server has different attribute
values in the root DSE.
-
5.1. Server-specific Data Requirements
-
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as a
group of attributes located in the root DSE, which is named with the
DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
string).
-
These attributes are retrievable, subject to access control and other
-
-
-
-
-Zeilenga LDAP Models [Page 36]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
restrictions, if a client performs a Search operation [Protocol] with
an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
[Filters], and with the attributes field listing the names of the
operational, and like other operational attributes, are not returned
in search requests unless requested by name.
-
The root DSE SHALL NOT be included if the client performs a subtree
search starting from the root.
-
Servers may allow clients to modify attributes of the root DSE where
appropriate.
-
The following attributes of the root DSE are defined in [Syntaxes].
Additional attributes may be defined in other documents.
-
- altServer: alternative servers;
-
- namingContexts: naming contexts;
-
- supportedControl: recognized LDAP controls;
-
- supportedExtension: recognized LDAP extended operations;
+ - supportedFeatures: recognized LDAP features;
- supportedLDAPVersion: LDAP versions supported; and
-
- supportedSASLMechanisms: recognized Simple Authentication and
Security Layers (SASL) [SASL] mechanisms.
-
The values provided for these attributes may depend on
session-specific and other factors. For example, a server supporting
the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
+
+
+
+Zeilenga LDAP Models [Page 37]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
client's identity has been established by a lower level. See
[AuthMeth].
-
The root DSE may also include a 'subschemaSubentry' attribute. If so,
it refers to the subschema (sub)entry holding the schema controlling
the root DSE. Clients SHOULD NOT assume that this subschema
subschema discovery procedures are provided in Section 4.4.
-
5.1.1. 'altServer'
-
The 'altServer' attribute lists URIs referring to alternative servers
which may be contacted when this server becomes unavailable. URIs for
servers implementing the LDAP are written according to [LDAPURL].
Other kinds of URIs may be provided. If the server does not know of
-
-
-
-
-Zeilenga LDAP Models [Page 37]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
any other servers which could be used this attribute will be absent.
Clients may cache this information in case their preferred server
later becomes unavailable.
-
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
-
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
[Syntaxes].
-
5.1.2. 'namingContexts'
-
The 'namingContexts' attribute lists the context prefixes of the
naming contexts the server masters or shadows (in part or in whole).
If the server is a first-level DSA [X.501], it should list (in
attribute will have a single value, and that value will be the empty
string (indicating the root of the DIT).
-
This attribute may be used, for example, to select a suitable entry
name for subsequent operations with this server.
-
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
-
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
- defined in [Syntaxes].
-5.1.3. 'supportedControl'
+Zeilenga LDAP Models [Page 38]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ defined in [Syntaxes].
+5.1.3. 'supportedControl'
+
The 'supportedControl' attribute lists object identifiers identifying
the request controls [Protocol] the server supports. If the server
does not support any request controls, this attribute will be absent.
Object identifiers identifying response controls need not be listed.
-
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
-
-
-
-Zeilenga LDAP Models [Page 38]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
+ USAGE dSAOperation )
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
-
5.1.4. 'supportedExtension'
-
The 'supportedExtension' attribute lists object identifiers
identifying the extended operations [Protocol] which the server
supports. If the server does not support any extended operations,
this attribute will be absent.
-
An extended operation generally consists of an extended request and an
extended response but may also include other protocol data units (such
as intermediate responses). The object identifier assigned to the
object identifiers used in the extended operation need not be listed
as values of this attribute.
-
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
-
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
defined in [Syntaxes].
+5.1.5. 'supportedFeatures'
+
+
+
+
+Zeilenga LDAP Models [Page 39]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedFeatures' attribute lists object identifiers identifying
+ elective features which the server supports. If the server does not
+ support any discoverable elective features, this attribute will be
+ absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
-5.1.5. 'supportedLDAPVersion'
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [Syntaxes].
+5.1.6. 'supportedLDAPVersion'
+
The 'supportedLDAPVersion' attribute lists the versions of LDAP which
the server supports.
-
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
-
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
[Syntaxes].
-
-5.1.6. 'supportedSASLMechanisms'
-
+5.1.7. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[SASL] which the server recognizes and/or supports [AuthMeth]. The
contents of this attribute may depend on the current session state.
If the server does not support any SASL mechanisms this attribute will
-
-
-
-
-Zeilenga LDAP Models [Page 39]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
not be present.
-
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
-
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
in [Syntaxes].
-
6. Other Considerations
-6.1. Preservation of User Information
+Zeilenga LDAP Models [Page 40]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+6.1. Preservation of User Information
+
Syntaxes may be defined which have specific value and/or value form
(representation) preservation requirements. For example, a syntax
containing digitally signed data can mandate the server preserve both
the value and form of value presented to ensure signature is not
invalidated.
-
Where such requirements have not been explicitly stated, servers
SHOULD preserve the value of user information but MAY return the value
in a different form. And where a server is unable (or unwilling) to
an equivalent value (per Section 2.3) is returned.
-
6.2. Short Names
-
Short names, also known as descriptors, are used as more readable
aliases for object identifiers and are used to identify various schema
elements. However, it is not expected that LDAP implementations with
(stateOrProvinceName) might be displayed to a German-speaking user as
"Land".
-
The same short name might have different meaning in different
subschemas and, within a particular subschema, the same short name
might refer to different object identifiers each identifying a
different kind of schema element.
-
Implementations MUST be prepared that the same short name might be
used in a subschema to refer to the different kinds of schema
elements. That is, there might be an object class 'x-fubar' and an
attribute type 'x-fubar' in a subschema.
-
-
-
-Zeilenga LDAP Models [Page 40]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
Implementations MUST be prepared that the same short name might be
used in the different subschemas to refer to the different schema
elements. That is, there might be two matching rules 'x-fubar', each
in different subschemas.
-
Procedures for registering short names (descriptors) are detailed in
BCP 64 [BCP64bis].
-
6.3. Cache and Shadowing
+
+
+Zeilenga LDAP Models [Page 41]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Some servers may hold cache or shadow copies of entries, which can be
used to answer search and comparison queries, but will return
referrals or contact other servers if modification operations are
by the originating server.
-
7. Implementation Guidelines
-
7.1 Server Guidelines
-
Servers MUST recognize all names of attribute types and object classes
defined in this document but, unless stated otherwise, need not
support the associated functionality. Servers SHOULD recognize all
the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema].
-
Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints.
-
Servers MAY support DIT Content Rules. Servers MAY support DIT
Structure Rules and Name Forms.
-
Servers MAY support alias entries.
-
Servers MAY support the 'extensibleObject' object class.
-
Servers MAY support subentries. If so, they MUST do so in accordance
with [RFC3672]. Servers which do not support subentries SHOULD use
object entries to mimic subentries as detailed in Section 3.2.
-
Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema
(sub)entries.
-
-
-
-
-Zeilenga LDAP Models [Page 41]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
7.2 Client Guidelines
-
In the absence of prior agreements with servers, clients SHOULD NOT
assume that servers support any particular schema elements beyond
those referenced in Section 7.1. The client can retrieve subschema
information as described in Section 4.4.
-
Clients MUST NOT display nor attempt to decode as ASN.1, a value if
its syntax is not known. Clients MUST NOT assume the LDAP-specific
string encoding is restricted to a UTF-8 encoded string of Unicode
characters or any particular subset of Unicode (such as a printable
+
+
+
+Zeilenga LDAP Models [Page 42]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
subset) unless such restriction is explicitly stated. Clients SHOULD
NOT send attribute values in a request that are not valid according to
the syntax defined for the attributes.
-
8. Security Considerations
-
Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws
regarding the publication of information about people.
-
General security considerations for accessing directory information
with LDAP are discussed in [Protocol] and [AuthMeth].
-
9. IANA Considerations
-
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated in the following
template:
-
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Author/Change Controller: IESG
Comments:
-
The following descriptors (short names) should be added to
the registry.
-
NAME Type OID
------------------------ ---- -----------------
-
-
-
-
-Zeilenga LDAP Models [Page 42]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
-
The following descriptors (short names) should be updated to
refer to this RFC.
-
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
+
+
+
+Zeilenga LDAP Models [Page 43]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
-
10. Acknowledgments
-
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
-
This document is a product of the IETF LDAP Revision (LDAPBIS) Working
Group.
+11. Editor's Address
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
-
-Zeilenga LDAP Models [Page 43]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
-11. Editor's Address
+ Email: Kurt@OpenLDAP.org
- Kurt Zeilenga
- E-mail: <kurt@openldap.org>
+12. References
-12. References
+Zeilenga LDAP Models [Page 44]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
[[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
12.1. Normative References
-
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
-
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003.
-
[RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
December 2003.
-
[RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
3672, December 2003.
-
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
-
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
-
-
-
-
-Zeilenga LDAP Models [Page 44]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.
-
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
[SASL] Melnikov, A. (Editor), "Simple Authentication and
+
+
+
+Zeilenga LDAP Models [Page 45]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
-
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
-
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
-
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
12.2. Informative References
-
None.
-
Appendix A. Changes
-
This appendix is non-normative.
-
-
-
-Zeilenga LDAP Models [Page 45]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
This document amounts to nearly a complete rewrite of portions of RFC
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
overall clarity of technical specification. This appendix provides a
summary of substantive changes made to the portions of these documents
incorporated into this document. Readers should consult [Roadmap],
[Protocol], [Syntaxes], and [Schema] for summaries of remaining
- portions of these documents.
-A.1 Changes to RFC 2251
+Zeilenga LDAP Models [Page 46]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ portions of these documents.
+A.1 Changes to RFC 2251
+
This document incorporates from RFC 2251 sections 3.2 and 3.4,
portions of Section 4 and 6 as summarized below.
-
A.1.1 Section 3.2 of RFC 2251
-
Section 3.2 of RFC 2251 provided a brief introduction to the X.500
data model, as used by LDAP. The previous specification relied on
[X.501] but lacked clarity in how X.500 models are adapted for use by
LDAP. This document describes the X.500 data models, as used by LDAP
in greater detail, especially in areas where adaptation is needed.
-
Section 3.2.1 of RFC 2251 described an attribute as "a type with one
or more associated values." In LDAP, an attribute is better described
as an attribute description, a type with zero or more options, and one
or more associated values.
-
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
objectClasses and attributeTypes attributes, yet X.500(93) treats
these attributes as optional. While generally all implementations
attribute.
-
A.1.2 Section 3.4 of RFC 2251
-
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
This material, with changes, was incorporated in Section 5.1 of this
document.
-
Changes:
-
-
-
-
-Zeilenga LDAP Models [Page 46]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
- Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to access controls.
-
- Clarify that only recognized extended requests need to be enumerated
'supportedExtension'.
+
+
+Zeilenga LDAP Models [Page 47]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
- Clarify that only recognized request controls need to be enumerated
'supportedControl'.
-
- Clarify that root DSE attributes are operational and, like other
operational attributes, will not be returned in search requests
unless requested by name.
-
- Clarify that not all root DSE attributes are user modifiable.
-
- Remove inconsistent text regarding handling of the
'subschemaSubentry' attribute within the root DSE. The previous
specification stated that the 'subschemaSubentry' attribute held in
available (see Section 4.4 of this document).
-
A.1.2 Section 4 of RFC 2251
-
Portions of Section 4 of RFC 2251 detailing aspects of the information
model used by LDAP were incorporated in this document, including:
-
- Restriction of distinguished values to attributes whose descriptions
have no options (from Section 4.1.3);
-
- Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
Matching Rule Identifier (from 4.1.9); and
-
- User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
-
Clarifications to these portions include:
-
- Subtyping and AttributeDescriptions with options.
-Zeilenga LDAP Models [Page 47]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+A.1.3 Section 6 of RFC 2251
-A.1.3 Section 6 of RFC 2251
+
+Zeilenga LDAP Models [Page 48]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
where incorporated into this document.
-
A.2 Changes to RFC 2252
-
This document incorporates Sections 4, 5 and 7 from RFC 2252.
-
A.2.1 Section 4 of RFC 2252
-
The specification was updated to use Augmented BNF [RFC2234]. The
string representation of an OBJECT IDENTIFIER was tighten to
disallow leading zeros as described in RFC 2252 text.
-
The <descr> syntax was changed to disallow semicolon (U+003B)
characters to appear to be consistent its natural language
specification "descr is the syntactic representation of an object
specification of the semantics of attribute options appearing in
NAME fields.
-
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
over the <numericoid> form. However, <descr> form can be ambiguous.
To address this issue, the imperative was replaced with a statement
available. Additionally, an expanded discussion of descriptor
issues is discussed in Section 6.2 (Short Names).
-
The ABNF for a quoted string (qdstring) was updated to reflect
support for the escaping mechanism described in 4.3 of RFC 2252.
-
A.2.2 Section 5 of RFC 2252
-
Definitions of operational attributes provided in Section 5 of RFC
2252 where incorporated into this document.
-
The 'namingContexts' description was clarified. A first-level DSA
should publish, in addition to other values, "" indicating the root
of the DIT.
+ The 'altServer' description was clarified. It may hold any URI.
-Zeilenga LDAP Models [Page 48]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
-
-
-
- The 'altServer' description was clarified. It may hold any URI.
+Zeilenga LDAP Models [Page 49]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
The 'supportedExtension' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the extended
requests of the extended operations it recognizes.
-
The 'supportedControl' description was clarified. A server need
only list the OBJECT IDENTIFIERs associated with the request
controls it recognizes.
-
Descriptions for the 'structuralObjectClass' and
'governingStructureRule' operational attribute types were added.
-
A.2.3 Section 7 of RFC 2252
-
Section 7 of RFC 2252 provides definitions of the 'subschema' and
'extensibleObject' object classes. These definitions where
integrated into Section 4.2 and Section 4.3 of this document,
implementation requirement. This was incorporated into Section 7 of
this document.
-
The specification of 'extensibleObject' was clarified of how it
interacts with precluded attributes.
-
A.3 Changes to RFC 2256
-
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2256.
-
Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
attribute type. This was integrated into Section 2.4.1 of this
document. The statement "One of the values is either 'top' or
'alias'" was replaced with statement that one of the values is 'top'
as entries belonging to 'alias' also belong to 'top'.
-
Section 5.2 of RFC 2256 provided the definition of the
'aliasedObjectName' attribute type. This was integrated into
Section 2.6.2 of this document.
-
Section 7.1 of RFC 2256 provided the definition of the 'top' object
class. This was integrated into Section 2.4.1 of this document.
-
Section 7.2 of RFC 2256 provided the definition of the 'alias'
object class. This was integrated into Section 2.6.1 of this
document.
-Zeilenga LDAP Models [Page 49]
-INTERNET-DRAFT draft-ietf-ldapbis-models-12 24 October 2004
+Zeilenga LDAP Models [Page 50]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-Intellectual Property Rights
+A.4 Changes to RFC 3674
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+
+
+
+Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
-
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
-
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
-
Full Copyright
-
- Copyright (C) The Internet Society (2004). This document is subject
+ Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
-
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-
-
-
-
-
-
-
-Zeilenga LDAP Models [Page 50]
\ No newline at end of file
+Zeilenga LDAP Models [Page 51]
+\f
+
Internet-Draft Editor: J. Sermersheim
Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-30.txt Feb 2005
+Document: draft-ietf-ldapbis-protocol-31.txt May 2005
Obsoletes: RFCs 2251, 2830, 3771
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
+ which he or she becomes aware will be disclosed, in accordance with
+ Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- This Internet-Draft will expire in February 2005.
+ This Internet-Draft will expire in November 2005.
Technical discussion of this document will take place on the IETF
LDAP Revision Working Group (LDAPbis) mailing list <ietf-
Copyright Notice
- Copyright (C) The Internet Society 2004. All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Protocol (DAP).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 1
+Sermersheim Internet-Draft - Expires Nov 2005 Page 1
\f
Lightweight Directory Access Protocol Version 3
4.13. IntermediateResponse Message................................36
4.14. StartTLS Operation..........................................37
5. Protocol Encoding, Connection, and Transfer....................39
- 5.1. Protocol Encoding............................................40
+ 5.1. Protocol Encoding............................................39
5.2. Transmission Control Protocol (TCP)..........................40
5.3. Termination of the LDAP session..............................40
- 6. Security Considerations........................................41
+ 6. Security Considerations........................................40
7. Acknowledgements...............................................42
8. Normative References...........................................42
9. Informative References.........................................44
-Sermersheim Internet-Draft - Expires Aug 2005 Page 2
+Sermersheim Internet-Draft - Expires Nov 2005 Page 2
\f
Lightweight Directory Access Protocol Version 3
[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].
-
- Appendix C.1 summarizes substantive changes to the remaining
- sections.
+ This document, together with [Roadmap], [AuthMeth], and [Models],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
+ [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
+ this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
- This document obsoletes RFC 2830, Sections 2 and 4 in entirety. The
- remainder of RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2
- summarizes substantive changes to the remaining sections.
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
This document also obsoletes RFC 3771 in entirety.
[CharModel].
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 3
+Sermersheim Internet-Draft - Expires Nov 2005 Page 3
\f
Lightweight Directory Access Protocol Version 3
security services, as well as associations established by these
services.
- The term "LDAP message layer" refers to the LDAP Message (PDU)
- services used in providing directory services, as well as
- associations established by these services.
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
The term "LDAP session" refers to combined services (transport
connection, TLS layer, SASL layer, LDAP message layer) and their
-Sermersheim Internet-Draft - Expires Aug 2005 Page 4
+Sermersheim Internet-Draft - Expires Nov 2005 Page 4
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 5
+Sermersheim Internet-Draft - Expires Nov 2005 Page 5
\f
Lightweight Directory Access Protocol Version 3
common fields required in all protocol exchanges. At this time the
only common fields are the messageID and the controls.
- If the server receives a PDU from the client in which the LDAPMessage
- SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
- the tag of the protocolOp is not recognized as a request, or the
- encoding structures or lengths of data fields are found to be
+ If the server receives an LDAPMessage from the client in which the
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+ be parsed, the tag of the protocolOp is not recognized as a request,
+ or the encoding structures or lengths of data fields are found to be
incorrect, then the server SHOULD return the Notice of Disconnection
described in Section 4.4.1, with the resultCode set to protocolError,
and MUST immediately terminate the LDAP session as described in
Section 5.3.
- In other cases where the client or server cannot parse a PDU, it
- SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
further communication (including providing notice) would be
pernicious. Otherwise, server implementations MUST return an
appropriate response to the request, with the resultCode set to
-Sermersheim Internet-Draft - Expires Aug 2005 Page 6
+Sermersheim Internet-Draft - Expires Nov 2005 Page 6
\f
Lightweight Directory Access Protocol Version 3
LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [LDAPDN]
-Sermersheim Internet-Draft - Expires Aug 2005 Page 7
+Sermersheim Internet-Draft - Expires Nov 2005 Page 7
\f
Lightweight Directory Access Protocol Version 3
used to assert that the value in assertionValue matches a value of an
attribute.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 8
+Sermersheim Internet-Draft - Expires Nov 2005 Page 8
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 9
+Sermersheim Internet-Draft - Expires Nov 2005 Page 9
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 10
+Sermersheim Internet-Draft - Expires Nov 2005 Page 10
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 11
+Sermersheim Internet-Draft - Expires Nov 2005 Page 11
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 12
+Sermersheim Internet-Draft - Expires Nov 2005 Page 12
\f
Lightweight Directory Access Protocol Version 3
without applying the semantics of the control. Specifically, the
criticality field is applied as follows:
- - Regardless of the value of the criticality field, if the server
- recognizes the control type and it is appropriate for the
- operation, the server is to make use of the control when
- performing the operation.
-
- - 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 for operations that
- have a response message, MUST return with the resultCode set to
- unavailableCriticalExtension.
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, MUST return with the
+ resultCode set to unavailableCriticalExtension.
- - If the server does not recognize the control type or it is not
- appropriate for the operation, and the criticality field is FALSE,
- the server MUST ignore the control.
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is FALSE, the server MUST ignore the control.
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 13
+Sermersheim Internet-Draft - Expires Nov 2005 Page 13
\f
Lightweight Directory Access Protocol Version 3
specification most recently published. When a combination of controls
is encountered whose semantics are invalid, not specified (or not
known), the message is considered to be not well-formed, thus the
- operation fails with protocolError. Additionally, unless order-
- dependent semantics are given in a specification, the order of a
- combination of controls in the SEQUENCE is ignored. Where the order
- is to be ignored but cannot be ignored by the server, the message is
- considered not well-formed and the operation fails with
- protocolError.
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored by
+ the server, the message is considered not well-formed and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
This document does not specify any controls. Controls may be
specified in other documents. Documents detailing control extensions
4.2. Bind Operation
+
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 14
+\f
+ Lightweight Directory Access Protocol Version 3
+
The function of the Bind operation is to allow authentication
information to be exchanged between the client and server. The Bind
operation should be thought of as the "authenticate" operation.
Operational, authentication, and security-related semantics of this
operation are given in [AuthMeth].
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 14
-\f
- Lightweight Directory Access Protocol Version 3
-
The Bind request is defined as follows:
BindRequest ::= [APPLICATION 0] SEQUENCE {
character set and encoding) transferred to the server using the
simple AuthenticationChoice SHALL be transferred as [UTF-8]
encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
- passwords by applying the [SASLprep] profile of the [Stringprep]
- algorithm. Passwords consisting of other data (such as random
- octets) MUST NOT be altered. The determination of whether a
- password is textual is a local client matter.
-
+ passwords as "query" strings by applying the [SASLprep] profile of
+ the [Stringprep] algorithm. Passwords consisting of other data
+ (such as random octets) MUST NOT be altered. The determination of
+ whether a password is textual is a local client matter.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 15
+Sermersheim Internet-Draft - Expires Nov 2005 Page 15
\f
Lightweight Directory Access Protocol Version 3
+
4.2.1. Processing of the Bind Request
Before processing a BindRequest, all uncompleted operations MUST
operationsError to that request, it may then send a BindRequest. If
this also fails or the client chooses not to bind on the existing
LDAP session, it may terminate the LDAP session, re-establish it and
- begin again by first sending a PDU with a BindRequest. This will aid
- in interoperating with servers implementing other versions of LDAP.
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
Clients may send multiple Bind requests to change the authentication
and/or security associations or to complete a multi-stage Bind
status of the client's request for authentication.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 16
+Sermersheim Internet-Draft - Expires Nov 2005 Page 16
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 17
+Sermersheim Internet-Draft - Expires Nov 2005 Page 17
\f
Lightweight Directory Access Protocol Version 3
The Search request is defined as follows:
-Sermersheim Internet-Draft - Expires Aug 2005 Page 18
+Sermersheim Internet-Draft - Expires Nov 2005 Page 18
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 19
+Sermersheim Internet-Draft - Expires Nov 2005 Page 19
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 20
+Sermersheim Internet-Draft - Expires Nov 2005 Page 20
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 21
+Sermersheim Internet-Draft - Expires Nov 2005 Page 21
\f
Lightweight Directory Access Protocol Version 3
- The assertion value is invalid.
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 22
-\f
- Lightweight Directory Access Protocol Version 3
-
For example, if a server did not recognize the attribute type
- shoeSize, a filter of (shoeSize=*) would evaluate to FALSE, and the
- filters (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would each
- evaluate to Undefined.
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
+ (shoeSize<=12) would each evaluate to Undefined.
Servers MUST NOT return errors if attribute descriptions or matching
rule ids are not recognized, assertion values are invalid, or the
assertion syntax is not supported. More details of filter processing
are given in Clause 7.8 of [X.511].
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 22
+\f
+ Lightweight Directory Access Protocol Version 3
+
4.5.1.7.1 SearchRequest.filter.equalityMatch
- The matching rule for equalityMatch filter items is defined by the
- EQUALITY matching rule for the attribute type.
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
4.5.1.7.2 SearchRequest.filter.substrings
be the last element of 'substrings'.
The matching rule for an AssertionValue in a substrings filter item
- is defined by the SUBSTR matching rule for the attribute type. Note
- that the AssertionValue in a substrings filter item conforms to the
- assertion syntax of the EQUALITY matching rule for the attribute type
- rather than the assertion syntax of the SUBSTR matching rule for the
- attribute type. Conceptually, the entire SubstringFilter is converted
- into an assertion value of the substrings matching rule prior to
- applying the rule.
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than the assertion syntax of the SUBSTR matching rule for
+ the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
4.5.1.7.3 SearchRequest.filter.greaterOrEqual
- The matching rule for the greaterOrEqual filter item is defined by
- the ORDERING and EQUALITY matching rules for the attribute type.
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
4.5.1.7.4 SearchRequest.filter.lessOrEqual
- The matching rule for the lessOrEqual filter item is defined by the
- ORDERING matching rule for the attribute type.
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
+ returns TRUE as applied to the attribute or subtype and the asserted
+ value.
4.5.1.7.5 SearchRequest.filter.present
- The present match evaluates to TRUE where there is an attribute or
- subtype of the specified attribute description present in an entry,
- and FALSE otherwise (including a presence test with an unrecognized
- attribute description).
-
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 23
+Sermersheim Internet-Draft - Expires Nov 2005 Page 23
\f
Lightweight Directory Access Protocol Version 3
+
4.5.1.7.6 SearchRequest.filter.approxMatch
- An approxMatch filter item 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
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g. spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
approximate match. If approximate matching is not supported for the
attribute, this filter item should be treated as an equalityMatch.
support that matchingRule.
- If the type field is present and the matchingRule is present, the
- matchValue is compared against entry attributes of the specified
- type.
+ matchValue is compared against the specified attribute type and
+ its subtypes.
- If the dnAttributes field is set to TRUE, the match is
additionally applied against all the AttributeValueAssertions in
an entry's distinguished name, and evaluates to TRUE if there is
- at least one attribute in the distinguished name for which the
- filter item evaluates to TRUE. The dnAttributes field is present
- to alleviate the need for multiple versions of generic matching
- rules (such as word matching), where one applies to entries and
- another applies to entries and DN attributes as well.
+ at least one attribute or subtype in the distinguished name for
+ which the filter item evaluates to TRUE. The dnAttributes field is
+ present to alleviate the need for multiple versions of generic
+ matching rules (such as word matching), where one applies to
+ entries and another applies to entries and DN attributes as well.
The matchingRule used for evaluation determines the syntax for the
assertion value. Once the matchingRule and attribute(s) have been
- determined, the filter item evaluates to TRUE if it matches 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, the matchingRule is unsuitable for use with the specified
- type, or the assertionValue is invalid.
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
4.5.1.7 SearchRequest.attributes
A selection list of the attributes to be returned from each entry
- which matches the search filter. LDAPString values of this field are
- constrained to the following Augmented Backus-Naur Form ([ABNF]):
+ which matches the search filter. Attributes which are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ ([ABNF]):
attributeSelector = attributedescription / selectorspecial
-
- selectorspecial = noattrs / alluserattrs
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 24
+Sermersheim Internet-Draft - Expires Nov 2005 Page 24
\f
Lightweight Directory Access Protocol Version 3
+
+ selectorspecial = noattrs / alluserattrs
+
noattrs = %x31.2E.31 ; "1.1"
alluserattrs = %x2A ; asterisk ("*")
objectName LDAPDN,
attributes PartialAttributeList }
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 25
+Sermersheim Internet-Draft - Expires Nov 2005 Page 25
\f
Lightweight Directory Access Protocol Version 3
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
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
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
SearchResultEntry responses, the server returns a SearchResultDone
response, which contains an indication of success, or detailing any
errors that have occurred.
entry named in the baseObject).
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 26
+Sermersheim Internet-Draft - Expires Nov 2005 Page 26
\f
Lightweight Directory Access Protocol Version 3
SearchResultReference.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 27
+Sermersheim Internet-Draft - Expires Nov 2005 Page 27
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 28
+Sermersheim Internet-Draft - Expires Nov 2005 Page 28
\f
Lightweight Directory Access Protocol Version 3
semantics respectively:
-Sermersheim Internet-Draft - Expires Aug 2005 Page 29
+Sermersheim Internet-Draft - Expires Nov 2005 Page 29
\f
Lightweight Directory Access Protocol Version 3
entry MUST be identical.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 30
+Sermersheim Internet-Draft - Expires Nov 2005 Page 30
\f
Lightweight Directory Access Protocol Version 3
DelRequest ::= [APPLICATION 10] LDAPDN
-Sermersheim Internet-Draft - Expires Aug 2005 Page 31
+Sermersheim Internet-Draft - Expires Nov 2005 Page 31
\f
Lightweight Directory Access Protocol Version 3
defined as follows:
-Sermersheim Internet-Draft - Expires Aug 2005 Page 32
+Sermersheim Internet-Draft - Expires Nov 2005 Page 32
\f
Lightweight Directory Access Protocol Version 3
the requested comparison and return the result in the Compare
Response, defined as follows:
-Sermersheim Internet-Draft - Expires Aug 2005 Page 33
+Sermersheim Internet-Draft - Expires Nov 2005 Page 33
\f
Lightweight Directory Access Protocol Version 3
when the Abandon was requested, or are not able to be abandoned).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 34
+Sermersheim Internet-Draft - Expires Nov 2005 Page 34
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 35
+Sermersheim Internet-Draft - Expires Nov 2005 Page 35
\f
Lightweight Directory Access Protocol Version 3
- the format of the contents of the responseValue (if any), and
-Sermersheim Internet-Draft - Expires Aug 2005 Page 36
+Sermersheim Internet-Draft - Expires Nov 2005 Page 36
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 37
+Sermersheim Internet-Draft - Expires Nov 2005 Page 37
\f
Lightweight Directory Access Protocol Version 3
4.14.1. StartTLS Request
A client requests TLS establishment by transmitting a StartTLS
- request 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 always absent.
+ request message to the server. The StartTLS request is defined in
+ terms of an ExtendedRequest. The requestName is
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+ absent.
- The client MUST NOT send any PDUs at this LDAP message layer
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer
following this request until it receives a StartTLS Extended response
and, in the case of a successful response, completes TLS
negotiations.
4.14.2. StartTLS Response
When a StartTLS request is made, servers supporting the operation
- MUST return a StartTLS response PDU to the requestor. The
+ MUST return a StartTLS response message to the requestor. The
responseName, if present, is also "1.3.6.1.4.1.1466.20037". The
responseValue is absent.
LDAP message layer intact by sending and receiving a TLS closure
alert.
- The initiating protocol peer sends the TLS closure alert. If it
- wishes to leave the LDAP message layer intact, it then MUST cease to
- send further PDUs and MUST ignore any received LDAP PDUs until it
- receives a TLS closure alert from the other peer.
+ The initiating protocol peer sends the TLS closure alert and MUST
+ wait until it receives a TLS closure alert from the other peer before
+ sending further LDAP PDUs.
- Once the initiating protocol peer receives a TLS closure alert from
- the other peer it MAY send and receive LDAP PDUs.
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 38
+Sermersheim Internet-Draft - Expires Nov 2005 Page 38
\f
Lightweight Directory Access Protocol Version 3
-
When a protocol peer receives the initial TLS closure alert, it may
choose to allow the LDAP message layer to remain intact. In this
case, it MUST immediately transmit a TLS closure alert. Following
Protocol peers MAY terminate the LDAP session after sending or
receiving a TLS closure alert.
-
- After the TLS layer has been removed, the server MUST NOT send
- responses to any request message received before the TLS closure
- alert. Thus, clients wishing to receive responses to messages sent
- while the TLS layer is intact MUST wait for those message responses
- before sending the TLS closure alert.
5. Protocol Encoding, Connection, and Transfer
Transport | transport connection |
+----------------------+
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 39
-\f
- Lightweight Directory Access Protocol Version 3
-
5.1. Protocol Encoding
- OCTET STRING values are encoded in the primitive form only.
+
+
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 39
+\f
+ Lightweight Directory Access Protocol Version 3
+
- If the value of a BOOLEAN type is true, the encoding of the value
octet is set to hex "FF".
5.3. Termination of the LDAP session
Termination of the LDAP session is typically initiated by the client
- sending an UnbindRequst (Section 4.3), or by the server sending a
+ sending an UnbindRequest (Section 4.3), or by the server sending a
Notice of Disconnection (Section 4.4.1). In these cases each protocol
peer gracefully terminates the LDAP session by ceasing exchanges at
the LDAP message layer, tearing down any SASL layer, tearing down any
In either case, when the LDAP session is terminated, uncompleted
operations are handled as specified in Section 3.1.
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 40
-\f
- Lightweight Directory Access Protocol Version 3
-
6. Security Considerations
It is also permitted that the server can return its credentials to
the client, if it chooses to do so.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 40
+\f
+ Lightweight Directory Access Protocol Version 3
+
Use of cleartext password is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may
result in disclosure of the password to unauthorized parties.
in controls attached to Bind requests or responses. Thus information
contained in these fields SHOULD NOT be relied on unless otherwise
protected (such as by establishing protections at the transport
- layer).
-
- Server implementors should plan for the possibility of (protocol or
- external) events which alter the information used to establish
- security factors (e.g., credentials, authorization identities, access
- controls) during the course of the LDAP session, and even during the
- performance of a particular operation, and should take steps to avoid
- insecure side effects of these changes. The ways in which these
- issues are addressed are application and/or implementation specific.
+ layer).
+
+ Implementors should note that various security factors, including
+ authentication and authorization information and data security
+ services may change during the course of the LDAP session, or even
+ during the performance of a particular operation. For instance,
+ credentials could expire, authorization identities or access controls
+ could change, or the underlying security layer(s) could be replaced
+ or terminated. Implementations should be robust in the handling of
+ changing security factors.
+ In some cases, it may be appropriate to continue the operation even
+ in light of security factor changes. For instance, it may be
+ appropriate to continue an Abandon operation regardless of the
+ change, or to continue an operation when the change upgraded (or
+ maintained) the security factor. In other cases, it may be
+ appropriate to fail, or alter the processing of the operation. For
+ instance, if confidential protections were removed, it would be
+ appropriate to either fail a request to return sensitive data, or
+ minimally, to exclude the return of sensitive data.
Implementations which cache attributes and entries obtained via LDAP
MUST ensure that access controls are maintained if that information
to be aware of this, and possibly reject referrals when
confidentiality measures are not in place. Clients are advised to
reject referrals from the StartTLS operation.
+
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 41
+Sermersheim Internet-Draft - Expires Nov 2005 Page 41
\f
Lightweight Directory Access Protocol Version 3
-
The matchedDN and diagnosticMessage fields, as well as some
resultCode values (e.g., attributeOrValueExists and
entryAlreadyExists), could disclose the presence or absence of
8. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, (a work in progress).
[ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
"Information Technology - Abstract Syntax Notation One
-Sermersheim Internet-Draft - Expires Aug 2005 Page 42
+Sermersheim Internet-Draft - Expires Nov 2005 Page 42
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 43
+Sermersheim Internet-Draft - Expires Nov 2005 Page 43
\f
Lightweight Directory Access Protocol Version 3
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP result code registry to indicate that this document
provides the definitive technical specification for result codes 0-
- 36, 48-54, 64-70, 80-90.
+ 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
+ (strongAuthRequired) has been renamed (to strongerAuthRequired).
It is requested that the IANA update the LDAP Protocol Mechanism
registry to indicate that this document and [AuthMeth] provides the
definitive technical specification for the StartTLS
(1.3.6.1.4.1.1466.20037) Extended operation.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 44
+Sermersheim Internet-Draft - Expires Nov 2005 Page 44
\f
Lightweight Directory Access Protocol Version 3
+
It is requested that the IANA update the occurrence of "RFC XXXX" in
Appendix B with this RFC number at publication.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 45
+Sermersheim Internet-Draft - Expires Nov 2005 Page 45
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 46
+Sermersheim Internet-Draft - Expires Nov 2005 Page 46
\f
Lightweight Directory Access Protocol Version 3
Indicates a critical control is unrecognized (see Section
4.1.11).
-Sermersheim Internet-Draft - Expires Aug 2005 Page 47
+Sermersheim Internet-Draft - Expires Nov 2005 Page 47
\f
Lightweight Directory Access Protocol Version 3
type.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 48
+Sermersheim Internet-Draft - Expires Nov 2005 Page 48
\f
Lightweight Directory Access Protocol Version 3
or renamed) as the target entry already exists.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 49
+Sermersheim Internet-Draft - Expires Nov 2005 Page 49
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 50
+Sermersheim Internet-Draft - Expires Nov 2005 Page 50
\f
Lightweight Directory Access Protocol Version 3
This appendix is normative.
Lightweight-Directory-Access-Protocol-V3
- -- Copyright (C) The Internet Society (2004). This version of
+ -- Copyright (C) The Internet Society (2005). This version of
-- this ASN.1 module is part of RFC XXXX; see the RFC itself
-- for full legal notices.
DEFINITIONS
-Sermersheim Internet-Draft - Expires Aug 2005 Page 51
+Sermersheim Internet-Draft - Expires Nov 2005 Page 51
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 52
+Sermersheim Internet-Draft - Expires Nov 2005 Page 52
\f
Lightweight Directory Access Protocol Version 3
Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-Sermersheim Internet-Draft - Expires Aug 2005 Page 53
+Sermersheim Internet-Draft - Expires Nov 2005 Page 53
\f
Lightweight Directory Access Protocol Version 3
-- <attributeSelector> in Section 4.5.1.7
-Sermersheim Internet-Draft - Expires Aug 2005 Page 54
+Sermersheim Internet-Draft - Expires Nov 2005 Page 54
\f
Lightweight Directory Access Protocol Version 3
entry LDAPDN,
attributes AttributeList }
-Sermersheim Internet-Draft - Expires Aug 2005 Page 55
+Sermersheim Internet-Draft - Expires Nov 2005 Page 55
\f
Lightweight Directory Access Protocol Version 3
-Sermersheim Internet-Draft - Expires Aug 2005 Page 56
+Sermersheim Internet-Draft - Expires Nov 2005 Page 56
\f
Lightweight Directory Access Protocol Version 3
- Required that the messageID of requests MUST be non-zero as the
zero is reserved for Notice of Disconnection.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 57
+Sermersheim Internet-Draft - Expires Nov 2005 Page 57
\f
Lightweight Directory Access Protocol Version 3
- Specified how control values defined in terms of ASN.1 are to be
encoded.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 58
+Sermersheim Internet-Draft - Expires Nov 2005 Page 58
\f
Lightweight Directory Access Protocol Version 3
- Noted that the criticality field is only applied to request
messages (except UnbindRequest), and must be ignored when present
on response messages and UnbindRequest.
+ - Specified that non-critical controls may be ignored at the
+ server's discretion. There was confusion in the original wording
+ which led some to believe that recognized controls may not be
+ ignored as long as they were associated with a proper request.
- Added language regarding combinations of controls and the ordering
of controls on a message.
- Specified that when the semantics of the combination of controls
Bind in relationship to other operations.
-C.1.14 Section 4.2.3 (Bind Response)
-
- - Moved most error-related text to Appendix A, and added text
- regarding certain errors used in conjunction with the Bind
- operation.
+
-Sermersheim Internet-Draft - Expires Aug 2005 Page 59
+Sermersheim Internet-Draft - Expires Nov 2005 Page 59
\f
Lightweight Directory Access Protocol Version 3
+C.1.14 Section 4.2.3 (Bind Response)
+
+ - Moved most error-related text to Appendix A, and added text
+ regarding certain errors used in conjunction with the Bind
+ operation.
- Prohibited the server from specifying serverSaslCreds when not
appropriate.
instructed to ignore subsequent names when they are duplicated.
This was relaxed in order to allow different short names and also
OIDs to be requested for an attribute.
+ - The present search filter now evaluates to Undefined when the
+ specified attribute is not known to the server. It used to
+ evaluate to FALSE, which caused behavior inconsistent with what
+ most would expect, especially when the not operator was used.
- The Filter choice SubstringFilter substrings type is now defined
with a lower bound of 1.
- The SubstringFilter substrings 'initial, 'any', and 'final' types
knows they are ambiguous or may cause interoperability problems.
- Removed all mention of ExtendedResponse due to lack of
implementation.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 60
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.1.19 Section 4.5.3 (Continuation References in the Search Result)
- Made changes similar to those made to Section 4.1.11.
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 60
-\f
- Lightweight Directory Access Protocol Version 3
-
C.1.20 Section 4.5.3.1 (Example)
- Fixed examples to adhere to changes made to Section 4.5.3.
added for consistency with other operations and to help ensure
data consistency.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 61
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.1.25 Section 4.11 (Abandon Operation)
not use it if they need to know the outcome.
- Specified that Abandon and Unbind cannot be abandoned.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 61
-\f
- Lightweight Directory Access Protocol Version 3
-
C.1.26 Section 4.12 (Extended Operation)
C.1.28 Section 7 (Security Considerations)
- Reworded notes regarding SASL not protecting certain aspects of
- the LDAP Bind PDUs.
+ the LDAP Bind messages.
- Noted that Servers are encouraged to prevent directory
modifications by clients that have authenticated anonymously
[AuthMeth].
- - Added a note regarding the scenario where an identity is changed
- (deleted, privileges or credentials modified, etc.).
+ - Added a note regarding the possibility of changes to security
+ factors (authentication, authorization, data confidentiality).
- Warned against following referrals that may have been injected in
the data stream.
- Noted that servers should protect information equally, whether in
to other sections.
+
+Sermersheim Internet-Draft - Expires Nov 2005 Page 62
+\f
+ Lightweight Directory Access Protocol Version 3
+
C.2.1 Section 2.3 (Response other than "success")
- Removed wording indicating that referrals can be returned from
- Removed requirement that only a narrow set of result codes can be
returned. Some result codes are required in certain scenarios, but
any other may be returned if appropriate.
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 62
-\f
- Lightweight Directory Access Protocol Version 3
-
C.2.1 Section 4 (Closing a TLS Connection)
- - 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.
+ - Reworded most of this section to align with definitions of the
+ LDAP protocol layers.
- Removed instructions on abrupt closure as this is covered in other
areas of the document (specifically, Section 5.3)
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires Aug 2005 Page 63
+Sermersheim Internet-Draft - Expires Nov 2005 Page 63
\f
Lightweight Directory Access Protocol Version 3
Copyright Statement
- Copyright (C) The Internet Society (2004). This document is subject
+ Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
-Sermersheim Internet-Draft - Expires Aug 2005 Page 64
+Sermersheim Internet-Draft - Expires Nov 2005 Page 64
\f
\ No newline at end of file
+
+
+
+
+
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 24 October 2004
+Expires in six months 10 February 2005
Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
-
Lightweight Directory Access Protocol (LDAP):
Technical Specification Road Map
- <draft-ietf-ldapbis-roadmap-06.txt>
-
+ <draft-ietf-ldapbis-roadmap-07.txt>
Status of this Memo
-
This document is intended to be published as a Standard Track RFC.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Revision Working Group
mailing list <ietf-ldapbis@openldap.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
-
By submitting this Internet-Draft, I accept the provisions of Section
4 of RFC 3667. By submitting this Internet-Draft, I certify that any
applicable patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware will
be disclosed, in accordance with RFC 3668.
-
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
-
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
-
The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
+ http://www.ietf.org/1id-abstracts.html
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
-
-
-
Zeilenga LDAP: TS Road Map [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
Abstract
-
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services which act in
accordance with X.500 data and service models. This document provides
a roadmap of the LDAP Technical Specification.
-
Conventions
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
-
1. The LDAP Technical Specification
-
The technical specification detailing version 3 of the Lightweight
Directory Access Protocol (LDAP), an Internet Protocol, consists of
this document and the following documents:
-
LDAP: The Protocol [Protocol],
LDAP: Directory Information Models [Models],
LDAP: Authentication Methods and Connection Level Security
LDAP: Internationalized String Preparation [LDAPprep], and
LDAP: User Schema [Schema].
-
The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
the protocol specified by this technical specification. The LDAP
suite, as defined here, should be formally identified in other
documents by a normative reference to this document.
-
LDAP is an extensible protocol. Extensions to LDAP may be specified
in other documents. Nomenclature denoting such combinations of
LDAP-plus-extension(s) is not defined by this document but may be
defined in some future document(s). Extensions are expected to be
truly optional.
-
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
-
Zeilenga LDAP: TS Road Map [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
2. Relationship to X.500
-
This technical specification defines LDAP in terms of [X.500] as an
X.500 access mechanism. An LDAP server MUST act in accordance with
X.500(1993) series of International Telecommunication Union - Telecom
other directory system so long as the X.500 data and service models
[X.501][X.511] as used in LDAP is not violated in the LDAP interface.
-
This technical specification explicitly incorporates portions of
- X.500(93). Later revisions of X.500 do not automatically apply.
-
+ X.500(93). Later revisions of X.500 do not automatically apply to
+ this technical specification.
3. Security Considerations
-
LDAP security considerations are discussed in each document comprising
the technical specification.
-
4. Relationship to Obsolete Specifications
-
This technical specification, as defined in Section 1, obsoletes
entirely the previously defined LDAP technical specification [RFC3377]
(which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
3377 itself). The technical specification was significantly
reorganized.
-
This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
[LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
replaces RFC 2255.
-
[LDAPprep] is new to this revision of the LDAP technical
specification.
-
Each document of this specification contains appendices summarizing
changes to all sections of the specifications they replace. Appendix
A.1 of this document details changes made to RFC 3377. Appendix A.2
of this document details changes made to Section 3.3 of RFC 2251.
-
Additionally, portions of this technical specification update and/or
- replace a number of other documents not listed above. These
-
Zeilenga LDAP: TS Road Map [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+ replace a number of other documents not listed above. These
relationships are discussed in the documents detailings these portions
of this technical specification.
-
5. Acknowledgments
-
This document is based largely on RFC 3377 by J. Hodges and R.
Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
Kille, a product of the ASID Working Group.
-
This document is a product of the IETF LDAPBIS Working Group.
-
6. Author's Address
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
- Kurt Zeilenga
- E-mail: <kurt@openldap.org>
-
+ Email: Kurt@OpenLDAP.org
7. References
-
[[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
7.1. Normative References
-
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
-
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
-
-
Zeilenga LDAP: TS Road Map [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
[Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
Representation of Search Filters",
draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
in progress.
-
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
-
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
-
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
-
7.2. Informative References
-
None.
-
Appendix A. Changes to Previous Documents
-
This appendix outlines changes this document makes relative to the
documents it replaces (in whole or in part).
-Appendix A.1. Changes to RFC 3377
-
-
- This document is nearly a complete rewrite of RFC 3377 as much of the
- material of RFC 3377 is no longer applicable. The changes include
-
-
Zeilenga LDAP: TS Road Map [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+Appendix A.1. Changes to RFC 3377
+ This document is nearly a complete rewrite of RFC 3377 as much of the
+ material of RFC 3377 is no longer applicable. The changes include
redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
the technical specification.
-
Appendix A.2. Changes to Section 3.3 of RFC 2251
-
The section was modified slightly (the word "document" was replaced
with "technical specification") to clarify that it applies to the
entire LDAP technical specification.
-
Intellectual Property Rights
-
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
on the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
-
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
-
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
-
Full Copyright
-
- Copyright (C) The Internet Society (2004). This document is subject
+ Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-
-
Zeilenga LDAP: TS Road Map [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-06 24 October 2004
-
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Zeilenga LDAP: TS Road Map [Page 7]
+\f
-
-
-Zeilenga LDAP: TS Road Map [Page 7]
\ No newline at end of file
-INTERNET-DRAFT S. Legg, Editor
-draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies
-Intended Category: Standards Track K. Dally
-Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
- 27 October 2003
+INTERNET-DRAFT S. Legg
+draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
+Intended Category: Standards Track 23 June 2005
+Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
- LDAP: Syntaxes and Matching Rules
+ Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
+ By submitting this Internet-draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ By submitting this Internet-draft, I accept the provisions of Section
+ 3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
+ http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ http://www.ietf.org/shadow.html
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
- <steven.legg@adacel.com.au>.
-
- This Internet-Draft expires on 27 April 2004.
+ <steven.legg@eb2bcom.com>.
+ This Internet-Draft expires on 23 December 2005.
Abstract
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory, and whose values may be transfered in the LDAP
-
-Legg & Dally Expires 27 April 2004 [Page 1]
+Legg Expires 23 December 2005 [Page 1]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory, and whose values may be transfered in the LDAP
protocol, has a defined syntax which constrains the structure and
format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided
-
-
-Legg & Dally Expires 27 April 2004 [Page 2]
+Legg Expires 23 December 2005 [Page 2]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Table of Contents
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General Considerations . . . . . . . . . . . . . . . . . 6
- 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
3.3.1. Attribute Type Description . . . . . . . . . . . 7
- 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7
+ 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Country String . . . . . . . . . . . . . . . . . 8
3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
3.3.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.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
+ 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
- 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16
+ 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
3.3.19. Matching Rule Description. . . . . . . . . . . . 17
- 3.3.20. Matching Rule Use Description. . . . . . . . . . 17
+ 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
- 3.3.22. Name Form Description. . . . . . . . . . . . . . 18
+ 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
3.3.24. Object Class Description . . . . . . . . . . . . 19
- 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19
+ 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
- 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20
+ 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
3.3.29. Printable String . . . . . . . . . . . . . . . . 22
- 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
+ 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
- 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24
+ 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
- 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
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
+ 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
+ 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
+ 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
+ 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
-Legg & Dally Expires 27 April 2004 [Page 3]
+Legg Expires 23 December 2005 [Page 3]
\f
-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
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
+ 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
+ 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
+ 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
+ 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
+ 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
+ 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
+ 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
+ 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
+ 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
+ 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
+ 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
+ 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
+ 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
+ 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
+ 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
+ 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
+ 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
+ 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
+ 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
+ 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
+ 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
+ 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
+ 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
+ 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
+ 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
+ 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
+ Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
+ Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
+ Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
+ Informative References . . . . . . . . . . . . . . . . . . . . . . 52
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction
semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion
+
+
+
+Legg Expires 23 December 2005 [Page 4]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
value, which also has a defined syntax. This document defines a base
set of syntaxes and matching rules for use in defining attributes for
LDAP directories.
Information Models [MODELS] before reading the rest of this document.
Section 3 provides definitions for the base set of LDAP syntaxes.
Section 4 provides definitions for the base set of matching rules for
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 4]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
LDAP.
This document is a integral part of the LDAP technical specification
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
The remainder of RFC 2252 is obsoleted by this document. Sections 6
and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
- remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].
+ remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
+ Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
A number of schema elements which were included in the previous
revision of the LDAP technical specification are not included in this
specified in [LDAP-PKI]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic.
- The changes from RFC 2252 and RFC 2256 are described in Appendix B of
+ The changes with respect to RFC 2252 are described in Appendix B of
this document.
2. Conventions
3. Syntaxes
+
+
+
+Legg Expires 23 December 2005 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute
and assertion values transfered in the LDAP protocol.
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 5]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
discouraged since it will hinder interoperability. Client and server
implementations typically do not have the ability to dynamically
recognize new syntaxes.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow
+
+
+
+Legg Expires 23 December 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet since
UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
The following ABNF rules are used in a number of the syntax
definitions in Section 3.3.
-
-
-Legg & Dally Expires 27 April 2004 [Page 6]
-\f
-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
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
- The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
- <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
- [MODELS].
+ The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
+ <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
3.3. Syntax Definitions
A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this
syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
- For example, the following definition of the createTimestamp
- attribute type from [MODELS] is also a value of the Attribute Type
- Description syntax (note: line breaks have been added for readability
- - they are not part of the value when transfered in protocol).
-
- ( 2.5.18.1 NAME 'createTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
+
+ For example, the following definition of the createTimestamp
+ attribute type from [MODELS] is also a value of the Attribute Type
+ Description syntax (note: line breaks have been added for
+ readability - they are not part of the value when transfered in
+ protocol).
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
The LDAP definition for the Attribute Type Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
This syntax corresponds to the AttributeTypeDescription ASN.1 type
+
+
+
+Legg Expires 23 December 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
from [X.501].
3.3.2. Bit String
following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 7]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
binary-digit = "0" / "1"
The <SQUOTE> rule is defined in [MODELS].
The <PrintableCharacter> rule is defined in Section 3.2.
Examples:
- US
- AU
- The LDAP definition for the Country String syntax is:
- ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
- This syntax corresponds to the following ASN.1 type from [X.520]:
+Legg Expires 23 December 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ US
+ AU
+ The LDAP definition for the Country String syntax is:
-Legg & Dally Expires 27 April 2004 [Page 8]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+ This syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE (2)) -- ISO 3166 codes only
3.3.6. Directory String
+
+
+
+Legg Expires 23 December 2005 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
A value of the Directory String syntax is a string of one or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero length character string is not permitted. The LDAP-specific
The <UTF8> rule is defined in [MODELS].
-
-
-Legg & Dally Expires 27 April 2004 [Page 9]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
Example:
This is a value of Directory String containing #!%#@.
LDAP-specific encoding to the BER encoding used by X.500 must choose
an alternative that permits the particular characters in the string,
and must convert the characters from the UTF-8 encoding into the
- character encoding of the chosen alternative.
-
- When converting Directory String values from the BER encoding to the
- LDAP-specific encoding the characters must be converted from the
- character encoding of the chosen alternative into the UTF-8 encoding.
+ character encoding of the chosen alternative. When converting
+ Directory String values from the BER encoding to the LDAP-specific
+ encoding the characters must be converted from the character encoding
+ of the chosen alternative into the UTF-8 encoding. These conversions
+ SHOULD be done in a manner consistent with the Transcode step of the
+ string preparation algorithms [PREP] for LDAP.
3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition
+
+
+
+Legg Expires 23 December 2005 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
of a DIT (Directory Information Tree) content rule. The
LDAP-specific encoding of a value of this syntax is defined by the
<DITContentRuleDescription> rule in [MODELS].
( 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 April 2004 [Page 10]
-\f
-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:
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].
+ syntax is defined by the <distinguishedName> rule from the string
+ representation of distinguished names [LDAPDN].
Examples (from [LDAPDN]):
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
+
+
+
+Legg Expires 23 December 2005 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
[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 April 2004 [Page 11]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name
(see Section 3.3.6).
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
<DOLLAR> rules are defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 12]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
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 April 2004 [Page 12]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
"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.
A value of the Fax syntax is an image which is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
+
+
+
+Legg Expires 23 December 2005 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
memo. The LDAP-specific encoding of a value of this syntax is the
string of octets for a Group 3 Fax image as defined in [FAX].
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
}
of this syntax is a restriction of the format defined in [ISO8601],
and is described by the following ABNF:
+ GeneralizedTime = century year month day hour
+ [ minute [ second / leap-second ] ]
+ [ fraction ]
+ g-time-zone
+
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %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"
- / ( %x36 %x30 ) ; "60" (a leap second)
- GeneralizedTime = century year month day hour
- [ minute [ second ] ] [ fraction ]
- g-time-zone
+ second = ( %x30-35 %x30-39 ) ; "00" to "59"
+ leap-second = ( %x36 %x30 ) ; "60"
+
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The above ABNF allows character strings which do not represent valid
+ dates (in the Gregorian calendar) and/or valid times (e.g., February
+ 31, 1994). Such character strings SHOULD be considered invalid for
+ this syntax.
+
The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
otherwise the value represents a local time in the time zone
the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>.
+ If <minute> is omitted then <fraction> represents a fraction of an
+ hour, otherwise if <second> and <leap-second> are omitted then
+ <fraction> represents a fraction of a minute, otherwise <fraction>
+ represents a fraction of a second.
+
Examples:
199412161032Z
199412160532-0500
Both example values represent the same coordinated universal time:
-
-
-
-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:
The <object-class> and <criteria> rules are defined in Section
3.3.10. The <SHARP> rule is defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
3.3.16. Integer
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 15]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is
the optionally signed decimal digit character string representation
The LDAP definition for the JPEG syntax is:
+
+
+Legg Expires 23 December 2005 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
The JPEG syntax corresponds to the following ASN.1 type:
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 LDAP definition for the Matching Rule Description syntax is:
+
+
+
+Legg Expires 23 December 2005 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
This syntax corresponds to the MatchingRuleDescription ASN.1 type
( 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].
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+
+
+Legg Expires 23 December 2005 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Name and Optional UID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
( 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].
A value of the Object Class Description syntax is the definition of
an object class. The LDAP-specific encoding of a value of this
+
+
+
+Legg Expires 23 December 2005 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
syntax is defined by the <ObjectClassDescription> rule in [MODELS].
Example:
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
1.2.3.4
cn
+
+
+
+Legg Expires 23 December 2005 [Page 20]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the OID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
the mailbox resides, for example "MCIMail", and <mailbox> is the
actual mailbox in the mail system described by <mailbox-type>. The
<PrintableString> and <IA5String> rules are defined in Section 3.2.
-
-
-
-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:
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
+
+
+
+Legg Expires 23 December 2005 [Page 21]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
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 3.2. The <DOLLAR> and <UTFMB> rules are
- defined in [MODELS].
+ by the two hexadecimal digit code for the character. The <DOLLAR>
+ and <UTFMB> rules are defined in [MODELS].
Many servers limit the postal address to no more than six lines of no
more than thirty characters each.
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],
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+
+
+Legg Expires 23 December 2005 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
This syntax corresponds to the PrintableString ASN.1 type from
[ASN.1].
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
3.3.31. Telephone Number
+
+
+
+Legg Expires 23 December 2005 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for
representing international telephone numbers [E.123].
unconverted string of characters, which conforms to the
<PrintableString> rule in Section 3.2.
- Example: +1 512 315 0280
+ Examples:
+ +1 512 315 0280
+ +1-512-315-0280
+ +61 3 9896 7830
The LDAP definition for the Telephone Number syntax is:
PrintableString (SIZE(1..ub-telephone-number))
The value of ub-telephone-number (an integer) is implementation
+ defined. A non-normative definition appears in [X.520].
+3.3.32. Teletex Terminal Identifier
-
-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.
+ A value of this syntax specifies the identifier and (optionally)
+ parameters of a teletex terminal.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
- ttx-value = *ttx-value-char
+ ttx-value = *ttx-value-octet
- ttx-value-char = %x00-23
- / (%x5C "24") ; escaped "$"
- / %x25-5B
- / (%x5C "5C") ; escaped "\"
- / %x5D-FF
+ ttx-value-octet = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-FF
The <PrintableString> and <COLON> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 24]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Teletex Terminal Identifier syntax is:
( 1.3.6.1.4.1.1466.115.121.1.51
answerback = PrintableString
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:
rules are defined in Section 3.3.13. The <PLUS> rule is defined in
[MODELS].
+
+
+Legg Expires 23 December 2005 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The above ABNF allows character strings which do not represent valid
+ dates (in the Gregorian calendar) and/or valid times. Such character
+ strings SHOULD be considered invalid for this syntax.
+
The time value represents coordinated universal time if the "Z" form
of <u-time-zone> is used, otherwise the value represents a local
time. In the latter case, if <u-differential> is provided then
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
A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
conditions under which an AttributeValueAssertion or
- MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
- If an assertion is not Undefined then the result of the assertion is
- the result of applying the selected matching rule. A matching rule
- evaluates to TRUE, and in some cases Undefined, as specified in the
- description of the matching rule, otherwise it evaluates to FALSE.
+ MatchingRuleAssertion evaluates to Undefined are specified elsewhere
+ [PROT]. If an assertion is not Undefined then the result of the
+ assertion is the result of applying the selected matching rule. A
+ matching rule evaluates to TRUE, and in some cases Undefined, as
+ specified in the description of the matching rule, otherwise it
+ evaluates to FALSE.
Each assertion contains an assertion value. The definition of each
+
+
+
+Legg Expires 23 December 2005 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule
- may be applied. Note that 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
- substrings matching rule for the attribute type. The entire
- SubstringFilter is converted into an assertion value of the
+ may be applied. Note that an AssertionValue in a SubstringFilter
+ [PROT] conforms to the assertion syntax of the equality matching rule
+ for the attribute type rather than the assertion syntax of the
+ substrings matching rule for the attribute type. Conceptually, the
+ entire SubstringFilter is converted into an assertion value of the
substrings matching rule prior to applying the rule.
The definition of each matching rule indicates the attribute syntaxes
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 4.2.
+ Servers MAY implement the wordMatch and keywordMatch matching rules,
+ but SHOULD implement the other matching rules in Section 4.2.
Servers MAY implement additional matching rules.
Servers which implement the extensibleMatch filter SHOULD allow the
Servers MUST publish in the matchingRules attribute, the definitions
of matching rules referenced by values of the attributeTypes and
matchingRuleUse attributes in the same subschema entry. Other
+
+
+
+Legg Expires 23 December 2005 [Page 27]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
unreferenced matching rules MAY be published in the matchingRules
attribute.
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.
+ Nominated character strings in assertion and attribute values are
+ prepared according to the string preparation algorithms [PREP] for
+ LDAP when evaluating the following matching rules:
+
+ numericStringMatch,
+ numericStringSubstringsMatch,
+ caseExactMatch,
+ caseExactOrderingMatch,
+ caseExactSubstringsMatch,
+ caseExactIA5Match,
+ caseIgnoreIA5Match,
+ caseIgnoreIA5SubstringsMatch,
+ caseIgnoreListMatch,
+ caseIgnoreListSubstringsMatch,
+ caseIgnoreMatch,
+ caseIgnoreOrderingMatch,
+ caseIgnoreSubstringsMatch,
+ directoryStringFirstComponentMatch,
+ telephoneNumberMatch,
+ telephoneNumberSubstringsMatch and
+ wordMatch.
+
+ The Transcode, Normalize, Prohibit and Check bidi steps are the same
+ for each of the matching rules. However, the Map and Insignificant
+ Character Handling steps depends on the specific rule, as detailed in
+ the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch
syntax to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING.
+ If the corresponding ASN.1 type of the attribute syntax does not have
+ a named bit list [ASN.1] (which is the case for the Bit String
+ syntax) then the rule evaluates to TRUE if and only if the attribute
+ value has the same number of bits as the assertion value and the bits
+ match on a bitwise basis.
+
-Legg & Dally Expires 27 April 2004 [Page 27]
+Legg Expires 23 December 2005 [Page 28]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- 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 rule evaluates to TRUE if and only if the attribute value has the
- same number of bits as the assertion value and the bits match on a
- bitwise basis.
If the corresponding ASN.1 type does have a named bit list then
bitStringMatch operates as above except that trailing zero bits in
The bitStringMatch rule is an equality matching rule.
-4.2.2. caseExactIA5Match
+4.2.2. booleanMatch
+
+ The booleanMatch rule compares an assertion value of the Boolean
+ syntax to an attribute value of a syntax (e.g., the Boolean syntax)
+ whose corresponding ASN.1 type is BOOLEAN.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are both TRUE or both FALSE.
+
+ The LDAP definition for the booleanMatch rule is:
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The booleanMatch rule is an equality matching rule.
+
+4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5
String syntax to an attribute value of a syntax (e.g the IA5 String
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.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+
+Legg Expires 23 December 2005 [Page 29]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The caseExactIA5Match rule is an equality matching rule.
-4.2.3. caseIgnoreIA5Match
+4.2.4. caseExactMatch
- 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 caseExactMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String, Printable String, Country String or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of the
+ alternative string types of DirectoryString, e.g., PrintableString
+ (the other alternatives do not correspond to any syntax defined in
+ this document).
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactMatch rule is:
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactMatch rule is an equality matching rule.
+
+4.2.5. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g., the
+ Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+ The LDAP definition for the caseExactOrderingMatch rule is:
-Legg & Dally Expires 27 April 2004 [Page 28]
+
+Legg Expires 23 December 2005 [Page 30]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactOrderingMatch rule is an ordering matching rule.
+
+4.2.6. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
+ the Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are not case folded in the Map preparation
+ step, and only Insignificant Space Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the caseExactSubstringsMatch rule is:
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseExactSubstringsMatch rule is a substrings matching rule.
+
+4.2.7. caseIgnoreIA5Match
+ The caseIgnoreIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
string have the same number of characters and corresponding
characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
- Insignificant Space Removal is applied in the Insignificant Character
- Removal step.
+
+
+
+Legg Expires 23 December 2005 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreIA5Match rule is:
The caseIgnoreIA5Match rule is an equality matching rule.
-4.2.4. caseIgnoreIA5SubstringsMatch
+4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
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.
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
-4.2.5. caseIgnoreListMatch
+4.2.9. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
OF the DirectoryString ASN.1 type.
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of strings and corresponding
+ strings (by position) match according to the caseIgnoreMatch matching
+ rule.
-Legg & Dally Expires 27 April 2004 [Page 29]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+Legg Expires 23 December 2005 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- The rule evaluates to TRUE if and only if the attribute value and the
- assertion value have the same number of strings and corresponding
- strings (by position) match according to the caseIgnoreMatch matching
- rule.
In [X.520] the assertion syntax for this matching rule is defined to
be:
The caseIgnoreListMatch rule is an equality matching rule.
-4.2.6. caseIgnoreListSubstringsMatch
+4.2.10. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+4.2.11. caseIgnoreMatch
+ The caseIgnoreMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
-Legg & Dally Expires 27 April 2004 [Page 30]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-4.2.7. caseIgnoreMatch
+Legg Expires 23 December 2005 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
- The caseIgnoreMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
String, Printable String, Country String or Telephone Number syntax)
- whose corresponding ASN.1 type is DirectoryString or one of the
- alternative string types of DirectoryString, e.g., PrintableString
- (the other alternatives do not correspond to any syntax defined in
- this document).
+ whose corresponding ASN.1 type is DirectoryString or one of its
+ alternative string types.
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
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.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreMatch rule is:
The caseIgnoreMatch rule is an equality matching rule.
-4.2.8. caseIgnoreOrderingMatch
+4.2.12. caseIgnoreOrderingMatch
The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
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.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ The caseIgnoreOrderingMatch rule is an ordering matching rule.
+4.2.13. caseIgnoreSubstringsMatch
-Legg & Dally Expires 27 April 2004 [Page 31]
-\f
-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.
+Legg Expires 23 December 2005 [Page 34]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-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.,
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.
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
-4.2.10. distinguishedNameMatch
+4.2.14. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares an assertion
+ value of the Directory String syntax to an attribute value of a
+ syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+ first component of the DirectoryString ASN.1 type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ caseIgnoreMatch.
+
+ The LDAP definition for the directoryStringFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+Legg Expires 23 December 2005 [Page 35]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The directoryStringFirstComponentMatch rule is an equality matching
+ rule. When using directoryStringFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+4.2.15. distinguishedNameMatch
The distinguishedNameMatch rule compares an assertion value of the DN
syntax to an attribute value of a syntax (e.g., the DN syntax) whose
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 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 distinguishedNameMatch rule is an equality matching rule.
-4.2.11. generalizedTimeMatch
+4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the
Generalized Time syntax to an attribute value of a syntax (e.g the
then the number of minutes or seconds (respectively) is assumed to be
zero.
+
+
+Legg Expires 23 December 2005 [Page 36]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the generalizedTimeMatch rule is:
( 2.5.13.27 NAME 'generalizedTimeMatch'
The generalizedTimeMatch rule is an equality matching rule.
-4.2.12. generalizedTimeOrderingMatch
+4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of
an assertion value of the Generalized Time syntax to an attribute
The LDAP definition for the generalizedTimeOrderingMatch rule is:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 33]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 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.
-4.2.13. integerFirstComponentMatch
+4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of
the Integer syntax to an attribute value of a syntax (e.g the DIT
The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values
+
+
+
+Legg Expires 23 December 2005 [Page 37]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
(of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can be derived
from an attribute value by taking the first component of that
attribute value.
-4.2.14. integerMatch
+4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer
syntax to an attribute value of a syntax (e.g the Integer syntax)
The integerMatch rule is an equality matching rule.
+4.2.20. integerOrderingMatch
+
+ The integerOrderingMatch rule compares an assertion value of the
+ Integer syntax to an attribute value of a syntax (e.g the Integer
+ syntax) whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the integer value of the
+ attribute value is less than the integer value the assertion value.
+
+ The LDAP definition for the integerOrderingMatch matching rule is:
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerOrderingMatch rule is an ordering matching rule.
+
+4.2.21. keywordMatch
+
+ The keywordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ character string matches any keyword in the attribute value. The
+ identification of keywords in the attribute value and the exactness
+ of the match are both implementation specific.
+
-Legg & Dally Expires 27 April 2004 [Page 34]
+
+Legg Expires 23 December 2005 [Page 38]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+ The LDAP definition for the keywordMatch rule is:
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-4.2.15. numericStringMatch
+4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the
Numeric String syntax to an attribute value of a syntax (e.g the
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.
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
The LDAP definition for the numericStringMatch matching rule is:
The numericStringMatch rule is an equality matching rule.
-4.2.16. numericStringSubstringsMatch
+4.2.23. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares an assertion value of
+ the Numeric String syntax to an attribute value of a syntax (e.g the
+ Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The rule is identical to the caseIgnoreOrderingMatch rule except that
+ all space characters are skipped during comparison (case is
+
+
+
+Legg Expires 23 December 2005 [Page 39]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ irrelevant as characters are numeric).
+
+ The LDAP definition for the numericStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringOrderingMatch rule is an ordering matching rule.
+
+4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g
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.
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
The LDAP definition for the numericStringSubstringsMatch matching
rule is:
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+ The numericStringSubstringsMatch rule is a substrings matching rule.
-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.
-
-4.2.17. objectIdentifierFirstComponentMatch
+4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to an attribute value of a syntax (e.g the
Description, Matching Rule Description, Matching Rule Use
Description, Name Form Description or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+
+
+
+Legg Expires 23 December 2005 [Page 40]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
The LDAP definition for the objectIdentifierFirstComponentMatch
matching rule is:
- ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
+ ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The objectIdentifierFirstComponentMatch rule is an equality matching
value can be derived from an attribute value by taking the first
component of that attribute value.
-4.2.18. objectIdentifierMatch
+4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID
syntax to an attribute value of a syntax (e.g the OID syntax) whose
<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.
-4.2.19. octetStringMatch
+4.2.27. octetStringMatch
+
+
+
+
+Legg Expires 23 December 2005 [Page 41]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g the Octet String
The octetStringMatch rule is an equality matching rule.
-4.2.20. telephoneNumberMatch
+4.2.28. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares an assertion value of the
+ Octet String syntax to an attribute value of a syntax (e.g the Octet
+ String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
+ STRING ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value appears
+ earlier in the collation order than the assertion value. The rule
+ compares octet strings from the first octet to the last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+ strings contain different numbers of octets but the longer string is
+ identical to the shorter string up to the length of the shorter
+ string then the shorter string precedes the longer string.
+
+ The LDAP definition for the octetStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringOrderingMatch rule is an ordering matching rule.
+
+4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the
Telephone Number syntax to an attribute value of a syntax (e.g the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
+
+
+
+Legg Expires 23 December 2005 [Page 42]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
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.
+ telephoneNumber Insignificant Character Handling is applied in the
+ Insignificant Character Handling 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.
-4.2.21. telephoneNumberSubstringsMatch
+4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
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.
+ and only telephoneNumber Insignificant Character Handling is applied
+ in the Insignificant Character Handling step.
The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is:
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
-4.2.22. uniqueMemberMatch
+
+
+
+Legg Expires 23 December 2005 [Page 43]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the
The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according
- to the distinguishedNameMatch rule and the <BitString> component is
- 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
-
+ to the distinguishedNameMatch rule and either, the <BitString>
+ component is absent from both the attribute value and assertion
+ value, or the <BitString> component is present in both the attribute
+ value and the assertion value and the <BitString> component of the
+ assertion value matches the <BitString> component of the attribute
+ value according to the bitStringMatch rule.
+
+ Note that this matching rule has been altered from its description in
+ X.520 [X.520] in order to make the matching rule commutative. Server
+ implementors should consider using the original X.520 semantics
+ (where the matching was less exact) for approximate matching of
+ attributes with uniqueMemberMatch as the equality matching rule.
The LDAP definition for the uniqueMemberMatch matching rule is:
The uniqueMemberMatch rule is an equality matching rule.
+4.2.32. wordMatch
+
+ The wordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value word
+ matches, according to the semantics of caseIgnoreMatch, any word in
+ the attribute value. The precise definition of a word is
+ implementation specific.
+
+ The LDAP definition for the wordMatch rule is:
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this
+
+
+
+Legg Expires 23 December 2005 [Page 44]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other
encoding (e.g., BER) and back into the LDAP-specific encoding will
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
- Group.
+ This document is primarily a revision of RFC 2252 by M. Wahl, A.
+ Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
+ ASID Working Group.
This document is based upon input of the IETF LDAPBIS working group.
- The authors wish to thank J. Sermersheim and K. Zeilenga for their
- significant contribution to this revision.
+ The author would like to thank Kathy Dally for editing the early
+ drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
+ their significant contributions to this revision.
7. IANA Considerations
the 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
Person & email address to contact for further information:
- Steven Legg <steven.legg@adacel.com.au>
+ Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
+
+
+Legg Expires 23 December 2005 [Page 45]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The following descriptors (short names) should be updated to refer
to RFC XXXX.
NAME Type OID
------------------------------------------------------------------
bitStringMatch M 2.5.13.16
+ booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11
+ caseIgnoreListSubstringsMatch M 2.5.13.12
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4
+ directoryStringFirstComponentMatch M 2.5.13.31
distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
numericStringMatch M 2.5.13.8
+ numericStringOrderingMatch M 2.5.13.9
numericStringSubstringsMatch M 2.5.13.10
- objectIdentifierFirstComponentMatch M 2.5.13.31
+ objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17
+ octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
+ wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly
registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
- It should be changed to the following with a reference to RFC
- XXXX.
+ It should be changed to the following with a reference to
+ RFC XXXX.
NAME Type OID
------------------------------------------------------------------
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]
+Legg Expires 23 December 2005 [Page 46]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information:
- Steven Legg <steven.legg@adacel.com.au>
- Usage: other (M)
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): caseIgnoreListSubstringsMatch
- Object Identifier: 2.5.13.12
- Person & email address to contact for further information:
- Steven Legg <steven.legg@adacel.com.au>
+ Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
-8. References
-
-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.
-
- [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
- progress, June 2003.
-
- [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, June 2003.
-
- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
- protocol-xx.txt, a work in progress, September 2003.
-
- [E.123] Notation for national and international telephone numbers,
- ITU-T Recommendation E.123, 1988.
-
- [FAX] Standardization of Group 3 facsimile apparatus for
- document transmission - Terminal Equipment and Protocols
- for Telematic Services, ITU-T Recommendation T.4, 1993
-
-
-
-
-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
- Interchange, ITU-T Recommendation T.50, 1992
-
- [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
- Information Technology - Message Handling Systems (MHS):
- Interpersonal messaging system
-
- [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Models
-
- [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Selected attribute types
-
- [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
- Information technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation
-
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
-
- [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1: 1993 (with amendments).
-
- [JPEG] JPEG File Interchange Format (Version 1.02). Eric
- Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
- 1992.
-
- [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.
-
-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.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- 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 (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)
-
-9. Authors' Addresses
-
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
-
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- Email: steven.legg@adacel.com.au
-
-
- Kathy Dally
- The MITRE Corp.
- 7515 Colshire Dr., ms-W650
- McLean VA 22102
- USA
-
- Phone: +1 703 883 6058
- Fax: +1 703 883 7142
- Email: kdally@mitre.org
-
-
-
-
-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
The following list summarizes the object identifiers assigned to the
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
+
+
+Legg Expires 23 December 2005 [Page 47]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+Appendix B. Changes from RFC 2252
This annex lists the significant differences between this
- specification and RFC 2252 and Sections 6 and 8 of RFC 2256.
+ specification and RFC 2252.
This annex is provided for informational purposes only. It is not a
normative part of this specification.
1. The IESG Note has been removed.
2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
- and revised. Changes to the parts of these sections moved to
+ and revised. Changes to the parts of these sections moved to
[MODELS] are detailed in [MODELS].
3. BNF descriptions of syntax formats have been replaced by ABNF
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.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented.
+
+
+
+Legg Expires 23 December 2005 [Page 48]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
12. The Binary syntax has been removed because it was not adequately
specified, implementations with different incompatible
interpretations exist, and it was confused with the ;binary
Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and
- Certificate Pair from RFC 2252, and Supported Algorithm syntax
- from RFC 2256) have been removed. They are to be reintroduced in
- PKIX documents.
+ Certificate Pair) have been removed. They are reintroduced in
+ [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity.
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,
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
Mail Preference syntax have been removed on the grounds that they
- are out of scope for a core specification.
+ are out of scope for the core specification.
23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for
interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+
+
+
+Legg Expires 23 December 2005 [Page 49]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
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.
+ 26. The specification of the octetStringMatch matching rule from
+ RFC 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching
- rule from RFC 2798 & X.520 has been added to this document.
+ rule from RFC 2798 & X.520 has been added.
31. String preparation algorithms have been applied to the character
string matching rules.
+ 32. The specifications of the booleanMatch, caseExactMatch,
+ caseExactOrderingMatch, caseExactSubstringsMatch,
+ directoryStringFirstComponentMatch, integerOrderingMatch,
+ keywordMatch, numericStringOrderingMatch,
+ octetStringOrderingMatch and wordMatch matching rules from
+ RFC 3698 & X.520 have been added.
+
+Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+Legg Expires 23 December 2005 [Page 50]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, a work in progress, March 2005.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", draft-ietf-
+ ldapbis-roadmap-xx.txt, a work in progress, February 2005.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt, a work in progress, February
+ 2005.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
+ protocol-xx.txt, a work in progress, May 2005.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress, February 2005.
+
+ [PREP] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
+ progress, February 2005.
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988.
+
+ [FAX] Standardization of Group 3 facsimile apparatus for
+ document transmission - Terminal Equipment and Protocols
+ for Telematic Services, ITU-T Recommendation T.4, 1993
+
+ [T.50] International Reference Alphabet (IRA) (Formerly
+ International Alphabet No. 5 or IA5) Information
+ Technology - 7-Bit Coded Character Set for Information
+ Interchange, ITU-T Recommendation T.50, 1992
+
+ [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+ Information Technology - Message Handling Systems (MHS):
+ Interpersonal messaging system
+
+ [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected attribute types
+
+ [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+
+
+
+Legg Expires 23 December 2005 [Page 51]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times".
+
+ [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1: 1993 (with amendments).
+
+ [JPEG] JPEG File Interchange Format (Version 1.02). Eric
+ Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+ 1992.
+
+Informative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+ [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
+ April 2005.
+
+ [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates", draft-
+ zeilenga-ldap-x509-xx.txt, a work in progress, February
+ 2005.
+
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+
+
+
+Legg Expires 23 December 2005 [Page 52]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)
+
+Author's Address
+
+ Steven Legg
+ eB2Bcom
+ Suite3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg@eb2bcom.com
+
Full Copyright Statement
+ Copyright (C) The Internet Society (2005).
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Legg & Dally Expires 27 April 2004 [Page 47]
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+
+
+
+Legg Expires 23 December 2005 [Page 53]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
- 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 April 2004 [Page 48]
+Legg Expires 23 December 2005 [Page 54]
\f
+
+
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Pearl Crescent, LLC
Obsoletes: RFC 2255 Tim Howes
-Expires: 24 April 2005 Opsware, Inc.
+Expires: 4 July 2005 Opsware, Inc.
- 24 October 2004
+ 4 January 2005
LDAP: Uniform Resource Locator
- <draft-ietf-ldapbis-url-07.txt>
+ <draft-ietf-ldapbis-url-09.txt>
Smith & Howes Intended Category: Standards Track [Page 1]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
Abstract
- This document describes a format for an LDAP Uniform Resource Locator
- (URL). An LDAP URL describes an LDAP search operation that is used
- to retrieve information from an LDAP directory, or, in the context of
- an LDAPv3 referral or reference, an LDAP URL describes a service
- where an LDAP operation may be progressed.
+ This document describes a format for a Lightweight Directory Access
+ Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
+ describes an LDAP search operation that is used to retrieve
+ information from an LDAP directory, or, in the context of an LDAP
+ referral or reference, an LDAP URL describes a service where an LDAP
+ operation may be progressed.
Table of Contents
Table of Contents..............................................2
1. Introduction...................................................2
2. URL Definition.................................................3
-2.1. Escaping Using the % Method.................................5
+2.1. Percent-Encoding............................................5
3. Defaults for Fields of the LDAP URL............................5
4. Examples.......................................................6
5. Security Considerations........................................8
6. IANA Considerations............................................9
7. Normative References...........................................9
8. Informative References.........................................10
-9. Intellectual Property Rights...................................10
-10. Acknowledgements...............................................10
-11. Authors' Addresses.............................................11
-12. Appendix A: Changes Since RFC 2255.............................11
-12.1. Technical Changes...........................................11
-12.2. Editorial Changes...........................................12
-13. Appendix B: Changes Since Previous Document Revision...........13
-13.1. Editorial Changes...........................................14
-14. Intellectual Property Rights...................................14
-15. Full Copyright.................................................14
+9. Acknowledgements...............................................10
+10. Authors' Addresses.............................................11
+11. Appendix A: Changes Since RFC 2255.............................11
+11.1. Technical Changes...........................................11
+11.2. Editorial Changes...........................................12
+12. Appendix B: Changes Since Previous Document Revision...........14
+12.1. Technical Changes...........................................14
+12.2. Editorial Changes...........................................14
+ Intellectual Property Rights...................................14
+ Full Copyright.................................................15
1. Introduction
- LDAP is the Lightweight Directory Access Protocol, defined in
- [Protocol]. This document specifies the LDAP URL format for version
- 3 of LDAP and clarifies how LDAP URLs are resolved. This document
- also defines an extension mechanism for LDAP URLs, so that future
- documents can extend their functionality, for example, to provide
- access to new LDAPv3 extensions as they are defined. Note: not all
- of the parameters of the LDAP search operation described in
- [Protocol] can be expressed using the format defined in this
- document.
+ LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
+ document specifies the LDAP URL format for version 3 of LDAP and
+ clarifies how LDAP URLs are resolved. This document also defines an
+ extension mechanism for LDAP URLs. This mechanism may be used to
+ provide access to new LDAP extensions.
+
+ Note that not all of the parameters of the LDAP search operation
+ described in [Protocol] can be expressed using the format defined in
+ this document. Note also that URLs may be used to represent reference
+ knowledge, including for non-search operations.
- This document is an integral part of the LDAP Technical Specification
- [Roadmap].
Smith & Howes Intended Category: Standards Track [Page 2]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
This document replaces RFC 2255. See Appendix A for a list of changes
relative to RFC 2255.
the 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]]]]]
+ ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
+ [SLASH dn [QUESTION [attributes]
+ [QUESTION [scope] [QUESTION [filter]
+ [QUESTION extensions]]]]]
+ ; <host> and <port> are defined
+ ; in Sections 3.2.2 and 3.2.3
+ ; of [RFC2396bis].
+ ; <filter> is from Section 3 of
+ ; [Filters], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
scheme = "ldap"
- hostport = <hostport from Section 3.2.2 of [RFC2396]>
- ; As updated by [RFC2732] to allow
- ; IPv6 literal addresses
- dn = <distinguishedName from Section 3 of [LDAPDN]>
- ; See the "Escaping Using the % Method"
- ; section below.
+
+ dn = distinguishedName ; From Section 3 of [LDAPDN],
+ ; subject to the provisions of
+ ; the "Percent-Encoding"
+ ; section below.
+
attributes = attrdesc *(COMMA attrdesc)
- attrdesc = <AttributeDescription
- from Section 4.1.4 of [Protocol]>
- / ASTERISK
- ; See the "Escaping Using the % Method"
- ; section below.
+ attrdesc = selector *(COMMA selector)
+ selector = attributeSelector ; From Section 4.5.1 of
+ ; [Protocol], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
scope = "base" / "one" / "sub"
- 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]>
-
- EXCLAMATION = %x21 ; exclamation mark ("!")
- ASTERISK = %x2A ; asterisk ("*")
- SLASH = %x2F ; forward slash ("/")
- COLON = %x3A ; colon (":")
- QUESTION = %x3F ; question mark ("?")
-
Smith & Howes Intended Category: Standards Track [Page 3]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ extype = oid ; From section 1.4 of [Models].
+
+ exvalue = LDAPString ; From section 4.1.2 of
+ ; [Protocol], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
The "ldap" prefix indicates an entry or entries accessible from the
LDAP server running on the given hostname at the given portnumber.
- Note that the hostport may contain literal IPv6 addresses as
- specified in [RFC2732].
+ Note that the <host> may contain literal IPv6 addresses as specified
+ in Section 3.2.2 of [RFC2396bis].
- The dn is an LDAP Distinguished Name using the string format
+ The <dn> is an LDAP Distinguished Name using the string format
described in [LDAPDN]. It identifies the base object of the LDAP
search or the target of a non-search operation.
- The attributes construct is used to indicate which attributes should
- be returned from the entry or entries. Individual attrdesc names are
- as defined for AttributeDescription in [Protocol].
+ The <attributes> construct is used to indicate which attributes
+ should be returned from the entry or entries.
- The scope construct is used to specify the scope of the search to
+ 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
+ The <filter> is used to specify the search filter to apply to entries
within the specified scope during the search. It has the format
specified in [Filters].
- The extensions construct provides the LDAP URL with an extensibility
- mechanism, allowing the capabilities of the URL to be extended in the
- future. Extensions are a simple comma-separated list of type=value
- pairs, where the =value portion MAY be omitted for options not
- requiring it. Each type=value pair is a separate extension. These
- LDAP URL extensions are not necessarily related to any of the LDAPv3
- extension mechanisms. Extensions may be supported or unsupported by
- the client resolving the URL. An extension prefixed with a '!'
- character (ASCII 0x21) is critical. An extension not prefixed with a
- '!' character is non-critical.
+ The <extensions> construct provides the LDAP URL with an
+ extensibility mechanism, allowing the capabilities of the URL to be
+ extended in the future. Extensions are a simple comma-separated list
+ of type=value pairs, where the =value portion MAY be omitted for
+ options not requiring it. Each type=value pair is a separate
+ extension. These LDAP URL extensions are not necessarily related to
+ any of the LDAP extension mechanisms. Extensions may be supported or
+ unsupported by the client resolving the URL. An extension prefixed
+ with a '!' character (ASCII 0x21) is critical. An extension not
+ prefixed with a '!' character is non-critical.
If an LDAP URL extension is implemented (that is, if the
implementation understands it and is able to use it), the
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
implementation MUST make use of it. If an extension is not
implemented and is marked critical, the implementation MUST NOT
process the URL. If an extension is not implemented and it not
marked critical, the implementation MUST ignore the extension.
- The extension type (extype) MAY be specified using the 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.
+ The extension type (<extype>) MAY be specified using the numeric OID
+ <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+ (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
+ restricted to registered object identifier descriptive names. See
+ [LDAPIANA] for registration details and usage guidelines for
+ descriptive names.
No LDAP URL extensions are defined in this document. Other documents
or a future version of this document MAY define one or more
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
extensions.
-2.1. Escaping Using the % Method
+2.1. Percent-Encoding
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 [RFC3629] as input. An octet MUST be escaped using the %
- method described in section 2.4 of [RFC2396] in any of these
- situations:
+ characters included in one of the following three productions defined
+ in [RFC2396bis]:
+
+ <reserved>
+ <unreserved>
+ <pct-encoded>
+
+ Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+ input. An octet MUST be encoded using the percent-encoding mechanism
+ described in section 2.1 of [RFC2396bis] in any of these situations:
The octet is not in the reserved set defined in section 2.2 of
- [RFC2396] or in the unreserved set defined in section 2.3 of
- [RFC2396].
+ [RFC2396bis] or in the unreserved set defined in section 2.3 of
+ [RFC2396bis].
- It is the single Reserved character '?' and occurs inside a dn,
- filter, or other element of an LDAP URL.
+ It is the single Reserved character '?' and occurs inside a <dn>,
+ <filter>, or other element of an LDAP URL.
- It is a comma character ',' that occurs inside an extension value.
+ It is a comma character ',' that occurs inside an <exvalue>.
- Note that before the % method of escaping is applied, the extensions
- component of the LDAP URL may contain one or more null (zero) bytes.
- No other component may.
+ Note that before the percent-encoding mechanism is applied, the
+ extensions component of the LDAP URL may contain one or more null
+ (zero) bytes. No other component may.
3. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the
absence of any other specification, the following general defaults
- SHOULD be used when a field is absent. Note: other documents MAY
+ SHOULD be used when a field is absent. Note that other documents MAY
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
specify different defaulting rules; for example, section 4.1.10 of
[Protocol] specifies a different rule for determining the correct DN
to use when it is absent in an LDAP URL that is returned as a
referral.
- hostport
- The default LDAP port is TCP port 389. If no hostport is given,
- the client must have some apriori knowledge of an appropriate LDAP
- server to contact.
+ <host>
+ If no <host> is given, the client must have some apriori knowledge
+ of an appropriate LDAP server to contact.
- dn
- If no dn is given, the default is the zero-length DN, "".
+ <port>
+ The default LDAP port is TCP port 389.
- attributes
- If the attributes part is omitted, all user attributes of the
+ <dn>
+ If no <dn> is given, the default is the zero-length DN, "".
+
+ <attributes>
+ If the <attributes> part is omitted, all user attributes of the
entry or entries should be requested (e.g., by setting the
attributes field AttributeDescriptionList in the LDAP search
- request to a NULL list, or (in LDAPv3) by requesting the special
- attribute name "*").
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+ request to a NULL list, or by using the special <alluserattrs>
+ selector "*").
+ <scope>
+ If <scope> is omitted, a <scope> of "base" is assumed.
- scope
- If scope is omitted, a scope of "base" is assumed.
+ <filter>
+ If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
- filter
- If filter is omitted, a filter of "(objectClass=*)" is assumed.
-
- extensions
- If extensions is omitted, no extensions are assumed.
+ <extensions>
+ If <extensions> is omitted, no extensions are assumed.
4. Examples
Both of these URLs correspond to a base object search of the
"o=University of Michigan,c=US" entry using a filter of
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 6]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
"(objectclass=*)", requesting all attributes.
The next example is an LDAP URL referring to only the postalAddress
The next example is an LDAP URL referring to all children of the c=GB
entry:
-
-
-Smith & Howes Intended Category: Standards Track [Page 6]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
- ldap://ldap1.example.com/c=GB?objectClass?one
+ LDAP://ldap1.example.com/c=GB?objectClass?ONE
The objectClass attribute is requested to be returned along with the
entries, and the default filter of "(objectclass=*)" is used.
The next example is an LDAP URL to retrieve the mail attribute for
the LDAP entry named "o=Question?,c=US" is given below, illustrating
- the use of the escaping mechanism on the reserved character '?'.
+ the use of the percent-encoding mechanism on the reserved character
+ '?'.
ldap://ldap2.example.com/o=Question%3f,c=US?mail
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.
+ character must be escaped in a URL, the \'s are percent-encoded as
+ %5c (or %5C) in the URL encoding.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
The next example illustrates the interaction between the LDAP string
representation of DNs quoting mechanism and URL quoting mechanisms.
- ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
+ ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
The DN encoded in the above URL is:
- o=An Example\2c Inc.,c=US
+ o=An Example\2C Inc.,c=US
That is, the left-most RDN value is:
These three URLs all point to the root DSE on the ldap.example.net
server.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 7]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
The final two examples show use of a hypothetical, experimental bind
name extension (the value associated with the extension is an LDAP DN).
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
The two URLs are the same, except that the second one marks the
- e-bindname extension as critical. Notice the use of the % encoding
- method to encode the commas within the distinguished name value in
- the e-bindname extension.
+ e-bindname extension as critical. Notice the use of the
+ percent-encoding mechanism to encode the commas within the
+ distinguished name value in the e-bindname extension.
5. Security Considerations
- General URL security considerations discussed in [RFC2396] are
+ General URL security considerations discussed in [RFC2396bis] are
relevant for LDAP URLs.
The use of security mechanisms when processing LDAP URLs requires
particular care, since clients may encounter many different servers
via URLs, and since URLs are likely to be processed automatically,
without user intervention. A client SHOULD have a user-configurable
- policy about which servers to connect to using which security
- mechanisms, and SHOULD NOT make connections that are inconsistent
- 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
- policies are violated.
+ policy that controls which servers the client will establish LDAP
+ sessions with using which security mechanisms, and SHOULD NOT
+ establish LDAP sessions that are inconsistent with this policy. If a
+ client chooses to reuse an existing LDAP session when resolving one
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ or more LDAP URLs, it MUST ensure that the session is compatible with
+ the URL and that no security policies are violated.
Sending authentication information, no matter the mechanism, may
violate a user's privacy requirements. In the absence of specific
policy permitting authentication information to be sent to a server,
- a client should use an anonymous connection. (Note that clients
- conforming to previous LDAP URL specifications, where all connections
- are anonymous and unprotected, are consistent with this
+ a client should use an anonymous LDAP session. (Note that clients
+ conforming to previous LDAP URL specifications, where all LDAP
+ sessions are anonymous and unprotected, are consistent with this
specification; they simply have the default security policy.) Simply
- opening a connection to another server may violate some users'
- privacy requirements, so clients should provide the user with a way
- to control URL processing.
+ opening a transport connection to another server may violate some
+ users' privacy requirements, so clients should provide the user with
+ a way to control URL processing.
Some authentication methods, in particular reusable passwords sent to
the server, may reveal easily-abused information to the remote server
methods that do not reveal sensitive information is much preferred.
If the URL represents a referral for an update operation, strong
authentication methods SHOULD be used. Please refer to the Security
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
Considerations section of [AuthMeth] for more information.
The LDAP URL format allows the specification of an arbitrary LDAP
[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
- progress.
-[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ progress.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997.
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
-[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.
+[RFC2396bis]
+ Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
+ Resource Identifiers (URI): Generic Syntax",
+ draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
8. Informative References
- None.
-
-9. 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.
+[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
-10. Acknowledgements
+9. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
+
+
Smith & Howes Intended Category: Standards Track [Page 10]
\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-11. Authors' Addresses
+10. Authors' Addresses
Mark Smith, Editor
Pearl Crescent, LLC
+1 408 744-7509
howes@opsware.com
-12. Appendix A: Changes Since RFC 2255
+11. Appendix A: Changes Since RFC 2255
-12.1. Technical Changes
+11.1. Technical Changes
The following technical changes were made to the contents of the "URL
Definition" section:
Revised all of the ABNF to use common productions from [Models].
- Added note and references to [RFC2732] to allow literal IPv6
- addresses inside the hostport portion of the URL.
-
- Added missing ASTERISK as an alternative for the attrdesc part of the
- URL. It is believed that existing implementations of RFC 2255
+ Replaced references to [RFC2396] with a reference to [RFC2396bis]
+ (this allows literal IPv6 addresses to be used inside the <host>
+ portion of the URL, and a note was added to remind the reader of this
+ enhancement). Referencing [RFC2396bis] required changes to the ABNF
+ and text so that productions that are no longer defined by
+ [RFC2396bis] are not used. For example, <hostport> is not defined by
+ [RFC2396bis] so it has been replaced with host [COLON port]. Note:
+ [RFC2396bis] includes new definitions for the "Reserved" and
+ "Unreserved" sets of characters, and the net result is that the
+ following two additional characters should be percent-encoded when
+ they appear anywhere in the data used to construct an LDAP URL: "["
+ and "]" (these two characters were first added to the Reserved set by
+ RFC 2732).
+
+ Changed the definition of <attrdesc> to refer to <attributeSelector>
+ from [Protocol]. This allows use of "*" in the <attrdesc> part of
+ the URL. It is believed that existing implementations of RFC 2255
already support this.
- Added angle brackets around free-form prose in the "dn", "hostport",
- "attrdesc", "filter", and "exvalue" rules.
+ Avoided use of <prose-val> (bracketed-string) productions in the
+ <dn>, <host>, <attrdesc>, and <exvalue> rules.
- Changed the ABNF for ldapurl to group the dn component with the
- preceding slash.
-
- Changed the extype rule to be an LDAPOID from [Protocol] or an OID
- description from [LDAPIANA].
-
- Changed the text about extension types so it references [LDAPIANA].
- Reordered rules to more closely follow the order the elements appear
- in the URL.
+Smith & Howes Intended Category: Standards Track [Page 11]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+ Changed the ABNF for <ldapurl> to group the <dn> component with the
+ preceding <SLASH>.
-Smith & Howes Intended Category: Standards Track [Page 11]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+ Changed the <extype> rule to be an <oid> from [Models].
+ Changed the text about extension types so it references [LDAPIANA].
+ Reordered rules to more closely follow the order the elements appear
+ in the URL.
"Bindname Extension": removed due to lack of known implementations.
-12.2. Editorial Changes
+11.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
LDAP search operation described in [Protocol] can be expressed using
this format.
- "URL Definition" section: removed second copy of ldapurl grammar and
- following two paragraphs (editorial error in RFC 2255). Fixed line
- break within '!' sequence. Replaced "residing in the LDAP server"
- with "accessible from the LDAP server" in the sentence immediately
- following the ABNF. 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
- to the ABNF from RFC 2234. Clarified and strengthened the
- requirements with respect to processing of URLs that contain
- implements and not implemented extensions (the approach now closely
- matches that specified in [Protocol] for LDAP controls).
+ "URL Definition" section: removed second copy of <ldapurl> grammar
+ and following two paragraphs (editorial error in RFC 2255). Fixed
+ line break within '!' sequence. Reformatted the ABNF to improve
+ readability by aligning comments and adding some blank lines.
+ Replaced "residing in the LDAP server" with "accessible from the LDAP
+ server" in the sentence immediately following the ABNF. Removed the
+ sentence "Individual attrdesc names are as defined for
+ AttributeDescription in [Protocol]." because [Protocol]'s
+ <attributeSelector> is now used directly in the ABNF. Reworded last
+ paragraph to clarify which characters must be percent-encoded. Added
+ text to indicate that LDAP URLs are used for references and
+ referrals. Added text that refers to the ABNF from RFC 2234.
+ Clarified and strengthened the requirements with respect to
- "Defaults for Fields of the LDAP URL" section: added; formed by
- moving text about defaults out of the "URL Definition" section.
- "URL Processing" section: clarified that connections MAY be reused
- only if the open connection is compatible with the URL. Added text
- 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
- interrogate the server to determine the most appropriate method.
+Smith & Howes Intended Category: Standards Track [Page 12]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+ processing of URLs that contain implements and not implemented
+ extensions (the approach now closely matches that specified in
+ [Protocol] for LDAP controls).
-Smith & Howes Intended Category: Standards Track [Page 12]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+ "Defaults for Fields of the LDAP URL" section: added; formed by
+ moving text about defaults out of the "URL Definition" section.
+ Replaced direct reference to the attribute name "*" with a reference
+ to the special <alluserattrs> selector "*" defined in [Protocol].
+ "URL Processing" section: removed.
"Examples" section: Modified examples to use example.com and
example.net hostnames. Added missing '?' to the LDAP URL example
comma within a DN. Revised the bindname example to use e-bindname.
Changed the name of an attribute used in one example from "int" to
"four-octet" to avoid potential confusion. Added an example that
- demonstrates the interaction between DN escaping and URL escaping.
- Added some examples to show URL equivalence with respect to the dn
- portion of the URL.
+ demonstrates the interaction between DN escaping and URL
+ percent-encoding. Added some examples to show URL equivalence with
+ respect to the <dn> portion of the URL. Used uppercase in some
+ examples to remind the reader that some tokens are case-insensitive.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
updates. Added a reference to [AuthMeth]. Added note that simply
opening a connection may violate some users' privacy requirements.
+ Adopted the working group's revised LDAP terminology specification by
+ replacing the word "connection" with "LDAP session" or "LDAP
+ connection" as appropriate.
"Acknowledgements" section: added statement about this being an
update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added references to RFC 2234, RFC 2732, and RFC 3629.
- Updated all RFC 1738 references to point to the appropriate sections
- within RFC 2396. Updated the LDAP references to refer to LDAPBis WG
+ document. Added references to RFC 2234 and RFC 3629. Updated all
+ RFC 1738 references to point to the appropriate sections within
+ [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
documents. Removed the reference to the LDAP Attribute Syntaxes
document and added references to the [AuthMeth], [LDAPIANA], and
[Roadmap] documents.
- "Informative References" section: added for clarity.
+ "Informative References" section: added.
Header and "Authors' Addresses" sections: added "editor" next to Mark
Smith's name. Updated affiliation and contact information.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 13]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
Copyright: updated the year.
+ Throughout the document: surrounded the names of all ABNF productions
+ with "<" and ">" where they are used in descriptive text.
+
+
-13. Appendix B: Changes Since Previous Document Revision
+12. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-url-06.txt. Note that when appropriate
+ revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
these changes are also included in Appendix A, but are also included
here for the benefit of the people who have already reviewed
- draft-ietf-ldapbis-url-06.txt. This section will be removed before
+ draft-ietf-ldapbis-url-08.txt. This section will be removed before
this document is published as an RFC.
+12.1. Technical Changes
+ Throughout the document: Replaced references to [RFC2396] and
+ [RFC2732] with references to [RFC2396bis]. This required changes to
+ the ABNF and text so that productions that are no longer defined by
+ [RFC2396bis] are not used. For example, <hostport> is not defined by
+ [RFC2396bis] so it has been replaced with host [COLON port]. Note:
+ [RFC2396bis] includes new definitions for the "Reserved" and
+ "Unreserved" sets of characters, and the net result is that the
+ following two additional characters should be percent-encoded when
+ they appear anywhere in the data used to construct an LDAP URL: "["
+ and "]" (these two characters were first added to the Reserved set by
+ RFC 2732).
+12.2. Editorial Changes
+ Throughout the document: Replaced phrases like "Escaping using the %
+ method" with "Percent-encoding" to be consistent with the terminology
+ used in [RFC2396bis].
+ "URL Definition" section: For consistency, replaced all occurrences
+ of the phrase 'see the "Percent-Encoding" section below' with
+ 'subject to the provisions of the "Percent-Encoding" section below.'
+ Updated the copyright year to 2005.
-Smith & Howes Intended Category: Standards Track [Page 13]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
+Intellectual Property Rights
-13.1. Editorial Changes
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
- "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate
- paragraph with the version that says "each author" instead of "I."
- "URL Definition" section: replaced phrases such as "recognized by"
- with "implemented by" when referring to LDAP URL extensions.
- "URL Definition" section: added the following two sentences at the
- end of the subsection on "Escaping Using the % Method":
- Note that before the % method of escaping is applied, the
- extensions component of the LDAP URL may contain one or more null
- (zero) bytes. No other component may.
+Smith & Howes Intended Category: Standards Track [Page 14]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-14. Intellectual Property Rights
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
-15. Full Copyright
+Full Copyright
- Copyright (C) The Internet Society (2004). This document is subject
+ Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 14]
-\f
-INTERNET-DRAFT LDAP: Uniform Resource Locator 24 October 2004
-
-
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-This Internet Draft expires on 24 April 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+This Internet Draft expires on 4 July 2005.
--- /dev/null
+
+INTERNET-DRAFT Editor: A. Sciberras
+Intended Category: Standard Track eB2Bcom
+Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
+Obsoletes: RFC 2256
+
+
+ LDAP: Schema for User Applications
+ draft-ietf-ldapbis-user-schema-09.txt
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3978. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3979.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please send
+ editorial comments directly to the editor
+ <andrew.sciberras@eb2bcom.com>.
+
+ This Internet-Draft expires on 4 October 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+Sciberras Expires 4 October 2005 [Page 1]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+Abstract
+
+ This document is an integral part of the Lightweight Directory Access
+ Protocol (LDAP) technical specification [Roadmap]. It provides a
+ technical specification of attribute types and object classes
+ intended for use by LDAP directory clients for many directory
+ services, such as, White Pages. These objects are widely used as a
+ basis for the schema in many LDAP directories. This document does
+ not cover attributes used for the administration of directory
+ servers, nor does it include directory objects defined for specific
+ uses in other documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 2]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+Table of Contents
+
+ Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
+ Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
+ Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1 Relationship with other specifications . . . . . . . . . 5
+ 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
+
+ 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
+ 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
+ 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
+ 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
+ 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
+ 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
+ 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
+ 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
+ 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
+ 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
+ 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
+ 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
+ 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
+ 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
+ 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
+ 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
+ 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
+ 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
+ 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
+ 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
+ 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
+
+
+
+Sciberras Expires 4 October 2005 [Page 3]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ 2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
+ 2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19
+ 2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20
+ 2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21
+ 2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
+
+ 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
+ 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
+ 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
+ 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
+ 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
+ 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
+ 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
+ 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
+ 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
+ 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
+
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
+
+ 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
+
+ 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
+
+ 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 4]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+1. Introduction
+
+ This document provides an overview of attribute types and object
+ classes intended for use by Lightweight Directory Access Protocol
+ (LDAP) directory clients for many directory services, such as, White
+ Pages. Originally specified in the X.500 [X.500] documents, these
+ objects are widely used as a basis for the schema in many LDAP
+ directories. This document does not cover attributes used for the
+ administration of directory servers, nor does it include directory
+ objects defined for specific uses in other documents.
+
+1.1 Relationship with other specifications
+
+ This document is an integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety. In terms of RFC 2256,
+ Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections
+ 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The
+ remainder of RFC 2256 is obsoleted by this document. Section 2.4 of
+ this document supersedes the technical specification for the 'dc'
+ attribute type and 'dcObject' object class found in RFC 2247. The
+ remainder of RFC 2247 remains in force.
+
+ This document updates RFC 2798 by replacing the informative
+ description of the 'uid' attribute type, with the definitive
+ description provided in Section 2.39 of this document.
+
+ A number of schema elements which were included in the previous
+ revision of the LDAP Technical Specification are not included in this
+ revision of LDAP. PKI-related schema elements are now specified in
+ [LDAP-PKI]. Unless reintroduced in future technical specifications,
+ the remainder are to be considered Historic.
+
+ The descriptions in this document SHALL be considered definitive for
+ use in LDAP.
+
+1.2 Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3 General Issues
+
+ This document references Syntaxes defined in Section 3 of [Syntaxes]
+ and Matching Rules defined in Section 4 of [Syntaxes].
+
+ The definitions of Attribute Types and Object Classes are written
+
+
+
+Sciberras Expires 4 October 2005 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
+ AttributeTypeDescription and ObjectClassDescription given in
+ [Models]. Lines have been folded for readability. When such values
+ are transferred as attribute values in the LDAP Protocol the values
+ will not contain line breaks.
+
+2. Attribute Types
+
+ The Attribute Types contained in this section hold user information.
+
+ There is no requirement that servers implement the 'searchGuide' and
+ 'teletexTerminalIdentifier' attribute types. In fact, their use is
+ greatly discouraged.
+
+ An LDAP server implementation SHOULD recognize the rest of the
+ attribute types described in this section.
+
+2.1 'businessCategory'
+
+ The 'businessCategory' attribute type describes the kinds of business
+ performed by an organization. Each kind is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "banking", "transportation" and "real estate".
+
+2.2 'c'
+
+ The 'c' ('countryName' in X.500) attribute type contains a two-letter
+ ISO 3166 [ISO3166] country code.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+ [Syntaxes].
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ Examples: "DE", "AU" and "FR".
+
+2.3 'cn'
+
+ The 'cn' ('commonName' in X.500) attribute type contains names of an
+ object. Each name is one value of this multi-valued attribute. If
+ the object corresponds to a person, it is typically the person's full
+ name.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
+
+ Examples: "Martin K Smith", "Marty Smith" and "printer12".
+
+2.4 'dc'
+
+ The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
+ holding one component, a <label> [RFC1034], 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.
+ (Source: RFC 2247 [RFC2247])
+
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
+ [Syntaxes].
+
+ Examples: Valid values include "example" and "com". The value
+ "example.com" is invalid, because it contains two <label>
+ components.
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the label production [RFC1034]. It is the
+ application's 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> [RFC1034] production. The special
+ considerations discussed in section 4 of RFC 3490 [RFC3490] should be
+ taken, depending on whether the domain component is used for "stored"
+ or "query" purposes.
+
+
+
+Sciberras Expires 4 October 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.5 'description'
+
+ The 'description' attribute type contains human-readable descriptive
+ phrases about the object. Each description is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.13 NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "a color printer", "Maintenance is done every Monday, at
+ 1pm." and "distribution list for all technical staff".
+
+2.6 'destinationIndicator'
+
+ The 'destinationIndicator' attribute type contains country and city
+ strings, associated with the object (the addressee), needed to
+ provide the Public Telegram Service. The strings are composed in
+ accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
+ Each string is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "AASD" as a destination indicator for Sydney, Australia.
+ "GBLD" as a destination indicator for London, United
+ Kingdom.
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the F.1 and F.30 CCITT Recommendations. It is
+ the application's responsibility to ensure destination indicators
+ that it stores in this attribute are appropriately constructed.
+
+2.7 'distinguishedName'
+
+ The 'distinguishedName' attribute type is not used as the name of the
+ object itself, but it is instead a base type from which some user
+
+
+
+Sciberras Expires 4 October 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ attribute types with a DN syntax can inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.49 NAME 'distinguishedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
+
+2.8 'dnQualifier'
+
+ The 'dnQualifier' attribute type contains disambiguating information
+ strings to add to the relative distinguished name of an entry. The
+ information is intended for use when merging data from multiple
+ sources in order to prevent conflicts between entries which would
+ otherwise have the same name. Each string is one value of this
+ multi-valued attribute. It is recommended that a value of the
+ 'dnQualifier' attribute be the same for all entries from a particular
+ source.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.46 NAME 'dnQualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "20050322123345Z" - timestamps can be used to disambiguate
+ information.
+ "123456A" - serial numbers can be used to disambiguate
+ information.
+
+2.9 'enhancedSearchGuide'
+
+ The 'enhancedSearchGuide' attribute type contains sets of information
+ for use by directory clients in constructing search filters. Each
+ set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [Syntaxes].
+
+ Examples: "person#(sn$APPROX)#wholeSubtree"
+ "organizationalUnit#(ou$SUBSTR)#oneLevel"
+
+2.10 'facsimileTelephoneNumber'
+
+ The 'facsimileTelephoneNumber' attribute type contains telephone
+ numbers (and, optionally, the parameters) for facsimile terminals.
+ Each telephone number is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+ 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+ Number syntax [Syntaxes].
+
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution"
+
+2.11 'generationQualifier'
+
+ The 'generationQualifier' attribute type contains name strings that
+ are the part of a person's name which typically is the suffix. Each
+ string is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
+
+ Examples: "III", "3rd" and "Jr.".
+
+2.12 'givenName'
+
+ The 'givenName' attribute type contains name strings that are the
+ part of a person's name which is not their surname. Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
+
+ Examples: "Andrew", "Charles" and "Joanne"
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.13 'houseIdentifier'
+
+ The 'houseIdentifier' attribute type contains identifiers for a
+ building within a location. Each identifier is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "20" to represent a the house number 20.
+
+2.14 'initials'
+
+ The 'initials' attribute type contains strings of initials of some or
+ all of an individual's names, except the surname(s). Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.43 NAME 'initials'
+ SUP name )
+
+ Examples: "K. A." and "K".
+
+2.15 'internationalISDNNumber'
+
+ The 'internationalISDNNumber' attribute type contains Integrated
+ Services Digital Network (ISDN) addresses, as defined in the
+ International Telecommunication Union (ITU) Recommendation E.164
+ [E.164]. Each address is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.25 NAME 'internationalISDNNumber'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
+
+ Example: "0198 333 333"
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.16 'l'
+
+ The 'l' ('localityName' in X.500) attribute type contains names of a
+ locality or place, such as a city, county or other geographic region.
+ Each name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
+
+ Examples: "Geneva", "Paris" and "Edinburgh".
+
+2.17 'member'
+
+ The 'member' attribute type contains the Distinguished Names of
+ objects that are on a list or in a group. Each name is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.31 NAME 'member'
+ SUP distinguishedName )
+
+ Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
+ "cn=John Xerri,ou=Finance,o=Widget\, Inc" may
+ be two members of the financial team (group) at Widget,
+ Inc. In which case, both of these distinguished names would
+ be present as individual values of the member attribute.
+
+2.18 'name'
+
+ The 'name' attribute type is the attribute supertype from which user
+ attribute types with the name syntax inherit. Such attribute types
+ are typically used for naming. The attribute type is multi-valued.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.41 NAME 'name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+
+
+Sciberras Expires 4 October 2005 [Page 12]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.19 'o'
+
+ The 'o' ('organizationName' in X.500) attribute type contains the
+ names of an organization. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.10 NAME 'o'
+ SUP name )
+
+ Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
+
+2.20 'ou'
+
+ The 'ou' ('organizationalUnitName' in X.500) attribute type contains
+ the names of an organizational unit. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.11 NAME 'ou'
+ SUP name )
+
+ Examples: "Finance", "Human Resources" and "Research and
+ Development".
+
+2.21 'owner'
+
+ The 'owner' attribute type contains the Distinguished Names of
+ objects that have an ownership responsibility for the object that is
+ owned. Each owner's name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
+
+ Example: The mailing list object, whose DN is "cn=All Employees,
+ ou=Mailing List,o=Widget\, Inc.", is owned by the Human
+ Resources Director.
+ Therefore, the value of the owner attribute within the
+ mailing list object, would be the DN of the director (role):
+ "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
+
+2.22 'physicalDeliveryOfficeName'
+
+ The 'physicalDeliveryOfficeName' attribute type contains names that a
+ Postal Service uses to identify a post office.
+ (Source: X.520 [X.520])
+
+
+
+Sciberras Expires 4 October 2005 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
+
+2.23 'postalAddress'
+
+ The 'postalAddress' attribute type contains addresses used by a
+ Postal Service to perform services for the object. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
+
+ Example: "15 Main St.$Ottawa$Canada".
+
+2.24 'postalCode'
+
+ The 'postalCode' attribute type contains codes used by a Postal
+ Service to identify postal service zones. Each code is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "22180", to identify Vienna, VA in the USA.
+
+2.25 'postOfficeBox'
+
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
+
+
+
+Sciberras Expires 4 October 2005 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ at a box on premises of the Postal Service. Each postal box
+ identifier is a single value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.18 NAME 'postOfficeBox'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "Box 45".
+
+2.26 'preferredDeliveryMethod'
+
+ The 'preferredDeliveryMethod' attribute type contains an indication
+ of the preferred method of getting a message to the object.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+ [Syntaxes].
+
+ Example: If the mhs-delivery Delivery Method is preferred over
+ telephone-delivery, which is preferred over all other
+ methods, the value would be: "mhs $ telephone"
+
+2.27 'registeredAddress'
+
+ The 'registeredAddress' attribute type contains postal addresses
+ suitable for reception of telegrams or expedited documents, where it
+ is necessary to have the recipient accept delivery. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
+
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.28 'roleOccupant'
+
+ The 'roleOccupant' attribute type contains the Distinguished Names of
+ objects (normally people) that fulfill the responsibilities of a role
+ object. Each distinguished name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+ Example: The role object, "cn=Human Resources
+ Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
+ people whose object names are "cn=Mary
+ Smith,ou=employee,o=Widget\, Inc." and "cn=James
+ Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
+ attribute will contain both of these distinguished names,
+ since they are the occupants of this role.
+
+2.29 'searchGuide'
+
+ The 'searchGuide' attribute type contains sets of information for use
+ by clients in constructing search filters. It is superseded by
+ 'enhancedSearchGuide', described above in section 2.9. Each set is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+ 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
+
+ Example: "person#sn$EQ"
+
+2.30 'seeAlso'
+
+ The 'seeAlso' attribute type contains Distinguished Names of objects
+ that are related to the subject object. Each related object name is
+ one value of this multi-valued attribute.
+
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
+
+ Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
+ Inc." is related to the role objects, "cn=Football Team
+ Captain,ou=sponsored activities,o=Widget\, Inc." and
+
+
+
+Sciberras Expires 4 October 2005 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
+ Since the role objects are related to the person object, the
+ 'seeAlso' attribute will contain the distinguished name of
+ each role object as separate values.
+
+2.31 'serialNumber'
+
+ The 'serialNumber' attribute type contains the serial numbers of
+ devices. Each serial number is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.5 NAME 'serialNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "WI-3005" and "XF551426".
+
+2.32 'sn'
+
+ The 'sn' ('surname' in X.500) attribute type contains name strings
+ for the family names of a person. Each string is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
+
+ Example: "Smith"
+
+2.33 'st'
+
+ The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
+ full names of states or provinces. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+
+ Example: "California".
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.34 'street'
+
+ The 'street' ('streetAddress' in X.500) attribute type contains site
+ information from a postal address (i.e., the street name, place,
+ avenue, and the house number.). Each street is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "15 Main St."
+
+2.35 'telephoneNumber'
+
+ The 'telephoneNumber' attribute type contains telephone numbers that
+ comply with the ITU Recommendation E.123 [E.123]. Each number is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
+ [Syntaxes].
+
+ Example: "+1 234 567 8901".
+
+2.36 'teletexTerminalIdentifier'
+
+ The withdrawal of Rec. F.200 has resulted in the withdrawal of this
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+ 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
+ Identifier syntax [Syntaxes].
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.37 'telexNumber'
+
+ The 'telexNumber' attribute type contains sets of strings which are a
+ telex number, country code, and answerback code of a telex terminal.
+ Each set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+ 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
+ [Syntaxes].
+
+ Example: "12345$023$ABCDE"
+
+2.38 'title'
+
+ The 'title' attribute type contains the title of a person in their
+ organizational context. Each title is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.12 NAME 'title'
+ SUP name )
+
+
+ Examples: "Vice President", "Software Engineer" and "CEO".
+
+2.39 'uid'
+
+ The 'uid' ('userid' in RFC 1274) attribute type contains computer
+ system login names associated with the object. Each name is one
+ value of this multi-valued attribute.
+ (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
+
+ ( 0.9.2342.19200300.100.1.1 NAME 'uid'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "s9709015", "admin" and "Administrator".
+
+2.40 'uniqueMember'
+
+ The 'uniqueMember' attribute type contains the Distinguished Names of
+
+
+
+Sciberras Expires 4 October 2005 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ an object that is on a list or in a group, where the Relative
+ Distinguished Names of the object include a value that distinguishes
+ between objects when a distinguished name has been reused. Each
+ distinguished name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.50 NAME 'uniqueMember'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
+ syntax [Syntaxes].
+
+ Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
+ disbanded, establishing a new battalion with the "same" name
+ would have a unique identifier value added, resulting in
+ "ou=1st Battalion, o=Defense,c=US#'010101'B".
+
+2.41 'userPassword'
+
+ The 'userPassword' attribute contains octet strings that are known
+ only to the user and the system to which the user has access. Each
+ string is one value of this multi-valued attribute.
+
+ The application SHOULD prepare textual strings used as passwords by
+ transcoding them to Unicode, applying SASLprep [SASLprep], and
+ encoding as UTF-8. The determination of whether a password is
+ textual is a local client matter.
+ (Source: X.509 [X.509])
+
+ ( 2.5.4.35 NAME 'userPassword'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
+ [Syntaxes].
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords is strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+ An example of a need for multiple values in the 'userPassword'
+ attribute is an environment where every month the user was expected
+ to use a different password generated by some automated system.
+ During transitional periods, like the last and first day of the
+ periods, it may be necessary to allow two passwords for the two
+
+
+
+Sciberras Expires 4 October 2005 [Page 20]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ consecutive periods to be valid in the system.
+
+2.42 'x121Address'
+
+ The 'x121Address' attribute type contains data network addresses as
+ defined by ITU Recommendation X.121 [X.121]. Each address is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.24 NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
+
+ Example: "36111222333444555".
+
+2.43 'x500UniqueIdentifier'
+
+ The 'x500UniqueIdentifier' attribute type contains binary strings
+ that are used to distinguish between objects when a distinguished
+ name has been reused. Each string is one value of this multi-valued
+ attribute.
+ In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
+ This is a different attribute type from both the 'uid' and
+ 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
+ attribute type is defined in [RFC1274].
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
+ [Syntaxes].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 21]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+3. Object Classes
+
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the 'objectClass' attribute (see [Models]).
+
+3.1 'applicationProcess'
+
+ The 'applicationProcess' object class definition is the basis of an
+ entry which represents an application executing in a computer system.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.11 NAME 'applicationProcess'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $
+ ou $
+ l $
+ description ) )
+
+3.2 'country'
+
+ The 'country' object class definition is the basis of an entry which
+ represents a country.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
+
+3.3 'dcObject'
+
+ The 'dcObject' object class permits an entry to contains domain
+ component information. This object class is defined as auxiliary,
+ because it will be used in conjunction with an existing structural
+ object class.
+ (Source: RFC 2247 [RFC2247])
+
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ SUP top
+ AUXILIARY
+ MUST dc )
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+3.4 'device'
+
+ The 'device' object class is the basis of an entry which represents
+ an appliance, computer or network element.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
+
+3.5 'groupOfNames'
+
+ The 'groupOfNames' object class is the basis of an entry which
+ represents a set of named objects including information related to
+ the purpose or maintenance of the set.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.9 NAME 'groupOfNames'
+ SUP top
+ STRUCTURAL
+ MUST ( member $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.6 'groupOfUniqueNames'
+
+ The 'groupOfUniqueNames' object class is the same as the
+ 'groupOfNames' object class except that the object names are not
+ repeated or reassigned within a set scope.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
+
+
+
+Sciberras Expires 4 October 2005 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.7 'locality'
+
+ The 'locality' object class is the basis of an entry which represents
+ a place in the physical world.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.3 NAME 'locality'
+ SUP top
+ STRUCTURAL
+ MAY ( street $
+ seeAlso $
+ searchGuide $
+ st $
+ l $
+ description ) )
+
+3.8 'organization'
+
+ The 'organization' object class is the basis of an entry which
+ represents a structured group of people.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.4 NAME 'organization'
+ SUP top
+ STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $
+ businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ st $ l $ description ) )
+
+3.9 'organizationalPerson'
+
+ The 'organizationalPerson' object class is the basis of an entry
+ which represents a person in relation to an organization.
+ (Source: X.521 [X.521])
+
+
+
+Sciberras Expires 4 October 2005 [Page 24]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ ( 2.5.6.7 NAME 'organizationalPerson'
+ SUP person
+ STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ ou $ st $ l ) )
+
+3.10 'organizationalRole'
+
+ The 'organizationalRole' object class is the basis of an entry which
+ represents a job, function or position in an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.8 NAME 'organizationalRole'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $
+ description ) )
+
+3.11 'organizationalUnit'
+
+ The 'organizationalUnit' object class is the basis of an entry which
+ represents a piece of an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.5 NAME 'organizationalUnit'
+ SUP top
+ STRUCTURAL
+ MUST ou
+ MAY ( businessCategory $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $ l $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ searchGuide $ seeAlso $ st $ street $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ userPassword $ x121Address ) )
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+3.12 'person'
+
+ The 'person' object class is the basis of an entry which represents a
+ human being.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.6 NAME 'person'
+ SUP top
+ STRUCTURAL
+ MUST ( sn $
+ cn )
+ MAY ( userPassword $
+ telephoneNumber $
+ seeAlso $ description ) )
+
+3.13 'residentialPerson'
+
+ The 'residentialPerson' object class is the basis of an entry which
+ includes a person's residence in the representation of the person.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.10 NAME 'residentialPerson'
+ SUP person
+ STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+3.14 'uidObject'
+
+ The 'uidObject' object class permits an entry to contains user
+ identification information. This object class is defined as
+ auxiliary, because it will be used in conjunction with an existing
+ structural object class.
+ (Source: RFC 2377 [RFC2377])
+
+ ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ SUP top
+ AUXILIARY
+ MUST uid )
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+4. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Andrew Sciberras <andrew.sciberras@eb2bcom.com>
+ Usage: (A = attribute type, O = Object Class) see comment
+ Specification: RFC XXXX [editor's note: The RFC number will be
+ the one assigned to this document.]
+ Author/Change Controller: IESG
+
+
+ Comments
+ In the LDAP descriptors registry, the following descriptors (short
+ names) should be updated to refer to RFC XXXX [editor's note: This
+ document]. Names that need to be reserved, rather than assigned to
+ an Object Identifier, will contain an Object Identifier value of
+ RESERVED.
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ applicationProcess O 2.5.6.11
+ businessCategory A 2.5.4.15
+ c A 2.5.4.6
+ cn A 2.5.4.3
+ commonName A 2.5.4.3
+ country O 2.5.6.2
+ countryName A 2.5.4.6
+ DC A 0.9.2342.19200300.100.1.25
+ dcObject O 1.3.6.1.4.1.1466.344
+ description A 2.5.4.13
+ destinationIndicator A 2.5.4.27
+ device O 2.5.6.14
+ distinguishedName A 2.5.4.49
+ dnQualifier A 2.5.4.46
+ domainComponent A 0.9.2342.19200300.100.1.25
+ enhancedSearchGuide A 2.5.4.47
+ facsimileTelephoneNumber A 2.5.4.23
+ generationQualifier A 2.5.4.44
+ givenName A 2.5.4.42
+ GN A RESERVED
+ groupOfNames O 2.5.6.9
+ groupOfUniqueNames O 2.5.6.17
+
+
+
+Sciberras Expires 4 October 2005 [Page 27]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ houseIdentifier A 2.5.4.51
+ initials A 2.5.4.43
+ internationalISDNNumber A 2.5.4.25
+ L A 2.5.4.7
+ locality O 2.5.6.3
+ localityName A 2.5.4.7
+ member A 2.5.4.31
+ name A 2.5.4.41
+ o A 2.5.4.10
+ organization O 2.5.6.4
+ organizationName A 2.5.4.10
+ organizationalPerson O 2.5.6.7
+ organizationalRole O 2.5.6.8
+ organizationalUnit O 2.5.6.5
+ organizationalUnitName A 2.5.4.11
+ ou A 2.5.4.11
+ owner A 2.5.4.32
+ person O 2.5.6.6
+ physicalDeliveryOfficeName A 2.5.4.19
+ postalAddress A 2.5.4.16
+ postalCode A 2.5.4.17
+ postOfficeBox A 2.5.4.18
+ preferredDeliveryMethod A 2.5.4.28
+ registeredAddress A 2.5.4.26
+ residentialPerson O 2.5.6.10
+ roleOccupant A 2.5.4.33
+ searchGuide A 2.5.4.14
+ seeAlso A 2.5.4.34
+ serialNumber A 2.5.4.5
+ sn A 2.5.4.4
+ st A 2.5.4.8
+ street A 2.5.4.9
+ surname A 2.5.4.4
+ telephoneNumber A 2.5.4.20
+ teletexTerminalIdentifier A 2.5.4.22
+ telexNumber A 2.5.4.21
+ title A 2.5.4.12
+ uid A 0.9.2342.19200300.100.1.1
+ uidObject O 1.3.6.1.1.3.1
+ uniqueMember A 2.5.4.50
+ userId A 0.9.2342.19200300.100.1.1
+ userPassword A 2.5.4.35
+ x121Address A 2.5.4.24
+ x500UniqueIdentifier A 2.5.4.45
+
+5. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+
+
+
+Sciberras Expires 4 October 2005 [Page 28]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ Multiple attribute values for the 'userPassword' needs to be used
+ with care. Especially reset/deletion of a password by an admin
+ without knowing the old user password gets tricky or impossible if
+ multiple values for different applications are present.
+
+ Certainly, applications which intend to replace the 'userPassword'
+ value(s) with new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). Additionally, server
+ implementations are encouraged to provide administrative controls
+ which, if enabled, restrict the 'userPassword' 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.
+
+ This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
+ product of the IETF ASID Working Group.
+
+ The 'dc' attribute type definition and the 'dcObject' object class
+ definition in this document supersede the specification in RFC 2247
+ by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
+
+ The 'uid' attribute type definition in this document supersedes the
+ specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
+ and of the uid in RFC 2798 by M. Smith.
+
+ The 'uidObject' object class definition in this document supersedes
+ the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
+ Huber, S, Sataluri and M. Smith.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The author wishes to thank S. Legg and K. Zeilenga for their
+ significant contribution to this update. The author would also like
+ to thank Kathy Dally who edited early drafts of this document.
+
+
+
+Sciberras Expires 4 October 2005 [Page 29]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+7. References
+
+7.1 Normative
+
+ [E.123] Notation for national and international telephone
+ numbers, ITU-T Recommendation E.123, 1988
+
+ [E.164] The international public telecommunication numbering
+ plan, ITU-T Recommendation E.164, 1997
+
+ [F.1] Operational Provisions For The International Public
+ Telegram Service Transmission System, CCITT
+ Recommendation F.1, 1992
+
+ [F.31] Telegram Retransmission System, CCITT Recommendation
+ F.31, 1988
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
+ models-xx (a work in progress)
+
+ [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, January 1987
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997
+
+ [RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997
+
+ [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)
+
+ [SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
+ names and passwords", draft-ietf-sasl-saslprep-xx (a
+ work in progress)
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx (a work in progress)
+
+ [X.121] International numbering plan for public data networks,
+
+
+
+Sciberras Expires 4 October 2005 [Page 30]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ ITU-T Recommendation X.121, 1996
+
+ [X.509] The Directory: Authentication Framework, ITU-T
+ Recommendation X.509, 1993
+
+ [X.520] The Directory: Selected Attribute Types, ITU-T
+ Recommendation X.520, 1993
+
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
+
+7.2 Informative
+
+ [AuthMeth] Harrison R., "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms", draft-ietf-
+ ldapbis-authmeth-xx (a work in progress)
+
+ [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates",
+ draft-zeilenga-ldap-x509-xx (a work in progress)
+
+ [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
+ Sataluri, S., "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998
+
+ [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
+ "Naming Plan for Internet-Enabled Applications", RFC
+ 2377, September 1998.
+
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000
+
+ [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
+
+8. Author's Address
+
+ Andrew Sciberras
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre,
+ 935 Station Street,
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7833
+ Email: andrew.sciberras@eb2bcom.com
+
+
+
+Sciberras Expires 4 October 2005 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+9. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+10. Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Copyright Statement Copyright (C) The Internet Society (2005). This
+ document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ Appendix A Changes Made Since RFC 2256
+
+ This appendix lists the changes that have been made from RFC 2256 to
+ this I-D.
+
+ This appendix is not a normative part of this specification, which
+ has been provided for informational purposes only.
+
+ 1. Replaced the document title.
+
+ 2. Removed the IESG Note.
+
+ 3. Dependencies on RFC 1274 have been eliminated.
+
+ 4. Added a Security Considerations section and an IANA
+ considerations section.
+
+ 5. Deleted the conformance requirement for subschema object
+ classes in favor of a statement in [Syntaxes].
+
+ 6. Added explanation to attribute types and to each object class.
+
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ (moved to [Syntaxes]).
+
+ 8. Removed the certificate-related attribute types:
+ authorityRevocationList, cACertificate,
+ certificateRevocationList, crossCertificatePair,
+ deltaRevocationList, supportedAlgorithms, and userCertificate.
+
+ Removed the certificate-related Object Classes:
+ certificationAuthority, certificationAuthority-V2,
+ cRLDistributionPoint, strongAuthenticationUser, and
+ userSecurityInformation
+
+ LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
+
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
+
+ 10. Deleted the aliasedObjectName and objectClass attribute type
+ definitions. Deleted the alias and top object class
+ definitions. They are included in [Models].
+
+ 11. Added the 'dc' attribute type from RFC 2247.
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ 12. Numerous edititorial changes.
+
+ 13. Removed upper bound after the SYNTAX oid in all attribute
+ definitions where it appeared.
+
+ 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
+
+ changes since 07:
+
+ 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
+ postalAddress, and registeredAddress attribute types.
+
+ 16. Clarified and corrected examples in owner and roleOccupant
+ attribute types.
+
+ 17. Added RFC 2234 to normative references.
+
+ 18. Added RFC 1274 and RFC 2798 to informative references.
+
+ 19. Removed the statement about RFC 2026 conformance.
+
+ 20. Added the IPR Disclosure and Notice
+
+ 21. Updated the Copyright text.
+
+ changes since 08:
+
+ 22. Included RFC 2377 into Updates header and Informative
+ References
+
+ 23. Changed Editor information to Andrew Sciberras.
+
+ 24. Updated I-D Template information.
+
+ 25. References made consistent with other LDAPbis ID's. [ROADMAP]
+ -> [RoadMap] and [AUTHMETH] -> [AuthMeth].
+
+ 26. Changed Introduction to include an (LDAP) acronym after the
+ first usage.
+
+ 27. Renamed section 1.1 to "Relationship with other
+ specifications" from "Situation".
+
+ 28. Included definitions, comments and references for 'dcObject'
+ and 'uidObject'.
+
+ 29. Replaced PKI schema references to use draft-zeilenga-ldap-
+ x509-xx
+
+
+
+Sciberras Expires 4 October 2005 [Page 34]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ 30. Spelt out and referenced ABNF on first usage.
+
+ 31. Removed Section 2.4 (Source). Replaced the source table with
+ explicit references for each definition.
+
+ 32. All references to an attribute type or object class are
+ enclosed in single quotes.
+
+ 33. The layout of attribute type definitions has been changed to
+ provide consistency throughout the document:
+ > Section Heading
+ > Description of Attribute type
+ > Multivalued description
+ > Source Information
+ > Definition
+ > Example
+ > Additional Comments
+
+ Adding this consistent output included the addition of
+ examples to some definitions.
+
+ 34. References to alternate names for attributes types are
+ provided with a reference to where they were originally
+ specified.
+
+ 35. Clarification of the description of 'distinguishedName' and
+ 'name', in regards to these attribute types being supertypes.
+
+ 36. Spelt out ISDN on first usage.
+
+ 37. Inserted a reference to [Syntaxes] for the
+ 'teletexTerminalIdentifier' definition's SYNTAX OID.
+
+ 38. Additional names were added to the IANA Considerations. Names
+ include 'commonName', 'dcObject', 'domainComponent', 'GN',
+ 'localityName', 'organizationName', 'organizationUnitName',
+ 'surname', 'uidObject' and 'userid'.
+
+ 39. Renamed all instances of supercede to supersede.
+
+ 40. Moved [F.1], [F.30] and [SASLprep] from informative to
+ normative references.
+
+ 41. Changed the 'c' definition to be consistent with X.500.
+
+ 42. Added text to 'dc', making the distinction between 'stored'
+ and 'query' values when preparing IDN strings.
+
+
+
+
+Sciberras Expires 4 October 2005 [Page 35]
+\f
+
projects / openldap / commitdiff