Draft:Connection-less Lightweight Directory Access Protocol

CLDAP (Connection-less Lightweight Directory Access Protocol) is a protocol defined in RFC 1798 (published April 1995) for accessing directory services over a connection-less transport, such as UDP. It was designed as a lightweight alternative to connection-oriented protocols like LDAP, targeting applications needing quick lookups of small amounts of directory information. CLDAP was published as a Proposed Standard but was moved to Historic status in March 2003 by RFC 3352 due to limited deployment and several technical shortcomings.

Overview

CLDAP was introduced to complement LDAPv2 by providing a mechanism for directory access without the overhead of establishing and closing TCP connections or performing session bind and unbind operations. It operates over UDP, using a simple request-response model where a client sends a search request, and the server responds with a search result or an error. CLDAP was intended for applications requiring minimal, read-only directory lookups with small result sizes, such as address book queries.

Features

Connection-less Operation: Uses UDP to avoid TCP connection setup and teardown.
Read-Only Access: Supports only search operations, not modifications.
Anonymous Access: Does not support authentication, limiting operations to anonymous users.
Small Result Sizes: Designed for queries returning limited data, reducing network overhead.
Simplified Protocol: Omits session management, making it lightweight but functionally limited.

Structure

CLDAP messages are formatted as Lightweight Directory Access Protocol (LDAP) messages, encapsulated in UDP datagrams. The message format follows the LDAP protocol structure as defined in RFC 1777 (LDAPv2), encoded using Basic Encoding Rules (BER) of ASN.1. A CLDAP message includes a message ID, a search request, and optional controls, with responses containing a message ID, search results or errors, and optional referrals. The fields are packed with the most significant byte first (network byte order), and the most significant bit is numbered 0 (MSB 0 bit numbering).

The diagram below shows a simplified structure of a minimal CLDAP SearchRequest message. Note that actual message lengths vary due to the variable nature of BER encoding (tag-length-value format); this example assumes a short Base DN and omits fields like Filter and Attributes for brevity.

CLDAP SearchRequest message format
Offset	Octet	0								1								2								3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Message ID Tag (0x02)								Message ID Length (4)								Message ID Value (part 1)
4	32	Message ID Value (part 2)																SearchRequest Tag (0x63)								SearchRequest Length (26)
8	64	Base DN Tag (0x04)								Base DN Length (5)								Base DN Value (part 1)
12	96	Base DN Value (part 2) ("o=org")																								Scope Tag (0x0A)
16	128	Scope Length (1)								Scope Value (0)								DerefAliases Tag (0x0A)								DerefAliases Length (1)

Message ID Tag: 8 bits: The tag identifying the Message ID field, set to 0x02 (BER Integer type).
Message ID Length: 8 bits: The length of the Message ID value in bytes, typically 4 for a 32-bit integer.
Message ID Value: 32 bits: A unique identifier for the message, used to match requests with responses. Split across two rows for bit alignment.
SearchRequest Tag: 8 bits: The tag identifying the SearchRequest operation, set to 0x63 (application-specific tag [3] for SearchRequest in BER).
SearchRequest Length: 8 bits: The length of the SearchRequest sequence in bytes, variable based on the content (assumed 26 in this example).
Base DN Tag: 8 bits: The tag identifying the Base DN field, set to 0x04 (BER Octet String type).
Base DN Length: 8 bits: The length of the Base DN value in bytes (e.g., 5 for "o=org").
Base DN Value: 40 bits: The Base Distinguished Name, specifying the starting point in the directory (e.g., "o=org"). Split across two rows for bit alignment.
Scope Tag: 8 bits: The tag identifying the Scope field, set to 0x0A (BER Enumerated type).
Scope Length: 8 bits: The length of the Scope value in bytes, typically 1.
Scope Value: 8 bits: The search scope (e.g., 0 for baseObject, 1 for singleLevel, 2 for wholeSubtree).
DerefAliases Tag: 8 bits: The tag identifying the DerefAliases field, set to 0x0A (BER Enumerated type).
DerefAliases Length: 8 bits: The length of the DerefAliases value in bytes, typically 1.

The response message follows a similar structure, replacing the SearchRequest with SearchResultEntry, SearchResultDone, or SearchResultReference, depending on the outcome. Fields like Filter and Attributes, omitted here for brevity, are also variable-length and encoded in BER format.

Applications

CLDAP was intended for:

Lightweight directory lookups, such as address book queries in email clients.
Applications requiring fast, stateless directory access with minimal overhead.
Environments where UDP’s simplicity was preferred over TCP’s reliability.

However, its limited functionality (anonymous, read-only, small results) restricted its practical use cases, contributing to its lack of widespread adoption.

Security Considerations

CLDAP has significant security limitations, which contributed to its obsolescence:

No Integrity Protection: Messages are not protected against tampering.
No Confidentiality: Data is transmitted in plaintext, exposing sensitive directory information.
Anonymous Access Only: Lacks authentication, making it unsuitable for secure environments.
Limited Internationalization: Inadequate support for non-ASCII character sets.

These shortcomings made CLDAP unsuitable for modern directory access needs, especially as security requirements grew in the late 1990s.

Status and Obsolescence

CLDAP was published as a Proposed Standard in 1995 but saw limited deployment over the following years. RFC 3352 (March 2003) moved CLDAP to Historic status, citing several reasons for its lack of adoption:

Limited functionality (anonymous, read-only, small results).
Insufficient security capabilities (no integrity or confidentiality protection).
Inadequate internationalization and extensibility.
Lack of multiple independent implementations.

The IETF’s LDAP Extensions Working Group (LDAPext WG), chartered in 1997 to update CLDAP, concluded without producing a revised standard. While interest in connection-less directory access protocols persisted, the community recognized the need for further experimentation to address outstanding technical issues, particularly security concerns. As of 2025, CLDAP remains Historic, and modern directory access typically uses LDAP over TCP or secure alternatives like LDAPS.

Notable Implementations

CLDAP saw very limited deployment due to its constraints and lack of security features. The protocol was initially developed with contributions from the Union Bank of Switzerland, which may have implemented an early version for internal directory lookups, such as employee address books. Despite its Historic status, CLDAP has been observed in legacy Microsoft Active Directory deployments, where misconfigured servers exposed on port 389 have been exploited in amplified reflection DDoS attacks since the 2010s, due to the protocol’s UDP-based nature and high amplification factor (56–70 times the request size). No widespread, production-grade implementations are documented, and RFC 3352 notes the absence of multiple independent implementations as a reason for its retirement.

References

"RFC 1798: Connection-less Lightweight Directory Access Protocol (CLDAP)". Internet Engineering Task Force. Retrieved 2025-05-15.
"RFC 3352: Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status". Internet Engineering Task Force. Retrieved 2025-05-15.
"RFC 1777: Lightweight Directory Access Protocol (LDAPv2)". Internet Engineering Task Force. Retrieved 2025-05-15.