Re: [ldapext] CLDAPv3

[Thorild Selen <thorild@Update.UU.SE>]

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
Datorföreningen Update / Update Computer Club, Uppsala, SE
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext