Access control vs. caches and gateways

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.
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