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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
