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

Brian Campbell <> Wed, 13 January 2016 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF76D1B2DC2 for <>; Wed, 13 Jan 2016 05:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WOVGzjpceLy for <>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 925401AD0C7 for <>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
Received: by with SMTP id g73so223615718ioe.3 for <>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zlpsxCZE4UKgmV/qxNOazhE5WJAVQkQbepWENwhWYuk=; b=CL+PTiQpKFZnMoD/EuwzujoAJaEQcvdbjR/3vHgSkmqR9h0MZrd5KXTfFdDjEOyWtt MQLdJKYg9xRge625D30oFOfkEIskWNPGw5GkR8jyItV6Q6zHUEAn/4zNY2Yj+in/yXEK GS2D9bRsz4F6akYOMJx9EwJsxiBq/llHOzHZg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zlpsxCZE4UKgmV/qxNOazhE5WJAVQkQbepWENwhWYuk=; b=LSZz5t71y2JsFZqXzNlGI61iSOJGH1LZ+Mn2/6XQyPcORpyBw4NbInxVKF4PcfY7G7 57FP5BG/PtD4OtKFFkstBe+z/lj9PrMLimFbZeqkHAjK5jyNumimjoF52SPMg+zu/Qgn l9ngluNeNqS6KIVAJIMq9bKtj/3WPlQy8yVHUS+euAYq5Sq4+O3N8i9FUFUxGVFtLDWS Wj2HNLKpoqlOOV8Xfv8ar5mry2a/5IM1nGWj8A+vBaoJiBWYf1bNkIxK/M6px82ZAB+g b9GKSYVSGBBj19OrDt6W7sibkJkbVeXRq25I0KfZhnCpFDzuA93I6T4ZY8JiiLW+29Ss rp7A==
X-Gm-Message-State: ALoCoQn76uMQ/wRK6fDqu/Khh6JX4UTtU1a5KrL67O2bP4Eb05/S1HVYud+uwb47vQLVtDolHc/OwZXRLOukd+HEvOMqn2m3YmvrlPWigosRfrJoqAwz14M=
X-Received: by with SMTP id 95mr100205199ioq.147.1452693334988; Wed, 13 Jan 2016 05:55:34 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 13 Jan 2016 05:55:05 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Wed, 13 Jan 2016 06:55:05 -0700
Message-ID: <>
To: Mike Jones <>
Content-Type: multipart/alternative; boundary="001a113ecda03328ad05293786a3"
Archived-At: <>
Cc: oauth <>
Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2016 13:55:37 -0000

Thanks Mike (and reluctantly John, I guess). I'm pleased to hear about the
direction things are taking and look forward to reviewing -01.

On Tue, Jan 12, 2016 at 3:53 PM, Mike Jones <>

> 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 <>
> Sent: ‎1/‎12/‎2016 5:24 PM
> To: oauth <>
> 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
> <>)
> 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
> <>
> 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.