[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile
hzandbelt at pingidentity.com
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.
> endpoint that simply turns the id_token around and re-posts it to the
> server, hence to /realistically/ solve this we need to support
which shouldn't be much trouble; but I agree that it has a
less-than-elegant feel to it
> 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,
> 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]
>> 2. Request with response_mode=form_post [Extra]
>> 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?
>> 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
>> "<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
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Hans Zandbelt | Sr. Technical Architect
hzandbelt at pingidentity.com | Ping Identity
More information about the Openid-specs-ab