[Date Prev][Date Next]
Re: OpenLDAP Replication - Trust or not to Trust?
At 11:47 AM 10/25/2004, Quanah Gibson-Mount wrote:
>>Since you already recognize that this is a client issue, asking how other
>>servers handle the question is irrelevant - it is not something servers
>>have to deal with.
>>As Ando already explained, the LDAP library provides functions for
>>rebinding on a referral, but the OpenLDAP tools don't use these
>>functions. So you would need to change the code for ldapmodify(1) to call
>>those functions to make it work the way you want.
>>The question is not one of technical standards, but of site policy. When
>>you perform a simple bind, you send your identity and cleartext password
>>to the server. When you receive a referral, you have to decide whether
>>you can trust the referred server. If you chase a referral to a rogue
>>server that simply steals all the passwords that it receives, you're in
>>I suppose from a technical perspective, the notion of referrals in LDAP
>>was never well designed. I believe the best way to blunder through with
>>these poor designs is to use strong mutual authentication everywhere, to
>>reduce the chance that you will inadvertently give away your credentials
>>to a rogue server. I.e., don't ever use simple binds.
>Since all the concern seems to be around simple/unprotected binds & referrals, what about making ldapmodify, etc, honor referrals when strong authentication is used?
Those are not the only concerns.
Note that even so-called strong authentication mechanisms
cause certain information to be disclosed to the server.
Even connecting to the server causes some information
to be disclosed (the IP address of the client) and certainly
opens that client to attack by the server.
Again, the question is whether or not the user trusts the
referral information and, if so, how far. Does the user
trust the information enough to connect to referred to server?
Does the user trust the information enough to enter into an
authentication exchange with that server? If so, what kind
of exchange? Etc..
Clients are suppose to act on the users behalf. This
implies a strong requirement that clients gain knowledge
from the user as to what actions to take and not to take,
especially when those actions expose information about