[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, 4 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