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 9720921F87B9; Thu, 5 Jan 2012 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 hjYhQuoZz539; Thu, 5 Jan 2012 09:11:45 -0800 (PST) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7321F875F; Thu, 5 Jan 2012 09:11:45 -0800 (PST) Received: from mtaout-db05.r1000.mx.aol.com (mtaout-db05.r1000.mx.aol.com [172.29.51.197]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q05HBKnb017943; Thu, 5 Jan 2012 12:11:20 -0500 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 75E25E00022C; Thu, 5 Jan 2012 12:11:19 -0500 (EST) Message-ID: <4F05D9B3.9000200@aol.com> Date: Thu, 05 Jan 2012 12:11:15 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Michael Thomas 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.3 <1325721020.62165.YahooMailNeo@web31812.mail.mud.yahoo.com> <1325781459.27034.YahooMailNeo@web31803.mail.mud.yahoo.com> <4F05D447.9070902@mtcc.com> In-Reply-To: <4F05D447.9070902@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1325783480; bh=aFXZhPLa1GM2684G18ZgSDR+CcLNNXjAmqvkXdIxdlA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=AOc/7X/VlGJbkbWgHzAfCFJ034VvJrEFZ7kjeXi+tLMTdhUBFsIdQ5YxocOi2xKOt COdbzk/HV4o7+z2wxCgBkVvnWrdnAFnAqPhA09PrelOCjqFz1De7QTNuwoWscs5ekC dCdhhhm1kQzfr7LfSnfajdro5Q+nhH9j8efDu6P4= X-AOL-SCOLL-SCORE: 0:2:443649792:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c54f05d9b72bf4 X-AOL-IP: 10.181.186.254 Cc: Barry Leiba , oauth WG , "oauth-bounces@ietf.org" 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 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:11:49 -0000 The problem is that even if the Authorization Server only gives out=20 credentials to "trusted clients", those clients can be "hacked" and the=20 credentials compromised allowing for impersonation of the "trusted=20 client". Obviously, protecting the credentials is easier if the client=20 is a web server with the appropriate security measures in place. However, that isn't the only use case that needs to be solved. Rich=20 desktop applications and mobile applications also need access to the=20 user's protected resources. The issue here is that clients (in the vast=20 majority of cases) can't be trusted. This means that all rich desktop/mobile app models currently in the=20 field are flawed (if we are trying to protect the user from a malicious=20 client). OAuth is specifically NOT trying to solve the "client=20 trustworthiness" problem. Personally, I don't see how to solve this=20 problem without "trusted hardware" in the client and that isn't yet=20 widely deployed. However, as others have pointed out, OAuth doesn't make the existing=20 situation worse (i.e. users are just as likely without OAuth to download = malicious code to their computers/devices and be phished). However, with = more "good" applications moving to OAuth, the situation generally=20 improves for the user, because their credentials are stored in fewer=20 places. It might even push the "bad guys" to having to implement=20 malicious apps as other methods of getting the user's credentials are=20 significantly reduced. From a threat model perspective, while OAuth doesn't solve this=20 specific threat, the use of OAuth overall improves the security of the us= er. My 2 cents:) On 1/5/12 11:48 AM, Michael Thomas wrote: > > Second: I don't think that the suggestion should be that the markets do= > this vetting -- they won't because they aren't fate shared. The auth=20 > server, > on the other hand, has the ability to not enroll clients. That at least= > is plausible rather than the completely implausible suggestion that > billions of users educate themselves on millions of apps. > > Mike > >> >> ----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------=20 >> > --=20 >> *From:* Mark Mcgloin >> *To:* William Mills >> *Cc:* Barry Leiba ; Michael Thomas=20 >> ; oauth WG ; oauth-bounces@ietf.org;=20 >> Torsten Lodderstedt >> *Sent:* Thursday, January 5, 2012 6:03 AM >> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, = >> ends 9 Dec 2011 >> >> Why do you think this William? Apple does it? Google android market=20 >> had to >> pull 30 apps recently because they contained malware. There are=20 >> automated >> tools that will do some sanity checks on apps and it is only advice,=20 >> i.e. >> 'could' >> >> Mark >> >> > William Mills > >> > >> > " o Client applications could be validated prior publication in a= >> > application market." >> > >> > Should just be struck. Michael is correct that it's fluff, and >> > unenforceable. There are too many app marketplaces, opensource >> > projects, etc. to make this a useful suggestion. >> > >> > From: Michael Thomas > >> > To: Torsten Lodderstedt > > >> > Cc: Barry Leiba > >; oauth WG > > >> > Sent: Wednesday, January 4, 2012 3:40 PM >> > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, >> > ends 9 Dec 2011 >> > >> > On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: >> > > Hi Michael, >> > > >> > > Am 04.01.2012 22:06, schrieb Michael Thomas: >> > >> I think the "perhaps unwisely" goes to the heart of my=20 >> objection. You >> > >> might as well be talking about "perhaps unwisely" driving a car, >> > >> or "perhaps unwisely" eating food: the reality is that people=20 >> download >> > >> apps by the *billions*. When I was initially blown off, many of = >> the >> > >> participants including document editors implied that only idiots = >> get >> > >> apps for their phones. That is *completely* unhelpful as the=20 >> reality >> > >> is that OAUTH's use is hugely if not primarily deployed in that=20 >> sort >> of >> > >> environment. >> > > >> > > I fully agree with you. That's why the core spec and the threat >> > document both consider native apps. >> > > >> > >> >> > >> This is a threat that cuts to the very heart of what OAUTH is, an= d >> purports >> > >> to defend against: keeping user credentials out of the hands of a= n >> > >> untrusted third party. If there really aren't any good ways to >> > mitigate this >> > >> in an app environment, why is OAUTH being deployed so aggressivel= y >> there? >> > >> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH= >> > >> IN NATIVE APPS CONSIDERED HARMFUL"? >> > > >> > > You lost me. Is the situation getting any worse with OAuth? I >> > don't think so. I think the situation is getting better, probably >> > not as you might expect. >> > >> > My concern is that putting on a veneer of "security" will lull peopl= e >> into >> > thinking "Oh, it's safe to enter my credentials here because this is= >> really >> > twitterbook, not evilapp!". When I had to ask them directly to put=20 >> their >> > twitterbook credentials into my app, there at least wasn't any=20 >> confusion >> > that I had access to them. >> > >> > Realistically, what you've done is protected the credentials from th= e >> good >> > guys and not changed much for a motivated bad guy. Is that an >> improvement? >> > I'll buy that it's generally bad practice for good guys with most=20 >> likely >> bad >> > security chops to be storing credentials, but I'm guessing that the= >> original >> > OAUTH motivation was more toward thwarting bad guys. >> > >> > > >> > > The key question is: Why do we aim on "keeping user credentials >> > out of the hands of an untrusted third party"? >> > > >> > > 1) To prevent phishing or 2) to prevent leakage of end-user >> > credentials due to inappropriate handling or weak defence on the 3rd= >> party? >> > > >> > > wrt 1) I don't think so. I don't see how an authorization server >> > shall validate the authenticity and trustworthiness of a client-side= >> > application. We already state this in section 4.4.1.4. of the >> threatdocument. >> > >> > The draft says: >> > >> > o Client applications could be validated prior publication in a >> > application market. >> > >> > I asked -- and didn't get a response -- about how exactly that might= >> > be done. I suspect >> > that in practice for the twitterbook universe that there is no way >> > that scales. So the >> > reality here seems to be there isn't an answer for the Internet at >> > large, and the threats >> > document should just say that mitigation MAY be possible in very >> > narrow use cases where >> > code reviews, and other heavy handed analysis can be performed, but >> > for the general case >> > there is no mitigation. >> > >> > As far as 4.4.1.4 goes, I'd say that the counter measures really >> > don't help except >> > maybe for auditing. If that's what they're really about, the draft >> > should make that >> > explicit. >> > >> > Also on the subject of 4.4.1.4, this bullet: >> > >> > >> > o If the authorization server automatically authenticates the end- >> > user, it may nevertheless require some user input in order to >> > prevent screen scraping. Examples are CAPTCHAs or user-specifi= c >> > secret like PIN codes. >> > >> > >> > I'm very skeptical because a native environment is a social >> > engineering nirvana. >> > The CAPTCHA could easily be shown to the user and they'd blissfully >> > solve it just >> > like they do any other one. >> > >> > >> > >> > >> > > >> > > ----------------------- >> > > It is not the task of the authorization server to protect >> > > the end-user's device from malicious software. This is the >> > > responsibility of the platform running on the particular device= >> > > probably in cooperation with other components of the respective= >> > > ecosystem (e.g. an application management infrastructure). =20 >> The sole >> > > responsibility of the authorization server is to control=20 >> access to >> > > the end-user's resources living in resource servers and to=20 >> prevent >> > > unauthorized access to them. >> > > ----------------------- >> > >> > I assume that it's in the authorization server's _interest_ to not >> divulge >> > user credentials to potentially evil third parties. If it's not,=20 >> whywould >> you >> > go to the trouble of implementing OAUTH at all? >> > >> > This is what's so troubling to me. The point is to keep user=20 >> credentials >> away >> > from bad guys, but when shown how OAUTH in widely deployed scenarios= >> fails >> > to do that, the response I get from the working group is "Not Our >> Problem". >> > Well it *is* your problem insofar as you are not advising the >> twitterbooks to >> > disallow native apps as clients, for example. >> > >> > > >> > > wrt 2) Yes, I think that's the reason. And OAuth is a appropriate >> > protocol to achieve this goal, even for mobile apps. Why? >> > > >> > > A typical mobile application consists of the app itself on the >> > device and a corresponding backend service storing user data and >> > implementing business and integration logic. Let's assume this >> > application features address book import from other service >> > providers. W/o OAuth, the app would gather the end-user's credential= >> > for a certain address book service and pass it to its backend >> > service. This service in turn uses this credentials to access the >> > service provider's API. So in such a scenario the following parties >> > get in touch with the user credentials: >> > > - the app >> > > - the app's backend service >> > > - the address book resource server >> > >> > With native mobile apps, the client (=3D app & app backend) isn't it= =20 >> plenty >> > enough to be seriously scary if they can screen scrape the credentia= ls >> > with impunity? What problem was solved again? >> > >> > > >> > > What threats do you see here? And which is most likely to occur? >> > My favorite is an attack against the log files or the database of >> > the backend service in order to obtain the end-users passwords for >> > the resource server. Why? Because the cost/benefit ratio for an >> > attacker is much better then attacking any app installation on a >> > device and the protective measure on the resource server might be >> > more appropriate then on the client side (backend service). >> > >> > Botnets prove that either is a successful business model. This isn't= a >> zero >> > sum game, after all. >> > >> > > OAuth mitigates this kind of attack by reducing the number of >> > parties handling user credentials to the authorization server and >> > the user agent. So even if the app itself would be the user agent >> > (which is not recommended), >> > >> > Not recommended? It's messed up even thinking of it that way. The >> > app is potentially >> > *evil*. It really doesn't care what the IETF RECOMMENDS. If it's >> > useful for it to be the >> > UA, it's going to do just exactly that. >> > >> > > it would directly interact with the authorization server and the >> > app's backend service would use tokens instead of end-user=20 >> credentials. >> > >> > The problem here is the capture of end user credentials. I believe=20 >> that >> OAUTH >> > defends pretty well in the trusted desktop browser scenario it set >> > out to solve >> > for. I do not believe that it does that in the new reality of native= >> > apps, and embedded >> > webviews. >> > >> > | Moreover, the recommended way is to let the app delegate the flow >> > to a trusted system >> > | component on the user's device, such as the system browser or an >> > account manager. In that >> > | case, the 3rd party is not getting in touch with the user >> > credentials at all. >> > >> > Again, the Bad Guys are specifically and completely uninterested in >> > being good and >> > sending it to a trusted component. They will disregard this RECOMMEN= D >> faster >> > than you can type it. >> > > >> > > I think the key question is whether anyone expects OAuth to solve >> > the phishing problem. I don't think this is its main purpose, but it= >> > could facilitate to overcome the habit to enter user credentials >> > everywhere. And this in turn may contribute to the fight against >> phishing. >> > >> > There's much more to this than just phishing. >> > >> > Mike >> > _______________________________________________ >> > 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 > https://www.ietf.org/mailman/listinfo/oauth >