INTERNET-DRAFT K. N. Vijay Intended Category: Informational Novell Inc. Expires: 17th July 2001 17th January 2001 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 July 17, 2001. Abstract This document describes an LDAP "caching proxy" model for use on mobile clients. The caching proxy speeds up LDAP accesses by caching objects and makes LDAP directory content available in offline mode, enabling offline execution of directory-enabled applications. 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 K. N. Vijay Expires July 2001 [Page 1] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 directory information, both within corporate networks and on the Internet, there is a growing need for LDAP caching proxy solutions to 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 for 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 on the client 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 & management of LDAP objects within the caching proxy. This draft complements recent drafts like the LDAP Client Update Protocol [LCUP] which discuss how a client can synchronize LDAP content cached on mobile clients with remote LDAP Servers. 2. The LDAP "Caching Proxy on the Client" Model: Mobile client +-------------------------+ | .+---------------+ | : . | LDAP Client-n | : | +---------------+ | | : | LDAP |--+ : | | Client-1 | . | : +---------------+. : | ^ | LDAP (with Proxy & Cache +----------------------+ : |...| Control Extensions) . | Origin LDAP Server-n | | v v | . +----------------------+ : +--------------------+ : +----------------------+ . | | LDAP | LDAP | | LDAP,LCUP +-+--------------------+ |. : | Server | Client |<------------>| Origin LDAP Server-1 |-+ | |[LDAP Caching Proxy]| | +----------------------+ : +--------------------+ : +-------------------------+ Figure 1: LDAP Caching Proxy on the client: An LDAP Proxy component between LDAP Clients and remote LDAP Servers K. N. Vijay Expires July 2001 [Page 2] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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 LDAP clients are directed to the LDAP caching proxy, which fetches LDAP objects from remote LDAP Server(s), caches objects and serves them to the LDAP clients. 3. LDAPv3 Control Extensions for Proxy Operation: This section identifies LDAPv3 Control extensions that allow LDAP clients to specify proxy information. 3.1 proxyServerBind Controls: The proxyServerBind control allows an 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 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. 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 K. N. Vijay Expires July 2001 [Page 3] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 disconnectedMode field is FALSE (i.e. the client wishes to operate in online mode). 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 caching proxy), 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 simple authentication, and Digest authentication (section 6.1) and "simple" authentication under TLS encryption (section 6.2) as defined in [authMethods] MUST be supported by the LDAP caching proxy. In all these cases, the LDAP caching proxy SHALL use the authentication method and credentials provided by the LDAP client for authentication to the remote server. If this is the first time the LDAP client is accessing 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, the identity and the authentication information used by the LDAP client to bind to the caching proxy. The authentication information stored will not contain the actual authentication credentials but will enable the caching proxy to verify them in offline mode. (This could be in the form of a message digest or a crypto strength one-way hash of the password in case of simple authentication). 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, without contacting the remote LDAP Server. Certificate-based authentication with TLS (section 7.1 in [authMethods]) MAY also be supported by the LDAP Caching Proxy. In this case, the caching proxy 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), by setting the authorization identity to the specified user identity 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 and/or the caching proxy must contact the remote server to service the LDAP Client K. N. Vijay Expires July 2001 [Page 4] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 request. 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 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 caching proxy SHALL return unavailable in its BindResponse to the LDAP client, if there are no objects cached from the specified remote LDAP Server. Note that when operating off the caching proxy, an LDAPv3 client MUST do an explicit LDAP Bind including the proxyServerBindRequest control, even if it wishes to bind anonymously. This is necessary since the caching proxy derives the proxy specification information from the proxyServerBindRequest control to determine the origin 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), 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 K. N. Vijay Expires July 2001 [Page 5] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 status of this bind operation. The caching proxy returns the result of the LDAP client Bind Request operation in its 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. Once the caching proxy has cached objects from the origin server, it may need to setup a session with the origin server only on need basis e.g. on a cache-miss or when an update operation is attempted. In such cases, the caching proxy MAY include the proxyServerBindResponse control along with the LDAPResult message corresponding to the LDAP request that caused the caching proxy to contact the origin server. 4. LDAPv3 Control Extensions for Cache Control and Management: This section first describes the logic used by the caching proxy to cache and refresh LDAP objects from the remote LDAP server. It then identifies LDAP controls that enable an LDAP client to modify the 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 in online mode 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. All mandatory attributes of the object and optional attributes requested by the LDAP client SHALL be fetched and cached. Results returned to the client, however, will be based on the attributes and typesOnly filter specified in the search request. When the origin server is not available (as in offline mode), all search operations (including subtree and one-level) SHALL be performed off the local 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 and port number of the remote LDAP server. (Shadow servers as defined in [LDAPv3] and listed in the K. N. Vijay Expires July 2001 [Page 6] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 "AltServers" RootDSE attribute on LDAPv3 servers MAY be cached within the cache-root container. Also, the list of shadow servers MAY be used to create alias containers pointing to this container object). Under this cache-root container, entries will be cached along with the hierarchy upto the root of the naming context on the LDAP Server i.e. container objects present in the Distinguished Name of the object SHALL be cached before the leaf object itself is cached. 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 LDAP Client Update Protocol (discussed in [LCUP]) as the default mechanism to refresh cached objects. Since, the LCUP specification is still evolving, the caching proxy SHALL use the following cache refresh logic in the interim till LCUP becomes a standard and is deployed on LDAP servers. The caching proxy SHOULD schedule an unconditional refresh of all cached objects periodically (based on the caching proxy configuration policy) to ensure that cached objects are in sync with the origin server. 4.3 The LDAP Caching Proxy logic for handling Update Operations: Update operations on cached objects SHALL be 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 optionally cache all entries returned as search results. This control provides a mechanism that allows an LDAP client to request the caching proxy to cache multiple objects. 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). K. N. Vijay Expires July 2001 [Page 7] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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 SHOULD cache all entries returned by the remote LDAP Server in response to the Search request. If set to FALSE, the caching proxy SHOULD submit the search request to the origin server and return the response to the LDAP client without caching the results. 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 to the LDAP client. If the cacheResults parameter is TRUE, the caching proxy SHALL attempt to cache all entries returned by the remote server. This control SHALL be applied to the scope set by the ldap_search operation, i.e. base, one-level or 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 selectively on a single object or a set of objects. With the cacheResults field set to TRUE, the client can use the attribute filter in the Search request to sync specific attributes of an object. 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 ensure that the search results returned are those obtained directly from the remote server (and not K. N. Vijay Expires July 2001 [Page 8] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 from the cache). 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 { proxyServerSearchResult ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), 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 its SearchResultDone message. The proxyServerSearchResponse control 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. K. N. Vijay Expires July 2001 [Page 9] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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 SHOULD 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 MUST not attempt a remote update operation, when this control is present. 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 control/management. 5. Authentication and Access control to objects cached in the caching proxy: The LDAP caching proxy SHOULD use 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 on behalf of the user for the first time, it SHALL cache the object that the user has authenticated as to the origin server. As discussed in section 3.1.1, the caching proxy SHALL also store the authentication method and authentication information used by the LDAP client to bind to the caching proxy. Access to cached objects in subsequent sessions SHALL be permitted only after the user has successfully authenticated to the caching proxy 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. This however puts a restriction of the caching proxy supporting only one identity with respect to each remote LDAP 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 K. N. Vijay Expires July 2001 [Page 10] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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. The caching proxy SHALL return unwillingToPerform, if an LDAP client attempts an update operation (without the proxyServerUpdate control) in offline mode. 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 the access control model is standardized and implemented on LDAP Servers, it should be possible to permit offline updates by caching effective rights that the 'cache user identity' (the identity used by the user to cache objects from the remote LDAP Server) has to the cached objects. Future revisions of this draft will explore the possibility of supporting 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 supported 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 extended by the LDAP client to support new application specific schema extensions. 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 object from LDAPv3 servers by first performing a RootDSE search to locate the the subschema entry DN and then doing a base search on the subschema entry to retrieve the schema supported on the server. The caching proxy SHALL return a new 'cachedNamingContexts' attribute upon a RootDSE search. This attribute value SHALL include a list of LDAP servers and associated naming contexts from which objects have been cached. This allows LDAP clients to query the caching proxy and discover the LDAP servers and corresponding naming contexts from which objects have been cached. Also, the supportedSASL mechanisms RootDSE attribute on the caching proxy SHALL list the authentication methods supported by the caching proxy for proxy authentication. 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 K. N. Vijay Expires July 2001 [Page 11] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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 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 K. N. Vijay Expires July 2001 [Page 12] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 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., S.K. Natarajan, Subramaniam K. V., Tejas Iyer and Hilarie Orman for reviewing the draft and providing valuable inputs. The author also thanks LDAP-EXT Working Group members Brain Jarvis and Tim Hahn for their valuable comments on the first version of the draft. 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. 12. Author's Addresses Comments regarding this draft may be sent to the author at the following address K. N. Vijay K. N. Vijay Expires July 2001 [Page 13] INTERNET-DRAFT The LDAP Client Caching Proxy Model January 2001 Novell, Inc. 7th Mile, Hosur Road, Bangalore 560 068 India Phone: +91-80-5731858 Ext: 2002 Fax: +91-80-5731870 Email : knvijay@novell.com This Internet Draft expires July 17, 2001. K. N. Vijay Expires July 2001 [Page 14]