Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
George Fletcher <gffletch@aol.com> Tue, 26 January 2016 12:37 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 E9FF01B2FF1 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 04:37:55 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ttTZN3gjVaqY for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 04:37:52 -0800 (PST)
Received: from omr-m018e.mx.aol.com (omr-m018e.mx.aol.com [204.29.186.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DD41B2FF0 for <oauth@ietf.org>; Tue, 26 Jan 2016 04:37:51 -0800 (PST)
Received: from mtaout-aam01.mx.aol.com (mtaout-aam01.mx.aol.com [172.27.19.145]) by omr-m018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 0F99E3800086; Tue, 26 Jan 2016 07:37:50 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aam01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7320138000081; Tue, 26 Jan 2016 07:37:49 -0500 (EST)
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, nov matake <matake@gmail.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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56A7689B.6070205@aol.com>
Date: Tue, 26 Jan 2016 07:37:47 -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: <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
Content-Type: multipart/alternative; boundary="------------020003050501070709050601"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453811869; bh=kI92hyWNMaD+Rj+RpnPeko4osAonlvmTFCithO4NKaM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=1y2ySXDUG/thW7oJ8+pf5ot+6fNZ8mQ436+Tx8bP2Z1rcUXZvBcpmF8Uhp2KCB70l dMU908pb3/VOvKJZB7BJHhfzIjvnSyOx2sQ1+YD96k80L8jOCFyzC0wdHYboxHGv37 jO3ANuypf1r9xErldqsAeU2+oGsGyFqQv8EolOMY=
x-aol-sid: 3039ac1b139156a7689d1a10
X-AOL-IP: 10.172.102.124
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/YRLEa9LTQi9YfdoTtZjOEGUmpSk>
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 12:37:56 -0000
While I agree it may not be "proper" OAuth the fact is that the attack is still possible and that means that some acknowledgement (security or spec considerations) is required. Being able to MITM the UA or get the user to click a link that takes them to a malicious "client" that is really a MITM agent is easily doable. While it's possible to confuse a client that just uses a single AS, that attack is more of a "endpoint phishing" style attack than a protocol attack. So far, baring no additional use cases, I'm still OK with declaring the existing spec viable for clients that pre-configure a single AS. Though I do think a "security consideration" should be written discussing this "endpoint phishing" attack that Nat describes. That said, to really protect these flows, I've come to the conclusion that discovery and cryptographic binding are required for clients. Thanks, George On 1/25/16 11:14 PM, Phil Hunt (IDM) 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 >> >> 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 >>> <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 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 <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. >>>>>>> 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 >>>>>>>> <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/, >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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-WG] Call for Adoption: OAuth 2.0 Mix-Up Mi… Hannes Tschofenig
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Brian Campbell
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… William Denniss
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Anthony Nadalin
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Antonio Sanso
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Roland Hedberg
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Josh Mandel
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Josh Mandel
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… William Denniss
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Mike Jones
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… nov matake
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Hans Zandbelt
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… William Denniss
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… nov matake
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Justin Richer
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… nov matake
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nov Matake
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… nov matake
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… George Fletcher
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Justin Richer
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Hans Zandbelt
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Hans Zandbelt
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… John Bradley
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Phil Hunt (IDM)
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-U… Mike Jones