Internet Engineering Task Force S. Barbato
Internet-Draft S. Dorigotti
Intended status: Informational T. Fossati, Ed.
Expires: August 25, 2011 KoanLogic
February 21, 2011
SCS: Secure Cookie Sessions for HTTP
draft-secure-cookie-session-protocol-00
Abstract
This document provides an overview of SCS, a cryptographic protocol
layered on top of the HTTP cookie facility, that allows an origin
server to handle session state without storing it locally.
Its typical use cases include devices with little or no storage
offering some functionality via an HTTP interface, and web
applications with High Availability or load balancing requirements
which may want to handle application state without the need to
synchronize the pool through shared storage or peering.
Nevertheless, its security properties allow it to be used whenever
privacy and integrity of cookies is a concern, at the cost of
increased server CPU and bandwidth usage, and of some "credential-
ownership" implications which will be thoroughly analysed.
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 August 25, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Barbato, et al. Expires August 25, 2011 [Page 1]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
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. 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. SCS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PDU Description . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. SCS_ATIME . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. SCS_DATA . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. SCS_TID . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. SCS_IV . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. SCS_AUTHTAG . . . . . . . . . . . . . . . . . . . . . 7
3.2. Crypto Transform . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Cipher Set . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Compression . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Cookie Encoding . . . . . . . . . . . . . . . . . . . 8
3.2.4. Outbound Transform . . . . . . . . . . . . . . . . . . 8
3.2.5. Inbound Transform . . . . . . . . . . . . . . . . . . 9
3.3. PDU Exchange . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Cookie Attributes . . . . . . . . . . . . . . . . . . 10
3.3.1.1. Expires . . . . . . . . . . . . . . . . . . . . . 11
3.3.1.2. Max-Age . . . . . . . . . . . . . . . . . . . . . 11
3.3.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1.4. Secure . . . . . . . . . . . . . . . . . . . . . . 11
4. Key Management and Session State . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Security of the Cryptographic Protocol . . . . . . . . . . 13
7.2. Impact of the SCS Cookie Model . . . . . . . . . . . . . . 13
7.2.1. Old cookie replay . . . . . . . . . . . . . . . . . . 13
7.2.2. Cookie Deletion . . . . . . . . . . . . . . . . . . . 15
7.2.3. Cookie Sharing or Theft . . . . . . . . . . . . . . . 15
7.3. Advantages of SCS over Server-side Sessions . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Reference Implementation . . . . . . . . . . . . . . 17
Barbato, et al. Expires August 25, 2011 [Page 2]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Barbato, et al. Expires August 25, 2011 [Page 3]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
1. Introduction
SCS is a cryptographic protocol layered on top of the HTTP cookie
facility [I-D.ietf-httpstate-cookie], that allows an origin server to
handle clients' session state without storing it locally.
An SCS enabled server delegates the application state storage to the
client (e.g. a browser) - which basically acts as a remote storage
device. A set of cryptographic transformations is used to ensure
that information authenticity and confidentiality attributes of state
data have the same characteristics as for typical "server-side"
sessions.
Anyway, a peculiar difference between SCS and "server-side" cookie
sessions arises when we carefully consider the roles of the playing
entities. In the "server-side" model, the Server acts a triple role
as the "generator", the "owner", and the "verifier" of cookie
credentials. Instead, a server implementing SCS acts the "generator"
and "verifier" roles only -- the "owner" being inapplicable as long
as we have imposed the no-storage requirement.
In all respects, the Server grants the custody of the generated
cookie to the Client, whose trust model needs to be taken into
consideration when designing applications using SCS. The
consequences of such discrepancy (e.g. deliberate deletion of a
cookie, explicit privilege revocation, etc.) will be explored and
analyzed in Section 7.2.
The no-storage requirement, which is the key design constraint of
SCS, makes it an ideal candidate in the following settings:
a. devices with little or no storage -- typically embedded devices
which provide functionality such as software updates,
configuration, device monitoring, etc. via an HTTP interface;
b. web applications with HA or load balancing requirements, which
may delegate handling of the application state to clients instead
of using shared storage or forced peering, to enhance overall
parallelism.
An SCS server can be implemented within a web application by means of
a user library that exposes the core SCS functionality and leaves
explicit control over SCS cookies to the programmer, or
transparently, by hiding the "diskless session" facility behind a
generic session API abstraction.
Barbato, et al. Expires August 25, 2011 [Page 4]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. SCS Protocol
The SCS protocol defines:
o a PDU, as a well-defined aggregate of cookies (Section 3.1);
o the cryptographic transformations which manipulate the PDU field
(Section 3.2);
o the HTTP-based PDU exchange model (Section 3.3).
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 browser. Only the server is involved in the PDU
manipulation process.
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 HA environment) and C to be the client with a cookie-
enabled browser, or User Agent with equivalent capabilities.
3.1. PDU Description
S and C exchange the same PDU (Section 3.3), which consists of a set
of interdependent cookies tied together by cryptographic
transformations.
Confidentiality is limited to the application state information (i.e.
SCS_DATA cookie), while integrity and authentication apply to the
entire PDU.
The following subsections describe the syntax and semantics of of
each SCS cookie.
3.1.1. SCS_ATIME
Timestamp relating to the last read or write operation performed on
session data, encoded a numeric string holding the number of seconds
since UNIX epoch.
Barbato, et al. Expires August 25, 2011 [Page 5]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
This value is updated with each client contact and is used to
identify expired sessions.
If the received SCS_ATIME value is older 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.
3.1.2. SCS_DATA
Block of encrypted and optionally compressed data, containing session
state. Note that no restriction is imposed on plain text structure:
the protocol is completely agnostic as to state data layout.
If the total size of the SCS_DATA cookie, including name, value and
attributes, exceeds 4096 bytes (see Section 6.1. of
[I-D.ietf-httpstate-cookie]), it is sliced into n SCS_DATA{n}
cookies, each 4KB in size, so that the concatenation of their values
ordered by cookie name (1, 2, ..., N) yields the original SCS_DATA.
It is suggested [I-D.ietf-httpstate-cookie] that browsers accept at
least 50 cookies per domain, which could lead to a theoretical limit
of 184 KB as the maximum allowed state data block.
Anyway, in order to minimize both network bandwidth and client cookie
store consumption, applications should try to upper bound state data
to some sensible value. Also, an SCS implementation MAY decide to
limit the accepted state data to any value greater than or equal to
4KB.
3.1.3. SCS_TID
ASCII string that uniquely identifies the transform set (keys and
algorithms) used to generate this PDU.
SCS assumes that a key-agreement/distribution mechanism exists for
environments in which S consists of multiple servers (it may consist
of a simple key-refresh in the case |S|=1), which provides a unique
external identifier for each transform set defined and shared amongst
pool members.
This identifier (equivalent to a SPI in a Data Security SA [RFC3740])
is represented in the cookie value.
3.1.4. SCS_IV
Initialization Vector used for the encryption algorithm
(Section 3.2).
Barbato, et al. Expires August 25, 2011 [Page 6]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
In order to avoid providing correlation information to a possible
attacker with access to a sample of SCS PDUs, the IV MUST be created
randomly for each PDU.
3.1.5. SCS_AUTHTAG
Authentication tag based on the concatenation of SCS_ATIME, SCS_DATA,
SCS_TID and SCS_IV.
The concatenation operation is done by packing the four strings
containing the base64 encoded values in order (e.g.:
"ZGF0YQ==YXRpbWU=dGlkaXY="), and supplying the resulting string to
HMAC.
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 possibility of using UMAC for authentication [RFC4418] has been
taken into consideration, but priority was given to space over
performance: the nonce field transfer would require an extra cookie,
therefore reducing the space reserved to state information by another
4KB.
The following conventions will be used in the algorithm description
(Section 3.2.4 and Section 3.2.5):
o Enc/Dec(): block encryption/decryption functions (Section 3.2.1);
o HMAC(): authentication function (Section 3.2.1);
o Comp/Uncomp(): compression/decompression functions
(Section 3.2.2);
o e/d(): cookie value encoding/decoding functions (Section 3.2.3);
o RAND(): random number generator [RFC4086].
3.2.1. Cipher Set
Implementors MUST support at least the following algorithms:
Barbato, et al. Expires August 25, 2011 [Page 7]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
o AES-CBC-128 for encryption;
o HMAC-SHA1 with a 128 bit key for authenticity and integrity,
which appear to be sufficiently secure in a wide range of use cases
[Bellare], are widely available, and can be implemented in a few
kilobytes of memory, providing an extremely valuable feature in
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.2. 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.
Compression should not be enabled when handling relatively short and
entropic state (e.g. pseudo random session identifiers). Instead,
large and quite regular state blobs could get a significant boost
when compressed.
3.2.3. Cookie Encoding
Base-64 [RFC4648] is used for encoding/decoding of SCS cookie values.
It is very wide-spread, and falls smoothly into the encoding rules
defined in Section 4.1.1 of [I-D.ietf-httpstate-cookie].
3.2.4. Outbound Transform
The output data transformation as seen by the server (the only actor
which manipulates PDUs) is illustrated by the pseudo-code in
Figure 1.
1. iv = RAND()
2. atime = NOW
3. data = Enc(Comp(state))
4. tag = HMAC(e(data)||e(atime)||e(tid)||e(iv))
Figure 1
NOW is defined as the current timestamp of the server clock.
Since the only user of the atime field is the server, it is
unnecessary for it to be synchronized with the client. However, if
Barbato, et al. Expires August 25, 2011 [Page 8]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
multiple servers are active in a load-balancing configuration, clocks
SHOULD be synchronized to avoid errors in the calculation of session
expiry.
If the length of (compressed) state is not a multiple of the block
size, its value MUST be filled with padding bytes of equal value as
the pad length -- equivalent to the scheme defined in Section 6.3 of
[RFC5652].
Hence the SCS PDU fields are created as follows:
SCS_ATIME = e(atime)
SCS_AUTHTAG = e(tag)
SCS_DATA = e(data)
SCS_TID = e(tid)
SCS_IV = e(iv)
3.2.5. Inbound Transform
The inbound transformation is described in Figure 2.
1. If (tid is available)
2. data' = d($SCS_DATA)
atime' = d($SCS_ATIME)
tid' = d($SCS_TID)
iv' = d($SCS_IV)
tag' = d($SCS_AUTHTAG)
3. tag = HMAC(<data'>||<atime'>||<tid'>||<iv'>)
4. If (tag == tag' && NOW - atime' <= session_max_age)
5. state = Uncomp(Dec(data'))
6. Else discard PDU
7. Else discard PDU
Figure 2
If the cryptographic credentials (encryption and authentication
algorithms and keys identified by SCS_TID) are unavailable (step 7.),
the inbound PDU cannot 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 available TIDs, etc.
Note that step 4. allows any altered packets or expired sessions to
be discarded, hence avoiding unnecessary state decryption and
decompression.
Barbato, et al. Expires August 25, 2011 [Page 9]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
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 3.
1. dump-state:
Set-Cookie: SCS_DATA=...;
Expires=...; Path=...;
Domain=...;
S --> --> C
Set-Cookie: SCS_TID=...;
Expires=...; Path=...;
Domain=...;
...
2. restore-state:
Cookie: SCS_DATA=...;
C --> Cookie: SCS_TID=...; --> S
...
Figure 3
Note that although SCS cookies always have the same naming, there can
be multiple active SCS sessions in use at a given user-agent as long
as the tuple <SCS PDU, Domain, Path> is different.
SCS cookies MUST NOT be folded into a single HTTP header field, see
Section 3 of [I-D.ietf-httpstate-cookie].
3.3.1. Cookie Attributes
All SCS cookies belonging to the same PDU MUST carry the same
attributes' set. This is not elegant nor bandwidth-friendly
solution, but it is necessary in order to guarantee PDU coherence.
In the following sub paragraphs a series of recommendations is
provided in order to maximize SCS PDU fitness in the generic cookie
ecosystem.
Barbato, et al. Expires August 25, 2011 [Page 10]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
3.3.1.1. Expires
SCS cookies MUST include an Expires attribute which shall 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.
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.
4. Key Management and Session State
This specification provides some common recommendations and praxis
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 length SHOULD be at least 128 bits;
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 SCS_TID
Barbato, et al. Expires August 25, 2011 [Page 11]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
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
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 SCS_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 4
As shown in Figure 4, 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.
Barbato, et al. Expires August 25, 2011 [Page 12]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
5. Acknowledgements
We would like to thank David Wagner and Lorenzo Cavallaro for their
valuable feedback on this document.
6. IANA Considerations
This memo includes no request to IANA.
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-EtM scheme described
in [Kohno].
Given a "provably-secure" encryption scheme and MAC (as for the
algorithms mandated in Section 3.2.1), Kohno et al. [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 paragraphs, 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 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 SCS_ATIME value along with the session_max_age configuration
Barbato, et al. Expires August 25, 2011 [Page 13]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
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].
Anyway, a generic solution is still out of scope: an SCS 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.
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.
It may be noteworthy that despite the chances of preventing replay in
some well established circumstances by using aforementioned
mechanisms, if the 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 August 25, 2011 [Page 14]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
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.
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
SCS doesn't prevent sharing (both voluntary and illegitimate) of
cookies between multiple clients.
In the context of voluntary cookie sharing, using HTTPS is useless:
Client certificates are just as shareable as cookies, hence
equivalently to the "server-side" cookie model, there seems to be no
way to prevent this threat.
The 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.
7.3. Advantages of SCS over Server-side Sessions
Note that all the abovementioned vulnerabilities also apply to
typical server-side sessions, making SCS at least as secure (based on
the current analysis), but there are a few good reasons to consider
its security level enhanced.
First of all, the confidentiality feature provided by SCS protects
cookie state information which is normally plain-text.
Furthermore, none of the common vulnerabilities of server-side
sessions (SID prediction, SID brute forcing, session fixation
Barbato, et al. Expires August 25, 2011 [Page 15]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
[Kolsec]) 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 generally no slicing nor altering operations can be done over an
SCS PDU without controlling the cryptographic keyset and cipherset.
8. References
8.1. Normative References
[I-D.ietf-httpstate-cookie]
Barth, A., "HTTP State Management Mechanism",
draft-ietf-httpstate-cookie-22 (work in progress),
February 2011.
[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.
[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.
8.2. Informative References
[Bellare] Bellare, M., "New Proofs for NMAC and HMAC: Security
Without Collision-Resistance", 2006.
[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.
Barbato, et al. Expires August 25, 2011 [Page 16]
Internet-Draft SCS: Secure Cookie Sessions for HTTP February 2011
[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.
[RFC4418] Krovetz, T., "UMAC: Message Authentication Code using
Universal Hashing", RFC 4418, March 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Reference Implementation
A reference implementation (at present in very early stage) of the
SCS protocol can be found at <http://github.com/koanlogic/libscs>.
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, 40139
Italy
Phone: +39 051 644 82 68
Email: tho@koanlogic.com
Barbato, et al. Expires August 25, 2011 [Page 17]