[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile
torsten at lodderstedt.net
Thu Apr 14 10:01:16 UTC 2016
why is form post important to prevent mix up? Are there variants of this
attack utilizing changed treatment of URI fragments by browsers?
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] (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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab