Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it.
Kerberos is secure precisely because client passwords are never transmitted across the network. Period. When you break that guarantee, everything else about the Kerberos system is jeopardized, and typically, when Kerberos is in use at a site, there's a large ecosystem of apps dependent on it and all of their security goes down the drain at the same time.
supports ldaps or STARTTLS, which would go a long way in mitigating that risk. If it didn't support TLS, I'd think that'd be a much more urgent
ldaps or TLS might be ok, assuming you're not using a broken SSL implementation. Abusing Kerberos in the requested way and relying on other security systems to take up the slack is opening yourself up to a whole world of unintended consequences, and we need only look at Debian last year to see how real those problems may be.
focus (GSSAPI only provides 56 bits of encryption).
The strength of GSSAPI's encryption layer is irrelevant in this discussion since, when used properly, it NEVER exposes the client's secret key to anybody else.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range of SASL mechanisms is broken? What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not?
RFC4513 pretty much deprecates Simple Binds. Certainly it discourages using them on an unprotected session, and the OP has already stated that he has yet to get TLS working. And applications don't have to implement specific SASL mechanisms, that's all hidden inside libldap and libsasl2. All they have to do is use the right libldap calls and they automatically get support for all mechanisms, currently known as well as future mechs.