Re: SASL authentication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Date: Fri, 08 Sep 2006 09:01:41 -0600
From: Richard Megginson <rmeggins@xxxxxxxxxx>

Josh Kelley wrote:
> On 9/7/06, Richard Megginson <rmeggins@xxxxxxxxxx> wrote:
>> I checked RFC 4513  - http://www.ietf.org/rfc/rfc4513.txt - it doesn't
>> say anything about the correct result code to return in this case, other
>> than it is an error if anything other than success or bindinprogress is
>> returned.  You might want to ask on ldap@xxxxxxxxx or on
>> IRC.freenode.net #ldap if there is a standard that covers this case.
>
> Thanks for the suggestion.  I'll ask.
>
> I skimmed RFC 4513 (sans coffee) and didn't find the section you're
> referring to.  I did see that RFC 4422 (last paragraph of section 3.6)
> seems to suggest that OS X's and OpenLDAP's behavior is legitimate and
> useful.

Before you go any further with this, please tell us which version of OpenLDAP you're using. Current releases (since 2.3.6) return invalidCredentials for a SASL bind failure:

ldapsearch -H ldap://:9000 -Y DIGEST-MD5
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): user not found: no secret in database

Probably we should also do something about not returning the SASL-specific error code in this case too, to adhere more to the intent of rfc4422. Logging it on the server side should be sufficient.

I just checked, and releases 2.1 and 2.2 returned error code 80 here. So it seems Apple is relying on a broken behavior.

Yes. But it seems to differ from the behavior of a simple bind (rfc4513 5.1.3). In a simple bind, the server resultCode differentiates these cases: 1) Invalid bind DN results in a noSuchObject (well, not exactly specified, but this is the usual behavior)
2) Valid bind DN but invalid password results in invalidCredentials

However, the rfc (and also rfc 4511 Appendix A LDAP Result Codes) says that other codes may be substituted for the above "to prevent unauthorized disclosures (such as substitution of noSuchObject for insufficientAccessRights, or invalidCredentials for insufficientAccessRights)."

The SASL doc (rfc4422) says:

"It is also important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user."


So it seems that SASL wants the server not to differentiate these cases, probably for security reasons. But this makes sasl binds have different semantics than simple binds.
>
> Even if the standards permit either behavior (and even if it's
> slightly more secure to not reveal additional information, as David
> Boreham pointed out), wouldn't it be worth having FDS compatible with
> OpenLDAP and OS X?
Yes.  And please file a bug about this at http://bugzilla.redhat.com/

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

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux