[Openid-specs-ab] Defining a Hardened (Mix-up and Cut-and-Paste Proof) OpenID Connect Profile
ve7jtb at ve7jtb.com
Wed Apr 13 12:12:20 UTC 2016
For a native app we still want to use PKCE so retuning AT directly would be
a bad idea unless you are certain the app is using a view controller and a
claimed URI (that is a separate discussion on how to do that safely)
For a server based app it would be fine.
I need to think about how token binding or Pop would work in that case, but
for bearrer it is OK with exact redirect URI matching.
On Apr 12, 2016 3:58 PM, "Hans Zandbelt" <hzandbelt at pingidentity.com> wrote:
> from an implementers/deployment standpoint I would argue that if the
> id_token is delivered in the front channel, I may just as well get the
> access token from there too rather than having to deal with the overhead of
> calling the token endpoint, esp. since at_hash is there to protect integrity
> so I'd favor response_mode=form_post, response_type="id_token token" over
> I realize that this doesn't leverage the possibility of using a client
> secret to get the access token but it doesn't really seem to matter
> security-wise at this point as the id_token was delivered without
> leveraging it as well
> anything wrong with that line of reasoning?
> On 4/12/16 9:23 PM, William Denniss wrote:
>> 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 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 <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
> Hans Zandbelt | Sr. Technical Architect
> hzandbelt at pingidentity.com | Ping Identity
> 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