summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6896.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6896.txt')
-rw-r--r--doc/rfc/rfc6896.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6896.txt b/doc/rfc/rfc6896.txt
new file mode 100644
index 0000000..f80633c
--- /dev/null
+++ b/doc/rfc/rfc6896.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Independent Submission S. Barbato
+Request for Comments: 6896 S. Dorigotti
+Category: Informational T. Fossati, Ed.
+ISSN: 2070-1721 KoanLogic
+ March 2013
+
+
+ SCS: KoanLogic's Secure Cookie Sessions for HTTP
+
+Abstract
+
+ This memo defines a generic URI and HTTP-header-friendly envelope for
+ carrying symmetrically encrypted, authenticated, and origin-
+ timestamped tokens. It also describes one possible usage of such
+ tokens via a simple protocol based on HTTP cookies.
+
+ Secure Cookie Session (SCS) use cases cover a wide spectrum of
+ applications, ranging from distribution of authorized content via
+ HTTP (e.g., with out-of-band signed URIs) to securing browser
+ sessions with diskless embedded devices (e.g., Small Office, Home
+ Office (SOHO) routers) or web servers with high availability or load-
+ balancing requirements that may want to delegate the handling of the
+ application state to clients instead of using shared storage or
+ forced peering.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6896.
+
+
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 1]
+
+RFC 6896 SCS March 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 2]
+
+RFC 6896 SCS March 2013
+
+
+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
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 3]
+
+RFC 6896 SCS March 2013
+
+
+1. Introduction
+
+ This memo defines a generic URI and HTTP-header-friendly envelope for
+ carrying symmetrically encrypted, authenticated, and origin-
+ timestamped tokens.
+
+ It is generic in that it does not force any specific format upon the
+ authenticated information, which makes SCS tokens flexible, easy, and
+ secure to use in many different scenarios.
+
+ It is URI and HTTP header friendly, as it has been 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 via a
+ simple protocol based on HTTP cookies that allows the establishment
+ of "client mode" sessions. This is not their sole possible use.
+ While no other operational patterns are outlined here, it is expected
+ that SCS tokens may 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
+ entailed by the act of delegating the whole application state to the
+ client (browser). In this regard, some hopefully useful security
+ considerations have been 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 may 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 transparently,
+ by hiding a "diskless session" facility behind a generic session API
+ abstraction, for example. SCS implementers are free to choose the
+ model that 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].
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 4]
+
+RFC 6896 SCS March 2013
+
+
+3. SCS Protocol
+
+ The SCS protocol defines:
+
+ o the SCS cookie structure and encoding (Section 3.1);
+
+ o the cryptographic transformations involved in SCS cookie creation
+ and verification (Section 3.2);
+
+ o the HTTP-based PDU exchange that uses the Set-Cookie and Cookie
+ HTTP headers (Section 3.3);
+
+ o the underlying key management model (Section 4).
+
+ Note that the PDU is transmitted to the client as an opaque data
+ block; hence, 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 the PDU manipulation process, which greatly simplifies
+ the crypto operations -- especially key management, which is 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) and C to be the client
+ with a cookie-enabled browser or any user agent with equivalent
+ capabilities.
+
+3.1. SCS Cookie Description
+
+ S and C exchange a cookie (Section 3.3) whose cookie value consists
+ of a sequence of adjacent non-empty values, each of which is the 'URL
+ and Filename safe' Base64 encoding [RFC4648] of a specific SCS field.
+
+ (Hereafter, the encoded and raw versions of each SCS field are
+ distinguished based on the presence, or lack thereof, of the 'e'
+ prefix in their name, e.g., eATIME and ATIME.)
+
+ Each SCS field is separated by its left and/or right sibling by means
+ of the %x7c ASCII character (i.e., '|'), as follows:
+
+
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 5]
+
+RFC 6896 SCS March 2013
+
+
+ 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
+
+ Absolute timestamp relating to the last read or write operation
+ performed on session DATA, 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 is updated with each client contact and is used to
+ identify 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 is chosen by S as an application-level
+ parameter), a session is considered to be no longer valid, and is
+ therefore rejected.
+
+ Such an expiration error may be used to force user logout from an
+ SCS-cookie-based session, or hooked in the web application logic to
+ display an HTML form requiring revalidation of user credentials.
+
+3.1.2. DATA
+
+ Block of encrypted and optionally compressed data, possibly
+ containing the current session state. Note that no restriction is
+ imposed on the cleartext structure: the protocol is completely
+ agnostic as to 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.
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 6]
+
+RFC 6896 SCS March 2013
+
+
+3.1.3. TID
+
+ This identifier is equivalent to a Security Parameter Index (SPI) in
+ a Data Security SA [RFC3740]) and consists of an ASCII string that
+ uniquely identifies the transform set (keys and algorithms) used to
+ generate this SCS cookie.
+
+ SCS assumes that a key-agreement/distribution mechanism exists for
+ environments in which S consists of multiple servers that provide a
+ unique external identifier for each transform set shared amongst pool
+ members.
+
+ Such a mechanism may safely downgrade to a periodic key refresh, if
+ there is only one server in the pool and the key is generated in
+ place -- i.e., it is not handled by an external source.
+
+ However, when many servers act concurrently upon the same pool, a
+ more sophisticated protocol, whose specification is out of the scope
+ of the present document, must be devised (ideally, one that is able
+ to handle key agreement for dynamic peer groups in a secure and
+ efficient way, e.g., [CLIQUES] or [Steiner]).
+
+3.1.4. IV
+
+ Initialization Vector used for the encryption algorithm (see
+ Section 3.2).
+
+ In order to avoid providing correlation information to a possible
+ attacker with access to a sample of SCS cookies created using the
+ same TID, the IV MUST be created randomly for each SCS cookie.
+
+3.1.5. AUTHTAG
+
+ Authentication tag that is based on the plain string concatenation of
+ the base64url-encoded DATA, ATIME, TID, and IV fields and is framed
+ by the "|" separator (see also the definition of the Box() function
+ in Section 3.2):
+
+ AUTHTAG = HMAC(base64url(DATA) "|"
+ base64url(ATIME) "|"
+ base64url(TID) "|"
+ base64url(IV))
+
+ Note that, from a cryptographic point of view, the "|" character
+ provides explicit authentication of the length of each supplied
+ field, which results in a robust countermeasure against splicing
+ attacks.
+
+
+
+
+Barbato, et al. Informational [Page 7]
+
+RFC 6896 SCS March 2013
+
+
+3.2. Crypto Transform
+
+ SCS could potentially use any combination of primitives capable of
+ performing authenticated encryption. In practice, an
+ encrypt-then-MAC approach [Kohno] with encryption utilizing the
+ Cipher Block Chaining (CBC) mode and Hashed Message Authentication
+ Code (HMAC) [RFC2104] authentication was chosen.
+
+ The two algorithms MUST be associated with two independent keys.
+
+ The following conventions will be used in the algorithm description
+ (Sections 3.2.5 and 3.2.6):
+
+ o Enc/Dec(): block encryption/decryption functions (Section 3.2.2);
+
+ o HMAC(): authentication function (Section 3.2.2);
+
+ o Comp/Uncomp(): compression/decompression functions
+ (Section 3.2.3);
+
+ o e/d(): cookie-value encoding/decoding functions (Section 3.2.4);
+
+ o RAND(): random number generator [RFC4086];
+
+ o Box(): string boxing function. It takes an arbitrary number of
+ base64url-encoded strings and returns the string obtained by
+ concatenating each input in the exact order in which they are
+ listed, separated by the "|" char. For example:
+
+ Box("akxI", "MTM", "Hadvo") = "akxI|MTM|Hadvo".
+
+3.2.1. Choice and Role of the Framing Symbol
+
+ Note that the adoption of "|" as the framing symbol in the Box()
+ function is arbitrary: any char allowed by the cookie-value ABNF in
+ [RFC6265] is safe to be used as long it has empty intersection with
+ the base64url alphabet.
+
+ It is also worth noting that the role of the framing symbol, which
+ provides an implicit length indicator for each of the atoms, is key
+ to the accuracy and security of SCS.
+
+ This is especially relevant when the authentication tag is computed
+ (see Section 3.1.5). More specifically, the explicit inclusion of
+ the framing symbol within the HMAC input seals the integrity of the
+ blob as a whole together with each of its composing atoms in their
+ exact position.
+
+
+
+
+Barbato, et al. Informational [Page 8]
+
+RFC 6896 SCS March 2013
+
+
+ This feature makes the protocol robust against attacks aimed at
+ disrupting the security of SCS PDUs by freely moving boundaries
+ between adjacent atoms.
+
+3.2.2. Cipher Set
+
+ Implementers MUST support at least the following algorithms:
+
+ o AES-CBC-128 for encryption [NIST-AES];
+
+ o HMAC-SHA1 with a 128-bit key for authenticity and integrity,
+
+ which appear to be sufficiently secure in a broad range of use cases
+ ([Bellare] [RFC6194]), are widely available, and can be implemented
+ in a few kilobytes of memory, providing an extremely valuable feature
+ for constrained devices.
+
+ One should consider using larger cryptographic key lengths (192- or
+ 256-bit) according to the actual security and overall system
+ performance requirements.
+
+3.2.3. Compression
+
+ Compression, which may be useful or even necessary when handling
+ large quantities of data, is not compulsory (in such a case, Comp/
+ Uncomp is replaced by an identity matrix). If this function is
+ enabled, the DEFLATE [RFC1951] format MUST be supported.
+
+ Some advice to SCS users: compression should not be enabled when
+ handling relatively short and entropic state, such as pseudorandom
+ session identifiers. Instead, large and quite regular state blobs
+ could get a significant boost when compressed.
+
+3.2.4. Cookie Encoding
+
+ SCS cookie values MUST be encoded using the alphabet that is URL and
+ filename safe (i.e., base64url) defined in Section 5 of Base64
+ [RFC4648]. This encoding is very widespread, falls smoothly into the
+ encoding rules defined in Section 4.1.1 of [RFC6265], and can be
+ safely used to supply SCS-based authorization tokens within a URI
+ (e.g., in a query string or straight into a path segment).
+
+3.2.5. Outbound Transform
+
+ The output data transformation, as seen by the server (the only actor
+ that explicitly manipulates SCS cookies), is illustrated by the
+ pseudocode in Figure 2.
+
+
+
+
+Barbato, et al. Informational [Page 9]
+
+RFC 6896 SCS March 2013
+
+
+ 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
+
+ A new Initialization Vector is randomly picked (step 1). As
+ previously mentioned (Section 3.1.4), this step is necessary to avoid
+ providing correlation information to an attacker.
+
+ A new ATIME value is taken as the current timestamp according to the
+ server clock (step 2).
+
+ Since the only user of the ATIME field is the server, it is
+ unnecessary for it to be synchronized with the client -- though it
+ needs to use a fairly stable clock. However, if multiple servers are
+ active in a load-balancing configuration, clocks SHOULD be
+ synchronized to avoid errors in the calculation of session expiry.
+
+ The plaintext cookie value is then compressed (if needed) and
+ encrypted by using the key-set identified by TID (step 3).
+
+ If the length of (compressed) state is not a multiple of the block
+ size, its value MUST be filled with as many padding bytes of equal
+ value as the pad length -- as defined by the scheme given in Section
+ 6.3 of [RFC5652].
+
+ Then, the authentication tag, which encompasses each SCS field (along
+ with lengths and relative positions), is computed by HMAC'ing the
+ "|"-separated concatenation of their base64url representations using
+ the key-set identified by TID (step 4).
+
+ Finally, the SCS-cookie-value is created as follows:
+
+ scs-cookie-value = Box(e(DATA), e(ATIME), e(TID), e(IV),
+ e(AUTHTAG))
+
+3.2.6. Inbound Transform
+
+ The inbound transformation is described in Figure 3. Each of the
+ 'e'-prefixed names shown has to be interpreted as the
+ base64url-encoded value of the corresponding SCS field.
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 10]
+
+RFC 6896 SCS March 2013
+
+
+ 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
+
+ First, the inbound scs-cookie-value is broken into its component
+ fields, which MUST be exactly 5, and each at least the minimum length
+ specified in Figure 3 (step 0). In case any of these preliminary
+ checks fails, the PDU is discarded (step 13); else, TID is decoded to
+ allow key-set lookup (step 1).
+
+ If the cryptographic credentials (encryption and authentication
+ algorithms and keys identified by TID) are unavailable (step 12), the
+ inbound SCS cookie is discarded since its value has no chance to be
+ interpreted correctly. This may happen for several reasons: e.g., if
+ a device without storage has been reset and loses the credentials
+ stored in RAM, if a server pool node desynchronizes, or in case of a
+ key compromise that forces the invalidation of all current TIDs, etc.
+
+ When a valid key-set is found (step 2), the AUTHTAG field is decoded
+ (step 3) and the (still) encoded DATA, ATIME, TID, and IV fields are
+ supplied to the primitive that computes the authentication tag (step
+ 4).
+
+ If the tag computed using the local key-set matches the one carried
+ by the supplied SCS cookie, we can be confident that the cookie
+ carries authentic material; otherwise, the SCS cookie is discarded
+ (step 11).
+
+ Then the age of the SCS cookie (as deduced by ATIME field value and
+ current time provided by the server clock) is decoded and compared to
+ the maximum time-to-live (TTL) defined by the session_max_age
+ parameter.
+
+
+
+
+
+Barbato, et al. Informational [Page 11]
+
+RFC 6896 SCS March 2013
+
+
+ If the "age" check passes, the DATA and IV fields are finally decoded
+ (step 8), so that the original plaintext data can be extracted from
+ the encrypted, and optionally compressed, blob (step 9).
+
+ Note that steps 5 and 7 allow any altered packets or expired sessions
+ to be discarded, hence avoiding unnecessary state decryption and
+ decompression.
+
+3.3. PDU Exchange
+
+ SCS can be modeled in the same manner as a typical store-and-forward
+ protocol in which the endpoints are S, consisting of one or more HTTP
+ servers and the client C, an intermediate node used to "temporarily"
+ store the data to be successively forwarded to S.
+
+ In brief, S and C exchange an immutable cookie data block
+ (Section 3.1): the state is stored on the client at the first hop and
+ then restored on the server at the second, as 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
+
+3.3.1. Cookie Attributes
+
+ In the following subsections, a series of recommendations is provided
+ in order to maximize SCS PDU fitness in the generic cookie ecosystem.
+
+3.3.1.1. Expires
+
+ If an SCS cookie includes an Expires attribute, then the 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.
+
+3.3.1.2. Max-Age
+
+ Since not all User Agents (UAs) support this attribute, it MUST NOT
+ be present in any SCS cookie.
+
+
+
+Barbato, et al. Informational [Page 12]
+
+RFC 6896 SCS March 2013
+
+
+3.3.1.3. Domain
+
+ SCS cookies MUST include a Domain attribute compatible with
+ application usage.
+
+ A trailing '.' MUST NOT be present in order to minimize the
+ possibility 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.
+
+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.
+
+ In the following, the term 'key' references both encryption and HMAC
+ keys.
+
+ o The key SHOULD be generated securely following the randomness
+ recommendations in [RFC4086];
+
+ o the key SHOULD only be used to generate and verify SCS PDUs;
+
+ o 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 13]
+
+RFC 6896 SCS March 2013
+
+
+ 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:
+
+ o the inbound transformation authenticates and decrypts/decompresses
+ using T (identified by TID);
+
+ o 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").
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Barbato, et al. Informational [Page 14]
+
+RFC 6896 SCS March 2013
+
+
+5. Cookie Size Considerations
+
+ In general, SCS cookies are bigger than their plaintext counterparts.
+ This is due to the following reasons:
+
+ o inflation of the Base64 encoding of state data (approximately 1.4
+ times the original size, including the encryption padding);
+
+ o 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.
+
+ 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.
+
+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.
+
+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].
+
+
+
+
+
+Barbato, et al. Informational [Page 15]
+
+RFC 6896 SCS March 2013
+
+
+ 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.
+
+7.2. Impact of the SCS Cookie Model
+
+ 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.
+
+ In the following subsections, a set of different attack scenarios
+ (together with corresponding countermeasures where applicable) are
+ identified and analyzed.
+
+7.2.1. Old Cookie Replay
+
+ SCS doesn't address replay of old cookie values.
+
+ In fact, there is nothing that assures an SCS application about the
+ client having returned the most recent version of the cookie.
+
+ 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.
+
+ 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.
+
+ 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].
+
+ 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.
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 16]
+
+RFC 6896 SCS March 2013
+
+
+ The following illustrate some typical use cases:
+
+ o 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.
+
+ o 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).
+
+ o 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.
+
+ o 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).
+
+ 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.
+
+7.2.2. Cookie Deletion
+
+ A direct and important consequence of the missing owner role in SCS
+ is that a client could intentionally delete its cookie and return
+ nothing.
+
+
+
+
+Barbato, et al. Informational [Page 17]
+
+RFC 6896 SCS March 2013
+
+
+ The application protocol has to be designed so there is no incentive
+ to do so, for instance:
+
+ o it is safe for the cookie to represent some kind of positive
+ capability -- the possession of which increases the client's
+ powers;
+
+ o 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.
+
+7.2.3. Cookie Sharing or Theft
+
+ Just like with plain cookies, SCS doesn't prevent sharing (both
+ voluntary and illegitimate) of cookies between multiple clients.
+
+ 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.
+
+ 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.
+
+ 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.)
+
+7.2.4. Session Fixation
+
+ Session fixation vulnerabilities [Kolsec] are not addressed by SCS.
+
+ A more sophisticated protocol involving active participation of the
+ UA in the SCS cookie manipulation process would be needed: e.g., some
+ form of challenge/response exchange initiated by the server in the
+ HTTP response and replied to by the UA in the next chained HTTP
+ request.
+
+
+
+
+
+
+Barbato, et al. Informational [Page 18]
+
+RFC 6896 SCS March 2013
+
+
+ Unfortunately, the present specification, which is based on
+ [RFC6265], sees the UA as a completely passive actor whose role is to
+ blindly paste the cookie value set by the server.
+
+ Nevertheless, the SCS cookies wrapping mechanism may be used in the
+ future as a building block for a more robust HTTP state management
+ protocol.
+
+7.3. Advantages of SCS over Server-Side Sessions
+
+ Note that all the above-mentioned vulnerabilities also apply to plain
+ cookies, making SCS at least as secure, but there are a few good
+ reasons to consider its security level enhanced.
+
+ First of all, the confidentiality and authentication features
+ provided by SCS protect the cookie value, which is normally plaintext
+ and tamperable.
+
+ Furthermore, neither of the common vulnerabilities of server-side
+ sessions (session identifier (SID) prediction and SID brute-forcing)
+ can be exploited when using SCS, unless the attacker possesses
+ encryption and HMAC keys (both current ones and those relating to the
+ previous set of credentials).
+
+ More in general, no slicing nor altering operations can be done over
+ an SCS PDU without controlling the cryptographic key-set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 19]
+
+RFC 6896 SCS March 2013
+
+
+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.
+
+
+
+
+
+Barbato, et al. Informational [Page 20]
+
+RFC 6896 SCS March 2013
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbato, et al. Informational [Page 21]
+
+RFC 6896 SCS March 2013
+
+
+Appendix A. Examples
+
+ The examples in this section have been created using the 'scs' test
+ tool bundled with LibSCS, a free and opensource reference
+ implementation of the SCS protocol that can be found 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"
+
+
+
+
+Barbato, et al. Informational [Page 22]
+
+RFC 6896 SCS March 2013
+
+
+ o ATIME: 1347281709
+
+ o IV:
+ \x1d\xa7\x6f\xa0\xff\x11\xd7\x95\xe3\x4b\xfb\xa9\xff\x65\xf9\xc7
+
+ produce the following tokens:
+
+ o DATA: PbE-ypmQ43M8LzKZ6fMwFg-COrLP2l-Bvgs
+
+ o ATIME: MTM0NzI4MTcwOQ
+
+ o TID: akxIKmhbMTE8
+
+ o IV: HadvoP8R15XjS_up_2X5xw
+
+ o AUTHTAG: A6qevPr-ugHQChlr_EiKYWPvpB0
+
+ In both cases, the resulting SCS cookie is obtained via ordered
+ concatenation of the produced tokens, as described in Section 3.1.
+
+Authors' Addresses
+
+ Stefano Barbato
+ KoanLogic
+ Via Marmolada, 4
+ Vitorchiano (VT), 01030
+ Italy
+
+ EMail: tat@koanlogic.com
+
+
+ Steven Dorigotti
+ KoanLogic
+ Via Maso della Pieve 25/C
+ Bolzano, 39100
+ Italy
+
+ EMail: stewy@koanlogic.com
+
+
+ Thomas Fossati (editor)
+ KoanLogic
+ Via di Sabbiuno 11/5
+ Bologna, 40136
+ Italy
+
+ EMail: tho@koanlogic.com
+
+
+
+
+Barbato, et al. Informational [Page 23]
+