Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3089F21F87CE for ; Wed, 4 Jan 2012 17:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.211 X-Spam-Level: X-Spam-Status: No, score=-17.211 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HxYKMR7m-0I for ; Wed, 4 Jan 2012 17:16:14 -0800 (PST) Received: from nm13-vm0.bullet.mail.ac4.yahoo.com (nm13-vm0.bullet.mail.ac4.yahoo.com [98.139.52.232]) by ietfa.amsl.com (Postfix) with SMTP id 04FAC21F87CB for ; Wed, 4 Jan 2012 17:16:13 -0800 (PST) Received: from [98.139.52.195] by nm13.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 Received: from [98.139.52.169] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 Received: from [127.0.0.1] by omp1052.mail.ac4.yahoo.com with NNFMP; 05 Jan 2012 01:16:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 834142.298.bm@omp1052.mail.ac4.yahoo.com Received: (qmail 64115 invoked by uid 60001); 5 Jan 2012 01:16:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325726167; bh=Xutx8L3IpZcT1o5luKWFEo3HRw6+n2uqsno6xXiRPsw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q84NW9K7zWIq8hmYgivm9jh9LKyL+I5Y/lpccRk68uMzdwXJc7r6E7XsPZu3wzEFzuGIwFEcgIZ5cLyBLDR2ivR11uiX1tzCZh6dtJd1+woH2nR1EDKmuF/Ht64jxOxAXcmm+G+Qt7yIN3QcA0FrCRtEfh4cnTC4LBtUyLNja7o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gNghri7Kh7+joxxVcl1DJQ+BkGA/YI2hna5+wHER7NrxL5866wMvxSmf6tlTWPEuksLHTWTXFmjz7qs/XJClSTfusqqO6bUR1rzOtSOzZLjBuoHOafgiul8oTxtSns1GEkCuZrUnC8iTWMGe9XNtB4a42CmSUniiY36DUagHQfc=; X-YMail-OSG: GCOqGFwVM1nqrwIuqEJXWXiwypo9_QnJ4GtsxFzCWgibbBt OiQ6SjK7kGgkBrIOM93kattnAfqJJc_5NhhXkM3yaPtv5P3TIsXWOXnKUCD1 PYZia4ZL6G0.xL9GP00mme8lyrkK3a76Ythm_uijDhQh2tZ_aWDRVbgrfodC Fe.u3ZeXfIxqshyNBXWzuTmeGZCT3nZSW2qwT4PGBZtXSGCF.4JjnER2fJ4L LFk_7XdZBP7AHK8iZOQXdAUNz.0KCKmr0w3LyommrVDEid6JfwdtlJGZXFV1 gXFTHnntsaS2PLY1MW1N.9dFu8wlldQW.fOY.pPOGESGOb5LVTEaXQRAFQ8i 4v6nAi_27JJdGRlbZvgOTZqnr.NYMBE_2AbHguQREkKCwWjb2LFt5Wg.OGvY iGetuQALiw2axnSA40ePi30RJVCe7WVtbRsMiD0yqxg-- Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Wed, 04 Jan 2012 17:16:07 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <4F0394D6.1090006@mtcc.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F04F134.5050409@mtc c.com> Message-ID: <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 4 Jan 2012 17:16:07 -0800 (PST) From: William Mills To: Michael Thomas , Eran Hammer-Lahav In-Reply-To: <4F04F134.5050409@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-706396534-1325726167=:42441" Cc: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:16:15 -0000 --767760015-706396534-1325726167=:42441 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The below is unfortunately probably a no-go:=0A=0A=0A> Given these threats,= authentication servers MUST NOT give clients access=0A> to authentication = services -- and by extension to resource services -- unless the=0A> authent= ication service can thoroughly vet the trustworthiness of the client. How= =0A> that vetting is achieved is outside of the scope of this document, but= the current=0A> practice of freely giving client keys to any would-be OAUT= H client is not sufficient."=0A=0A=0AIt's unfortunately not really a solved= problem for widely distributed clients.=A0 I attack this by spoofing a kno= wn client and the resource server or auth server can't tell the difference.= =A0 That's why I was falling back to the more brutal "this doesn't protect = you from ..." statement.=0A=0ANative mobile clients where the default exper= ience is likely to be not to spawn a browser for the interaction are going = to be a real problem too.=0A=0AAuth servers (I think that's where you get t= he best control) can do their best to keep track of what clients a user has= authenticated and prompt the user on a new client, but it's still up to th= e user to make sure they're not being lied to, and in practice this is only= marginally effective (and tends in fact to slow adoption with a "scary" me= ssage, so product type folks don't like it). =0A=0A=0A-bill=0A=0A=0A=0A=0A_= _______________________________=0A From: Michael Thomas =0AT= o: Eran Hammer-Lahav =0ACc: oauth WG = ; Barry Leiba =0ASent: Wednesday, January 4, 2012= 4:39 PM=0ASubject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-= 01, ends 9 Dec 2011=0A =0AOn 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:= =0A>=0A>> -----Original Message-----=0A>> From: oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] On Behalf=0A>> Of Michael Thomas=0A>> Sent: Wed= nesday, January 04, 2012 3:40 PM=0A>> My concern is that putting on a venee= r of "security" will lull people into=0A>> thinking "Oh, it's safe to enter= my credentials here because this is really=0A>> twitterbook, not evilapp!"= . When I had to ask them directly to put their=0A>> twitterbook credentials= into my app, there at least wasn't any confusion that=0A>> I had access to= them.=0A> This is ridiculous (e.g. the fact we are still discussing this).= =0A>=0A> First, end users know nothing about security or OAuth. Second, evi= l apps can create this veneer of security by faking a redirection flow with= or without OAuth. Suggesting that OAuth (which is a de-facto web pattern f= or over a decade) makes anything worse is patently false.=0A>=0A> The only = thing we can possibly add to the threat model document is to mention that "= OAuth does not provide any protection against malicious applications and th= at the end user is solely responsible for the trustworthiness of any native= application installed". That is accurate (and completely obvious to the ta= rget audience of this document). It is not very helpful but if it will make= you feel better (since no one else here seems to share your concerns), I h= ave no objection to such one line added.=0A>=0A> And again, to highlight th= e absurdity of your security claim, it is equally important to warn develop= ers in earthquake-prone countries to put enough distance between the Approv= e and Deny buttons so that the user will not accidentally hit Approve durin= g a tremor.=0A>=0A=0AIt's this kind of hostility and ad hominem that leads = me to believe that=0Ayou have forgotten some of your lessons in charm schoo= l.=0A=0AFor one, I am not the only one and even if I were that would still = not be=0Aa reason to shoot the messenger. Secondly it is *not* the sole res= ponsibility=0Aof the end user: the authentication server absolutely has a p= art to play=0Ahere too. They have to give out client keys, after all, and i= ts their service=0Athat could be hacked. So they have as much if not more r= esponsibility=0Athan the end user.=0A=0ASo to Bill's request here is the te= xt I would propose.=0A=0A"Native apps, not limited to, but including apps w= hich are available on popular=0Amobile app stores, have the potential for g= aining access to the end user's credentials.=0AThis can be accomplished by = gaining access to browser UI components and key logging,=0Aspoofing the loo= k and feel of an authentication server's authentication page, and=0Apotenti= ally many other social engineering attacks. The potential for these attacks= =0Aexist in many existing OAUTH2 deployments including but not limited to F= acebook=0Aand Twitter.=0A=0AGiven these threats, authentication servers MUS= T NOT give clients access=0Ato authentication services -- and by extension = to resource services -- unless the=0Aauthentication service can thoroughly = vet the trustworthiness of the client. How=0Athat vetting is achieved is ou= tside of the scope of this document, but the current=0Apractice of freely g= iving client keys to any would-be OAUTH client is not sufficient."=0A=0AMik= e=0A_______________________________________________=0AOAuth mailing list=0A= OAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --767760015-706396534-1325726167=:42441 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The = below is unfortunately probably a no-go:

