RFC 6896

SCS: KoanLogic's Secure Cookie Sessions for HTTP

📅 published March 2013, from ietf

RFC 6896: SCS: KoanLogic's Secure Cookie Sessions for HTTP 🎀

Okay bestie, first the vibe check on the title block 💅 This is an Independent Submission by S. Barbato, S. Dorigotti, and T. Fossati (Ed.) from KoanLogic. It's Category: Informational, so it is not a Standards Track thing. The ISSN is 2070-1721 and it's dated March 2013. The title block doesn't list anything it obsoletes or updates, so no drama there 🌸

Abstract ✨

So this memo defines a generic URI and HTTP-header-friendly envelope for carrying tokens that are symmetrically encrypted, authenticated, and origin-timestamped 🔐 It also shows one possible way to use those tokens through a simple protocol built on HTTP cookies 🍪

Secure Cookie Session (SCS) use cases are literally all over the place 🦋 You could use them to distribute authorized content over HTTP (for example, with out-of-band signed URIs). You could also secure browser sessions on diskless embedded devices like Small Office, Home Office (SOHO) routers. And web servers with high availability or load-balancing needs might want to hand the application state off to clients instead of using shared storage or forced peering 🧚

Status of This Memo 🌈

This document is not an Internet Standards Track specification. It's published for informational purposes only 🫶

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the receipts 📜

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6896.

Copyright Notice ⭐

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 💜

Table of Contents 📚

1. Introduction ....................................................4
2. Requirements Language ...........................................4
3. SCS Protocol ....................................................5
   3.1. SCS Cookie Description .....................................5
        3.1.1. ATIME ...............................................6
        3.1.2. DATA ................................................6
        3.1.3. TID .................................................7
        3.1.4. IV ..................................................7
        3.1.5. AUTHTAG .............................................7
   3.2. Crypto Transform ...........................................8
        3.2.1. Choice and Role of the Framing Symbol ...............8
        3.2.2. Cipher Set ..........................................9
        3.2.3. Compression .........................................9
        3.2.4. Cookie Encoding .....................................9
        3.2.5. Outbound Transform ..................................9
        3.2.6. Inbound Transform ..................................10
   3.3. PDU Exchange ..............................................12
        3.3.1. Cookie Attributes ..................................12
               3.3.1.1. Expires ...................................12
               3.3.1.2. Max-Age ...................................12
               3.3.1.3. Domain ....................................13
               3.3.1.4. Secure ....................................13
               3.3.1.5. HttpOnly ..................................13
4. Key Management and Session State ...............................13
5. Cookie Size Considerations .....................................15
6. Acknowledgements ...............................................15
7. Security Considerations ........................................15
   7.1. Security of the Cryptographic Protocol ....................15
   7.2. Impact of the SCS Cookie Model ............................16
        7.2.1. Old Cookie Replay ..................................16
        7.2.2. Cookie Deletion ....................................17
        7.2.3. Cookie Sharing or Theft ............................18
        7.2.4. Session Fixation ...................................18
   7.3. Advantages of SCS over Server-Side Sessions ...............19
8. References .....................................................20
   8.1. Normative References ......................................20
   8.2. Informative References ....................................20
Appendix A. Examples ..............................................22
   A.1. No Compression ............................................22
   A.2. Use Compression ...........................................22

1. Introduction ✨

So this memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens 💖

It's generic, which means it doesn't force any specific format onto the authenticated information. That makes SCS tokens flexible, easy, and secure to use in lots of different scenarios 🦋

It's also URI and HTTP header friendly, because it was explicitly designed to be compatible with both the ABNF "token" syntax [RFC2616] (the one used for, e.g., Set-Cookie and Cookie headers) and the path or query syntax of HTTP URIs 🎀

This memo also describes one possible usage of such tokens through a simple protocol based on HTTP cookies that allows the establishment of "client mode" sessions. That is not their only possible use 🌸 No other operational patterns are outlined here, but SCS tokens are expected to be easily employed as a building block for other types of HTTP-based applications that need to carry in-band secured information 🧚

