[OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 04 February 2016 20:27 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EBA1AD0C9 for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 12:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUvPAlBsEWDp for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 12:27:24 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEDF1AD0C7 for <oauth@ietf.org>; Thu, 4 Feb 2016 12:27:23 -0800 (PST)
Received: from [192.168.10.140] ([80.92.118.18]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVsUW-1aY3HM1XjM-00X7J4 for <oauth@ietf.org>; Thu, 04 Feb 2016 21:27:20 +0100
To: "oauth@ietf.org" <oauth@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56B3B425.1020701@gmx.net>
Date: Thu, 04 Feb 2016 21:27:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="DnJaTkiwBh7brbEIFe6XH3v9ELtocgbAp"
X-Provags-ID: V03:K0:kgsQ2Yjr9npJqgxtt2DjLE7NmHNx3i10TvEf1I1pQUn6de7qvrv u/29GZo7Ny+XU4ZJVQ2Y1F7WBz65lN83XyahsXKH3NVtBuAA3jUpvssXkMznrKSA+X4G6Nq PxPVOmNoqWYegfXToOwbnZN7mr7aQqhLBFGUw5jV2EZGPzZBQKzMsEHqfF2wJuTimJ85puq TdCK3vZSK4YGjsjCRdOYg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:O+znfMTkHc4=:yNwl5Lo2frILw0+/ZuZ0/L d9/ks8ktR+ir8E1lEGA9FpPaQTc+hyu8K1d3ilnZPfRrsR2rgKKI33fVKCe4vF06pWy3Y4NFL jJcYdNfNvY8plAQuywTTnU4KZqirBz0gM8LcoPsswgyWWwWScg9MNGMVB2uV7hdTL/JyebzPD QFoQ1MVSF+2OdqH9flaGHF8/XeyByq7FBciXvgm1zTWc/7N5eZ7BQ680xrguoMpzgj4vvM5XQ FF9nKjU2LBxhPQJRoVu9tMkiDkCKYDU2swit+IoxGYKcCOxyAnBUzFmnrOvgHqKVbsMKR4Lam R2J4R/9HFVUDNTErsnGteRZqb2MX+SnlAFVSkNC3ucUaisjc2ujqMKdxOlunDQZoQ3DI5MLDw I3Xy8zhQ56kU2ZpXREdSSqKQBWGuymONESyevVTgwU/5lUIfnBCqQn79TJstLeIf+MQIDqSOY 2biu8FDLBqrvo9AeF/VAP3gLs20HiDdc/CTlj7mqOdv38N5VMNxPOvj/w1vogZOao48LLBq48 YJu+FwshF4a8L9MUVHqbCSQu3yK49bUWa68HDWw7MtkeYcEbMlZZksncmtBZaT7wL1Q2GON3r gsCUBa+GANfIWi7vB9B49z/gG9zz4fJmZ39OEC+jrbK6PjZi9VuQTe3slqE76zUOK7UTUglUz n6lsxypZU8UsOspcdjkRzuUwlyDNUvxL12ficHTgktANkT4MccipE/MBf0t3TqGBnJXzypHR0 /jh6x+AmuSJ5l5mRcwwnNadHo9bzdhhVDIzfLAoo72HKPOZldNlsbUrjTf0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/tBduXPJTiMs4HHaecA8eMHMqJnU>
Subject: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 20:27:26 -0000
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
- Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Im… John Bradley
- Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Im… Torsten Lodderstedt
- [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impres… Hannes Tschofenig
- Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Im… Nat Sakimura