[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile
ve7jtb at ve7jtb.com
Thu Apr 14 11:02:37 UTC 2016
It is not directly important. It make it easier for clients that want to use “code id_token” to do that easily and securely as they don’t need to have JS on the return page. The default fragment encoding is now not as secure as POST due to browser changes.
So fragment encoding is a separate issue, but related due to one of the best mitigations for mix-up being the “code id_token” response type.
> On Apr 14, 2016, at 6:01 AM, Torsten Lodderstedt <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?
> 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:
>> ID Token has nonce when requested for code flow [Basic] (OP-nonce-code)
>> 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?
>> 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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> 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