[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile

Dominick Baier dbaier at leastprivilege.com
Wed Apr 13 14:35:36 UTC 2016

Depends if you want to expose the access token to the browser/user machine/outside your server - as opposed to wanting it to use pure server-side.

Dominick Baier

On 12 April 2016 at 20:58:41, Hans Zandbelt (hzandbelt at pingidentity.com) wrote:

from an implementers/deployment standpoint I would argue that if the  
id_token is delivered in the front channel, I may just as well get the  
access token from there too rather than having to deal with the overhead  
of calling the token endpoint, esp. since at_hash is there to protect  

so I'd favor response_mode=form_post, response_type="id_token token"  
over hybrid  

I realize that this doesn't leverage the possibility of using a client  
secret to get the access token but it doesn't really seem to matter  
security-wise at this point as the id_token was delivered without  
leveraging it as well  

anything wrong with that line of reasoning?  


On 4/12/16 9:23 PM, William Denniss wrote:  
> Good point.  
> Regarding the OP tests, the following are relevant to mitigate the  
> cut-and-paste and mix-up attacks:  
> 1. ID Token has nonce when requested for code flow [Basic] (OP-nonce-code)  
> 2. Request with response_mode=form_post [Extra] (OP-Response-form_post)  
> 1) is important for preventing cut-and-paste (the id token needs to  
> contain the 'nonce')  
> 2) is important for preventing mix-up as it means the redirect endpoint  
> gets the id_token on the response at the server, as opposed to in the  
> URI fragment.  
> Unfortunately, form_post is optional for OPs, and sending the nonce on  
> the code flow is optional for RPs (though fortunately to it is  
> compulsory for OPs to support thanks to OP-nonce-code).  
> We could add an hardened OP test for:  
> – Forcing nonce to be present on the code flow  
> We should definitely have RP tests for:  
> – sending and validating nonce on the code flow  
> – validating the c_hash, iss, aud on the hybrid flow  
> How we would profile these tests I'm not sure; would they go in the  
> Basic testing profile, or in a new Hardened one? We could move  
> OP-Response-form_post to the Basic profile if we wanted to be  
> opinionated, or define a new profile.  
> The good news is that supporting the features required to mitigate  
> mix-up & cut-and-paste is not all that hard to do in Connect.  
> On Tue, Apr 12, 2016 at 10:46 AM, Nick Roy <nroy at internet2.edu  
> <mailto:nroy at internet2.edu>> wrote:  
> Would it be possible to check for the secure behavior in Roland's  
> test suite and either not certify non-mitigating implementations, or  
> offer a risk mitigation add-on cert for those that do the right thing?  
> Nick  
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net  
> <mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of  
> William Denniss <wdenniss at google.com <mailto:wdenniss at google.com>>  
> Date: Tuesday, April 12, 2016 at 11:01 AM  
> To: "openid-specs-ab at lists.openid.net  
> <mailto:openid-specs-ab at lists.openid.net>"  
> <openid-specs-ab at lists.openid.net  
> <mailto:openid-specs-ab at lists.openid.net>>  
> Subject: [Openid-specs-ab] Defining a Hardened (Mix-up and  
> Cut-and-Paste Proof) OpenID Connect Profile  
> One item that came out of the discussions on the sidelines of IETF95  
> with folk from this WG (specifically Nat, Mike, John, Brian and  
> myself) was the need for the Connect community to respond to the  
> recently <http://arxiv.org/abs/1508.04324v2/> documented  
> <http://arxiv.org/abs/1601.01229v2/> security threats.  
> Connect is actually in a much stronger place for mitigating these  
> attacks (as noted in the papers themselves) than pure OAuth, with  
> the id_token offering a cryptographic binding of the code to the  
> issuer, audience and session identifier (nonce).  
> However, certain steps need to be followed, for example using  
> 'nonce' with the code flow (which is optional to implement for  
> clients) to protect against cut-and-paste, and using the form-post  
> response type with the hybrid flow to verify that the code was  
> issued by the expected IdP, to ensure the code is exchanged at the  
> correct token endpoint (mitigating mix-up).  
> We discussed last week creating a profile of Connect that recommends  
> those practices to mitigate these classes of attack as a response to  
> the security researchers' findings. I wanted to share that  
> suggestion with the list, and continue the conversation.  
> _______________________________________________  
> Openid-specs-ab mailing list  
> Openid-specs-ab at lists.openid.net  
> http://lists.openid.net/mailman/listinfo/openid-specs-ab  

Hans Zandbelt | Sr. Technical Architect  
hzandbelt at pingidentity.com | Ping Identity  
Openid-specs-ab mailing list  
Openid-specs-ab at lists.openid.net  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160413/ab2efa38/attachment-0001.html>

More information about the Openid-specs-ab mailing list