[Freeipa-devel] Web SSO and securely storing the ccache

[Jason Gerard DeRose]

On Thu, 2009-07-09 at 20:32 -0400, John Dennis wrote:
> I think the dirsec folks should review this too, perhaps you might want 
> to cc them as well.
> 
> What purpose is the sha56 hash of the session key serving? It appears to 
> be only used for look-up purposes, if that's the case why not just 
> lookup based on the session key?

The session_key is what's used to encrypt the ccache, so we don't want
to store it on the server at all (certainly not in the same table as the
ccache).  Doing a one-way-hash of the session_key is a simple way to
preserve the association with the session_key without storing the
session_key in the session table.

> You didn't state if this scheme would be restricted to only SSL/TLS 
> sessions, if not then ...

The IPA web UI and XML-RPC are only accessibly via SSL (right, Rob?).
Obviously the scheme I presented can't be used over clear HTTP.

> The session key is visible in the HTML headers, correct? Doesn't that 
> mean all one would need to do is sniff the session key to masquerade as 
> a legitimate user and automatically be authenticated as them? (Because 
> you'll look up the cached credentials under that session key and present 
> them without validating there is an uncompromised association between 
> the original user, the TGT, the ccache, and the currently presented 
> session cookie). In which case the scheme is essentially equivalent to 
> using clear text passwords with the exception the credentials will 
> eventually expire.

Again, if the HTTP traffic is in the clear, this scheme wont work.  We
can also keep the session lifetime fairly short (say 15 minutes).

Unless I'm missing something, if our goal is to avoid doing the
modauthkerb negotiation at each request, we will have to use some kind
of cookie-based scheme (or add session information to URLs dynamically,
but that doesn't offer any security advantage over cookies).

Simo, am I on track here?  Details aside, your idea was some kind of
cookie-based session after the user hits /login, correct?

> Otherwise if the session is SSL/TLS encrypted then the primary exposure 
> is reduced to brute force attacks on the session key which is probably a 
> minimal risk given it's a 256 bit key which is valid only during the 
> window the TGT is valid. You will have to be careful that there is no 
> collision or reuse of the session key within a specified time interval 
> (greater than the ticket duration).

Well, with a 256-bit random key (from /dev/urandom) I think we can just
assume there wont be collisions in our lifetimes.  ;)