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

Adam Barth <ietf@adambarth.com> Wed, 23 February 2011 10:40 UTC

MIME-Version: 1.0
In-Reply-To: <24FCC78D-AFC9-4B87-93C6-E62EFCB56D83@koanlogic.com>
References: <6B225A95-E14E-4178-AF98-689C3161A584@koanlogic.com> <AANLkTinYuzfqGLVvGh-O2TxnVhwVRiOurPS-72B+KQz2@mail.gmail.com> <24FCC78D-AFC9-4B87-93C6-E62EFCB56D83@koanlogic.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 23 Feb 2011 02:41:10 -0800
Message-ID: <AANLkTi=Cd7rxUY5s3ZvWr1p66Y772Vvt=EWu2O_FAokq@mail.gmail.com>
To: tho <tho@koanlogic.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] SCS I-D document
Precedence: list

On Wed, Feb 23, 2011 at 2:24 AM, tho <tho@koanlogic.com> wrote:
> On Feb 22, 2011, at 11:16 PM, Adam Barth wrote:
>> Thanks for the draft.  I'm not sure I quite understood what problem
>> 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.

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

[http-state] SCS I-D document tho
Re: [http-state] SCS I-D document Adam Barth
Re: [http-state] SCS I-D document tho
Re: [http-state] SCS I-D document Adam Barth
Re: [http-state] SCS I-D document tho