> = Given these threats, authentication servers MUST NOT give clients access> to authentication services -- and by extension to resource services -= - unless the
> authentication service can thoroughly vet the trustwor= thiness of the client. How
> that vetting is achieved is outside of t= he scope of this document, but the current
> practice of freely givin= g client keys to any would-be OAUTH client is not sufficient."

It's unfortunately not really a solved problem for widely = distributed clients.  I attack this by spoofing a known client and the= resource server or auth server can't tell the difference.  That's why= I was falling back to the more brutal "this doesn't protect you from ..." statement.

Native mobile clients where the d= efault experience is likely to be not to spawn a browser for the interactio= n are going to be a real problem too.

Auth servers= (I think that's where you get the best control) can do their best to keep = track of what clients a user has authenticated and prompt the user on a new= client, but it's still up to the user to make sure they're not being lied = to, and in practice this is only marginally effective (and tends in fact to= slow adoption with a "scary" message, so product type folks don't like it)= .

-bill



From:= Michael Thomas <mike@mtcc.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: oauth WG <oauth@ietf.org= >; Barry Leiba <barryleiba@computer.org>
Sent: Wednesday, January 4, 2012 4:39 PM
<= b>Subject: Re: [OAUTH-WG] WGL= C on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
= =0AOn 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:
>
>> ---= --Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mi= chael Thomas
>> Sent: Wednesday, January 04, 2012 3:40 PM
>&= gt; My concern is that putting on a veneer of "security" will lull people i= nto
>> thinking "Oh, it's safe to enter my credentials here becaus= e this is really
>> twitterbook, not evilapp!". When I had to ask = them directly to put their
>> twitterbook credentials into my app,= there at least wasn't any confusion that
>> I had access to them.=
> This is ridiculous (e.g. the fact we are still discussing this).>
> First, end users know nothing about security or OAuth. Secon= d, evil apps can create this veneer of security by faking a redirection flow = with or without OAuth. Suggesting that OAuth (which is a de-facto web patte= rn for over a decade) makes anything worse is patently false.
>
&g= t; The only thing we can possibly add to the threat model document is to me= ntion that "OAuth does not provide any protection against malicious applica= tions and that the end user is solely responsible for the trustworthiness o= f any native application installed". That is accurate (and completely obvio= us to the target audience of this document). It is not very helpful but if = it will make you feel better (since no one else here seems to share your co= ncerns), I have no objection to such one line added.
>
> And ag= ain, to highlight the absurdity of your security claim, it is equally impor= tant to warn developers in earthquake-prone countries to put enough distanc= e between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor.
>

