[ldapext] Re: Comments to <draft-sermersheim-ldap-chaining>

Jim

>>> Pierangelo Masarati <ando@sys-net.it> 1/25/05 3:03:05 PM >>>
Jim,

I'm currently implementing the (now expired) version 02 of
<draft-sermersheim-ldap-chaining> in OpenLDAP based on the "chain"
overlay as first implemented by Howard Chu and subsequently extended by
myself. What follows is a collection of considerations that emerged
from the implementation and that, perhaps owing to my lack of
understanding of some details, I think require a clarification and might
be useful for the continuation of the work on the draft. The comments
are quite unsorted.

1. Comments

1.1. Return code renaming
I suggest to change the name of "chainingRequired" into
"requiresChaining" to avoid confusion and symbol clashes with the
"requiresChaining" value in the "Behavior" enumeration.

1.2. Return code usage clarification
I think you should clarify when the special return codes related to the
control need be returned. For instance, if behavior is
"chainingRequired" and the operation would return a referral that cannot
be chased, I'd return "cannotChain", but for any other "Behavior" case
returning a referral is acceptable, and returning a referral is not an
error: <draft-ietf-ldapbis-protocol> lists "referral" as a non-error
result code in Appendix A.1, so I don't see an application for the other
error code you indicate ("chainingRequired"). I suggest you clarify
your intentions.

1.3 OPTIONAL values and defaults
In the draft, both "Behavior" fields are marked as OPTIONAL. My point
is: what's the reason for not providing any? For instance, the "chain"
overlay in OpenLDAP's slapd by default acts as if both "Behavior" were
"chainingPreferred". If the control is present, but no values are
given, I see no point in using the control. Unless you mean that the
default behavior of the DSA may differ if the control is present or not;
e.g. if no control is present, default to "referralsRequired", while if
the control is present, default to "chainingPreferred" (OpenLDAP's slapd
without and with the "chain" overlay), and in any case both defaults are
left to the implementor. If this is the case, I suggest it is clarified.
[technical note: it is not clear to me if, in case none of the values is
provided, the crtls_value of the control structure should be empty or null].

1.4 Operations.
It appears from the draft that the control applies to all operations,
except "abandon, unbind, and StartTLS"; the second value applies only to
search continuations, and may apply to future operations. Should the
presence of the second value in other operations among those already
defined that do not require it be treated as an error? I think this
should be clarified.

1.5 Behavior
1.5.1. "chainingPreferred" and "referralsPreferred" don't present any
issue;
1.5.2. "chainingRequired" might be an issue if, in case it cannot be
honored, no intermediate results should be returned at all (I'm talking
about searches). In fact, unless caching all intermediate results
locally upon completion, it is very likely that a referral is met after
some entries/other intermediate results have already been returned. If
the referral cannot be chased, the operation should be terminated and
"cannotChain" be returned. I think it should be clarified if this
behavior is acceptable or not.
1.5.3 "referralsRequired" should never fail, because that's the
regular behavior in case no chaining capabilities are available; I don't
see any issue that might prevent a DSA from returning a referral. Can
you clarify why this option is ever supposed to fail?

1.6. Criticality
I think the behavior should be discussed in view of the criticality of
the control. Would it be correct to simply ignore the "Behavior" in
case the control is not critical? It is my understanding that only the
"chainingRequired" behavior may suffer from the criticality field being
set when referrals cannot be chased; the other options should pose no
issues. How should the behavior differ in this case based on the value
of the criticality flag?

2. Few notes on the implementation.

2.1. Approach
The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase
referrals in case they're being returned by the underlying backend (or
at the frontend level, if used as a global overlay). Credits for both
the overlay and the underlying LDAP backend essentially go to Howard Chu.

2.2. Authorization and Security
As such, it can exploit the identity assertion capabilities of back-ldap
to proxyAuthz the identity of the client while chasing the referral;
this provides features like SASL bind, authorization policies based on
pattern matching, grouping and so both at the local and at the remote
site. The connection can be wrapped in a TLS layer (use ldaps://
referral URIs, or StartTLS over regular ldap:// URIs).

2.3. Relationship with other extensions
Interaction with the "manageDSAit" control as described in the draft,
although not intended, seems to work as described in the draft. Of
course it may need further testing.

2.4. Missing features and possible development
I plan to introduce:
2.4.1. authorization based on referral suffix (e.g. only chain
requests rooted at <DN>)
2.4.2. authorization based on the referral URI (host/port portion)
2.4.3. authorization based on the protocol scheme (e.g. only ldaps://)
2.4.4. authorization based on some ssf
2.4.5. to allow chaining of multiple DSAs, back-ldap's identity
assertion must be modified to allow authentication identity selection
based on the DSA that is being chained (now a single identity can be
specified, since back-ldap is intended to contact a single URI).
2.4.6. it is not clear yet how the control could interact with further
referral chasing operated at the client library's level by the LDAP
backend (proxyAuthz and so).
2.4.7 there's yet no provisions to check for loops and so.

2.5. Specific numbers and #defines
I'm currently using OIDs and return codes under OpenLDAP's/private
space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h):

/* LDAP Chaining Behavior Control *//* work in progress */
/* <draft-sermersheim-ldap-chaining>;
* see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */
#ifdef LDAP_DEVEL
#define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3"

#define LDAP_CHAINING_PREFERRED 0
#define LDAP_CHAINING_REQUIRED 1
#define LDAP_REFERRALS_PREFERRED 2
#define LDAP_REFERRALS_REQUIRED 3
#endif

/* for the Chaining Behavior control (consecutive result codes requested;
* see <draft-sermersheim-ldap-chaining> ) */
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
#define LDAP_REQUIRES_CHAINING 0x4110
#define LDAP_CANNOT_CHAIN 0x4111
#endif

I hope the discussion above, and the quick overview on the current
implementation and its todo list, may be of help in stabilizing and
completing the draft.

Sincerely, p.

SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497