OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6817
Full headers

From: masarati@aero.polimi.it
Subject: idassert-bind with SASL issues
Compose comment
Download message
State:
0 replies:
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 31 Jan 2011 17:44:23 +0000
From: masarati@aero.polimi.it
To: openldap-its@OpenLDAP.org
Subject: idassert-bind with SASL issues
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2.40.14.92)
Submitted by: ando


When idassert-bind is configured to use SASL bind, an "authcID" needs to be
provided, while the "binddn" is not needed.  However, if a "binddn" is not
provided as well, in some cases the proxiedAuthz control may be used
incorrectly.  The need to configure the "binddn" is not documented, so this ITS
is minimally addressed by documenting this requirement.

If the "binddn" is provided, everything works as expected, with the only minor
issue that the DN of the user as it is known to back-meta may not match the
actual identity the "authcID" assumed on the remote server.  The "right" way to
address this problem consists in performing a "WhoAmI" (RFC 4532) right after
the bind, or better use a "authorization identity control" (RFC 3829) along with
the bind operation.  Both approaches should be implemented, but they should not
be used unless explicitly requested.

p.

Followup 1

Download message
Date: Mon, 28 Feb 2011 02:06:08 -0800
From: Howard Chu <hyc@symas.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6817) idassert-bind with SASL issues
masarati@aero.polimi.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD/re24
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2.40.14.92)
> Submitted by: ando
>
>
> When idassert-bind is configured to use SASL bind, an "authcID" needs to be
> provided, while the "binddn" is not needed.  However, if a "binddn" is not
> provided as well, in some cases the proxiedAuthz control may be used
> incorrectly.  The need to configure the "binddn" is not documented, so this
ITS
> is minimally addressed by documenting this requirement.

I tripped over this change while investigating #6711. Adding this requirement 
is certainly not the right solution; SASL Binds ordinarily don't require a 
BindDN and requiring it here just makes things confusing.

Also with the fixes that I made for #6711 I don't believe the issue exists any 
more. Please describe the conditions where the problem occurs.

> If the "binddn" is provided, everything works as expected, with the only
minor
> issue that the DN of the user as it is known to back-meta may not match the
> actual identity the "authcID" assumed on the remote server.  The "right"
way to
> address this problem consists in performing a "WhoAmI" (RFC 4532) right
after
> the bind, or better use a "authorization identity control" (RFC 3829) along
with
> the bind operation.  Both approaches should be implemented, but they should
not
> be used unless explicitly requested.

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



Followup 2

Download message
Date: Wed, 2 Mar 2011 14:21:48 +0100 (CET)
Subject: Re: (ITS#6817) idassert-bind with SASL issues
From: masarati@aero.polimi.it
To: "Howard Chu" <hyc@symas.com>
Cc: openldap-its@openldap.org
> masarati@aero.polimi.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version: HEAD/re24
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2.40.14.92)
>> Submitted by: ando
>>
>>
>> When idassert-bind is configured to use SASL bind, an "authcID" needs
to
>> be
>> provided, while the "binddn" is not needed.  However, if a "binddn" is
>> not
>> provided as well, in some cases the proxiedAuthz control may be used
>> incorrectly.  The need to configure the "binddn" is not documented, so
>> this ITS
>> is minimally addressed by documenting this requirement.
>
> I tripped over this change while investigating #6711. Adding this
> requirement
> is certainly not the right solution; SASL Binds ordinarily don't require a
> BindDN and requiring it here just makes things confusing.
>
> Also with the fixes that I made for #6711 I don't believe the issue exists
> any
> more. Please describe the conditions where the problem occurs.

At the time I looked at this issue, there were places in the code where
after an idassert-bind the lc_bound_ndn would receive a copy of idassert's
authcDN.  In case of SASL, this is empty/null; then back-ldap (and meta)
would fail from recognizing the connection as successfully bound.  I
understand there are better solutions; for example, ldapconn_t could have
a "bound" flag, or so.  I understand that code may need some reworking,
but I can't work at that now, sorry.  p.

>> If the "binddn" is provided, everything works as expected, with the
only
>> minor
>> issue that the DN of the user as it is known to back-meta may not match
>> the
>> actual identity the "authcID" assumed on the remote server.  The
"right"
>> way to
>> address this problem consists in performing a "WhoAmI" (RFC 4532) right
>> after
>> the bind, or better use a "authorization identity control" (RFC 3829)
>> along with
>> the bind operation.  Both approaches should be implemented, but they
>> should not
>> be used unless explicitly requested.
>
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>




Followup 3

Download message
Date: Wed, 2 Mar 2011 14:25:07 +0100 (CET)
Subject: Re: (ITS#6817) idassert-bind with SASL issues
From: masarati@aero.polimi.it
To: "Howard Chu" <hyc@symas.com>
Cc: openldap-its@openldap.org
> masarati@aero.polimi.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version: HEAD/re24
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2.40.14.92)
>> Submitted by: ando
>>
>>
>> When idassert-bind is configured to use SASL bind, an "authcID" needs
to
>> be
>> provided, while the "binddn" is not needed.  However, if a "binddn" is
>> not
>> provided as well, in some cases the proxiedAuthz control may be used
>> incorrectly.  The need to configure the "binddn" is not documented, so
>> this ITS
>> is minimally addressed by documenting this requirement.
>
> I tripped over this change while investigating #6711. Adding this
> requirement
> is certainly not the right solution; SASL Binds ordinarily don't require a
> BindDN and requiring it here just makes things confusing.

I understand the fix I'm suggesting can sound counter-intuitive.  The
documentation should clearly indicate that the binddn in case of SASL is
for *local* and *internal* issues, and will not be part of the
authentication process.  As an alternative, lc_bound_ndn could receive a
dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive
the actual identity from the remote server using the authid control along
with the bind or performing a whoami extop later, as already implemented).

p.

> Also with the fixes that I made for #6711 I don't believe the issue exists
> any
> more. Please describe the conditions where the problem occurs.
>
>> If the "binddn" is provided, everything works as expected, with the
only
>> minor
>> issue that the DN of the user as it is known to back-meta may not match
>> the
>> actual identity the "authcID" assumed on the remote server.  The
"right"
>> way to
>> address this problem consists in performing a "WhoAmI" (RFC 4532) right
>> after
>> the bind, or better use a "authorization identity control" (RFC 3829)
>> along with
>> the bind operation.  Both approaches should be implemented, but they
>> should not
>> be used unless explicitly requested.
>
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>




Followup 4

Download message
Date: Fri, 04 Mar 2011 15:13:13 -0800
From: Howard Chu <hyc@symas.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6817) idassert-bind with SASL issues
masarati@aero.polimi.it wrote:
>> masarati@aero.polimi.it wrote:
>>> Full_Name: Pierangelo Masarati
>>> Version: HEAD/re24
>>> OS: irrelevant
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (2.40.14.92)
>>> Submitted by: ando
>>>
>>>
>>> When idassert-bind is configured to use SASL bind, an "authcID"
needs to
>>> be
>>> provided, while the "binddn" is not needed.  However, if a "binddn"
is
>>> not
>>> provided as well, in some cases the proxiedAuthz control may be
used
>>> incorrectly.  The need to configure the "binddn" is not documented,
so
>>> this ITS
>>> is minimally addressed by documenting this requirement.
>>
>> I tripped over this change while investigating #6711. Adding this
>> requirement
>> is certainly not the right solution; SASL Binds ordinarily don't
require a
>> BindDN and requiring it here just makes things confusing.
>
> I understand the fix I'm suggesting can sound counter-intuitive.  The
> documentation should clearly indicate that the binddn in case of SASL is
> for *local* and *internal* issues, and will not be part of the
> authentication process.  As an alternative, lc_bound_ndn could receive a
> dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive
> the actual identity from the remote server using the authid control along
> with the bind or performing a whoami extop later, as already implemented).

Using a dummy DN here sounds OK.

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


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org