Network Working Group Johansson Internet-Draft Stockholm University Expires: December 31, 2000 Hedberg Catalogix May 31, 2000 Connection-less Lightweight Directory Access Protocol draft-ietf-ldapext-cldap-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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.. This Internet-Draft will expire on December 31, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes modifications to LDAP version 3[1] to allow transport of a subset of the LDAP protocol over connection-less transport. The case of UDP/IP is covered in detail in this memo but other transport layers are possible. Johansson & Hedberg Expires December 31, 2000 [Page 1] Internet-Draft CLDAP (v3) May 2000 Table of Contents 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 3 2. Mapping LDAP protocol operations . . . . . . . . . . . . . . . 4 3. Protocol Elements and Result Codes . . . . . . . . . . . . . . 5 4. Client and Server Operation . . . . . . . . . . . . . . . . . 6 5. Considerations for Server location . . . . . . . . . . . . . . 7 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Johansson & Hedberg Expires December 31, 2000 [Page 2] Internet-Draft CLDAP (v3) May 2000 1. Overview and Rationale Using LDAP version 3[1] involves normal TCP/IP connection setup which for some applications may constitute undesirable overhead, especially in situations where only unauthenticated requests are performed. The typical use would be for fast light-weight read-only clients where latency must be kept to a minimum or for clients which makes large numbers of requests to multiple LDAP servers. An example of the latter would be an LDAP server which maintains a CIP[5] index and provides chaining of requests to servers indexed by the mesh. Such a server will often have to maintain large numbers of tcp connections. Experience from the TISDAG[4] project has shown that even with relatively small indices and few concurrent clients to the index server the number of outgoing tcp connections may be quite large and even approaching limits imposed by popular operating systems. Johansson & Hedberg Expires December 31, 2000 [Page 3] Internet-Draft CLDAP (v3) May 2000 2. Mapping LDAP protocol operations It is a requirement of CLDAPv3 that the underlying transport layer uses 8 bits per octet and that all bits are used when encoding messages. LDAP messages are encoded, one PDU per packet, as packets of the underlying transport layer. Encoded packets must be small enough to fit inside a datagram no bigger than the size of the MTU of the transport mechanism. For UDP/IP normally this means that an LDAP message may be no larger than 512 bytes. Furthermore the MTU of the transport mechanism must be at least big enough for a client LDAPMessage request. Johansson & Hedberg Expires December 31, 2000 [Page 4] Internet-Draft CLDAP (v3) May 2000 3. Protocol Elements and Result Codes The protocol messages of CLDAPv3 are identical with those of LDAPv3 and each LDAPMessage is mapped to a single packet of the underlying transport layer. In addition the following error code added by CLDAP version 2[3] is included: resultsTooLarge (70), The semantics of this error message in CLDAPv3 also remains the same: If when encoding a reply to a client the LDAPMessage PDU containing the message cannot be encoded in a single transport layer datagram the server must send this error code to the client. The action taken by a client when encountering this error message is not specified in this document. The client may choose to open a tcp connection to the server and retry the request. Note that it is possible for a client to issue a modifying request (add, delete, moddn, modify) together with a control or an extended request which modifies the directory such that the response is too large to fit in a datagram which would make it impossible for the client to know if the requested operation was successful or not. For this reason servers implementing this protocol must respond with an error of unwillingToPerform(53) if such a request is received. An alternative would be to include a control with the resultsToLarge(70) response containing a cookie which when presented to the server on a tcp connection would result in the server returning the full response to the client. Such a scheme is beyond the scope of this memo but may be addressed in a future draft. Johansson & Hedberg Expires December 31, 2000 [Page 5] Internet-Draft CLDAP (v3) May 2000 4. Client and Server Operation In this section we describe the requirements on servers and clients implementing CLDAPv3 as well as a description of the protocol exchanges and the differences that exist between LDAPv3 and CLDAPv3. The rest of this section will focus on CLDAPv3 over UDP/IP, other connection-less transport layers may pose additional or completely different requirements on servers and clients although it is expected that the protocol itself would not need to changed. Servers implementing this protocol over UDP/IP should provide a protocol listener on port 389. They must also check the version field of the LDAP PDU and return an error code of protocolError(2) if a version 2 client issues any requests besides searchRequest. Since the protocol described in this memo is not compatible with CLDAPv2 it is worth noting that it is very easy for server implementations to support both version 2 and 3 clients over UDP/IP and other connection-less transports described in CLDAP version 2[3]. They only have to check the ASN.1 tag of the first ASN.1 object following the MessageID. In the case of CLDAPv3 this tag has the CONTEXT tag bit set (being a CHOICE component) this is not the case in CLDAPv2 (where the second ASN.1 object in the CLDAPMessage SEQUENCE is an OCTET STRING). Servers wishing to support both version 2 and version 3 clients must reply to version 2 searchRequests as per RFC1789[3]. Using UDP there is no guarantee that all packets sent from the server will eventually arrive at the client. Therefore the application using CLDAPv3 have to handle packet loss. One way of aiding this would be to add something like a packet sequence number in the PDUs sent from the server to the client, how this is to be done is outside the scope of this document. Johansson & Hedberg Expires December 31, 2000 [Page 6] Internet-Draft CLDAP (v3) May 2000 5. Considerations for Server location If a client uses DNS to locate LDAP servers as per RFCXXXX[2] and finds a SRV record for _ldap._udp all referenced servers must support the protocol described in this memo over UDP/IP-transport. It is beyond the scope of this document to describe how a client may find out what transport mechanisms are supported by a given server. Johansson & Hedberg Expires December 31, 2000 [Page 7] Internet-Draft CLDAP (v3) May 2000 6. Security considerations Unlike CLDAP verison 2[3] it is possible for a CLDAPv3 client to establish a secure association to a CLDAPv3 server by a SASL bind which can establish an integrity or security layer. Note that authentication alone is not enough to maintain a secure association with a connection-less LDAP server since there is no connection with which to associate the authenticated client. In order to establish a secure association a security or integrity layer must be in place through the usual method of embedding the LDAP messages in bind requests. Also in order to make use of this method any APIs involved must take care to protect the association between client and server (including session credentials) from hijacking If high reliability is needed clients must either employ some external means of ensuring that messages get through (such as a strict regimen of timeouts and resends) or use normal LDAP instead. This is especially important during a sequence of bind requests and responses. Johansson & Hedberg Expires December 31, 2000 [Page 8] Internet-Draft CLDAP (v3) May 2000 References [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [2] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP Services with DNS", Internet-Draft draft-ietf-ldapext-locate-02, April 2000. [3] Young, A., "Connection-less Lightweight Directory Access Protocol", RFC 1798, June 1995. [4] Daigle, L. and Hedberg, R, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)", Internet-Draft draft-daigle-tisdag-01.txt, January 2000. [5] Hedberg, R, "LDAPv2 client vs. the Index Mesh", RFC 2657, August 1999. Authors' Addresses Leif Johasson Stockholm University Stockholm SE-10691 Sweden Phone: +46 8 164541 EMail: leifj@it.su.se Roland Hedberg Catalogix Dalsveien 53 Oslo 0775 Norway Phone: +47 23082996 EMail: roland@catalogix.ac.se Johansson & Hedberg Expires December 31, 2000 [Page 9] Internet-Draft CLDAP (v3) May 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Johansson & Hedberg Expires December 31, 2000 [Page 10]