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

Nat Sakimura <sakimura@gmail.com> Thu, 28 January 2016 01:42 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 C33401A01BA for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 17:42:20 -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 MxYxYlB8-ZxU for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 17:42:18 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 8F92C1A01AE for <oauth@ietf.org>; Wed, 27 Jan 2016 17:42:18 -0800 (PST)
Received: by mail-qg0-x233.google.com with SMTP id b35so22754200qge.0 for <oauth@ietf.org>; Wed, 27 Jan 2016 17:42:18 -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=1rLIht+4KgcupXS1Vk1kDDfuoYRt566+UpihSBoI4HQ=; b=pCyv2v6pqE4TJjPYJyIBNZ2qaWlENNgGwdOB1Qp/P8CW7TcFNvKw6PuJRk975IcYtm Fy5swl9e9OSNVAi0DFCcjU8rCJNqLMBV1igBwhM8S5B8xqrX/7lasHde1fe1bJqDXTWL QOYbEzaDI6ekATj0e5mFVE6tU/O5+YMOsv3ls9nX8AvRdFGTjisAYo+l/T0hanTmVE8h HjkUkjQVWpn8SzKJzWTK3SPoCiRCZasgxAdhWoSXXIIoGYGCDcwVdW0urAZLgf+FRdYF KQG4XdaGTpOtNhT9r/72zqjforMsVKXkt5skI+ClzuKKURJRu11IbpWyygPYawJWE8Lg 8o+Q==
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=1rLIht+4KgcupXS1Vk1kDDfuoYRt566+UpihSBoI4HQ=; b=XzJQTYJHjiVCV1BgFKY24en2zJktO2oM+vZAJGgmg8wLo+S/SpiiKlSj0hBdZhtcvR Aw2IQJMToYMlztzPcXl0mHNeJxeICETQp0NtAGScxuA55RjL7zm981zeqh0fK5b6FzO9 BPqmXcJRYLD0J4hTAHtutRz06NB16HlyHJNz50HA84mNpE+FfRHZnqdTnY0jjwI66Qtf 3hT7kD5Je5OJdsRFbHmcnGOgUxRY4FWF3Y/qhLW4RmPMClwkczioLMkjbgm4UxgKqsvJ yz5S8HQqUmbsMNywq0XB+FnWt/7C8ZMT8X22gc7+RIgPWnsoSd6HWe5K34kJPMwCES4i yySQ==
X-Gm-Message-State: AG10YOQNR8+artHAU3+D220AaCWVabSbpTMFV1nzUsioFCLl7PJu06SctmEgIRVG4qmLBpfZCGq8zgGrstBJUA==
X-Received: by 10.140.250.138 with SMTP id v132mr544133qhc.0.1453945337742; Wed, 27 Jan 2016 17:42:17 -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>
In-Reply-To: <56A962FA.2010004@pingidentity.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Thu, 28 Jan 2016 01:42:07 +0000
Message-ID: <CABzCy2CKfZAMg2arjx1uvA73tB4kFaoL2ri4CBNimE99naKarA@mail.gmail.com>
To: Hans Zandbelt <hzandbelt@pingidentity.com>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=001a113a99d0610d76052a5b074e
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Ubj_N2SQ3sYJLdA3oK91KeYl_QQ>
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: Thu, 28 Jan 2016 01:42:20 -0000

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>;:

> 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.
>
>