[OAUTH-WG] OAuth Security Advisory: Authorization Server Mix-Up

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sun, 10 January 2016 18:59 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5EF9D1ACEAC for <oauth@ietfa.amsl.com>; Sun, 10 Jan 2016 10:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tvTGo1Xkm9aO for <oauth@ietfa.amsl.com>; Sun, 10 Jan 2016 10:59:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (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 294141ACEA8 for <oauth@ietf.org>; Sun, 10 Jan 2016 10:59:37 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMkDH-1aGyhE3bdn-008Zt1 for <oauth@ietf.org>; Sun, 10 Jan 2016 19:59:36 +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: <5692AA1A.5000909@gmx.net>
Date: Sun, 10 Jan 2016 19:59:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="DOr4Pqkebcd12QSCcGuXeFrRE6mllEnqL"
X-Provags-ID: V03:K0:umjhvnIQKlSaun6ULGkhmZC3bcR2d/YSrp/r/8td0jNhObKFNc9 437NIznmZIK5MkUUgNpFsocI9bFpXEpsk2LZ+ro76WLkAn60Jfvm3WY+8rsao/EPFxAXUR4 DYUVG75iq/4b4kry513XC4S0eOr7O3feR6zM/0QIN0vUdup8SqRPWgEapX/a84m8aGPL3k6 dRVPcil8SzioeuQJjCwlw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:OxGDaDL65z4=:J4g7AAdj7n4PPXWR/tvBSm zQlBZueTO8aWtgBVGgosG4HDQIad61nakLugQWZ9WybDfnWt7y1rgN4qW/957zv+yavQeDZPS NYnioMPh3frJ12MD3z7VdcTbW9p3yK6p8m0FL8Uyk/K4W5c5ZtrxlwQSeQQrgm5lDOWeiGPuS LhmEFsRkoXCftfxnH4qmeLr0T1YJWuWMe5k7TuwdkAMRF7bV+CBxCj79fWaX34qzhjH2OE1nT 85woPrrisAXRQLlkzgaJ9ztztc1pI0lPCiXmfoIl7ENN6rk2zJ1X6J1/+rnug7/biuaOXJE7p dP9f72Wi3vp7hJv6dTHVaSb9PKSwIhDt96ftEMOnHHAytPx+XI1WOdYnrEood0FPm0aMnFceE Ax7uVTdXkMwkEXn5MsYIsQ3D0Zj2eZ0Sm4ghFLVS4ci8GDkvC3IJg+InmpX+5r0e1+luWaF9V Wphbhr7aePwVidejlEVXOXhPGs2HOaHf55FoMBOnS4lgHfSVNY8+jK83W3NbYcGYtUOk+X5nK SqwWc3dqXSOXGrmMzfRDl6Z7tB1u3S8oXsLApHM4uytaTJt5gXV67kmh6X9iYwtcfo0Vhl4MN OhokUf2VZjHSZ66vu5MMwRSiYKCggIVyWk5NCUR1cUdEVbw5YZrEvBlgnAf+mJ3SkSTeTBagC 56g65ZoFOF57npC8IrnYTeOQWsbRrnAHsQYuNUP636Tn1fZqbp5kiTwA+el5owKiRK9Kr7k6l dHIiI1xZ+zuL9gpxexCx/Cx0xCPXThHvVtbJDXCIjztIebKF3t9JFY33M/k=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>
Subject: [OAUTH-WG] OAuth Security Advisory: Authorization Server Mix-Up
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: Sun, 10 Jan 2016 18:59:40 -0000

In November 2015 the OAuth WG chairs had been informed about new attacks
against OAuth clients using multiple authorization servers. Such a setup
may exist in OAuth as well as in OpenID Connect. To discuss the details
of the (not yet published) attacks a small group met at Deutsche Telekom
in Darmstadt/Germany in December and brainstormed about mitigation

On a high-level the attack can be described as an OAuth / OpenID Connect
client that gets confused about which authorization server (AS) issued
tokens, which leads to a failure in authentication and authorization.
Details about the attack can be found at http://arxiv.org/abs/1601.01229
and http://arxiv.org/pdf/1508.04324.pdf.

As a quick and immediate self-mitigation, which requires manual
configuration, a client that has client ids issued by more than one AS
MUST register a "redirect_uri" value with each AS containing a distinct
AS specific component. Client implementations must verify that the AS
specific component received in the authorization response correlates
with state information stored internally at the client for that request.
If the authorization response does not contain the anticipated
AS-specific component then it MUST be rejected.

A strawman proposal for a protocol-based mitigation technique that
relies on a new issuer parameter within the authorization response will
be submitted to the OAuth working group in the next few days.

We encourage the OAuth WG members to carefully study the attack and the
proposed mitigation mechanism. We believe that the working group should
standardize a solution with high priority and therefore ask for feedback
by January 31st 2016. The solution technique will be developed within
the IETF OAuth working group using our regular working group process.

The chairs would like to thank Guido Schmitz (University of Trier),
Daniel Fett (University of Trier), Christian Mainka (Ruhr-University
Bochum) and Vladislav Mladenov (Ruhr-University  Bochum) for contacting
us and for providing us a possibility to investigate the attack and to
develop mitigation techniques. We would also like to thank Torsten
Lodderstedt (from Deutsche Telekom) for hosting our meeting.

Receiving security review from the research community helps to improve
the quality of our protocols. We anticipate a much closer working
relationship with these research groups to tackle potential security
issues before the publication of our specifications as finished RFCs.

To make it easier to contact our working group for security related
issues we have created a dedicated mailing list
<oauth-security-reports@ietf.org>. For implementation specific bugs we
will attempt to forward the appropriate developers.

Hannes & Derek