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

John Bradley ve7jtb at ve7jtb.com
Fri Apr 15 04:12:25 UTC 2016


Given that Basic is MTI, it is not surprising that hybrid has lower support in testing.

Some IdP like MS actually started only supporting hybrid and added code to pass the tests.

For IdP only supporting code now hybrid is more work.

For clients hybrid is more work as they need to check c_hash and validate the signature on the id_token that many clients skip doing on the id_token in the direct connection.

I thing for clients and servers that support hybrid, recommending using that now if they are connecting to multiple AS is probably the responsible thing to do.

For clients and servers not currently supporting hybrid we need to decide if we want to send them in that direction or have another extension to secure code.

Token binding the id_token is a great way to stop cut and paste, and stop leakage of AT.  A token binding version of PKCE would stop a number of the mixup attacks.   That is worth developing but is not a overnight solution.   

Other things that will mitigate these attacks for OAuth add more moving parts so have plusses and minuses.   As the Connect WG it is probably best to be mindful of our scope and not prejudice the work the OAuth WG is going to do.   

John B.

> On Apr 14, 2016, at 11:50 PM, William Denniss <wdenniss at google.com> wrote:
> 
> Connect can mitigate these attacks today (via the Hybrid flow) with no spec changes at all.  Those who have deployed Connect with Hybrid can start hardening their deployments today. This suggestion is simply to profile that.  It doesn't preclude other approaches.  I'm not sure why it has to be mutually exclusive.
> 
> "code id_token" with form_post is actually not that much different to "code" for Connect RPs – in both cases you get the ID token on the code exchange and potentially refresh, it just adds an extra id_token to the authorization grant.
> 
> On Thu, Apr 14, 2016 at 3:12 PM, Brian Campbell <bcampbell at pingidentity.com <mailto:bcampbell at pingidentity.com>> wrote:
> 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/ <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 <mailto: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 <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 <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 [ <mailto:openid-specs-ab-bounces at lists.openid.net>mailto:openid-specs-ab-bounces at lists.openid.net <mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of John Bradley
>>> Sent: Tuesday, April 12, 2016 5:31 PM
>>> To: William Denniss  <mailto:wdenniss at google.com><wdenniss at google.com> <mailto:wdenniss at google.com>
>>> Cc: openid-specs-ab at lists.openid.net <mailto: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 <mailto:wdenniss at google.com>> wrote:
>>> 
>>>  
>>> 
>>> 
>>> On Tue, Apr 12, 2016 at 2:28 PM, John Bradley < <mailto:ve7jtb at ve7jtb.com>ve7jtb at ve7jtb.com <mailto: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 < <mailto:wdenniss at google.com>wdenniss at google.com <mailto:wdenniss at google.com>> wrote:
>>> 
>>>  
>>> 
>>> On Tue, Apr 12, 2016 at 12:50 PM, Hans Zandbelt < <mailto:hzandbelt at pingidentity.com>hzandbelt at pingidentity.com <mailto: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 < <mailto:nroy at internet2.edu>nroy at internet2.edu <mailto:nroy at internet2.edu>
>>> <mailto: <mailto:nroy at internet2.edu>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?
>>> 
>>>     Nick
>>> 
>>>     From: Openid-specs-ab < <mailto: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>
>>>     <mailto: <mailto: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>>> on behalf of
>>>     William Denniss < <mailto:wdenniss at google.com>wdenniss at google.com <mailto:wdenniss at google.com> <mailto: <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>
>>>     <mailto: <mailto:openid-specs-ab at lists.openid.net>openid-specs-ab at lists.openid.net <mailto: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>
>>>     <mailto: <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/>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/ <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
>>>  <mailto:Openid-specs-ab at lists.openid.net>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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> 
>>> -- 
>>> Hans Zandbelt              | Sr. Technical Architect
>>>  <mailto:hzandbelt at pingidentity.com>hzandbelt at pingidentity.com <mailto:hzandbelt at pingidentity.com> | Ping Identity
>>> 
>>>  
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>>  <mailto:Openid-specs-ab at lists.openid.net>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 <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>>  
>>> 
>>> 
>>> _______________________________________________
>>> 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 <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
> 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/20160415/b2219fc6/attachment-0001.html>


More information about the Openid-specs-ab mailing list