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

Brian Campbell <bcampbell@pingidentity.com> Wed, 13 January 2016 13:55 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 AF76D1B2DC2 for <oauth@ietfa.amsl.com>; Wed, 13 Jan 2016 05:55: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 6WOVGzjpceLy for <oauth@ietfa.amsl.com>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 925401AD0C7 for <oauth@ietf.org>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id g73so223615718ioe.3 for <oauth@ietf.org>; Wed, 13 Jan 2016 05:55:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; 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; d=1e100.net; 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 10.107.16.226 with SMTP id 95mr100205199ioq.147.1452693334988; Wed, 13 Jan 2016 05:55:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Wed, 13 Jan 2016 05:55:05 -0800 (PST)
In-Reply-To: <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CA+k3eCSpWFwyvk=XHP4b_zxzu-zrMYsS-axF6csO90-ahmkueQ@mail.gmail.com> <BY2PR03MB4423033D5604E9E36B20C23F5CA0@BY2PR03MB442.namprd03.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 13 Jan 2016 06:55:05 -0700
Message-ID: <CA+k3eCR3rZB8xYKZgLNdfRLxtbU_10=ED-Gcghbyt8PoZ-FQHA@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a113ecda03328ad05293786a3
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/pVKnluM-XzMwER9VvsPhOmhAK14>
Cc: oauth <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 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 <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 <bcampbell@pingidentity.com>;
> Sent: ‎1/‎12/‎2016 5:24 PM
> To: oauth <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.
>
>
>
>