RE: slap_sasl_checkpass - why?

["Howard Chu" <hyc@highlandsun.com>]

> -----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. (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.
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. Even stranger, if you have an
entry like so:

	dn: cn=dummy,o=foo
	userPassword: {SASL}dn:cn=dummy,o=foo

then performing a simple bind as "cn=dummy,o=foo" will cause an infinite
recursion.

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