Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock

[hyc@symas.com]

Kurt@OpenLDAP.org wrote:
> On Apr 8, 2010, at 8:08 PM, Howard Chu wrote:
>
>> Kurt@OpenLDAP.org wrote:
>>> On Apr 8, 2010, at 3:58 PM, hyc@symas.com wrote:
>>> =20
>>>> Sounds like your servers are mis-configured, it is not legal to send =
> a=3D20=3D
>>> =20
>>>> referral in response to a Bind request.
>>> =20
>>> I note that the technical specification doesn't actually preclude =
> return =3D
>>> of a referral in response to a Bind request.  However, in practice, =
> such =3D
>>> return is quite problematic due to ambiguous semantics and security =3D=
>
>>> considerations.
>> =20
>> Right. I can't find the discussion we had about this back in 2004, but =
> certainly we've already hashed this out in great detail before.
>> =20
>> The fact is that acting on a referral simply means performing a Bind =
> against some other server.
>> It does nothing for the authentication state of the session on the =
> original server.
>
> Right, by returning a referral, regardless of how far the client got in =
> authentication process (including completion of all challenges), the =
> client is now anonymous at the original server.
>
> And there's a security concern, the referral information is not =
> protected by the underlying authentication mechanism.  It is actually =
> quite possible that this be used by an attacker to cause the client to =
> try authentication multiple times, possibly with chosen plaintext.
>
> I recommend that the library never chase bind referrals.

Agreed. Patched in HEAD.

>  (I tend to =
> think of rebind as a misfeature.   Robust clients really should be using =
> the async API and carefully managing security contexts and chasing.)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/