When SCS tokens are used to implement client-mode cookie sessions, the SCS implementer must fully understand the security implications of delegating the whole application state to the client (browser). 😭 Some hopefully useful security considerations are collected in Section 7.2. However, please note that they may not cover all possible scenarios. Therefore, they must be weighed carefully against the specific application threat model 🙈

An SCS server can be implemented within a web application by means of a user library that exposes the core SCS functionality and leaves explicit control over SCS tokens to the programmer. Or it can work transparently by hiding a "diskless session" facility behind a generic session API abstraction, for example. SCS implementers are free to choose whichever model best suits their needs 👑

2. Requirements Language 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅

3. SCS Protocol 🦋

The SCS protocol defines:

the SCS cookie structure and encoding (Section 3.1);
the cryptographic transformations involved in SCS cookie creation and verification (Section 3.2);
the HTTP-based PDU exchange that uses the Set-Cookie and Cookie HTTP headers (Section 3.3);
the underlying key management model (Section 4).

Note that the PDU is sent to the client as an opaque data block, so no interpretation nor validation is necessary. The single requirement for client-side support of SCS is cookie activation on the user agent. The origin server is the sole actor involved in PDU manipulation, which greatly simplifies the crypto operations. Key management especially benefits, since it's usually a pesky task 😩✨

In the following sections, we assume S to be one or more interchangeable HTTP server entities (e.g., a server pool in a load-balanced or high-availability environment). We also assume C to be the client, meaning a cookie-enabled browser or any user agent with equivalent capabilities 🌈

S and C exchange a cookie (Section 3.3) whose cookie value is a sequence of adjacent non-empty values. Each of those values is the 'URL and Filename safe' Base64 encoding [RFC4648] of a specific SCS field 🧁

Here's how to tell the encoded and raw versions of each SCS field apart: it's all about the e prefix in the name. For example, eATIME is the encoded one and ATIME is the raw one 💜

Each SCS field is separated from its left and/or right sibling by the %x7c ASCII character (i.e., '|'), like so:

scs-cookie        = scs-cookie-name "=" scs-cookie-value
scs-cookie-name   = token
scs-cookie-value  = eDATA "|" eATIME "|" eTID "|" eIV "|" eAUTHTAG
eDATA             = 1*base64url-character
eATIME            = 1*base64url-character
eTID              = 1*base64url-character
eIV               = 1*base64url-character
eAUTHTAG          = 1*base64url-character

Figure 1

Confidentiality is limited to the application-state information (i.e., the DATA field), while integrity and authentication apply to the entire cookie value. 🔐

The following subsections describe the syntax and semantics of each SCS cookie field 🎀

3.1.1. ATIME ⏰

ATIME is an absolute timestamp for the last read or write operation performed on session DATA. It's encoded as a HEX string holding the number of seconds since the UNIX epoch (i.e., since 00:00:00, Jan 1 1970) 🕰️

This value gets updated with each client contact, and it's what identifies expired sessions. If the delta between the received ATIME value and the current time on S is larger than a predefined session_max_age (which S chooses as an application-level parameter), the session is considered no longer valid and gets rejected 🚫

That expiration error can be used to force a user logout from an SCS-cookie-based session. It can also be hooked into the web application logic to display an HTML form that requires the user to revalidate their credentials 🙈

3.1.2. DATA 🌸

DATA is a block of encrypted and optionally compressed data, possibly containing the current session state. No restriction is imposed on the cleartext structure, because the protocol is completely agnostic about the inner data layout 🧚

Generally speaking, the plaintext is the "normal" cookie that would have been exchanged by S and C if SCS had not been used. ✨

3.1.3. TID 🔑

Okay so TID is basically the Security Parameter Index (SPI) of a Data Security SA [RFC3740]) 💅 It's an ASCII string that uniquely identifies the transform set (the keys and algorithms) used to make this SCS cookie. Main character energy, fr fr ✨

SCS assumes there's a key-agreement or key-distribution mechanism for setups where S is made up of multiple servers. That mechanism has to give each transform set a unique external identifier that every pool member shares 🫶

If there's only one server in the pool and the key gets generated right there (meaning no external source is involved), the mechanism is allowed to downgrade to a periodic key refresh. Simple and iconic 🌸

But when a bunch of servers are acting on the same pool at once, you need something more sophisticated. That protocol is out of scope for this document, so someone else has to figure it out. Ideally it handles key agreement for dynamic peer groups in a secure and efficient way, like [CLIQUES] or [Steiner] 🧚

3.1.4. IV 🎀

IV is the Initialization Vector used by the encryption algorithm (see Section 3.2). Lowkey the most important part of keeping things random 🦋

To stop an attacker from getting correlation info while they're looking at a bunch of SCS cookies made with the same TID, the IV MUST be created randomly for each SCS cookie. No shortcuts, periodt 💅

3.1.5. AUTHTAG 🔐

AUTHTAG is the authentication tag. It's built from a plain string concatenation of the base64url-encoded DATA, ATIME, TID, and IV fields, and each one gets framed by the "|" separator (see also the Box() function in Section 3.2):

AUTHTAG = HMAC(base64url(DATA)  "|"
               base64url(ATIME) "|"
               base64url(TID)   "|"
               base64url(IV))

Here's the cute bit 🙈 From a cryptographic point of view, the "|" character explicitly authenticates the length of each field, which is a robust countermeasure against splicing attacks. Iconic engineering, no cap 👑

3.2. Crypto Transform 💜

SCS could technically use any combo of primitives that can do authenticated encryption. In practice, they went with an encrypt-then-MAC approach [Kohno], using Cipher Block Chaining (CBC) mode for encryption and Hashed Message Authentication Code (HMAC) [RFC2104] for authentication. Chef's kiss 🍓

The two algorithms MUST be associated with two independent keys. Two separate keys, no sharing allowed 🔑✨

Here's the cheat sheet for the algorithm descriptions in Sections 3.2.5 and 3.2.6:

Enc/Dec(): block encryption/decryption functions (Section 3.2.2);
HMAC(): authentication function (Section 3.2.2);
Comp/Uncomp(): compression/decompression functions (Section 3.2.3);
e/d(): cookie-value encoding/decoding functions (Section 3.2.4);
RAND(): random number generator [RFC4086];
Box(): string boxing function. It takes an arbitrary number of base64url-encoded strings and returns the string you get by concatenating each input in the exact order they're listed, separated by the "|" char. For example:

Box("akxI", "MTM", "Hadvo") = "akxI|MTM|Hadvo".

3.2.1. Choice and Role of the Framing Symbol 🌈

Using "|" as the framing symbol in Box() is arbitrary. Any char allowed by the cookie-value ABNF in [RFC6265] is safe to use, as long as it has an empty intersection with the base64url alphabet 🦋

The framing symbol is also key to the accuracy and security of SCS. It acts as an implicit length indicator for each atom, which is a big deal ✨

This matters a lot when the authentication tag is computed (see Section 3.1.5). Including the framing symbol right in the HMAC input seals the integrity of the whole blob, along with each atom in its exact position. Lowkey genius 🧠

That makes the protocol robust against attacks that try to mess with SCS PDUs by sliding the boundaries between adjacent atoms around 🙅‍♀️

3.2.2. Cipher Set 💅

Implementers MUST support at least the following algorithms:

AES-CBC-128 for encryption [NIST-AES];
HMAC-SHA1 with a 128-bit key for authenticity and integrity,

These seem sufficiently secure across a broad range of use cases ([Bellare] [RFC6194]). They're widely available and can be implemented in a few kilobytes of memory, which is an extremely valuable feature for constrained devices 🌸

