Subject: Re: Introducing a Session header...

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 20 Jul 2012 12:30:52 +0200

>> But they were completely abused to carry anything
>> everywhere and the first issue is that JS has access to them.

>Aye. But to kill them we have to pull out their utility and provide
>easier tools for their users to work with.

Actually the main cookie issue is that their scope is fuzzy, so everyone
(server, intermediaries, user agents) applies heuristics to what has
access and when, resulting in very brittle configurations that are abused
just by stepping outside the heuristic writer assumptions (most often
without malicious thoughts). And because agents tend to be conservative
about the scope to avoid breakage, it was open to many abuses.

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)

4. it also explicitely tags the URLs over which it expects stateful answers

5. the user agent tags its use of those URLs with the id it provided at
the beginning of the interaction

6. if at any point server of user agent get any answer/request that
reference an unknown or stale tag/id (too old, node ip change , whatever)
they dump it (or request a retry with a 'good' id if you prefer). No one
is supposed to reuse anything tagged with an old session id.

7. multiple levels of state can exist at the same moment, but they are all
transient (secure clients refuse indefinite states)

That is more reliable and less open to abuses (and it prevents all the
breakage that occurs when some content is served from cache or a page is
reloaded). But it forces the server (not the client) to maintain what's
associated with a particular state and to define precisely the state
boundaries. So it's going to be more expensive for webapp authors. And
it's not going to be popular web application-side (but then reliable is
never cheap for the easy cases. Reliable forces everyone to pay the
difficult cases costs). Cookies are convenient just like global variables
in php were convenient till people realised they were too abuse-prone to
live.

(and this is not intended to be secure, just protect from the problems
that occur today when one part of the chain gets confused over what it can
reuse. For security you probably need to add more)

I'm quite sure that if such a mechanism existed today the EU would have
just banned cookie use altogether.

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 10:41:24 +0000

In message <[email-masked]>, "Nicol

