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

John Bradley <ve7jtb@ve7jtb.com> Tue, 26 January 2016 17:18 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 95C261A906F for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 09:18:23 -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 ZuSqOFM1zVRc for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 09:18:19 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 679371A9073 for <oauth@ietf.org>; Tue, 26 Jan 2016 09:18:18 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id x1so65517532qkc.1 for <oauth@ietf.org>; Tue, 26 Jan 2016 09:18:18 -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=6Bch92s6W9RoVpebOphox6LqQunuGcvvAUMzRAwFi+c=; b=e/nLcj3GLn+8WwbBwQe0HMpaGo1Wm21yBntoMf0xy3S2a//a3rj8nttHZc+Ewe/EiX SfphQxgOm4CHzDDUK08K1VLxIz3xco7f7WSot4N2tjLKrge1vVYkQtD2G4AOQPqhd1pg +1+2f3WkBvdx5t7T+5H6sCONSMlz5StQb4WAeOYMhaKQDIEvzH13/PYJYCHFGl5TZij5 CYNJT7pXx9ZgvS0Haj5L2EPSt3XrmsMxfFvK7qWVSrXUaet1ibGt2jlZcAf9AxAvlnpB iVys3ypywSQ4aqe3p6y0KbJmK9FAfNPlthQAO82A8RNnadN82rEQWzS59S0Qew7/ZVOX uGIw==
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=6Bch92s6W9RoVpebOphox6LqQunuGcvvAUMzRAwFi+c=; b=HDzUeJVjMq8s0D064g+el0B7ct8pRgYPq35M6seU3ZcO4X9WAuFVJ3XrDgwcvS19Ay j4vFMcc/ldbsYKFdZwoccI5IpVklT2ca8QoZik+ldxB2KjBIjIO534QMWRZUT7AUffh7 D3jOuTAcXe51Rb8/Vq7Kb4/9Lpx4oB18D/VWThH/SaXoWWiH/dtmWDwsGbhBLvVCbXwi hoIEdV/61md3sbJwin6RXKDbTxN6+RRV+cG/jiQuQmoxmK/sPcGW8pdi6r/TzVumGKhT BWy/MMs7A3AukkMKI6gPXjTgPoq4nikPjoD+VwTIt0bVta5yT1n3RqQm9gOysVrG2QLC v4cQ==
X-Gm-Message-State: AG10YOQzwPXG5TZZ/Th1avJ1UljYuKw2b1wcHZA+TAWmhEJwsMCxgP1E/ZXq9A9j/AavTQ==
X-Received: by 10.55.19.129 with SMTP id 1mr4718707qkt.51.1453828697959; Tue, 26 Jan 2016 09:18:17 -0800 (PST)
Received: from [192.168.8.100] ([181.202.129.132]) by smtp.gmail.com with ESMTPSA id s130sm881108qhb.6.2016.01.26.09.18.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 09:18:17 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7A580B9D-6A2A-4EB5-8A0C-F9342FF13A67"; 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: <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
Date: Tue, 26 Jan 2016 14:18:13 -0300
Message-Id: <63914724-175F-47EA-BC48-5FB9E6C5FE87@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>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Wo4yrSV6r9zEZqaE1PAWgq8ThQ0>
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 17:18:23 -0000

Nov,

Are you referring to Sec 3.1.2.1 of RFC 6749.

Stating that the the redirection endpoint SHOULD require TLS, and that the AS should warn the user if the redirect URI is not over TLS (Something I have never seen done in the real world)

Not using TLS is reasonable when the redirect URI is using a custom scheme for native apps.

It might almost be reasonable for the token flow where the JS page itself is not loaded over TLS so the callback to extract the fragment would not be as well. 
Note that the token itself is never passed over a non https connection in tis case.
I would argue now that it is irresponsible to have a non TLS protected site, but not everyone is going to go along with that.  

Using a http scheme URI for the redirect is allowed but is really stupid.   We did have a large debate about this when profiling OAuth for Connect.
We did tighten connect to say that if you are using the code flow then a http scheme redirect URI is only allowed if the client is confidential. 

John B.
> On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
> 
> Still don't see it. Though i think the diagram is wrong (the rp should redirct to the ua and not call the authz direct), the IDP should either return an error or redirect the RP to TLS. 
> 
> I don't see this as proper oauth protocol since the RP is MITM the UA rather than acting as a client. 
> 
> Phil
> 
> On Jan 25, 2016, at 19:57, nov matake <matake@gmail.com <mailto:matake@gmail.com>> wrote:
> 
>> In this flow, AuthZ endpoint is forced to be TLS-protected.
>> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png <http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png>
>> 
>> However, RP’s redirect response which causes following AuthZ request is still not TLS-protected, and modified on the attacker’s proxy.
>> 
>> Section 3.2 of this report also describes the same flow.
>> http://arxiv.org/pdf/1601.01229v2.pdf <http://arxiv.org/pdf/1601.01229v2.pdf>
>> 
>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>> Also the authz endpoint is required to force tls. So if the client doesn't do it the authz should reject (eg by upgrading to tls). 
>>> 
>>> Phil
>>> 
>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>>> When the RP acting as the client issues a authorize redirect to the UA it has to make it with TLS
>>>> 
>>>> Phil
>>>> 
>>>> On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com <mailto:matake@gmail.com>> wrote:
>>>> 
>>>>> It doen't say anything about the first request which initiate the login flow.
>>>>> It is still a reasonable assumption that RP puts a "login with FB" button on a non TLS-protected page.
>>>>> 
>>>>> nov
>>>>> 
>>>>> On Jan 26, 2016, at 10:45, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>>>> 
>>>>>> I would find it hard to believe that is true.
>>>>>> 
>>>>>> From 6749 Sec 3.1 
>>>>>>    Since requests to the authorization endpoint result in user
>>>>>>    authentication and the transmission of clear-text credentials (in the
>>>>>>    HTTP response), the authorization server MUST require the use of TLS
>>>>>>    as described in Section 1.6 <https://tools.ietf.org/html/rfc6749#section-1.6> when sending requests to the
>>>>>>    authorization endpoint.
>>>>>> 
>>>>>> Sec 3.1.2.1 
>>>>>>    The redirection endpoint SHOULD require the use of TLS as described
>>>>>>    in Section 1.6 <https://tools.ietf.org/html/rfc6749#section-1.6> when the requested response type is "code" or "token",
>>>>>>    or when the redirection request will result in the transmission of
>>>>>>    sensitive credentials over an open network.  This specification does
>>>>>>    not mandate the use of TLS because at the time of this writing,
>>>>>>    requiring clients to deploy TLS is a significant hurdle for many
>>>>>>    client developers.  If TLS is not available, the authorization server
>>>>>>    SHOULD warn the resource owner about the insecure endpoint prior to
>>>>>>    redirection (e.g., display a message during the authorization
>>>>>>    request).
>>>>>> 
>>>>>>    Lack of transport-layer security can have a severe impact on the
>>>>>>    security of the client and the protected resources it is authorized
>>>>>>    to access.  The use of transport-layer security is particularly
>>>>>>    critical when the authorization process is used as a form of
>>>>>>    delegated end-user authentication by the client (e.g., third-party
>>>>>>    sign-in service).
>>>>>> 
>>>>>> Section 10.5 talks about transmission of authorization codes in connection with redirects.
>>>>>> 
>>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.
>>>>>> 
>>>>>> 
>>>>>> Phil
>>>>>> 
>>>>>> @independentid
>>>>>> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com <mailto:matake@gmail.com>> wrote:
>>>>>>> 
>>>>>>> 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 <mailto: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 <mailto:OAuth@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>> 
>>>>>> 
>>>> _______________________________________________
>>>> 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