Re: Access control vs. caches and gateways

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:04 AM 3/9/2004, Hallvard B Furuseth wrote:
>Protocol-22 contains the following.  BTW, I wonder if that and my
>suggested addition fits better in [Authmeth].
>
>> 6. Security Considerations
>
>>    Implementations which cache attributes and entries obtained via LDAP
>>    MUST ensure that access controls are maintained if that information
>>    is to be provided to multiple clients, since servers may have access
>>    control policies which prevent the return of entries or attributes in
>>    search results except to particular authenticated clients. For
>>    example, caches could serve result information only to the client
>>    whose request caused it to be in the cache.
>
>s/client(s)/client(s) or association(s)/.  A client could bind, read a
>protected entry, bind again, and try to reread the entry without
>sufficient access to it.
>
>The "MUST ensure that access controls are maintained" is troublesome.

I concur, especially as this applies to caching.  Caching procedures and
policies are outside the scope of the directory specification [X.525].
This should apply to access control (in caching environments) as well as
it applies to replication of information (by caching).

It seems odd to address the access control issue by placing requirements
upon the consumer DSA to honor the trust of the provider DSA.  Instead,
caution should be stated to operators of provider DSA that they need to
be careful who they trust.  If worded well (e.g., very general), such
a consideration could cover Hallvard's consideration below as well.

>To obey this requirement, the implementation must know which factors
>affect authorization on the server.  I suspect that's just too hard, so
>we can only make it a SHOULD.  We could say it MUST at least obey access
>control based on the authorization identity, except that the cache
>server might not be able to figure out what that is either if there are
>different authentication methods involved.  If the authorization
>identity is not supplied, it is derived from the authentication
>identity, but need not be identical to it ([Authmeth] section C.4).
>
>Also, I suggest a somewhat related security consideration is added:
>
>   Access controls, in particular those based on other factors than
>   authentication, can be unintentionally broken by gateways to the
>   server.  For example, a server can let some data be accessible only
>   for connections from IP addresses in the local network.  A gateway
>   which can be used by outsiders but is placed in the local network
>   will then give outsiders the same access as locals.
>
>-- 
>Hallvard