Re: LDAP authenticaton against PAM how-to

[Howard Chu <hyc@symas.com>]

Emmanuel Dreyfus wrote:
 > Sure, I'm very interested by feedback on the actual content on the
> document. Here are the feedbacks I gathered so far:
>
> 1) I used deprecated features, but I was not told which was the
> deprecated features

The use of plaintext passwords to authenticate to "strong" authentication 
systems is discouraged. Browsing through the mailing list archives will turn 
up this point in discussions time and time again. The use of Simple Bind to 
authenticate against SASL, instead of using actual SASL Binds, is deprecated. 
The use of Simple Bind to authenticate against Kerberos is deprecated. etc. 
etc...

> 2) I document only a small part of SASL capacities. I'm aware of that.
> The scope of the document was just to explain how to validate a
> login/password against a random PAM authentication source. It's better
> than nothing.

Are you so sure it's better than nothing? With "nothing" the integrity of 
your site's security policy remains intact. (Granted, no work gets done right 
away.) With "something" your site's security policy may crumble to nothing 
(and then down the road, no work may get done, but for worse reasons).

> 3) Doing authentication that way is The Wrong Way, I should
> authentitcate against LDAP or Kerberos. Well, it would certainly be
> better to do that, but is it completely unreasonnable to start using
> OpenLDAP without refactoring the world around it? Migration paths can go
> through harsh flag days or through softer incremental steps. I'm
> convinced that setting up an LDAP authentication against PAM can help
> people that try to make a small incremental step.

You are trading off security for expedience. That's almost always a poor 
trade. If you have convinced yourself that you've weighed all of the pros and 
cons, go ahead, but we will never encourage such a thing.

You have to step back and consider - what is authentication for? What is 
being secured? What are the consequences of insecure access to the data? What 
are the consequences of giving away a "secure" password? Can you actually 
enumerate all of them?

Taking very simple examples - the directory either contains highly sensitive 
information, or it contains completely public information. In the public 
case, there is no need for enforcement of authentication at all. If the 
system is public anyway, then you should use no passwords, or you should use 
low-value passwords - e.g., passwords that are only valid in the context of 
the directory server itself.

If you use a password to a "strong" security system, and the directory 
service is breached, you have very likely given away the keys to a lot of 
much more important systems, that were all protected by that same "strong" 
key. Can you afford such a possibility?

Using SSL/TLS to encrypt the sessions isn't a fool-proof solution. If you 
still have a cleartext LDAP port enabled on the server, anybody can perform a 
plaintext Simple Bind. Even though the server security policy may reject such 
a Bind, the damage is already done because the plaintext password has already 
been sent across the network. Do you really want to risk that?

In short - don't use Simple Binds unless both the passwords and the directory 
content are of low importance. Once you connect Simple Bind to a "strong" 
security system (like Kerberos, RADIUS, whatever) you jeopardize every other 
service on the network that also uses those systems.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/