idnits 2.17.1 draft-secure-cookie-session-protocol-05.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 (September 7, 2012) is 4242 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: March 11, 2013 KoanLogic 6 September 7, 2012 8 SCS: Secure Cookie Sessions for HTTP 9 draft-secure-cookie-session-protocol-05 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 March 11, 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. Cipher Set . . . . . . . . . . . . . . . . . . . . . . 8 91 3.2.2. Compression . . . . . . . . . . . . . . . . . . . . . 9 92 3.2.3. Cookie Encoding . . . . . . . . . . . . . . . . . . . 9 93 3.2.4. Outbound Transform . . . . . . . . . . . . . . . . . . 9 94 3.2.5. Inbound Transform . . . . . . . . . . . . . . . . . . 10 95 3.3. PDU Exchange . . . . . . . . . . . . . . . . . . . . . . . 11 96 3.3.1. Cookie Attributes . . . . . . . . . . . . . . . . . . 12 97 3.3.1.1. Expires . . . . . . . . . . . . . . . . . . . . . 12 98 3.3.1.2. Max-Age . . . . . . . . . . . . . . . . . . . . . 12 99 3.3.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . 12 100 3.3.1.4. Secure . . . . . . . . . . . . . . . . . . . . . . 12 101 4. Key Management and Session State . . . . . . . . . . . . . . . 12 102 5. Cookie Size Considerations . . . . . . . . . . . . . . . . . . 14 103 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 106 8.1. Security of the Cryptographic Protocol . . . . . . . . . . 15 107 8.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 15 108 8.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 15 109 8.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 17 110 8.2.3. Cookie Sharing or Theft . . . . . . . . . . . . . . . 17 111 8.2.4. Session Fixation . . . . . . . . . . . . . . . . . . . 17 112 8.3. Advantages of SCS over Server-side Sessions . . . . . . . 18 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 116 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 117 A.1. No Compression . . . . . . . . . . . . . . . . . . . . . . 19 118 A.2. Use Compression . . . . . . . . . . . . . . . . . . . . . 20 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 121 1. Introduction 123 SCS is a small cryptographic protocol layered on top of the HTTP 124 cookie facility [RFC6265], that allows its users to produce and 125 consume authenticated and encrypted cookies, as opposed to usual 126 cookies, which are un-authenticated and sent in clear text. 128 By having a non-tamperable proof of authorship attached, each SCS 129 cookie can always be validated by the originator, making it possible 130 for a server to handle clients' session state without the need to 131 store it locally. In fact, an SCS enabled server could completely 132 delegate the application state storage to the client (e.g. a web 133 browser) and use it, in all respects, as a remote storage device. 134 The result of the cryptographic transformations applied to state data 135 can be used to ensure that its information authenticity and 136 confidentiality attributes are the same as if they were stored 137 privately on server-side. 139 The no-storage requirement, which is the key design constraint of 140 SCS, makes it an ideal candidate in the following settings: 142 a. devices with little or no storage -- typically embedded devices 143 which provide functionality such as software updates, 144 configuration, device monitoring, etc. via an HTTP interface; 146 b. web applications with high availability or load balancing 147 requirements, which may delegate handling of the application 148 state to clients instead of using shared storage or forced 149 peering, to enhance overall parallelism. 151 It is worth noting that a peculiar difference between SCS, when used 152 in strict no-storage mode, and usual "server-side" cookie sessions 153 arises as soon as we carefully consider the roles of the playing 154 entities. In the "server-side" model, the server acts a triple role 155 as the "generator", the "owner", and the "verifier" of cookie 156 credentials. Instead, a server implementing SCS in no-storage mode, 157 acts the "generator" and "verifier" roles only -- the "owner" being 158 inapplicable for obvious reasons. 160 In all respects, the Server grants the custody of the generated 161 cookie to the Client, whose trust model needs to be taken into 162 consideration when designing applications that use SCS this way. The 163 consequences of such discrepancy (e.g. deliberate deletion of a 164 cookie, explicit privilege revocation, etc.) will be analyzed in 165 Section 8.2. 167 An SCS server can be implemented within a web application by means of 168 a user library that exposes the core SCS functionality and leaves 169 explicit control over SCS cookies to the programmer, or 170 transparently, by hiding, for example, a "diskless session" facility 171 behind a generic session API abstraction. SCS implementers are free 172 to choose the model that best suites their needs. 174 2. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. SCS Protocol 182 The SCS protocol defines: 184 o the SCS cookie structure and encoding (Section 3.1); 186 o the cryptographic transformations involved in SCS cookie creation 187 and verification (Section 3.2); 189 o the HTTP-based PDU exchange (Section 3.3). 191 o the underlying key management model (Section 4). 193 Note that the PDU is transmitted to the client as an opaque data 194 block, hence no interpretation nor validation is necessary. The 195 single requirement for client-side support of SCS is cookie 196 activation on the user agent. The origin server is sole actor 197 involved in the PDU manipulation process, which greatly simplifies 198 the crypto operations -- especially key management, which is usually 199 a pesky task. 201 In the following sections we assume S to be one or more 202 interchangeable HTTP server entities (e.g. a server pool in a load- 203 balanced or high-availability environment) and C to be the client 204 with a cookie-enabled browser, or any user agent with equivalent 205 capabilities. 207 3.1. SCS Cookie Description 209 S and C exchange a cookie (Section 3.3), whose cookie-value consists 210 of a sequence of adjacent non-empty values, each of which is the 'URL 211 and Filename safe' Base-64 encoding [RFC4648] of a specific SCS 212 field. 214 (Hereafter the encoded and raw versions of each SCS field are 215 distinguished based on the presence, or lack thereof, of the 'e' 216 prefix in their name, e.g. eATIME and ATIME.) 218 Each SCS field is separated by its left and/or right sibling by means 219 of the %x7c ASCII character (i.e. '|'), as follows: 221 scs-cookie = scs-cookie-name "=" scs-cookie-value 222 scs-cookie-name = token 223 scs-cookie-value = eDATA "|" eATIME "|" eTID "|" eIV "|" eAUTHTAG 224 eDATA = 1*base64url-character 225 eATIME = 1*base64url-character 226 eTID = 1*base64url-character 227 eIV = 1*base64url-character 228 eAUTHTAG = 1*base64url-character 230 Figure 1 232 Confidentiality is limited to the application state information (i.e. 233 the DATA field), while integrity and authentication apply to the 234 entire cookie-value. 236 The following subsections describe the syntax and semantics of each 237 SCS cookie field. 239 3.1.1. ATIME 241 Absolute timestamp relating to the last read or write operation 242 performed on session DATA, encoded as a HEX string holding the number 243 of seconds since UNIX epoch (i.e. since 00:00:00, Jan 1 1970.) 245 This value is updated with each client contact and is used to 246 identify expired sessions. If the delta between the received ATIME 247 value and the current time on S, is larger than a predefined 248 "session_max_age" (which is chosen by S as an application-level 249 parameter), a session is considered to be no longer valid, and is 250 therefore rejected. 252 Such an expiration error may be used to force user logout from an SCS 253 cookie based session, or hooked in the web application logics to the 254 display of a HTML form asking re-validation of user credentials. 256 3.1.2. DATA 258 Block of encrypted and optionally compressed data, possibly 259 containing the current session state. Note that no restriction is 260 imposed on clear text structure: the protocol is completely agnostic 261 as to inner data layout. 263 Generally speaking, the plain text is the "normal" cookie that would 264 have been exchanged by S and C if SCS wasn't used. 266 3.1.3. TID 268 This identifier is equivalent to a SPI in a Data Security SA 269 [RFC3740]) and consists of an ASCII string that uniquely identifies 270 the transform set (keys and algorithms) used to generate this SCS 271 cookie. 273 SCS assumes that a key-agreement/distribution mechanism exists for 274 environments in which S consists of multiple servers, which provides 275 a unique external identifier for each transform set shared amongst 276 pool members. 278 Please note that the said mechanism may safely downgrade to a 279 periodic key-refresh in case there is one only server in the pool and 280 key is generated in place -- i.e. it is not handled from an external 281 source. 283 3.1.4. IV 285 Initialization Vector used for the encryption algorithm 286 (Section 3.2). 288 In order to avoid providing correlation information to a possible 289 attacker with access to a sample of SCS cookies created using the 290 same TID, the IV MUST be created randomly for each SCS cookie. 292 3.1.5. AUTHTAG 294 Authentication tag based on the plain string concatenation of the 295 base64url encoded DATA, ATIME, TID and IV fields, framed by the "|" 296 separator: 298 AUTHTAG = HMAC(base64url(DATA) "|" 299 base64url(ATIME) "|" 300 base64url(TID) "|" 301 base64url(IV)) 303 Note that, from a cryptographic point of view, the "|" character 304 provides explicit authentication of the length of each supplied 305 field, which results in a robust countermeasure against splicing 306 attacks. 308 3.2. Crypto Transform 310 SCS could potentially use any combination of primitives capable of 311 performing authenticated encryption. In practice an encrypt-then-mac 312 approach [Kohno] with CBC-mode encryption and HMAC [RFC2104] 313 authentication was chosen. 315 The two algorithms MUST be associated with two independent keys. 317 The following conventions will be used in the algorithm description 318 (Section 3.2.4 and Section 3.2.5): 320 o Enc/Dec(): block encryption/decryption functions (Section 3.2.1); 322 o HMAC(): authentication function (Section 3.2.1); 324 o Comp/Uncomp(): compression/decompression functions 325 (Section 3.2.2); 327 o e/d(): cookie value encoding/decoding functions (Section 3.2.3); 329 o ||: explicit framing byte, i.e. the "|" char; 331 o RAND(): random number generator [RFC4086]. 333 Please note that using "|" as the framing byte is arbitrary: any 334 symbol with empty intersection with the base64url alphabet is safe to 335 be used (as long as it is allowed by the cookie-value ABNF in 336 [RFC6265]). 338 3.2.1. Cipher Set 340 Implementors MUST support at least the following algorithms: 342 o AES-CBC-128 for encryption; 344 o HMAC-SHA1 with a 128 bit key for authenticity and integrity, 346 which appear to be sufficiently secure in a wide range of use cases 347 [Bellare], are widely available, and can be implemented in a few 348 kilobytes of memory, providing an extremely valuable feature in 349 constrained devices. 351 One should consider using larger cryptographic key lengths (192 or 352 256 bit) according to the actual security and overall system 353 performance requirements. 355 3.2.2. Compression 357 Compression, which may be useful or even necessary when handling 358 large quantities of data, is not compulsory (in such case Comp/Uncomp 359 are replaced by an identity matrix). If this function is enabled, 360 DEFLATE [RFC1951] format MUST be supported. 362 Some advice to SCS users: compression should not be enabled when 363 handling relatively short and entropic state such as pseudo random 364 session identifiers. Instead, large and quite regular state blobs 365 could get a significant boost when compressed. 367 3.2.3. Cookie Encoding 369 SCS cookie values MUST be encoded using the URL and filename safe 370 alphabet (i.e. base64url) defined in section 5 of Base-64 [RFC4648]. 371 This encoding is very wide-spread, falls smoothly into the encoding 372 rules defined in Section 4.1.1 of [RFC6265], and can be safely used 373 to supply SCS based authorization tokens within an URI (e.g. in a 374 query string or straight into a path segment). 376 3.2.4. Outbound Transform 378 The output data transformation as seen by the server (the only actor 379 which explicitly manipulates SCS cookies) is illustrated by the 380 pseudo-code in Figure 2. 382 1. IV := RAND() 383 2. ATIME := NOW 384 3. DATA := Enc(Comp(plain-text-cookie-value), IV) 385 4. AUTHTAG := HMAC(e(DATA)||e(ATIME)||e(TID)||e(IV)) 387 Figure 2 389 A new Initialization Vector is randomly picked (step 1.). As 390 previously mentioned (Section 3.1.4) this step is necessary to avoid 391 providing correlation information to an attacker. 393 A new ATIME value is taken as the current timestamp according to the 394 server clock (step 2.). 396 Since the only user of the ATIME field is the server, it is 397 unnecessary for it to be synchronized with the client -- though it 398 needs to use a fairly stable clock. However, if multiple servers are 399 active in a load-balancing configuration, clocks SHOULD be 400 synchronized to avoid errors in the calculation of session expiry. 402 The plain text cookie value is then compressed (if needed) and 403 encrypted by using the key-set identified by TID (step 3.). 405 If the length of (compressed) state is not a multiple of the block 406 size, its value MUST be filled with as many padding bytes of equal 407 value as the pad length -- as defined in the scheme of Section 6.3 of 408 [RFC5652]. 410 Then the authentication tag, which encompasses each SCS field (along 411 with lengths, and relative positions) is computed by HMAC'ing the 412 "|"-separated concatenation of their base64url representations using 413 the key-set identified by TID (step 4.). 415 Finally the SCS cookie-value is created as follows: 417 scs-cookie-value = e(DATA)||e(ATIME)||e(TID)||e(IV)||e(tag) 419 3.2.5. Inbound Transform 421 The inbound transformation is described in Figure 3. In it, each of 422 the 'e'-prefixed names has to be interpreted as the base64url encoded 423 value of the corresponding SCS field. 425 0. If (split_fields(scs-cookie-value) == ok) 426 1. tid' := d(eTID) 427 2. If (tid' is available) 428 3. tag' := d(eAUTHTAG) 429 4. tag := HMAC(eDATA||eATIME||eTID||eIV) 430 5. If (tag = tag') 431 6. atime' := d(eATIME) 432 7. If (NOW - atime' <= session_max_age) 433 8. iv' := d(eIV) 434 data' := d(eDATA) 435 9. state := Uncomp(Dec(data', iv')) 436 10. Else discard PDU 437 11. Else discard PDU 438 12. Else discard PDU 439 13. Else discard PDU 441 Figure 3 443 First of all, the inbound scs-cookie-value is broken into its 444 component fields which MUST be exactly 5, and each at least of the 445 minimum length specified in Figure 1 (step 0.). In case any of these 446 preliminary checks fails, the PDU is discarded (step 13.); else TID 447 is decoded to allow key-set lookup (step 1.). 449 If the cryptographic credentials (encryption and authentication 450 algorithms and keys identified by TID) are unavailable (step 12.), 451 the inbound SCS cookie is discarded since its value has no chance to 452 be interpreted correctly. This may happen for several reasons: e.g., 453 if a device without storage has been reset and loses the credentials 454 stored in RAM, if a server pool node desynchronizes, or in case of a 455 key compromise that forces the invalidation of all current TID's, 456 etc. 458 When a valid key-set is found (step 2.), the AUTHTAG field is decoded 459 (step 3.) and the (still) encoded DATA, ATIME, TID and IV fields are 460 supplied to the primitive that computes the authentication tag (step 461 4.). 463 If the tag computed using the local key-set matches the one carried 464 by the supplied SCS cookie, we can be confident that the cookie 465 carries authentic material; otherwise the SCS cookie is discarded 466 (step 11.). 468 Then the age of the SCS cookie (as deduced by ATIME field value and 469 current time provided by the server clock) is decoded and compared to 470 the maximum time-to-live defined by the session_max_age parameter. 472 In case the "age" check is passed, the DATA and IV fields are finally 473 decoded (step 8.), so that the original plain text data can be 474 extracted from the encrypted and optionally compressed blob (step 475 9.). 477 Note that steps 5. and 7. allow any altered packets or expired 478 sessions to be discarded, hence avoiding unnecessary state decryption 479 and decompression. 481 3.3. PDU Exchange 483 SCS can be modeled in the same manner as a typical store-and-forward 484 protocol, in which the endpoints are S, consisting of one or more 485 HTTP servers, and the client C, an intermediate node used to 486 "temporarily" store the data to be successively forwarded to S. 488 In brief, S and C exchange an immutable cookie data block 489 (Section 3.1): the state is stored on the client at the first hop and 490 then restored on the server at the second, as in Figure 4. 492 1. dump-state: 493 S --> C 494 Set-Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0... 495 Expires=...; Path=...; Domain=...; 497 2. restore-state: 498 C --> S 499 Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0... 501 Figure 4 503 3.3.1. Cookie Attributes 505 In the following sub paragraphs a series of recommendations is 506 provided in order to maximize SCS PDU fitness in the generic cookie 507 ecosystem. 509 3.3.1.1. Expires 511 SCS cookies MUST include an Expires attribute which shall be set to a 512 value consistent with session_max_age. 514 For maximum compatibility with existing user agents the timestamp 515 value MUST be encoded in rfc1123-date format which requires a 4-digit 516 year. 518 3.3.1.2. Max-Age 520 Since not all UAs support this attribute, it MUST NOT be present in 521 any SCS cookie. 523 3.3.1.3. Domain 525 SCS cookies MUST include a Domain attribute compatible with 526 application usage. 528 A trailing '.' MUST NOT be present in order to minimize the 529 possibility of a user agent ignoring the attribute value. 531 3.3.1.4. Secure 533 This attribute MUST always be asserted when SCS sessions are carried 534 over a TLS channel. 536 4. Key Management and Session State 538 This specification provides some common recommendations and practices 539 relevant to cryptographic key management. 541 In the following, the term 'key' references both encryption and HMAC 542 keys. 544 o The key SHOULD be generated securely following the randomness 545 recommendations in [RFC4086]; 547 o the key SHOULD only be used to generate and verify SCS PDUs; 549 o the key SHOULD be replaced regularly as well as any time the 550 format of SCS PDUs or cryptographic algorithms changes. 552 Furthermore, to preserve the validity of active HTTP sessions upon 553 renewal of cryptographic credentials (whenever the value of TID 554 changes), an SCS server MUST be capable of managing at least two 555 transforms contemporarily: the currently instantiated one, and its 556 predecessor. 558 Each transform set SHOULD be associated with an attribute pair: 559 "refresh" and "expiry", which is used to identify the exposure limits 560 (in terms of time or quantity of encrypted and/or authenticated 561 bytes, etc) of related cryptographic material. 563 In particular, the "refresh" attribute specifies the time limit for 564 substitution of transform set T with new material T'. From that 565 moment onwards, and for an amount of time determined by "expiry", all 566 new sessions will be created using T', while the active T-protected 567 ones go through a translation phase in which: 569 o the inbound transformation authenticates and decrypts/decompresses 570 using T (identified by TID); 572 o the outbound transformation encrypts/compresses and authenticates 573 using T'. 575 T' {not valid yet} |---------------------|---------------- 576 | translation stage | 577 T ----------------|---------------------| {no longer valid} 578 refresh refresh + expiry 580 Figure 5 582 As shown in Figure 5, the duration of the HTTP session MUST fit 583 within the lifetime of a given transform set (i.e. from creation time 584 until "refresh" + "expiry"). 586 In practice, this should not be an obstacle because the longevity of 587 the two entities (HTTP session and SCS transform set) should differ 588 by one or two orders of magnitude. 590 An SCS server may take this into account by determining the duration 591 of a session adaptively according to the expected deletion time of 592 the active T, or by setting the "expiry" value to at least the 593 maximum lifetime allowed by an HTTP session. 595 Since there is only one refresh attribute also in situations with 596 more than one key (e.g. one for encryption and one for 597 authentication) within the same T, the smallest value is chosen. 599 5. Cookie Size Considerations 601 In general, SCS cookies are bigger than their plain text 602 counterparts. This is due to a couple of different factors: 604 o inflation of the Base-64 encoding of the state data (approx. 1.4 605 times the original size, including the encryption padding), and 607 o the fixed size increment (approx. 80/90 bytes) due to SCS fields 608 and framing overhead. 610 While the former is a price the user must always pay proportionally 611 to the original data size, the latter is a fixed quantum, which can 612 be huge on small amounts of data, but is quickly absorbed as soon as 613 data becomes big enough. 615 The following table compares byte lengths of SCS cookies (with a four 616 bytes' TID) and corresponding plain text cookies in a worst case 617 scenario, i.e. when no compression is in use (or applicable). 619 plain | SCS 620 -------+------- 621 11 | 128 622 102 | 256 623 285 | 512 624 651 | 1024 625 1382 | 2048 626 2842 | 4096 628 The largest uncompressed cookie value that can be safely supplied to 629 SCS is about 2.8KB. 631 6. Acknowledgements 633 We would like to thank Jim Schaad, David Wagner and Lorenzo Cavallaro 634 for their valuable feedback on this document. 636 7. IANA Considerations 638 This memo includes no request to IANA. 640 8. Security Considerations 642 8.1. Security of the Cryptographic Protocol 644 From a cryptographic architecture perspective, the described 645 mechanism can be easily traced to an "encode then encrypt then MAC" 646 scheme (Encode-then-EtM) as described in [Kohno]. 648 Given a "provably-secure" encryption scheme and MAC (as for the 649 algorithms mandated in Section 3.2.1), Kohno et al. [Kohno] 650 demonstrate that their composition results in a secure authenticated 651 encryption scheme. 653 8.2. Impact of the SCS Cookie Model 655 The fact that the server does not own the cookie it produces, gives 656 rise to a series of consequences that must be clearly understood when 657 one envisages the use of SCS as a cookie provider and validator for 658 his/her application. 660 In the following paragraphs, a set of different attack scenarios 661 (together with corresponding countermeasures where applicable) are 662 identified and analyzed. 664 8.2.1. Old cookie replay 666 SCS doesn't address replay of old cookie values. 668 In fact, there is nothing that guarantees an SCS application about 669 the client having returned the most recent version of the cookie. 671 As with "server-side" sessions, if an attacker gains possession of a 672 given user's cookies - via simple passive interception or another 673 technique - he/she will always be able to restore the state of an 674 intercepted session by representing the captured data to the server. 676 The ATIME value along with the session_max_age configuration 677 parameter allow SCS to mitigate the chances of an attack (by forcing 678 a time window outside of which a given cookie is no longer valid), 679 but cannot exclude it completely. 681 A countermeasure against the "passive interception and replay" 682 scenario can be applied at transport/network level using the anti- 683 replay services provided by e.g., SSL/TLS [RFC5246] or IPsec 684 [RFC4301]. 686 Anyway, a generic solution is still out of scope: an SCS application 687 wishing to be replay-resistant must put in place some ad hoc 688 mechanism to prevent clients (both rogue and legitimate) from (a) 689 being able to replay old cookies as valid credentials and/or (b) 690 getting any advantage by replaying them. 692 In the following, some typical use cases are illustrated: 694 o Session inactivity timeout scenario (implicit invalidation): use 695 the session_max_age parameter if a global setting is viable, else 696 place an explicit TTL in the cookie (e.g. 697 validity_period="start_time, duration") that can be verified by 698 the application each time the Client presents the SCS cookie. 700 o Session voidance scenario (explicit invalidation): put a randomly 701 chosen string into each SCS cookie (cid="$(random())") and keep a 702 list of valid session cid's against which the SCS cookie presented 703 by the client can be checked. When a cookie needs to be 704 invalidated, delete the corresponding cid from the list. The 705 described method has the drawback that, in case a non-permanent 706 storage is used to archive valid cid's, a reboot/restart would 707 invalidate all sessions (It can't be used when |S| > 1). 709 o One-shot transaction scenario (ephemeral): this is a variation on 710 the previous theme when sessions are consumed within a single 711 request/response. Put a nonce="$(random())" within the state 712 information and keep a list of not-yet-consumed nonces in RAM. 713 Once the client presents its cookie credential, the embodied nonce 714 is deleted from the list and will be therefore discarded whenever 715 replayed. 717 It may be noteworthy that despite the chances of preventing replay in 718 some well established circumstances by using aforementioned 719 mechanisms, if the attacker is able to use the cookie before the 720 legitimate client gets a chance to, then the impersonation attack 721 will always succeed. 723 8.2.2. Cookie Deletion 725 A direct, and important, consequence of the missing owner role in SCS 726 is that a client could intentionally delete its cookie and return 727 nothing. 729 The application protocol has to be designed so there is no incentive 730 to do so, for instance: 732 o it is safe for the cookie to represent some kind of positive 733 capability - the possession of which increases the client's 734 powers; 736 o It is not safe to use the cookie to represent negative 737 capabilities - where possession reduces the client's powers-, or 738 for revocation. 740 Note that this behavior is not equivalent to cookie removal in the 741 "server-side" cookie model, because in case of missing cookie backup 742 by other parties (e.g. the application using SCS), the Client could 743 simply make it disappear once and for all. 745 8.2.3. Cookie Sharing or Theft 747 Just like with plain cookies, SCS doesn't prevent sharing (both 748 voluntary and illegitimate) of cookies between multiple clients. 750 In the context of voluntary cookie sharing, using HTTPS is useless: 751 Client certificates are just as shareable as cookies, hence 752 equivalently to the "server-side" cookie model, there seems to be no 753 way to prevent this threat. 755 The theft could be mitigated by securing the wire (e.g. via HTTPS, 756 IPsec, VPN, ...), thus reducing the opportunity of cookie stealing to 757 a successful attack on the protocol endpoints. 759 8.2.4. Session Fixation 761 Session fixation vulnerabilities [Kolsec] are not addressed by SCS. 763 A more sophisticated protocol involving an active participation by 764 the UA in the SCS cookie manipulation would be needed: e.g. some form 765 of challange-response exchange initiated by the Server on the HTTP 766 response and replied by the UA on the next chained HTTP request. 768 Unfortunately the present specification which bases on [RFC6265] sees 769 the UA as a completely passive character, whose role is to blindly 770 paste the cookie value set by the Server. 772 Nevertheless, the SCS cookies wrapping mechanism may be used in the 773 future as a building block for a more robust HTTP state management 774 protocol. 776 8.3. Advantages of SCS over Server-side Sessions 778 Note that all the above-mentioned vulnerabilities also apply to plain 779 cookies, making SCS at least as secure, but there are a few good 780 reasons to consider its security level enhanced. 782 First of all, the confidentiality and authentication features 783 provided by SCS protects the cookie-value which is normally plain 784 text and tamperable. 786 Furthermore, none of the common vulnerabilities of server-side 787 sessions (SID prediction, SID brute forcing) can be exploited when 788 using SCS, unless the attacker possesses encryption and HMAC keys 789 (both current ones and those relating to the previous set of 790 credentials). 792 More generally no slicing nor altering operations can be done over an 793 SCS PDU without controlling the cryptographic key-set. 795 9. References 797 9.1. Normative References 799 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 800 version 1.3", RFC 1951, May 1996. 802 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 803 Hashing for Message Authentication", RFC 2104, 804 February 1997. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 809 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 810 Requirements for Security", BCP 106, RFC 4086, June 2005. 812 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 813 Encodings", RFC 4648, October 2006. 815 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 816 RFC 5652, September 2009. 818 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 819 April 2011. 821 9.2. Informative References 823 [Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security 824 Without Collision-Resistance", 2006. 826 [Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure 827 Cryptographic Transforms, or How to Encrypt and MAC", 828 2003. 830 [Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based 831 Applications", 2002. 833 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 834 Architecture", RFC 3740, March 2004. 836 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 837 Internet Protocol", RFC 4301, December 2005. 839 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 840 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 842 Appendix A. Examples 844 The examples in this section have been created using the 'scs' test 845 tool bundled with LibSCS, a free and opensource reference 846 implementation of the SCS protocol that can be found at 847 . 849 A.1. No Compression 851 The following parameters: 853 o Plain text cookie: "a state string" 855 o AES-CBC-128 key: "cipher key" 857 o HMAC-SHA1 key: "hmac key" 859 o TID: "tid" 861 o ATIME: 1347043871 863 o IV: 864 \x13\xa0\x73\xca\x17\x15\xe1\x79\xaa\xd0\x11\xc4\x3d\x64\xeb\x99 866 produce the following tokens: 868 o DATA: PzGTlg3d0ttg4xweT6JmmA 870 o ATIME: MTM0NzA0Mzg3MQ 872 o TID: dGlk 874 o IV: E6BzyhcV4Xmq0BHEPWTrmQ 876 o AUTHTAG: GydWZ1jLnxVhnaXnPGwv8C5SMsE 878 A.2. Use Compression 880 The same parameters as above, except ATIME and IV: 882 o Plain text cookie: "a state string" 884 o AES-CBC-128 key: "cipher key" 886 o HMAC-SHA1 key: "hmac key" 888 o TID: "tid" 890 o ATIME: 1347044039 892 o IV: 893 \x01\x84\xef\xe8\x43\x66\xa1\x21\x2a\x8b\x80\x55\xf0\x7d\xf4\x18 895 produce the following tokens: 897 o DATA: DnZwvXWGIwQtD5oU4kdakEWIcNvugk-COrLP2l-Bvgs 899 o ATIME: MTM0NzA0NDAzOQ 901 o TID: dGlk 903 o IV: AYTv6ENmoSEqi4BV8H30GA 905 o AUTHTAG: q8gmgQK8TWU-wqas_TGDxZqy8PM 907 In both cases, the resulting SCS cookie is obtained via ordered 908 concatenation of the produced tokens, as described in Section 3.1. 910 Authors' Addresses 912 Stefano Barbato 913 KoanLogic 914 Via Marmolada, 4 915 Vitorchiano (VT), 01030 916 Italy 918 Email: tat@koanlogic.com 920 Steven Dorigotti 921 KoanLogic 922 Via Maso della Pieve 25/C 923 Bolzano, 39100 924 Italy 926 Email: stewy@koanlogic.com 928 Thomas Fossati (editor) 929 KoanLogic 930 Via di Sabbiuno 11/5 931 Bologna, 40136 932 Italy 934 Phone: +39 051 644 82 68 935 Email: tho@koanlogic.com