Subject: [http-state] SCS I-D document

From: tho <[email-masked]>
Date: Tue, 22 Feb 2011 21:22:05 +0100

Hello all,

we have just uploaded the following I-D:

http://www.ietf.org/id/draft-secure-cookie-session-protocol-00.txt

The draft describes a tiny cryptographic protocol layered on top of cookies, that can be used to handle session state in cases where the origin server doesn't want to, or simply can't, use local storage.  

It targets web server applications deployed on embedded devices with small or no disk, as well as distributed/parallel web apps that could benefit from the lack of a centralized data store or some other peering mechanism to maintain clients' state.

We were wondering if the draft could be taken as a working item by the http-state WG, in which case we're available to drive the related editing, implementation and interoperability activities.

In this respect, we've implemented a beta version of the protocol in one of our products, and are currently working on a reference implementation which will be licensed as Public Domain, BSD or GPL'd software, depending on the linked crypto toolkit.

The source code can be found at http://github.com/koanlogic/libscs and is open to contribution from anyone who wants to join: we have just setup the libscs-dev mailing list (http://koanlogic.com/cgi-bin/mailman/listinfo/libscs-dev) to coordinate the code development. 

Any comment is very welcome !

t.

---

From: Adam Barth <[email-masked]>
Date: Tue, 22 Feb 2011 14:16:15 -0800

Thanks for the draft.  I'm not sure I quite understood what problem
this protocol addresses or how it addresses that problem.  Maybe
including some example protocol traces with an explanation of what's
going on would be helpful?  For example,
<http://tools.ietf.org/html/draft-ietf-httpstate-cookie-22#section-3.1>
shows some example uses of the cookie protocol.

Adam

On Tue, Feb 22, 2011 at 12:22 PM, tho <[email-masked]> wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: tho <[email-masked]>
Date: Wed, 23 Feb 2011 11:24:15 +0100

Hello Adam,

On Feb 22, 2011, at 11:16 PM, Adam Barth wrote:
> this protocol addresses or how it addresses that problem.  

the problem is the following: suppose a web app needs to save its execution state with a given client and has no local storage available to do so.

It can pack the state (say "user=bob;role=admin;auth=ok;lang=en_us;..."), create an SCS cookie out of it, and send the SCS cookie to the client.

An SCS cookie is created such that:
a) the state string can be seen in clear-text by no one but the web application;
b) it embeds ancillary information that carries the proof of authorship of the given web application over the cookie.

So, when the client returns to the web app, the latter can verify that:
a) the supplied SCS cookie was its (i.e. generated by the web app),
b) the state string has not been tampered;
this way it can safely restore state and continue execution (or reject in case any of the two properties can't be satisfied).

This is especially useful in embedded devices (think for example of an home router with a web app providing configuration and monitoring via HTTP running from firmware), but could also come in handy at a completely different magnitude order.  When you have to deal with a massive web app you usually need to rely on a centralized storage to save/restore session state shared by the multiple nodes.  Using SCS cookies each node can dump/restore global application state independently, provided all the nodes are initially feeded with the same crypto material (i.e. the same ~64 bytes of entropy).

Hope the intent is less opaque now, of course I'm available for any further clarification.

ciao, t.

---

From: Adam Barth <[email-masked]>
Date: Wed, 23 Feb 2011 02:41:10 -0800

> Hope the intent is less opaque now, of course I'm available for any further clarification.

Why does the server need any help from the user agent?  It seems like
the server can just encrypt and mac the data itself and store it in a
cookie.

Adam

---

From: tho <[email-masked]>
Date: Wed, 23 Feb 2011 12:04:47 +0100

Hello Adam,

On Feb 23, 2011, at 11:41 AM, Adam Barth wrote:
> Why does the server need any help from the user agent?  

It doesn't, as long as the user agent has cookie support enabled, SCS works fine.

> It seems like the server can just encrypt and mac the data itself and store it in a cookie.

There are many ways in which a server could try to do authenticated encryption, and some are plain wrong
(http://www.iacr.org/cryptodb/data/paper.php?pubkey=11891).

SCS uses a scheme which is provably secure, and offers a single interface for doing such things.

It is what standards exist for, right ? :)

ciao, t.