Subject: Re: [ldapext] CLDAPv3

From: Luke Howard <[email-masked]>
Date: Sat, 15 Feb 2003 10:03:48 +1100

Active Directory does use CLDAPv3, so I think it is worth documenting; 
it is on my todo list.

Like RFC 1798, multiple LDAP messages are returned in a single PDU;
however, AD does not wrap these in an ASN.1 sequence, but instead
return them back-to-back.

-- Luke

>From: Thorild Selen <[email-masked]>
>Subject: [ldapext] CLDAPv3
>To: [email-masked]
>Date: Fri, 14 Feb 2003 18:22:47 +0100
>
>Greetings,
>
>I've noticed that the web page for ldapext working group mentions that
>the group will define connectionless LDAPv3; this is however not
>mentioned among the Goals and Milestones on the page, nor can I find
>anything about it anywhere, so I'm getting curious; is someone working
>on this, and in that case, how is it going; and if the project has
>been abandoned, why?
>
>It may be that CLDAP hasn't ever been much used, but to me, stressing
>the "Lightweight" in "LDAP", it seems quite useful for applications
>that just need to do very simple lookups now and then. So, what's
>happened to CLDAP?
>
>Thorild Selén
>Datorföreningen Update / Update Computer Club, Uppsala, SE
>_______________________________________________
>Ldapext mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ldapext

--
Luke Howard | PADL Software Pty Ltd | www.padl.com
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Thorild Selen <[email-masked]>
Date: Sat, 15 Feb 2003 01:20:37 +0100

> Active Directory does use CLDAPv3, so I think it is worth documenting; 

Right, so CLDAPv3 actually exists in practice, whether we choose to
believe in it or not. (Of course, one could argue that it's not CLDAP,
but just some ugly hack that happens to resemble CLDAP.)

 > return them back-to-back.

Is this how CLDAPv3 was meant to work? In any case, it should be easy
for the server to look at the BER encoding of the request and see
whether the client has wrapped the request in an ASN.1 sequence or
not, and assume that it expects a reply on the same form; perhaps not
pretty, but it should work.

So, does anyone of you have anything vaguely resembling a draft spec
on CLDAPv3? If so, does it address this issue of (possibly optional)
sequence wrapping?

Thorild Selén

---

From: Thorild Selen <[email-masked]>
Date: Mon, 17 Feb 2003 20:45:44 +0100

Here are some thoughts about adapting CLDAP as in RFC1798 to
LDAPv3. It is not to be taken as a draft of any kind, rather as a
quick sketch.

---

CLDAP as specified in RFC1798 allows only one request per datagram,
only one response per datagram. We change this as follows:

A datagram is allowed to contain:

	(optionally) one BindRequest or BindResponse. This must be the
	first element of the sequence when present.

then
    	zero or more of SearchResultEntry and SearchResultReference,
	followed by one SearchResultDone
     OR
  	any single response of another kind
	(CompareResponse, extendedResponse)
     OR
	any single request other than BindRequest.

(This is a minimalistic approach. Perhaps one would want to allow one
or more extended operations in a datagram, possibly in combination
with another operation.)

Structure of the datagram:

CLDAPMessage ::= SEQUENCE {
	messageID	MessageID
	user		LDAPDN,		-- on request only --
	protocolOP 	CHOICE {
			bindRequest	BindRequest,
			bindResponse	BindResponse,
			searchRequest	SearchRequest,
			searchResEntry	SearchResultEntry,
			searchResDone	SearchResultDone,
			searchResRef	SearchResultReference,
			compareRequest	CompareRequest,
			compareResponse	CompareResponse,
			abandonRequest	AbandonRequest,
			extendedReq	ExtendedRequest,
			extendedResp	ExtendedResponse },
	controls	[0] Controls OPTIONAL
	}

All these are as defined in RFC2251 (LDAPv3) except:

  user: as in RFC1798 (CLDAP); for logging purposes or
	whatever. You're probably not going to trust this anyway. One
	possible use would be for abuse tracking, since a proxy could
	use it to tell you about the origin of the request. (But do
	you trust the proxy?)

