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

John Bradley <ve7jtb@ve7jtb.com> Thu, 28 January 2016 17:53 UTC

Return-Path: <ve7jtb@ve7jtb.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 66D401A9029 for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 09:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 5KDeH-LxeheT for <oauth@ietfa.amsl.com>; Thu, 28 Jan 2016 09:53:52 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 2B8F01A8B84 for <oauth@ietf.org>; Thu, 28 Jan 2016 09:53:52 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id b35so45279729qge.0 for <oauth@ietf.org>; Thu, 28 Jan 2016 09:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Y1AoMu8xa1LtnAjYidVSjyNFCSpDPQHxvDFtfiBYJTw=; b=yBEFAk5yMZ5W+9jWjqWffDkfBawF3JOUBQzJKjixEHpfOsilY1zLmKCgRJZbfpN1q6 WCbXhSVQ1HeFchAfeh+Vq9ojY+eV3ua7BA7sS+VpA/el+HCRZC3c6FtbVvpKwNC3zsOy TpVlXfLy71DcKC3iR4yF8JAiXlToaGA+juVkUT+LWqcikP9Xvhv/bR5TU2V4DLCU/1vB 2lbQUvi39INn6xcIv3J77Igr22eiQbaetAZ8hTJx1JsvOSjdMBCq3AXQPIKNQmXk/kC/ RPxJ51OSst1PDhtd2a/d5QSf2neze7PrCg4HV3a6tGzXJSttKThO5YRc9gmaBr663GOs EJGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Y1AoMu8xa1LtnAjYidVSjyNFCSpDPQHxvDFtfiBYJTw=; b=SjGxNaeNfXbEx6/EFdkeOrp5WeT2WDqxW5GslPTpGxfuMX51wNXXFtDfNX7auYk3dZ XbGe5eLe0EwRlbJe8JR7JHaV+HOKxIRDKZHYE23qeQVufMtcpQXEYGXkQQwES43L/TzV i1hvjRgcSXwMN+4cNsBEQbInupfAlHTF8qRFHxTPkEpjtH1VghilIj+eGw0kXeNNkzii 9cYCUsX8Nr+v7fanlVU4jQiN6whw74Nuz9M/UPN1QoMjc+bwTXt8s7PkzTuEpKT6lpyG CN18EpOEOJ5tZN9uAt6bWF6Fy/+7zVfitu1eWc8C5RC5Xy5THNq4wmJvOwWqHl7vUrRp IWww==
X-Gm-Message-State: AG10YOSdsQNHbyJbtatW1haXd/mUdC/Sc6haAl6Qp36i6TKL9CVILUOMRkJ+8YF+CEHDKg==
X-Received: by 10.140.92.215 with SMTP id b81mr5330348qge.44.1454003630295; Thu, 28 Jan 2016 09:53:50 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id d62sm5235317qga.41.2016.01.28.09.53.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 09:53:49 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BAFC9259-7646-487D-BFEE-BB35D037AA1F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CABzCy2CKfZAMg2arjx1uvA73tB4kFaoL2ri4CBNimE99naKarA@mail.gmail.com>
Date: Thu, 28 Jan 2016 14:53:46 -0300
Message-Id: <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
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>
To: Nat Sakimura <sakimura@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/fsuJhS4_vKZyDSXBfrwehEQo_kg>
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 17:53:54 -0000

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 <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 <mailto: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.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth