Re: Introducing a Session header...

On Fri, Jul 20, 2012 at 06:35:54PM +1200, Amos Jeffries wrote:
> Client-generated session ID, is just a key / salting value. That gives 
> us a couple of things:

I agree, this is equivalent to salting.

>  1) client can ensure that it is unique (at least relative to any other 
> one they generate) over some long time period
>  2) client can maintain multiple sessions to the same server simultaneously
>  3) client can share session ID between software on their own machine 
> (ie several browser tabs, or a browser tab and some independent 
> credentials manager software)
>  4) client can implement do-not-track by omitting the session ID from 
> any request, OR changing it frequently, OR sending some max-age property 
> for expiry.
>  5) client can "logout" at will by erasing the state associated 
> (possibly informing the server, but not necessarily)
>  6) limited meaning - simplicity leads to better security through 
> easier understanding and thus correct use.
>    Making it mean just "here is a reference ID to the data I have on 
> you" is simple.

OK.

> The server can not be expected to rely on that session ID alone as any 
> kind of UUID. They need to be able to assign session based on that ID 
> *plus* any other information they have available to guarantee the 
> uniqueness (client IP, channel number, socket number, UA header, phase 
> of the moon, whatever)

Warning when you're saying this, some of these info are neither stable
nor unique to the client, they provide low value when building an ID.

>  1) server can use it as a salting value to uniquely identify the 
> separate client sessions. IFF, the server uses additional data to 
> generate the session.
>  2) server can track the session across any requests regardless of 
> delivery method (relative to what the server tacks on as extra key bits 
> for its own end - this also determins/limits theft of session-ID key risk).
>  3) middleware can play to its hearts content, altering session IDs to 
> new values. They mean nothing but opaque blob to the recipients end, 
> worst case is fail-closed if they are used for anything security related.

It's not as simple : if we want it to be simple for both ends, ideally
a fixed-length well-defined ID is fine. However its use will be too
limited (middleware cannot rely only on "learning" IDs, they need to
put deterministic information there such as server identifiers when
performing load balancing between multiple DCs, DMZ, ...).

If we have a variable-sized ID that intermediaries can fiddle with,
then it's harder to put that in the protocol and we risk seeing it
degraded as cookies to put whatever in them.

Maybe we need a specific part for routing information, but I'm really
not convinced this is needed. I think in fact that the client-generated
ID should be fix-sized and always present, and that the server-generated
part could be variable with a limited size so that it is not abused
anymore.

> What we have in abstract is a shared session between client and server, 
> where those client/server endpoints may be any number of Federated 
> softwares or machines. Each end has its own state, which may or may not 
> be conveyed over the links,

Wait a minute, a few times in this thread I felt like there was an issue
here, it's important to keep in mind that there is not a single-end on the
server side. Servers are often split between multiple machines, multiple
DMZ, multiple areas, multiple DCs for a single client session, and with
various possible paths between them without the client ever being aware
of it. It's important because there is not an "own state" as called here,
but a global state made of many independant states.

(...)
> >Based on your first point above, I think that the client could build
> >*part* of the ID. If the client generates a 64-bit random for instance,
> >it doesn't ensure unicity, which is a server's task, but it saves it
> >from being injected another ID. So from the server's point of view,
> >a client could be identified by the couple of (ID1,ID2) where ID1 is
> >invented by the client and unknown from JS and ID2 is invented by the
> >server.
> 
> Exactly. Neither end being required to complete the session, or even to 
> inform what its internal session ID key (or even algorithm) is.
> 
> >We could then even keep cookies as they are for ID2, and just use a
> >new identifier for ID1. That way we remain compatible with HTTP/1
> >(important goal) and HTTP/2to1 gateways can pass ID1 into a header
> >field that the server can use.
> 
> IMO, we can ignore Cookies as headers for all of this. Sessions in 
> Cookies are already largely the provence of web servers and if servers 
> and browser roll out the new session they will be able to drop use of 
> session-cookie cleanly when Session-ID no longer needs to be 
> encapsulated inside one.

Only when the session-id is able to convey as much information as is
needed to route the request to its target. Right now cookies are used
*a lot* for this. I know some places where there are up to 6 layers
of server farms with multiple possible paths between them (think many
portals for similar access to same information), and the only way to
know where to pass through is to use the information inserted by LBs
into cookies. To completely get rid of cookies we need to be able to
store this routing information somewhere else (I would love this, so
that we don't have to deal with this horrible cookie header anymore).
But this is not a small issue to deal with.

> Cookies as used for data transfer is a different problem entirely and 
> should not be tackled by the creation of a session state semantics. 

Cookies are even more generic, they're just a copy of opaque data the
server needs when the client gets back. Originally it was just a way
to find the pointer to the session (which is routing information as
well after all). But they were completely abused to carry anything
everywhere and the first issue is that JS has access to them.

> Simply removing the credential-like identifier from Cookie will go a 
> long way towards clearing up the mess.

Agreed!

Willy

Received on Friday, 20 July 2012 07:03:07 UTC