What's different?

The following parts of LDAPv3 have a restricted usage or are left out
for simplicity, or simply because they are not very useful for a
connectionless transport:

In the message:

   bindRequest, bindResponse, unbindRequest:

      One purpose of the bindRequest is for the client to tell the
      server which version of the LDAP protocol to use. A client
      should therefore be allowed to prefix a request with an
      anonymous bind request, in which case the reply should contain
      the corresponding bind response.  SASL authentication is not
      available for connectionless transports.  Unbinding or rebinding
      is not supported for CLDAP.

   modifyRequest, modifyResponse, addRequest, addResponse, delRequest,
   ddelREsponse, modDNRequest, modDNResponse:

      Updating operations are probably better left out, because of the
      security problems with UDP and similar connectionless protocols,
      and also because of the problems that duplicate or lost messages
      would introduce. These requests and their corresponding
      responses are therefore not available for CLDAP.

   extendedReq, extendedResp:

      Some extended operations will not be available for CLDAP;
      updating operations (for the reasons listed above) as well as
      other operations that are not meaningful in a connectionless
      context.

----

Comments are certainly welcome.

Thorild Selén

---

From: Leif Johansson <[email-masked]>
Date: Mon, 17 Feb 2003 22:52:28 +0100

>LDAPv3. It is not to be taken as a draft of any kind, rather as a

In the enclosed draft Roland and I tried to bring ldap/udp more in line
with the rest of ldapv3. The problem (imho) with RFC1798 is that it
is a completely separate protocol with totally different semantics from
ldapv2 and certainly from ldapv3. Our idea was to create something
which could be used in the same way as ldapv3.

The idea is to keep ldap/udp very simple and require the use of extensions
which provide a _limited_ form of safe delivery and/or authentication.
Remember that if you wind up creating tcp you are probably doing
something wrong. We never got around to specifying the extensions but
a shared-secret HMAC across the PDU might be one of them.

          MVH leifj

Network Working Group                                          Johansson
Internet-Draft                                      Stockholm University
Expires: November 8, 2001                                        Hedberg
                                                               Catalogix
                                                            May 10, 2001

           Lightweight Directory Access Protocol over UDP/IP
                     draft-ietf-ldapext-ldapudp-00

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."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 8, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This memo describes modifications to LDAP version 3[1] to allow
   transport of a subset of the LDAP protocol over UDP/IP. 

Johansson & Hedberg     Expires November 8, 2001                [Page 1]

Internet-Draft                 LDAPv3/UDP                       May 2001

Table of Contents

   1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . . 3
   2. Protocol Elements and Result Codes . . . . . . . . . . . . . . . 4
   3. Description of the protocol  . . . . . . . . . . . . . . . . . . 5
   4. Dealing with lost result PDUs: reuse of messageIDs . . . . . . . 6
   5. Security considerations  . . . . . . . . . . . . . . . . . . . . 7
      References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9

Johansson & Hedberg     Expires November 8, 2001                [Page 2]

Internet-Draft                 LDAPv3/UDP                       May 2001

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 the number of round-trips 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[6] 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[5] 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 very large.

Johansson & Hedberg     Expires November 8, 2001                [Page 3]

Internet-Draft                 LDAPv3/UDP                       May 2001

2. Protocol Elements and Result Codes

   The protocol messages of LDAPv3/UDP are identical with those of
   LDAPv3 and each LDAPMessage is encoded and transmitted in a single
   UDP datagram. In addition a new result code is defined:

                             connectionRequired           (70??)

   The semantics of this result code is as follows:

      * Whenever a server implementing the protocol described in this
      draft or any protocol derived from this protocol receives a
      request it for some reason is unwilling or unable to perform over
      connection-less transport the server must return this result
      code. Typical examples for this are when the resultset is to
      large to fit into the biggest packet the network in use can
      support or when a client tries to do a bind but does not provide
      enough information for it to succeed

      * Whenever a client implementing the protocol described in this
      draft or any protocol derived from this protocol receives this
      result code the client must not retry the request using
      connection-less transport.

