Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Jan 2012 15:18:17 -0800

Barry -- It's now been two weeks and I haven't heard anything to
the objections I raised. It is not my responsibility to come up with
mitigation that works, it's the working group's. If there is no reasonable
mitigation it should just say that.

Mike

On 12/16/2011 06:55 AM, Michael Thomas wrote:
> On 12/16/2011 03:02 AM, Mark Mcgloin wrote:
>> Michael,
>>
>> I will review the comments from Phil where he suggests some changes in
>> section 4.1.4 of the threat model
>>
>> I am unclear exactly what you are proposing. If you want to propose a
>> clearly worded revamp of that section in the next couple of days, I am
>> willing to review and accept legitimate changes. Clearly worded means
>> concise, technically accurate and devoid of alarmist phrases and words used
>> out of context, such as existential. Can I suggest you review with a
>> colleague before posting here.
>
> Barry -- I have gone through this section and made comments
> and was blown off seemingly without reading them at all, and
> now I'm being told to come up with text for which I can be blown
> off again: "Can I suggest you review..."
>
> The fact of the matter is that my comments say that the
> threats are understated and mitigations that are proposed do not
> work. It's not my job alone to fix this. It's the working group's.
> In fact if I were to propose text, it would be along the lines of
> "can't be mitigated" because I do not know how to fix them. If
> nobody else can come up with a better mitigation, then that
> *is* what should be there, not some hand waving nonsense that
> doesn't work.
>
> Mike, "instruct users..." feh
>
>> Regards
>> Mark
>>
>> [email-masked] wrote on 15/12/2011 18:15:45:
>>
>>> From:
>>>
>>> Michael Thomas<[email-masked]>
>>>
>>> To:
>>>
>>> Phil Hunt<[email-masked]>
>>>
>>> Cc:
>>>
>>> Barry Leiba<[email-masked]>, oauth WG<[email-masked]>
>>>
>>> Date:
>>>
>>> 15/12/2011 18:16
>>>
>>> Subject:
>>>
>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
>> 2011
>>> Sent by:
>>>
>>> [email-masked]
>>>
>>> On 12/15/2011 09:54 AM, Phil Hunt wrote:
>>>> Note: one change recommended below...
>>>>
>>>> With regards to 4.1.4…
>>>> 4.1.4.  Threat: End-user credentials phished using compromised or
>>>>           embedded browser
>>>>
>>>>      A malicious application could attempt to phish end-user passwords
>> by
>>>>      misusing an embedded browser in the end-user authorization process,
>>>>      or by presenting its own user-interface instead of allowing trusted
>>>>      system browser to render the authorization user interface.  By
>> doing
>>>>      so, the usual visual trust mechanisms may be bypassed (e.g.  TLS
>>>>      confirmation, web site mechanisms).  By using an embedded or
>> internal
>>>>      client application user interface, the client application has
>> access
>>>>      to additional information it should not have access to (e.g. uid/
>>>>      password).
>>>>
>>>>
>>>> [mat] I think it's also worth mentioning either here, or in another
>>>> threat that there is a further social engineering misuse/attack where
>> an
>>>> app offers/demands to keep your credentials so that you don't have to
>> go
>>>> through the authorization rigmarole. Users are already conditioned to
>>>> give their credentials up to do things -- just this morning I
>>> noticed facebook
>>>> asking for my email password which they promise with sugar on top to
>> not
>>>> store. It might be worth mentioning that things like CAPTCHA could be
>>>> deployed to defend against that sort of attack/misuse.
>>>>
>>>> [Phil] I don't think we need to really add much here. We could
>>> write whole essays on this topic and likely will.
>>>> I think the point is simply to educate the client developer that
>>> there is no need for a client application to ever have access to a
>>> raw uid/password (or any other user credential).
>>>> [/Phi]
>>>>
>>> Remember: I came here not understanding whether this threat was real or
>> not.
>>> A threat document that can't be bothered to elaborate on one of the
>> biggest
>>> existential  threats to the protocol is worthless. The way it is worded
>>> now does
>>> not make it crystal clear that, yes, this means UIWebView's in iPhone
>>> apps, etc too.
>>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH
>>> SERVER.
>>>
>>>
>>>> [snip]
>>>>
>>>>      Countermeasures:
>>>>
>>>>      o  Client developers and end-user can be educated to trust an
>>>>         external System-Browser only.
>>>>
>>>>
>>>> [mat] I assume that this is in here just for the amusement factor
>> because
>>>> it is not a credible countermeasure.
>>>>
>>>> [Phil] I agree, Firefox recently demonstrated how poorly users
>>> recognize the security signals in the browser by dropping the "lock"
>>> icon without announcement. When I found out, I had already been
>>> using it for some time and hadn't noticed.  This counter measure
>>> should be changed to:
>>>> o The OAuth flow is designed so that client applications never
>>> need to know user passwords. Where possible Client applications
>>> SHOULD avoid directly asking for user credentials during an
>>> authorization flow.
>>>> [/Phil]
>>>>
>>> The basic problem here is that the client app is not trusted. So if it's
>>> a bad
>>> actor this admonition will be ignored. If it's a good actor, there
>>> wasn't a threat
>>> in first place. So the mitigation completely misses the mark.
>>>
>>>>      o  Client applications could be validated prior publication in a
>>>>         application market.
>>>>
>>>> [mat] How would this be done in practice?
>>>> [Phil] I think this needs to change to:
>>>>
>>>> o Client applications could be validated for acceptable practices
>>> by the Resource Site provider prior to issuing production Client
>> Credentials.
>>> When, exactly, can we expect to see this in the field? Neither Twitter
>>> or Facebook
>>> do this. And even if they were so inclined, the draft provides exactly
>>> zero guidance
>>> as to what exactly that "validated" might mean in practice. The way I
>>> read this is:
>>> "we don't know how to mitigate this".
>>>> [/Phil]
>>>>      o  Client developers should not collect authentication information
>>>>         directly from users and should instead use redirects to and back
>>>>         from a trusted external system-browser.
>>>>
>>>>
>>>> [mat] How would the resource/authentication server enforce such a
>> thing?
>>>> [Phil] This is a best practice for the client developer. [Phil]
>>>>
>>>>
>>> I don't even know what that means in the context of embedded apps.
>>> Has anybody even tried this? At the very least, an example flow might
>>> be useful for the uninitiated client developer.
>>>
>>> Mike
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 3 Jan 2012 15:46:18 -0800

-1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. 

Phil

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Jan 2012 15:52:54 -0800

> -1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here.

My "responsibility", such as it is, is to bring up that the document's
threat mitigations suggested don't work. I am only a recent and
reluctant participant, versus the principals of this working group
who have been around for many years.

But if you insist, here's my concise suggestion to that points that I
raised objections to:

"No known mitigation exists."

Mike

>
> Phil
>
> On 2012-01-03, at 15:18, Michael Thomas<[email-masked]>  wrote:
>

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 4 Jan 2012 11:42:19 +0000

Hi Michael

Can you clearly word the threat for which this countermeasure (or lack of)
applies

thanks
Mark

Michael Thomas <[email-masked]> wrote on 03/01/2012 23:52:54:

> From:
>
> Michael Thomas <[email-masked]>
>
> To:
>
> Phillip Hunt <[email-masked]>
>
> Cc:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba
> <[email-masked]>, oauth WG <[email-masked]>, "oauth-
> [email-masked]" <[email-masked]>
>
> Date:
>
> 03/01/2012 23:53
>
> Subject:
>
2011
> > -1. I think you should be suggesting alternative text at this
> stage. We all have same responsibilities here.
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 11:38:22 -0800

> Can you clearly word the threat for which this countermeasure (or lack of)

I've already done that in my original last call comments. Given that you
rejected my comments out of hand, it doesn't appear that it was for
lack of clarity.

Mike, rather put off by the attitude of the editors in this wg

>
>
> thanks
> Mark
>
> Michael Thomas<[email-masked]>  wrote on 03/01/2012 23:52:54:
>
>> From:
>>
>> Phillip Hunt<[email-masked]>
>>
>> Cc:
>>
>> <[email-masked]>, oauth WG<[email-masked]>, "oauth-
>> [email-masked]"<[email-masked]>
>>
>> Date:
>>
>> 03/01/2012 23:53
>>
>> Subject:
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 04 Jan 2012 12:47:48 -0700

> Mike, rather put off by the attitude of the editors in this wg

Mike:

In my experience, the IETF tradition is not to passively complain, but
to actively contribute. Thus if I don't like the fact that there's no
specification for some feature or protocol I care about, it's my
responsibility to write an Internet-Draft to fill that gap. Similarly,
if I have concerns about someone else's Internet-Draft, it's incumbent
on me to propose new or alternative text. Sure, I could wait for the
authors, editors, working group chairs, or area directors to take
action, but you will have much greater success if you actively contribute.

Just my gram of silver...

Peter

-- 
Peter Saint-Andre
http://stpeter.im/

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 12:05:21 -0800

> action, but you will have much greater success if you actively contribute.

I am not an IETF noob. The problem here is that I DO NOT KNOW
HOW TO MITIGATE THE THREATS I brought up as inadequately
mitigated in the threat draft. I don't know how I can state that more
plainly. I would *hope* that the participants of this working group who
have been working on this for years could do a better job. But if they
can't then the threat draft should just say that there is no known defense
instead of feel-good things like "educate users".

And I completely disagree that this isn't "active" participation. It
denigrates draft reviewers as being lesser participants. Nor does it
match IETF reality: cross area reviewers typically just point out the
problems and leave it to the working group participants to work it
out. Same goes for an IESG DISCUSS.

Mike

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 4 Jan 2012 20:34:21 +0000

Hi Michael

I have asked you to clearly describe the threat, not the mitigation.

It obviously was either not clear or convincing the first time and I am not
going to start digging through emails when you clearly understand it.

Regards
Mark

Michael Thomas <[email-masked]> wrote on 04/01/2012 20:05:21:

> Peter Saint-Andre <[email-masked]>
>
> Cc:
>
> 04/01/2012 20:07
2011

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Jan 2012 15:41:18 -0500

> going to start digging through emails when you clearly understand it.

To try to shortcut this:
Mike did lay it out clearly, I think, in his first note (which I
linked at the beginning of this thread), and that should be the only
one that needs to be read to understand his point.  The basic point is
that the OAuth framework relies on both the end user and the
authorization server being able to trust the user's UA.  If that winds
up being a compromised browser or a native application that the user
perhaps unwisely installed, all the security in the framework goes out
the window, because an untrustworthy UA can fiddle with pretty much
everything.

Mike's note said much more than that, but I think I've encapsulated
things in an oversimplified version above.  I agree that this is
something that needs to be made very clear... and that I don't see any
way to mitigate it -- it's basically an aspect of what we're working
with here.

I don't think this is a difficult issue to document, and perhaps two
paragraphs should be enough to do it.  Identifying the right place and
the right two paragraphs should be something that a combination of
Mike and the documnet editors can do, if you can do it without getting
on each others' nerves.  :-)

Barry

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 13:06:56 -0800

> perhaps unwisely installed, all the security in the framework goes out
    ^^^^^^^^^
> the window, because an untrustworthy UA can fiddle with pretty much

I think the "perhaps unwisely" goes to the heart of my objection. You
might as well be talking about "perhaps unwisely" driving a car,
or "perhaps unwisely" eating food: the reality is that people 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 reality
is that OAUTH's use is hugely if not primarily deployed in that sort of
environment.

This is a threat that cuts to the very heart of what OAUTH is, and purports
to defend against: keeping user credentials out of the hands of an
untrusted third party. If there really aren't any good ways to mitigate this
in an app environment, why is OAUTH being deployed so aggressively there?
Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH
IN NATIVE APPS CONSIDERED HARMFUL"?

Mike

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 04 Jan 2012 23:14:56 +0100

Hi Michael,

> is that OAUTH's use is hugely if not primarily deployed in that sort of

I fully agree with you. That's why the core spec and the threat document 
both consider native apps.

> 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.

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 threat 
document.

-----------------------
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).  The sole
    responsibility of the authorization server is to control access to
    the end-user's resources living in resource servers and to prevent
    unauthorized access to them.
-----------------------

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

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).

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), it would directly interact with the authorization server 
and the app's backend service would use tokens instead of end-user 
credentials. 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.

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.

regards,
Torsten.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 15:40:18 -0800

On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote:
> I fully agree with you. That's why the core spec and the threat document both consider native apps.
>
>>
> 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 people 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 their
twitterbook credentials into my app, there at least wasn't any confusion
that I had access to them.

Realistically, what you've done is protected the credentials from the 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 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 threat document.

The draft says:

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-specific
       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.

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, why would you
go to the trouble of implementing OAUTH at all?

This is what's so troubling to me. The point is to keep user 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

With native mobile apps, the client (= app & app backend) isn't it plenty
enough to be seriously scary if they can screen scrape the credentials
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 credentials.

The problem here is the capture of end user credentials. I believe 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 RECOMMEND 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

---

From: William Mills <[email-masked]>
Date: Wed, 4 Jan 2012 15:42:56 -0800 (PST)

I think the threat draft should simply say, "OAuth does not and can not protect the user against credential compromise as a result of phishing, malware, social engineering, or machine compromise."

Get rid of the fancy rhetoric, we don't need to explain a lot more than this.  

I don't agree that OAuth purports to solve these problems. What it solves is limiting the credentials granted to allow the user more control and limited damage in the event of credential misuse.

-bill

________________________________
 From: Michael Thomas <[email-masked]>
To: Barry Leiba <[email-masked]> 
Cc: oauth WG <[email-masked]> 
Sent: Wednesday, January 4, 2012 1:06 PM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
 
    ^^^^^^^^^

Mike

---

From: William Mills <[email-masked]>
Date: Wed, 4 Jan 2012 15:50:20 -0800 (PST)

"  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 <[email-masked]>
To: Torsten Lodderstedt <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; oauth WG <[email-masked]> 
Sent: Wednesday, January 4, 2012 3:40 PM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

The draft says:

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 15:58:19 -0800

> I think the threat draft should simply say, "OAuth does not and can not protect the user against credential compromise as a result of phishing, malware, social engineering, or machine compromise."

I could live with something like this, but I think it needs to be much more
explicit that it applies to any authentication service that allows native apps as clients
with no form of strong app vetting. It may even be useful to point to a couple of
large deployments who are at risk from this, like, oh say, twitterbook.

If this draft doesn't take a strong stand against that practice, it's doing nothing
more than giving a wink and a nod that what twitterbook is currently doing is safe.
That's bad, but I suspect it's the elephant in the room.

Mike

> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Michael Thomas <[email-masked]>
> *To:* Barry Leiba <[email-masked]>
> *Cc:* oauth WG <[email-masked]>
> *Sent:* Wednesday, January 4, 2012 1:06 PM
> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
>
> [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 4 Jan 2012 17:05:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Michael Thomas
> Sent: Wednesday, January 04, 2012 3:40 PM

> 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. Second, 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 pattern for over a decade) makes anything worse is patently false.

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 that the end user is solely responsible for the trustworthiness of any native application installed". That is accurate (and completely obvious 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 concerns), I have no objection to such one line added.

And again, to highlight the absurdity of your security claim, it is equally important to warn developers in earthquake-prone countries to put enough distance between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor.

EHL

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 16:39:16 -0800

> And again, to highlight the absurdity of your security claim, it is equally important to warn developers in earthquake-prone countries to put enough distance between the Approve and Deny buttons so…

It's this kind of hostility and ad hominem that leads me to believe that
you have forgotten 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 messenger. Secondly it is *not* the sole responsibility
of the end user: the authentication server absolutely has a part to play
here too. They have to give out client keys, after all, and its their service
that could be hacked. So they have as much if not more responsibility
than the end user.

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

"Native apps, not limited to, but including apps which are available on popular
mobile app stores, have the potential for gaining access to the end user's credentials.
This can be accomplished by gaining access to browser 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 many 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 resource services -- unless the
authentication service can thoroughly vet the trustworthiness of the client. How
that vetting is achieved is outside of the scope of this document, but the current
practice of freely giving client keys to any would-be OAUTH client is not sufficient."

Mike

---

From: William Mills <[email-masked]>
Date: Wed, 4 Jan 2012 17:16:07 -0800 (PST)

> practice of freely giving 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 default experience is likely to be not to spawn a browser for the interaction 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 <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]> 
Cc: oauth WG <[email-masked]>; Barry Leiba <[email-masked]> 
Sent: Wednesday, January 4, 2012 4:39 PM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 04 Jan 2012 17:39:31 -0800

> 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 wh…

So what you're saying is that it's even worse than what I wrote, which
is pretty confining as to what clients an auth server should have a
relationship with. I guess that's progress.

A known client whose client keys are compromised is certainly a threat,
but it at least requires one more step beyond just freely getting client
keys from the auth service. On phone apps with no backend, for example,
it's problematic to keep that key secret, but for clients that have backend
servers it's not as bad. Part of the vetting process could be "clients MUST
NOT store client keys in a program that can be disassembled trivially like
a phone app". This may already be in this draft though, so apologies if
I didn't see it.

I guess I'd rather there not be a blanket MUST NOT -- I hope it doesn't
come down to that -- but they way I'm reading you is that it will come
down to just that.

Mike

> *To:* Eran Hammer-Lahav <[email-masked]>
> *Cc:* oauth WG <[email-masked]>; Barry Leiba <[email-masked]>
> *Sent:* Wednesday, January 4, 2012 4:39 PM
> >> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
> >> Of Michael Thomas

---

From: Mark Mcgloin <[email-masked]>
Date: Thu, 5 Jan 2012 14:01:56 +0000

Having read the suggested wording from Eran, William and Michael, I think
Eran's description is the most succinct and relevant: "OAuth does not
provide any protection against malicious applications and that the end user
is solely responsible for the trustworthiness of any native application
installed"
@William: The threat has been described in the context of installing
malicious apps so the wording above it more applicable
@Michael: It has been repeated many times that we should only address
security issues specific to Oauth, and Oauth does not make things worse if
a user installs a malicious client. If you want to continue the discussion,
please email me directly and we can revert to this forum if you still think
your point is relevant

Section 4.1.4 of the threat model will be updated as below. Remember the
threat model is just offering advice on best practices.

Threat: End-user credentials phished using compromised or  embedded browser

A malicious application could attempt to phish end-user passwords by
misusing an embedded browser in the end-user authorization process, or by
presenting its own user-interface instead of allowing trusted system
browser to render the authorization user interface.  By doing so, the usual
visual trust mechanisms may be bypassed (e.g.  TLS confirmation, web site
mechanisms).  By using an embedded or internal client application user
interface, the client application has access to additional information it
should not have access to (e.g. uid/password).

Impact: If the client application or the communication is compromised, the
user would not be aware and all information in the authorization exchange
could be captured such as username and password.

Countermeasures:

1. The OAuth flow is designed so that client applications never need to
know user passwords. Client applications SHOULD avoid directly asking users
for the their credentials. In addition, end users could be educated about
phishing attacks and best practices, such as only accessing trusted
clients, as OAuth does not provide any protection against malicious
applications and the end user is solely responsible for the trustworthiness
of any native application installed

2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for
OAuth but could include validating that the client application handles user
authentication in an appropriate way

3. Client developers should not write client applications that collect
authentication information directly from users and should instead delegate
this task to a trusted system component, e.g. the system-browser.

Regards
Mark

[email-masked] wrote on 05/01/2012 00:05:04:

> From:
>
> Eran Hammer-Lahav <[email-masked]>
>
> To:
>
> Michael Thomas <[email-masked]>, Torsten Lodderstedt
<[email-masked]>
>
> Cc:
>
> Barry Leiba <[email-masked]>, oauth WG <[email-masked]>
>
> Date:
>
> 05/01/2012 00:05
>
> Subject:
>
2011
> First, end users know nothing about security or OAuth. Second, 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 pattern for over a decade) makes anything worse is patently false.
>
> 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 that the end user is solely responsible
> for the trustworthiness of any native application installed". That
> is accurate (and completely obvious 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 concerns), I have
> no objection to such one line added.
>
> And again, to highlight the absurdity of your security claim, it is
> equally important to warn developers in earthquake-prone countries
> to put enough distance between the Approve and Deny buttons so that
> the user will not accidentally hit Approve during a tremor.
>
> EHL
>
>
>
>
>

---

From: Mark Mcgloin <[email-masked]>
Date: Thu, 5 Jan 2012 14:03:41 +0000

Why do you think this William? Apple does it? Google android market had to
pull 30 apps recently because they contained malware. There are automated
tools that will do some sanity checks on apps and it is only advice, i.e.
'could'

Mark

> William Mills <[email-masked]>
>
> 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.
>
> > 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.
>
> > 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.
> user credentials to potentially evil third parties. If it's not, whywould
you
> > 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
> > 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).
>
> > 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),
>
> > it would directly interact with the authorization server and the
> app's backend service would use tokens instead of end-user credentials.
>
> > 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.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 05 Jan 2012 07:27:08 -0800

The wording you propose is unacceptable. It is a rehash of the
same misleading nonsense that is in there now. In particular #1 and
#3 that say in effect "bad guys really should be good" are silly
and unhelpful. #2 has possibilities, but in its current form gives
absolutely no guidance as to what might be done; mine at least
explicitly said that the status quo is unacceptable.

I also completely object to the notion that the authentication
service has no part in protecting itself. It has complete control
over who it allows to register as a client, and as written Eran's
text contradicts #2's possibility of mitigation -- even if William
thinks it's hopeless (as I read him). If William is right the
appropriate guidance is that authentication services MUST NOT
enroll clients that use untrusted browsers. Putting this on the
end users shoulders is useless and should be a reason that the
IESG should just reject the protocol.

I also object to not *explicitly* pointing out that native apps
mean apps from App stores, markets,  etc. and the general problem
that users cannot know a priori whether an app is malicious or not. I
don't  see why this is even controversial -- unless your aim is to hide
that uncomfortable fact.

This is a threat document, not a marketing puff piece. Downplaying
threats does nobody any good. Except bad guys.

Mike

On 01/05/2012 06:01 AM, Mark Mcgloin wrote:
>> Eran Hammer-Lahav<[email-masked]>
>>
>> To:
>>
>> Michael Thomas<[email-masked]>, Torsten Lodderstedt

---

From: Justin Richer <[email-masked]>
Date: Thu, 5 Jan 2012 10:54:32 -0500

I'm OK with the threat document including a line this this, or Eran's 
proposed text, in the introduction to what OAuth can and can't do. It's 
important to set scope appropriately. (and I am very sorry for that pun)

However, the contention about native apps that Mike brings up is 
misleading for one key reason: if the user's browser is compromised 
(which is the attack vector in question), then all OAuth-backed webapps 
will *also* be compromised, since the bad party can just grab the data 
on its way to the screen. And if the user downloads malware masquerading 
as a good app (which OAuth *can* protect against by using client secrets 
in some circumstances and trusted callback urls in others), and they 
approve the bad app, then they're hosed too.

