Shibboleth Developers

[Chad La Joie <>]

We currently do various things to try and guard our IdP's session:
using  cryptographic random identifiers to prevent session fixation,
checking IP addresses to prevent hijacking, and computing a MAC over
the data to ensure data integrity.  Scott's work on channel bindings,
and the Servlet 3.0 spec, gave me the idea that another option would
simply be to bind the session to the TLS session ID.

Doing this seems like it would address all the aforementioned issues
and obviate the need for a session cookie (in most cases, see below).
Those seem like two big wins.  It should also address the issues that
occasionally turn up when there are not-so-transparent proxies between
the browser and the IdP (e.g., ones that randomly change the client's
IP address).

I can, however, see a few possible issues with using the TLS session
identifier.  First, the IdP may not be using TLS (either because it's
just a test system or because they really don't need it for some
reason).  In that case I think the IdP can just fall back to doing
what we do now.  Second, the IdP may be behind TLS-terminating
hardware (e.g., web server, load balancer, accelerator) but all such
systems this that I've encountered can be configured to pass the TLS
data through and if they don't then it just looks like the previous
case.  Lastly, and this is my big concern, browsers may do dumb things
and, seemingly randomly, drop/restart TLS sessions.

Does anyone have any experience really using these TLS session
identifiers in their web apps?  If so, what sorts of issues did you
encounter?  Did you find solutions to them?

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered