doc: Add RFC documents

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]
+