So, no, OAuth won't protect you against malware-infested browsers or 
against phishing. It significantly reduces but does not eliminate 
security threats, and (a point that hasn't been brought up) it 
significantly eases the cleanup burden on users and service providers in 
the case of a breach. If this really is a confusing point to people, we 
can say that in the threat document, and Bill's text would do that, 
without the addendum about native clients. I believe that the native 
client text that speaks about embedded vs. external browsers is already 
clear on this matter -- but if someone has better text (as in, 
"paragraph X should say the following exact words", not "it needs to be 
better"), then we can incorporate it.

Even so, I do think it's clear from what text we already have. It would 
be superfluous but not burdensome to add extra text into the threat 
model document (not core) as has been proposed here by Bill and 
previously be Eran.

  -- Justin

On 01/04/2012 06:58 PM, Michael Thomas wrote:
>> I think the threat draft should simply say, "OAuth does not and can 
>> not protect the user against credential compromise as a result of 
>> phishing, malware, social engineering, or machine compromise."
>
>> I don't agree that OAuth purports to solve these problems. What it 
>> solves is limiting the credentials granted to allow the user more 
>> control and limited damage in the event of credential misuse.
>>
>> -bill
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
> --

---

From: Michael Thomas <[email-masked]>
Date: Thu, 05 Jan 2012 08:21:48 -0800

On 01/05/2012 07:54 AM, Justin Richer wrote:
>
> However, the contention about native apps that Mike brings up is misleading for one key reason: if the user's browser is compromised (which is the attack vector in question), then all OAuth-backed webapps will *also* be compromised, since the bad party can just grab the data on its way to the screen. And if the user downloads malware masquerading as a good app (which OAuth *can* protect against by using client secrets in some circumstances and trusted callback urls in others), and they approve the bad app, then they're hosed too.

There's a big difference between a compromised browser and a native app with
an embedded browser. The first is considered harmful and browsers already take
steps to insure they do not remain infected through updates, etc. The second is
working as intended.

| Even so, I do think it's clear from what text we already have.

Remember: the reason that I am here at all is precisely because it was *not*
clear. It's why I find the belligerence I've been afforded from the beginning
so mystifying.

Mike

---

From: William Mills <[email-masked]>
Date: Thu, 5 Jan 2012 08:29:02 -0800 (PST)

There's going to be a whole class of apps tat will be in violation of "Client applications SHOULD avoid directly asking users for the their 
credentials.".  We know that already, because the password grant exists 
and we have real use cases for it.  I think we should strikes that 
sentence and move that idea to #3 (soon to be #2)

I think point 2 should be struck, it's pointless.  What would matter here is whether the user can check that the app has been validated, and 
we're not defining that.

I would change #3 (now #2?) to:
   3. It is RECOMMENDED that client applications use the web based authentication 
   flow, this takes advantage of a more trusted system component, e.g. the system 
   browser, and provides a consistent authentication experience for the user
   across applications.  The user is then always presenting their credential to a
   known and trusted web page.  Collection and use of primary authentication from
   the user by client applications is NOT RECOMMENDED.

Regards,

-bill

P.S. hit the wrong key earlier and replied only to Mark with this.  Should have hit the list.  Sorry Mark.

________________________________
 From: Mark Mcgloin <[email-masked]>
To: OAuth WG <[email-masked]> 
Sent: Thursday, January 5, 2012 6:01 AM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

Countermeasures:

Regards
Mark

2011

---

From: William Mills <[email-masked]>
Date: Thu, 5 Jan 2012 08:37:39 -0800 (PST)

It relies on the marketplace to do this.  The current model is that apps are not validated first, they are pulled if found to be hostile.   You're making a recommendation here about how an app marketplace should behave to be trustworthy, and I think that's beyond the scope of users and client developers here.  We're already saying users should only install trustworthy applications.

________________________________
 From: Mark Mcgloin <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; Michael Thomas <[email-masked]>; oauth WG <[email-masked]>; [email-masked]; Torsten Lodderstedt <[email-masked]> 
Sent: Thursday, January 5, 2012 6:03 AM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

Mark

party?
threatdocument.
you
phishing.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 05 Jan 2012 08:48:07 -0800

> It relies on the marketplace to do this.  The current model is that apps are not validated first, they are pulled if found to be hostile.   You're making a recommendation here about how an app mark…

First, asking users to only install "trustworthy" application is a completely
useless recommendation: how do they know? How does anybody on this
list know, in fact?

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 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

> *From:* Mark Mcgloin <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* Barry Leiba <[email-masked]>; Michael Thomas <[email-masked]>; oauth WG <[email-masked]>; [email-masked]; Torsten Lodderstedt <[email-masked]>
> *Sent:* Thursday, January 5, 2012 6:03 AM
> > William Mills <[email-masked] <mailto:[email-masked]>>
> >
> > From: Michael Thomas <[email-masked] <mailto:[email-masked]>>
> > To: Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>
> > Cc: Barry Leiba <[email-masked] <mailto:[email-masked]>>; oauth WG <[email-masked] <mailto:[email-masked]>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 05 Jan 2012 12:11:15 -0500

The problem is that even if the Authorization Server only gives out 
credentials to "trusted clients", those clients can be "hacked" and the 
credentials compromised allowing for impersonation of the "trusted 
client". Obviously, protecting the credentials is easier if the client 
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 
desktop applications and mobile applications also need access to the 
user's protected resources. The issue here is that clients (in the vast 
majority of cases) can't be trusted.

This means that all rich desktop/mobile app models currently in the 
field are flawed (if we are trying to protect the user from a malicious 
client). OAuth is specifically NOT trying to solve the "client 
trustworthiness" problem. Personally, I don't see how to solve this 
problem without "trusted hardware" in the client and that isn't yet 
widely deployed.

However, as others have pointed out, OAuth doesn't make the existing 
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 
improves for the user, because their credentials are stored in fewer 
places. It might even push the "bad guys" to having to implement 
malicious apps as other methods of getting the user's credentials are 
significantly reduced.

 From a threat model perspective, while OAuth doesn't solve this 
specific threat, the use of OAuth overall improves the security of the user.

My 2 cents:)

