idnits 2.17.1 draft-secure-cookie-session-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2011) is 4806 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-httpstate-cookie-22 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: August 25, 2011 KoanLogic 6 February 21, 2011 8 SCS: Secure Cookie Sessions for HTTP 9 draft-secure-cookie-session-protocol-00 11 Abstract 13 This document provides an overview of SCS, a cryptographic protocol 14 layered on top of the HTTP cookie facility, that allows an origin 15 server to handle session state without storing it locally. 17 Its typical use cases include devices with little or no storage 18 offering some functionality via an HTTP interface, and web 19 applications with High Availability or load balancing requirements 20 which may want to handle application state without the need to 21 synchronize the pool through shared storage or peering. 23 Nevertheless, its security properties allow it to be used whenever 24 privacy and integrity of cookies is a concern, at the cost of 25 increased server CPU and bandwidth usage, and of some "credential- 26 ownership" implications which will be thoroughly analysed. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 25, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 64 3. SCS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. PDU Description . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.1. SCS_ATIME . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. SCS_DATA . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1.3. SCS_TID . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1.4. SCS_IV . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.5. SCS_AUTHTAG . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. Crypto Transform . . . . . . . . . . . . . . . . . . . . . 7 72 3.2.1. Cipher Set . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2.2. Compression . . . . . . . . . . . . . . . . . . . . . 8 74 3.2.3. Cookie Encoding . . . . . . . . . . . . . . . . . . . 8 75 3.2.4. Outbound Transform . . . . . . . . . . . . . . . . . . 8 76 3.2.5. Inbound Transform . . . . . . . . . . . . . . . . . . 9 77 3.3. PDU Exchange . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.3.1. Cookie Attributes . . . . . . . . . . . . . . . . . . 10 79 3.3.1.1. Expires . . . . . . . . . . . . . . . . . . . . . 11 80 3.3.1.2. Max-Age . . . . . . . . . . . . . . . . . . . . . 11 81 3.3.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . 11 82 3.3.1.4. Secure . . . . . . . . . . . . . . . . . . . . . . 11 83 4. Key Management and Session State . . . . . . . . . . . . . . . 11 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Security of the Cryptographic Protocol . . . . . . . . . . 13 88 7.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 13 89 7.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 13 90 7.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 15 91 7.2.3. Cookie Sharing or Theft . . . . . . . . . . . . . . . 15 92 7.3. Advantages of SCS over Server-side Sessions . . . . . . . 15 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 96 Appendix A. Reference Implementation . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 SCS is a cryptographic protocol layered on top of the HTTP cookie 102 facility [I-D.ietf-httpstate-cookie], that allows an origin server to 103 handle clients' session state without storing it locally. 105 An SCS enabled server delegates the application state storage to the 106 client (e.g. a browser) - which basically acts as a remote storage 107 device. A set of cryptographic transformations is used to ensure 108 that information authenticity and confidentiality attributes of state 109 data have the same characteristics as for typical "server-side" 110 sessions. 112 Anyway, a peculiar difference between SCS and "server-side" cookie 113 sessions arises when we carefully consider the roles of the playing 114 entities. In the "server-side" model, the Server acts a triple role 115 as the "generator", the "owner", and the "verifier" of cookie 116 credentials. Instead, a server implementing SCS acts the "generator" 117 and "verifier" roles only -- the "owner" being inapplicable as long 118 as we have imposed the no-storage requirement. 120 In all respects, the Server grants the custody of the generated 121 cookie to the Client, whose trust model needs to be taken into 122 consideration when designing applications using SCS. The 123 consequences of such discrepancy (e.g. deliberate deletion of a 124 cookie, explicit privilege revocation, etc.) will be explored and 125 analyzed in Section 7.2. 127 The no-storage requirement, which is the key design constraint of 128 SCS, makes it an ideal candidate in the following settings: 130 a. devices with little or no storage -- typically embedded devices 131 which provide functionality such as software updates, 132 configuration, device monitoring, etc. via an HTTP interface; 134 b. web applications with HA or load balancing requirements, which 135 may delegate handling of the application state to clients instead 136 of using shared storage or forced peering, to enhance overall 137 parallelism. 139 An SCS server can be implemented within a web application by means of 140 a user library that exposes the core SCS functionality and leaves 141 explicit control over SCS cookies to the programmer, or 142 transparently, by hiding the "diskless session" facility behind a 143 generic session API abstraction. 145 2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. SCS Protocol 153 The SCS protocol defines: 155 o a PDU, as a well-defined aggregate of cookies (Section 3.1); 157 o the cryptographic transformations which manipulate the PDU field 158 (Section 3.2); 160 o the HTTP-based PDU exchange model (Section 3.3). 162 Note that the PDU is transmitted to the client as an opaque data 163 block, hence no interpretation nor validation is necessary. 165 The single requirement for client-side support of SCS is cookie 166 activation on the browser. Only the server is involved in the PDU 167 manipulation process. 169 In the following sections we assume S to be one or more 170 interchangeable HTTP server entities (e.g. a server pool in a load- 171 balanced or HA environment) and C to be the client with a cookie- 172 enabled browser, or User Agent with equivalent capabilities. 174 3.1. PDU Description 176 S and C exchange the same PDU (Section 3.3), which consists of a set 177 of interdependent cookies tied together by cryptographic 178 transformations. 180 Confidentiality is limited to the application state information (i.e. 181 SCS_DATA cookie), while integrity and authentication apply to the 182 entire PDU. 184 The following subsections describe the syntax and semantics of of 185 each SCS cookie. 187 3.1.1. SCS_ATIME 189 Timestamp relating to the last read or write operation performed on 190 session data, encoded a numeric string holding the number of seconds 191 since UNIX epoch. 193 This value is updated with each client contact and is used to 194 identify expired sessions. 196 If the received SCS_ATIME value is older than a predefined 197 "session_max_age" (which is chosen by S as an application-level 198 parameter), a session is considered to be no longer valid, and is 199 therefore rejected. 201 3.1.2. SCS_DATA 203 Block of encrypted and optionally compressed data, containing session 204 state. Note that no restriction is imposed on plain text structure: 205 the protocol is completely agnostic as to state data layout. 207 If the total size of the SCS_DATA cookie, including name, value and 208 attributes, exceeds 4096 bytes (see Section 6.1. of 209 [I-D.ietf-httpstate-cookie]), it is sliced into n SCS_DATA{n} 210 cookies, each 4KB in size, so that the concatenation of their values 211 ordered by cookie name (1, 2, ..., N) yields the original SCS_DATA. 213 It is suggested [I-D.ietf-httpstate-cookie] that browsers accept at 214 least 50 cookies per domain, which could lead to a theoretical limit 215 of 184 KB as the maximum allowed state data block. 217 Anyway, in order to minimize both network bandwidth and client cookie 218 store consumption, applications should try to upper bound state data 219 to some sensible value. Also, an SCS implementation MAY decide to 220 limit the accepted state data to any value greater than or equal to 221 4KB. 223 3.1.3. SCS_TID 225 ASCII string that uniquely identifies the transform set (keys and 226 algorithms) used to generate this PDU. 228 SCS assumes that a key-agreement/distribution mechanism exists for 229 environments in which S consists of multiple servers (it may consist 230 of a simple key-refresh in the case |S|=1), which provides a unique 231 external identifier for each transform set defined and shared amongst 232 pool members. 234 This identifier (equivalent to a SPI in a Data Security SA [RFC3740]) 235 is represented in the cookie value. 237 3.1.4. SCS_IV 239 Initialization Vector used for the encryption algorithm 240 (Section 3.2). 242 In order to avoid providing correlation information to a possible 243 attacker with access to a sample of SCS PDUs, the IV MUST be created 244 randomly for each PDU. 246 3.1.5. SCS_AUTHTAG 248 Authentication tag based on the concatenation of SCS_ATIME, SCS_DATA, 249 SCS_TID and SCS_IV. 251 The concatenation operation is done by packing the four strings 252 containing the base64 encoded values in order (e.g.: 253 "ZGF0YQ==YXRpbWU=dGlkaXY="), and supplying the resulting string to 254 HMAC. 256 3.2. Crypto Transform 258 SCS could potentially use any combination of primitives capable of 259 performing authenticated encryption. In practice an encrypt-then-mac 260 approach [Kohno] with CBC-mode encryption and HMAC [RFC2104] 261 authentication was chosen. 263 The two algorithms MUST be associated with two independent keys. 265 The possibility of using UMAC for authentication [RFC4418] has been 266 taken into consideration, but priority was given to space over 267 performance: the nonce field transfer would require an extra cookie, 268 therefore reducing the space reserved to state information by another 269 4KB. 271 The following conventions will be used in the algorithm description 272 (Section 3.2.4 and Section 3.2.5): 274 o Enc/Dec(): block encryption/decryption functions (Section 3.2.1); 276 o HMAC(): authentication function (Section 3.2.1); 278 o Comp/Uncomp(): compression/decompression functions 279 (Section 3.2.2); 281 o e/d(): cookie value encoding/decoding functions (Section 3.2.3); 283 o RAND(): random number generator [RFC4086]. 285 3.2.1. Cipher Set 287 Implementors MUST support at least the following algorithms: 289 o AES-CBC-128 for encryption; 291 o HMAC-SHA1 with a 128 bit key for authenticity and integrity, 293 which appear to be sufficiently secure in a wide range of use cases 294 [Bellare], are widely available, and can be implemented in a few 295 kilobytes of memory, providing an extremely valuable feature in 296 constrained devices. 298 One should consider using larger cryptographic key lengths (192 or 299 256 bit) according to the actual security and overall system 300 performance requirements. 302 3.2.2. Compression 304 Compression, which may be useful or even necessary when handling 305 large quantities of data, is not compulsory (in such case Comp/Uncomp 306 are replaced by an identity matrix). If this function is enabled, 307 DEFLATE [RFC1951] format MUST be supported. 309 Compression should not be enabled when handling relatively short and 310 entropic state (e.g. pseudo random session identifiers). Instead, 311 large and quite regular state blobs could get a significant boost 312 when compressed. 314 3.2.3. Cookie Encoding 316 Base-64 [RFC4648] is used for encoding/decoding of SCS cookie values. 317 It is very wide-spread, and falls smoothly into the encoding rules 318 defined in Section 4.1.1 of [I-D.ietf-httpstate-cookie]. 320 3.2.4. Outbound Transform 322 The output data transformation as seen by the server (the only actor 323 which manipulates PDUs) is illustrated by the pseudo-code in 324 Figure 1. 326 1. iv = RAND() 327 2. atime = NOW 328 3. data = Enc(Comp(state)) 329 4. tag = HMAC(e(data)||e(atime)||e(tid)||e(iv)) 331 Figure 1 333 NOW is defined as the current timestamp of the server clock. 335 Since the only user of the atime field is the server, it is 336 unnecessary for it to be synchronized with the client. However, if 337 multiple servers are active in a load-balancing configuration, clocks 338 SHOULD be synchronized to avoid errors in the calculation of session 339 expiry. 341 If the length of (compressed) state is not a multiple of the block 342 size, its value MUST be filled with padding bytes of equal value as 343 the pad length -- equivalent to the scheme defined in Section 6.3 of 344 [RFC5652]. 346 Hence the SCS PDU fields are created as follows: 348 SCS_ATIME = e(atime) 349 SCS_AUTHTAG = e(tag) 350 SCS_DATA = e(data) 351 SCS_TID = e(tid) 352 SCS_IV = e(iv) 354 3.2.5. Inbound Transform 356 The inbound transformation is described in Figure 2. 358 1. If (tid is available) 359 2. data' = d($SCS_DATA) 360 atime' = d($SCS_ATIME) 361 tid' = d($SCS_TID) 362 iv' = d($SCS_IV) 363 tag' = d($SCS_AUTHTAG) 364 3. tag = HMAC(||||||) 365 4. If (tag == tag' && NOW - atime' <= session_max_age) 366 5. state = Uncomp(Dec(data')) 367 6. Else discard PDU 368 7. Else discard PDU 370 Figure 2 372 If the cryptographic credentials (encryption and authentication 373 algorithms and keys identified by SCS_TID) are unavailable (step 7.), 374 the inbound PDU cannot be interpreted correctly. 376 This may happen for several reasons: e.g., if a device without 377 storage has been reset and loses the credentials stored in RAM, if a 378 server pool node desynchronizes, or in case of a key compromise that 379 forces the invalidation of all available TIDs, etc. 381 Note that step 4. allows any altered packets or expired sessions to 382 be discarded, hence avoiding unnecessary state decryption and 383 decompression. 385 3.3. PDU Exchange 387 SCS can be modeled in the same manner as a typical store-and-forward 388 protocol, in which the endpoints are S, consisting of one or more 389 HTTP servers, and the client C, an intermediate node used to 390 "temporarily" store the data to be successively forwarded to S. 392 In brief, S and C exchange an immutable cookie data block 393 (Section 3.1): the state is stored on the client at the first hop and 394 then restored on the server at the second, as in Figure 3. 396 1. dump-state: 397 Set-Cookie: SCS_DATA=...; 398 Expires=...; Path=...; 399 Domain=...; 400 S --> --> C 401 Set-Cookie: SCS_TID=...; 402 Expires=...; Path=...; 403 Domain=...; 404 ... 406 2. restore-state: 407 Cookie: SCS_DATA=...; 408 C --> Cookie: SCS_TID=...; --> S 409 ... 411 Figure 3 413 Note that although SCS cookies always have the same naming, there can 414 be multiple active SCS sessions in use at a given user-agent as long 415 as the tuple is different. 417 SCS cookies MUST NOT be folded into a single HTTP header field, see 418 Section 3 of [I-D.ietf-httpstate-cookie]. 420 3.3.1. Cookie Attributes 422 All SCS cookies belonging to the same PDU MUST carry the same 423 attributes' set. This is not elegant nor bandwidth-friendly 424 solution, but it is necessary in order to guarantee PDU coherence. 426 In the following sub paragraphs a series of recommendations is 427 provided in order to maximize SCS PDU fitness in the generic cookie 428 ecosystem. 430 3.3.1.1. Expires 432 SCS cookies MUST include an Expires attribute which shall be set to a 433 value consistent with session_max_age. 435 For maximum compatibility with existing user agents the timestamp 436 value MUST be encoded in rfc1123-date format which requires a 4-digit 437 year. 439 3.3.1.2. Max-Age 441 Since not all UAs support this attribute, it MUST NOT be present in 442 any SCS cookie. 444 3.3.1.3. Domain 446 SCS cookies MUST include a Domain attribute compatible with 447 application usage. 449 A trailing '.' MUST NOT be present in order to minimize the 450 possibility of a user-agent ignoring the attribute value. 452 3.3.1.4. Secure 454 This attribute MUST always be asserted when SCS sessions are carried 455 over a TLS channel. 457 4. Key Management and Session State 459 This specification provides some common recommendations and praxis 460 relevant to cryptographic key management. 462 In the following, the term 'key' references both encryption and HMAC 463 keys. 465 o The key SHOULD be generated securely following the randomness 466 recommendations in [RFC4086]; 468 o the key length SHOULD be at least 128 bits; 470 o the key SHOULD only be used to generate and verify SCS PDUs; 472 o the key SHOULD be replaced regularly as well as any time the 473 format of SCS PDUs or cryptographic algorithms changes. 475 Furthermore, to preserve the validity of active HTTP sessions upon 476 renewal of cryptographic credentials (whenever the value of SCS_TID 477 changes), an SCS server MUST be capable of managing at least two 478 transforms contemporarily: the currently instantiated one, and its 479 predecessor. 481 Each transform set SHOULD be associated with an attribute pair: 482 "refresh" and "expiry", which is used to identify the exposure limits 483 (in terms of time or quantity of encrypted and/or authenticated 484 bytes, etc) of related cryptographic material. 486 In particular, the "refresh" attribute specifies the time limit for 487 substitution of transform set T with new material T'. From that 488 moment onwards, and for an amount of time determined by "expiry", all 489 new sessions will be created using T', while the active T-protected 490 ones go through a translation phase in which: 492 o the inbound transformation authenticates and decrypts/decompresses 493 using T (identified by SCS_TID); 495 o the outbound transformation encrypts/compresses and authenticates 496 using T'. 498 T' {not valid yet} |---------------------|---------------- 499 | translation stage | 500 T ----------------|---------------------| {no longer valid} 501 refresh refresh + expiry 503 Figure 4 505 As shown in Figure 4, the duration of the HTTP session MUST fit 506 within the lifetime of a given transform set (i.e. from creation time 507 until "refresh" + "expiry"). 509 In practice, this should not be an obstacle because the longevity of 510 the two entities (HTTP session and SCS transform set) should differ 511 by one or two orders of magnitude. 513 An SCS server may take this into account by determining the duration 514 of a session adaptively according to the expected deletion time of 515 the active T, or by setting the "expiry" value to at least the 516 maximum lifetime allowed by an HTTP session. 518 Since there is only one refresh attribute also in situations with 519 more than one key (e.g. one for encryption and one for 520 authentication) within the same T, the smallest value is chosen. 522 5. Acknowledgements 524 We would like to thank David Wagner and Lorenzo Cavallaro for their 525 valuable feedback on this document. 527 6. IANA Considerations 529 This memo includes no request to IANA. 531 7. Security Considerations 533 7.1. Security of the Cryptographic Protocol 535 From a cryptographic architecture perspective, the described 536 mechanism can be easily traced to an Encode-then-EtM scheme described 537 in [Kohno]. 539 Given a "provably-secure" encryption scheme and MAC (as for the 540 algorithms mandated in Section 3.2.1), Kohno et al. [Kohno] 541 demonstrate that their composition results in a secure authenticated 542 encryption scheme. 544 7.2. Impact of the SCS Cookie Model 546 The fact that the server does not own the cookie it produces, gives 547 rise to a series of consequences that must be clearly understood when 548 one envisages the use of SCS as a cookie provider and validator for 549 his/her application. 551 In the following paragraphs, a set of different attack scenarios 552 (together with corresponding countermeasures where applicable) are 553 identified and analyzed. 555 7.2.1. Old cookie replay 557 SCS doesn't address replay of old cookie values. 559 In fact, there is nothing that guarantees an SCS application about 560 the client having returned the most recent version of the cookie. 562 As with "server-side" sessions, if an attacker gains possession of a 563 given user's cookies - via simple passive interception or another 564 technique - he/she will always be able to restore the state of an 565 intercepted session by representing the captured data to the server. 567 The SCS_ATIME value along with the session_max_age configuration 568 parameter allow SCS to mitigate the chances of an attack (by forcing 569 a time window outside of which a given cookie is no longer valid), 570 but cannot exclude it completely. 572 A countermeasure against the "passive interception and replay" 573 scenario can be applied at transport/network level using the anti- 574 replay services provided by e.g., SSL/TLS [RFC5246] or IPsec 575 [RFC4301]. 577 Anyway, a generic solution is still out of scope: an SCS application 578 wishing to be replay-resistant must put in place some ad hoc 579 mechanism to prevent clients (both rogue and legitimate) from (a) 580 being able to replay old cookies as valid credentials and/or (b) 581 getting any advantage by replaying them. 583 In the following, some typical use cases are illustrated: 585 o Session inactivity timeout scenario (implicit invalidation): use 586 the session_max_age parameter if a global setting is viable, else 587 place an explicit TTL in the cookie (e.g. 588 validity_period="start_time, duration") that can be verified by 589 the application each time the Client presents the SCS cookie. 591 o Session voidance scenario (explicit invalidation): put a randomly 592 chosen string into each SCS cookie (cid="$(random())") and keep a 593 list of valid session cid's against which the SCS cookie presented 594 by the client can be checked. When a cookie needs to be 595 invalidated, delete the corresponding cid from the list. The 596 described method has the drawback that, in case a non-permanent 597 storage is used to archive valid cid's, a reboot/restart would 598 invalidate all sessions (It can't be used when |S| > 1). 600 o One-shot transaction scenario (ephemeral): this is a variation on 601 the previous theme when sessions are consumed within a single 602 request/response. Put a nonce="$(random())" within the state 603 information and keep a list of not-yet-consumed nonces in RAM. 604 Once the client presents its cookie credential, the embodied nonce 605 is deleted from the list and will be therefore discarded whenever 606 replayed. 608 It may be noteworthy that despite the chances of preventing replay in 609 some well established circumstances by using aforementioned 610 mechanisms, if the attacker is able to use the cookie before the 611 legitimate client gets a chance to, then the impersonation attack 612 will always succeed. 614 7.2.2. Cookie Deletion 616 A direct, and important, consequence of the missing owner role in SCS 617 is that a client could intentionally delete its cookie and return 618 nothing. 620 The application protocol has to be designed so there is no incentive 621 to do so, for instance: 623 o it is safe for the cookie to represent some kind of positive 624 capability - the possession of which increases the client's 625 powers; 627 o It is not safe to use the cookie to represent negative 628 capabilities - where possession reduces the client's powers-, or 629 for revocation. 631 Note that this behavior is not equivalent to cookie removal in the 632 "server-side" cookie model, because in case of missing cookie backup 633 by other parties (e.g. the application using SCS), the Client could 634 simply make it disappear once and for all. 636 7.2.3. Cookie Sharing or Theft 638 SCS doesn't prevent sharing (both voluntary and illegitimate) of 639 cookies between multiple clients. 641 In the context of voluntary cookie sharing, using HTTPS is useless: 642 Client certificates are just as shareable as cookies, hence 643 equivalently to the "server-side" cookie model, there seems to be no 644 way to prevent this threat. 646 The theft could be mitigated by securing the wire (e.g. via HTTPS, 647 IPsec, VPN, ...), thus reducing the opportunity of cookie stealing to 648 a successful attack on the protocol endpoints. 650 7.3. Advantages of SCS over Server-side Sessions 652 Note that all the abovementioned vulnerabilities also apply to 653 typical server-side sessions, making SCS at least as secure (based on 654 the current analysis), but there are a few good reasons to consider 655 its security level enhanced. 657 First of all, the confidentiality feature provided by SCS protects 658 cookie state information which is normally plain-text. 660 Furthermore, none of the common vulnerabilities of server-side 661 sessions (SID prediction, SID brute forcing, session fixation 663 [Kolsec]) can be exploited when using SCS, unless the attacker 664 possesses encryption and HMAC keys (both current ones and those 665 relating to the previous set of credentials). 667 More generally no slicing nor altering operations can be done over an 668 SCS PDU without controlling the cryptographic keyset and cipherset. 670 8. References 672 8.1. Normative References 674 [I-D.ietf-httpstate-cookie] 675 Barth, A., "HTTP State Management Mechanism", 676 draft-ietf-httpstate-cookie-22 (work in progress), 677 February 2011. 679 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 680 version 1.3", RFC 1951, May 1996. 682 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 683 Hashing for Message Authentication", RFC 2104, 684 February 1997. 686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 687 Requirement Levels", BCP 14, RFC 2119, March 1997. 689 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 690 Requirements for Security", BCP 106, RFC 4086, June 2005. 692 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 693 Encodings", RFC 4648, October 2006. 695 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 696 RFC 5652, September 2009. 698 8.2. Informative References 700 [Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security 701 Without Collision-Resistance", 2006. 703 [Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure 704 Cryptographic Transforms, or How to Encrypt and MAC", 705 2003. 707 [Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based 708 Applications", 2002. 710 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 711 Architecture", RFC 3740, March 2004. 713 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 714 Internet Protocol", RFC 4301, December 2005. 716 [RFC4418] Krovetz, T., "UMAC: Message Authentication Code using 717 Universal Hashing", RFC 4418, March 2006. 719 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 720 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 722 Appendix A. Reference Implementation 724 A reference implementation (at present in very early stage) of the 725 SCS protocol can be found at . 727 Authors' Addresses 729 Stefano Barbato 730 KoanLogic 731 Via Marmolada, 4 732 Vitorchiano (VT), 01030 733 Italy 735 Email: tat@koanlogic.com 737 Steven Dorigotti 738 KoanLogic 739 Via Maso della Pieve 25/C 740 Bolzano, 39100 741 Italy 743 Email: stewy@koanlogic.com 745 Thomas Fossati (editor) 746 KoanLogic 747 Via di Sabbiuno 11/5 748 Bologna, 40139 749 Italy 751 Phone: +39 051 644 82 68 752 Email: tho@koanlogic.com