Johansson & Hedberg     Expires November 8, 2001                [Page 4]

Internet-Draft                 LDAPv3/UDP                       May 2001

3. Description of the protocol

   Use of the LDAPv3 protocol over UDP means that protocol elements can
   become dropped, delayed or even duplicated by the transport layer.
   In order to deal with these situations clients and servers
   implementing this protocol must employ some means for detecting
   and/or retrying failed requests.

   Note that the search operation is slightly different in this
   respect. A SearchResultEntry or a SearchResultReference can become
   lost or duplicated withouth affecting the flow of requests and
   responses between the client and the server as long as the
   SearchResultDone packet is not lost. The loss of this packet would
   be indistinguishable from the situation where the search is still
   underway. Thus the delivery of the resultcode packets (including the
   ExtendedResponse) is different from the delivery of search result
   packets. Since the application may or may not care about actually
   receiving SearchResultEntry and SearchResultReference packets some
   method for ensuring the delivery of these may or may not be needed.

   The reason why the safe delivery of the result-code pdu is important
   can be illustrated with a simple example. Assume that a client
   issues an add operation for a new entry. This request is received by
   the server and the add operation is performed but the resultcode
   (SUCCESS) gets lost on its way to the client. If the client were to
   retry the operation by issuing the same add request under a new
   message id the result code would indicate a failure since the object
   already exists in the server.

   There are several possible mechanisms for solving the problems
   described above and a particular choice must be agreed upon by the
   client and server before using ldap over connection-less transports.
   The method by which a mechanism is selected is not covered by this
   document but may involve the client connecting to the server over
   tcp to read the root-DSE entry before using connection-less
   transport. This standard may be extended by specifying other
   mechanisms for safe delivery of protocol messages.

   Servers implementing this protocol SHOULD provide a protocol
   listener on port 389. How the existence of other protocol listeners
   are communicated to clients (server location) is not covered in this
   document.

   To be used over LDAPv3/UDP other extensions defined for LDAPv3 must
   be amended by text which explains how the controls and/or exops
   defined in the extension interact with LDAPv3/UDP. In particular,
   for each control that is marked critical by the extension the
   standard must explain how safe delivery of the pdu containing the
   control is ensured.

Johansson & Hedberg     Expires November 8, 2001                [Page 5]

Internet-Draft                 LDAPv3/UDP                       May 2001

4. Dealing with lost result PDUs: reuse of messageIDs

   A simple method for sending and receiving protocol messages over
   lossy connection-less transport is reuse of messageIDs. Whenever a
   client times out before receiving a result PDU it is waiting for it
   may, using this mechanism, retry the same request using the same
   messageID as before. A server implementing reuse of messageIDs is
   required to maintain a cache (the size of which should be annonced
   in the rootDSE-object; see below) of recent result-codes for each
   source port and address. Consequently a client using this mechanism
   must bind to the local port before issuing requests so that a
   particular client process can be identified by the server. The
   client must not issue more operations at a time than the cachesize.

   A server implementing this mechanism must announce it by providing a
   value for the size of the result code cache in the root-DSE
   attribute LDAPResultCacheSize:

              (<TBA>
               NAME 'LDAPResultCacheSize'
               DESC 'The size of the per-client cache of resultcodes
               SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
               EQUALITY 'integerMatch'
               NO-USER-MODIFICATION
               USAGE dSAOperation )

   Note that this mechanism does not protect agains a third party
   inserting protocol messages. See the section on security
   considerations.

Johansson & Hedberg     Expires November 8, 2001                [Page 6]

Internet-Draft                 LDAPv3/UDP                       May 2001

5. Security considerations

   Since SASL[3] is only defined for connection-oriented operation it
   is not possible to use SASL authentication with LDAPv3/UDP and a
   server must respond with an result code of connectionRequired (??)
   if a bind requesting SASL authentication is received.

   Mechanisms for safe delivery of protocol messages which do not
   protect against third-party attacks (inserting messages into the
   protocol stream) should not be used for update operations unless the
   underlying transport provides protection against such attacks.

Johansson & Hedberg     Expires November 8, 2001                [Page 7]

