INTERNET-DRAFT K. N. Vijay Intended Category: Informational Novell Inc. Expires: 1st March 2001 1st September 2000 The LDAP Client Caching Proxy Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires March 1, 2001. Abstract This document describes an LDAP "caching proxy" model for use on mobile clients. The caching proxy speeds up LDAP accesses by caching and enables access to LDAP directory content & execution of directory applications in offline mode. It includes a description of the model and identifies LDAP control extensions for proxy operation, cache- control & cache-management. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 1. Introduction LDAP clients have traditionally been able to access directory information from LDAP servers in online, networked mode alone. With increasing adoption of LDAP as the standard protocol for accessing directory information, both within corporate networks and on the Internet, there is a growing need for LDAP caching proxy solutions to K. N. Vijay Expires March 2001 [Page 1] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 improve availability and speed-up access to directory content. Simultaneously, the user community with mobile PC's has been growing exponentially. With increasing number of mobile users, it is essential to provide better LDAP support on mobile clients (such as notebooks, laptops). This can be accomplished by enabling offline access to LDAP content, through support for a light-weight LDAP caching proxy on the mobile client. A directory typically manages and publishes information which is subject to frequent accesses and infrequent updates. A caching proxy solution is ideally suited for such an environment. A client-based caching proxy allows mobile users to access cached LDAP content and run LDAP applications even in an offline mode. The caching proxy speeds up LDAP accesses when used in connected or online mode. This document describes a model for an LDAP caching proxy on a mobile client. It discusses mechanisms that allow LDAP clients to operate off a caching proxy and allow LDAP clients to control caching and management of LDAP objects within the caching proxy. This draft complements recent drafts like the [LCUP] which discuss how a client can synchronize cached LDAP information on mobile clients with a remote LDAP Server. 2. The LDAP "Caching Proxy on the Client" Model: Mobile client +-------------------------+ | +-------------+ | : | LDAP Client | : | +-------------+ | : ^ : | | LDAP (with Proxy & Cache : | Control Extensions) | v | : +--------------------+ : | | LDAP | LDAP | | LCUP +--------------------+ : | Server | Client |<-------------->| Origin LDAP Server | | |[LDAP Caching Proxy]| | +--------------------+ : +--------------------+ : +-------------------------+ Figure 1: LDAP Caching Proxy on the client: An LDAP Proxy component between the LDAP Client and remote LDAP Server The LDAP Caching Proxy is a component residing on the client that operates as an intermediary between the LDAP client and the remote LDAP Server(s), as shown in the figure above. LDAP accesses from the K. N. Vijay Expires March 2001 [Page 2] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 client are directed to the LDAP caching proxy, which fetches LDAP objects from remote LDAP Server(s), caches objects and serves them to the LDAP client. 3. LDAPv3 Control Extensions for Proxy Operation: This section identifies LDAPv3 Control extensions proposed to allow LDAP clients to provide proxy information. 3.1 proxyServerBind Controls: The proxyServerBind control allows the LDAP client to specify the remote LDAP server to be contacted. This control is included in the Bind Request sent to the LDAP caching proxy. 3.1.1 proxyServerBindRequest Control This control is included in the LDAP Bind Request message as part of the controls field of the LDAPMessage. The criticality SHOULD be set to TRUE. The controlValue is an OCTET STRING, whose value is the BER encoding of the following type: proxyServerBindRequest ::= SEQUENCE { serverName LDAPSTRING serverPort INTEGER DEFAULT 389 disconnectedMode BOOLEAN DEFAULT FALSE } serverName - the domain name or the IP address of the origin LDAP server. serverPort - the Port number to bind to on the origin LDAP server. This field has a default value of 389. disconnectedMode - if this field is set to TRUE, the LDAP caching proxy SHOULD service requests from the local cache for this LDAP session, without contacting the remote LDAP server. When set to TRUE, the serverPort field of the control is ignored. This feature allows implementing a logical disconnected mode operation. It is useful when a mobile user is offline and wishes to operate entirely off the local caching proxy on his client without attempting to contact the remote LDAP server. The LDAP client initiates a session with the caching proxy by including this control in the Bind Request. The default value for disconnectedMode field is FALSE (i.e. the client wishes to operate in online mode). K. N. Vijay Expires March 2001 [Page 3] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 When the disconnectedMode field is FALSE, the caching proxy SHALL attempt to bind to the origin server. The caching proxy SHALL use the same authentication method, identity and credentials as provided by the LDAP client in its Bind Request to the LDAP Proxy cache, to bind to the remote server. Authentication methods identified in [authMethods] SHOULD be supported by the LDAP Proxy cache. Anonymous authentication (section 5.1), anonymous authentication with TLS (section 5.2), Password-based authentication methods including Digest authentication (section 6.1) and "simple" authentication under TLS encryption (section 6.2) as defined in [authMethods] MUST be supported by the LDAP Proxy cache. In all these cases, the LDAP Proxy cache SHALL use the authentication method and credentials provided by the LDAP client to authenticate with the remote server. If this is the first time the LDAP client is authenticating to the remote server via the caching proxy, the caching proxy shall first attempt to authenticate to the remote server. Once the caching proxy has successfully authenticated to the remote server, it SHALL store the authentication method and credentials used by the LDAP client to bind to the caching proxy. The LDAP client is expected to authenticate to the caching proxy using the same mechanism and credentials for subsequent sessions involving the remote LDAP server. If the caching proxy has already cached objects from the specified remote LDAP Server earlier using an authenticated session, it may authenticate the LDAP client session, without contacting the remote LDAP Server. Certificate-based authentication with TLS (section 7.1 in [authMethods]) SHALL also be supported by the LDAP Caching Proxy. In this case, the proxy-agent SHOULD be able to perform a certificate- based authentication using its own certificate and request the access privileges of the identity specified by the LDAP client (in its authentication request to the caching proxy), as part of the SASL negotiations, discussed in [SASL]. The caching proxy SHOULD retain the proxyServerBindRequest control parameters and setup a session with the origin server (if one is not already active), whenever there is a cache-miss upon a base-search request or a subtree/one-level search is requested. The caching proxy may attempt to bind to one of the Shadow servers, when the origin LDAP server is not accessible. When the disconnectedMode field is set to TRUE, the caching proxy SHALL authenticate the LDAP client session and serve all requests from the local cache. In this case, the caching proxy SHOULD not contact the remote LDAP server for this LDAP Session. The LDAP K. N. Vijay Expires March 2001 [Page 4] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 caching proxy SHALL return unavailable in its BindResponse to the LDAP client, if there are no objects cached from the specified remote LDAP Server. 3.1.2 proxyServerBindResponse Control This control is included by the LDAP caching proxy server in its LDAP Bind Response message. The criticality SHALL be set to FALSE. The controlValue is an OCTET STRING, whose value is the BER encoding of the following type: proxyServerBindResponse :: = SEQUENCE { proxyServerBindResult ENUMERATED { success (0), operationsError (1), protocolError (2), authMethodNotSupported (7), strongAuthRequired(8), confidentialityRequired (13), saslBindInProgress (14), inappropriateAuthentication (48), invalidCredentials (49), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), other (80) }, } The caching proxy shall include this control in the Bind Response only when the disconnectedMode field in the proxyServerBindRequest control is set to FALSE and the caching proxy needed to bind to the origin server. In response to the proxyServerBindRequest Control, the caching proxy may attempt to bind to the origin server. The proxyServerBindResponse control allows the caching proxy to inform the LDAP client about the status of this bind operation. The caching proxy returns the result of the LDAP client Bind Request operation in the BindResponse. If it attempted a bind operation to the origin server (e.g. if this is first time, the caching proxy is contacting the origin server), it shall return the result of that bind operation in the proxyServerBindResponse control. If the origin server is not accessible, the caching proxy SHOULD return unavailable in the proxyServerBindResponse. K. N. Vijay Expires March 2001 [Page 5] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 4. LDAPv3 Control Extensions for Cache Control and Management: This section describes the logic used by the caching proxy to cache and refresh objects from the remote LDAP server. It then identifies specific LDAP controls that enable an LDAP client to modify this default caching logic by providing additional directives to the LDAP caching proxy to control caching and to manage cached objects within the caching proxy. 4.1 Caching logic used by the LDAP caching proxy: The LDAP caching proxy shall use a default caching logic as follows: Subtree and one-level search operations from the LDAP client shall be redirected to the origin LDAP server and the results relayed to the LDAP client without caching. Base search operations shall be attempted to be served from the cache. On a cache-miss, the caching proxy shall fetch the object from the origin LDAP server and return it to the LDAP client, while simultaneously caching the object. The entire object shall be fetched and cached. Results returned to the client, however, will be based on the search filter specified. When the origin server is not available (as in offline mode), all search operations (including subtree and one-level) shall be performed off the cache. Update operations shall not be permitted in offline mode. The caching proxy shall group all entries accessed from a specific LDAP server under a domain (cache-root) container which shall be named using the domain name of the remote LDAP server. (Shadow servers as defined in [LDAPv3] and listed in the "AltServers" RootDSE attribute on LDAPv3 servers may be created as alias containers pointing to this container object. This list of shadow servers may be cached within the cache-root container object). Under this cache-root container, entries will be cached along with the hierarchy upto the root of the LDAP Server i.e. all container objects present in the Distinguished Name of the object shall be cached before the leaf object itself is cached. The caching proxy shall use LCUP (refer [LCUP]) to refresh cached objects. The following sections provide an alternate cache refresh logic to be used in the interim till LCUP is deployed on LDAP servers. For each cached object, the caching proxy shall query the modifyTimestamp operational attribute of the object from the origin server and store it along with the cached object in a new "remoteModificationTimeStamp" attribute. The remoteModificationTimeStamp is an operational attribute that will be K. N. Vijay Expires March 2001 [Page 6] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 part of an auxiliary class (defined below) and will be associated with each cached object. This operational attribute and the corresponding auxiliary class shall not be returned by the caching proxy in response to search requests from the LDAP client. 4.1.1 remoteModificationTimeStamp Attribute Definition: The following attribute MUST be included in the Remote MTS auxiliary class. ( NAME 'remoteModificationTimeStamp' DESC Modification Time Stamp of object on the origin LDAP Server SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 4.1.2 ldapProxyCacheTimeStamp Auxiliary Class Definition: The following auxiliary class may be associated with each object cached by the caching proxy. ( NAME 'ldapProxyCacheTimeStamp' DESC Auxiliary Class containing modification time stamp of the object on the remote LDAP Server AUXILIARY MUST (remoteModificationTimeStamp)) ) 4.2 Cache Refresh logic used by the LDAP Caching Proxy: A caching proxy configuration policy shall determine when the LDAP caching proxy refreshes cached objects. The caching proxy shall use LCUP as the default mechanism to refresh cached objects. The following logic can be used as an alternative to interoperate with LDAP Servers in the interim till LCUP is deployed on LDAP servers. The caching proxy shall query the modifyTimeStamp attribute of the objects on the origin LDAP server and compare it with the cached "remoteModificationTimeStamp" attribute to determine if the objects present in the cache need to be refreshed. If the LDAP caching proxy finds that object has been updated on the K. N. Vijay Expires March 2001 [Page 7] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 origin server since the time the object was cached/refreshed, it will refresh the cached object along with the new modifyTimeStamp. If the modifyTimeStamp attribute is not accessible, the caching proxy shall refresh all the cached objects unconditionally. Previously cached objects that are no longer available or accessible from the origin LDAP Server shall be deleted from the cache. 4.3 The LDAP Caching Proxy logic for handling Update Operations: Update operations on cached objects are performed by the caching proxy first on the origin server and then the cached object is refreshed. Offline updates shall be permitted only when it is possible to cache access control information from the origin server as defined in section 5. The scope of this draft is restricted to mechanisms to implement a caching proxy that permits updates only in online mode. The following sections identify LDAPv3 Control extensions that allow LDAP clients to provide Cache control and Cache management directives to the LDAP caching proxy. 4.4 The proxyServerSearch Control: The proxyServerSearch control allows the LDAP client to force a search operation to be performed on the origin server and cache all entries returned as search results. This control provides the caching proxy server with information on the objects to be cached. It also provides a cache-override mechanism for the LDAP client to access an object directly from the origin server (and not from the cache). LDAP clients shall use this control only in Online mode. 4.4.1 proxyServerSearchRequest Control This control is included in the searchRequest message as part of the controls field of the LDAPMessage. The criticality MAY be set to TRUE or FALSE, in the absence of which the criticality defaults to TRUE. The controlValue is an OCTET STRING, whose value is the BER encoding of the following type: proxyServerSearchRequest ::= SEQUENCE { cacheResults BOOLEAN DEFAULT FALSE } cacheResults - if set to TRUE, the LDAP caching proxy MUST cache all entries returned by the remote LDAP Server in response to the K. N. Vijay Expires March 2001 [Page 8] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 Search request. If set to FALSE, the caching proxy submits the search request to the origin server and returns the response to the LDAP client without caching the results. This control is applied to the scope set by the ldap_search operation, i.e. base, one-level, subtree. When this control is present, the caching proxy server SHOULD submit the search request to the origin server (after removing the control) and return all entries that match the search criteria and are returned by the origin server as search results. If the cacheResults parameter is TRUE, the caching proxy shall attempt to cache all entries returned by the remote server. This control is applied to the scope set by the ldap_search operation, i.e. base, one-level, subtree. This feature is useful when an LDAP client needs to cache multiple objects returned by a sub-tree or one-level search without doing a base-search individually on each object. When objects are already present in the cache, this control effectively allows the cached objects (within the scope of the search) to be refreshed from the origin server, thereby providing a means to the LDAP client to trigger a sync to occur. The search scope allows the sync to be done on a single object or a set of objects. This control when associated with a base search provides a cache- override mechanism allowing the LDAP client to force a base search to be performed directly on and get the results from the origin server. By setting the cacheResults field to FALSE, the client can do a base search on the remote LDAP server (and selectively access some or all attributes), without updating the object in the cache. When the cacheResults field is set to TRUE, the client can use the search filter to cache/sync specific attributes of the object. 4.4.2 proxyServerSearchResponse Control: This control may be included by the LDAP caching proxy server in its LDAP SearchResultDone message. The criticality SHALL be set to FALSE. The controlValue is an OCTET STRING, whose value is the BER encoding of the following type: proxyServerSearchResponse :: = SEQUENCE { cacheResult ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), K. N. Vijay Expires March 2001 [Page 9] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 strongAuthRequired(8), noSuchAttribute(16), undefinedAttributeType(17), inappropriateMatching(18), constraintViolation(19), invalidAttributeSyntax (21), noSuchObject (32), aliasProblem (33), invalidDNSyntax(34), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), namingViolation (64), other (80) }, } The proxyServerSearchResponse control is used by the caching proxy to inform the LDAP client about the status of the search request submitted to the remote LDAP Server. If the LDAP caching proxy is not able to perform the search successfully on the remote LDAP Server, it returns an OperationsError in the SearchResultDone message. The proxyServerSearchResponse provides the specific error that occurred when the caching proxy attempted a search on the remote LDAP server. 4.5 proxyServerUpdate Control: The proxyServerUpdate Control provides a mechanism for the LDAP Client to manage the cache - specifically to cleanup/remove objects from the cache - by forcing an update operation to be performed locally on the caching proxy. This control is included in the DelRequest message as part of the controls field of the LDAPMessage. The criticality is TRUE. The ControlValue is NULL. The caching proxy shall process the DelRequest request associated with the proxyServerUpdate control only if the LDAP client has authenticated as the same identity that was used to cache the objects. Else it will return the insufficientAccessRights error in the DelResponse. When this control is present, the caching proxy server SHOULD perform the delete operation locally within the cache i.e. if the object identified by the DN in the DelRequest operation is present in the cache and is a leaf entry, the caching proxy SHOULD delete the object from the cache. The caching proxy cache MUST not attempt a remote update operation, when this control is present. K. N. Vijay Expires March 2001 [Page 10] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 This feature is useful when an LDAP client needs to cleanup objects within the cache. It provides an escape mechanism that allows the LDAP client to perform an operation locally within the cache, without attempting the operation on the remote LDAP Server. Future revisions of this draft will explore the utility of associating this control with other LDAP update operations for better cache management. 5. Authentication and Access control to objects cached in the caching proxy: The LDAP caching proxy uses the identity and credentials provided by the user to access LDAP objects from the remote LDAP Server. When the caching proxy has successfully authenticated to the remote LDAP server, it shall cache the object that the user has authenticated as to the origin server. Access to cached objects in subsequent sessions shall be permitted only after the user has successfully authenticated as the identity originally used to cache information. This ensures that the caching proxy preserves the origin server access controls to cached LDAP content by permitting access only to the user identity used to access and cache LDAP information from the origin server. Updates to cached information shall be permitted only in Online mode when the remote LDAP server is accessible, except when accompanied with the proxyServerUpdate Control, discussed in section 4.5. The caching proxy shall submit Update requests to the remote LDAP Server and refresh the cached object when this operation has been successfully completed. In effect, the update operation is performed on the remote server and then the cached object is synchronized with that on the remote server. LDAP servers today use custom access control methods to determine access rights to different objects for a subject DN. Standardization of Access Control Model for LDAP [ACL] is in progress. Once this is done and implemented on LDAP Servers, it should be possible to permit offline updates by caching effective rights the cache user identity (that user uses to authenticate to the remote LDAP Server) has to the cached objects. Future revisions of this draft will address possibility of offline updates. 6. Schema support in the caching proxy: The LDAP caching proxy shall support the base LDAP Schema defined in RFC2256. Object classes and attributes not understood by the LDAP caching proxy shall be returned to the LDAP client as is in online mode, without caching. The caching proxy schema may be enhanced to support new application specific schema extensions. K. N. Vijay Expires March 2001 [Page 11] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 The caching proxy may support intelligent schema learning wherein it learns new object class and attribute definitions online when accessing objects from the remote LDAP Server. Schema learning can be supported when caching from LDAPv3 servers by performing a base search on subschema entry. 7. Security Considerations Security considerations primarily relate to the authentication and access control to the cached objects. The LDAP caching proxy should preserve the access control restrictions of the origin server by restricting access to cached content to the client whose request caused the objects to be cached. This is covered in section 5 above. 8. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of K. N. Vijay Expires March 2001 [Page 12] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. Acknowledgements The author thanks Dinkar S., Ganesan R., Sachidanand M., Savitha R., Subramaniam K. V. and Hilarie Orman for reviewing the draft and providing valuable inputs. 11. References [LDAPv3] Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December, 1997. [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [LCUP] O. Natkovich, M. Smith, "LDAP Client Update Protocol", Internet draft, February 2000 [authMethods] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication Methods for LDAP", May 2000 [authPassword] Kurt Zeilenga, "LDAP Authentication Password Attribute", Internet draft, July 2000 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [ACL] E. Stokes, D. Byrne, B. Blakley, "Access Control Model for LDAP" July, 2000. K. N. Vijay Expires March 2001 [Page 13] INTERNET-DRAFT The LDAP Client Caching Proxy Model September 2000 12. Author's Addresses Comments regarding this draft may be sent to the author at the following address K. N. Vijay Novell, Inc. 7th Mile, Hosur Road, Bangalore 560 068 India Phone: +91-80-5721858 Ext: 2002 Fax: +91-80-5721870 Email : knvijay@novell.com This Internet Draft expires March 1, 2001. K. N. Vijay Expires March 2001 [Page 14]