idnits 2.17.1 draft-williams-websec-session-continue-prob-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (January 1, 2013) is 4133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2616' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC5849' is defined on line 312, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Informational January 1, 2013 5 Expires: July 5, 2013 7 Hypertext Transport Protocol (HTTP) Session Continuation: Problem 8 Statement 9 draft-williams-websec-session-continue-prob-00 11 Abstract 13 One of the most often talked about problems in web security is 14 "cookies". Web cookies are a method of associating requests with 15 "sessions" that may have been authenticated somehow. Cookies are a 16 form of bearer token that leave much to be desired. This document 17 describes the session "continuation" problem for the HyperText 18 Transport Protocol (HTTP). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 5, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Conventions used in this document . . . . . . . . . . . . . 4 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Statelessness . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 11 64 6.2. Informative References . . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 Today most web applications use "cookies" to associate HTTP requests 70 with "sessions". A "session" is a set of related HTTP requests (and 71 responses), where the relation is to some request(s) that created the 72 session. Some sessions are created by the act of authenticating a 73 user, in which case the primary goal of "sessions" is to avoid having 74 to re-authenticate the user on every request. Other times a session 75 is created when a request is received that is not associated with any 76 session, in which case the primary purpose of "sessions" may be to 77 provide a pseudonymous identifier for an otherwise anonymous user. 78 We call the mechanisms by which requests are strung into sessions 79 "session continuation". 81 "Cookies" are server-assigned bearer tokens - nothing more, nothing 82 less, though some cookies are used just to store things like 83 "shopping cart" state. A bearer token is an octet blob which can be 84 presented as-is, possibly repeatedly, to authenticate a user to some 85 party; mere possession of the bearer token is sufficient to act on 86 the user's behalf to at least one service. As such they are 87 susceptible to theft via passive attacks (eavesdropping) if not 88 protected in some other way (e.g., by using TLS), or via active 89 attacks such as BEAST and CRIME 90 [http://www.xors.me/?attachment_id=3727], as well as to leakage in 91 various ways [XXX expand]. 93 We would like a session continuation mechanism to replace or augment 94 cookies that has better security semantics than bearer tokens. In 95 particular we would like a system that is not susceptible to theft 96 via active attacks like BEAST and CRIME. We believe that such a 97 scheme should use cryptographic algorithms and cryptographic session 98 keys, and should be amenable to being keyed by HTTP- and web- 99 authentication mechanisms. A new session continuation mechanism 100 should be suitable for use in web and non-web HTTP applications, and 101 should work even for unauthenticated sessions. 103 1.1. Motivation 105 The motivation for this document and the related session continuation 106 protocol [I-D.draft-williams-websec-session-continue-proto] document 107 is as follows. We want: 109 o A variable authentication token instead of (or in addition to) web 110 cookies, for resistance to BEAST, CRIME, and other adaptive chosen 111 plaintext active attacks on TLS. 113 o The ability to explicitly logout and destroy all session state 114 even if the session has been compromised, assuming there is no Man 115 In The Browser (MITB). 117 o The ability to manage sessions. 119 o The ability to negotiate replay protection. 121 o Cryptographic binding ("channel binding" [RFC5056]) to the lower 122 transport layer (TLS, where available). 124 o Cryptographic binding to the user authentication mechanisms (where 125 the authentication mechanism can export a secret value). 127 o The ability to use HTTP/Negotiate [RFC4559] in such a way that a) 128 new HTTP(S) connections need not result in re-authentication, b) 129 does not strobgly bind requests in a single HTTP connection to the 130 HTTP/Negotiate authentication that precedes them. 132 1.2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Requirements 140 Any session continuation scheme to replace or augment cookies must 141 provide the following functionality: 143 1. Support for authenticated and unauthenticated sessions alike. 145 2. Support for http: and https: both. 147 3. Session continuation must be possible to implement without 148 keeping state on the server side (see below), and it must be 149 possible to keep some state on the server and some on the 150 client. 152 4. Resistance to active attacks on https. [NOTE: This should 153 probably NOT be a requirement. Instead we should be happy to 154 note where a proposed protocol provides this.] 156 5. Session continuation must be expressed via HTTP headers. 158 6. Session continuation header values must be cryptographically 159 difficult for attackers to spoof, and servers must be able to 160 validate these values. 162 7. Session continuation header values used with TLS must be 163 cryptographically distinct from those used without TLS such that 164 no such values taken from HTTP requests sent without TLS can be 165 used in HTTP requests with TLS. 167 8. Session continuation must provide protection against man-in-the- 168 middle (MITM) attacks when using TLS. (This is important when 169 using anonymous Diffie-Hellman cipher suites for TLS, as well as 170 when using server certificates from low-value Public Key 171 Infrastructures (PKI). 173 9. Must support explicit session termination ("logout"), initiated 174 by either party, client or server. Once a session is logged out 175 there should be no way to use it again, even if any session keys 176 are compromised. Note that this is not a deployment 177 requirement, just a protocol requirement; a fully stateless 178 deployment may not be able to implement faithful logout. 180 10. Must work across all types of proxies. Proxies that can modify 181 the plaintext HTTP requests and responses can (but should not) 182 interfere with any session continuation protocol. 184 11. Sessions should be tied to "origins"; multi-origin sessions 185 (sharing sessions across servers) are allowed, but there are 186 user interface considerations. 188 [[anchor1: Can you move a session from one server to another? No, 189 probably not. Servers can share sessions, so we need to at least be 190 able to scope sessions to sets of servers or DNS sub-domains. This 191 appears to require that sessions have names. Once we have proper 192 session continuation we may well end up needing a mechanism by which 193 to authenticate to a service as a user of a given session on a 194 foreign service that is "friends" with the first.]] 196 Recommendations: 198 1. Session continuation SHOULD use proof-of-possession of secret 199 session key(s). 201 2. Session continuation header values SHOULD include a 202 cryptographically-secure value (indistinguishable from random) 203 that can be validated by the server and is hard for attackers to 204 guess. 206 3. Session continuation header values should be salted with a nonce 207 to defeate BEAST- and CRIME-style active attacks. 209 2.1. Statelessness 211 Session continuation protocols for HTTP MUST allow for stateless 212 implementation on the server side, at least when TLS is used. 213 Statelessness is not a requirement of deployments; implementations 214 SHOULD support both, stateful and stateless servers. This generally 215 means that any state must be encrypted and encoded into a session 216 state cookie that is re-sent by the client to the server on every 217 request. The server, of course, must be the one to assign such 218 state, and it must use an encryption key known only by the server. 220 Server-side statelessness is NOT REQUIRED in actual deployments, but 221 the ability to implement session continuation in a stateless fashion 222 on the server side is REQUIRED. 224 Note that statelessness implies that there is no way to implement 225 replay protection. In the case of session continuation with TLS this 226 is not a concern because TLS itself protects against replays. But 227 when session continuation is used without TLS then statelessness 228 really does mean that there can be no replay protection (of course, 229 this is also thus with web cookies). Therefore servers that require 230 replay protection must either require the use of TLS or must use 231 stateful sessions. 233 Note also that statelessness makes session logout a no-op on the 234 server-side, which means that a compromised session can continue to 235 be used even after a client attempts to logout. A session 236 continuation protocol MUST allow for storing some state on the 237 server, and some on the client, allowing deployments where the only 238 state stored is the existence of a session. 240 Probabilistic data structures (e.g., Bloom filters) MAY be used to 241 record logouts. This may require the ability to expire and refresh 242 sessions to render the logout system scalable. In other words, HTTP 243 responses MUST be allowed to replace session server state stored on 244 the client side. 246 3. IANA Considerations 248 This document does not specify any protocols and has no IANA 249 considerations. 251 4. Security Considerations 253 This document does not specify any protocols and is Informational. 254 There are, however, few security considerations to document here. 256 We seek to improve security on the web (as well as for non-web HTTP 257 applications) by: 259 1. reducing the need for expensive HTTP authentication exchanges 260 (e.g., HTTP/Negotiate), thereby removing an obstacle to their 261 use; 263 2. reducing exposure to session credentials theft via attacks on TLS 264 such as BEAST and CRIME; 266 3. reducing exposure to session credentials theft when not using 267 TLS; 269 4. introducing a replacement for / augmentation of cookies that will 270 give browsers a chance to pursue better security policies. 272 As discussed in Section 2.1, there is a security consideration 273 regarding session continuation without TLS and with server-side 274 statelessness: there can be no replay protection in this case. 275 However, this is not a loss of security relative to web cookies. 276 Applications must use TLS if they require integrity protection. 278 5. Acknowledgements 280 The author thanks Yaron Sheffer, Yoav Nir, and Phillip Hallam-Baker, 281 all of whom are practically co-authors, and invited to be listed as 282 such. The term "session continuation" is Phillip's. The motivation, 283 requirements and recommendations text is a group effort. 285 6. References 287 6.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 6.2. Informative References 294 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 295 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 296 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 298 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 299 Leach, P., Luotonen, A., and L. Stewart, "HTTP 300 Authentication: Basic and Digest Access Authentication", 301 RFC 2617, June 1999. 303 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 304 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 306 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 307 Channels", RFC 5056, November 2007. 309 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 310 for TLS", RFC 5929, July 2010. 312 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 313 April 2010. 315 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 316 Kerberos and NTLM HTTP Authentication in Microsoft 317 Windows", RFC 4559, June 2006. 319 [I-D.draft-williams-websec-session-continue-proto] 320 Williams, N., "Hypertext Transport Protocol (HTTP) Session 321 Continuation Protocol", 322 draft-williams-websec-session-continue-proto-00 (work in 323 progress), January 2013. 325 Author's Address 327 Nicolas Williams 328 Cryptonector, LLC 330 Email: nico@cryptonector.com