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

nov matake <matake@gmail.com> Tue, 26 January 2016 00:52 UTC

Return-Path: <matake@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 46AF11AC40C for <oauth@ietfa.amsl.com>; Mon, 25 Jan 2016 16:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 MeQi9JZ1WBnl for <oauth@ietfa.amsl.com>; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 59E541AC405 for <oauth@ietf.org>; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
Received: by mail-pa0-x235.google.com with SMTP id yy13so88865833pab.3 for <oauth@ietf.org>; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=83SMRjS6rxKes+eb3x1UjD6rVdc1pKsyvkzp2hPeHFU=; b=dP10t7RiJ58OUAv3O75/DSGvY8q09E/TTB5vbyhMhyuNCsa3acYOp/ZCOlpoDZwV8K 4V/jjvzisbpT4pzKkFXIbH5dCzpQNmR/MkVL0F0tuc+hCkXxWJuoTjWPPNQ5P3KZcsSH 7MdqgePuMACEPPxaTrki6fsi3EqsD7UppkkBf6tJmuz4uE4sAGZDht1OWjhGMGyJqsoq 5JUhai5bwTBqxewjmSIWsYi+4e2MiXJkWTatJ2HrNqHe6by0dCLa+jnHMp5t+TMMFhTS gIL7S82W8defCAlnaz3aZdWyTLdBabpNEaF/l0RfCsFDPYpU9W4H0yWh7bdKsv2hO8JI RGLA==
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=83SMRjS6rxKes+eb3x1UjD6rVdc1pKsyvkzp2hPeHFU=; b=MJFXGw5WLow9HdqYk1U9gx7anVjfQXG1N0aMtM/aa4E/V/odEOATm3OlUDQ37lbzo8 nI58IMEk4qWV83Fv81wPj59sZ9597ncBaEgwDX/ajwMUOZsr8/kh/jAi0TeWwknjfzu4 K/NNSIwUSqX0JxIJ+DLg5oIps2gv1hf8EpyKIPgpXmAIoZSLh6TQ5FlWyHaoFK3ys69/ T65AzeNz3BeycZr4z4EgY3PhnvpcKlsbYFJel0qiFqnl5G6RE1lNMvDfHYkHx2U3BzW7 3qqDHpKUQ9R9gywuw0ExO03vhO1Vc14NQnqE9Ar7/jnwLJxS9/dvC81dQm67nGKmczoe QvLw==
X-Gm-Message-State: AG10YOR8FjxpjZGErUGPkfb2K1hrCSW6VGaSThWzBwd3GPOT7HskIkUVxkpHDXnFEo5Vlg==
X-Received: by 10.66.185.225 with SMTP id ff1mr29657789pac.97.1453769554724; Mon, 25 Jan 2016 16:52:34 -0800 (PST)
Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id u69sm31294110pfa.61.2016.01.25.16.52.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 16:52:34 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6006A2CB-84FA-4135-B3BD-51DCFBFFEE51"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake <matake@gmail.com>
In-Reply-To: <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com>
Date: Tue, 26 Jan 2016 09:52:30 +0900
Message-Id: <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/H8GKQImbdw7hnPfba_Q9fV2IdPg>
Cc: "oauth@ietf.org WG" <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: Tue, 26 Jan 2016 00:52:37 -0000

The first assumption is coming from the original security report at http://arxiv.org/abs/1601.01229 <http://arxiv.org/abs/1601.01229>.
RFC 6749 requires TLS between RS and AS, and also between UA and AS, but not between UA and RS.

The blog post is based on my Japanese post, and it describes multi-AS case.
Nat's another post describes the case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>

nov

> On Jan 26, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> Sorry, meant to reply-all.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
> 
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>
>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>> Date: January 25, 2016 at 3:20:19 PM PST
>> To: Nat Sakimura <sakimura@gmail.com <mailto:sakimura@gmail.com>>
>> 
>> I am having trouble with the very first assumption. The user-agent sets up a non TLS protected connection to the RP? That’s a fundamental violation of 6749.
>> 
>> Also, the second statement says the RP (assuming it acts as OAuth client) is talking to two IDPs.  That’s still a multi-AS case is it not?
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>> 
>> 
>> 
>> 
>> 
>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com <mailto:sakimura@gmail.com>> wrote:
>>> 
>>> Hi Phil, 
>>> 
>>> Since I was not in Darmstadt, I really do not know what was discussed there, but with the compromised developer documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>, all RFC6749 clients with a naive implementer will be affected. The client does not need to be talking to multiple IdPs. 
>>> 
>>> Nat
>>> 
>>> 2016年1月26日(火) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:
>>> I recall making this point in Germany. 99% of existing use is fine. OIDC is probably the largest community that *might* have an issue.
>>> 
>>> I recall proposing a new security document that covers oauth security for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>> * clients who have configured at runtime or install time (including clients that do discovery)
>>> * clients that communicate with more than one endpoint
>>> * clients that are deployed in large volume and may update frequently (more discussion of "public" cases)
>>> * clients that are script based (loaded into browser on the fly)
>>> * others?
>>> 
>>> Phil
>>> 
>>> > On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com <mailto:gffletch@aol.com>> wrote:
>>> >
>>> > would
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth