idnits 2.17.1 draft-williams-websec-session-continue-proto-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 document date (January 1, 2013) is 4131 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) == Unused Reference: 'RFC5246' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC5849' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-v2' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-httpintegrity' is defined on line 541, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational draft: draft-williams-websec-session-continue-prob (ref. 'I-D.williams-websec-session-continue-prob') -- 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 5849 (Obsoleted by RFC 6749) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: Standards Track January 1, 2013 5 Expires: July 5, 2013 7 Hypertext Transport Protocol (HTTP) Session Continuation Protocol 8 draft-williams-websec-session-continue-proto-00 10 Abstract 12 One of the most often talked about problems in web security is 13 "cookies". Web cookies are a method of associating requests with 14 "sessions" that may have been authenticated somehow. Cookies are a 15 form of bearer token that leave much to be desired. This document 16 proposes a session "continuation" protocol for HyperText Transport 17 Protocol (HTTP). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 5, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Session Keying . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Mixing HTTP and HTTPS . . . . . . . . . . . . . . . . . . 4 57 2.2. Authenticated Session Keying . . . . . . . . . . . . . . . 4 58 2.2.1. HTTP/Negotiate Session Keying . . . . . . . . . . . . . . 5 59 2.2.2. Digest . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Unauthenticated Session Keying . . . . . . . . . . . . . . 5 61 3. Session Initiation . . . . . . . . . . . . . . . . . . . . 6 62 4. Session Scope: Sharing Sessions Across Servers . . . . . . 9 63 5. Unauthenticated to Authenticated Session Upgrade . . . . . 10 64 6. Session Continuation . . . . . . . . . . . . . . . . . . . 11 65 6.1. Session Validation and Error Handling . . . . . . . . . . 11 66 6.2. Session Expiration and Renewal . . . . . . . . . . . . . . 12 67 6.3. Alternative: Define Session Scheme for WWW-Authenticate . 12 68 7. Logout . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. Inquiring Session Status . . . . . . . . . . . . . . . . . 14 70 9. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 16 72 11. Security Considerations . . . . . . . . . . . . . . . . . 17 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . 18 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 The motivation for this protocol is described in 81 [I-D.williams-websec-session-continue-prob]. 83 We define a protocol for cryptographic "session continuation" for 84 HyperText Transport Protocol (HTTP) [RFC2616]. Session continuation 85 is the act of binding an HTTP request to a "session". A "session" 86 consists of all the HTTP requests by a given user (possibly an 87 authenticated user, or possibly an anonymous user). This protocol is 88 a cryptographic protocol that aims to meet all the requirements given 89 in [I-D.williams-websec-session-continue-prob]. 91 The protocol consists of: 93 o a request header carrying a keyed Message Authentication Code 94 (MAC) that proves possession of a shared session key (shared 95 between the user and the server); 97 o a response header advertising a default session scope to clients; 99 o a session identification in the form of a URI; 101 o an optional facility for server-side statelessness by storing 102 state on the client-side, encrypted in a secret key known to the 103 server; 105 o a request header for requesting the establishment of a session; 107 o a response header for indicating the establishment of a session, 108 and including a session URI and any optional state to be repeated 109 by the client. 111 1.1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Session Keying 119 There are two methods for keying an HTTP session: 121 o session keys are output by HTTP authentication; 123 o or session keys are asserted by the client or the server; 125 For the key assertion method TLS with confidentiality protection is 126 clearly REQUIRED for security. We've considered the possibility of 127 using Diffie-Hellman key agreement or RSA key transport, but as that 128 would duplicate functionality that is in TLS we consider that out of 129 scope for the time being. 131 In either case a single session key is produced, and that is the only 132 key utilized. Having a single key helps reduce session state size 133 and protocol complexity, but we must (and do) distinguish key usage 134 by prefixing a purpose indicator to the MAC input. 136 When keys are output by HTTP authentication there may be a key length 137 mismatch. In this case a Key Derivation Function (KDF) [RFC5869] is 138 applied to generate the session key. 140 [[anchor1: We could also use the TLS extractor to generate keys, but 141 that would be an unnecessary complication and would provide very 142 little additional value. Channel binding is achieved per-RFCs 5056 143 and 5929.]] 145 [[anchor2: Should we have distinct session keys for request and 146 response MACs? Probably, but it increases state size. Better to add 147 a direction indicator to the MAC plaintext.]] 149 2.1. Mixing HTTP and HTTPS 151 We expect that many sites will continue to mix HTTP and HTTPS for 152 various reasons. To make this possible the MAC input will include a 153 marker indicating HTTP or HTTPS. 155 2.2. Authenticated Session Keying 157 When an HTTP client uses HTTP authentication, and the authentication 158 mechanism used can establish a session key, then the client SHOULD 159 request session initiation using a shared session key output by the 160 HTTP authentication mechanism. The client MUST send the session 161 initiation header concurrently with the last HTTP authentication 162 message. 164 2.2.1. HTTP/Negotiate Session Keying 166 [[anchor3: Write text explaining how to use the GSS PRF to exchange 167 keys when using HTTP/Negotiate]] 169 2.2.2. Digest 171 [[anchor4: Digest could output a session key. Do we want to bother? 172 (Basic certainly can't, or we'd not want it to anyways.)]] 174 2.3. Unauthenticated Session Keying 176 Sessions for unauthenticated users may appear to make little sense at 177 first. This is useful, for example, and just as web cookies are, for 178 tracking "shopping carts" when a user is window shopping, so to 179 speak. 181 For unauthenticated session initiation the client merely requests the 182 creation of a session with an asserted session key, for lack of a 183 better choice. 185 3. Session Initiation 187 Sessions are always initiated by the client by including a Session- 188 Init header in the client's request carrying the client's proposal 189 for a session. 191 Servers that support sessions will respond by creating a session and 192 returning a session ID URI. 194 The Session-Init proposal header's value consists of a comma- 195 separated list of proposal parameters: 197 session-param = token "=" ( token | quoted-string ) 198 Session-Init = 1#session-param 200 Figure 1: Session-Init request header 202 The following session parameters are defined: 204 Key-Method The type of keying: "auth" (key will be output by HTTP 205 authentication), "c-assert" (key is asserted in this Session-Init) 206 or "s-assert" (the server is expected to assert a key). In the 207 "auth" case the Session-Init MUST also carry a nonce and a MAC. 208 This session-param MUST be present. 210 Key The key that the client asserts, if the client asserts a key 211 (Key-Method=c-assert). This may also be included when Key-Method 212 is "auth" in case the server's implementation of HTTP 213 authentication does not output a key, but only when using HTTPS. 215 Key-Length The length of the master session key, as a count of key 216 bits, in base-10. The value MUST NOT be less than 96 or larger 217 than 256. If absent the key length SHALL be 128 bits. 219 MAC-Algs The MAC algorithms supported by the client. This document 220 defines only "HMAC-SHA-1" (HMAC with SHA-1), "HMAC-SHA-1-96" (HMAC 221 with SHA-1 and truncation to 96 bits), "HMAC-SHA256" (HMAC with 222 SHA256), and "HMAC-SHA256-128" (HMAC with SHA256 and truncation to 223 128 bits). All of these use HMAC [RFC2104]. Clients and servers 224 MUST support HMAC-SHA-1-96 and HMAC-SHA256-128. If absent the 225 default value is "HMAC-SHA256-128". 227 KDF-Algs A list of KDF algorithms. This is needed only when Key- 228 Method is "auth". The following are specified here: "HKDF-SHA-1" 229 (HKDF [RFC5869] with SHA-1) and "HKDF-SHA256" (HKDF with SHA256). 230 Clients and servers MUST support HKDF-SHA256. If absent and Key- 231 Method is "auth" then the default value is HKDF-SHA256. 233 Channel-Binding-Types A comma-separated list of channel binding 234 [RFC5056] types. Clients and servers MUST support 'tls-server- 235 end-point' [RFC5929] when using HTTPS. (Note the need to use 236 quoted-string when the list has more than one item.) If absent 237 the default is 'tls-server-end-point'. 239 Nonce A 128-bit nonce, base64-encoded. This session-param MUST be 240 present. 242 Previous-Session-URI The URI of a previous session. See Section 5. 244 Previous-Session-State The session state for the previous session, 245 if any. See Section 5. 247 Unprotected-Allowed If present the value MUST be "true", and 248 indicates that HTTP and HTTPS are both allowed for this session. 249 Otherwise only HTTPS is allowed for this session. 251 The server responds with a Session-Assign header: 253 session-params = 1#session-param 254 Session-Init-Value = 255 MAC-input = Session-Init-Value "," session-params 256 MAC = 257 Session-Assign = session-params ["," MAC] 259 Figure 2: Session-Assign response header 261 The MAC is OPTIONAL when using HTTPS, REQUIRED otherwise. 263 The session-params for Session-Assign are: 265 Key-Method If the client requested "auth" as the key method but the 266 server's implementation of HTTP authentication could not output a 267 key then this session-param MUST be present with a value of 268 "c-assert" (if the client included a Key in its Session-Init) or 269 "s-assert" (otherwise). 271 Key The server-asserted key, if the client requested a server- 272 asserted key. 274 MAC-Alg The name of the MAC algorithm selected by the server from 275 the client's proposal (REQUIRED). 277 KDF-Alg The selected KDF algorithm (when the client's selected Key- 278 Method is "auth"). 280 URI The URI of the session (REQUIRED). 282 State Server-side state to be stored on the client (OPTIONAL). Note 283 that servers MAY choose to store server-side state in cookies 284 instead. 286 Previous-Session Indicates whether the previous session was 287 recognized and accepted ("accepted"), rejected ("rejected"), or 288 unknown ("unknown"). This session-param MUST be present when the 289 client's Session-Init had a Previous-Session-URI session-param. 291 Host-Scope A DNS domainname (in A-label form) that the session can 292 be used with. Multiple Scope parameters are allowed. If the 293 domainname starts with a '.' then the session may be used with all 294 server hosts whose domainnames are sub-domains of the given Host- 295 Scope domainname. The server's fully-qualified hostname is always 296 part of the session's host scope. 298 4. Session Scope: Sharing Sessions Across Servers 300 A service might be composed of multiple related servers, each with a 301 different hostname. As a result the service may require a client to 302 use the same session across the service's component servers. We 303 provide a mechanism by which the server may indicate a set of such 304 servers to the client: the Host-Scope session-param in the server's 305 Session-Assign response header. 307 [XXX We need a way to constrain this for privacy protection reasons. 308 It's not yet clear how the client can judge which Host-Scope 309 paramters to accept or ignore, only that must be allowed to do so.] 311 To facilitate interoperable session sharing across heterogeneous 312 server implementations we define a session resource -named by its 313 session URI- that can be obtained with a properly-authenticated GET 314 by authorized entities. The session resource's representation is a 315 application/json document type, containing a JSON-serialized 316 associative array with the following REQUIRED keys: 318 Master-Key The session's master key, base64-encoded. 320 MAC-Alg The MAC algorithm for this session. 322 [[anchor5: We probably want each server to see a different master 323 key, in which case we probably want to use a KDF with the server's 324 hostname as part of the salt.]] 326 [[anchor6: We probably want to define some OPTIONAL keys for this 327 object, such as "User", "User-URI", "HTTP-Auth-Scheme-Used", "HTTP- 328 Auth-Scheme-", and so on, as well as an application-specific 329 namespace of keys (e.g., "App-" or "").]] 331 5. Unauthenticated to Authenticated Session Upgrade 333 A client might first establish an unauthenticated session then 334 authenticate the user later. When authentication is done the client 335 might wish to preserve any state associated with the preceding 336 unauthenticated session. The client does this by sending a Session- 337 Init at authentication time with a 'Previous-Session-URI' session- 338 param and, if there was server-assigned session state, a 'Previous- 339 Session-State' session-param. 341 6. Session Continuation 343 Once a session is established the client binds requests to sessions 344 as described here. 346 There are two cases: HTTPS and HTTP. In both cases the client adds a 347 header 349 For the HTTPS case the client adds a "Session" header to its requests 350 with the following content: the session identifier assigned by the 351 server, a nonce generated by the client, and a MAC of the nonce and 352 the TLS channel bindings. 354 The value of the Session header consists of a base64-encoded 128-bit 355 nonce and a MAC, using the session's MAC algorithm, of the nonce and 356 the channel binding, each base64-encoded then concatenated in that 357 order: 359 CB = 360 nonce = 361 new-state = ... 362 direction = "c2s" | "s2c" 363 prot-state = "protected" | "unprotected" 364 response-status = "" | "Invalid-MAC" | 365 | "Session-expired" "Session-unknown" 366 MAC-input = direction "," prot-state "," nonce 367 "," CB "," status "," [new-state] 368 MAC = 369 Session = nonce "," response-status "," [new-state] "," MAC 371 Figure 3: Session header 373 Where the response must carry a Session header, the form of the value 374 is the same as for requests. 376 The MAC is taken over a direction indicator, an indicator of whether 377 TLS is used, the nonce, the channel bindings, and so on, as shown in 378 Figure 3. Only the server may assert new session state, and only the 379 server indicates a response-status other than "" (empty string). 381 6.1. Session Validation and Error Handling 383 The receiver computes the same MAC using the sender's nonce (and new- 384 state, if present, when the receiver is the client) and compares the 385 resulting MAC to the MAC from the Session header. 387 If MAC validation of a request fails then the server MUST respond 388 with a 403 status code with a non-empty response-status int he 389 Session-header. Error responses MUST include a Session header. If 390 403 response's Session header indicates "Invalid-MAC" then if the 391 client had used HTTPS then the client SHOULD warn the user, otherwise 392 the client SHOULD retry. If the 403 response's Session header 393 indicates "Session-expired" then the client SHOULD renew the session 394 (see Section 6.2). Otherwise the client must assume that the old 395 session has been destroyed (e.g., because of a logout or server state 396 data loss) and may establish a new session. 398 If MAC validation of a response fails the the client MUST act as 399 though a 400 (bad request) had been sent instead. If the request was 400 idempotent the client SHOULD retry, otherwise recovery is not 401 specified. 403 6.2. Session Expiration and Renewal 405 If the server decides that a session is no longer valid then the 406 server should respond with a 401 status code. The client should then 407 re-authenticate or establish a new unauthenticated session, using the 408 Previous-Session-URI and Previous-Session-State session-params of the 409 new Session-Init to indicate that the old session is being "renewed". 411 6.3. Alternative: Define Session Scheme for WWW-Authenticate 413 One possibility that has some appeal would be to define a new HTTP 414 authentication scheme called "Session" (say) and use that instead of 415 the "Session" header defined above. The primary advantage to the 416 WWW-Authenticate approach is that it fits the existing HTTP 417 authentication framework, allowing a server to present to an 418 application the user authentication information embedded in the 419 session state as if the user were re-authenticated in each request. 420 Session continuation can then be seen as a form of fast re- 421 authentication. 423 7. Logout 425 To logout the client SHOULD perform a DELETE of the session URI. 427 8. Inquiring Session Status 429 The client MAY do a GET of the session URI. The semantics of the 430 response body for this are not specified here. As explained in 431 Section 4, servers also may GET a session URI; see Section 4 for more 432 details. 434 9. Analysis 436 Quite clearly this protocol meets requirements 1, 2, 3, 5, and 11 437 from [I-D.williams-websec-session-continue-prob]. 439 The security requirements are also met: 441 requirement 4 The active cookie recovery attacks on TLS we consider 442 are adaptive chosen plaintext attacks. These attacks depend on 443 the cookies sent by the client being the same in every request. 444 This protocol uses MAC of at least channel bindings data (which 445 doesn't change for any one connection) salted (so to speak) with a 446 nonce. This use of nonces causes the MAC sent to be different for 447 each request, which defeats the known cookie recovery attacks on 448 TLS. Note that we assume confidentiality protection from TLS; 449 clients MUST NOT negotiate cipher suites that provide no 450 confidentiality protection. 452 requirement 6 This is clearly met by the use of a MAC keyed with a 453 session key not available to attackers. This clearly depends on 454 implementations having decent entropy sources, but this is no 455 different than for TLS. Note, however, that insecure session 456 initiation with key assertion is clearly insecure relative to 457 passive attackers, as well as active attackers that can redirect 458 packet flows so they can observe session initiation. 460 requirement_7 This is clearly met by prefixing an indicator of 461 whether TLS is used or not to the MAC input. 463 requirement_8 The use of channel bindings as an input to the MAC 464 meets this requirement. 466 requirement_9 This requirement is clearly met by having DELETE of a 467 session URI terminate a session. It is important that clients 468 promptly destroy any remnant of deleted sessions' state so that 469 servers get no benefit from not deleting sessions when the clients 470 demand it. 472 requirement_10 This is clearly met by using headers that proxies 473 should pass unmodified. 475 10. IANA Considerations 477 This document creates a number of new HTTP request and response 478 headers. These headers will need to be added to the HTTP header 479 registry: . 481 11. Security Considerations 483 This session continuation protocol appears to meet the requirements 484 outlined in [I-D.williams-websec-session-continue-prob]. [XXX Add 485 analysis. In particular explain how MAC(CB + nonce) is sufficient to 486 defeat BEAST and CRIME.] 488 This proposal meets security requirements from the problem statement 489 [I-D.williams-websec-session-continue-prob]. See Section 9 for 490 details. 492 [...] 494 12. References 496 12.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 502 Hashing for Message Authentication", RFC 2104, 503 February 1997. 505 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 506 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 507 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 509 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 510 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 512 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 513 Channels", RFC 5056, November 2007. 515 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 516 for TLS", RFC 5929, July 2010. 518 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 519 Key Derivation Function (HKDF)", RFC 5869, May 2010. 521 [I-D.williams-websec-session-continue-prob] 522 Williams, N., "Hypertext Transport Protocol (HTTP) Session 523 Continuation: Problem Statement", 524 draft-williams-websec-session-continue-prob-00 (work in 525 progress), January 2013. 527 12.2. Informative References 529 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 530 Leach, P., Luotonen, A., and L. Stewart, "HTTP 531 Authentication: Basic and Digest Access Authentication", 532 RFC 2617, June 1999. 534 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 535 April 2010. 537 [I-D.ietf-oauth-v2] 538 Hardt, D., "The OAuth 2.0 Authorization Framework", 539 draft-ietf-oauth-v2-31 (work in progress), August 2012. 541 [I-D.hallambaker-httpintegrity] 542 Hallam-Baker, P., "HTTP Integrity Header", 543 draft-hallambaker-httpintegrity-02 (work in progress), 544 November 2012. 546 Author's Address 548 Nicolas Williams 549 Cryptonector, LLC 551 Email: nico@cryptonector.com