You should consider larger cryptographic key lengths (192- or 256-bit) depending on your actual security and overall system performance requirements. (The original says "One should", but lowercase, so it's just a nudge, not a rule 💖)

3.2.3. Compression 📦

Compression can be super useful or even necessary when you're handling big piles of data, but it isn't compulsory. If you skip it, Comp/Uncomp just gets replaced by an identity matrix. If it's enabled, the DEFLATE [RFC1951] format MUST be supported 🎀

Some advice for SCS users: don't enable compression when you're dealing with relatively short and entropic state, like pseudorandom session identifiers. Big, quite regular state blobs are the ones that get a major glow-up from compression 💅✨

SCS cookie values MUST be encoded using the URL and filename safe alphabet (that's base64url) defined in Section 5 of Base64 [RFC4648]. It's super widespread, fits smoothly into the encoding rules in Section 4.1.1 of [RFC6265], and it's safe to use SCS-based authorization tokens inside a URI, like in a query string or straight into a path segment 🦋

3.2.5. Outbound Transform 📤

The output transformation, as seen by the server (the only actor that explicitly manipulates SCS cookies), is shown in the pseudocode in Figure 2:

      1.  IV := RAND()
      2.  ATIME := NOW
      3.  DATA := Enc(Comp(plain-text-cookie-value), IV)
      4.  AUTHTAG := HMAC(Box(e(DATA), e(ATIME), e(TID), e(IV)))

                              Figure 2

Step 1 picks a brand-new Initialization Vector at random. Like we said in Section 3.1.4, this step is necessary so the attacker can't get correlation info 🙈

Step 2 sets a new ATIME value to the current timestamp according to the server clock 🕰️

ATIME only gets used by the server, so it doesn't have to be synced with the client. It does need a fairly stable clock, though. If multiple servers are active in a load-balancing setup, clocks SHOULD be synchronized to avoid errors when calculating session expiry. Should, not must, but still very much recommended 💜

Step 3: the plaintext cookie value gets compressed (if needed) and then encrypted with the key-set identified by TID 🔐

If the length of the (compressed) state isn't a multiple of the block size, it MUST be filled with as many padding bytes of equal value as the pad length, using the scheme in Section 6.3 of [RFC5652]. Padding, but make it precise 🧁

Step 4: the authentication tag, which covers each SCS field (along with lengths and relative positions), gets computed by HMAC'ing the "|"-separated concatenation of their base64url representations, using the key-set identified by TID 💖

Finally, the SCS-cookie-value comes together like this:

   scs-cookie-value = Box(e(DATA), e(ATIME), e(TID), e(IV),
                          e(AUTHTAG))

3.2.6. Inbound Transform 📥

Here's the inbound transformation, shown in Figure 3. Every 'e'-prefixed name in it has to be read as the base64url-encoded value of the matching SCS field 🫶

        0.  If (split_fields(scs-cookie-value) == ok)
        1.      tid' := d(eTID)
        2.      If (tid' is available)
        3.          tag' := d(eAUTHTAG)
        4.          tag := HMAC(Box(eDATA, eATIME, eTID, eIV))
        5.          If (tag = tag')
        6.              atime' := d(eATIME)
        7.              If (NOW - atime' <= session_max_age)
        8.                  iv' := d(eIV)
                            data' := d(eDATA)
        9.                  state := Uncomp(Dec(data', iv'))
        10.             Else discard PDU
        11.         Else discard PDU
        12.     Else discard PDU
        13. Else discard PDU

                              Figure 3

Step 0 is the first check. The inbound scs-cookie-value gets split into its component fields, which MUST be exactly 5, and each one has to be at least the minimum length given in Figure 3. If any of these preliminary checks fail, the PDU gets discarded (step 13). If they pass, TID gets decoded so we can look up the key-set (step 1) 🔍

If the cryptographic credentials (the encryption and authentication algorithms and keys identified by TID) are unavailable (step 12), the inbound SCS cookie is discarded, because its value has no chance of being interpreted correctly. This can happen for a bunch of reasons, like a device without storage getting reset and losing the credentials stored in RAM, a server pool node desynchronizing, or a key compromise that forces every current TID to be invalidated. Chaos, but make it cryptographic 💀

When a valid key-set is found (step 2), the AUTHTAG field gets decoded (step 3). Then the (still encoded) DATA, ATIME, TID, and IV fields get fed to the primitive that computes the authentication tag (step 4) 🧮

If the tag computed with the local key-set matches the one on the SCS cookie, we can be confident the cookie carries authentic material. If not, the SCS cookie is discarded (step 11). No match, no entry 🚫

Next up is the age check. The age of the SCS cookie gets deduced from the ATIME value and the current time from the server clock, then it's compared to the maximum time-to-live (TTL) set by the session_max_age parameter ⏳

If the age check passes, the DATA and IV fields get decoded (step 8), so the original plaintext can be pulled out of the encrypted, and optionally compressed, blob (step 9) 🎁

Note that steps 5 and 7 let altered packets or expired sessions get tossed out early, which means we skip unnecessary state decryption and decompression. Efficient and slay 💅

3.3. PDU Exchange 🔄

SCS can be modeled like a typical store-and-forward protocol. The endpoints are S, which is one or more HTTP servers, and the client C, an intermediate node that "temporarily" stores the data to be forwarded on to S 📬

Basically, S and C swap an immutable cookie data block (Section 3.1). The state gets stored on the client at the first hop, then restored on the server at the second hop, like in Figure 4:

  1.  dump-state:
      S --> C
          Set-Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0...
             Expires=...; Path=...; Domain=...;

  2.  restore-state:
      C --> S
          Cookie: ANY_COOKIE_NAME=KrdPagFes_5ma-ZUluMsww|MTM0...

                              Figure 4

The next subsections give a series of recommendations to maximize SCS PDU fitness in the generic cookie ecosystem 💖

3.3.1.1. Expires ⏰

If an SCS cookie includes an Expires attribute, that attribute MUST be set to a value consistent with session_max_age.

For maximum compatibility with existing user agents, the timestamp value MUST be encoded in rfc1123-date format, which requires a 4-digit year. Four digits, bestie 📅

3.3.1.2. Max-Age 🚫

Not all User Agents (UAs) support this attribute, so Max-Age MUST NOT be present in any SCS cookie. Left on read 🙅‍♀️

3.3.1.3. Domain 🌐

SCS cookies MUST include a Domain attribute that's compatible with application usage.

A trailing '.' MUST NOT be present. That keeps the odds down of a user agent ignoring the attribute value 🥹

3.3.1.4. Secure 🔒

This attribute MUST always be asserted when SCS sessions are carried over a Transport Layer Security (TLS) channel. Bestie, this one is non-negotiable 💅 if you're running SCS over TLS, the Secure flag MUST always be set, no exceptions 🫶

3.3.1.5. HttpOnly 🙈

This attribute SHOULD always be asserted. 🌸

4. Key Management and Session State 🔑

This specification provides some common recommendations and practices relevant to cryptographic key management. Okay, so this is the part where we talk keys like responsible adults 💖

In the following, the term 'key' references both encryption and HMAC keys. So when I say "key," I mean both kinds 🗝️

The key SHOULD be generated securely following the randomness recommendations in [RFC4086];
the key SHOULD only be used to generate and verify SCS PDUs;
the key SHOULD be replaced regularly as well as any time the format of SCS PDUs or cryptographic algorithms changes.

Furthermore, to preserve the validity of active HTTP sessions upon renewal of cryptographic credentials (whenever the value of TID changes), an SCS server MUST be capable of managing at least two transforms contemporarily: the currently instantiated one and its predecessor. Two transforms at once, bestie, the old one and the new one, so nobody's session gets yeeted mid-scroll ✨

Each transform set SHOULD be associated with an attribute pair, refresh and expiry, which is used to identify the exposure limits (in terms of time or quantity of encrypted and/or authenticated bytes, etc.) of related cryptographic material. So basically each transform set gets its own little pair of timers 🦋

In particular, the refresh attribute specifies the time limit for substitution of transform set T with new material T'. From that moment onwards, and for an amount of time determined by expiry, all new sessions will be created using T', while the active T-protected ones go through a translation phase in which:

the inbound transformation authenticates and decrypts/decompresses using T (identified by TID);
the outbound transformation encrypts/compresses and authenticates using T'.

  T' {not valid yet} |---------------------|----------------
                     |  translation stage  |
  T  ----------------|---------------------| {no longer valid}
                   refresh         refresh + expiry

                           Figure 5

As shown in Figure 5, the duration of the HTTP session MUST fit within the lifetime of a given transform set (i.e., from creation time until refresh + expiry). The session has to fit inside the transform's lifetime, so no overstaying 💀

In practice, this should not be an obstacle because the longevity of the two entities (HTTP session and SCS transform set) should differ by one or two orders of magnitude. Lowkey not a problem at all, since the transform set lives way longer than any one session 🌈

An SCS server may take this into account by determining the duration of a session adaptively according to the expected deletion time of the active T, or by setting the expiry value to at least the maximum lifetime allowed by an HTTP session. Two ways to handle it, both are valid vibes ✨

Since there is also only one refresh attribute in situations with more than one key (e.g., one for encryption and one for authentication) within the same T, the smallest value is chosen. So when there are multiple keys, the smallest refresh value wins 👑

It is critical for the correctness of the protocol that in case multiple equivalent SCS servers are used in a pool, all of them share the same view of time (see also Section 3.2.5) and keying material. Pool members have to agree on both the time and the keys, periodt 🕰️

As far as the latter is concerned, SCS does not mandate the use of any specific key-sharing mechanism, and will keep working correctly as long as the said mechanism is able to provide a single, coherent view of the keys shared by pool members -- while conforming to the recommendations given in this section. So SCS doesn't care which key-sharing method you pick, as long as it gives every server the same coherent keys 🧚

In general, SCS cookies are bigger than their plaintext counterparts. This is due to the following reasons:

inflation of the Base64 encoding of state data (approximately 1.4 times the original size, including the encryption padding);
the fixed size increment (approximately 80/90 bytes) caused by SCS fields and framing overhead.

While the former is a price the user must always pay proportionally to the original data size, the latter is a fixed quantum, which can be huge on small amounts of data but is quickly absorbed as soon as data becomes big enough. So the Base64 bloat is a proportional tax, and the fixed overhead hits hard on tiny cookies but fades once the data gets chunky 🫠

The following table compares byte lengths of SCS cookies (with a four-byte TID) and corresponding plaintext cookies in a worst-case scenario, i.e., when no compression is in use (or applicable).

                           plain |  SCS
                           -------+-------
                             11  |  128
                            102  |  256
                            285  |  512
                            651  | 1024
                           1382  | 2048
                           2842  | 4096

The largest uncompressed cookie value that can be safely supplied to SCS is about 2.8 KB. So keep your uncompressed values under roughly 2.8 KB, bestie 📏

6. Acknowledgements 💜

We would like to thank Jim Schaad, David Wagner, Lorenzo Cavallaro, Willy Tarreau, Tobias Gondrom, John Michener, Sean Turner, Barry Leiba, Robert Sparks, Stephen Farrell, Stewart Bryant, and Nevil Brownlee for their valuable feedback on this document. Huge shoutout to all of them for the feedback 🙌

7. Security Considerations 🛡️

7.1. Security of the Cryptographic Protocol

From a cryptographic architecture perspective, the described mechanism can be easily traced to an "encode then encrypt-then-MAC" scheme (Encode-then-EtM) as described in [Kohno]. So the design is basically a well-known pattern, not something made up on the spot 🔐

Given a "provably-secure" encryption scheme and MAC (as for the algorithms mandated in Section 3.2.2), the authors of [Kohno] demonstrate that their composition results in a secure authenticated encryption scheme. The security argument leans on those provably-secure building blocks, so pick algorithms from Section 3.2.2 and the math checks out 🧠

The fact that the server does not own the cookie it produces, gives rise to a series of consequences that must be clearly understood when one envisages the use of SCS as a cookie provider and validator for his/her application. Ngl this is the scary part, so read carefully 😭

In the following subsections, a set of different attack scenarios (together with corresponding countermeasures where applicable) are identified and analyzed. Let's go through them one by one 🦋

SCS doesn't address replay of old cookie values. Replay is not handled by SCS itself 🙅‍♀️

In fact, there is nothing that assures an SCS application about the client having returned the most recent version of the cookie. The app has no way to know if the cookie it's looking at is the latest one.

As with "server-side" sessions, if an attacker gains possession of a given user's cookies -- via simple passive interception or another technique -- he/she will always be able to restore the state of an intercepted session by representing the captured data to the server. Same energy as server-side sessions, so a stolen cookie is a stolen session 💀

The ATIME value, along with the session_max_age configuration parameter, allows SCS to mitigate the chances of an attack (by forcing a time window outside of which a given cookie is no longer valid) but cannot exclude it completely. Helpful, but not a full fix 🫶

A countermeasure against the "passive interception and replay" scenario can be applied at transport/network level using the anti-replay services provided by e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or IPsec [RFC4301]. So you can lean on the transport layer for anti-replay 🔒

A native solution is not in scope with the security properties inherent to an SCS cookie. Hence, an application wishing to be replay-resistant must put in place some ad hoc mechanism to prevent clients (both rogue and legitimate) from (a) being able to replay old cookies as valid credentials and/or (b) getting any advantage by replaying them. SCS won't do this for you, so your app has to build its own anti-replay setup 🛠️

The following illustrate some typical use cases:

Session inactivity timeout scenario (implicit invalidation): use the session_max_age parameter if a global setting is viable, else place an explicit TTL in the cookie (e.g., validity_period="start_time, duration") that can be verified by the application each time the client presents the SCS cookie.
Session voidance scenario (explicit invalidation): put a randomly chosen string into each SCS cookie (cid="$(random())") and keep a list of valid session cids against which the SCS cookie presented by the client can be checked. When a cookie needs to be invalidated, delete the corresponding cid from the list. The described method has the drawback that, in case a non-permanent storage is used to archive valid cids, a reboot/restart would invalidate all sessions (it can't be used when |S| > 1).
One-shot transaction scenario (ephemeral): this is a variation on the previous theme when sessions are consumed within a single request/response. Put a nonce="$(random())" within the state information and keep a list of not-yet-consumed nonces in RAM. Once the client presents its cookie credential, the embodied nonce is deleted from the list and will be therefore discarded whenever replayed. One use, then it's gone ✨
TLS binding scenario: the server application must run on TLS, be able to extract information related to the current TLS session, and store it in the DATA field of the SCS cookie itself [RFC5056]. The establishment of this secure channel binding prevents any third party from reusing the SCS cookie, and drops its value altogether after the TLS session is terminated -- regardless of the lifetime of the cookie. This approach suffers a scalability problem in that it requires each SCS session to be handled by the same client-server pair. However, it provides a robust model and an affordable compromise when security of the session is exceptionally valuable (e.g., a user interacting with his/her online banking site). Iykyk, this one is the banking-grade option 🏦

It is worth noting that in all but the latter scenario, if an attacker is able to use the cookie before the legitimate client gets a chance to, then the impersonation attack will always succeed. Basically, if the attacker gets there first, they win, unless you're using the TLS binding 😱

A direct and important consequence of the missing owner role in SCS is that a client could intentionally delete its cookie and return nothing. Since nobody "owns" the cookie, the client can just ghost it 👻

The application protocol has to be designed so there is no incentive to do so, for instance:

it is safe for the cookie to represent some kind of positive capability -- the possession of which increases the client's powers;
it is not safe to use the cookie to represent negative capabilities -- where possession reduces the client's powers -- or for revocation.

Note that this behavior is not equivalent to cookie removal in the "server-side" cookie model, because in case of missing cookie backup by other parties (e.g., the application using SCS), the client could simply make it disappear once and for all. So the deletion is permanent unless someone else has a backup, no cap 💅

Just like with plain cookies, SCS doesn't prevent sharing (both voluntary and illegitimate) of cookies between multiple clients. Sharing happens with plain cookies too, so SCS isn't any worse here 🫤

In the context of voluntary cookie sharing, using HTTPS only as a separate secure transport provider is useless: in fact, client certificates are just as shareable as cookies. Instead, using some form of secure channel binding (as illustrated in Section 7.2.1) may cancel this risk. HTTPS alone won't stop sharing, but channel binding from Section 7.2.1 might 🔗

The risk of theft could be mitigated by securing the wire (e.g., via HTTPS, IPsec, VPN, etc.), thus reducing the opportunity of cookie stealing to a successful attack on the protocol endpoints. So lock down the wire and theft gets a lot harder 🔐

In order to reduce the attack window on stolen cookies, an application may choose to generate cookies whose lifetime is upper bounded by the browsing session lifetime (i.e., by not attaching an Expires attribute to them.) Leaving off the Expires attribute keeps the cookie tied to the browsing session, which shrinks the window for stolen cookies 🌙

7.2.4. Session Fixation 🪤

okay so session fixation vulnerabilities [Kolsec] are NOT addressed by SCS 😭 it's giving "not my problem" and honestly that's kind of the vibe we have to be upfront about 💅

to actually fix it you'd need a much more sophisticated protocol where the UA is actively involved in the SCS cookie manipulation process. e.g., some form of challenge/response exchange that the server starts in the HTTP response, and then the UA replies to it in the next chained HTTP request. ✨ very main character energy, but it's a whole different level 🧚

the tea is that the present specification, which is based on [RFC6265], treats the UA as a completely passive actor. its only job is to blindly paste the cookie value the server set 🙈 no challenge, no reply, just vibes.

BUT (and this is the sparkly part 🌈) the SCS cookie wrapping mechanism might be used later as a building block for a more robust HTTP state management protocol. so SCS could be the foundation for the glow-up 🦋

7.3. Advantages of SCS over Server-Side Sessions 💜

ngl, all the vulnerabilities we just talked about also apply to plain cookies. so SCS is at least as secure as plain cookies, but there are a few good reasons to think its security level is enhanced ✨

first of all, the confidentiality and authentication features that SCS provides protect the cookie value. and that matters because a plain cookie value is normally plaintext and tamperable 😭 SCS wraps it up so nobody can just read or mess with it.

furthermore, neither of the common vulnerabilities of server-side sessions can be exploited when using SCS. those are session identifier (SID) prediction and SID brute-forcing 🙅‍♀️ the one catch is that the attacker has to possess the encryption and HMAC keys (both the current ones and the ones relating to the previous set of credentials). so no keys, no party 🔑

more in general, no slicing or altering operations can be done over an SCS PDU without controlling the cryptographic key-set. basically, if you don't hold the keys, you can't chop it up or edit it 💅

8. References 📚

8.1. Normative References 🍓

[NIST-AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

8.2. Informative References 🦋

[Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security Without Collision-Resistance", 2006.
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "Cliques: A New Approach to Group Key Agreement", 1996.
[Kohno] Kohno, T., Palacio, A., and J. Black, "Building Secure Cryptographic Transforms, or How to Encrypt and MAC", 2003.
[Kolsec] Kolsec, M., "Session Fixation Vulnerability in Web-based Applications", 2002.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[Steiner] Steiner, M., Tsudik, G., and M. Waidner, "Diffie-Hellman Key Distribution Extended to Group Communication", 1996.

Appendix A. Examples 🎀

the examples in this section were made with the 'scs' test tool bundled with LibSCS, a free and opensource reference implementation of the SCS protocol. you can find it at (http://github.com/koanlogic/libscs) 🌸

A.1. No Compression 🧊

the following parameters:

o  Plaintext cookie: "a state string"

o  AES-CBC-128 key: "123456789abcdef"

o  HMAC-SHA1 key: "12345678901234567890"

o  TID: "tid"

o  ATIME: 1347265955

o  IV:
   \xb4\xbd\xe5\x24\xf7\xf6\x9d\x44\x85\x30\xde\x9d\xb5\x55\xc9\x4f

produce the following tokens:

o  DATA: DqfW4SFqcjBXqSTvF2qnRA

o  ATIME: MTM0NzI2NTk1NQ

o  TID: OHU7M1cqdDQt

o  IV: tL3lJPf2nUSFMN6dtVXJTw

o  AUTHTAG: AznYHKga9mLL8ioi3If_1iy2KSA

A.2. Use Compression 🗜️

the same parameters as above, except ATIME and IV:

o  Plaintext cookie: "a state string"

o  AES-CBC-128 key: "123456789abcdef"

o  HMAC-SHA1 key: "12345678901234567890"

o  TID: "tid"
o  ATIME: 1347281709

o  IV:
   \x1d\xa7\x6f\xa0\xff\x11\xd7\x95\xe3\x4b\xfb\xa9\xff\x65\xf9\xc7