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

tho <tho@koanlogic.com> Wed, 23 February 2011 10:23 UTC

Return-Path: <tho@koanlogic.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052563A6836 for <http-state@core3.amsl.com>; Wed, 23 Feb 2011 02:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGnki3alfuCQ for <http-state@core3.amsl.com>; Wed, 23 Feb 2011 02:23:44 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by core3.amsl.com (Postfix) with ESMTP id 71C933A6839 for <http-state@ietf.org>; Wed, 23 Feb 2011 02:23:43 -0800 (PST)
Received: from 93-63-252-189.ip30.fastwebnet.it ([93.63.252.189]:29251 helo=abergantin2.sunriseitaly.sunrisetelecom.com) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1PsBtL-00084Q-6A; Wed, 23 Feb 2011 05:24:29 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: tho <tho@koanlogic.com>
In-Reply-To: <AANLkTinYuzfqGLVvGh-O2TxnVhwVRiOurPS-72B+KQz2@mail.gmail.com>
Date: Wed, 23 Feb 2011 11:24:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <24FCC78D-AFC9-4B87-93C6-E62EFCB56D83@koanlogic.com>
References: <6B225A95-E14E-4178-AF98-689C3161A584@koanlogic.com> <AANLkTinYuzfqGLVvGh-O2TxnVhwVRiOurPS-72B+KQz2@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1082)
X-SA-Exim-Connect-IP: 93.63.252.189
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: :
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com)
Cc: http-state@ietf.org
Subject: Re: [http-state] SCS I-D document
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 10:23:45 -0000

Hello Adam,

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.

ciao, t.