idnits 2.17.1 draft-secure-cookie-session-protocol-08.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 (October 9, 2012) is 4217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Barbato 3 Internet-Draft S. Dorigotti 4 Intended status: Informational T. Fossati, Ed. 5 Expires: April 12, 2013 KoanLogic 6 October 9, 2012 8 SCS: Secure Cookie Sessions for HTTP 9 draft-secure-cookie-session-protocol-08 11 Abstract 13 This document provides an overview of SCS, a small cryptographic 14 protocol layered on top of the HTTP cookie facility, that allows its 15 users to produce and consume authenticated and encrypted cookies, as 16 opposed to usual cookies, which are un-authenticated and sent in 17 clear text. 19 An interesting property, rising naturally from the given 20 confidentiality and authentication properties, is that by using SCS 21 cookies, it is possible to avoid storing the session state material 22 on the server side altogether. In fact, an SCS cookie presented by 23 the user agent to the origin server can always be validated (i.e. 24 possibly recognized as self-produced, fresh, untampered material) 25 and, as such, be used to safely restore application state. 27 Hence, typical use cases may include devices with little or no 28 storage offering some functionality via an HTTP interface, as well as 29 web applications with high availability or load balancing 30 requirements which would prefer to handle application state without 31 the need to synchronize the pool through shared storage or peering. 33 Another noteworthy application scenario is represented by the 34 distribution of authorized web content (e.g. by CDNs), where an SCS 35 token can be used, either in a cookie or embedded in the URI, to 36 provide evidence of the entitlement to access the associated resource 37 by the requesting user agent. 39 Nevertheless, its security properties allow SCS to be used whenever 40 the privacy and integrity of cookies is a concern, by paying an 41 affordable price in terms of increased cookie size, additional CPU 42 clock cycles needed by the symmetric key encryption and HMAC 43 algorithms, and related key management, which can be made a nearly 44 transparent task. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on April 12, 2013. 63 Copyright Notice 65 Copyright (c) 2012 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 82 3. SCS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3.1. SCS Cookie Description . . . . . . . . . . . . . . . . . . 5 84 3.1.1. ATIME . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1.2. DATA . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 3.1.3. TID . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1.4. IV . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 3.1.5. AUTHTAG . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.2. Crypto Transform . . . . . . . . . . . . . . . . . . . . . 8 90 3.2.1. Choice and Role of the Framing Symbol . . . . . . . . 8 91 3.2.2. Cipher Set . . . . . . . . . . . . . . . . . . . . . . 9 92 3.2.3. Compression . . . . . . . . . . . . . . . . . . . . . 9 93 3.2.4. Cookie Encoding . . . . . . . . . . . . . . . . . . . 9 94 3.2.5. Outbound Transform . . . . . . . . . . . . . . . . . . 9 95 3.2.6. Inbound Transform . . . . . . . . . . . . . . . . . . 10 96 3.3. PDU Exchange . . . . . . . . . . . . . . . . . . . . . . . 12 97 3.3.1. Cookie Attributes . . . . . . . . . . . . . . . . . . 12 98 3.3.1.1. Expires . . . . . . . . . . . . . . . . . . . . . 12 99 3.3.1.2. Max-Age . . . . . . . . . . . . . . . . . . . . . 13 100 3.3.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . 13 101 3.3.1.4. Secure . . . . . . . . . . . . . . . . . . . . . . 13 102 4. Key Management and Session State . . . . . . . . . . . . . . . 13 103 5. Cookie Size Considerations . . . . . . . . . . . . . . . . . . 14 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 107 8.1. Security of the Cryptographic Protocol . . . . . . . . . . 15 108 8.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 16 109 8.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 16 110 8.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 17 111 8.2.3. Cookie Sharing or Theft . . . . . . . . . . . . . . . 18 112 8.2.4. Session Fixation . . . . . . . . . . . . . . . . . . . 18 113 8.3. Advantages of SCS over Server-side Sessions . . . . . . . 18 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 117 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 118 A.1. No Compression . . . . . . . . . . . . . . . . . . . . . . 20 119 A.2. Use Compression . . . . . . . . . . . . . . . . . . . . . 20 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 122 1. Introduction 124 SCS is a small cryptographic protocol layered on top of the HTTP 125 cookie facility [RFC6265], that allows its users to produce and 126 consume authenticated and encrypted cookies, as opposed to usual 127 cookies, which are un-authenticated and sent in clear text. 129 By having a non-tamperable proof of authorship attached, each SCS 130 cookie can always be validated by the originator, making it possible 131 for a server to handle clients' session state without the need to 132 store it locally. In fact, an SCS enabled server could completely 133 delegate the application state storage to the client (e.g. a web 134 browser) and use it, in all respects, as a remote storage device. 135 The result of the cryptographic transformations applied to state data 136 can be used to ensure that its information authenticity and 137 confidentiality attributes are the same as if they were stored 138 privately on server-side. 140 The no-storage requirement, which is the key design constraint of 141 SCS, makes it an ideal candidate in the following settings: 143 a. devices with little or no storage -- typically embedded devices 144 which provide functionality such as software updates, 145 configuration, device monitoring, etc. via an HTTP interface; 147 b. web applications with high availability or load balancing 148 requirements, which may delegate handling of the application 149 state to clients instead of using shared storage or forced 150 peering, to enhance overall parallelism. 152 It is worth noting that a peculiar difference between SCS, when used 153 in strict no-storage mode, and usual "server-side" cookie sessions 154 arises as soon as we carefully consider the roles of the playing 155 entities. In the "server-side" model, the server acts a triple role 156 as the "generator", the "owner", and the "verifier" of cookie 157 credentials. Instead, a server implementing SCS in no-storage mode, 158 acts the "generator" and "verifier" roles only -- the "owner" being 159 inapplicable for obvious reasons. 161 In all respects, the Server grants the custody of the generated 162 cookie to the Client, whose trust model needs to be taken into 163 consideration when designing applications that use SCS this way. The 164 consequences of such discrepancy (e.g. deliberate deletion of a 165 cookie, explicit privilege revocation, etc.) will be analyzed in 166 Section 8.2. 168 An SCS server can be implemented within a web application by means of 169 a user library that exposes the core SCS functionality and leaves 170 explicit control over SCS cookies to the programmer, or 171 transparently, by hiding, for example, a "diskless session" facility 172 behind a generic session API abstraction. SCS implementers are free 173 to choose the model that best suites their needs. 175 2. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. SCS Protocol 183 The SCS protocol defines: 185 o the SCS cookie structure and encoding (Section 3.1); 187 o the cryptographic transformations involved in SCS cookie creation 188 and verification (Section 3.2); 190 o the HTTP-based PDU exchange (Section 3.3). 192 o the underlying key management model (Section 4). 194 Note that the PDU is transmitted to the client as an opaque data 195 block, hence no interpretation nor validation is necessary. The 196 single requirement for client-side support of SCS is cookie 197 activation on the user agent. The origin server is sole actor 198 involved in the PDU manipulation process, which greatly simplifies 199 the crypto operations -- especially key management, which is usually 200 a pesky task. 202 In the following sections we assume S to be one or more 203 interchangeable HTTP server entities (e.g. a server pool in a load- 204 balanced or high-availability environment) and C to be the client 205 with a cookie-enabled browser, or any user agent with equivalent 206 capabilities. 208 3.1. SCS Cookie Description 210 S and C exchange a cookie (Section 3.3), whose cookie-value consists 211 of a sequence of adjacent non-empty values, each of which is the 'URL 212 and Filename safe' Base-64 encoding [RFC4648] of a specific SCS 213 field. 215 (Hereafter the encoded and raw versions of each SCS field are 216 distinguished based on the presence, or lack thereof, of the 'e' 217 prefix in their name, e.g. eATIME and ATIME.) 219 Each SCS field is separated by its left and/or right sibling by means 220 of the %x7c ASCII character (i.e. '|'), as follows: 222 scs-cookie = scs-cookie-name "=" scs-cookie-value 223 scs-cookie-name = token 224 scs-cookie-value = eDATA "|" eATIME "|" eTID "|" eIV "|" eAUTHTAG 225 eDATA = 1*base64url-character 226 eATIME = 1*base64url-character 227 eTID = 1*base64url-character 228 eIV = 1*base64url-character 229 eAUTHTAG = 1*base64url-character 231 Figure 1 233 Confidentiality is limited to the application state information (i.e. 234 the DATA field), while integrity and authentication apply to the 235 entire cookie-value. 237 The following subsections describe the syntax and semantics of each 238 SCS cookie field. 240 3.1.1. ATIME 242 Absolute timestamp relating to the last read or write operation 243 performed on session DATA, encoded as a HEX string holding the number 244 of seconds since UNIX epoch (i.e. since 00:00:00, Jan 1 1970.) 246 This value is updated with each client contact and is used to 247 identify expired sessions. If the delta between the received ATIME 248 value and the current time on S, is larger than a predefined 249 "session_max_age" (which is chosen by S as an application-level 250 parameter), a session is considered to be no longer valid, and is 251 therefore rejected. 253 Such an expiration error may be used to force user logout from an SCS 254 cookie based session, or hooked in the web application logics to the 255 display of a HTML form asking re-validation of user credentials. 257 3.1.2. DATA 259 Block of encrypted and optionally compressed data, possibly 260 containing the current session state. Note that no restriction is 261 imposed on clear text structure: the protocol is completely agnostic 262 as to inner data layout. 264 Generally speaking, the plain text is the "normal" cookie that would 265 have been exchanged by S and C if SCS wasn't used. 267 3.1.3. TID 269 This identifier is equivalent to a SPI in a Data Security SA 270 [RFC3740]) and consists of an ASCII string that uniquely identifies 271 the transform set (keys and algorithms) used to generate this SCS 272 cookie. 274 SCS assumes that a key-agreement/distribution mechanism exists for 275 environments in which S consists of multiple servers, which provides 276 a unique external identifier for each transform set shared amongst 277 pool members. 279 Please note that the said mechanism may safely downgrade to a 280 periodic key-refresh in case there is one only server in the pool and 281 key is generated in place -- i.e. it is not handled from an external 282 source. 284 3.1.4. IV 286 Initialization Vector used for the encryption algorithm 287 (Section 3.2). 289 In order to avoid providing correlation information to a possible 290 attacker with access to a sample of SCS cookies created using the 291 same TID, the IV MUST be created randomly for each SCS cookie. 293 3.1.5. AUTHTAG 295 Authentication tag based on the plain string concatenation of the 296 base64url encoded DATA, ATIME, TID and IV fields, framed by the "|" 297 separator (see also the definition of the Box() function in 298 Section 3.2): 300 AUTHTAG = HMAC(base64url(DATA) "|" 301 base64url(ATIME) "|" 302 base64url(TID) "|" 303 base64url(IV)) 305 Note that, from a cryptographic point of view, the "|" character 306 provides explicit authentication of the length of each supplied 307 field, which results in a robust countermeasure against splicing 308 attacks. 310 3.2. Crypto Transform 312 SCS could potentially use any combination of primitives capable of 313 performing authenticated encryption. In practice an encrypt-then-mac 314 approach [Kohno] with CBC-mode encryption and HMAC [RFC2104] 315 authentication was chosen. 317 The two algorithms MUST be associated with two independent keys. 319 The following conventions will be used in the algorithm description 320 (Section 3.2.5 and Section 3.2.6): 322 o Enc/Dec(): block encryption/decryption functions (Section 3.2.2); 324 o HMAC(): authentication function (Section 3.2.2); 326 o Comp/Uncomp(): compression/decompression functions 327 (Section 3.2.3); 329 o e/d(): cookie value encoding/decoding functions (Section 3.2.4); 331 o RAND(): random number generator [RFC4086]; 333 o Box(): string boxing function. It takes an arbitrary number of 334 base64url encoded strings and returns the string obtained by 335 juxtaposing each of the inputs in the exact order in which they 336 are listed, separated by the "|" char. For example: 338 Box("akxI", "MTM", "Hadvo") = "akxI|MTM|Hadvo". 340 3.2.1. Choice and Role of the Framing Symbol 342 Note that that the adoption of "|" as the framing symbol in the Box() 343 function is arbitrary: any char allowed by the cookie-value ABNF in 344 [RFC6265] is safe to be used as long it has empty intersection with 345 the base64url alphabet. 347 It is also worth noting that the role of the framing symbol, which 348 provides an implicit length indicator for each of the atoms, is key 349 to the correctness and security of SCS. 351 This is especially relevant when the authentication tag is computed 352 (see Section 3.1.5). There, the explicit inclusion of the framing 353 symbol to the HMAC input, seals the integrity of the blob as a whole, 354 together with each of its composing atoms in their exact position. 356 This feature makes the protocol robust against attacks aimed at 357 disrupting the security of SCS PDUs by freely moving boundaries 358 between adjacent atoms. 360 3.2.2. Cipher Set 362 Implementors MUST support at least the following algorithms: 364 o AES-CBC-128 for encryption; 366 o HMAC-SHA1 with a 128 bit key for authenticity and integrity, 368 which appear to be sufficiently secure in a wide range of use cases 369 [Bellare], are widely available, and can be implemented in a few 370 kilobytes of memory, providing an extremely valuable feature in 371 constrained devices. 373 One should consider using larger cryptographic key lengths (192 or 374 256 bit) according to the actual security and overall system 375 performance requirements. 377 3.2.3. Compression 379 Compression, which may be useful or even necessary when handling 380 large quantities of data, is not compulsory (in such case Comp/Uncomp 381 are replaced by an identity matrix). If this function is enabled, 382 DEFLATE [RFC1951] format MUST be supported. 384 Some advice to SCS users: compression should not be enabled when 385 handling relatively short and entropic state such as pseudo random 386 session identifiers. Instead, large and quite regular state blobs 387 could get a significant boost when compressed. 389 3.2.4. Cookie Encoding 391 SCS cookie values MUST be encoded using the URL and filename safe 392 alphabet (i.e. base64url) defined in section 5 of Base-64 [RFC4648]. 393 This encoding is very wide-spread, falls smoothly into the encoding 394 rules defined in Section 4.1.1 of [RFC6265], and can be safely used 395 to supply SCS based authorization tokens within an URI (e.g. in a 396 query string or straight into a path segment). 398 3.2.5. Outbound Transform 400 The output data transformation as seen by the server (the only actor 401 which explicitly manipulates SCS cookies) is illustrated by the 402 pseudo-code in Figure 2. 404 1. IV := RAND() 405 2. ATIME := NOW 406 3. DATA := Enc(Comp(plain-text-cookie-value), IV) 407 4. AUTHTAG := HMAC(Box(e(DATA), e(ATIME), e(TID), e(IV))) 409 Figure 2 411 A new Initialization Vector is randomly picked (step 1.). As 412 previously mentioned (Section 3.1.4) this step is necessary to avoid 413 providing correlation information to an attacker. 415 A new ATIME value is taken as the current timestamp according to the 416 server clock (step 2.). 418 Since the only user of the ATIME field is the server, it is 419 unnecessary for it to be synchronized with the client -- though it 420 needs to use a fairly stable clock. However, if multiple servers are 421 active in a load-balancing configuration, clocks SHOULD be 422 synchronized to avoid errors in the calculation of session expiry. 424 The plain text cookie value is then compressed (if needed) and 425 encrypted by using the key-set identified by TID (step 3.). 427 If the length of (compressed) state is not a multiple of the block 428 size, its value MUST be filled with as many padding bytes of equal 429 value as the pad length -- as defined by the scheme given in Section 430 6.3 of [RFC5652]. 432 Then the authentication tag, which encompasses each SCS field (along 433 with lengths, and relative positions) is computed by HMAC'ing the 434 "|"-separated concatenation of their base64url representations using 435 the key-set identified by TID (step 4.). 437 Finally the SCS cookie-value is created as follows: 439 scs-cookie-value = Box(e(DATA), e(ATIME), e(TID), e(IV), e(tag)) 441 3.2.6. Inbound Transform 443 The inbound transformation is described in Figure 3. In it, each of 444 the 'e'-prefixed names has to be interpreted as the base64url encoded 445 value of the corresponding SCS field. 447 0. If (split_fields(scs-cookie-value) == ok) 448 1. tid' := d(eTID) 449 2. If (tid' is available) 450 3. tag' := d(eAUTHTAG) 451 4. tag := HMAC(Box(eDATA, eATIME, eTID, eIV)) 452 5. If (tag = tag') 453 6. atime' := d(eATIME) 454 7. If (NOW - atime' <= session_max_age) 455 8. iv' := d(eIV) 456 data' := d(eDATA) 457 9. state := Uncomp(Dec(data', iv')) 458 10. Else discard PDU 459 11. Else discard PDU 460 12. Else discard PDU 461 13. Else discard PDU 463 Figure 3 465 First of all, the inbound scs-cookie-value is broken into its 466 component fields which MUST be exactly 5, and each at least of the 467 minimum length specified in Figure 1 (step 0.). In case any of these 468 preliminary checks fails, the PDU is discarded (step 13.); else TID 469 is decoded to allow key-set lookup (step 1.). 471 If the cryptographic credentials (encryption and authentication 472 algorithms and keys identified by TID) are unavailable (step 12.), 473 the inbound SCS cookie is discarded since its value has no chance to 474 be interpreted correctly. This may happen for several reasons: e.g., 475 if a device without storage has been reset and loses the credentials 476 stored in RAM, if a server pool node desynchronizes, or in case of a 477 key compromise that forces the invalidation of all current TID's, 478 etc. 480 When a valid key-set is found (step 2.), the AUTHTAG field is decoded 481 (step 3.) and the (still) encoded DATA, ATIME, TID and IV fields are 482 supplied to the primitive that computes the authentication tag (step 483 4.). 485 If the tag computed using the local key-set matches the one carried 486 by the supplied SCS cookie, we can be confident that the cookie 487 carries authentic material; otherwise the SCS cookie is discarded 488 (step 11.). 490 Then the age of the SCS cookie (as deduced by ATIME field value and 491 current time provided by the server clock) is decoded and compared to 492 the maximum time-to-live defined by the session_max_age parameter. 494 In case the "age" check is passed, the DATA and IV fields are finally 495 decoded (step 8.), so that the original plain text data can be 496 extracted from the encrypted and optionally compressed blob (step 497 9.). 499 Note that steps 5. and 7. allow any altered packets or expired 500 sessions to be discarded, hence avoiding unnecessary state decryption 501 and decompression. 503 3.3. PDU Exchange 505 SCS can be modeled in the same manner as a typical store-and-forward 506 protocol, in which the endpoints are S, consisting of one or more 507 HTTP servers, and the client C, an intermediate node used to 508 "temporarily" store the data to be successively forwarded to S. 510 In brief, S and C exchange an immutable cookie data block 511 (Section 3.1): the state is stored on the client at the first hop and 512 then restored on the server at the second, as in Figure 4. 514 1. dump-state: 515 S --> C 516 Set-Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0... 517 Expires=...; Path=...; Domain=...; 519 2. restore-state: 520 C --> S 521 Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0... 523 Figure 4 525 3.3.1. Cookie Attributes 527 In the following sub paragraphs a series of recommendations is 528 provided in order to maximize SCS PDU fitness in the generic cookie 529 ecosystem. 531 3.3.1.1. Expires 533 SCS cookies MUST include an Expires attribute which shall be set to a 534 value consistent with session_max_age. 536 For maximum compatibility with existing user agents the timestamp 537 value MUST be encoded in rfc1123-date format which requires a 4-digit 538 year. 540 3.3.1.2. Max-Age 542 Since not all UAs support this attribute, it MUST NOT be present in 543 any SCS cookie. 545 3.3.1.3. Domain 547 SCS cookies MUST include a Domain attribute compatible with 548 application usage. 550 A trailing '.' MUST NOT be present in order to minimize the 551 possibility of a user agent ignoring the attribute value. 553 3.3.1.4. Secure 555 This attribute MUST always be asserted when SCS sessions are carried 556 over a TLS channel. 558 4. Key Management and Session State 560 This specification provides some common recommendations and practices 561 relevant to cryptographic key management. 563 In the following, the term 'key' references both encryption and HMAC 564 keys. 566 o The key SHOULD be generated securely following the randomness 567 recommendations in [RFC4086]; 569 o the key SHOULD only be used to generate and verify SCS PDUs; 571 o the key SHOULD be replaced regularly as well as any time the 572 format of SCS PDUs or cryptographic algorithms changes. 574 Furthermore, to preserve the validity of active HTTP sessions upon 575 renewal of cryptographic credentials (whenever the value of TID 576 changes), an SCS server MUST be capable of managing at least two 577 transforms contemporarily: the currently instantiated one, and its 578 predecessor. 580 Each transform set SHOULD be associated with an attribute pair: 581 "refresh" and "expiry", which is used to identify the exposure limits 582 (in terms of time or quantity of encrypted and/or authenticated 583 bytes, etc) of related cryptographic material. 585 In particular, the "refresh" attribute specifies the time limit for 586 substitution of transform set T with new material T'. From that 587 moment onwards, and for an amount of time determined by "expiry", all 588 new sessions will be created using T', while the active T-protected 589 ones go through a translation phase in which: 591 o the inbound transformation authenticates and decrypts/decompresses 592 using T (identified by TID); 594 o the outbound transformation encrypts/compresses and authenticates 595 using T'. 597 T' {not valid yet} |---------------------|---------------- 598 | translation stage | 599 T ----------------|---------------------| {no longer valid} 600 refresh refresh + expiry 602 Figure 5 604 As shown in Figure 5, the duration of the HTTP session MUST fit 605 within the lifetime of a given transform set (i.e. from creation time 606 until "refresh" + "expiry"). 608 In practice, this should not be an obstacle because the longevity of 609 the two entities (HTTP session and SCS transform set) should differ 610 by one or two orders of magnitude. 612 An SCS server may take this into account by determining the duration 613 of a session adaptively according to the expected deletion time of 614 the active T, or by setting the "expiry" value to at least the 615 maximum lifetime allowed by an HTTP session. 617 Since there is only one refresh attribute also in situations with 618 more than one key (e.g. one for encryption and one for 619 authentication) within the same T, the smallest value is chosen. 621 5. Cookie Size Considerations 623 In general, SCS cookies are bigger than their plain text 624 counterparts. This is due to a couple of different factors: 626 o inflation of the Base-64 encoding of the state data (approx. 1.4 627 times the original size, including the encryption padding), and 629 o the fixed size increment (approx. 80/90 bytes) due to SCS fields 630 and framing overhead. 632 While the former is a price the user must always pay proportionally 633 to the original data size, the latter is a fixed quantum, which can 634 be huge on small amounts of data, but is quickly absorbed as soon as 635 data becomes big enough. 637 The following table compares byte lengths of SCS cookies (with a four 638 bytes' TID) and corresponding plain text cookies in a worst case 639 scenario, i.e. when no compression is in use (or applicable). 641 plain | SCS 642 -------+------- 643 11 | 128 644 102 | 256 645 285 | 512 646 651 | 1024 647 1382 | 2048 648 2842 | 4096 650 The largest uncompressed cookie value that can be safely supplied to 651 SCS is about 2.8KB. 653 6. Acknowledgements 655 We would like to thank Jim Schaad, David Wagner and Lorenzo Cavallaro 656 for their valuable feedback on this document. 658 7. IANA Considerations 660 This memo includes no request to IANA. 662 8. Security Considerations 664 8.1. Security of the Cryptographic Protocol 666 From a cryptographic architecture perspective, the described 667 mechanism can be easily traced to an "encode then encrypt then MAC" 668 scheme (Encode-then-EtM) as described in [Kohno]. 670 Given a "provably-secure" encryption scheme and MAC (as for the 671 algorithms mandated in Section 3.2.2), Kohno et al. [Kohno] 672 demonstrate that their composition results in a secure authenticated 673 encryption scheme. 675 8.2. Impact of the SCS Cookie Model 677 The fact that the server does not own the cookie it produces, gives 678 rise to a series of consequences that must be clearly understood when 679 one envisages the use of SCS as a cookie provider and validator for 680 his/her application. 682 In the following paragraphs, a set of different attack scenarios 683 (together with corresponding countermeasures where applicable) are 684 identified and analyzed. 686 8.2.1. Old cookie replay 688 SCS doesn't address replay of old cookie values. 690 In fact, there is nothing that guarantees an SCS application about 691 the client having returned the most recent version of the cookie. 693 As with "server-side" sessions, if an attacker gains possession of a 694 given user's cookies - via simple passive interception or another 695 technique - he/she will always be able to restore the state of an 696 intercepted session by representing the captured data to the server. 698 The ATIME value along with the session_max_age configuration 699 parameter allow SCS to mitigate the chances of an attack (by forcing 700 a time window outside of which a given cookie is no longer valid), 701 but cannot exclude it completely. 703 A countermeasure against the "passive interception and replay" 704 scenario can be applied at transport/network level using the anti- 705 replay services provided by e.g., SSL/TLS [RFC5246] or IPsec 706 [RFC4301]. 708 Anyway, a generic solution is still out of scope: an SCS application 709 wishing to be replay-resistant must put in place some ad hoc 710 mechanism to prevent clients (both rogue and legitimate) from (a) 711 being able to replay old cookies as valid credentials and/or (b) 712 getting any advantage by replaying them. 714 In the following, some typical use cases are illustrated: 716 o Session inactivity timeout scenario (implicit invalidation): use 717 the session_max_age parameter if a global setting is viable, else 718 place an explicit TTL in the cookie (e.g. 719 validity_period="start_time, duration") that can be verified by 720 the application each time the Client presents the SCS cookie. 722 o Session voidance scenario (explicit invalidation): put a randomly 723 chosen string into each SCS cookie (cid="$(random())") and keep a 724 list of valid session cid's against which the SCS cookie presented 725 by the client can be checked. When a cookie needs to be 726 invalidated, delete the corresponding cid from the list. The 727 described method has the drawback that, in case a non-permanent 728 storage is used to archive valid cid's, a reboot/restart would 729 invalidate all sessions (It can't be used when |S| > 1). 731 o One-shot transaction scenario (ephemeral): this is a variation on 732 the previous theme when sessions are consumed within a single 733 request/response. Put a nonce="$(random())" within the state 734 information and keep a list of not-yet-consumed nonces in RAM. 735 Once the client presents its cookie credential, the embodied nonce 736 is deleted from the list and will be therefore discarded whenever 737 replayed. 739 It may be noteworthy that despite the chances of preventing replay in 740 some well established circumstances by using aforementioned 741 mechanisms, if the attacker is able to use the cookie before the 742 legitimate client gets a chance to, then the impersonation attack 743 will always succeed. 745 8.2.2. Cookie Deletion 747 A direct, and important, consequence of the missing owner role in SCS 748 is that a client could intentionally delete its cookie and return 749 nothing. 751 The application protocol has to be designed so there is no incentive 752 to do so, for instance: 754 o it is safe for the cookie to represent some kind of positive 755 capability - the possession of which increases the client's 756 powers; 758 o It is not safe to use the cookie to represent negative 759 capabilities - where possession reduces the client's powers-, or 760 for revocation. 762 Note that this behavior is not equivalent to cookie removal in the 763 "server-side" cookie model, because in case of missing cookie backup 764 by other parties (e.g. the application using SCS), the Client could 765 simply make it disappear once and for all. 767 8.2.3. Cookie Sharing or Theft 769 Just like with plain cookies, SCS doesn't prevent sharing (both 770 voluntary and illegitimate) of cookies between multiple clients. 772 In the context of voluntary cookie sharing, using HTTPS is useless: 773 Client certificates are just as shareable as cookies, hence 774 equivalently to the "server-side" cookie model, there seems to be no 775 way to prevent this threat. 777 The theft could be mitigated by securing the wire (e.g. via HTTPS, 778 IPsec, VPN, ...), thus reducing the opportunity of cookie stealing to 779 a successful attack on the protocol endpoints. 781 8.2.4. Session Fixation 783 Session fixation vulnerabilities [Kolsec] are not addressed by SCS. 785 A more sophisticated protocol involving an active participation by 786 the UA in the SCS cookie manipulation would be needed: e.g. some form 787 of challange-response exchange initiated by the Server on the HTTP 788 response and replied by the UA on the next chained HTTP request. 790 Unfortunately the present specification which bases on [RFC6265] sees 791 the UA as a completely passive character, whose role is to blindly 792 paste the cookie value set by the Server. 794 Nevertheless, the SCS cookies wrapping mechanism may be used in the 795 future as a building block for a more robust HTTP state management 796 protocol. 798 8.3. Advantages of SCS over Server-side Sessions 800 Note that all the above-mentioned vulnerabilities also apply to plain 801 cookies, making SCS at least as secure, but there are a few good 802 reasons to consider its security level enhanced. 804 First of all, the confidentiality and authentication features 805 provided by SCS protects the cookie-value which is normally plain 806 text and tamperable. 808 Furthermore, none of the common vulnerabilities of server-side 809 sessions (SID prediction, SID brute forcing) can be exploited when 810 using SCS, unless the attacker possesses encryption and HMAC keys 811 (both current ones and those relating to the previous set of 812 credentials). 814 More generally no slicing nor altering operations can be done over an 815 SCS PDU without controlling the cryptographic key-set. 817 9. References 819 9.1. Normative References 821 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 822 version 1.3", RFC 1951, May 1996. 824 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 825 Hashing for Message Authentication", RFC 2104, 826 February 1997. 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, March 1997. 831 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 832 Requirements for Security", BCP 106, RFC 4086, June 2005. 834 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 835 Encodings", RFC 4648, October 2006. 837 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 838 RFC 5652, September 2009. 840 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 841 April 2011. 843 9.2. Informative References 845 [Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security 846 Without Collision-Resistance", 2006. 848 [Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure 849 Cryptographic Transforms, or How to Encrypt and MAC", 850 2003. 852 [Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based 853 Applications", 2002. 855 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 856 Architecture", RFC 3740, March 2004. 858 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 859 Internet Protocol", RFC 4301, December 2005. 861 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 862 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 864 Appendix A. Examples 866 The examples in this section have been created using the 'scs' test 867 tool bundled with LibSCS, a free and opensource reference 868 implementation of the SCS protocol that can be found at 869 . 871 A.1. No Compression 873 The following parameters: 875 o Plain text cookie: "a state string" 877 o AES-CBC-128 key: "123456789abcdef" 879 o HMAC-SHA1 key: "12345678901234567890" 881 o TID: "tid" 883 o ATIME: 1347265955 885 o IV: 886 \xb4\xbd\xe5\x24\xf7\xf6\x9d\x44\x85\x30\xde\x9d\xb5\x55\xc9\x4f 888 produce the following tokens: 890 o DATA: DqfW4SFqcjBXqSTvF2qnRA 892 o ATIME: MTM0NzI2NTk1NQ 894 o TID: OHU7M1cqdDQt 896 o IV: tL3lJPf2nUSFMN6dtVXJTw 898 o AUTHTAG: AznYHKga9mLL8ioi3If_1iy2KSA 900 A.2. Use Compression 902 The same parameters as above, except ATIME and IV: 904 o Plain text cookie: "a state string" 906 o AES-CBC-128 key: "123456789abcdef" 907 o HMAC-SHA1 key: "12345678901234567890" 909 o TID: "tid" 911 o ATIME: 1347281709 913 o IV: 914 \x1d\xa7\x6f\xa0\xff\x11\xd7\x95\xe3\x4b\xfb\xa9\xff\x65\xf9\xc7 916 produce the following tokens: 918 o DATA: PbE-ypmQ43M8LzKZ6fMwFg-COrLP2l-Bvgs 920 o ATIME: MTM0NzI4MTcwOQ 922 o TID: akxIKmhbMTE8 924 o IV: HadvoP8R15XjS_up_2X5xw 926 o AUTHTAG: A6qevPr-ugHQChlr_EiKYWPvpB0 928 In both cases, the resulting SCS cookie is obtained via ordered 929 concatenation of the produced tokens, as described in Section 3.1. 931 Authors' Addresses 933 Stefano Barbato 934 KoanLogic 935 Via Marmolada, 4 936 Vitorchiano (VT), 01030 937 Italy 939 Email: tat@koanlogic.com 941 Steven Dorigotti 942 KoanLogic 943 Via Maso della Pieve 25/C 944 Bolzano, 39100 945 Italy 947 Email: stewy@koanlogic.com 948 Thomas Fossati (editor) 949 KoanLogic 950 Via di Sabbiuno 11/5 951 Bologna, 40136 952 Italy 954 Phone: +39 051 644 82 68 955 Email: tho@koanlogic.com