>and provides a unique state tag (short so it can not be abused for

I think we can speed up this safely by allowing the client to always
offer a unique ID without being asked.  If the server doesn't need it,
it will just ignore it.

>just banned cookie use altogether.

Indeed.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 20 Jul 2012 13:14:39 +0200

> offer a unique ID without being asked.  If the server doesn't need it,

The problem if you do it this way is that:
1. state becomes implicit to anyone but the server
2. the user agent has no information when it can switch id without
breaking apps
3. the user agent has no information if it should share the id with
another site or not
4. you make it unsafe to cache anything if app writers posit (as they will
if you don't force them to delimit state boundaries) that they can rely on
responses not being shared between user agents that sent different ids

So user agents will end up publishing all the time an id with indefinite
lifetime, on all web sites (I'm pretty sure this is bad for privacy, it
would be worse than the doubleclick cookies)

Now of course I'm not a security expert so I'll bow to their judgement.

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 12:35:23 +0000

In message <[email-masked]>, "Nicol

>3. the user agent has no information if it should share the id with

Ohh, that's the disconnect:  It should _never_ share the session-id
with any other site, that's sort of the entire point.

As for how long the session lasts ?

By default: Until user switches to another site, closes the
tab/window/computer or by other means makes the intention clear.

*unless* the user by positive action indicates to the user-agent
that she wants a persistent session to that site.

---

From: Ross Nicoll <[email-masked]>
Date: Fri, 20 Jul 2012 13:45:50 +0100

> with any other site, that's sort of the entire point.
We rather do want sites to share session IDs, actually, so we can do 
easy single-sign-on. At the moment we fairly much only do this within a 
domain, but in the future we might see something like Project Moonshot ( 
http://www.project-moonshot.org/ ) providing single-sign-on for all UK 
academic institutions (this is really useful for cases such as external 
examiners being able to access resources in institutions not their own, 
for example). Of course, we do also want to control how session IDs are 
shared (I don't think it's something I'd want my bank doing!)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 12:51:04 +0000

>easy single-sign-on.

I'm all for single-sign-on, but they need to use a different nonce
than the session-id I'm talking about.

The session-id I'm talking about, are mainly for letting HTTP routers
chose the same server for the entire sessions, without having to
dig through cookies.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 14:53:24 +0200

> shared (I don't think it's something I'd want my bank doing!)

Note that SSO actually does work cross-domain using redirects. It's just
not the easiest thing to do but it does work. Cross-domain cookies are
extremely dangerous and badly used. I regularly see some websites ask me
for help with their site behaving in a bad way using new browsers and I
can tell you that sometimes you see scary things. I'm glad Adam Barth has
worked on RFC6265 to remind what's right and what's wrong.

Regards,
Willy

---

From: Jonathan Ballard <[email-masked]>
Date: Fri, 20 Jul 2012 07:19:33 -0700

The SSO is something we negotiate between two or more origin servers, and
the UAs need not be part of that negotiation. It's may be the
simpler design step to use the UAs for such negotiation between servers
(with such "session header") after we establish the connection, yet that
does not help secure authentication.

The hint for redirection is correct, the origin server(s) may create new
resource, upon UA connection,  and encode any session/state in that
resource without affect to the headers.

On Friday, July 20, 2012, Willy Tarreau wrote:

> > >In message <[email-masked]<javascript:;>
> >,
> > >"Nicol
> > >as Mailhot" writes:
> > >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 10:32:46 -0400

> chose the same server for the entire sessions, without having to

I think it would be good to have just one of these and it could cut
down on the number of cookies a browser needs to store/track.

The REST argument seems to be a red herring to me. If people want to
write stateless servers then fine, they can use a different technique.
There have been statefull servers on the Web since 1993. That is why
the POST method is written the way it is. The design goal was to
separate out the idempotent methods from the rest.

You can't do an application like Web Mail without loca state because a
mailspool IS state.

But it is quite easy for the session-ID to be used for routing without
state at either end:

Session-ID: Base64 ( HMAC-SHA2-256 ( host-domain, client-secret ))

Client only needs to store the variable 'client secret' which is the
same for all domains. The specification does not need to be tied to
any crypto algorithm as it is just an opaque blob with at least 256
bits of randomness (the birthday attack is an issue here for a
change).

A router can then take as many bits as it needs to identify the
'bucket' to direct the response to and then map 'buckets' to back-end
servers as required to meet need.

An application can use the session-id as an index into whatever table
it has to maintain per-connection state - which is why you would need
a router in the first place.

Having said that, this is not a total slam dunk for doing client side
state as you might also want to achieve the same thing with a server
pushed token being used in an authentication scheme.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 14:58:04 +0000

In message <[email-masked]>

>pushed token being used in an authentication scheme.

That's why I'm hope we can find a card-carrying cryptographer to
help us, I'd hate to do it almost but not quite right.

---

From: Ross Nicoll <[email-masked]>
Date: Fri, 20 Jul 2012 16:13:53 +0100

Ah, sorry, had misintepreted the phrase session (I was thinking somewhat 
of the way Java servlets manage a user session). On that note though, 
probably worth thinking about an alternative header name... 
"Connection-Session" perhaps? Although I'm not sure that's much clearer, 
any other suggestions?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 17:20:30 +0200

On 2012-07-20 16:32, Phillip Hallam-Baker wrote:
> ...
> ...

ReST is not about stateless servers. If it was, we wouldn't have write 
operations.

Best regards, Julian

---

From: Philippe Mougin <[email-masked]>
Date: Fri, 20 Jul 2012 17:58:08 +0200

> You can't do an application like Web Mail without loca state because a

But REST allows having state on the server (resource state, so no need for session identifiers) and also allows having session state, provided it isn't stored on the server. You can do all sorts of supercool webmail systems with that.
So REST != fully stateless, and it could be useful to ponder the idea that designing without session state stored on the server is good for system such as the Web.

P.M.

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 09:40:43 -0700

On Fri, Jul 20, 2012 at 3:30 AM, Nicolas Mailhot <
[email-masked]> wrote:

> [snip]
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

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 09:43:06 -0700

> offer a unique ID without being asked.  If the server doesn't need it,
Again, just brainstorming on this.... not sure if this works..

Client                 Server
  |                      |
  |=====================>|
  |1)KEY_NEGO            |
  | id=1                 |
  | alg=session_key      |
  | params=...           |
  |                      |
  |=====================>|
  |2)SYN_STREAM          |
  | id=1                 |
  | method=GET           |
  | session_key=1        |
  |                      |

---

From: Jonathan Ballard <[email-masked]>
Date: Fri, 20 Jul 2012 10:19:12 -0700

I have seen that kind tight-loop often enough, and I suggest to consider
any loop like that as SPDY in the manner one-step ahead.

In that sense, I can then say we can use Microsoft's post about the
Multi-Legged authentication scheme and consider SPDY as one of the options
along with Kerberos (and others).

For the political mode, later, it wraps client-server technology into
HTTP/2 that was not so wrapped in HTTP/1.x

On Friday, July 20, 2012, James M Snell wrote:

>
>
> On Fri, Jul 20, 2012 at 3:41 AM, Poul-Henning Kamp <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> In message <[email-masked]<javascript:_e({}, 'cvml',
>> [email-masked]');>>, "Nicol
>> as Mailhot" writes:
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 14:17:22 -0400

> help us, I'd hate to do it almost but not quite right.

I am not sure that anyone issues cards for Web cryptographic protocol
design. If they ever do, I think I can fairly claim card number 001.

Don't worry about HTTP shipping with wrong or bad crypto due to lack
of over oversight. At this point that is just not going to happen. I
think it more likely we have the opposite problem of too many people
sticking their oar in.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 20:05:31 +0000

In message <CAMm+LwiJVWMqE+_R87c+rUpyzVt-Ge2jS2kt-Dnna=[email-masked]>

>design. If they ever do, I think I can fairly claim card number 001.

Dunno, I have always been yelled at for not being "a real cryptographer"
so there must at least be a secret handshake of some sort :-)

For the session-id I'm talking about, the transport-routing session-id,
I'm mostly worried about here is getting the privacy aspect wrong, and
ending up with something which the EU bans.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Jul 2012 00:30:32 +0300

> so there must at least be a secret handshake of some sort :-)

It's not a handshake. It's an extension to Internet lawyering.

You begin your message with the disclaimer "I am not a cryptographer, but" and then proceed to make whatever outrageous claims you want. For extra credit, end your message with the claim that this is secure only in the random oracle model.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 18:21:38 -0400

> so there must at least be a secret handshake of some sort :-)

The people shouting tend to be people who mistake disagreement with their
misunderstanding of his Bruce-ship with not understanding cryptography.

> ending up with something which the EU bans.

I would not worry too much about that. The EU has not banned cookies, they
have banned using them for certain nefarious ends. What is being proposed
here is much smaller in scope and more highly constrained.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 21 Jul 2012 12:27:45 +1200

On 21/07/2012 2:19 a.m., Jonathan Ballard wrote:
> The SSO is something we negotiate between two or more origin servers, 
> and the UAs need not be part of that negotiation. It's may be the 
> simpler design step to use the UAs for such negotiation between 
> servers (with such "session header") after we establish the 
> connection, yet that does not help secure authentication.
>

Indeed. The securest setup for SSO is to have the cleint present unique 
session-ID to each server *also* to provide the same credentials.
Both servers knowing which DC to validate those credentials against they 
can register their internal state-reference to the account.
The client never sees any of the server IDs or federation activity. When 
done right eavesdroppers with access to both connections cannot link the 
two credential sets easily.

> The hint for redirection is correct, the origin server(s) may create 
> new resource, upon UA connection,  and encode any session/state in 
> that resource without affect to the headers.

Separate UA generated session-ID is *essential* here since the redirect 
may have been added/triggered by an attacker. Handing them a 
pre-authenticated session ID is not acceptible. The only hope of 
detecting and protecting against such attackes is to require the 
attacker to repeat the authentication process where they should get 
caught (if it was auth worth its cost).

Amos

---

From: Jonathan Ballard <[email-masked]>
Date: Fri, 20 Jul 2012 18:35:46 -0700

To move forward on this without the redirect, the "Separate UA generated
session-ID" is just that. The User and Agent are not the same, so there
are, at least, three end-points, instead of two. The redirect, then, does
not exist between the user end-point and the agent end-point, as you
expect. The redirect may exist between the agent end-point and the origin
server.

That allows us to have the agent at HTTP 2, or later, and keep the origin
server at the most stateless HTTP 1.1. I wrote more description about the
user end-point in such scenario, yet I trashed it several times already.
Easier if I keep it summarized to an example snippet under ASP.NET where
"runat=server" allows its process to migrate to the agent or where we can
replace "runat=client" with "runat=agent". That is not so comprehensible in
javascript since the agent is then virtual, and you run into concerns as
you mentioned.

On Friday, July 20, 2012, Amos Jeffries wrote:

>> the UAs need not be part of that negotiation. It's may be the simpler
>> design step to use the UAs for such negotiation between servers (with such
>> "session header") after we establish the connection, yet that does not help
>> secure authentication.
>>
>>
> pre-authenticated session ID is not acceptible. The only hope of detecting
> and protecting against such attackes is to require the attacker to repeat
> the authentication process where they should get caught (if it was auth
> worth its cost).
>
> Amos
>
>
>