idnits 2.17.1 draft-secure-cookie-session-protocol-04.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 (August 13, 2012) is 4273 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: February 14, 2013 KoanLogic 6 August 13, 2012 8 SCS: Secure Cookie Sessions for HTTP 9 draft-secure-cookie-session-protocol-04 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, untampered material) and, as 25 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 February 14, 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 . . . . . . . . . . . . . . . . . . . . . 7 90 3.2.1. Cipher Set . . . . . . . . . . . . . . . . . . . . . . 8 91 3.2.2. Compression . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 13 103 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 106 8.1. Security of the Cryptographic Protocol . . . . . . . . . . 14 107 8.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 15 108 8.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 15 109 8.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . 17 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 116 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 117 A.1. No Compression . . . . . . . . . . . . . . . . . . . . . . 19 118 A.2. Use Compression . . . . . . . . . . . . . . . . . . . . . 19 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 211 Base-64 encoding of a specific SCS field, separated by its left 212 and/or right sibling by means of the %x7c ASCII character (i.e. '|'), 213 as follows: 215 scs-cookie = scs-cookie-name "=" scs-cookie-value 216 scs-cookie-name = token 217 scs-cookie-value = DATA "|" ATIME "|" TID "|" IV "|" AUTHTAG 218 DATA = 4*base64-character 219 ATIME = 4*base64-character 220 TID = 4*base64-character 221 IV = 4*base64-character 222 AUTHTAG = 4*base64-character 224 Figure 1 226 Confidentiality is limited to the application state information (i.e. 227 the DATA field), while integrity and authentication apply to the 228 entire cookie-value. 230 The following subsections describe the syntax and semantics of each 231 SCS cookie field. 233 3.1.1. ATIME 235 Absolute timestamp relating to the last read or write operation 236 performed on session DATA, encoded as a HEX string holding the number 237 of seconds since UNIX epoch (i.e. since 00:00:00, Jan 1 1970.) 239 This value is updated with each client contact and is used to 240 identify expired sessions. If the delta between the received ATIME 241 value and the current time on S, is larger than a predefined 242 "session_max_age" (which is chosen by S as an application-level 243 parameter), a session is considered to be no longer valid, and is 244 therefore rejected. 246 Such an expiration error may be used to force user logout from an SCS 247 cookie based session, or hooked in the web application logics to the 248 display of a HTML form asking re-validation of user credentials. 250 3.1.2. DATA 252 Block of encrypted and optionally compressed data, possibly 253 containing the current session state. Note that no restriction is 254 imposed on clear text structure: the protocol is completely agnostic 255 as to inner data layout. 257 Generally speaking, the plain text is the "normal" cookie that would 258 have been exchanged by S and C if SCS wasn't used. 260 3.1.3. TID 262 This identifier is equivalent to a SPI in a Data Security SA 263 [RFC3740]) and consists of an ASCII string that uniquely identifies 264 the transform set (keys and algorithms) used to generate this SCS 265 cookie. 267 SCS assumes that a key-agreement/distribution mechanism exists for 268 environments in which S consists of multiple servers, which provides 269 a unique external identifier for each transform set shared amongst 270 pool members. 272 Please note that the said mechanism may safely downgrade to a 273 periodic key-refresh in case there is one only server in the pool and 274 key is generated in place -- i.e. it is not handled from an external 275 source. 277 3.1.4. IV 279 Initialization Vector used for the encryption algorithm 280 (Section 3.2). 282 In order to avoid providing correlation information to a possible 283 attacker with access to a sample of SCS cookies created using the 284 same TID, the IV MUST be created randomly for each SCS cookie. 286 3.1.5. AUTHTAG 288 Authentication tag based on the concatenation of DATA, ATIME, TID and 289 IV fields encoded in Base-64, framed by the "|" separator: 291 AUTHTAG = HMAC(base64(DATA) || "|" || 292 base64(ATIME) || "|" || 293 base64(TID) || "|" || 294 base64(IV)) 296 Note that, from a cryptographic point of view, the "|" character 297 provides explicit authentication of the length of each supplied 298 field, which results in a robust countermeasure against splicing 299 attacks. 301 3.2. Crypto Transform 303 SCS could potentially use any combination of primitives capable of 304 performing authenticated encryption. In practice an encrypt-then-mac 305 approach [Kohno] with CBC-mode encryption and HMAC [RFC2104] 306 authentication was chosen. 308 The two algorithms MUST be associated with two independent keys. 310 The following conventions will be used in the algorithm description 311 (Section 3.2.4 and Section 3.2.5): 313 o Enc/Dec(): block encryption/decryption functions (Section 3.2.1); 315 o HMAC(): authentication function (Section 3.2.1); 317 o Comp/Uncomp(): compression/decompression functions 318 (Section 3.2.2); 320 o e/d(): cookie value encoding/decoding functions (Section 3.2.3); 322 o ||: concatenation operator, i.e. "|" char; 324 o RAND(): random number generator [RFC4086]. 326 3.2.1. Cipher Set 328 Implementors MUST support at least the following algorithms: 330 o AES-CBC-128 for encryption; 332 o HMAC-SHA1 with a 128 bit key for authenticity and integrity, 334 which appear to be sufficiently secure in a wide range of use cases 335 [Bellare], are widely available, and can be implemented in a few 336 kilobytes of memory, providing an extremely valuable feature in 337 constrained devices. 339 One should consider using larger cryptographic key lengths (192 or 340 256 bit) according to the actual security and overall system 341 performance requirements. 343 3.2.2. Compression 345 Compression, which may be useful or even necessary when handling 346 large quantities of data, is not compulsory (in such case Comp/Uncomp 347 are replaced by an identity matrix). If this function is enabled, 348 DEFLATE [RFC1951] format MUST be supported. 350 Some advice to SCS users: compression should not be enabled when 351 handling relatively short and entropic state such as pseudo random 352 session identifiers. Instead, large and quite regular state blobs 353 could get a significant boost when compressed. 355 3.2.3. Cookie Encoding 357 SCS cookie values MUST be encoded using the URL and filename safe 358 alphabet (i.e. base64url) defined in section 5 of Base-64 [RFC4648]. 359 This encoding is very wide-spread, falls smoothly into the encoding 360 rules defined in Section 4.1.1 of [RFC6265], and can be safely used 361 to supply SCS based authorization tokens within an URI (e.g. in a 362 query string or straight into a path segment). 364 3.2.4. Outbound Transform 366 The output data transformation as seen by the server (the only actor 367 which explicitly manipulates SCS cookies) is illustrated by the 368 pseudo-code in Figure 2. 370 1. IV := RAND() 371 2. ATIME := NOW 372 3. DATA := Enc(Comp(plain-text-cookie-value), IV) 373 4. AUTHTAG := HMAC(e(DATA)||e(ATIME)||e(TID)||e(IV)) 375 Figure 2 377 A new Initialization Vector is randomly picked (step 1.). As 378 previously mentioned (Section 3.1.4) this step is necessary to avoid 379 providing correlation information to an attacker. 381 A new ATIME value is taken as the current timestamp according to the 382 server clock (step 2.). 384 Since the only user of the ATIME field is the server, it is 385 unnecessary for it to be synchronized with the client -- though it 386 needs to be a fairly stable clock. However, if multiple servers are 387 active in a load-balancing configuration, clocks SHOULD be 388 synchronized to avoid errors in the calculation of session expiry. 390 The plain text cookie value is then compressed (if needed) and 391 encrypted by using the key-set identified by TID (step 3.). 393 If the length of (compressed) state is not a multiple of the block 394 size, its value MUST be filled with as many padding bytes of equal 395 value as the pad length -- as defined in the scheme of Section 6.3 of 396 [RFC5652]. 398 Then the authentication tag, which encompasses each SCS field (along 399 with lengths, and relative positions) is computed by HMAC'ing the 400 "|"-separated concatenation of their base64 representations using the 401 key-set identified by TID (step 4.). 403 Finally the SCS cookie-value is created as follows: 405 scs-cookie-value = e(DATA)||e(ATIME)||e(TID)||e(IV)||e(tag) 407 3.2.5. Inbound Transform 409 The inbound transformation is described in Figure 3. In it, each of 410 the 'e'-prefixed names has to be interpreted as the base64url encoded 411 value of the corresponding SCS field. 413 0. If (split_fields(scs-cookie-value) == ok) 414 1. tid' := d(eTID) 415 2. If (tid' is available) 416 3. tag' := d(eAUTHTAG) 417 4. tag := HMAC(eDATA||eATIME||eTID||eIV) 418 5. If (tag = tag') 419 6. atime' := d(eATIME) 420 7. If (NOW - atime' <= session_max_age) 421 8. iv' := d(eIV) 422 data' := d(eDATA) 423 9. state := Uncomp(Dec(data', iv')) 424 10. Else discard PDU 425 11. Else discard PDU 426 12. Else discard PDU 427 13. Else discard PDU 429 Figure 3 431 First of all, the inbound scs-cookie-value is broken into its 432 component fields which MUST be exactly 5, and each at least of the 433 minimum length specified in Figure 1 (step 0.). In case any of these 434 preliminary checks fails, the PDU is discarded (step 13.); else TID 435 is decoded to allow key-set lookup (step 1.). 437 If the cryptographic credentials (encryption and authentication 438 algorithms and keys identified by TID) are unavailable (step 12.), 439 the inbound SCS cookie is discarded as its value has no chance to be 440 interpreted correctly. This may happen for several reasons: e.g., if 441 a device without storage has been reset and loses the credentials 442 stored in RAM, if a server pool node desynchronizes, or in case of a 443 key compromise that forces the invalidation of all current TID's, 444 etc. 446 When a valid key-set is found (step 2.), the AUTHTAG field is decoded 447 (step 3.) and the (still) encoded DATA, ATIME, TID and IV fields are 448 supplied to the primitive that computes the authentication tag (step 449 4.). 451 If the tag computed using the local key-set matches the one carried 452 by the supplied SCS cookie, we can be confident that the cookie 453 carries authentic material; otherwise the SCS cookie is discarded 454 (step 11.). 456 Then the age of the SCS cookie (as deduced by ATIME field value and 457 current time provided by the server clock) is decoded and compared to 458 the maximum time-to-live defined by the session_max_age parameter. 460 In case the "age" check is passed, the DATA and IV fields are finally 461 decoded (step 8.), so that the original plain text data can be 462 extracted from the encrypted and optionally compressed blob (step 463 9.). 465 Note that steps 5. and 7. allow any altered packets or expired 466 sessions to be discarded, hence avoiding unnecessary state decryption 467 and decompression. 469 3.3. PDU Exchange 471 SCS can be modeled in the same manner as a typical store-and-forward 472 protocol, in which the endpoints are S, consisting of one or more 473 HTTP servers, and the client C, an intermediate node used to 474 "temporarily" store the data to be successively forwarded to S. 476 In brief, S and C exchange an immutable cookie data block 477 (Section 3.1): the state is stored on the client at the first hop and 478 then restored on the server at the second, as in Figure 4. 480 1. dump-state: 481 S --> C 482 Set-Cookie: ANY_COOKIE_NAME=BO2zHC0tRg76axnguyuK5g==|MTI5... 483 Expires=...; Path=...; Domain=...; 485 2. restore-state: 486 C --> S 487 Cookie: ANY_COOKIE_NAME=BO2zHC0tRg76axnguyuK5g==|MTI5... 489 Figure 4 491 3.3.1. Cookie Attributes 493 In the following sub paragraphs a series of recommendations is 494 provided in order to maximize SCS PDU fitness in the generic cookie 495 ecosystem. 497 3.3.1.1. Expires 499 SCS cookies MUST include an Expires attribute which shall be set to a 500 value consistent with session_max_age. 502 For maximum compatibility with existing user agents the timestamp 503 value MUST be encoded in rfc1123-date format which requires a 4-digit 504 year. 506 3.3.1.2. Max-Age 508 Since not all UAs support this attribute, it MUST NOT be present in 509 any SCS cookie. 511 3.3.1.3. Domain 513 SCS cookies MUST include a Domain attribute compatible with 514 application usage. 516 A trailing '.' MUST NOT be present in order to minimize the 517 possibility of a user agent ignoring the attribute value. 519 3.3.1.4. Secure 521 This attribute MUST always be asserted when SCS sessions are carried 522 over a TLS channel. 524 4. Key Management and Session State 526 This specification provides some common recommendations and practices 527 relevant to cryptographic key management. 529 In the following, the term 'key' references both encryption and HMAC 530 keys. 532 o The key SHOULD be generated securely following the randomness 533 recommendations in [RFC4086]; 535 o the key SHOULD only be used to generate and verify SCS PDUs; 537 o the key SHOULD be replaced regularly as well as any time the 538 format of SCS PDUs or cryptographic algorithms changes. 540 Furthermore, to preserve the validity of active HTTP sessions upon 541 renewal of cryptographic credentials (whenever the value of TID 542 changes), an SCS server MUST be capable of managing at least two 543 transforms contemporarily: the currently instantiated one, and its 544 predecessor. 546 Each transform set SHOULD be associated with an attribute pair: 547 "refresh" and "expiry", which is used to identify the exposure limits 548 (in terms of time or quantity of encrypted and/or authenticated 549 bytes, etc) of related cryptographic material. 551 In particular, the "refresh" attribute specifies the time limit for 552 substitution of transform set T with new material T'. From that 553 moment onwards, and for an amount of time determined by "expiry", all 554 new sessions will be created using T', while the active T-protected 555 ones go through a translation phase in which: 557 o the inbound transformation authenticates and decrypts/decompresses 558 using T (identified by TID); 560 o the outbound transformation encrypts/compresses and authenticates 561 using T'. 563 T' {not valid yet} |---------------------|---------------- 564 | translation stage | 565 T ----------------|---------------------| {no longer valid} 566 refresh refresh + expiry 568 Figure 5 570 As shown in Figure 5, the duration of the HTTP session MUST fit 571 within the lifetime of a given transform set (i.e. from creation time 572 until "refresh" + "expiry"). 574 In practice, this should not be an obstacle because the longevity of 575 the two entities (HTTP session and SCS transform set) should differ 576 by one or two orders of magnitude. 578 An SCS server may take this into account by determining the duration 579 of a session adaptively according to the expected deletion time of 580 the active T, or by setting the "expiry" value to at least the 581 maximum lifetime allowed by an HTTP session. 583 Since there is only one refresh attribute also in situations with 584 more than one key (e.g. one for encryption and one for 585 authentication) within the same T, the smallest value is chosen. 587 5. Cookie Size Considerations 589 In general, SCS cookies are bigger than their plain text 590 counterparts. This is due to a couple of different factors: 592 o inflation of the Base-64 encoding of the state data (approx. 1.4 593 times the original size, including the encryption padding), and 595 o the fixed size increment (approx. 80/90 bytes) due to SCS fields 596 and framing overhead. 598 While the former is a price the user must always pay proportionally 599 to the original data size, the latter is a fixed quantum, which can 600 be huge on small amounts of data, but is quickly absorbed as soon as 601 data becomes big enough. 603 The following table compares byte lengths of SCS cookies (with a four 604 bytes' TID) and corresponding plain text cookies in a worst case 605 scenario, i.e. when no compression is in use (or applicable). 607 plain | SCS 608 -------+------- 609 11 | 128 610 102 | 256 611 285 | 512 612 651 | 1024 613 1382 | 2048 614 2842 | 4096 616 The largest uncompressed cookie value that can be safely supplied to 617 SCS is about 2.8KB. 619 6. Acknowledgements 621 We would like to thank Jim Schaad, David Wagner and Lorenzo Cavallaro 622 for their valuable feedback on this document. 624 7. IANA Considerations 626 This memo includes no request to IANA. 628 8. Security Considerations 630 8.1. Security of the Cryptographic Protocol 632 From a cryptographic architecture perspective, the described 633 mechanism can be easily traced to an Encode-then-EtM scheme described 634 in [Kohno]. 636 Given a "provably-secure" encryption scheme and MAC (as for the 637 algorithms mandated in Section 3.2.1), Kohno et al. [Kohno] 638 demonstrate that their composition results in a secure authenticated 639 encryption scheme. 641 8.2. Impact of the SCS Cookie Model 643 The fact that the server does not own the cookie it produces, gives 644 rise to a series of consequences that must be clearly understood when 645 one envisages the use of SCS as a cookie provider and validator for 646 his/her application. 648 In the following paragraphs, a set of different attack scenarios 649 (together with corresponding countermeasures where applicable) are 650 identified and analyzed. 652 8.2.1. Old cookie replay 654 SCS doesn't address replay of old cookie values. 656 In fact, there is nothing that guarantees an SCS application about 657 the client having returned the most recent version of the cookie. 659 As with "server-side" sessions, if an attacker gains possession of a 660 given user's cookies - via simple passive interception or another 661 technique - he/she will always be able to restore the state of an 662 intercepted session by representing the captured data to the server. 664 The ATIME value along with the session_max_age configuration 665 parameter allow SCS to mitigate the chances of an attack (by forcing 666 a time window outside of which a given cookie is no longer valid), 667 but cannot exclude it completely. 669 A countermeasure against the "passive interception and replay" 670 scenario can be applied at transport/network level using the anti- 671 replay services provided by e.g., SSL/TLS [RFC5246] or IPsec 672 [RFC4301]. 674 Anyway, a generic solution is still out of scope: an SCS application 675 wishing to be replay-resistant must put in place some ad hoc 676 mechanism to prevent clients (both rogue and legitimate) from (a) 677 being able to replay old cookies as valid credentials and/or (b) 678 getting any advantage by replaying them. 680 In the following, some typical use cases are illustrated: 682 o Session inactivity timeout scenario (implicit invalidation): use 683 the session_max_age parameter if a global setting is viable, else 684 place an explicit TTL in the cookie (e.g. 685 validity_period="start_time, duration") that can be verified by 686 the application each time the Client presents the SCS cookie. 688 o Session voidance scenario (explicit invalidation): put a randomly 689 chosen string into each SCS cookie (cid="$(random())") and keep a 690 list of valid session cid's against which the SCS cookie presented 691 by the client can be checked. When a cookie needs to be 692 invalidated, delete the corresponding cid from the list. The 693 described method has the drawback that, in case a non-permanent 694 storage is used to archive valid cid's, a reboot/restart would 695 invalidate all sessions (It can't be used when |S| > 1). 697 o One-shot transaction scenario (ephemeral): this is a variation on 698 the previous theme when sessions are consumed within a single 699 request/response. Put a nonce="$(random())" within the state 700 information and keep a list of not-yet-consumed nonces in RAM. 701 Once the client presents its cookie credential, the embodied nonce 702 is deleted from the list and will be therefore discarded whenever 703 replayed. 705 It may be noteworthy that despite the chances of preventing replay in 706 some well established circumstances by using aforementioned 707 mechanisms, if the attacker is able to use the cookie before the 708 legitimate client gets a chance to, then the impersonation attack 709 will always succeed. 711 8.2.2. Cookie Deletion 713 A direct, and important, consequence of the missing owner role in SCS 714 is that a client could intentionally delete its cookie and return 715 nothing. 717 The application protocol has to be designed so there is no incentive 718 to do so, for instance: 720 o it is safe for the cookie to represent some kind of positive 721 capability - the possession of which increases the client's 722 powers; 724 o It is not safe to use the cookie to represent negative 725 capabilities - where possession reduces the client's powers-, or 726 for revocation. 728 Note that this behavior is not equivalent to cookie removal in the 729 "server-side" cookie model, because in case of missing cookie backup 730 by other parties (e.g. the application using SCS), the Client could 731 simply make it disappear once and for all. 733 8.2.3. Cookie Sharing or Theft 735 Just like with plain cookies, SCS doesn't prevent sharing (both 736 voluntary and illegitimate) of cookies between multiple clients. 738 In the context of voluntary cookie sharing, using HTTPS is useless: 739 Client certificates are just as shareable as cookies, hence 740 equivalently to the "server-side" cookie model, there seems to be no 741 way to prevent this threat. 743 The theft could be mitigated by securing the wire (e.g. via HTTPS, 744 IPsec, VPN, ...), thus reducing the opportunity of cookie stealing to 745 a successful attack on the protocol endpoints. 747 8.2.4. Session Fixation 749 Session fixation vulnerabilities [Kolsec] are not addressed by SCS. 751 A more sophisticated protocol involving an active participation by 752 the UA in the SCS cookie manipulation would be needed: e.g. some form 753 of challange-response exchange initiated by the Server on the HTTP 754 response and replied by the UA on the next chained HTTP request. 756 Unfortunately the present specification which bases on [RFC6265] sees 757 the UA as a completely passive character, whose role is to blindly 758 paste the cookie value set by the Server. 760 Nevertheless, the SCS cookies wrapping mechanism may be used in the 761 future as a building block for a more robust HTTP state management 762 protocol. 764 8.3. Advantages of SCS over Server-side Sessions 766 Note that all the above-mentioned vulnerabilities also apply to plain 767 cookies, making SCS at least as secure, but there are a few good 768 reasons to consider its security level enhanced. 770 First of all, the confidentiality and authentication features 771 provided by SCS protects the cookie-value which is normally plain 772 text and tamperable. 774 Furthermore, none of the common vulnerabilities of server-side 775 sessions (SID prediction, SID brute forcing) can be exploited when 776 using SCS, unless the attacker possesses encryption and HMAC keys 777 (both current ones and those relating to the previous set of 778 credentials). 780 More generally no slicing nor altering operations can be done over an 781 SCS PDU without controlling the cryptographic key-set. 783 9. References 785 9.1. Normative References 787 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 788 version 1.3", RFC 1951, May 1996. 790 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 791 Hashing for Message Authentication", RFC 2104, 792 February 1997. 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, March 1997. 797 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 798 Requirements for Security", BCP 106, RFC 4086, June 2005. 800 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 801 Encodings", RFC 4648, October 2006. 803 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 804 RFC 5652, September 2009. 806 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 807 April 2011. 809 9.2. Informative References 811 [Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security 812 Without Collision-Resistance", 2006. 814 [Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure 815 Cryptographic Transforms, or How to Encrypt and MAC", 816 2003. 818 [Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based 819 Applications", 2002. 821 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 822 Architecture", RFC 3740, March 2004. 824 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 825 Internet Protocol", RFC 4301, December 2005. 827 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 828 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 830 Appendix A. Examples 832 The examples in this section have been created using the 'scs' test 833 tool bundled with LibSCS, a free and opensource reference 834 implementation of the SCS protocol that can be found at 835 . 837 A.1. No Compression 839 The following parameters: 841 o Plain text cookie: "a state string" 843 o AES-CBC-128 key: "cipher key" 845 o HMAC-SHA1 key: "hmac key" 847 o TID: "tid" 849 o ATIME: 1323898800 851 o IV: 852 \xd1\x02\xfc\xca\xbf\x05\x03\xb1\xf4\x4f\x1f\xfd\x6d\x12\x5c\x66 854 produce the following tokens: 856 o DATA: GJRz3N0cuPKTumCqjtVjgw%3D%3D 858 o ATIME: MTMyMzg5ODgwMA%3D%3D 860 o TID: dGlk 862 o IV: 0QL8yr8FA7H0Tx_9bRJcZg%3D%3D 864 o AUTHTAG: ktKOYXnTjrCzXgxGH__dWXUZAJ8%3D 866 A.2. Use Compression 868 The same parameters as above, except ATIME and IV: 870 o Plain text cookie: "a state string" 872 o AES-CBC-128 key: "cipher key" 873 o HMAC-SHA1 key: "hmac key" 875 o TID: "tid" 877 o ATIME: 1323899388 879 o IV: 880 \x72\x6f\x00\x2e\x4c\xf3\x6d\xfd\xf1\x1f\x92\xcf\x12\x8e\xe7\x8b 882 produce the following tokens: 884 o DATA: XaLWZDoFmv9vYF8wYYYxeXtCkUYAwbzpCfBWBzAy3Y8%3D 886 o ATIME: MTMyMzg5OTM4OA%3D%3D 888 o TID: dGlk 890 o IV: cm8ALkzzbf3xH5LPEo7niw%3D%3D 892 o AUTHTAG: K_rig5ZxGz_aGPQkyAb8JRMcTUY%3D 894 In both cases, the resulting SCS cookie is obtained via ordered 895 concatenation of the produced tokens, as described in Section 3.1. 897 Authors' Addresses 899 Stefano Barbato 900 KoanLogic 901 Via Marmolada, 4 902 Vitorchiano (VT), 01030 903 Italy 905 Email: tat@koanlogic.com 907 Steven Dorigotti 908 KoanLogic 909 Via Maso della Pieve 25/C 910 Bolzano, 39100 911 Italy 913 Email: stewy@koanlogic.com 914 Thomas Fossati (editor) 915 KoanLogic 916 Via di Sabbiuno 11/5 917 Bologna, 40136 918 Italy 920 Phone: +39 051 644 82 68 921 Email: tho@koanlogic.com