RE: C LDAP API: security considerations

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 12:16 16.11.99 -0800, Paul Leach (Exchange) wrote:

> Fine -- then let's make an _option_ that says "I'm a really smart app, and 
> I want to have control over whether referrals are chased".

We already have that.
The question is whether we remove it, mandate one reasonable thing to do 
with credentials when chasing referrals, or add more controls to let the 
client control what the Right Thing is.


> However, I still believe that apps don't want to be that smart, that no 
> apps are that smart, that no apps should be expected to be that smart, and 
> that no apps can be that smart.

My take is that not doing this right is forcing applications to be stupid 
whether they want to or not.

IF one implements the current spec as "simple credentials are reused", the 
result is that the right to write an operational entry causing a referral 
is now equivalent to the right to capture all passwords used in LDAP with 
referrral-chasing applications.

May be a valid policy decision. But it needs to be an informed one.


> In particular, with respect to the last point, any policy that an admin 
> wants to apply, they want to apply across all the apps in their 
> organization. E.g., if Dun&Bradstreet is an "expensive" site, then all 
> apps should avoid it if the policy is not to pay. Or, conversely, the 
> policy might be that only fee-based sites with which the organization has 
> an agreement can be used -- in which case, again, _all_ apps should obey 
> the policy. IMO, the only way that can happen is if the LDAP API layer 
> does it. It is not plausible that lots of independently developed apps 
> will enforce such policies in the same way. That's what I meant by "no 
> apps can be that smart" -- they can't be the same as other apps.

<SPAN MODE="IETF Policy">
IMNSHO, this is exactly the wrong thing to have happen in the *standard* 
LDAP API. Policy engines cannot be standardized at the present stage of our 
ignorance; a standard API should (IMNSHO) be no more than a means of 
creating protocol elements on the wire and state in the state machines on 
each end.

It is then up to the vendor (hi vendor!) to provide extended APIs that 
build upon the standard LDAP API to encapsulate policy decisions by the 
site admin.
But this functionality SHOULD NOT be standardized and MUST NOT be mandatory.
</SPAN>


> FInally, all these requirements for public directories are conflicting 
> with what often wants to happen within an organization. Organizations will 
> want the ability to repartition their namespace across servers without 
> affecting the clients. This implies that referrals get chased automatically.

Using what credentials?

                     Harald

--
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no