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

Nat Sakimura <sakimura@gmail.com> Fri, 29 January 2016 06:11 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 ABE651B3E8D for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 22:11:48 -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 oi07HCszkcff for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 22:11:46 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 AB5FD1B3E8B for <oauth@ietf.org>; Thu, 28 Jan 2016 22:11:45 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id 6so58174899qgy.1 for <oauth@ietf.org>; Thu, 28 Jan 2016 22:11:45 -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=0kIA39+8e2sXOmze1QSCY1Ss8jJkW/IkRqag9Dz9yiU=; b=xJl/SM+gLHiE7hTAqHKm9GCtZsUT8ocvgvyVzBn6clPx8TQ37P2Xro4UyYzbR+BhUE hFYJJ7ysSKKLX0whQsPVaSAmmwY6wTORc6gzyoKVt7EBpX0u3XRBBWVn3xDiuEKz5eK4 M74GtaIAdYoxKLJk13n/x589UCmMxFODvOiHFC5jXKnsA6wuePGhpr7vNlth12WvTp6A Kv54nmE5Rargvr5Hpoftcr7EqdQPZ2q/LJXbHmqJ1oqWnQW9JHfwEzzpAf/MPyy7SIXN 30pE27C0V7SIdvqSB4sHSmvpZPdW6duSX/zWzOsj6yUqB16N8bvGwYA38yIEbjyVfvn7 zLtw==
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=0kIA39+8e2sXOmze1QSCY1Ss8jJkW/IkRqag9Dz9yiU=; b=UaxyWnu2i+EOgkGw3wPbz03n/yt3rGFirdU8q5DSZu376tvFR6QgKb7Oeq3KrY3EgX MO5QnIxjeRuZLLPk2v+T7x+/FbWJcZV1ukFkGPVKFox2XTNnG+13UXCLpydD1lKvo/r3 x1bD0S3Mmip2OqfCDo+cBNAa1ViK2lwzg6KnlkKVuc9oUF7d5KZBWAftfpsuatcsGKJ2 dZw2FZfjWWLP2EDY8jLGi7XK2r3H10svCt5La8+iKOZG6WFqVsBdSVgp9j9t+tkEp4EM q/WqIsdRRDQ13ufgccCV+YFqNbRkoK76aNDHrNRvQKZ4itYSY4Csb4Q/MSlShzDkkA6b H+Ag==
X-Gm-Message-State: AG10YOQmT1wvrDyj5JlJY9cmf5PL07T6kHVQbmQEPiWinAvfbZsX1vsOZp6RzYLfAtgoxymFx8mwe0GFbx/aBA==
X-Received: by 10.140.101.201 with SMTP id u67mr8574859qge.33.1454047904777; Thu, 28 Jan 2016 22:11:44 -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> <CABzCy2BnB7tM+Z-zDzMBq6pRmpPsZaLWt7GM31E+EPTppoLmzQ@mail.gmail.com> <7FC3FCB3-2FFA-4629-A59F-755BAFEA73FA@oracle.com>
In-Reply-To: <7FC3FCB3-2FFA-4629-A59F-755BAFEA73FA@oracle.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 29 Jan 2016 06:11:33 +0000
Message-ID: <CABzCy2A0PV5fG8yrsvaSidr1dUd1nb=e3ub9jTsBBZ6SSDHMhA@mail.gmail.com>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary=001a11c16e6ad9e798052a72e87d
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/UHXKRVXcYRIEjhABIa29in7ighc>
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 06:11:48 -0000

But that's cut-n-paste protection using "state" token endpoint parameter,
is it not?

2016年1月29日(金) 14:14 Phil Hunt (IDM) <phil.hunt@oracle.com>om>:

> We discussed that redirecr helps but we wanted the Token endpoint to also
> be able to detect assuming many client devs won't implement the check.
>
>
> Phil
>
> On Jan 28, 2016, at 20:54, Nat Sakimura <sakimura@gmail.com> wrote:
>
> 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
>>
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>