Re: C LDAP API: security considerations

[Ashish Kolli <akolli@us.oracle.com>]

Hi Kurt,

	Your suggestions are good but it is difficult to get
a consistent implementation unless one (or all) of the following are put
in the standards track:

- additional API hooks to control the referral chasing characteristics on
  the client side. Currently the API draft provides for functions/control
  that can chase or not chase referrals. We need some more controls that
  will allow a client to control the type of authentication used when
  binding to a referred server.
  
- Root DSE of the main LDAP server containing some information about the
   'trustworthiness' of LDAP servers that it can return referrals to.

- the 'trustworthiness' of the referred servers being returned with the
   actual referral message from the main LDAP server.


I would recommend against changing the current default behavior of clients
chasing referrals. I think that the clients should use the same
'authentication information' for the referred server as the main server.
This is useful because:
	+ it will cover most of the usage cases
	+ it requires no change to existing client code
	+ to some extent it requires little administrative overhead
	   (other than duplicating the user information in both the
	     LDAP servers)

Only the security minded clients should use the additional
API functions to hide the 'authentication information' from "unsafe"
servers while chasing referrals. 

Comments/suggestions are welcome.


Regards,

Ashish Kolli

OiD Group


On Mon, 8 Nov 1999, Kurt D. Zeilenga wrote:

> I believe it wise to add a security consideration stating that
> implementations should not reuse authentication information,
> without application interaction, when chasing referrals.
> That is, unless the application authorizes reuse with the
> authentication information (or provides new information via
> some mechanism) with the server chased, the implementation
> should use an anonymous bind.
> 
> Even if DIGEST-MD5 was in use, such application interaction
> should still be recommended to be consistent with "keeping
> long-lived copies of credentials without the application's
> knowledge is discouraged."
> 
> I also suggest that "long-lived" should be clarified. Something
> like "implementations should not maintain copies of authentication
> information, including credentials, any longer than necessary."
> In particular, authentication information should not live longer
> than the API call it was used with.  (Implementations are encouraged
> to "forget" such information sooner).
> 
> Note also that I prefer "authentication information" over
> "authentication credentials" as the authorization ID itself
> may be sensitive.
> 
> Kurt
> 
>