[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Pierangelo Masarati wrote: 
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

I'm a bit skeptical about these features of the draft. X.511 only provides for "preferChaining" and "chainingProhibited." It strikes me that "chainingRequired" (and the implication that a request must fail if chaining is not available) is not useful. In the default case, where the control is not present, and the server does not support chaining, the server would just return a referral and the client would receive it and choose to follow it or drop it. Any client that goes to the effort of implementing this control will receive less information than it had without it. Seems like a lot of effort to go thru to be worse off than you were when you started. From another angle, the decision of whether to deal with referrals or not still resides with the client/App writer, and the server doesn't (and shouldn't have to) care.

I would eliminate the chainingRequired behavior, and leave the result code name alone (out of a foolish consistency, perhaps, but it matches the name used in X.511).

Further aligning with X.511, I would consider renaming "referralsRequired" to "chainingProhibited" since the two are equivalent. I personally don't see any use for "referralsPreferred" since (a) that's probably the server's default anyway and (b) it's only a preference, and the server will blithely ignore it if it's not the default. If you have a use case in mind I guess I'll let it slide, but surely any LDAP -> X.500 gateways would just delete this in any requests passed along. [By the way, I'm looking at a 2001 4th Edition X.500 draft; if I'm out of date here please disregard...]

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


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext



--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext