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

William Denniss wdenniss at google.com
Tue Apr 12 19:23:55 UTC 2016

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

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> 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> on
> behalf of William Denniss <wdenniss at google.com>
> Date: Tuesday, April 12, 2016 at 11:01 AM
> To: "openid-specs-ab at lists.openid.net" <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160412/db65a138/attachment-0001.html>

More information about the Openid-specs-ab mailing list