[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: [ldapext] Comments to <draft-sermersheim-ldap-chaining>

To: <hyc@highlandsun.com>, <ando@sys-net.it>
Subject: Re: [ldapext] Comments to <draft-sermersheim-ldap-chaining>
From: "Jim Sermersheim" <jimse@novell.com>
Date: Thu, 24 Feb 2005 21:45:57 -0700
Cc: Kurt@OpenLDAP.org, ldapext@ietf.org
Content-disposition: inline
I have to admit that I disliked the names and limited usefulnes of the
controls as they are defined in X.511, and that may have influenced me
to simply define them in a symmetrical and (to me) more clear way for
LDAP.

I see usefulness in chainingRequired. For example, assume a client
wishes to perform a SSS or VLV search operation and knows that the data
in the result set may be distributed (and perhaps further assume some
DSAs support chaining these operations). If the client can specify
chainingRequired, it would know that the results it gets back are
already sorted and no extra work needs to be done. If the server cannot,
or will not chain, then the operation fails, and the client learns this
up front. In the absence of chainingRequired, the client may get back
many search results -- assuming they're sorted, only to find out in the
end that one or more search result references need to be followed to
complete the operation. I believe that chainingRequired may also be
useful for other multi-object operations which are served best (or can
only be completed) by the act of DSA chaining. Off the top of my head, I
can't think of a strong case for chainingRequired during name resolution
(otehr than the case I make below for referralsPreferred), but I see no
harm in allowing it's specification.

I also see usefulness in referralsPreferred. It allows one to possibly
override whatever the server's behavior is.  We have deployments where
the server's setting is chainingPreferred or chainingRequired. Clients
may prefer to receive referrals, yet want the operation to be chained
when policy prevents a referral from being returned.

Jim

>>> Howard Chu <hyc@highlandsun.com> 02/24/05 8:45 PM >>>
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
Prev by Date: Re: [ldapext] draft-behera-ldap-password-policy - last login time
Next by Date: Re: [ldapext] Comments to <draft-sermersheim-ldap-chaining>
Index(es):
- Chronological
- Thread