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

Thu Apr 14 18:29:52 UTC 2016

On 4/14/16 6:05 PM, William Denniss wrote:
>
>
> On Thu, Apr 14, 2016 at 3:01 AM, Torsten Lodderstedt
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>     Hi William,
>
>     why is form post important to prevent mix up? Are there variants of
>     this attack utilizing changed treatment of URI fragments by browsers?
>
>
> If you have a server side flow, and want to prevent mix up you need to
> validate c_hash so the token is bound to the code, and you can trust the
> other attributes like issuer, to verify the correct token endpoint to
> send the code to.
>
> It isn't practical to ask developers to host javascript on the token
> endpoint that simply turns the id_token around and re-posts it to the
> server, hence to /realistically/ solve this we need to support

that piece of Javascript can be static as I showed earlier:
https://hanszandbelt.wordpress.com/2014/08/21/openid-connect-and-post-bindings/

which shouldn't be much trouble; but I agree that it has a 
less-than-elegant feel to it

Hans.

> form-post.  If the solution is too wacky, nobody will adopt it so in my
> opinion, it's a non-starter without form_post.
>
> Fortunately it's a very easy response mode to add, my team is already
> looking at it.
>
>     best regards,
>     Torsten.
>
>
>     Am 12.04.2016 um 21:23 schrieb William Denniss:
>>     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
>>         <<mailto:wdenniss at google.com>wdenniss at google.com
>>         <mailto:wdenniss at google.com>>
>>         Date: Tuesday, April 12, 2016 at 11:01 AM
>>         To:
>>         "<mailto:openid-specs-ab at lists.openid.net>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
>>     <mailto:Openid-specs-ab at lists.openid.net>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> 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