RE: slap_sasl_checkpass - why?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:27 AM 2002-04-16, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> slapd should both support external SASL password storage
>> and in-directory SASL password storage.  slap_sasl_checkpass()
>> is the former, not the latter.  A configure option or something
>> should allow the admin to choose.
>
>I don't think that's quite it. liblutil/passwd.c:chk_sasl() supports
>external
>SASL password storage. slapd/sasl.c:slap_sasl_checkpass(), as written,
>validates a given plaintext password against userPassword values in a
>particular directory entry. My confusion arises because the only time
>slap_sasl_checkpass() can possibly be invoked is if the user is performing
>an LDAP simple bind because the checkpass callback only handles plaintext
>passwords.

Yes.  It's only intended to be used with LDAP simple bind.

>(And slapd normally will not use any plaintext SASL mechanisms
>like PLAIN or LOGIN.) Therefore, this code can only be invoked if OpenLDAP
>is configured with --enable-spasswd, and the user's entry must contain a
>userPassword with "{SASL}something" as one of its values.

Yes.

>And as I already described below, all this will do is cause a nested search
>for some other LDAP entry, to lookup that entry's userPassword attribute,
>and perform the plaintext password validation. 

{SASL} should only be used when SASL passwords are being external
to the directory, e.g., in SASLdb or other store managed by
Cyrus SASL.

>To support generalized in-directory SASL password storage, someone needs to
>write the sasl_auxprop plugin functions to handle those lookups. There
>should be two
>versions of this, one that's embedded inside the slapd code, for its own use
>in SASL authentications, and one that is an external dynamic library that
>arbitrary SASL-based services can use.
>
>> At 07:30 PM 2002-04-15, Howard Chu wrote:
>> >Still staring at the SASL 2 code in slapd/sasl.c ... The
>> slap_sasl_checkpass
>> >function doesn't make a lot of sense to me. The checkpass
>> callback is only
>> >used when SASL is validating a plaintext password. In the
>> context of slapd,
>> >this can only happen when someone performs a simple bind, and their
>> >userPassword attribute contains "{SASL}my-username". So, we've already
>> >specified a valid LDAP DN, looked it up, and found that its
>> password should
>> >be retrieved from SASL. Now we're going to take that SASL
>> username, and ask
>> >it to be transformed into a valid LDAP DN, look for that DN's
>> userPassword
>> >attribute, and try to validate the given credentials.
>> >
>> >   ????
>> >
>> >If you want to do a simple bind, why not just stick the actual
>> password in
>> >your userPassword attribute in the first place?
>> >
>> >I suppose another way to look at it is a way to allow someone
>> else to login
>> >to your account using their plaintext password. Is this really a good
>> >feature to support? (i.e., I set my LDAP entry's userPassword to
>> include the
>> >value {SASL}dn:someone-elses-DN and then that other DN's password becomes
>> >valid for binding to my DN.) It's somewhat the opposite of SASL
>> >authorization, where you bind with your own password and then operate as
>> >someone else. Seems like a potential security hole to me, but I guess you
>> >have to go out of your way to screw yourself with it.
>> >
>> >  -- Howard Chu
>> >  Chief Architect, Symas Corp.       Director, Highland Sun
>> >  http://www.symas.com               http://highlandsun.com/hyc
>> >  Symas: Premier OpenSource Development and Support
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support