Internet-Draft                 LDAPv3/UDP                       May 2001

References

   [1]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol (v3)", RFC 2251, December 1997.

   [2]  Kent, S and R Atkinson, "Security Architecture for the Internet
        Protocol", November 1998.

   [3]  Myers, J, "Simple Authentication and Security Layer (SASL)",
        October 1997.

   [4]  Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP
        Services with DNS", Internet-Draft
        draft-ietf-ldapext-locate-02, April 2000.

   [5]  Hedberg, R and L Daigle, "Technical Infrastructure for Swedish
        Directory Access Gateways (TISDAG)", January 2000.

   [6]  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: [email-masked]

   Roland Hedberg
   Catalogix
   Jegerveien 25
   Oslo  0777
   Norway

   Phone: +47 23082996
   EMail: [email-masked]

Johansson & Hedberg     Expires November 8, 2001                [Page 8]

Internet-Draft                 LDAPv3/UDP                       May 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001). 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 November 8, 2001                [Page 9]

---

From: Thorild Selen <[email-masked]>
Date: Mon, 17 Feb 2003 23:37:32 +0100

[quoting draft-ietf-ldapext-ldapudp-00:]

 >    [...] A server implementing reuse of messageIDs is required to
 >    maintain a cache (the size of which should be annonced in the
 >    rootDSE-object; see below) of recent result-codes for each
 >    source port and address. Consequently a client using this
 >    mechanism must bind to the local port before issuing requests so
 >    that a particular client process can be identified by the
 >    server. The client must not issue more operations at a time than
 >    the cachesize.

This approach has a few drawbacks:

 * The server is not stateless; it has to keep track of some data for
   each client. This means that it won't be as lightweight as CLDAP,
   from the server's point of view.

 * The client is required to keep track of the cache size of the
   server. This makes it less lightweight in another way; you have to
   start your communications with asking about the cache size.

Avoiding this would be more useful, in my opinion. The big win with
connectionless LDAP ought to be that it is even more lightweight than
LDAP over TCP; no unneeded packages going back and forth, no extra
state to maintain for the server. If that isn't so important, then you
could just as well use LDAP over some connection-oriented protocol,
such as TCP, instead.

Thorild Selén

---

From: Leif Johansson <[email-masked]>
Date: Tue, 18 Feb 2003 00:50:14 +0100

>   from the server's point of view.
Granted but that is hardly an issue with modern servers.

>   start your communications with asking about the cache size.
I am not sure about that but even if it is true most clients start life 
by asking
about various capabilities anyway... The usefullness of disconnected 
operation
is (imho) all about managing large amounts of tcp connections or not.

>could just as well use LDAP over some connection-oriented protocol,
Again I don't agree that this is the point (if indeed there is a point) 
to this
exercise.

          Cheers Leif

---

From: Thorild Selen <[email-masked]>
Date: Wed, 19 Feb 2003 01:53:30 +0100

> Granted but that is hardly an issue with modern servers.

That depends on how much you want it to scale, of course. For normal
loads you are probably correct, whatever a "normal load" is.

 > is (imho) all about managing large amounts of tcp connections or not.

So with your proposal it will have to manage a large number of UDP
"connections" instead. What you have described is not connectionless
LDAP, but LDAPv3 over a connectionless transport. There are still
connections in some sense, you just move the job of managing the
connections from one layer to another, probably with some gains
depending on how lousy your TCP/IP implementation is.

(If it is so troublesome to manage many simultaneous TCP connections,
then maybe one should ask why; the state for managing a TCP connection
might well be smaller than the data you have to keep track of for each
client using your LDAP/UDP. If LDAP/UDP is still that much better --
perhaps your implementation of TCP is the culprit, rather than LDAP.)

 > Again I don't agree that this is the point (if indeed there is a point) 

Perhaps we're talking past each other, since we seem to have different
goals in the first place; you want to run LDAPv3 (as true to the
original as possible) over UDP, while I'm looking for an extremely
lightweight protocol for directory lookups. (That's the point, and
that was the point for CLDAP as described by RFC1798.) These goals are
close to each other but different; the most appropriate solutions may
therefore be different.

