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

George Fletcher <gffletch@aol.com> Wed, 27 January 2016 12:49 UTC

Return-Path: <gffletch@aol.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 DC6DF1A88DB for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 04:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 4ZdQCiqMMXdO for <oauth@ietfa.amsl.com>; Wed, 27 Jan 2016 04:49:10 -0800 (PST)
Received: from omr-a015e.mx.aol.com (omr-a015e.mx.aol.com [204.29.186.63]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248BF1A88C0 for <oauth@ietf.org>; Wed, 27 Jan 2016 04:49:08 -0800 (PST)
Received: from mtaout-mba02.mx.aol.com (mtaout-mba02.mx.aol.com [172.26.133.110]) by omr-a015e.mx.aol.com (Outbound Mail Relay) with ESMTP id EA3FC3800046; Wed, 27 Jan 2016 07:49:06 -0500 (EST)
Received: from [10.172.102.147] (unknown [10.172.102.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mba02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 619FC38000082; Wed, 27 Jan 2016 07:49:06 -0500 (EST)
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <ve7jtb@ve7jtb.com>, "Phil Hunt (IDM)" <phil.hunt@oracle.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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56A8BCC3.6030903@aol.com>
Date: Wed, 27 Jan 2016 07:49:07 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A8BB7C.80702@aol.com>
Content-Type: multipart/alternative; boundary="------------020209060408020102070606"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453898946; bh=NZV8f6fL0e+CAPsBedgdRdZQFUYNtHGtUWi4+j1OawU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=SWitID+H5pexpX/YT28qRyM1GITAaP2IkxjoJO7GVVQHEwimYToP6RUkJguGiyoOF 7bXv1moQZ0VCDDgSAI7RuawtNIDrnWrUzVJgQOFnWCtBOlb525f7PDsiW3nMqICFNt cEdqUioXB9nD1705NWEh93vdlmBWMUHxfow3+2MU=
x-aol-sid: 3039ac1a856e56a8bcc232fe
X-AOL-IP: 10.172.102.147
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/kl4k4SdiDBjDvjI5aO0MH46UMjI>
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: Wed, 27 Jan 2016 12:49:15 -0000

Based on Hans' response to Nat I understand why this doesn't solve all 
the use cases. It does still seem like a good idea from a client 
perspective that would address the dynamic client registration cases 
where the Bad AS is returning mixed endpoints.

On 1/27/16 7:43 AM, George Fletcher wrote:
> Following up on Nat's last paragraph... did the group in Darmstadt 
> discuss this option? Namely, to require that the authority section of 
> the AuthZ and Token endpoints be the same? Are there known 
> implementations already deployed where the authority sections are 
> different? It seems like a simple check that would address the 
> endpoint mix-up cases.
>
> Thanks,
> George
>
> On 1/26/16 8:58 PM, Nat Sakimura wrote:
>> John,
>>
>> Nov is not talking about the redirection endpoint. I just noticed 
>> that 3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD" and I think 
>> it needs to be changed to "MUST" but that is not what he is talking 
>> about.
>>
>> Instead, he is talking about before starting the RFC 6749 flow.
>>
>> In many cases, a non TLS protected sites have "Login with HIdP" 
>> button linked to a URI that initiates the RFC 6749 flow. This portion 
>> is not within  RFC 6749 and this endpoint has no name or no 
>> requirement to be TLS protected. Right, it is very stupid, but there 
>> are many sites like that.
>> As a result, the attacker can insert itself as a proxy, say by 
>> providing a free wifi hotspot, and either re-write the button or the 
>> request so that the RP receives "Login with AIdP" instead of "Login 
>> with HIdP".
>>
>> I have add a note explaining this to 
>> http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/
>>
>> I also have added a bit of risk analysis on it and considered other 
>> risk control measures as well.
>>
>> It does not seem to be worthwhile to introduce a new wire-protocol 
>> element to deal with this particular attack. (I regard code 
>> cut-and-paste attack a separate attack.) I am inclining to think that 
>> just to TLS protect the pre-RFC6749 flow portion and add a check to 
>> disallow the ASs that has different authority section for the Auhtz 
>> EP and Token EP would be adequate.
>>
>> Nat
>>
>> 2016年1月27日(水) 2:18 John Bradley <ve7jtb@ve7jtb.com>:
>>
>>     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> 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
>>>>
>>>>     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
>>>>
>>>>>     On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
>>>>>     <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> 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> 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>
>>>>>>>     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 inSection 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
>>>>>>>>         inSection 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
>>>>>>>>     phil.hunt@oracle.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>     On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com>
>>>>>>>>>     wrote:
>>>>>>>>>
>>>>>>>>>     The first assumption is coming from the original security
>>>>>>>>>     report at 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/
>>>>>>>>>
>>>>>>>>>     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
>>>>>>>>>>     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
>>>>>>>>>>>     phil.hunt@oracle.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>     On Jan 25, 2016, at 2:58 PM, Nat Sakimura
>>>>>>>>>>>>     <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/,
>>>>>>>>>>>>     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>:
>>>>>>>>>>>>
>>>>>>>>>>>>         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> wrote:
>>>>>>>>>>>>         >
>>>>>>>>>>>>         > would
>>>>>>>>>>>>
>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>         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
>>>>>>>>>
>>>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
> Chief Architect
> Identity Services Engineering     Work:george.fletcher@teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography