Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

LDAP Version 3

Overview of LDAP and CLDAP

Overall LDAPv2 Architecture

The original model of LDAPv2 was as a protocol to access an X.500 directory. LDAP is defined in terms of the X.500 Directory Abstract Service, which is provided by the X.500 Directory Access Protocol (DAP), that is the standard client access protocol to an X.500 directory. LDAP was designed to provide access to X.500 directories while not incurring the network resource requirements of the X.500 Directory Access Protocol (DAP). In essence, LDAP is a lightweight DAP.

LDAP uses the X.500 information model. Details of this information model, and information on X.500 in general, is available in many places. The core X.500 model is of a tree of entries, each of which contains information about a particular object. Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kinds of values are allowed in the attribute. In the tree, each entry is uniquely named relative to its siblings by its relative distinguished name, consisting of one or more distinguished attribute values from the entry. The concatenation of all the relative distinguished names from the root of the tree to a particular entry is that entry's distinguished name, which is globally unique.

The primary differences between LDAP and the X.500 Directory Access Protocol (DAP) are:

1. LDAP does not use the OSI upper layers stack: a client simply makes a TCP connection to an LDAP server, over which it sends requests and receives responses.
2. Although the LDAP protocol, like DAP, is written in the ASN.1 language and encoded in binary, LDAP uses a string representation for all attribute types, values and distinguished names.

These two differences are why LDAP is considered 'light', and in many cases these changes will simplify the implementation of directory clients and user interfaces.

LDAP version 2 (LDAPv2), is specified in three documents:  RFC 1777 'The Lightweight Directory Access Protocol'; RFC 1778 'The String Representation of Standard Attribute Syntaxes'; and RFC 1279 'A String Encoding of Distinguished Name'. These documents are all Internet standards track specifications.

LDAPv2 provides most of the DAP functionality. The significant functional differences between DAP and LDAPv2 are:

1. LDAPv2 allows clients to bind to servers either anonymously with no authentication, or with a password carried in the clear. The cryptographically secure authentication methods of DAP are not supported in LDAPv2.
2. LDAPv2 has search, compare, abandon, add, remove and modifyRDN operations, but it does not have read or list operations, since these are functionally equivalent to base object or single level searches with a filter that matches every entry. Thus the operation mapping between the protocols is not 1:1.
3. An LDAPv2 client connects only to a single server. There is no "referral" mechanism, such as the one in DAP, to enable an LDAP server to redirect an LDAP client to another server. This difference was intended to hide the complexities of the directory infrastructure from an LDAP client. While this was helpful in some situations, it proved to be an undesirable restriction.

The C API for the University of Michigan LDAPv2 client library has been published as informational RFC 1823. This API achieves simplicity by the basic underlying data types having string representations. For example, a search request procedure call might be written as:

ldap_search_s( ld, 'o=U of M, c=US',
               LDAP_SCOPE_SUBTREE,'(cn=Babs Jensen)', NULL, 0,
               &results );

This API, along with the free LDAP implementation from the University of Michigan, has enabled a wide range of applications to integrate LDAP.

There is a second protocol, CLDAP (Connectionless LDAP), specified in RFC 1485, which defines a simple "single shot" lookup protocol based on the LDAP protocol data units (PDUs) and mapped onto the Internet User Datagram Protocol (UDP). CLDAP is useful for programs which require very high performance lookup of simple data. An example of this is a system process requiring network addressing information.

LDAP Version 3

After LDAP implementations began to be deployed and experience in operating them was gained in the Internet community, it became clear that there were a number of limitations in the specifications which needed to be addressed as work was undertaken to deploy LDAP more broadly. In addition, a number of new features had been identified which were desirable for integration into the protocol, such as stronger authentication mechanisms. Thus it was decided to upgrade the specifications in order to address these new requirements. The IETF started active work on LDAP version 3 (LDAPv3) in December 1995.

Since December 1995, the original proposal for LDAPv3 developed by the LDAP authors has been discussed and refined in the IETF working group on accessing and synchronization of directories, and is now an Internet Proposed Standard RFC.

LDAPv3 is an incremental extension to LDAP, which is broadly compatible with the previous LDAPv2, and servers which implement version 3 must be capable of interoperating with clients supporting version 2. All LDAPv2 operations and options are valid in LDAPv3, and with the exception of the certificate and revocation list attributes, all the attribute definitions and syntaxes are also supported. In addition, the specification of LDAPv3 also incorporates CLDAP as a connectionless mode of LDAP.

Architectural Change

Old Model

New Model

An architectural shift has been made for LDAPv3. LDAPv3 is defined to be a client server protocol, and the server can be provided in any manner. There is no requirement to use LDAP to access an X.500 directory. Many have interpreted this change as LDAP somehow being 'liberated' from X.500. This is not a sensible interpretation, because LDAP is still defined in terms of X.500. Thus an LDAPv3 server does not have to be X.500, but it does have to behave in the manner defined by X.500.

Distribution

The directory information tree can be distributed across multiple servers through the X.500 concept of the naming context, a contiguous tree of entries mastered by a single server. If an LDAPv3 server receives a request which affects an entry outside of the naming contexts it holds, then it can return to the client a referral, containing the URLs of servers which are more likely to hold that naming context.

The client can control whether the server returns referrals by providing a list of the protocols it supports for referral, such as 'ldap' or 'X.500', and sets service controls for the server which control how the server makes use of referrals.

Earlier versions of LDAP did not permit servers to return referrals. This meant that servers were required to be able to contact other servers if necessary, which would often require significant additional network processing resources on servers.

Management

Since with referrals clients may be contacting arbitrary servers in the Internet, LDAPv3 servers are required to provide additional management information. The client can obtain from the server:

• A list of the naming contexts it maintains.
• The URLs of alternative servers to contact in case this server is later unreachable.
• The identifiers of any supported extensions which this server supports.
• The electronic mail address of the server's administrator.

The client can also retrieve from each entry the name of the client which last modified the entry, and the time when it was last modified.

A client when following a referral indicates to the referred-to server the URL of the referring server, so that if a server has incorrect knowledge about the distribution of directory information, this problem can more quickly be detected.

In LDAPv2, the complete list of object classes and attributes permitted to be carried in protocol was fixed in the specification, and there was no mechanism for a client to discover if a server was capable of handling additional attributes. LDAPv3 servers are required to support the X.500 subschema subentry, in which they publish all their supported object classes and attributes. Thus organizations can define and use their own attributes in servers, and there is a mechanism for clients to discover the definitions of these attributes.

Internationalization

As LDAP version 2 was based on the attribute definitions in X.500 (1988), the only supported character sets were ASCII and T.61 (a western European character set). X.500 (1993) also permits the Unicode character set to be used, which has been designed to allow for all natural language scripts to be represented, including those of Asian languages. In LDAPv3 all string values and distinguished names are written in a UTF-8 encoding of the Unicode character set. UTF-8 encodes a character into a variable number of bytes, and the advantages over double-byte or four-byte character encodings is that its representation is more space efficient, and that printable ASCII characters have the same representation in UTF-8.

There is also a framework added to LDAPv3, which allows for attributes to be tagged with a language. This mechanism is intended to allow future extensions to support multiple languages in a single directory.

Extensibility

LDAPv3 provides a framework for bilaterally defined operations, which could be optionally supported by clients or servers. This will be used as a framework for future extensions of LDAP and is also useful for certain deployments which require additional features be carried in LDAP, for example X.500 signed operations and results.

Client Flexibility

Three features have been added in order to enhance clients with user interfaces.

The first is that clients may request that information in a search result be returned in pages. The client might choose a page size which corresponds to the maximum number of entries which could be displayed on the screen at once. The client can then request any page be returned from the search, in order to support the user scrolling.

The second is that clients can request an attribute value size limit, in order to prevent values too large to process or too slow to transfer from being returned from a search. This would be useful for clients located across a slow link: large attributes such as photographs would be excluded from a result, in order to provide faster retrieval of smaller attribute values.

The client can also request modify rights during a base object search, which indicate whether it would be permitted to later modify that entry.

X.500 (1993)

LDAPv3 also provides support for several of the new features from X.500 (1993) and X.500 (1997). Some of these have been covered in other sections. An LDAPv3 client also has access to the following functions:

• Specify new matching rules to use during a search (such as keyword matching).
• Modify a DSA's knowledge of naming context distribution with the manageDsaIT extension.
• Provide a new superior entry name in the modifyDN operation, in order to move an entire subtree of entries.
• Make modifications using alias names for entries, so that a client does not need to discover an entry's actual name in order to make changes to it.

Security

The main security enhancement to LDAPv3 is that new authentication mechanisms have been added to the bind operation: password protection using a hash function, and certificate-based digitally signed token. These are fully compatible with the definitions found in X.509, so that an LDAP to X.500 gateway can pass them directly to the X.500 server. The protocol is extensible to allow for privately-defined or future additional authentication mechanisms, including challenge-response and multi-stage binds, and the server can return credentials to the client.

A problem with LDAPv2 deployment was that the string syntaxes for certificates and certificate revocation lists (CRLs) were not reversible, and that is was not always possible to obtain the DER binary encoding of values with these syntaxes in order to be able verify signatures. Thus in LDAPv3 clients can request to obtain CRLs, certificates and distinguished names in binary (DER encoded ASN.1) form, which eliminates the ambiguity.

More Information

LDAPv3 is specified in the following RFCs:

There is a wide range of ongoing IETF work to increase LDAPv3 functionality. There are at least 30 LDAP related working drafts The following work items are ongoing:

• Schema listing mechanisms.
• Peer authentication using an X.509 based SASL mechanism.
• Operation of TLS (Transport Layer Security), previously known as SSL (Secure Socket Layer).
• Role Based Access Control.
• Paged results, and a variant on paged results known as scrolling view.
• LDAP APIs in 'C' and Java.
• LDAP Java controls.
• LDAP over MIME.
• Dynamic directory entries (two specifications)

Some of this work is likely to result in standards specifications at some stage.

Isode and LDAP

Isode has a long association with LDAP. Steve Kille, CEO of Isode, was one of authors of the original LDAP and chaired the IETF working group that led to its standardization. The other two authors of LDAP worked for organizations that were members of the ISODE Consortium (the precursor to Isode). The ISODE Consortium, Isode and Isode have included LDAP in their product set since the first release in 1993, and funded development of the freely available LDAP from University of Michigan that played a key role in the success of LDAP. Alan Young of Isode was the author of the connectionless LDAP (CLDAP) specification. Isode staff provided the initial drafts of LDAPv3, and continue to play an active role in developing LDAP. This will be reflected in the M-Vault, and other Isode products.