David Wright schrieb am Wed, Apr 10, 2002 at 01:13:37AM -0700:
>
> Since there is such as SASL love-fest going on here, allow me to chime
> in with my dissenting viewpoint. SASL adds nothing but an annoying
> dependency to LDAP. No, I take that back, it also adds a security hole.
>
> Challenge-response mechanisms have absolutely no advantage over straight
> password transmittion across an SSL/TLS encrypted line. In fact, if they
> run in cleartext, they have a few disadvantages: (1) No server
> certificate authentication. (2) If you watch challenge-response a few
> times, you can get a good deal of the way toward decrypting the password.
>
> Furthermore, in order to support multiple authentication mechanisms,
> SASL must store password essentially in cleartext (i.e. not in a hased
> form). That means if anyone ever gets access to your sasldb, you are
> hosed. Not true for an LDAP database, stores passwords in hashed form.
>
> The only advantage of a security layer is flexibility: allowing
> authentication via arbitrary backeds (LDAP, SQL, passwd, shadow,
> kerberos). While SASL makes this possible in theory, I have not had good
> experiences in trying to make use of this flexibility -- there is very
> little in the way of widely-distributed, well-tested, well-supported,
> drop-in code to do all this stuff.
>
> Finally, Birger, what's "really creative" about
>
> by self write
> by anonymous auth
> by * none
>
> ?
I have absolutly no problem with that, do it myself somewhat similar.
But what I acknowledge is that LDAP is not a framework for authentication
*mechanisms*, whatever those are/will be. SASL is one. On the other hand,
one has to see that SASL is not for storing user information (apart from
storing user passwords), LDAP is. So how do we get these toys together
if one
1. is going to protect user information based on "by self write" - you
first have to see what "self" is! - and
2. has, to faciliate 1., authenticate someone based on user information
which will always result in a request loop? We simply don't. At this
point the separation of a
user information database
and a
authentication mechanism framework
simply does not work because of overloaded interdependencies. A solution?
I don't know exactly. Either merge those two or find a workaround I guess.
Regards,
Birger
