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

Brian Campbell <bcampbell@pingidentity.com> Tue, 12 January 2016 22:24 UTC

Return-Path: <bcampbell@pingidentity.com>
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 226941A8AC9 for <oauth@ietfa.amsl.com>; Tue, 12 Jan 2016 14:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 XTg41psYrJkS for <oauth@ietfa.amsl.com>; Tue, 12 Jan 2016 14:24:35 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E49B1A066C for <oauth@ietf.org>; Tue, 12 Jan 2016 14:24:35 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id z14so154826073igp.0 for <oauth@ietf.org>; Tue, 12 Jan 2016 14:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=GNxUiaIcZ/k9YnLJ9VF0L9T+8hytsYVw9P4gW9nywUY=; b=kxhvJIbkfsXC1CdKtKNwyXfBSzCyGY5K+46fRe0F4DWKzbVa0OYY/YUJlKpQlrg2uZ qIG8H/JFJsuZ+fNFetLTwCGzcYPsifBgHsBjFmtJSkStqTTPQvTUW4WWN6YWLX/8+nDu LjslIHd1sp1J8Gzb9x4bgvztynpBXflUOxOyI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GNxUiaIcZ/k9YnLJ9VF0L9T+8hytsYVw9P4gW9nywUY=; b=Qa7H4zcIiPQKj+OFYkkw1UQTibFA19fobO2i4kF0uIC1Dvdp3M03CoSQHP7CCFLWxA AIMSp3acE3dEDEwSUush2i6480DVVYojfXi7Xu6AsB5VuUV+YLccb8hpiYQL1oUwfd5H +9q8Sc1HIAwd20OGaCDEhq2Kcv6rXgyAjuRksm33QY99rUNpEA3JeSPLoPh+NtztN5WM AvQ1ifLxVSAZMDgqCjCJq4SlGcfb26dmA0j365JhyQxB2kE1quFVQbkN5+ya+GBhkJhl EfLkZcRqbjGDf3QKRUwONgc4+3siTj4guDftoGrsBkiU3sGK2FkEbbfF4jcYxd9PzpJe RTDw==
X-Gm-Message-State: ALoCoQml+QRQtp+rnBr12l3+31Fuhd1pHlK6+B339otPHe7w8Nu2wx7MXk35MdtBBF1PgKzA0hyEl1+dPM4D6gDB9g9W06NFsuVLNuD0pUjJtqRhg6sXmWo=
X-Received: by 10.50.142.73 with SMTP id ru9mr20561773igb.49.1452637474361; Tue, 12 Jan 2016 14:24:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Tue, 12 Jan 2016 14:24:04 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 12 Jan 2016 15:24:04 -0700
Message-ID: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3db70a5b69905292a8441
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/-0tbkGyaKKyhpX_vEPjtFKDjltQ>
Subject: [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: Tue, 12 Jan 2016 22:24:37 -0000

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.