Re: [OAUTH-WG] TLS is needed for redirecting back to the client
Francisco Corella <fcorella@pomcor.com> Tue, 04 January 2011 21:25 UTC
Return-Path: <fcorella@pomcor.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4223A6BCF for <oauth@core3.amsl.com>; Tue, 4 Jan 2011 13:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGfa32IJ8Mm4 for <oauth@core3.amsl.com>; Tue, 4 Jan 2011 13:25:19 -0800 (PST)
Received: from nm6-vm0.bullet.mail.ac4.yahoo.com (nm6-vm0.bullet.mail.ac4.yahoo.com [98.139.52.70]) by core3.amsl.com (Postfix) with SMTP id 206273A6BCE for <oauth@ietf.org>; Tue, 4 Jan 2011 13:25:18 -0800 (PST)
Received: from [98.139.52.196] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000
Received: from [98.139.52.145] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000
Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 383219.93060.bm@omp1028.mail.ac4.yahoo.com
Received: (qmail 3539 invoked by uid 60001); 4 Jan 2011 21:27:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294176443; bh=Ydrjbkw3E3PIUMn+7c/afkPuirTOCMhlITogtJV/7BQ=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hJ87GHXe3jK0u2NZS6jyyIjwjXMwpEqRKqmsdpUd0WLGJabzhg0/y7JDDJvG+IpZpeyvuQt8D7aGZzgsB5q1hhlp1Q2fdm4Hmxwc9mA99v65Sl6U20CxiSxd/8+NpB7s3tZduvBz1LwEOUJ2D42KYzkti9li1SSTBQThz+z5kN0=
Message-ID: <180992.98715.qm@web55806.mail.re3.yahoo.com>
X-YMail-OSG: 7VKzbRUVM1mUwA3p8q1qFRW7EWwNE14fG0gNEsLCV0m1yAE t_Yx9BXmPjCi_P.Cv847C7FOWfg6WA3vYyrEzp62N.BPTiQr9ZyPeywYrhwN .UWpeZvGCvvRV2GdXC1n4XDqqLbBNvcl7oiw723BcOfa.GJr7KaZbxxDVaI_ oie3lEaEYyC7IoOmevl29k75JKOlhBO_IMplxiR_8BtzljHUs93l_g.aKN7N a6x4KmrP4Sfv_ensPtm.au0uu1ATFmkQf9Q1Kk_g01hGG5FOmakRJaimis_I 6ETYk6.vDTK8NEtQudyegSVc2ox1XpY.ipv5dEg3kyicUocKGNZcEfByPpOT f5Hz1YzlxKDzmKRkL6kYhLqqG2ACsBPKhRlzfKjauc61JyPdDqaCTF4Wn8EM O5F8-
Received: from [67.91.91.101] by web55806.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 13:27:22 PST
X-RocketYMMF: francisco_corella
X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259
Date: Tue, 04 Jan 2011 13:27:22 -0800
From: Francisco Corella <fcorella@pomcor.com>
To: oauth@ietf.org, torsten@lodderstedt.net
In-Reply-To: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1788708054-1294176442=:98715"
Cc: "Karen P. Lewison" <kplewison@pomcor.com>
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: fcorella@pomcor.com
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 04 Jan 2011 21:25:20 -0000
Torsten, > you made a good point. However, the question is if this > belongs into the OAuth scope since this a general attack on > a web app's session management. I gave two variants of the attack. I agree that the first variant "looks like" an attack against session management, but the second variant is clearly an attack against the protocol. Let me recap the second variant. The attacker compromises the DNS, mapping the domain name in the redirection URI to the attacker's machine. The http request sent by the resource owner's browser to the redirection uri, which contains the authorization code, is received by the attacker's machine. The attacker forwards the request with the authorization code to the client application from the attacker's own machine, thereby impersonating the resource owner. The client application mistakenly authenticates the attacker as the resource owner after verifying that the authorization code is legitimate by using it to get an access code from the authorization server. After the mistaken authentication, the client application creates a session and gives an authentication cookie to the attacker. Let me philosophize a bit. OAuth was conceived as an authorization protocol, hence the vocabulary ("authorization server", "resource owner"), but it has morphed. Now it is also used for authentication. When you click on a button "Login with Twitter" or "Login with Facebook" you are authenticated with OAuth: Twitter and Facebook do not currently support OpenID for social login. When OAuth is used for authentication, the authorization code takes on a different role: posession of the authorization code is what authenticates the user. Therefore transmission of the authorization code must be protected by TLS. Let me philosophize some more. (Busy people should stop reading here ;-) We need a protocol that does both authentication and authorization. We can take OAuth and adapt it for authentication, or take OpenID and adapt it for authorization, or combine OpenID and OAuth (great solution for people who love complexity) or... take the best ideas from OpenID and OAuth and incorporate them into a new protocol that's designed from the start for both authentication and authorization. That's one of my motivations for proposing PKAuth. Now a political speech. Social login is going to win. (I use "social login" as Janrain uses it, I believe they coined the term, is that right?) It will win because it has tremendous advantages not just for users (that's not enough), but also for social sites and applications. Once it wins we may get into a situation where social login with the social identity provided by the dominant social site (currently Facebook) becomes the de fact standard for user authentication on the Web. If the dominant social site requires application registration, then every application on the Web will have to register with the dominant social site just to be able to authenticate its users, whether or not they have anything to do with the social site. The dominant social site would then have to power to kill any application by terminating its registration. This would be an intolerable situation for everybody, including the dominant social site. The dominant social site will not need or want this kind of power, which would call for government regulation by every government on the planet. So we need an authentication and authorization protocol where application registration is optional. But registration has an essential function in OAuth. The social site relies on registration to be able to reliably identify the application to the user. We need a protocol that can reliably identify unregistered applications to the user. That's a second motivation for PKAuth. Francisco
- [OAUTH-WG] TLS is needed for redirecting back to … Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… torsten
- Re: [OAUTH-WG] TLS is needed for redirecting back… Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… Marius Scurtescu
- Re: [OAUTH-WG] TLS is needed for redirecting back… torsten
- Re: [OAUTH-WG] TLS is needed for redirecting back… Justin Richer
- Re: [OAUTH-WG] TLS is needed for redirecting back… Torsten Lodderstedt
- Re: [OAUTH-WG] TLS is needed for redirecting back… Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… torsten
- Re: [OAUTH-WG] TLS is needed for redirecting back… Mike Jones
- Re: [OAUTH-WG] TLS is needed for redirecting back… Francisco Corella
- Re: [OAUTH-WG] TLS is needed for redirecting back… Nat Sakimura
- Re: [OAUTH-WG] TLS is needed for redirecting back… Nat Sakimura