[OpenID] Some thoughts on Open ID Connect Session

Sun Apr 3 20:05:13 UTC 2016

Thing to do, for your level of interest, is join at a level sufficient to access lists where folks debate actively.

I see things too simplistically. 

Once saml2 became a religious group (Far too tied up with us govt interests) openid found a way to transform itself from a sideline into a mainstream effort. And to that I have to give credit (since it guessed correctly the end of pure web). 

While the vendor community still has far too many links with us and uk spying-related manipulations, I also see that it has found a way to negotiate on difficult issues - such as session management and metadata that facilitates opened at a level saml2 never contemplated (while giving away all notions of privacy, unlike saml2 sessions)

Crypto politics as normal. Join in!

Sent from my iPhone

> On Apr 3, 2016, at 07:18, boris8479 at gmail.com wrote:
> 
> Peter,
>  
> Thanks for the replay. I need to understand what is the vision for OpenID Connect session. The spec is currently in Draft 26. I do completely understand the idea of the RP and OP frames. If it is going like it is today, I believe it needs some additional clarifications and security concerns in the spec. Are there any big changes coming? I also see the community is working on the Identity Events, maybe it is to replace the session one. Any thoughts on that are highly appreciated.
>  
> Regards,
> Boris Georgiev
>  
> Sent from Mail for Windows 10
>  
> From: Peter Williams
> Sent: Thursday, March 31, 2016 9:10 PM
> To: boris8479 at gmail.com
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] Some thoughts on Open ID Connect Session
>  
> The original model was that a token transferred a session.
>  
> Before opened connect added authentication tokens, it did not adhere to the original model.
>  
> Thus an rp-local session would take a hint, from the authz token.
>  
> Now the original model had a variant in which independent sessions, on Idp(s) and rp(s) could be mapped , by token minting intermediaries (see wsfedp protocol from vrsn/iBm/Msft and excellent use in Msft azure cloud). 
>  
> But that's not opened connect today. Opened connect may be that tomorrow being somewhat of a follower (of models) as they finally find relevance in app, web, Pc-app world 
> 
> Sent from my iPhone
> 
> On Mar 31, 2016, at 16:31, boris8479 at gmail.com wrote:
> 
> Hi Community,
>  
> My name is Boris Georgiev and I am in charge for Application Security in a large financial institution. I do appreciate bringing up the standard Open ID Connect. I am excited after so many years, finally there is a standard. However, when facing up with Open ID Connect Session spec, I started to experience some disappointments.
>  
> Section 3 says: “In Open ID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token”. In my mind, as I am trying to protect everything, I am about to receive the session together with the ID token, i.e. via the token API. However, reading further, the spec states that the variable session_state is returned in “the authentication response” which was changed few specifications back from “the authorization response”. The reference to 3.1.1.5 core shows example with the authorization code, and there is no example, showing the code and the session_state together. I was thinking initially that it is my confusion only, however I showed it to other engineers, native English speakers and they were confused too. I do believe this needs to be explained better, which session is which. So far I did not like the fact, that the session state is returned in a redirect via GET request, which we all know its vulnerabilities.
>  
> Further, section 4 explains that this is all about session state change notification, so the RP can refresh the ID token, avoiding the network traffic. So far so good. Finally, section 4.2 explains that the session actually is hashed and re-calculated at the OP frame. I think finally, the session is safe. However, to my disbelief, the spec explains that OP frame “may” use a cookie which is not http only, so it can be accessed by a JavaScript. Here I start wondering how people with security regulations similar to mine pass audit.
>  
> If the session is passed to the OP frame in some other secure way and if it is not used for any other purpose but for the session change notification, this will solve the problem. However the spec does not list it anywhere as a security concern, neither recommends secure ways. Moreover, I saw open source implementations out there, where the same cookie is driving the Single-Sign-On at the Authorization Server. This means, once the value of this cookie is obtained, it can be used to invoke the authorization API, bypass authentication and if implicit grant is requested, the attacker can get access tokens. The last safeguard is the callback URL, which can be easily bypassed by overwriting the local hosts file. Sounds like a complex and almost impossible, however in the financial industry the security is attempted to be penetrated by the brightest minds across the globe where patience and persistence can be well awarded. I need just one case like that to end my career. Therefore I do need to think about closing all the gaps and I still cannot find piece, thinking what else can be out there.
>  
> I do believe the above security concerns need to be listed in the spec. And I do believe this non http cookie idea needs to be listed in the security concerns, instead of being recommended.
>  
> If you need my opinion how it can be improved:
>  
> There is already a mechanism to protect token exchange. This is via the authorization code and token API. I thing, passing it from there will eliminate the need of encryption. Then, the session_state can be embedded in the script of the RP frame and comparison/calculation logic to be embedded in the OP frame (not via a cookie). Encryption is great, but one of the goals of OAuth is for authentication/authorization not to be done too often. The solution is acceptable for desktops, powered by the power grid, but for a thin device, one cannot do often encryption operations and expect a great battery life. I do not know if anyone ever considered that and was there any reason not to be pursued.
>  
> Regards,
> Boris Georgiev
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>  
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20160403/be0f3c72/attachment.html>
-------------- next part --------------
_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general