Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Nat Sakimura <sakimura@gmail.com> Fri, 29 January 2016 04:54 UTC

Return-Path: <sakimura@gmail.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 28F1F1B3DB4 for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 20:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 m6pgmWH3NRrC for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 20:54:48 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 D1F661B3DB3 for <oauth@ietf.org>; Thu, 28 Jan 2016 20:54:47 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id s5so20307010qkd.0 for <oauth@ietf.org>; Thu, 28 Jan 2016 20:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=C3GZyA/TrrRgcjmmJclK45ZHlToyhIpOzfzea2iOPfU=; b=CE5iCMjJOdHxA7NDEuB/VFzTOM6U2VHG3ZimAMOPJfffzvut8+ofdq8Wn7u3Ead9lr gVGXAkcv7oGKjMuXg3xGB1RUxLRTjryFrB1w18P9ROUjb+zk4l28cYnu1IYrFc/zEYyV wAT8EjZZiAnZQW+gFnruh2oIGLjpnQ1q/h1U1I6/qLrRO9ENKqHLFHkFcV/R5fFtvcPi bLWcrzXXCaBAxy2sn2FDA8MG900PTczMKRzO42sqHDiXHhjxd7kVr+j10Cy8bkuAOtgK pGdkXJdB0W9DznNRv3LtAU8j5LwXYRGLwcqlqcjf7Cej+55wuwQHYqx3jmkfskfO6cXZ m1sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=C3GZyA/TrrRgcjmmJclK45ZHlToyhIpOzfzea2iOPfU=; b=P/gDXtz3pa5VGKJj/3hTkh408B9yTuw7dP6vrLxo5vOqBk88amBTNpB0cOcBfWbD8I aWvAI5BJENoXpPxfE1iK0kiN8AsXibsWuDdDMWaxTPN/5VnfmU/s0JTRKcvkttyy4Zxi Sba8+Nw07BzWjQkOvBbmNlzr3Ddppa/4KbXlZWFbQyz+Xw6nbK2Gudi0lxCKQ84RJ5mR v1rkZTZXwyZHYX0F0pYcTXpeArktJt1B53Wa+sR7EYwVprewv7CzGd2zdYwQmWeLdxRp BPzyeYaone6ERrtOUV4MF4oJis6k2ZcLQsp1Rm96Va55JH8ogZueFfksfIg0HeBIS/20 lnaA==
X-Gm-Message-State: AG10YOQgGEsQQypGj/HLqZCHZfSCxWQYiTqlB94CYCbNn4RsWZDJP+OmPAKJqAtF97+75FT36b414xOUB+aqOg==
X-Received: by 10.55.78.207 with SMTP id c198mr8221259qkb.34.1454043286895; Thu, 28 Jan 2016 20:54:46 -0800 (PST)
MIME-Version: 1.0
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com> <DDFE7F75-46BB-4868-8548-CF449452EB69@gmail.com> <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com> <CABzCy2A6UwB5PmwdAkvaWtz1UVE9r8E1qmOJYHWtG7O2S3FEPg@mail.gmail.com> <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com> <CABzCy2BFP2pOoFML4DujF3Q9F0=1nqw_6uVaVrsjZFTs7hE1ow@mail.gmail.com> <F89550EB-EBED-4AB3-BF6F-B15D6B4DD7A3@mit.edu> <56A92F08.9050706@pingidentity.com> <CABzCy2BniK8586Ka_pb3Wz26MUkdRBZK1CsJe=W7TX179+Wh5A@mail.gmail.com> <56A962FA.2010004@pingidentity.com> <CABzCy2CKfZAMg2arjx1uvA73tB4kFaoL2ri4CBNimE99naKarA@mail.gmail.com> <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
In-Reply-To: <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 29 Jan 2016 04:54:36 +0000
Message-ID: <CABzCy2BnB7tM+Z-zDzMBq6pRmpPsZaLWt7GM31E+EPTppoLmzQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a114a7c9c9aa69e052a71d5fa
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ZxRy0Lo6STX7EDziOPWRlim1MT8>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 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: Fri, 29 Jan 2016 04:54:50 -0000

My preferred way of dealing with mix-up has been to use separate
redirection URI but your using issuer instead is for the backward
compatibility?

Nat

2016年1月29日(金) 2:53 John Bradley <ve7jtb@ve7jtb.com>om>:

> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01
> will stop this attack.
>
> White listing AS seems tempting, but is just sweeping the problem
> partially under the rug.
> There are probably good policy reasons to whitelist AS but
> we shouldn’t let this AS mixup be one of them.
>
> John B.
>
> On Jan 27, 2016, at 10:42 PM, Nat Sakimura <sakimura@gmail.com> wrote:
>
> I see. That's like double cut-n-paste.
>
> I tried to capture this case of used-to-be-good AS turning Compromised AS
> (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>
> Given this, just relying on not using random AS is not good enough. You
> would probably require AS w/ISMS with the policy of not logging un-masked
> credentials and has strict access control on the log ;-)
>
> Nat
>
> 2016年1月28日(木) 9:38 Hans Zandbelt <hzandbelt@pingidentity.com>om>:
>
>> indeed, if the attacker is able to phish the user, he can put up a
>> script that first triggers the authorization request to the compromised
>> AS (i.e. the AS at which he has access to the logs and gathers the state
>> value from) through the Client, and subsequently trigger the redirect to
>> the good AS using an auto-refresh of that same phishing page (with the
>> stolen state value); no need to control the authorization endpoint of
>> the compromised AS itself
>>
>> Hans.
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>