Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

Justin Richer <jricher@mit.edu> Wed, 13 January 2016 04:03 UTC

Return-Path: <jricher@mit.edu>
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 B6DB71B2CF3 for <oauth@ietfa.amsl.com>; Tue, 12 Jan 2016 20:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ozX-D4W9PsnJ for <oauth@ietfa.amsl.com>; Tue, 12 Jan 2016 20:03:15 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500131B2CF1 for <oauth@ietf.org>; Tue, 12 Jan 2016 20:03:13 -0800 (PST)
X-AuditID: 12074424-f79216d00000156e-0e-5695cc7f3e82
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DA.8B.05486.F7CC5965; Tue, 12 Jan 2016 23:03:11 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0D43A6e011583; Tue, 12 Jan 2016 23:03:11 -0500
Received: from [107.16.90.107] ([107.16.90.107]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0D438Ae000482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jan 2016 23:03:09 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_2CC89D0D-8685-489C-89B0-1B1B31F83382"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Tue, 12 Jan 2016 23:03:08 -0500
Message-Id: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu>
References: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com> <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrlt/ZmqYwYmNShar/99ktNg77ROL xcm3r9gcmD2WLPnJ5NG64y+7x92jF1kCmKO4bFJSczLLUov07RK4MtaueMlY8D+u4t3U1awN jJMCuhg5OSQETCQ2Xv7BCmGLSVy4t56ti5GLQ0hgMZPEicXn2CGcjYwSbVP7WCCctUwSXevO MYO0MAskSKx+vZsFxOYV0JN4desy2ChhASuJl3M+gtlsAqoS09e0MIHYnALREr/3PGIDsVmA 4o/OvWWCmBMr8an1DRPEHCuJBbtXg80UEpjPKDHtFC+ILSKgI/H44jc2iFNlJXb/fsQ0gVFg FpIzZiE5AyKuLbFs4WtmCFtTYn/3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczMKU5N1i1OTszL Sy3SNdfLzSzRS00p3cQIjgMXlR2MzYeUDjEKcDAq8fB2zJoaJsSaWFZcmXuIUZKDSUmU9886 oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3sJTQDnelMTKqtSifJiUNAeLkjjvt8opYUIC6Ykl qdmpqQWpRTBZGQ4OJQle7tNAjYJFqempFWmZOSUIaSYOTpDhPEDDH4HU8BYXJOYWZ6ZD5E8x KkqJ88qDJARAEhmleXC9oDSVLRCV/YpRHOgVYV57kCoeYIqD634FNJgJaLBF3GSQwSWJCCmp Bkamuc9Tg9q4C9W3s+ltPv3ypdy70tOR31zWPxY6fqh5A1+0qo/rVTblgj/pvI/YLiZqfRN4 evyuh/mU/e2TPjjkVc/9zH6zmXGi85HUYL8zhbn125/LJrybZKl0VPznZxOxU+b7nj+a8n/2 M+uJtrvmd016lHdiVnLi0QU569veb5JZzHehqiRYiaU4I9FQi7moOBEAsdOx4C4DAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/XWqq0YVk5vWt4jzN-Bk7HbYvhBU>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
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: Wed, 13 Jan 2016 04:03:18 -0000

+1 to Brian’s point, and points to Mike for promising to address this. I wasn’t able to attend the meeting in Darmstadt, but I’ve been following the discussion and original papers. Let’s take this one piece at a time and not overreach with a solution.

In particular, the whole “late binding discovery” bit would cause huge problems on its own. There’s good reason that OpenID Connect mandates that the “iss” value returned from the discovery endpoint MUST be the same as the “iss” value coming back from the ID Token, so let’s not ignore that.

 — Justin

> On Jan 12, 2016, at 5:53 PM, Mike Jones <Michael.Jones@microsoft.com>; wrote:
> 
> John Bradley and I went over this today and I'm already planning on simplifying the draft along the lines described. I would have written this earlier but I've been busy at a NIST meeting today. 
> 
> John has also stated writing a note about how cut-and-paste does and doesn't apply here but hasn't finished it yet because he's been similarly occupied.  He's also started writing up the state_hash token request parameter, as he agreed to do.
> 
> Watch this space for the new draft...
> 
> Best wishes,
> -- Mike
> From: Brian Campbell <mailto:bcampbell@pingidentity.com>
> Sent: ‎1/‎12/‎2016 5:24 PM
> To: oauth <mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
> 
> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on them) take advantage of the fact that there's nothing in the OAuth authorization response to the client's redirect_uri that identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the code (or token in some cases) to the wrong endpoint.
> 
> To the best of my recollection the general consensus coming out of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>) was to put forth an I-D as a simple extension to OAuth, which described how to return an issuer identifier for the authorization server and client identifier as authorization response parameters from the authorization endpoint. Doing so enables the client to know which AS the response came from and thus avoid sending the code to a different AS. Also, it doesn't introduce application/message level cryptography requirements on client implementations. 
> 
> The mitigation draft that was posted yesterday <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00> diverges considerably from that with a significantly expanded scope that introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the authorization request and the access token request. 
> 
> It is possible that my recollection from Darmstadt is wrong. But I expect others who were there could corroborate my account of what transpired. Of course, the agreements out of the Darmstadt meeting were never intended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goal of meeting face-to-face was to come away with a good consensus towards a proposed solution that could (hopefully) be implementable in the very near term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content of -00 draft does not reflect it. 
> 
> I've made the plea off-list several times to simplify the draft to reflect the simple solution and now I'm doing the same on-list. Simplify the response validation to just say not to send the code/token back to an AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that . 
> 
> If this WG and/or the larger community believes that OAuth needs signed responses, let's develop a proper singed response mechanism. I don't know if it's needed or not but I do know that it's a decent chunk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and implement fix for the idp mix-up problem.
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth