Subject: [ldapext] Proposal of a companion control to draft-wahl-ldap-session

From: Pierangelo Masarati <[email-masked]>
Date: Sat, 15 Sep 2007 16:13:58 +0200

Hi all.

The draft in object proposes a control that a client can send along with
a request, and similarly a server can return along with a response, to
add session tracking information to LDAP operations when a client-server
operation is just part of a larger infrastructure.

I think that, in the spirit of a fair cooperation between components of
the same infrastructure, the session tracking control of
draft-wahl-ldap-session (1.3.6.1.4.1.21008.108.63.1) could be augmented
by a companion control that requests session tracking contents in
response to an operation, to allow the client to request information
about how a proxy handled the operation.  The rationale behind it is
that a proxy, acting as a client in an operation that is chained across
a distributed system (I'm using the term "chain" in a loose manner, with
no direct reference to chained operations as described in X.500), might
want to track how the operation is actually performed only in some
cases, so a server could be configured to return control
1.3.6.1.4.1.21008.108.63.1 only on demand.

I'm proposing this enhancement here instead of in a separate I.D.
because I think I need some preliminary feedback first, and also because
I think it is so closely related to draft-wahl-ldap-session that it
could even be integrated in it, if considered appropriate.  Based on
discussion, if any, I plan to start implementing it in OpenLDAP very soon.

The semantics of the proposed control is discussed below.

Cheers, p.

        - o --- o --- o -

This control solicits a response containing the same type of information
of control 1.3.6.1.4.1.21008.108.63.1 for informational purposes.

request control: sessionTrackingRequest
OID: TBA
criticality: TRUE or FALSE
value: propagate BOOLEAN OPTIONAL

if the server is willing to propagate the control, this occurs only if
propagate is not FALSE.

if the server is not willing to propagate the control and propagate is
TRUE, if criticality is TRUE, the operation is bounced returning
unwillingToPerform, otherwise if criticality is FALSE the control is
ignored.

if the client has no preference about control propagation, the control
value MUST be absent.

response control: sessionTrackingRequest
OID: TBA
criticality: FALSE as per RFC 4511

four response scenarios:

1. [in case of request criticality == FALSE]
   the control is absent (not recognized, or unwillingToPerform
   because of local privacy/security policy considerations)

2. [in case of request criticality == TRUE]
   the response is unwillingToPerform (not recognized, or because
   of local privacy/security policy considerations)

3. [regardless of request criticality]
   the control is present, but the value is absent: the request
   has been handled locally, or the server is pretending so

4. [regardless of request criticality]
   the control is present, with value as per 1.3.6.1.4.1.21008.108.63.1

If value is present, it SHALL contain information as per
1.3.6.1.4.1.21008.108.63.1 related to the remote server that was
contacted to perform the operation.  It is left to the DSA's discretion
(based on local privacy/security policy considerations) to propagate the
control request along with the operation, according to the semantics of
the "propagate" in the request, and to return any other instance of the
control response along with the response to the operation; in this case
there might be multiple instances of the control in the response.

If the server is willing to provide 1.3.6.1.4.1.21008.108.63.1 in the
response, and sessionTrackingRequest was issued and not ignored, it
SHALL return sessionTrackingRequest instead.

The same security considerations of draft-wahl-ldap-session apply.

Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   [email-masked]
---------------------------------------

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext