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

Thanks for the feedback,

I've updated the I-D and will submit. I think I addressed everything
except the question about criticality. For criticality, the instructions
in 4.1.11 of
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-30.txt.
Basically, if the server understands the control, the criticality is
ignored and the control is honored. If the control is not understood,
then criticality determines whether the control is ignored or causes the
operation to fail.

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