On 1/5/12 11:48 AM, Michael Thomas wrote:
>> *Cc:* Barry Leiba <[email-masked]>; Michael Thomas 
>> <[email-masked]>; oauth WG <[email-masked]>; [email-masked]; 
>> Torsten Lodderstedt <[email-masked]>
>> > Cc: Barry Leiba <[email-masked] 
>> <mailto:[email-masked]>>; oauth WG <[email-masked] 
>> <mailto:[email-masked]>>
>> > >> is that OAUTH's use is hugely if not primarily deployed in that 
>> sort
>> of
>> > >> environment.
>> > >
>> > I'll buy that it's generally bad practice for good guys with most 
>> likely
>> bad
>> > This is what's so troubling to me. The point is to keep user 
>> credentials
>> away
>> > The problem here is the capture of end user credentials. I believe 
>> that
>> OAUTH

---

From: Mark Mcgloin <[email-masked]>
Date: Mon, 16 Jan 2012 13:52:41 +0000

Hi William

Sorry for slow response - comments inline below.

I really would like to close out on this set of countermeasures. I think
the differing opinions are subjective as this point and we all need to bear
in mind that the threat model is intended to advise on best practices and
not all of those will be applicable to all developers

Regards
Mark

2011
>
> There's going to be a whole class of apps tat will be in violation
> of "Client applications SHOULD avoid directly asking users for the
> their credentials.".  We know that already, because the password
> grant exists and we have real use cases for it.  I think we should
> strikes that sentence and move that idea to #3 (soon to be #2)
>

The resource owner password credentials is intended for clients with trust
relationships with the resource server, mainly intranet apps. For all other
cases, client apps should use Oauth as it was intended, i.e. to avoid the
anti-pattern of asking users for credentials.

> I think point 2 should be struck, it's pointless.  What would matter
> here is whether the user can check that the app has been validated,
> and we're not defining that.

Agree that this countermeasure applies whether the app uses oauth or not
and because this threat is getting side tracked into advising on non-oauth
specific threats/countermeasures (i.e. user downloads malicious client)
It is just a suggestion, i.e. 'could', and may not apply to all
marketplaces. If the market place, such as apple, says the app has been
validated, then the user knows. You state elsewhere:

> "The current model is that apps are not validated first, they are pulled
if found to be hostile.   You're making a > recommendation here about how
an app marketplace should behave to be trustworthy, and I think that's
beyond the
> scope of users and client developers here.  We're already saying users
should only install trustworthy applications."

Again, it is just a suggestion. It may apply to some marketplaces more than
others, e.g. where the clients are accessing resources also under control
of the marketplace. Recommendations are aimed at resource server and
authorization server developers too.

>    the user by client applications is NOT RECOMMENDED.

I don't agree that your wording clarifies anything

Countermeasures:

---

From: Michael Thomas <[email-masked]>
Date: Mon, 16 Jan 2012 08:03:54 -0800

> Countermeasures:

First off the title: it says Countermeasures. Therefore, anything here
must be a real and meaningful "countermeasure".

> for the their credentials.

This is not a countermeasure. It is a request that bad guys be good.

Strike it entirely.

> In addition, end users could be educated about

This is not a credible countermeasure. End users know nothing
about this, and I'd venture to say that includes you and me too.

Strike it entirely.

> authentication in an appropriate way

This may be a valid countermeasure, but there needs to be some
reason to believe that it is not just a hope and a prayer put here
just to feel good.

If it cannot be substantiated, strike it entirely.

> this task to a trusted system component, e.g. the system-browser.

This is not a valid countermeasure. It expects bad guys to be good.

Strike it entirely.

Mike