Newbie Questions Re Use of SASL with LDAPv3

[Geiman Gilbert-GGEIMAN1]

Thanks again Howard.  One more....

As I indicated, in the application I'm working on I actually need to be
able to support both the LDAP "simple" authentication scheme (because
it's a user requirement) as well as the DIGEST-MD5 scheme.   (This would
be from an application that uses an LDAP API to do BIND operations,
either using "simple" or "sasl", as opposed to using PAM.  PAM would be
used for Linux-level login authentication...)  I understand the LDAP
"simple" scheme requires the password to be passed to the directory
server in cleartext format - does this also require the password to be
stored in cleartext in LDAP?  Part of what is confusing me is that I've
read that passwords "may" be stored in a 1-way encrypted format in the
directory, such as crypt(3).  

In general, I'm still somewhat confused on what determines whether a
password in the LDAP directory must be stored in cleartext format or
not.  Can you help clarify this for me?

(It makes sense to me that in my case, since I need to use two different
mechanisms, the password may have to be stored in cleartext format since
one method may require no encryption while the other method does require
the server to encrypt the password......)

Thanks,
Gil

-----Original Message-----
From: Howard Chu [mailto:hyc at highlandsun.com] 
Sent: Wednesday, June 07, 2006 7:13 PM
To: Geiman Gilbert-GGEIMAN1
Cc: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Newbie Questions Re Use of SASL with LDAPv3

Geiman Gilbert-GGEIMAN1 wrote:
> Howard,
> 
> Thanks for the responses!  See below for followups.
> 
> gil

> First question: Why do you need to support both Simple and SASL Binds?
> 
> [Gil] One of the customer requirements is to use "normal" (i.e.,
> UNIX-like) plaintext password authentication via LDAP. This is because

> not all LDAP servers that the system will have to connect to will 
> support SASL.  However, I also want to provide the option for a more 
> secure scheme, which is where DIGEST comes in.  And it seems as though

> SASL is the best way to support that.  If PAM is going to be used for 
> the Linux-level logins, then based on what you say below it sounds 
> like only one of these two methods can be supported for those logins.
> Correct?  

Yes, you configure pam_ldap to use one or the other.

> Then at the application level, as long as the LDAP API supports both 
> simple and SASL, I'm assuming I can query the LDAP server for the 
> "supportedSASLMechanisms" to determine if DIGEST (or any SASL options)

> are supported, and make a decision as to which type of authentication 
> to use based on the response to that query.  Do you see any problems 
> with this approach?

That is the generally recommended approach, but it misses an essential
consideration: what is the actual need for secrecy on the transaction? 
The point of using SASL/DIGEST-MD5 is to prevent plaintext credentials
from being exposed on the wire. When faced with a server that only
supports Simple Binds over cleartext connections, sometimes the correct
decision is not to talk to that server at all.

>> The current plan is to use OpenLDAP and either Cyrus or GNU SASL.  A 
>> PAM vendor has not been chosen yet, but I'm looking at PADL.
>>
>> Having read as much as I can digest on each of these mechanisms, I 
>> still have the following questions I'm hoping someone on this list 
>> can
> 
>> help me
>> with:
>>
>> 1) What form should the "userPassword" attribute in the
"posixAccount"
> 
>> entry be stored in?  Plain text?  Will the SASL functionality at the 
>> LDAP server do the MD5 hash when DIGEST is used?  Are 2
"userPassword"
>> attributes required?
> 
> Your question seems to assume that SASL will use LDAP for its password

> store. That's probably a smart thing to do, but it is not the default 
> behavior for SASL. But yes, if you're going to configure SASL to 
> retrieve its secrets from LDAP, then you must configure LDAP to store 
> userPassword's in plain text.
> 
> [Gil] I assume nothing needs to be done differently on the client side

> of things regardless of whether LDAP is used to store the 
> authentication secret or another database is used.  Is this a correct
assumption?

Correct.
> 
> I also assume when you say "you must configure LDAP to store 
> userPasswords in plain text", that such configuration would be a 
> standard function of any SASL-aware LDAP server.  In other words, is 
> it safe to assume that any LDAP server that advertises itself as 
> SASL-aware would support the ability to do this type of configuration 
> (without any form of proprietary enhancements)?

It is never safe to assume anything about arbitrary LDAP servers, you'll
have to read their respective documentation. Generally you may assume
that Cyrus-SASL and OpenLDAP play well together since a number of people
are active on both projects. (As long as you're using recent enough
versions...)

> If the LDAP server needs to store the DIGEST secrets in a separate 
> database but still use the "userPassword" attribute in the 
> posixAccount entry for the simple bind, will this present any 
> problems?  Again, does this imply that anything needs to be done 
> differently on the client side, or will the server's implementation 
> strategy along these lines be transparent to the client?

In the case of OpenLDAP there is no problem here. I can't say anything
about how other servers handle it. But it's an internal server
implementation detail, it should not be visible from the client.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/