Subject: Re: [ldapext] Chained Operation (control, extended op, or op?)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 21 Jun 2004 16:13:00 -0700

At 03:37 PM 6/21/2004, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <[email-masked]> 6/21/04 2:14:38 PM >>>
>>A few more reasons to use an extended operation here:
>>
>>MessageId handling - if we assume messages from multiple
>>  clients are multiplex over one session to the chained
>>  server, use of a control would require messageId munging.
>
>I purposely defined the 'wrapped' thing to be specific operations and
>controls (not LDAPMessage) so that we wouldn't have two different
>messageIDs. I can change it back,

Please do.  IIRC, message signatures encompass the whole
LDAPMessage (less the signature control).

>but I note for the scenario above
>would require the sending DSA to also provide the incomming user's
>identity using something like the proxy AuthN control,
>or by adding another 'originator' field to the chained request.

"Another" or "an"?  That is, do we need more than one
'originator' field?

BTW, I'd like to add support for chaining SASL bind exchanges.
This will require some fields beyond those offered by the
X.518 ChainingArguments/ChainingResults structures.

Kurt 

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

---

From: Mark Ennis <[email-masked]>
Date: Fri, 25 Jun 2004 16:47:08 +1000

> X.518 ChainingArguments/ChainingResults structures.

I agree that a mechanism for chaining SASL bind exchanges would be 
useful, however, current chaining mechanisms (e.g. X.518 or LDAP 
referrals) depend on name resolution of a base object. The bind 
operation, particularly when using a SASL mechanism, does not have a 
base object for the name resolution process. This would mean special 
procedures for "chaining" this operation.

Does this also require formalising some type of trust model between DSAs 
if we are going to delegate authentication operations to another server?

Is it possible to translate this SASL bind exchange into a LDAP 
operation the initiating DSA invokes, e.g. a search for the SASL 
"username" with a control used to transmit the SASL credentials and 
receive the SASL auth-response? Such an operation may then be chained by 
the responding DSA(s) and authorization decisions will be done using the 
initiating DSA as the authorization identity?

- Mark.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 25 Jun 2004 06:49:08 -0700

At 11:47 PM 6/24/2004, Mark Ennis wrote:
>I agree that a mechanism for chaining SASL bind exchanges would be useful, however, current chaining mechanisms (e.g. X.518 or LDAP referrals) depend on name resolution of a base object. The bind operation, particularly when using a SASL mechanism, does not have a base object for the name resolution process. This would mean special procedures for "chaining" this operation.
>
>Does this also require formalising some type of trust model between DSAs if we are going to delegate authentication operations to another server?

Yes.

>Is it possible to translate this SASL bind exchange into a LDAP operation the initiating DSA invokes, e.g. a search for the SASL "username" with a control used to transmit the SASL credentials and receive the SASL auth-response?

Depending on mechanism, depending on assumptions, yes.

>Such an operation may then be chained by the responding DSA(s) and authorization decisions will be done using the initiating DSA as the authorization identity?

Possibly.

I, however, was considering an approach where the initiating server
would pass through the original request with some additional information
so that the chained server can form the proper response, and return
that response with some additional information needed by the chaining
server to make use of the response.

This may be an area better left to a separate document (and
separate extended operation).  If I have time in the next few
weeks, I'll try to outline a proposal here in an I-D.