Subject: re: the LDAP client caching proxy model ...

From: Brian Jarvis <[email-masked]>
Date: Mon, 18 Sep 2000 17:49:52 -0600

A general comment about the approach:

The method described using special purpose controls and responses means that
every ldap enabled program will need to be "cache enabled".  IOW, they will
not be to able to make use of the cache unless programmed to do so.  Would
it not be better to use some sort of flow through model where an ldap
enabled program that is *not* "cache enabled" would attempt to bind to the
local cache which would either use its cache or flow through to the "real"
server?  Then mobile users would only need one "cache enabled" program to
easily add/remove things from the cache.

3.1 proxyServierBind Controls:
  disconnectedMode

    Why ignore the serverPort field when in disconnected mode?  This makes
it impossible to differentiate between the LDAP servers when there are
multiple servers running on the same serverName.

4.1 Caching logic...
  base search
    "Results returned to the client, however, will be based on the search
filter specified."

        The filter only is used to determine which objects qualify.  The
attributes and typesOnly fields determine the results sent to the client.

    "The entire object shall be fetched and cached."

        What is the reason behind caching the whole object?  The search
request shows that the only the attributes named in the filter and
attributes fields are of interest...  If this is intended, then put * in the
attributes field.  If the object is large over a slow (dialup?) link this
could be painful.

5.  Authentication and access control...

  Access control and authentication in a discretionary access control system
such as LDAP (in the current ID) only control how the information is
released or modified in the system.  It does not control what can be done
with it.  IOW, once you have read information, LDAP does not control or
dictate how you will use it or where you will store it.  If the
administrator does not trust you to treat the information appropriately (as
he defines it), he should not give you access.

  Having said that, I agree that the cached objects should be protected (if
possible).  I am very concerned that you seem to be storing the identity and
keys to access the directories in the proxy server (so that the user can be
authenticated in disconnected operations).  If the mobile system falls into
the wrong hands, all objects accessible by those identities/keys are
vulnerable.  If you don't store the identities and keys, then only the
objects in the cache are exposed.  I would rather deal with the later and
restrict what I cache, than deal with the former.

--the walrus

---

From: "Vijay Kn" <[email-masked]>
Date: Thu, 21 Sep 2000 01:37:29 -0600

> The method described using special purpose controls and responses 
> means that every ldap enabled program will need to be "cache 
> enabled". IOW, they will not be to able to make use of the cache unless 
> programmed to do so. Would it not be better to use some sort of flow 
> through model where an ldap enabled program that is *not* "cache 
> enabled" would attempt to bind to the local cache which would either use 
> its cache or flow through to the "real" server? Then mobile users would 
> only need one "cache enabled" program to easily add/remove things 
> from the cache.

Good point. Support for a flow-through model is indeed desirable to transparently  support non "cache enabled" programs.  However, LDAP apps that bind to the local cache must at a minimum specify the real/remote server and port no. to the caching proxy.  LDAP apps can choose to support the proxyServerBindControl alone. This could even be integrated in the LDAP SDK so that it is transparent to apps using the LDAP SDK. The LDAP library/DLL could add the proxy control before sending it to the caching proxy.  Another option is to pass the remote server and port info. as part of the Bind DN when binding to the local cache but this makes it a non-standard solution. 

> multiple servers running on the same serverName.

Agreed. 

> attributes and typesOnly fields determine the results sent to the client.

Yes. It will be based on the attributes and typesOnly field.

> attributes field. If the object is large over a slow (dialup?) link this

If we attempt caching a partial object, it may violate schema rules wrt mandatory attributes, since the caching proxy itself would include an LDAP server and enforce schema. 

The caching proxy aims at working transparently with existing applications and use base searches as a hint to cache objects. We could say that the caching proxy will use the attribute filter to access the object from the remote server and cache the object only if all mandatory attributes are requested. However, while this would address the slow link scenario, we lose the caching benefit. 

> Access control and authentication in a discretionary access control 
> system such as LDAP (in the current ID) only control how the information is

RFC 2251 does recommend how you should store the retrieved information. Please take a look at this last paragraph from the Security Considerations section of RFC 2251.  

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

> possible). I am very concerned that you seem to be storing the identity 
> and keys to access the directories in the proxy server (so that the user 
> can be authenticated in disconnected operations). If the mobile system 
> falls into the wrong hands, all objects accessible by those identities/keys 
> are vulnerable. If you don't store the identities and keys, then only the

Again, it is important to authenticate the user in offline mode before allowing access to cached content. With secure authentication methods like Message Digest and Certificate authentication, the stored info. pose little risk since they cannot be used to authenticate to the remote directory. For  simple,  password based authentication, the caching proxy will store a one-way hash to verify the password - but not store the actual password itself (as discussed in <draft-zeilenga-ldap-authpasswd-03.txt>) .

Vijay