I think Toresen states it well. The reason we looked at 2 again is that #1 in some of the attacks was being used to leak the code. In some of those cases the attacker had the client credentials and could use the directly to get access tokens.
In other cases the attacker doesn’t have the client credentials, but could still get access to the information protected by the API by presenting the code back to the client as part of a new flow, and bind it to a new account or if the clint is unwise and using the code for authentication, impersonate the user. There are certainly other ways an attacker could get code, via logs, open redirectors etc. The closest mention of this in 6819 is sec 4.4.1.13 , but that considered two clients with two client_id. that was mitigated by having the client send it’s client_id with code to exchange it. The difference with 2 is that only one client_id is used, and that is not mitigated by the current counter measures in 6819. Perhaps referring to 6819 sec 4.4.1.13 is a distraction, in this case. We however were concerned at the time about codes leaking and being replayed but missed some of the ways that could happen. The two opportunities that we are leaving for attackers, 1 not knowing who is sending the authorization response, and not tying the authorization request and response to the same browser instance open a whole world of attacks. What we think currently is that there are two basic flaws that are being exploited (some attacks use one or the other and some use them together) . We should probably keep the fixes separate from documents that are more how to guides to attack un-patched clients. Both issues are around the client being mislead or confused by an authorization response, in that it is coming back from the wrong place or in the wrong browser instance. That is why the two mitigations probably belong in the same document. John B. > On Feb 6, 2016, at 8:32 AM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote > > Hi Hannes, > > #2 is not directly described in the paper but was used to replay the > code/token the attacker obtained via #1. In my observation, the discussion in > Darmstadt has shown that OAuth (and its built-in mitigations) so far focused > on preventing code/token leakage but we lake mitigation for replay in this > particular case. > > #2 does not require the attacker to control the network or the victim's > device. The attacker (using #1 or other attacks, e.g. on referrer headers or > log files) obtains a code and injects this code into a legitimate OAuth/OIDC > flow on its device. All she has to do is starting a authz code flow on the > legitimate client, the particular code was issued for, and replace the code > in the response from the AS. From the client's perspective, the response > looks ok, since it carries the correct state value bound to the client in the > particular user agent (since this is not a XSRF). But since there is no way > (currently) to bind the code to a certain user agent, the client would accept > the code and exchange it for token(s) on the AS. That gives the attacker > access to resources of the victim and/or impersonates the attacker as the > victim. > > There are several way to mitigate this issue: > - OIDC has the "code id_token" response type, which uses nounce and c_hash in > the id_token to bind the code to the user agent session > - in Darmstadt we came up with the idea to utilize the state value for that > purpose. > > Do we need to describe the threat and mitigation if > draft-jones-oauth-mix-up-mitigation? I don't think so. > We could describe the mechanisms in a different draft. > > I personally would prefer (and Phil already states this as well) the WG to > work on a single draft, providing a consolidated view on all threats caused > by the more dynamic usage of OAuth. We could also include all > threats/mitigations/issues we have seen in the wild since RFC 6749 was > published. This would also include stronger advice regarding XSRF prevention > and open redirectors. I don't think we serve the community well be spreading > those issues and mitigation over 3 or 4 drafts. > > best regards, > Torsten. > > Am 04.02.2016 um 21:27 schrieb Hannes Tschofenig: >> Hi all, >> >> when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation' >> solution <draft-jones-oauth-mix-up-mitigation> I wasn't expecting such a >> heavy debate on the list. While the call for adoption is still ongoing I >> would like to share my view as someone who has to judge consensus in a >> few days together with Derek. >> >> Regardless of where we are with respect to oauth-meta vs. >> draft-jones-oauth-mix-up-mitigation we should keep an eye on the threats >> we are trying to address (and we have to document them). >> >> Here is how I would summarize the situation after reviewing the drafts, >> blog posts and various emails sent to the list. >> >> >> We have two types of threats: >> >> #1: Threat described in the papers referenced in my email to the list >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html> >> >> The attack assumes that '... the presence of a network attacker who can >> manipulate the request in which the user sends her identity to the RP as >> well as the corresponding response to this request ...' (see page 15 of >> http://arxiv.org/pdf/1601.01229v2.pdf >> <http://arxiv.org/pdf/1601.01229v2.pdf>). >> >> I believe that this threat is well documented (at least in the paper). >> >> #2: Cut-and-Paste Attacks >> >> Here things get a bit more difficult since the threat is less well >> described. In Section 7.3 of >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >> <https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01> Mike >> makes an attempt to describe the attack and refers to Section 4.4.1.13 >> of RFC 6819, which talks about 'Code Substitution'. I am not convinced >> that the description in RFC 6819 exactly matches the intention of >> Section 7.3 of draft-jones-oauth-mix-up-mitigation-01 but I might be >> misinterpreting. >> >> Anyway, here is a copy-and-paste from the draft: >> >> A "cut-and-paste" attack is performed >> by the attacker creating what appears to be a legitimate >> authorization response, but that substitutes some of the response >> parameter values with values of the attacker's choosing. >> >> Clearly, this attack makes different assumptions than what is stated in >> the papers listed under item #1. It appears that the attacker will have >> to be on the users device /browser itself. If that's true then the text >> needs to state that. >> >> Nat also provides a description of a similar attack in his blog post >> under the name of 'Code Phishing' at >> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ >> >> <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/> >> In his description the attacker assumption is that the developer is >> tricked into re-configuring the token endpoint so that the attacker is >> able to obtain the authorization code. >> >> While I believe the group is well advised to tackle the attack described >> in item #1 to mitigate the attacks discovered late last year. I am >> curious whether the group also sees the mitigation of threat #2 in scope >> of this document. In some sense, one could argue that cut-and-paste is >> more generic and a concern also for those cases where an OAuth client >> does not talk to multiple ASs. >> >> So, here are my questions: >> >> - Can we describe the threat #2 in more details and by stating the >> assumptions about the attacker? >> >> I believe that this is important for understanding the attack within the >> participants of the group but also for those who stumble over our >> documents. Once we have a good description we should move on and answer >> the next two questions: >> >> - Should the document describe mitigations for attacks #1 and #2? >> >> - Should the solution mandate a solution for dealing with both attacks? >> >> Finally, we can talk about the details of the attack mitigation itself. >> >> As far as the work from Mike (oauth-mix-up-mitigation) and Nat >> (oauth-meta) is concerned Derek and I will find ways to ensure that the >> prior work by all involved participants is appropriately attributed and >> acknowledged! >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
