idnits 2.17.1 draft-nottingham-http-auth-cache-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2002) is 8100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (ref. '3') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 21, 2002 4 Expires: August 22, 2002 6 HTTP Authentication Credential Caching Extension 7 draft-nottingham-http-auth-cache-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 22, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This note proposes an HTTP cache-control extension mechanism that 39 allows caching of authentication credentials, thereby allowing 40 authenticated resources to be served from cache without incurring the 41 cost of a round-trip to the origin server more than once during the 42 freshness lifetime of the credentials. 44 1. Introduction 46 HTTP [2] allows messages which are subject to authentication (such as 47 that defined by RFC2617 [3]) to be cached when certain directives are 48 present. In particular, Section 14.8 of RFC2616 says: 50 When a shared cache (see section 13.7) receives a request 51 containing an Authorization field, it MUST NOT return the 52 corresponding response as a reply to any other request, unless 53 one of the following specific exceptions holds: 55 1. If the response includes the s-maxage cache-control 56 directive, the cache MAY use that response in replying to a 57 subsequent request. But (if the specified maximum age has 58 passed) a proxy cache MUST first revalidate it with the 59 origin server, using the request-headers from the new 60 request to allow the origin server to authenticate the new 61 request. (This is the defined behavior for s-maxage.) If 62 the response includes s-maxage= 0 , the proxy MUST always 63 revalidate it before re-using it. 65 2. If the response includes the must-revalidate cache-control 66 directive, the cache MAY use that response in replying to a 67 subsequent request. But if the response is stale, all 68 caches MUST first revalidate it with the origin server, 69 using the request-headers from the new request to allow the 70 origin server to authenticate the new request. 72 3. If the response includes the public cache-control 73 directive, it MAY be returned in reply to any subsequent 74 request. 76 The most useful approach here is that described in the end of #1, 77 whereby a cache keeps the response, but revalidates new requests 78 before serving it (Note that this can also be effected by use of a 79 combination of the 'public' and 'max-age' cache-control directives). 81 This is useful for caching large representations (e.g., distributed 82 binary programs, PDF files); the efficiency of the cache hit offsets 83 the cost of going back to the origin server to authenticate the 84 request. It is less useful for caching of smaller representations 85 (such as images or HTML pages), because the efficiency gained from 86 the cache does not overcome the latency introduced by the round trip 87 to the origin server. 89 This note proposes an HTTP cache-control extension directive that 90 allows caching of authentication credentials, thereby allowing 91 authenticated resources to be served from cache without incurring the 92 cost of a round-trip to the origin server more than once during the 93 freshness lifetime of the credentials. 95 Please direct comments to the HTTP-WG mailing list, http- 96 wg@cuckoo.hpl.hp.com. 98 1.1 Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [1]. 104 An implementation is not compliant if it fails to satisfy one or more 105 of the MUST or REQUIRED level requirements. An implementation that 106 satisfies all the MUST or REQUIRED level and all the SHOULD level 107 requirements is said to be "unconditionally compliant"; one that 108 satisfies all the MUST level requirements but not all the SHOULD 109 level requirements is said to be "conditionally compliant". 111 2. The Auth-Cache Cache-Control Extension Directive 113 The auth-realm cache-control directive allows caches to serve an 114 authenticated response without validation on the origin server under 115 controlled conditions. 117 auth-cache = "auth-cache" [ "=" delta-seconds ] 119 When a shared cache receives a request containing an Authorization 120 field, it MAY return the corresponding response as a reply to a 121 subsequent request, if all of the following conditions hold; 123 1. The auth-cache cache-control extension is present in the (cached) 124 response. 126 2. The cached response credentials' realm matches that presented in 127 the request, and the cached response and the Request-URI have the 128 same canonical root URL (as defined by RFC2617, Section 1.2). 130 3. The presented credentials match the stored authentication state. 132 4. The response is fresh, according to its normal (non- 133 authenticated) HTTP freshness lifetime. 135 5. The cached credentials are fresh, as outlined below. 137 By default, the freshness lifetime of the stored credentials is equal 138 to that of the cached response. However, if the auth-cache directive 139 includes a value, it is interpreted as the cached credentials' 140 freshness lifetime. 142 Implementations MUST generate 401 Authentication Required HTTP 143 responses and WWW-Authenticate headers when requests for such 144 resources do not present appropriate credentials. 146 3. Example 148 For example, if a shared cache contains a response for the URI http:/ 149 /www.example.org/resource which includes the following response 150 headers: 152 Cache-Control: max-age=86400, auth-cache 153 WWW-Authenticate: Basic realm="WallyWorld" 155 This cached response can be served without validation, if: 157 o the request includes credentials that are valid for http:// 158 www.example.org 160 o the request includes credentials with the realm 'WallyWorld' 162 o the credentials have been validated on the origin server in the 163 last day 165 o the response is fresh (i.e., has been validated on or directly 166 fetched from the origin server in the last day) 168 Note that the cached credentials may have been associated with a 169 different resource (e.g., http://www.example.org/Another/resource). 171 If the auth-cache directive included a value, for example: 173 Cache-Control: max-age=86400, auth-cache=3600 174 WWW-Authenticate: Basic realm="WallyWorld" 176 the same constraints would apply, except that the cached credentials 177 would need to be one hour or fresher. 179 4. Security Considerations 181 Authentication caching is vulnerable in the same ways as normal HTTP 182 authentication (as explained in RFC2616 and RFC2617), with the added 183 risk inherent in delegating authority for authentication to another 184 device or administrative domain, as applicable. 186 Additionally, the use of cached credentials introduces the 187 possibility of a replay attack, sometimes in cases where there may 188 not have been such a risk previously. In particular, cached 189 credentials SHOULD NOT be used in conjunction with Digest 190 authentication, as doing so seriously weakens its security. 192 It should be noted that if the auth-cache directive is implemented by 193 multiple devices in a chain of caches (e.g., hierarchical caching 194 proxies), the cached credentials in some caches may in fact be older 195 than the specified freshness lifetime. This issue may be addressed 196 in future revisions of this note. 198 References 200 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 201 Levels", RFC 2119, March 1997. 203 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 204 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - 205 HTTP/1.1", RFC 2616, June 1999. 207 [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 208 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 209 Basic and Digest Access Authentication", RFC 2617, June 1999. 211 Author's Address 213 Mark Nottingham 215 EMail: mnot@pobox.com 216 URI: http://www.mnot.net/ 218 Full Copyright Statement 220 Copyright (C) The Internet Society (2002). All Rights Reserved. 222 This document and translations of it may be copied and furnished to 223 others, and derivative works that comment on or otherwise explain it 224 or assist in its implementation may be prepared, copied, published 225 and distributed, in whole or in part, without restriction of any 226 kind, provided that the above copyright notice and this paragraph are 227 included on all such copies and derivative works. However, this 228 document itself may not be modified in any way, such as by removing 229 the copyright notice or references to the Internet Society or other 230 Internet organizations, except as needed for the purpose of 231 developing Internet standards in which case the procedures for 232 copyrights defined in the Internet Standards process must be 233 followed, or as required to translate it into languages other than 234 English. 236 The limited permissions granted above are perpetual and will not be 237 revoked by the Internet Society or its successors or assigns. 239 This document and the information contained herein is provided on an 240 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 241 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 242 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 243 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 244 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 Acknowledgement 248 Funding for the RFC Editor function is currently provided by the 249 Internet Society.