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

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

To: "Jim Sermersheim" <jimse@novell.com>
Subject: Re: chaining SASL binds (Was: [ldapext] Chained Operation (control, extended op, or op?))
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Fri, 25 Jun 2004 09:39:06 -0700
Cc: mark.ennis@adacel.com, Hal Henderson <HAL@novell.com>, Ron.Ramsay@ca.com, Tammy Green <TGREEN@novell.com>, ldapext@ietf.org
In-reply-to: <s0dbf4fa.007@sinclair.provo.novell.com>
References: <s0dbf4fa.007@sinclair.provo.novell.com>

At 08:48 AM 6/25/2004, Jim Sermersheim wrote:
>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.

Some mechanisms (DIGEST-MD5's digest-uri, integrity layers)
have protections to hinder MITM attacks, but can made to
work through trusted active intermediate systems.

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

The SASL framework is client/server authentication.  But it
doesn't preclude either the client or the server implementations
from being distributed, but if they are, then they have to
take appropriate steps to ensure interoperability.

To effectively chain a DIGEST-MD5, the intermediate box
(which the client has connected to) needs to advise the remote
box (fulfilling the authentication) what digest-uri to use
in its responses to the client (passed back through the
intermediate).

Another feature would be pass enough information back to
the intermediate to allow it to establish security layers
between it and the client, preferably without exposing the
shared secret (the A1 hash) to the intermediate.  Whether
or not this is possible depends on the layer particulars.

I note that this kind of "distributed authentication" can
be applied where the communication between the client
and intermediate is not over LDAP, but over some other
SASL-supporting protocol.  For instance, it could
be used in implementation of SOAP/BEEP -> LDAP application
level gateway.

>It would be great if this research could happen in parallel,

It does seems a bit "experimental".  Another good reason
to keep it separate from the "distributed operation"
work.  Another reason to keep this "distributed authentication"
stuff separate is ease security considerations discussions.

>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

Prev by Date: Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?))
Next by Date: Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?))
Index(es):
- Chronological
- Thread