Re: chaining SASL binds (Was: [ldapext] Chained Operation (control, extended op, or op?))

["Jim Sermersheim" <jimse@novell.com>]

When I've talked about this with people in the past, I was told that
some SASL mechanisms will work with a man in the middle, but others
won't. Of course, I don't remember the details.

Is there such a thing as a recognized trusted MITM? Does the concept
exist in the SASL framework?

It would be great if this research could happen in parallel, but
somewhat separately, from the chained operation (just one less set of
problems for me to focus on).

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/25/04 8:35:17 AM >>>
I changed the subject as it likely best to separate this
discussion from the more general chained operation discussion.

At 12:54 AM 6/25/2004, Ramsay, Ron wrote:
>It seems a funny model. The X.500 approach would be to bind to the
other DSA at the appropriate authentication level and pass the requester
and the auth level in the request. In fact, I don't even understand what
is meant by chaining SASL bind exchanges as some of these would be point
to point and no third party would/should be able to participate.

s/no third party/no untrusted third party (e.g., an attacker)/

Mechanisms are often designed to offer protection from MITM attack.
While these mechanisms can make it hard for trusted 3rd parties
to participate in the exchange, they don't generally preclude
such participation.  It is often possible for trusted 3rd
parties to participate without losing the MITM protective
services.

The reason why I want to formalize a mechanism for trusted 3rd
party participation is to ensure the MITM protective services
are preserved.

Kurt

>-----Original Message-----
>From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On 
>Behalf Of Mark Ennis
>Sent: Friday, 25 June 2004 16:47
>To: Kurt D. Zeilenga
>Cc: ldapext@ietf.org; Jim Sermersheim
>Subject: Re: [ldapext] Chained Operation (control, extended op, or
op?)
>
>
>Kurt D. Zeilenga wrote:
>> 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.
>
>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.
>
>> 
>> Kurt 
>> 
>> 
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/ldapext 
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org 
>https://www1.ietf.org/mailman/listinfo/ldapext 
>
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org 
>https://www1.ietf.org/mailman/listinfo/ldapext 


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