It's this kind of= hostility and ad hominem that leads me to believe that
you have forgott= en some of your lessons in charm school.

For one, I am not the only = one and even if I were that would still not be
a reason to shoot the mes= senger. Secondly it is *not* the sole responsibility
of the end user: th= e authentication server absolutely has a part to play
here too. They hav= e to give out client keys, after all, and its their service
that could b= e hacked. So they have as much if not more responsibility
than the end u= ser.

So to Bill's request here is the text I would propose.

"= Native apps, not limited to, but including apps which are available on popu= lar
mobile app stores, have the potential for gaining access to the end = user's credentials.
This can be accomplished by gaining access to browse= r UI components and key logging,
spoofing the look and feel of an authentication server's authentication page, and
potentially many other= social engineering attacks. The potential for these attacks
exist in ma= ny existing OAUTH2 deployments including but not limited to Facebook
and= Twitter.

Given these threats, authentication servers MUST NOT give = clients access
to authentication services -- and by extension to resourc= e services -- unless the
authentication service can thoroughly vet the t= rustworthiness of the client. How
that vetting is achieved is outside of= the scope of this document, but the current
practice of freely giving c= lient keys to any would-be OAUTH client is not sufficient."

Mike
= _______________________________________________
OAuth mailing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth


--767760015-706396534-1325726167=:42441--