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
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).
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 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/
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
