Network Working Group Y. Pettersen Internet-Draft Opera Software ASA Updates: 2616 (if approved) March 6, 2012 Intended status: Standards Track Expires: September 7, 2012 A context mechanism for controlling caching of HTTP responses draft-pettersen-cache-context-06 Abstract A common problem for sensitive web services is informing the client, in a reliable fashion, when a password protected resource is no longer valid because the user is logged out of the service. This is, in particular, considered a potential security problem by some sensitive services, such as online banking, when the user navigates the client's history list, which is supposed to display the resource as it was when it was loaded, not as it is the time the user navigates to it. This document presents a method for collecting such sensitive resources into a group, called a "Cache Context", which permits the server to invalidate all the resources belonging in the group either by direct action, or according to some expiration policy. The context can be configured to invalidate not just the resources, but also specific cookies, HTTP authentication credentials and HTTP over TLS session information. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Pettersen Expires September 7, 2012 [Page 1] Internet-Draft HTTP Cache Context March 2012 material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Pettersen Expires September 7, 2012 [Page 2] Internet-Draft HTTP Cache Context March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. How Cache Contexts work . . . . . . . . . . . . . . . . . . . 5 2.1. What is a Cache Context? . . . . . . . . . . . . . . . . . 5 2.2. Life of a Cache Context . . . . . . . . . . . . . . . . . 6 2.3. What happens when a context is discarded? . . . . . . . . 7 2.4. Server role . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Client role . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Effects on clients that do not support Cache Contexts . . 8 3. Context Specification Syntax . . . . . . . . . . . . . . . . . 8 3.1. ABNF syntax . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Context directive . . . . . . . . . . . . . . . . . . . . 9 3.3. Discard-Context directive . . . . . . . . . . . . . . . . 11 3.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. No expiration . . . . . . . . . . . . . . . . . . . . . . 11 4.2. With expiration . . . . . . . . . . . . . . . . . . . . . 12 4.3. With server-only cookie . . . . . . . . . . . . . . . . . 13 4.4. With cookiedomain . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Pettersen Expires September 7, 2012 [Page 3] Internet-Draft HTTP Cache Context March 2012 1. Introduction An early problem seen with HTTP was that, since it is inherently stateless, there is no direct way to tell that two separate requests are related, in particular that the requests originated from the same user. While it is possible to encode the information in URLs or queries, these methods are difficult to secure and it is also difficult to maintain that information. Finally, much of the problem was solved by the introduction of HTTP Cookies [RFC6265] and the HTTP Authentication methods [RFC2617]. One problem remains, though: History list navigation and access to temporarily cached resources in web applications handling sensitive data, such as online banking. The user may have logged out of the service, or have been logged out automatically, and it is therefore difficult for the client to tell whether to display a given resource, not display it, or display it only after revalidating. A typical use case will be that Alice goes to her online banking site, checks her accounts, performs a couple of transactions and, then, logs out of the bank. The bank might want to permit Alice to navigate in her browser's history session while she is logged in, for example, to recheck how much money is available in her account, but prevent her from seeing any such information after she has logged out. The reason is that, if she forgets to close her session (after logging out) and then leaves her computer for a minute, Eve might sneak over to peek at her colleague's account information by navigating the history list in Alice's client. Some providers of sensitive web services, for example banks, consider failure to revalidate when displaying a cached document, or during history navigation, a security problem. Some of these providers have put great efforts into making sure the client is always revalidating a page before displaying it, even while navigating history (which is quite the opposite of what [RFC2616] sec. 13.13 recommends). This has led to numerous strategies, such as the use of scripting and using the "must-revalidate" Cache-Control directive as a revalidate indication for history navigation. Use of most of these methods not only results in more traffic to the websites, but may also reduce the usability of the service. For example, such methods may prevent a user from reviewing, or correcting, data entered or presented earlier in the process, or to print or save data presented earlier (for example, a receipt), because the document is re-rendered differently. While it is possible to use cookies and credential information to Pettersen Expires September 7, 2012 [Page 4] Internet-Draft HTTP Cache Context March 2012 group such documents, these methods are not fine-grained enough to distinguish the sensitive parts of a site from the non-sensitive parts. That kind of information is only available to the service manager, and potentially the user, but not to the client. This document presents a mechanism that permits a webservice to group webpages by associating them in a named context, a "Cache Context", that can have a specific expiration time or be specifically discarded by the service. When a context is expired, or discarded, this expires all documents that the client has that are part of the context, meaning that they should either be deleted from the client's cache or revalidated before being displayed to the user. The mechanism is implemented as an extension to the HTTP Cache- Control Header, but will also require access to state information about HTTP Cookies and various forms of authentication credentials, such as HTTP Authentication credentials and SSL Client Certificate session states. 1.1. Terminology HTTP Resource: A resource loaded from a HTTP [RFC2616] or HTTP over TLS (HTTPS) [RFC2818] server 2. How Cache Contexts work 2.1. What is a Cache Context? A Cache Context is a group of HTTP resources served from a specific HTTP server, or group of HTTP servers, that are associated with a name unique on that server, or within that group of servers. The same name used from a different server, or a server that is not part of the group, becomes a different context. Any given server can use multiple contexts. An HTTP resource from a server for which a context is defined does not become part of the context unless the server explicitly informs the client that it is a member of that context. Such a group of resources may, for example, consist of all the sensitive and password protected pages in a netbank web application, but none of the images used when displaying the information. A context may also just contain a group of temporary documents that are not intended to be persistently cached. A Cache Context can be created with policies that define when it is to be discarded, and what actions it should then take, aside from Pettersen Expires September 7, 2012 [Page 5] Internet-Draft HTTP Cache Context March 2012 invalidating all the resources that are part of the context. Such extra actions may include deleting or invalidating cookies, HTTP authentication credentials or SSL session information. 2.2. Life of a Cache Context The Cache Context enters existence the first time the server sends a directive that informs the client about the context, and what boundaries the context has. Resources are added to the context each time the server sends a new resource with a directive specifying that it is part of the context. The server (or servers) that can serve resources in a context are either the server defining the context (this is the default), or the initial server can specify that the context spans the same group of servers that will receive a specific HTTP cookie [RFC6265]. HTTP cookies can be set by servers to only be returned by the client to the server that sent them, or to be sent to all servers within the domain which the sending server belongs to (there are some security related restrictions to how extensive such domains can be). For example, when Alice logs into her online bank, the server tells her client that the "onlinebanking" context has been created, and, for each successive action she makes to display her account statements and filling in forms with payment information, the server informs the client that the resulting pages are also part of the "onlinebanking" context. This continues until the context is discarded, an event that can come about as a result of several conditions: o Alice logs out of her online bank, and the server sends a "Discard Context" notice to the client. o The server has specified how long the context may live, and, when the limit expires, the context is automatically discarded. o The server can also tie the context to an HTTP State Management cookie[RFC6265], and when this cookie expires, the context is also automatically discarded. o The client SHOULD offer the user the possibility to discard a context in the form of a logout button. o The client is shut down. Pettersen Expires September 7, 2012 [Page 6] Internet-Draft HTTP Cache Context March 2012 2.3. What happens when a context is discarded? When a context is discarded, the resources that are part of the context are deleted or marked for deletion (e.g., if they cannot be deleted immediately due to internal book-keeping). When a resource is marked for deletion, its status in the client's cache will be as if it had been received with max-age set to 0 (zero); that is, it has expired and cannot be displayed to the user unless its freshness has been confirmed by the server after a validation request. This also applies to such documents that would be displayed after the user navigated in the browser's history. Preferably, the resource SHOULD NOT be used if the client requests the same URI as that of the resource, even conditionally, after the context has been discarded, except during history list navigation. If the context is associated with an HTTP cookie, discarding the context also causes the client to automatically discard the cookie. The server can also specify that when a context is discarded, stored credentials that are valid for the server(s) that the context spans should also be deleted. Such credentials should include, but should not be limited to, HTTP Authentication credentials and SSL Session information. Credentials stored in a client's password management utility MUST NOT be discarded during this process. Resources gathered in a context MUST NOT be kept persistently cached by the client, but MUST be discarded when it shuts down, even if the context is still valid. Please note that this does not prevent a client from storing the resource on a disk drive for the duration. If a server wants to prevent a resource from being stored on a disk drive it MUST indicate this request with the "no-store" Cache-Control directive. A resource served with an explicit discard context instruction from the server is not part of the context and MUST NOT be invalidated, and the server SHOULD NOT include sensitive information in such resources. 2.4. Server role A service that wants to use Cache Contexts must update the HTTP Cache-Control headers sent by each of the resources it wants to make part of the context. Only the entry point(s) into the service will need to send a directive with expiration details and other advanced information, all other resources need only send a directive specifying the name of the context. When a service has exit points, such as a logout button, these Pettersen Expires September 7, 2012 [Page 7] Internet-Draft HTTP Cache Context March 2012 special resources should send a special directive informing supporting clients that they must discard the context. A server MAY send updated Cache Context directives to the client, and need not resend unchanged attributes in such updates. 2.5. Client role The client will parse the Cache-Control headers, and when it recognizes the Cache Context directives it will take one of several actions: o Create the context as defined, if it does not already exist. o If the server sends updated attributes for the context, update the relevant attributes without changing other attributes. o Add the resource to the context, unless the context is being discarded as a result of the current directive. o If the directive specifies that the context must be discarded immediately, the client MUST proceed to invalidate all the resources contained in the context, as specified above. The client MUST maintain a list of active contexts for each server or group of servers, their policies and which resources are associated with them. A server MAY specify that a resource belongs in two different contexts by sending two directives in the same response. In such cases the resource MUST be invalidated when the first context is discarded. 2.6. Effects on clients that do not support Cache Contexts All the information about the Cache Contexts and actions on them are contained in new HTTP Cache-Control directives. Clients that do not recognize these directives will ignore them. They will follow the Cache-Control directives they recognize, and otherwise act as they would if the Cache Contexts did not exist. 3. Context Specification Syntax Pettersen Expires September 7, 2012 [Page 8] Internet-Draft HTTP Cache Context March 2012 3.1. ABNF syntax This ABNF has the same syntax as is used in [RFC2616], with the addition of Incremental Alternatives from [RFC5234] section 3.3. This syntax expands the cache-response-directive part of the Cache- Control header ABNF in RFC 2616 sec. 14.9. cache-response-directives =/ "context" "=" context-name *[ ";" context-attributes] | "discard-context" "=" context-name *[; context-name] context-name = token context-attributes = "max-age" ":" delta-seconds | "max-idle" ":" delta-seconds | "cookie" ":" token | "authenticated" | "include-credentials" | "no-persistent-history" | extension-attributes extension-attributes = token [":" token] delta-seconds = 1*DIGIT 3.2. Context directive The Context directive MUST be included with every response that is included in a context. It always starts with a context-name, which MUST be unique within the given service. The context-name, which is case-insensitive, is the only required field in the directive. All other attributes are optional, and need only be specified when the attribute is updated. By default, a given context on one server is not associated with a context by the same name for another server, but if a group of servers share a common HTTP cookie, they can participate in a common context by using the same name. Additionally, the directive may contain one or more context- attributes that specify how the context as well as additional information should be handled by the client. These attributes need not be sent with every response, but when an attribute is sent with a later response, it will update the context with the new information, and any previous information for that attribute will be overwritten. Pettersen Expires September 7, 2012 [Page 9] Internet-Draft HTTP Cache Context March 2012 max-age This attribute indicates how many seconds the context should be kept alive. A value of zero (0) means that the context should be discarded immediately. A server may send this directive to extend the lifetime of the context, e.g when the context nears the end of its lifetime. If this attribute is not defined, the context may live until the client is shut down, or a discard event is received by the client. max-idle This attribute indicates how many seconds the context should be kept alive after the last time a resource in the context was accessed. If this attribute is not defined, or the value is zero (0), the context may live until the client is shut down, or a discard event is received by the client. cookie This attribute names the most specific HTTP State Management Cookie [RFC6265] visible to the resource sending when this attribute is received by the client. Cookies received and accepted in the current response MAY be considered as part of evaluating this attribute. The named cookie is used for three purposes. First, its expiration date also becomes one of the expiration dates of the context (an earlier max-age or max-idle takes precedence), and if the server deletes the cookie, it automatically deletes the context as well. Second, if a cookie is valid across multiple hosts (that is, a domain), the given context is also valid across the same hosts. Third, if the context expires or is discarded before the cookie expires, the named cookie MUST also be deleted when the context is discarded. Multiple cookies may be defined by the server. By default, the context is not assiciated with a cookie. authenticated This attribute specifies that the context shall be valid across the domain of the HTTP authentication credential currently valid for the resource. The domain MUST at least include the entire server, but multiple hosts may be included if it is supported by the authentication mechanism, as for example Digest Authentication [RFC2617] do. When the context is discarded, the authentication credential is also discarded. If the credential is invalidated or destroyed, the context must also be discarded. By default, the context is not associated with an authentication credential. include-credentials This attribute informs the client that when this context is discarded it MUST also destroy all HTTP Authorization credentials, SSL/TLS Client Certificate authenticated sessions, and other credentials that are valid for the resources that are part of the context, thus logging the user out of the service. By default, credentials are not included when discarding a context. Pettersen Expires September 7, 2012 [Page 10] Internet-Draft HTTP Cache Context March 2012 no-persistent-history This attribute informs the client that it SHOULD NOT remember resources that are part of this context as part of a persistent history mechanism. That is, the client SHOULD maintain a history list in the document window or "tab" viewed by the user (as described in [RFC2616] Section 13.13) , but it SHOULD NOT keep any information about the URLs visited for a persistent browsing history. By default, the client MAY remember the used resources as part of a persistent history mechanism. delta-seconds All periods used in the Cache Context attributes are measured in seconds. 3.3. Discard-Context directive A server can send this directive when it wants the client to immediately discard the named context(s) (which includes the extra actions specified in Section 2.3 when specified for the context). Multiple context names separated by ";" can be specified in a single directive, or multiple directives can be used. 3.4. Extensions Extension attribute names SHOULD be documented in an RFC. 4. Examples 4.1. No expiration Pettersen Expires September 7, 2012 [Page 11] Internet-Draft HTTP Cache Context March 2012 Request-URI: http://www.example.com/initial_page Response: Cache-Control: context=simplecontext Request-URI: http://www.example.com/page2 Response: Cache-Control: context=simplecontext Request-URI: http://www.example.com/page3 Response: Cache-Control: context=simplecontext Request-URI: http://www.example.com/page4 Response: Cache-Control: max-age=3600 Request-URI: http://www.example.com/final_page Response: Cache-Control: discard-context=simplecontext This example loads 3 resources, "initial_page", "page2" and "page3", as part of the Cache Context "simplecontext". By default, this context lives until the client is shut down. In this case, however, the context is discarded by the response to the request for "final_page". After the context has been discarded, all future attempts to view "initial_page", "page2" or "page3" will result in an "If-Modified-Since" validation request to the server, or a completely new request, because the responses are no longer valid. "Page4" is not part of the context, and is not discarded by the "final_page" action, and no "If-Modified-Since" request will be sent for this resource until 3600 seconds (1 hour) after it was originally loaded. 4.2. With expiration Pettersen Expires September 7, 2012 [Page 12] Internet-Draft HTTP Cache Context March 2012 Request-URI: http://www.example.com/initial_page Response: Cache-Control: context=expirecontext;max-age=900 Request-URI: http://www.example.com/page2 Response: Cache-Control: context=expirecontext Request-URI: http://www.example.com/page3 Response: Cache-Control: context=expirecontext This example loads 3 resources, "initial_page", "page2" and "page3", as part of the Cache Context "expirecontext". By default, this context lives for at most 15 minutes (900 seconds). After the context has been discarded (in this case, after 15 minutes), all future attempts to view "initial_page", "page2" or "page3" will result in an "If-Modified-Since" validation request to the server, or a completely new request, because the responses are no longer valid. 4.3. With server-only cookie Pettersen Expires September 7, 2012 [Page 13] Internet-Draft HTTP Cache Context March 2012 Defined cookie (server only): ExampleSession=UserId; max-age=900; domain=www.example.com Request-URI: http://www.example.com/initial_page Response: Cache-Control: context=cookiecontext;cookie=ExampleSession Request-URI: http://www.example.com/page2 Response: Cache-Control: context=cookiecontext Request-URI: http://www.example.com/page3 Response: Cache-Control: context=cookiecontext Request-URI: http://www.example.com/final_page Response: Cache-Control: discard-context=cookiecontext This example loads 3 resources, "initial_page", "page2" and "page3", as part of the Cache Context "cookiecontext" which is associated with the cookie "ExampleSession". By default, this context lives until the cookie expires 15 minutes (900 seconds) after it was set. In this case, however, the context is discarded by the response to the request for "final_page". After the context has been discarded, the cookie "ExampleSession" no longer exists even if it was not yet expired, and all future attempts to view "initial_page", "page2" or "page3" will result in an "If-Modified-Since" validation request to the server, or a completely new request, because the responses are no longer valid. 4.4. With cookiedomain Pettersen Expires September 7, 2012 [Page 14] Internet-Draft HTTP Cache Context March 2012 Defined cookie: ExampleDomainSession=UserId; max-age=900; domain=.example.com Request-URI: http://www.example.com/initial_page Response: Cache-Control: context=domaincontext;cookie=ExampleSession Request-URI: http://server2.example.com/page2 Response: Cache-Control: context=domaincontext Request-URI: http://server3.example.com/page3 Response: Cache-Control: context=domaincontext Request-URI: http://final.example.com/final_page Response: Cache-Control: discard-context=domaincontext This example loads 3 resources, "initial_page", "page2" and "page3" from different servers, as part of the Cache Context "domaincontext" which is associated with the cookie "ExampleDomainSession" which is sent to the entire example.com domain. This causes "domaincontext" to apply to all servers in the example.com domain, too. By default, this context lives until the cookie expires 15 minutes (900 seconds) after it was set. In this case, however, the context is discarded by the response to the request for "final_page". After the context has been discarded, the cookie "ExampleDomainSession" no longer exists even if it was not yet expired, and all future attempts to view "initial_page", "page2" or "page3" will result in an "If-Modified- Since" validation request to the server, or a completely new request, because the responses are no longer valid. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Pettersen Expires September 7, 2012 [Page 15] Internet-Draft HTTP Cache Context March 2012 6. Security Considerations If two independent web applications that use the same name for their contexts are hosted on the same server, or within the domain covered by one or both of the contexts, they are likely to interfere with each other. This can happen if the user uses both applications while both contexts are valid, possibly causing some loss of functionality and information if a context is discarded, or prolonged exposure of information if the session is extended. Such interference can only be avoided by choosing context names that are not shared among independent web applications. When using the Cookie attribute, which expands the context to a cookie's domain, this specification relies on the same security safeguards that are used by the client when accepting the cookie in order to avoid interfering with web applications in other services that are using the same context name. Given the wide variety of domain name hierarchies used by TLD administrators, it is presently possible, unless prevented by client specific heuristics, for a server to share a cookie with all servers within a registry-like part of a TLD, such as the "co.uk" Domain Name hierarchy. This kind of interference may also occur within smaller domain name segments. A possible method to avoid or limit such interference could be to require clients to perform an evaluation of the context directive's cookie specification from the resource's environment, which might associate it with a different cookie. Such an evaluation would most likely result in undesirable processing overhead, and is therefore not included in this specification. 7. References 7.1. Informative References [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 7.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Pettersen Expires September 7, 2012 [Page 16] Internet-Draft HTTP Cache Context March 2012 Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. Appendix A. Open Issues Should the client indicate support for Cache Contexts? Is it necessary to do so? If so, how should support be indicated? A possiblity is an HTTP header with a directive indicating support. Should the client indicate that it has accepted a particular context and is using it? If so, how should it indicate it? Possible solution: The above mentioned header directive could contain a list of active contexts. Should the client, when automatically discarding a context, replace the viewed document with a "you have been logged out of the service" document? Or should the last viewed page continue to be displayed? If the document is replaced, how should this situation be handled when a server specifies an unreasonably short expiration time? How should a client interpret non-context Cache-Control directives in the same header? Given that such directives are likely intended to place more restrictive non-context expiration policies on the resource than is necessary for clients that do support Cache Contexts, the best solution may be that clients supporting Cache Contexts should ignore at least the "no-cache", "max-age=0" and "must-revalidate" directives for resources that are part of a context, all of which are implied when the cache-context is discarded. How should responses to requests using methods that have side effects, such as POST, be handled after a context has been discarded? Such responses should most likely not be revalidated automatically. The best option may be to require the client to replace the resource with an information message about the resource not being available anymore. Pettersen Expires September 7, 2012 [Page 17] Internet-Draft HTTP Cache Context March 2012 Author's Address Yngve N. Pettersen Opera Software ASA Waldemar Thranes gate 98 N-0175 OSLO, Norway Email: yngve@opera.com Pettersen Expires September 7, 2012 [Page 18]