W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Introducing a Session header...

From: James M Snell <jasnell@gmail.com>
Date: Fri, 20 Jul 2012 09:40:43 -0700
Message-ID: <CABP7Rbeu4Q-qugwvLpLHONRFp3HcTKRsYCJnVv+=uXFGAL3vvg@mail.gmail.com>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, Willy Tarreau <w@1wt.eu>, ietf-http-wg@w3.org
On Fri, Jul 20, 2012 at 3:30 AM, Nicolas Mailhot <
nicolas.mailhot@laposte.net> wrote:

> [snip]
> To have a reliable system you would need something like the following:
>
> 1. at the start of a stateful interaction the server (only actor that
> knows it will need state) challenges the user agent for a new unique id,
> and provides a unique state tag (short so it can not be abused for
> anything else)
>
> 2. the user agent generates it following its own rules and sends it to the
> server. Server gets no say in what ends up in the id (can only reject it
> if not unique)
>
> 3. the server then tags anything related to this state with its tag (bank
> logo is not stateful, even if sent over tls, it's ok for the user agent to
> reuse it later in another tab)
>
>
Just thinking off the top of my head... not sure if this works or not as I
had not originally thought of the possibility of using this for this kind
of session but consider the KEY_NEGO mechanism I describe here:
http://chmod777self.blogspot.com/2012/07/spdy-in-session-key-negotiation.html

Consider..

Client                  Server
   |                      |
   |=====================>|
   |1)SYN_STREAM          |
   |  id:1                |
   |  method:get          |
   |                      |
   |<=====================|
   |2)KEY_NEGO            |
   |  id=2                |
   |  alg=session_key     |
   |  params=...          |
   |                      |
   |=====================>|
   |3)KEY_NEGO            |
   |  id=2                |
   |  alg=session_key     |
   |  params=...          |
   |                      |
   |<=====================|
   |4)SYN_REPLY           |
   |  id=1                |
   |  session_key=2       |
   |  status: 200         |
   | ...                  |

Using this approach, either end can maintain a session secret that prevents
the session from being hijacked, an the streams themselves are tagged with
a identifier that can be used for persistent routing / session stickiness.

I dunno if that works or not, but will definitely have to give some more
thought to it....

- James
Received on Friday, 20 July 2012 16:41:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 16:41:38 GMT