Draft:Connection-less Lightweight Directory Access Protocol
| Developed by | Internet Engineering Task Force (IETF) |
|---|
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), with a simplified operation set. 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 table below shows the bit-by-bit structure of a typical CLDAP search request message, based on the LDAP message format:
| Bits | 0–7 | 8–15 | 16–23 | 24–31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Message ID | |||||||||||||||||||||||||||||||
| 32 | Protocol Op (SearchRequest) | SearchRequest Parameters (Base DN, Scope, etc.) | ||||||||||||||||||||||||||||||
| 64 | SearchRequest Parameters (cont.) | |||||||||||||||||||||||||||||||
| 96 | Optional Controls (if present) | |||||||||||||||||||||||||||||||
The response message follows a similar structure, replacing the SearchRequest with SearchResultEntry, SearchResultDone, or SearchResultReference, depending on the outcome.
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 result sizes).
- 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.