SCS: Secure Cookie Sessions for HTTP
draft-secure-cookie-session-protocol-03

The information below is for an old version of the document
Document Type Expired Internet-Draft (individual)
Authors Stefano Barbato  , Steven Dorigotti  , Thomas Fossati 
Last updated 2012-06-22 (latest revision 2011-12-20)
Stream (None)
Formats
Expired & archived
pdf htmlized bibtex
IETF conflict review conflict-review-secure-cookie-session-protocol
Additional Resources
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-secure-cookie-session-protocol-03.txt

Abstract

This document provides an overview of SCS, a small cryptographic protocol layered on top of the HTTP cookie facility, that allows its users to produce and consume authenticated and encrypted cookies, as opposed to usual cookies, which are un-authenticated and sent in clear text. An interesting property, rising naturally from the given confidentiality and authentication properties, is that by using SCS cookies, it is possible to avoid storing the session state material on the server side altogether. In fact, an SCS cookie presented by the user agent to the origin server can always be validated (i.e. possibly recognized as self-produced, untampered material) and, as such, be used to safely restore application state. Hence, typical use cases may include devices with little or no storage offering some functionality via an HTTP interface, as well as web applications with high availability or load balancing requirements which would prefer to handle application state without the need to synchronize the pool through shared storage or peering. Nevertheless, its security properties allow SCS to be used whenever the privacy and integrity of cookies is a concern, by paying an affordable price in terms of increased cookie size, additional CPU clock cycles needed by the symmetric key encryption and HMAC algorithms, and related key management, which can be made a nearly transparent task.

Authors

Stefano Barbato (tat@koanlogic.com)
Steven Dorigotti (stewy@koanlogic.com)
Thomas Fossati (tho@koanlogic.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)