Assurance

[Russell J Yount <>]

 

Shouldn’t the scenarios of  an attacker creating a cookie and its contents, places it in the browser cache, then visits the IDP which recognizes the cookie as a valid session be addressed also?

 

SSL only addresses the security of the communications between browser and IdP.  There are other techniques  employed to prevent the use of a non-IdP created cookie that could fool the IdP into believing the browser has an authenticated session.

 

-Russ

 

 

 

From: [mailto:] On Behalf Of Roy, Nicholas S
Sent: Wednesday, August 08, 2012 12:04 PM
To:
Cc: Russell J Yount
Subject: RE: [Assurance] Addressing InCommon IAP & Shibboleth IdP

 

That has been my opinion, too.  I think a really short and sweet management assertion to that effect should suffice.  Of course, I am not an auditor.

 

Nick

 

From: On Behalf Of Michael R. Gettes
Sent: Wednesday, August 08, 2012 10:13 AM
To: <>
Cc: Russell J Yount
Subject: Re: [Assurance] Addressing InCommon IAP & Shibboleth IdP

 

In my humble opinion, my read of this language seems to indicate as long as the session involving cookie exchange is protected with SSL then we are ok.  Is this a valid viewpoint?

 

/mrg

 

On Aug 8, 2012, at 8:01, Russell J Yount wrote:

 

In the section “4.2.5.5 SESSION AUTHENTICATION” it states.

If the IdP uses session-maintenance methods (such as cookies) so that after an initial

authentication act new Assertions can be issued without the Subject having to

re-authenticate, such methods shall use  industry standard cryptographic techniques to

ensure that sessions are at least as resistant to attack as initial authentication.

 

 

I could not find references on wiki.shibboleth.net as to how Shibboleth IdP handles sessions with enough details to point an auditor too.

 

Chad had responded to a question about IdP cookie protection on  at at 2012-02-23 14:22:27 with:

The cookie isn't considered part of the public API so there isn't any documentation of it outside the code itself. That said, the protections in place are:
- normal cookie domain/path settings
- user-agent address checking
- cookie content signatures using a server-side, per-session secret key
- randomly generated sessions IDs

As far as I know, that's about all you can do for cookies.

 

How have others addressed this area? Would it make sense for the InCommon Assurance group to put some text together for a stock Shibboleth installation and perhaps for common add-ons such as the Ohio State Custom Login Handler which provides technical details that one could point an auditor to?

 

-Russ

 

Carnegie Mellon University