Re: Introducing a Session header...

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:

> 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
>
>
>