Internet DRAFT - draft-secure-cookie-session-protocol
draft-secure-cookie-session-protocol
Internet Engineering Task Force S. Barbato
Internet-Draft S. Dorigotti
Intended status: Informational T. Fossati, Ed.
Expires: June 5, 2013 KoanLogic
December 2, 2012
SCS: Secure Cookie Sessions for HTTP
draft-secure-cookie-session-protocol-09
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.
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. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2013.
Copyright Notice
Copyright (c) 2012 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
Barbato, et al. Expires June 5, 2013 [Page 1]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Barbato, et al. Expires June 5, 2013 [Page 2]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Security of the Cryptographic Protocol . . . . . . . . . . 16
8.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 16
8.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 16
8.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 18
8.2.3. Cookie Sharing or Theft . . . . . . . . . . . . . . . 18
8.2.4. Session Fixation . . . . . . . . . . . . . . . . . . . 18
8.3. Advantages of SCS over Server-side Sessions . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
A.1. No Compression . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Use Compression . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Barbato, et al. Expires June 5, 2013 [Page 3]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 to establish
"client mode" sessions. This is not their sole possible usage, and
while no other operational patterns are outlined here, it is expected
that SCS tokens may be easily employed as a building block for other
kind 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 8.2. Please note that
they may not cover all possible scenarios though, and must therefore
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,
for example by hiding a "diskless session" facility behind a generic
session API abstraction. 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. Expires June 5, 2013 [Page 4]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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' Base-64 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. Expires June 5, 2013 [Page 5]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 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 re-validation 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 clear text structure: the protocol is completely
agnostic as to inner data layout.
Generally speaking, the plain text is the "normal" cookie that would
have been exchanged by S and C if SCS had not been used.
Barbato, et al. Expires June 5, 2013 [Page 6]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
3.1.3. TID
This identifier is equivalent to a 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, which provides
a unique external identifier for each transform set shared amongst
pool members.
Such 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], [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 based on the plain string concatenation of the
base64url encoded DATA, ATIME, TID and IV fields, 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. Expires June 5, 2013 [Page 7]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 CBC-mode encryption and 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
(Section 3.2.5 and Section 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 of the inputs 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 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 correctness 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.
This feature makes the protocol robust against attacks aimed at
Barbato, et al. Expires June 5, 2013 [Page 8]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
disrupting the security of SCS PDUs by freely moving boundaries
between adjacent atoms.
3.2.2. Cipher Set
Implementors 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 case Comp/Uncomp
are replaced by an identity matrix). If this function is enabled,
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 pseudo random
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 URL and filename safe
alphabet (i.e. base64url) defined in section 5 of Base-64 [RFC4648].
This encoding is very wide-spread, 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
which explicitly manipulates SCS cookies) is illustrated by the
pseudo-code in Figure 2.
Barbato, et al. Expires June 5, 2013 [Page 9]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 plain text 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(tag))
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. Expires June 5, 2013 [Page 10]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 of all, the inbound scs-cookie-value is broken into its
component fields which MUST be exactly 5, and each at least of the
minimum length specified in Figure 1 (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 TID's,
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 defined by the session_max_age parameter.
If the "age" check passes, the DATA and IV fields are finally decoded
Barbato, et al. Expires June 5, 2013 [Page 11]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
(step 8.), so that the original plain text 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 sub paragraphs 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 UAs support this attribute, it MUST NOT be present in
any SCS cookie.
Barbato, et al. Expires June 5, 2013 [Page 12]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 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.
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
Barbato, et al. Expires June 5, 2013 [Page 13]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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 only one refresh attribute also 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.
5. Cookie Size Considerations
In general, SCS cookies are bigger than their plain text
Barbato, et al. Expires June 5, 2013 [Page 14]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
counterparts. This is due to the following reasons:
o inflation of the Base-64 encoding of state data (approx. 1.4 times
the original size, including the encryption padding);
o the fixed size increment (approx. 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 plain text 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.8KB.
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. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
Barbato, et al. Expires June 5, 2013 [Page 15]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
8.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].
Given a "provably-secure" encryption scheme and MAC (as for the
algorithms mandated in Section 3.2.2), Kohno et al. [Kohno]
demonstrate that their composition results in a secure authenticated
encryption scheme.
8.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 paragraphs, a set of different attack scenarios
(together with corresponding countermeasures where applicable) are
identified and analyzed.
8.2.1. Old cookie replay
SCS doesn't address replay of old cookie values.
In fact, there is nothing that guarantees 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 allow 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., SSL/TLS [RFC5246] or IPsec
[RFC4301].
A native solution is not in scope with the security properties
inherent to an SCS cookie. Hence, 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
Barbato, et al. Expires June 5, 2013 [Page 16]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
as valid credentials and/or (b) getting any advantage by replaying
them.
In the following, some typical use cases are illustrated:
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 cid's 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 cid's, 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.
Barbato, et al. Expires June 5, 2013 [Page 17]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
8.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.
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.
8.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 8.2.1) may
cancel this risk.
The risk of theft could be mitigated by securing the wire (e.g. via
HTTPS, IPsec, VPN, ...), 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.)
8.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
Barbato, et al. Expires June 5, 2013 [Page 18]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
form of challange-response exchange initiated by the Server in the
HTTP response and replied to by the UA in the next chained HTTP
request.
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.
8.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 plain text
and tamperable.
Furthermore, neither of the common vulnerabilities of server-side
sessions (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.
9. References
9.1. Normative References
[NIST-AES]
"Advanced Encryption Standard (AES)", NIST, FIPS PUB 197,
November 2001.
[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
Barbato, et al. Expires June 5, 2013 [Page 19]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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.
9.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.
Barbato, et al. Expires June 5, 2013 [Page 20]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
[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 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 Plain text 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 Plain text cookie: "a state string"
o AES-CBC-128 key: "123456789abcdef"
Barbato, et al. Expires June 5, 2013 [Page 21]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
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
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
Barbato, et al. Expires June 5, 2013 [Page 22]
Internet-Draft SCS: Secure Cookie Sessions for HTTP December 2012
Thomas Fossati (editor)
KoanLogic
Via di Sabbiuno 11/5
Bologna, 40136
Italy
Phone: +39 051 644 82 68
Email: tho@koanlogic.com
Barbato, et al. Expires June 5, 2013 [Page 23]