Thorild Selén

---

From: Thorild Selen <[email-masked]>
Date: Fri, 21 Feb 2003 23:39:31 +0100

I've given some more thought to the CLDAPv3 issue. How about a
solution like this?

Basically: A request datagram (client to server) consists of one
single LDAPMessage containing optionally one BindRequest, then any
number of other requests (but see below). A response (server to
client) is one single datagram consisting of a LDAPMessage containing
the results of each of the requests in the request datagram, or an
appropriate error if these won't fit into a single datagram (with
possible exceptions as detailed below).

Any LDAPv3 request is allowed. However:

A datagram sent by the client SHOULD NOT contain any request in
addition to (first) the optional initial bind request and (last) any
other request, unless these additional requests are Extended
Operations that are intended to affect how the server interprets or
processes other requests in the datagram.

A server MUST NOT perform an operation unless it knows that it
eventually will be able to deliver the full result, assuming that both
client and server are still running by then and can still
communicate. If a server decides not to accept an operation on these
grounds, it SHOULD return a "connection required" type of error.

A server MAY perform an operation that, for correct operation, would
require caching of results (as described by Leif Johansson and Roland
Hedberg, or by any other means), but only if both client and server
support such a method, and the client explicitly asks the server to
use it for the operation (using a Control or Extended Operation
request submitted with the request). A server is not required to
support any such method.

A server MAY split the results of one request into several datagrams
only if the client explicitly asks for it (by some Control or Extended
Operation possibly to be defined later; and in this case every
datagram must still be a complete LDAPMessage). Otherwise, the server
MUST return at most one single datagram in response to a single
datagram.

For any request, a server MAY return a "connection required" type of
error.

Again, this is just a quick sketch. Please tell me what you think.

Thorild Selén

---

From: Leif Johansson <[email-masked]>
Date: Sat, 22 Feb 2003 15:56:39 +0100

>single LDAPMessage containing optionally one BindRequest, then any
I have a couple of problem with this:

1. You can't do bind over UDP in any sensible way. You won't get away
with specifying plain password mechs in this day and age and SASL requires
a connection.

2. You will limit yourself to applications where all results fit in a single
datagram. Try returning a few userCertificates and you will be running out
of space really quick.

This is just off the top of my head. I will have to read your proposal 
again...

       MVH leifj

---

From: Thorild Selen <[email-masked]>
Date: Sat, 22 Feb 2003 20:52:07 +0100

> with specifying plain password mechs in this day and age and SASL requires

True; the main reason for allowing a bind here is to let the client
tell the server which version of the protocol it uses. (A suitable
authentication scheme for CLDAP could be devised later; I agree that
plain passwords are not to recommend.)

 > 2. You will limit yourself to applications where all results fit in
 > a single datagram. Try returning a few userCertificates and you will
 > be running out of space really quick.

I would like to allow for an extension for multiple datagram
responses, but not mandate it.

Thorild Selén

---

From: Leif Johansson <[email-masked]>
Date: Sun, 23 Feb 2003 00:08:32 +0100

Stig Venaas wrote:

>On Sat, Feb 22, 2003 at 03:56:39PM +0100, Leif Johansson wrote:
>  
>
>I haven't looked enough at these things, but I wonder if one could reuse
>mechanisms from SNMP? Something like HMAC-SHA or HMAC-MD5, See sections 6
>and 7 of RFC 3414.
>
>Stig
>
>  
>
That was my idea. That way you can also make sure you are not loosing 
response pdus.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 23 Feb 2003 00:12:05 +0100

>plain passwords are not to recommend.)
It is generally a good idea to authenticate the entire protocol exchange 
if possible...
The protocol version may seem harmless but...

>responses, but not mandate it.
Then I suggest you define the "multipleResponse" extension to LDAPv3 and
stick that into a standard LDAPv3 pdu. Such an extension might be useful for
TCP applications aswell....

---

From: Stig Venaas <[email-masked]>
Date: Sat, 22 Feb 2003 21:07:03 +0100

Stig