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

Brian Campbell bcampbell at pingidentity.com
Thu Apr 14 22:12:17 UTC 2016


The Connect level mitigation guidance sounded good over lunch in BA but,
with some time thinking about it, I must say I'm sympathetic to what
Torsten is saying here. Code alone is very popular for both Connect and
OAuth. And looking at the certification results
http://openid.net/certification/ shows that the amount of support for
'Hybrid'  is less than 'Basic'.



On Thu, Apr 14, 2016 at 12:47 PM, Torsten Lodderstedt <
torsten at lodderstedt.net> wrote:

> Hi William,
>
> Am 14.04.2016 um 18:22 schrieb William Denniss:
>
> extensions to OP:
>
>> - issue ID token in the front channel
>>
> - add c_hash to id token
>>
>
> I would rephrase these two extensions as "supporting the hybrid flow",
> c_hash is a REQUIRED claim for the hybrid flow, the conformance test ID for
> this is: OP-IDToken-c_hash
>
>
> That's certainly right. I wanted to list all the necessary changes an OP
> Basic needs to implement in order to support this profile.
>
> ...
>
>
>> Apperently, this solution would not work for plain OAuth. Moreover, I
>> personally think this significantly adds complexity (and cost) to both
>> ends, OP as well as RPs, in comparison to other potential mitigations.
>> Experience shows that complexity is the enemy of correct/reliable
>> implementations, which is esp. dangerous when it comes to security for mass
>> market/internet services.
>>
>
> We have a solution in Connect. We should document that solution.
>
>
> We have a solution for hybrid OPs, not basic OPs. And as I said, it does
> not work for OAuth. So even if a basic OP is extended to become an hybrid
> OP, there is no solution for the OAuth use cases, which run on the same
> endpoint.
>
>
> The Connect solution requires no changes to Connect. The proposal here is
> simply documenting what people should do if they want to mitigate these
> potential attacks.
>
>
> The proposal might not require changes to Connect, but it requires
> significant changes to basic OPs and RPs. That's what I wanted to point
> out. There might be a significant difference between what is documented in
> a spec and deployed reality. Do we have insights, how many _deployed_ OPs
> and RPs in the wild nowadays use hybrid flows (code id_token specifically)?
>
>
> I don't believe the Connect WG should be constrained to solve problems
> without using the features of Connect.
>
> So from my perspective, there are two questions:
>> 1) Can we find a solution for OIDC and OAuth (for code)?
>>
>
> That solution may well be: use Connect.  At least, if you wanted to solve
> it today without any spec changes or extensions, that would be my advice.
>
>
> Hmmm, I don't intend to issue id tokens to OAuth clients and I don't want
> to make of client any bit harder than absolutely necessary. That has been
> the reason for the success of OAuth 2.0 and OpenId Connect.
>
>
>
>> 2) Can we make it a simpler one?
>>
>
> I'm listening.
>
>
> As you said, checking nonce (even on the backchannel) is sufficient to
> detect/prevent cut and paste. An alternative solution would be to link the
> state to the code and provide the state value for validation to the token
> endpoint.
>
> With respect to mix up, there are several potential solutions:
> - clients/RPs use different redirect uris for different ASs/OPs (as
> originally proposed by the researchers, who discovered the attack)
> - provide the client/RP with issuer and client_id as response query
> parameters (
> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00#section-3.1
> )
> - provide the client/RP with the token endpoint the particular code is
> good for (
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
>
> best regards,
> Torsten.
>
>
>
>>
>> best regards,
>> Torsten.
>>
>>
>> Am 13.04.2016 um 06:22 schrieb Mike Jones:
>>
>> It is always mandatory for the server to include the nonce in the ID
>> Token if provided in the request and it is likewise always mandatory for
>> the RP to validate the nonce, if present in the ID Token.  For all
>> response_type values other than “code”, including a nonce in the request is
>> also mandatory.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab [ <openid-specs-ab-bounces at lists.openid.net>
>> mailto:openid-specs-ab-bounces at lists.openid.net
>> <openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of *John Bradley
>> *Sent:* Tuesday, April 12, 2016 5:31 PM
>> *To:* William Denniss <wdenniss at google.com><wdenniss at google.com>
>> <wdenniss at google.com>
>> *Cc:* openid-specs-ab at lists.openid.net
>> *Subject:* Re: [Openid-specs-ab] Defining a Hardened (Mix-up and
>> Cut-and-Paste Proof) OpenID Connect Profile
>>
>>
>>
>> If they send it and don’t detect if it has changed from the request then
>> that is a definite error.
>>
>>
>>
>> If they don’t send it, it should be a warning as there are some cases
>> with a simple preconfigured client that not checking may be OK.
>>
>>
>>
>> I personally argued at the time to always check it, so I am not going to
>> push back very hard on making it mandatory to check other than it is a
>> change to the spec.
>>
>>
>>
>> John B.
>>
>>
>>
>> On Apr 12, 2016, at 5:34 PM, William Denniss <wdenniss at google.com> wrote:
>>
>>
>>
>>
>>
>> On Tue, Apr 12, 2016 at 2:28 PM, John Bradley < <ve7jtb at ve7jtb.com>
>> ve7jtb at ve7jtb.com> wrote:
>>
>> The AS is all-ready required to include nonce in the id_token if it is
>> present in the request.  That is a MUST in the spec.
>>
>> That should be a test all-ready.
>>
>>
>>
>> There is: *ID Token has nonce when requested for code flow [Basic]
>> (OP-nonce-code)*
>>
>>
>>
>> So for this, it's more that we need to add an RP test to ensure that RPs
>> are actually sending and verifying nonce.
>>
>>
>>
>> Basically fragment encoding is not a good idea any more other than for JS
>> in the browser or for native apps using view controllers or system browsers.
>>
>>
>>
>> Servers really should support the form post response mode.
>>
>>
>>
>> A client that wants to be secure can send nonce and use “code id_token”
>> if they want offline or “token id_token” if they don’t want offline.
>>
>>
>>
>> That is secure.
>>
>>
>>
>> There are other mitigations we talked about in OAuth with returning the
>> client_id and iss as parameters rather than returning a id_token.
>>
>>
>>
>> The client really only needs to check those two values in the front
>> channel, but I would not want to change the spec to say that.
>>
>>
>>
>> +1 to all the above
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> John B.
>>
>>
>>
>> On Apr 12, 2016, at 4:58 PM, William Denniss < <wdenniss at google.com>
>> wdenniss at google.com> wrote:
>>
>>
>>
>>
>> On Tue, Apr 12, 2016 at 12:50 PM, Hans Zandbelt <
>> <hzandbelt at pingidentity.com>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
>> hybrid
>>
>> 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?
>>
>>
>>
>> 1) Server won't have offline access with "id_token token". 2) The primary
>> case we are dealing with today is the code flow, and we are really just
>> suggesting clients add security checks onto their existing flows by
>> leveraging id_token.
>>
>>
>>
>> It's true that you could do many of the same checks with "id_token token"
>> to verify that the access token was issued by the correct party and avoid
>> cut-and-paste and mix-up, if you only needed a once-off access token.
>>
>>
>>
>> You raise an interesting point regarding client confidentiality.
>>
>>
>>
>> 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]
>> (OP-nonce-code)
>>  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>
>> nroy at internet2.edu
>> <mailto: <nroy at internet2.edu>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>
>> openid-specs-ab-bounces at lists.openid.net
>>     <mailto: <openid-specs-ab-bounces at lists.openid.net>
>> openid-specs-ab-bounces at lists.openid.net>> on behalf of
>>     William Denniss < <wdenniss at google.com>wdenniss at google.com <mailto:
>> <wdenniss at google.com>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
>>     <mailto: <openid-specs-ab at lists.openid.net>
>> openid-specs-ab at lists.openid.net>"
>>     < <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>>
>>     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/>
>> http://arxiv.org/abs/1508.04324v2/> documented
>>     < <http://arxiv.org/abs/1601.01229v2/>
>> 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>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
>>
>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> <hzandbelt at pingidentity.com>hzandbelt at pingidentity.com | Ping Identity
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> <Openid-specs-ab at lists.openid.net>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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160414/b9118c05/attachment-0001.html>


More information about the Openid-specs-ab mailing list