Subject: [OAUTH-WG] problem statement

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 10:40:53 -0700

Hi all,

Barry suggested that I might subscribe and explain what I sent him.

My basic problem is that in neither the protocol nor the threats drafts,
I can't seem to find what problem is actually trying to be solved with
oauth, and what assumptions you're making about various elements.

Here's what I did. I've written an app, and I wanted re-integrate the
ability to send tweets after they deprecated Basic. So the app has a
webView (android, iphone...) which it obviously completely controls.
With oauth, the webview UA will ultimately redirect off to Twitter's
site to collect the user's credentials and grant my app's backend an
access token (sorry if I get terminology screwed up, i'm just coming
up to speed).

What occurs to me is that webview affords exactly zero protection from
my client (ie, the app) from getting the user's twitter credentials. All
I have to do is set up a keypress handler on that webview and in a few
minutes of hacking I have a key logger. etc.

So what I can't tell is whether this is a "problem" or not, because I
don't know what problem you're trying to solve. If the object of oauth
isn't to keep user/server credentials out of the hands of a third party,
then what is it trying to solve? Is there an expectation that the
UA is trusted by the user/server? What happens when that's not the case?

Regardless of whether I'm misunderstanding, it would sure be nice to have
both the problem and your assumptions laid out, hopefully with some prominence
so you don't get these sort of dumb questions.

Mike

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 14:10:02 -0400

Mike,

You've got the problem statement right: allowing the user to authorize  
resource access to another party without divulging user's credentials is 
the objective of OAuth. You are also right in that the attack you have 
described defies the whole purpose of OAuth.  I do not think though that 
it is related to OAuth per se.

To this end, the security work led by Torsten has thoroughly analyzed 
the protocol and specified protection against multiple protocol 
attacks.  From what you described, it appears to me that the attack you 
mention is not related to the protocol but rather to the user's 
environment.  There is no possible protection from key loggers that a 
protocol can implement. I could be mistaken; in any case, it looks like 
the problem rests with the implementation of WebView.

If I am wrong, I would appreciate a detailed description of what happened.

Igor

On 9/6/2011 1:40 PM, Michael Thomas wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Paul Madsen <[email-masked]>
Date: Tue, 06 Sep 2011 14:12:43 -0400

that is the original problem statement, but surely no longer the only one

On 9/6/11 2:10 PM, Igor Faynberg wrote:
> Mike,
>
> You've got the problem statement right: allowing the user to 
> authorize  resource access to another party without divulging user's 
> credentials is the objective of OAuth. You are also right in that the 
> attack you have described defies the whole purpose of OAuth.  I do not 
> think though that it is related to OAuth per se.
>
> attacks.  From what you described, it appears to me that the attack 
> you mention is not related to the protocol but rather to the user's 
> protocol can implement. I could be mistaken; in any case, it looks 
> like the problem rests with the implementation of WebView.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 11:14:25 -0700

I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. 

EHL

---

From: John Kemp <[email-masked]>
Date: Tue, 6 Sep 2011 14:15:47 -0400

Michael,

> minutes of hacking I have a key logger. etc.

If an attacker is able to log key presses from a "webview" created by your app with their own app/library, then this is a threat to the user's credentials, yes.

> don't know what problem you're trying to solve.

Broadly-speaking, the "problem" to be solved is to avoid the requirement for a user to share her username/password at one web application with another. OAuth is similar in that regard to Kerberos or SAML - a "ticket" system. 
 
> If the object of oauth
> UA is trusted by the user/server?

Not in all cases, no. It depends on which OAuth "flow" you use for your application. In general, I would say that the UA is NOT to be trusted by the user/server.

> What happens when that's not the case?
> 

One point I would mention first is that your question isn't dumb ;) 

But, as I noted, OAuth seeks to avoid the requirement for a user to share her username/password at one web application with another. That being said, there are lots of ways to get that wrong, and the way of resolving those is to implement OAuth-based applications using the security features available in their specific environments, as these vary quite a lot. OAuth provides a number of different protocol flows to help with that, and "security considerations" that discuss known security threats within various environments. By careful reading, you can determine which flow is appropriate for your application, and which security features should be used to avoid the threats to your application.

Regards,

- John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:17:39 -0700

> the problem rests with the implementation of WebView.

There is no problem with the webview; it's working completely as intended.
An embedded webview is not a fortress for the sake of the user/server, it's
a UI element that can be manipulated by an app. And even if Android, say,
did try to make keyboard logging impossible, I could always create my own
webview UA that allowed me to log keystrokes after it rendered the server's
login page.

So it appears that there is an implicit expectation that the UA is "trusted".
Well, here's a case where that's not the case. Can the server tell the difference?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:23:14 -0700

> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to cha…

How, exactly, is the user supposed to protect themselves against rogue apps?
It sounds like the solution is to tell them to never use oauth in an app at all.

Is oauth only intended to be used on standalone trustable web browsers? I don't recall
seeing that anywhere.

Mike

---

From: William Mills <[email-masked]>
Date: Tue, 6 Sep 2011 11:26:51 -0700 (PDT)

> How, exactly, is the user supposed to protect themselves against rogue apps?

Don't install them.

________________________________
From: Michael Thomas <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tuesday, September 6, 2011 11:23 AM
Subject: Re: [OAUTH-WG] problem statement

Mike

>> You've got the problem statement right: allowing the user to authorize  resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth.  I do not think though that it is related to OAuth per se.
>> 
>> To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks.  From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment.  There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView.
>>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:28:31 -0700

> But, as I noted, OAuth seeks to avoid the requirement for a user to share her username/password at one web application with another. That being said, there are lots of ways to get that wrong, and t…

So to take this back to the concrete (I'm new here, so abstractions are hard): are you saying that Twitter
got it wrong? My app can't be the one that's wrong because my app is the potential attacker. If it was
Twitter, what did they do wrong? If not, who got what wrong that allows this situation to occur?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:30:01 -0700

>  > How, exactly, is the user supposed to protect themselves against 

Will they be marked with rfc 3514?

Mike

> 
> *From:* Michael Thomas <[email-masked]>
> *To:* Eran Hammer-Lahav <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, September 6, 2011 11:23 AM
> *Subject:* Re: [OAUTH-WG] problem statement
> 
> Eran Hammer-Lahav wrote:
>  > I agree. If you are going to install a native app, you better trust 
> it not to do bad things. Grabbing your password is the least interesting 
> thing such an app can abuse. I don't see any need to change the v2 draft.
> 
>  > On Sep 6, 2011, at 11:10, "Igor Faynberg" 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  >
>  >> Mike,
>  >>
>  >> To this end, the security work led by Torsten has thoroughly 
> analyzed the protocol and specified protection against multiple protocol 
>  >>> [email-masked] <mailto:[email-masked]>
>  >> [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 11:29:47 -0700

Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. 

If there was a solution to this we would not need an antivirus. 

EHL

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:34:57 -0700

> If there was a solution to this we would not need an antivirus. 

How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in
general? I don't think that apple and google are going to close up shop because it breaks oauth's
trust model.

Mike

---

From: William Mills <[email-masked]>
Date: Tue, 6 Sep 2011 11:44:37 -0700 (PDT)

OAuth doesn't solve this problem, and can't.  Generally the question is whether the app appears to come from a reputable source, and nowadays whether it's signed (in windows land) or otherwize certified by the provider.

If you manage to solve this problem in a real way I'd be interested in investing in your company.

Sent: Tuesday, September 6, 2011 11:34 AM

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 11:46:53 -0700

I'm dismissive of this being an OAuth problem. 

EHL

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Sep 2011 14:48:55 -0400

Mike,

The basic argument here is that if the app wants to do bad things, and
you go through the process of authorizing it, it's going to be able to
do bad things. Not just to your stolen credentials, either, since it's
now got an access token too.

OAuth's trust model does work with installed applications -- however,
there are several caveats. This is one of them, as is the fact that they
can't be shipped with secured secrets (ie, client secrets). And it's
exactly this acquiescence to their limitations that opens the way for
things like the username/password flow in OAuth2. In this flow, the app
just asks for the user's username and password directly and exchanges
them for an access token. There is still a distinction from logging in
directly with the user's credentials to the API endpoint though. First,
the user's credentials don't get tossed out onto the wire with every
request. This lessens the susceptibility to theft in transmission.
Second, the app doesn't *have* to store the credentials. After the first
step goes through and the app gets a token, it can toss them. That way
nobody can steal the credentials out of an on-disk store after the fact.
If it wants to hang on to them, then yeah, you're absolutely right -- it
has your credentials and you're hosed. But nothing in the OAuth protocol
is going to force a misbehaving application to not do that. Just like
nothing in the OAuth protocol is going to stop phishing attempts to look
like the Twitter login screen. 

A solution to not letting an app steal your credentials is to not use
credentials in the first place and to use things like a rotating token
or a client-side certificate instead of a username/password to
authenticate the user during the authoirzation flow. Since OAuth doesn't
care how the user authenticates in the verification code flow, you don't
even have to change your client code. We actually had this happen
locally when developers moved from one environment that used
username/password and into another that used OpenID. The OAuth code
didn't change at all between them.

But ultimately, a bad app is going to be a bad app, and you need to be
careful what software you run and where you type your password. I think
it's a mistake of this group to flippantly ignore the threat, but at the
same token this reality does not make the OAuth protocol or its
underlying model useless.

 -- Justin

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:50:13 -0700

William Mills wrote:
> OAuth doesn't solve this problem, and can't.  Generally the question is 
> whether the app appears to come from a reputable source, and nowadays 
> whether it's signed (in windows land) or otherwize certified by the 
> provider.
> 

Then what I don't see anywhere is that oauth is not applicable to embedded
web objects, and that end users should *never* trust oauth in a, say, phone
app. As far as I can tell, the server deploying oauth can't tell that it's
being misused, so this is all on the shoulders of the end user.

It sure looks like oauth is easily subverted in the real world.

Mike

> 
> ------------------------------------------------------------------------
> *Sent:* Tuesday, September 6, 2011 11:34 AM
>  > Don't install crap on you device or computer. OAuth is the least of 
> your concern if you install bad software.
>  > On Sep 6, 2011, at 11:23, "Michael Thomas" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  >
>  >> Eran Hammer-Lahav wrote:

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 11:58:11 -0700

> I'm dismissive of this being an OAuth problem. 

Which brings us back to my original problem: what is the problem it's trying to solve?
What are the assumptions it makes? What is its applicability? None of those are addressed
very well if at all in the drafts. I'm sure that I'm not the only one who would be very
surprised to hear that using oauth on a phone app is a bad idea.

Put it this way: your favorite example of a photo printing service needing access to flickr.
It's ok if you do that from a browser, but not if the photo printer makes an app. How many users,
exactly, are going to know that they shouldn't do the second one?

I think that's an oauth problem because oauth makes it *seem* like you're protected from
the third party, whereas if the app itself asked for your login credentials there would
be far less confusion. So in that sense, oauth is making things worse, not better.

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 11:57:22 -0700

Framing this as an OAuth issue is wrong. In your scenario:

1. Install bad app
2. Do protocol X
3. Bad things happen

X can be anything. For example, the app can add a root cert to your os and break TLS protection. 

EHL

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 12:03:15 -0700

> Framing this as an OAuth issue is wrong. In your scenario:

No. It's

1. Install app.

Users don't know which are which. Have you ever used oauth through a phone app? How
did you determine it wasn't evil? The yahoo guy here apparently has lots of money
if you can tell him too.

Mike

---

From: Jill Burrows <[email-masked]>
Date: Tue, 6 Sep 2011 12:11:59 -0700

Mike,

Let me say this:

If I hired a developer to write an app for me for, I would expect that
developer to not implement a key logger or anything that could damage my
company's reputation down the line. If I reviewed the code and found
something suspicious, I would terminate their contract.

Generally, companies who care about their brand and reputation implement
trusted applications. There are times when they may contract with people who
are shady, but they will find out later once the damage is done that they
needed to do more research and hire someone who could be trusted to not
injure their brand. If that company's brand suffered, I would hope they sued
the developer for damages to teach that shady developer a lesson.

It is definitely up to people to choose what they install on their devices.
If they randomly install malicious software, I'm sure that getting
credentials to an OAuth enabled site is the least of what they could do.
Someone could write an app for anything, like a bank and steal the users
credentials for that. It doesn't matter the protocol involved if the
application or website, is made to do something malicious.

People who are susceptible to installing non-trusted applications might also
suffer from a rootkit infestation -- in which case, their social media
credentials might be the least of their worries, since all of the
information on their device would be available to the writer of the rootkit.

I repeat, it is not an OAuth problem.

Perhaps, companies that implement OAuth servers for their service should
remind developers and users what to expect with OAuth on their service. As
for as I know, it is not in the scope of the OAuth specification to clearly
state things which are entirely dependent on a certain services
implementation of OAuth.

-Jill

On Tue, Sep 6, 2011 at 12:03 PM, Michael Thomas <[email-masked]> wrote:

>>>  ------------------------------**------------------------------**
>>>> ------------
>>>>>> it not to do bad things. Grabbing your password is the least
>>>> interesting thing such an app can abuse. I don't see any need to change the
>>>> v2 draft.
>>>>
>>>>> How, exactly, is the user supposed to protect themselves against
>>>>>>
>>>>> rogue apps?
>>>>
>>>>> It sounds like the solution is to tell them to never use oauth in an
>>>>>>
>>>>> app at all.
>>>>
>>>>> Is oauth only intended to be used on standalone trustable web
>>>>>>
>>>>> browsers? I don't recall
>>>>
>>>>> seeing that anywhere.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>  EHL
>>>>>>>
>>>>>> <igor.faynberg@alcatel-lucent.**com<[email-masked]><mailto:
>>>> igor.faynberg@alcatel-**lucent.com <[email-masked]>>>
>>>> wrote:
>>>>
>>>>> Mike,
>>>>>>>>
>>>> credentials is the objective of OAuth. You are also right in that the attack
>>>> you have described defies the whole purpose of OAuth.  I do not think though
>>>> that it is related to OAuth per se.
>>>>
>>>>>>> analyzed the protocol and specified protection against multiple
>>>> protocol attacks.  From what you described, it appears to me that the attack
>>>> protocol can implement. I could be mistaken; in any case, it looks like the
>>>> problem rests with the implementation of WebView.
>>>>
>>>>> If I am wrong, I would appreciate a detailed description of what
>>>>>>>>
>>>>>>> happened.
>>>>
>>>>> Igor
>>>>>>>>
>>>>>>>>> My basic problem is that in neither the protocol nor the threats
>>>>>>>>>
>>>>>>>> drafts,
>>>>
>>>>> I can't seem to find what problem is actually trying to be solved
>>>>>>>>>
>>>>>>>> with
>>>>
>>>>>>>>> What occurs to me is that webview affords exactly zero protection
>>>>>>>>>
>>>>>>>> from
>>>>
>>>>> my client (ie, the app) from getting the user's twitter
>>>>>>>>>
>>>>>>>> credentials. All
>>>>
>>>>> I have to do is set up a keypress handler on that webview and in
>>>>>>>>>
>>>>>>>> a few
>>>>
>>>>>>>>> don't know what problem you're trying to solve. If the object of
>>>>>>>>>
>>>>>>>> oauth
>>>>
>>>>> isn't to keep user/server credentials out of the hands of a third
>>>>>>>>>
>>>>>>>> party,
>>>>
>>>>>>>>> UA is trusted by the user/server? What happens when that's not
>>>>>>>>>
>>>>>>>> the case?
>>>>
>>>>> Regardless of whether I'm misunderstanding, it would sure be nice
>>>>>>>>>
>>>>>>>> to have
>>>>
>>>>> both the problem and your assumptions laid out, hopefully with
>>>>>>>>>
>>>>>>>> some prominence
>>>>
>>>>>>>>> ______________________________**_________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>>>
>>>>>>>> ______________________________**_________________
>>>>>>>> OAuth mailing list
>>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>>
>>>>>>> ______________________________**_________________
>>>>>>> OAuth mailing list
>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>
>>>>>> ______________________________**_________________
>>>> OAuth mailing list
>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>>>
>>>>
>>>>
> ______________________________**_________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>

-- 
Thanks,

Jill Burrows
CTO / Lead Technologist - uLynk
Consultant / Technologist - Creative Sagacity
+1 503 208 5455
[email-masked]
http://adaburrows.com
@jburrows (http://twitter.com/jburrows)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 12:14:23 -0700

You are one making the argument that no one should be installing apps.

There is no known way to stop users from installing malware and viruses other than not letting them install anything off a whitelist. The problem you are describing has nothing to do with OAuth, its a fundamental problem with running untrusted code on your devices. Once you do that, yes, OAuth can be exploited but that's true for every authentication scheme when one side is compromised.

My point, which you seems to miss, is that the same argument can be made against any other protocol. TLS offers your certain protections but they are all gone if you install a bad native app – following your logic people should not use TLS in apps either.

I do not consider this an issue.

EHL

From: Michael Thomas <[email-masked]<mailto:[email-masked]>>
Date: Tue, 6 Sep 2011 11:58:11 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote:

Mike

EHL
On Sep 6, 2011, at 11:35, "Michael Thomas" <[email-masked]<mailto:[email-masked]>> wrote:
Eran Hammer-Lahav wrote:
Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software.

Mike

EHL

On Sep 6, 2011, at 11:23, "Michael Thomas" <[email-masked]<mailto:[email-masked]>> wrote:

Eran Hammer-Lahav wrote:

Mike

EHL

On Sep 6, 2011, at 11:10, "Igor Faynberg" <[email-masked]<mailto:[email-masked]>> wrote:

Mike,

Igor

Regardless of whether I'm misunderstanding, it would sure be nice to have
both the problem and your assumptions laid out, hopefully with some
prominence
so you don't get these sort of dumb questions.

Mike
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aiden Bell <[email-masked]>
Date: Tue, 6 Sep 2011 20:17:19 +0100

I agree. This is like saying SSL has an issue because it doesn't stop
keyloggers.

Not an oauth issue.

sent from my android phone
On Sep 6, 2011 8:14 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:
> There is no known way to stop users from installing malware and viruses
other than not letting them install anything off a whitelist. The problem
you are describing has nothing to do with OAuth, its a fundamental problem
with running untrusted code on your devices. Once you do that, yes, OAuth
can be exploited but that's true for every authentication scheme when one
side is compromised.
>
> My point, which you seems to miss, is that the same argument can be made
against any other protocol. TLS offers your certain protections but they are
all gone if you install a bad native app – following your logic people
should not use TLS in apps either.
> Cc: "[email-masked]<mailto:
[email-masked]>" <[email-masked]<mailto:
[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>
> I agree. If you are going to install a native app, you better trust it not
to do bad things. Grabbing your password is the least interesting thing such
an app can abuse. I don't see any need to change the v2 draft.
> On Sep 6, 2011, at 11:10, "Igor Faynberg" <
[email-masked]<mailto:[email-masked]>>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Sep 2011 11:18:18 -0800

> I repeat, it is not an OAuth problem.

If I'm reading Mike correctly (and if I'm not it won't be the
first time I've misunderstood him), he's not really asking for
OAUTH to solve this particular problem but to clarify the
documents and beef up discussions of what is and is not in
scope.  He read the document and couldn't figure out whether
or not this particular problem is the business of the working
group.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 12:22:15 -0700

Eran Hammer-Lahav wrote:
> other than not letting them install anything off a whitelist. The 
> problem you are describing has nothing to do with OAuth, its a 
> fundamental problem with running untrusted code on your devices. Once 
> you do that, yes, OAuth can be exploited but that's true for every 
> authentication scheme when one side is compromised.
> 
> against any other protocol. TLS offers your certain protections but they 
> are all gone if you install a bad native app – following your logic 
> people should not use TLS in apps either.

I haven't missed the issue. OAuth is fundamentally trying to make an assertion
that it protects you from third party snooping. Except that it doesn't in some
large use cases. As far as I can tell that's not documented anywhere. How many
oauth server-owners know that their users have this vulnerability?

> I do not consider this an issue.

That's the real problem here.

Mike

> 
> EHL
> 
> From: Michael Thomas <[email-masked] <mailto:[email-masked]>>
> To: Eran Hammer-lahav <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] 
> <mailto:[email-masked]>" 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>                 Don't install crap on you device or computer. OAuth is
>                 the least of your concern if you install bad software.
> 
>                 On Sep 6, 2011, at 11:23, "Michael Thomas"
>                 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                     Eran Hammer-Lahav wrote:
> 
>                         I agree. If you are going to install a native
>                         app, you better trust it not to do bad things.
>                         Grabbing your password is the least interesting

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 12:22:17 -0700

I understood his request and disagree that any action needs to be taken. It is unreasonable to expect every protocol to discuss the security considerations of a user installing malware.

EHL

From: Melinda Shore <[email-masked]<mailto:[email-masked]>>
Date: Tue, 6 Sep 2011 12:18:18 -0700
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] problem statement

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 12:28:41 -0700

> or not this particular problem is the business of the working

I'm fairly certain that if somebody were deploying oauth for their servers
that unless the document told me that oauth doesn't provide protection
against third party snooping if it's embedded in any app, most people wouldn't
have a clue that that was a dangerous assumption.

What this says is that oauth only works in one use case, and that only the
user can tell the difference. Given the proliferation of phone apps and
embedded webviews, it seems that the original assumptions of oauth are
no longer up to date.

Mike

---

From: Aiden Bell <[email-masked]>
Date: Tue, 6 Sep 2011 20:36:26 +0100

I'm pretty sure anyone charged with implementing the oauth protocol should
be able to make a fairly informed judgement about what oauth does and
doesn't do and the implications of that scope. Like all security, it is
about layers ... And oauth isn't all layers. That's obvious.

I don't think writing about that helps the spec too much, past saying "oauth
isn't a one stop shop for end to end security"

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 12:36:21 -0700

Eran Hammer-Lahav wrote:
> I understood his request and disagree that any action needs to be taken. 
> It is unreasonable to expect every protocol to discuss the security 
> considerations of a user installing malware.

If you could find an equivalent attack on, oh say, DKIM, I'd say yes you
should discuss it. OAuth is a user-facing protocol. That means that users
will be using it. It absolutely guarantees you that hackers will hack it.
In the case of embedded webviews, oauth makes the malware situation worse
from what I can tell.

Mike

> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Sep 2011 15:36:49 -0400

Mike,

I think this is a red herring. as this vector has nothing to do with
mobile apps. The attack that you've suggested is also possible with a
compromised browser on a desktop using the web flow. In this case, the
browser (UA) can steal the user's credentials and hand them to whoever
they want to when the user gets redirected. It doesn't have to be the
OAuth client that's phishing the credentials, after all. 

OAuth *does* work with phone apps, and it's a misnomer to say that it's
not a good idea in such environments. In all cases, you have to trust
the user agent and all of the mechanisms that let the user log into the
host site. But you have to do that in order to let the user log into the
host site at all. Fixing that is a larger problem for the web as a whole
and ultimately outside of OAuth.

 -- Justin

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 15:40:21 -0400

On 9/6/2011 2:23 PM, Michael Thomas wrote:
> ...
>  ...

There are a number of ways: 1) Buy shrink-wrapped software only, 2) 
Inspect the source code of every application, etc...  The mobile network 
providers solve this problem by allowing ONLY applications signed with a 
special key to run.
> Is oauth only intended to be used on standalone trustable web 

When it comes to browsers, yes the user is supposed to trust them. But 
OAuth is expected to work with the native applications, too (you may 
find several interesting threads in the archive on that). In both cases, 
ensuring that the application is not evil is a basic administrative 
problem. It is not an OAuth problem for two reasons: 1) Whatever would 
make OAuth fail here will make any other  protocol  fail; 2) Neither 
OAuth nor any other protocol can deal with key logging.

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 15:47:13 -0400

Q.E.D.

Igor

On 9/6/2011 2:57 PM, Eran Hammer-Lahav wrote:
> On Sep 6, 2011, at 11:50, "Michael Thomas"<[email-masked]>  wrote:
>
>> William Mills wrote:
>>> *From:* Michael Thomas<[email-masked]>
>>> *To:* Eran Hammer-Lahav<[email-masked]>
>>> *Cc:* "[email-masked]"<[email-masked]>
>>>> On Sep 6, 2011, at 11:23, "Michael Thomas"<[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 12:49:39 -0700

> OAuth client that's phishing the credentials, after all. 

Absolutely. I only brought it up because that is what I was working on.

> and ultimately outside of OAuth.

Except in the desktop web world, I choose from a *tiny* set of browsers:
chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't
expect that the browsers themselves are malicious. Which is a pretty ok
assumption.

With embedded web views, that assumption goes out the window. There are
100's of thousands of apps, all of which can use webviews. I have no way
to know if a given app is evil or not, and *lots* of apps provide facebook
and twitter integration. Not because they're evil, but because that's what's
expected by users. So the use model of oauth in this case is *very* different
than the desktop use case.

But I'm being told that use cases aren't the problem of oauth. I'd say that
there has all along been a hidden assumption that the browser was
a trusted entity. Since it isn't always, it should be very explicit in the
protocol, threats, and security considerations of what could happen if it's
not.

Mike, frankly this is why apps do suck but i'm not king of the world

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 06 Sep 2011 15:54:15 -0400

On 9/6/2011 3:36 PM, Justin Richer wrote:
> not a good idea in such environments.
>

To support and amplify Justin's point, OAuth has been adopted by OMA and 
WAC, and ITU-T is developing an OAuth profile.  Mobile providers 
reported OAuth implementation on this list.

Igor

---

From: John Kemp <[email-masked]>
Date: Tue, 6 Sep 2011 15:58:28 -0400

> expect that the browsers themselves are malicious. Which is a pretty ok

It is? I would certainly question it. The WebKit WebView is embeddable in the C/C++ programming languages and APIs are available for that on most platforms - all are open to the same attacks you mention. How about the plugins you get for your browser from various places - they could have key loggers too. It's also possible for an app delivered from a server to present a login form that looks like it is from Twitter, but is actually from an attacker site. Such attacks are very common indeed, and don't require a key logger. They do require the user to "trust" the app though, just as the user would need to trust the key logger he installed.

> than the desktop use case.

I disagree. If anything, because desktop machines tend to be less 'locked-down' than mobile platforms (app stores for desktops followed app stores for mobile platforms), they are more widely open to abuse.

> a trusted entity.

The point is simply that if you can subvert the actual platform, then OAuth problems are the least of your worries (as a user).

- John

> Since it isn't always, it should be very explicit in the

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 13:10:22 -0700

> It is? I would certainly question it. The WebKit WebView is embeddable in the C/C++ programming languages and APIs are available for that on most platforms - all are open to the same attacks you me…

I didn't say they weren't embeddable elsewhere. I just gave my example. And if I don't
use plugins, the browser is relatively trustable, especially in comparison to standalone
apps -- on desktop *or* phone, etc.

> I disagree. If anything, because desktop machines tend to be less 'locked-down' than mobile platforms (app stores for desktops followed app stores for mobile platforms), they are more widely open t…

I can tell you from experience that Android absolutely doesn't check anything of this
sort, and it would take extremely deep voodoo for Apple to do the same: they never see
source.

So the reality is that neither are trustable.

> The point is simply that if you can subvert the actual platform, then OAuth problems are the least of your worries (as a user).

People keep saying that to deflect criticism, but I don't buy it. Other protocols aren't
availing an attacker to user credentials to third party servers by simply snooping on the
webview key traffic in an otherwise completely normal use pattern.

Have you ever signed on to facebook in an app before?

Mike

---

From: John Kemp <[email-masked]>
Date: Tue, 6 Sep 2011 16:16:26 -0400

> apps -- on desktop *or* phone, etc.

Again, I disagree. As a user, I should pay attention to the sites I visit - as much as I should pay attention to the apps I download.

> sort, and it would take extremely deep voodoo for Apple to do the same: they never see

I believe that both Apple and Google *do attempt* to prevent malware from getting into their stores. 
 
> So the reality is that neither are trustable.

This I agree with ;)

> webview key traffic in an otherwise completely normal use pattern.

HTTP Auth? Web form login? 

> Have you ever signed on to facebook in an app before?

Frankly, not too often, no, since these apps usually ask for far more authority than I believe is necessary for the purpose of using the app.

- John

---

From: William Mills <[email-masked]>
Date: Tue, 6 Sep 2011 13:36:26 -0700 (PDT)

Yes, unfortunately a lot *is* on the shoulders of the users.  It's a very difficult problem.  What OAuth *does* do is hopefully make the situation incrementally better because there's an infrastructure for having the user only enter their username/password pair at the site they actually have that relationship with, and in installed apps that previously demanded caching the user password we can have a credential there instead.

None of it addresses the "is this thing safe to use?" question though.

________________________________
From: Michael Thomas <[email-masked]>
To: William Mills <[email-masked]>
Cc: Eran Hammer-Lahav <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Tuesday, September 6, 2011 11:50 AM
Subject: Re: [OAUTH-WG] problem statement

Mike

>  > Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software.
>  > If there was a solution to this we would not need an antivirus.
> 
>  >
>  > EHL
>  > On Sep 6, 2011, at 11:23, "Michael Thomas" <[email-masked] <mailto:[email-masked]>> wrote:
>  >
>  >> Eran Hammer-Lahav wrote:
>  >>> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft.
>  >> How, exactly, is the user supposed to protect themselves against rogue apps?
>  >> It sounds like the solution is to tell them to never use oauth in an app at all.
>  >>
>  >> Is oauth only intended to be used on standalone trustable web browsers? I don't recall
>  >> seeing that anywhere.
>  >>
>  >> Mike
>  >>
>  >>> EHL
>  >>>
>  >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" <[email-masked] <mailto:[email-masked]>> wrote:
>  >>>
>  >>>> Mike,
>  >>>>
>  >>>> You've got the problem statement right: allowing the user to authorize  resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth.  I do not think though that it is related to OAuth per se.
>  >>>>
>  >>>> To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks.  From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment.  There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView.
>  >>>>
>  >>>> If I am wrong, I would appreciate a detailed description of what happened.
>  >>>>
>  >>>> Igor
>  >>>>
>  >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote:
>  >>>>> Hi all,
>  >>>>>
>  >>>>> Barry suggested that I might subscribe and explain what I sent him.
>  >>>>>
>  >>>>> My basic problem is that in neither the protocol nor the threats drafts,
>  >>>>> I can't seem to find what problem is actually trying to be solved with
>  >>>>> oauth, and what assumptions you're making about various elements.
>  >>>>>
>  >>>>> Here's what I did. I've written an app, and I wanted re-integrate the
>  >>>>> ability to send tweets after they deprecated Basic. So the app has a
>  >>>>> webView (android, iphone...) which it obviously completely controls.
>  >>>>> With oauth, the webview UA will ultimately redirect off to Twitter's
>  >>>>> site to collect the user's credentials and grant my app's backend an
>  >>>>> access token (sorry if I get terminology screwed up, i'm just coming
>  >>>>> up to speed).
>  >>>>>
>  >>>>> What occurs to me is that webview affords exactly zero protection from
>  >>>>> my client (ie, the app) from getting the user's twitter credentials. All
>  >>>>> I have to do is set up a keypress handler on that webview and in a few
>  >>>>> minutes of hacking I have a key logger. etc.
>  >>>>>
>  >>>>> So what I can't tell is whether this is a "problem" or not, because I
>  >>>>> don't know what problem you're trying to solve. If the object of oauth
>  >>>>> isn't to keep user/server credentials out of the hands of a third party,
>  >>>>> then what is it trying to solve? Is there an expectation that the
>  >>>>> UA is trusted by the user/server? What happens when that's not the case?
>  >>>>>
>  >>>>> Regardless of whether I'm misunderstanding, it would sure be nice to have
>  >>>>> both the problem and your assumptions laid out, hopefully with some prominence
>  >>>>> so you don't get these sort of dumb questions.
>  >>>>>
>  >>>>> Mike
>  >>>>> _______________________________________________
>  >>>>> OAuth mailing list
>  >>>>> [email-masked] <mailto:[email-masked]>
>  >>>>> https://www.ietf.org/mailman/listinfo/oauth
>  >>>> _______________________________________________
>  >>>> OAuth mailing list
>  >>>> [email-masked] <mailto:[email-masked]>
>  >>>> https://www.ietf.org/mailman/listinfo/oauth
>  >>> _______________________________________________
>  >>> OAuth mailing list
>  >>> [email-masked] <mailto:[email-masked]>
>  >>> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 13:36:46 -0700

> I believe that both Apple and Google *do attempt* to prevent malware from getting into their stores. 

No, seriously, they don't. Google has no review process at all, just a kill switch after the fact.
Apple doesn't have source, so the amount of testing they can do is limited, and is about 99 & 44/100%
marketing hype in any case.

> HTTP Auth? Web form login? 

When an app asks for your login credentials, it looks like the app itself asking
if it's on the up and up. With OAuth, it looks like it's twitter, or facebook,
or whichever trusted service you're logging into. That's why I say that this situation
is worse: as a user, I have no idea which apps are good and which are sending your
credentials to a broker in Romania. At least I have some clue that it *might* do
that in the first case, but with OAuth I'm being told that that's why it exists
so that I don't *have* to trust that app. Except that I do as it turns out.

> Frankly, not too often, no, since these apps usually ask for far more authority than I believe is necessary for the purpose of using the app.

But even if you did it once, how did you know that you didn't reveal your credentials
to a bad guy?

And I'm being told that this isn't even worthy of any mention anywhere? I came
here hoping to hear that the attack wasn't possible, or could be mitigated. Zoicks.

Mike

---

From: John Kemp <[email-masked]>
Date: Tue, 6 Sep 2011 16:59:17 -0400

On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote:

[…]

> here hoping to hear that the attack wasn't possible, or could be mitigated.

The attack can be mitigated, but it cannot be prevented through protocols like OAuth (or any other protocol that I know of) alone.

The point is that you have a point. 

But OAuth alone cannot address your point - it provides a different -- and still useful, mitigation for attacks on user credentials sent over a network. It's not a superhero though.

- John

> Zoicks.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Sep 2011 14:22:52 -0800

> The point is that you have a point.

He does, and that's in some large part why I don't
fully understand the temperature of the responses.
I do not think it's a particularly big deal to stick
a couple of sentences in the security considerations
underscoring the fact that OAUTH can't do anything
about a compromised host or a malicious application.
I've learned to live with the fact that sometimes
people implementing or deploying security technologies
don't fully understand them and it's my impression that
there's some number of people out there who think that
OAUTH and other third-party protocols provide sufficient
protection against password snagging.

Melinda

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 15:27:46 -0700

It is a problem. For a few months now we have been going through this over and over again. The longer we work on this draft the more of this two-sentence changes people suggest. They don't make the document any better, create a false sense of comprehensiveness, and just further delay being done. 

So yeah, unless you can prove that there is an actual problem, we are done. 

EHL

---

From: Aiden Bell <[email-masked]>
Date: Wed, 7 Sep 2011 00:12:14 +0100

Perhaps a solution is to push OAuth.net as more of a "everything you ever
wanted to know about OAuth"
and direct non-core issues there for a page of good content to be created.
This way the RFC can focus on the
issue at hand and broader scope can be taken care of without having a 40+
thread on something like this.

Developers can still have a voice on these things, even if it isn't directly
through the RFC.

I feel strongly enough that I would be willing to help here. Let me know if
I can be of any assistance
in having these things dealt with more appropriately through something like
that.

Aiden

On 6 September 2011 23:27, Eran Hammer-Lahav <[email-masked]> wrote:

> It is a problem. For a few months now we have been going through this over
> and over again. The longer we work on this draft the more of this
> two-sentence changes people suggest. They don't make the document any
> better, create a false sense of comprehensiveness, and just further delay
> being done.
>

-- 
------------------------------------------------------------------
Never send sensitive or private information via email unless it is
encrypted. http://www.gnupg.org

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 17:02:04 -0700

> protection against password snagging.

The thing that was baffling to me is that there is no mention
at all about the assumptions anywhere I could find. I knew of
the "trusted" web browser assumption because it appears that
oauth predates the widespread phenomenon of phone apps, and
I kind of understood where oauth was coming from. So to *not*
have that assumption discussed or even listed as an assumption
is very surprising -- does this play well in the scenario I outlined
or not? As it turns out, not. Barry thought this was "obvious",
but it wasn't obvious to me. I suspect that this will come as
quite a  surprise to the uninitiated who  would roll this out to
the masses. It's not even clear to me that Twitter or Facebook
even realize that this attack exists. Or are they cool with the fact
that anybody with an app and a webview can ship their credentials
to Romania? My guess is that it's pretty uncool.

So no, I don't get all of the hostility either.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 17:05:14 -0700

> So yeah, unless you can prove that there is an actual problem, we are done.

I will point out that the chairs make that determination based on
working group consensus, not the document editor.

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 17:07:37 -0700

Write content and ping me off list. To avoid confusion, note that oauth.net<http://oauth.net> has nothing to do with this list and the IETF.

EHL

On Sep 6, 2011, at 16:12, "Aiden Bell" <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps a solution is to push OAuth.net<http://OAuth.net> as more of a "everything you ever wanted to know about OAuth"
and direct non-core issues there for a page of good content to be created. This way the RFC can focus on the
issue at hand and broader scope can be taken care of without having a 40+ thread on something like this.

Developers can still have a voice on these things, even if it isn't directly through the RFC.

I feel strongly enough that I would be willing to help here. Let me know if I can be of any assistance
in having these things dealt with more appropriately through something like that.

Aiden

On 6 September 2011 23:27, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
It is a problem. For a few months now we have been going through this over and over again. The longer we work on this draft the more of this two-sentence changes people suggest. They don't make the document any better, create a false sense of comprehensiveness, and just further delay being done.

EHL

On Sep 6, 2011, at 15:22, "Melinda Shore" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

--
------------------------------------------------------------------
Never send sensitive or private information via email unless it is encrypted. <http://www.gnupg.org> http://www.gnupg.org

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 17:09:04 -0700

> The attack can be mitigated, but it cannot be prevented through protocols like OAuth (or any other protocol that I know of) alone.

Even mitigation would be a big improvement, especially mitigation
on the server side which has access to better resources to find and
toss out bad guys.  If you know of some, I for one would be interested
in hearing about it.

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 17:09:15 -0700

Wg consensus is clearly to do nothing here. 

EHL

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Sep 2011 16:13:33 -0800

> Wg consensus is clearly to do nothing here.

??  No, it clearly is not, unless you're laboring
under the misconception that "consensus" means "voting."
At any rate the job of calling consensus *explicitly*
belongs to working group chairs, not editors.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 17:15:50 -0700

> Wg consensus is clearly to do nothing here.

Perhaps you are new to IETF process, but your job is to
put into the document what the chairs call as consensus.
Even if you disagree. Even vehemently.

Mike

> EHL
>
> On Sep 6, 2011, at 17:05, "Michael Thomas"<[email-masked]>  wrote:
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 17:21:28 -0700

The chairs have the final say, not a monopoly on making observations. The editor role *is* to distill wg discussion onto proposed changes. So saying I have no intention on making changes is clearly within my authority and the chair have the right to override that call. 

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 18:23:00 -0600

> protection against password snagging.

I just looked at the most recent specifications for TLS (RFC 5246) and
secure shell (RFC 4253), which I think we'd all agree are two quite
successful security technologies. Neither of those specs says anything
about not protecting humans users from malicious clients that perform
keylogging to capture security-critical data the user might enter. Not
only is OAuth "not a superhero" as John Kemp said, but I fail to see why
we need to document exactly which superhero powers OAuth lacks (given
that it's not reasonable to expect *any* security protocol to have those
powers). IMHO this is gilding the documentation lily.

Peter

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Sep 2011 16:50:56 -0800

On 09/06/2011 04:23 PM, Peter Saint-Andre wrote:
> keylogging to capture security-critical data the user might enter.

I think there's an argument to be made that the user interface
is sufficiently different that those might not be a great model.
But it's also the case that there have been security problems
with both that may or may not have been avoided in part by
putting in warnings not to trust every crappy, random CA
certificate that wafts by, or not to respond "Sure - thanks!"
to every ssh host key you're offered.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 19:03:10 -0600

On 9/6/11 6:33 PM, Michael Thomas wrote:
> On 09/06/2011 05:23 PM, Peter Saint-Andre wrote:
> That is because neither TLS or SSH are trying to allow access
> but protect you from a third party that is not necessarily
> trustworthy. OAuth  is. When the eve literally has access to
> the to-be protected data in many cases, that's noteworthy.
> That is not the case of either TLS or SSH.

TLS and ssh are controlling access to things like my bank account and my
VPS. Those are less important than my Flickr photos?

Peter

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 18:05:34 -0700

What do you think such a warning would accomplish? There are no ways to mitigate malware (bad client or otherwise), and using passwords make it even easier. 

End users are not going to read the specification and service providers have absolutely no alternatives.

As for the example, the issue you described with accepting every CA is completely irrelavent because changing the root certificates will be done in secrecy by the installed malware. 

I have not seen any argument showing how such a warming makes any difference in deploying OAuth (or not).

Can you propose text and show how it mau affect implementation?

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 19:08:23 -0600

> to every ssh host key you're offered.

Put me in the "may not have been avoided" camp. We can't legislate
common sense (which, sadly, is all too uncommon).

Look, I spent months working on RFC 6125, which has a title too long to
quote here but basically spends many dozens of pages defining what it
means to check that you're connecting to the right TLS server. That
advice at least is something positive that clients can operationalize.
Documenting a lack of superhero powers seems like a waste of time to me,
but if someone wants to propose a few sentences of text that's up to them.

Peter

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 18:13:05 -0700

> common sense (which, sadly, is all too uncommon).

Can somebody show me in the archives where this has been
discussed before? Specifically about oauth clients that also
have control of the web UA?

In any case, you site this as common sense. It's not. You are
close to the problem. Nobody else is.

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 18:24:46 -0700

You clearly feel strongly about this. The only way forward if you want to pursue this is to suggest text and show how providing it will lead to more secure implementations. Otherwise this is just going in circles. 

EHL

---

From: William Mills <[email-masked]>
Date: Tue, 6 Sep 2011 18:27:27 -0700 (PDT)

I think the only potential mitigation OAuth can offer is that the authenticating sites can do more due dilligence about the clients they allow.  I say this knowing that it's not likely to happen in most cases, but it's possible.  Sites *can* limit the clients they allow, *but* it doesn't really work for installed clients on the desktop, software copy protection being the hard problem that it has proved to be.

Nobody dismisses the problem you're talking about, it's definitely a problem.  What you have not do is provided any concrete way in which OAuth can mitigate it beyond it's present state.

I personally want OAuth 2.0 to get out the door.  What you seem to be asking for (if we really go there) is a far more comprehensive and general security considerations section that's goign to cover a huge swath of space not specific to OAuth.  I don't think what you're asking for is specific to OAuth, so I don't think it's appropriate to take this spec there.

If you really think you've got something here, draft language and propose it.  That takes this from the theory of the problem to specifics.  It's got to be concrete though and actionable.  The recent discussions around CSRF identified a problem of CSRF in the auth server, and the new language addresses that in an actionable way.

________________________________
From: Michael Thomas <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, September 6, 2011 6:13 PM
Subject: Re: [OAUTH-WG] problem statement

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 18:27:51 -0700

> You clearly feel strongly about this. The only way forward if you want to pursue this is to suggest text and show how providing it will lead to more secure implementations. Otherwise this is just g…

Didn't you just get done announcing how you weren't going to do anything
under any circumstances unless you were forced to by the chairs? I think
I'll wait for them to chime in before I waste my time.

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Sep 2011 18:36:35 -0700

*I* am not going to do anything to move this forward which means nothing will happen unless someone propose text. Even the chairs can't instruct the editor to produce new prose.

All the chairs are going to do is give you the same answer. If you want the wg to consider anything at this point you must provide text. In fact, they already issued this clear instructions. 

Now, the overwhelming resistance to such a change would make *me* reconsider spending my time on this of I was in your position, but proposing text is the only advise the chairs can offer you at this point. 

If you think you can offer text that will win wg consensus you should. Arguing with me as a participant is, unfortunately, part of the deal. 

EHL

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Sep 2011 18:57:46 -0700

On 09/06/2011 06:27 PM, William Mills wrote:
> I think the only potential mitigation OAuth can offer is that the 
> authenticating sites can do more due dilligence about the clients they 
> allow.  I say this knowing that it's not likely to happen in most 
> cases, but it's possible.  Sites *can* limit the clients they allow, 
> *but* it doesn't really work for installed clients on the desktop, 
> software copy protection being the hard problem that it has proved to be.

Yeah, I agree that it would be hard for the authenticating side to
do much, mainly because it's hard for them to tell if the app is
doing something untoward. I wonder if triggering DOM keypress
events gets propagated up to external webview code and you could
set some honeypots or steganography... hmm. I'm sorry but I'm still
very new to thinking about this problem space.

>
> Nobody dismisses the problem you're talking about, it's definitely a 
> problem.  What you have not do is provided any concrete way in which 
> OAuth can mitigate it beyond it's present state.

At this point, it would be just nice for the industry to know that the issue
even *exists*. Hence my puzzlement at the overt hostility from some 
quarters.

>
> I personally want OAuth 2.0 to get out the door.  What you seem to be 
> asking for (if we really go there) is a far more comprehensive and 
> general security considerations section that's goign to cover a huge 
> swath of space not specific to OAuth.  I don't think what you're 
> asking for is specific to OAuth, so I don't think it's appropriate to 
> take this spec there.

I have no dog in this race. I was just very puzzled by the lack of 
discussion
about the lack of applicability of the protocol in either the protocol 
document
or in the threats. It made me wonder whether this scenario had even been
considered. I'm still not sure if it had been.

> If you really think you've got something here, draft language and 
> propose it.  That takes this from the theory of the problem to 
> specifics.  It's got to be concrete though and actionable.  The recent 
> discussions around CSRF identified a problem of CSRF in the auth 
> server, and the new language addresses that in an actionable way.
>

Like I said in my first message: the documents lack any clear description of
the problem they are trying to address, any implicit assumptions about the
trust of the various elements, and the applicability of the protocol. That
should be part of the abstract and introduction, IMO.

Mike

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 7 Sep 2011 13:52:41 +1000

A strange aspects of this thread is that the current draft already talks about exactly this issue:

draft-ietf-oauth-v2-21 section 9 "Native Applications"

  "...Native applications can invoke an external user-agent or
  embed a user-agent within the application
  ...
  Embedded user-agents pose a security challenge because resource
  owners are authenticating in an unidentified window without access
  to the visual protections found in most external user-agents.
  Embedded user-agents educate end-user to trust unidentified
  requests for authentication (making phishing attacks easier to
  execute)."

The webView that Michael Thomas talks about is an "embedded user-agent".

--
James Manger

----------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas

...
even *exists*.

---

From: Justin Richer <[email-masked]>
Date: Wed, 7 Sep 2011 10:17:14 -0400

Ah, guess that settles it then. Mike, if you have any suggested text to
make this point clearer in the spec, this is probably the best place to
put it.

 -- Justin

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 07:54:23 -0700

> The webView that Michael Thomas talks about is an "embedded user-agent".

First, thank you for finding this -- this is far more useful than
the snarls I've received.

Second, I'd say that this is a good first step, but the text there
should be explicit and not pussy-foot around the fact that it
means embedded UA's in phone apps and other examples. It
should also make clear that the "challenge" (ack, ptui) involves
untrusted apps stealing the user's credentials by simply snooping
on the UA itself. If there is reasonable mitigation, then by all means
add text about it. This is important because I do not think that
many people grok the seriousness of the issue, and most especially
people who would deploy oauth authentication services.

Third, I think that the introduction needs to have an applicability
statement of *when/where/what* oauth can be used. That is,
do not beat around the bush about the need for the UA to be
trustable because that is a basic the assumption that oauth makes.
As inconvenient as that may be, it would be far worse for people
in the industry to not fully understand the threat.

Fourth, it would be *really* nice to hear from folks at Facebook
and Twitter who have deployed oauth and oauth-like flows with
their experience here, and most especially if they understood the
threat ahead of their deployment, and what they do to mitigate
it if anything.

Mike

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 13:17:04 -0400

+300 (if I can do that) to indicate my strong agreement.  But if somehow 
it is decided to add a few sentences on saying that OAuth cannot deal 
with key-logging, I will insist on adding two sentences each on OAuth 
being unable to deal with 1) earthquakes, 2) certain contageous 
diseases, etc., and I will invite others to complete that list. And 
encouraged by the precedent, I will require similar changes to TLS as 
well as the whole list of password-authenticated key exchange protocols.

  Melinda, in my reading the "temperature of the responses" is explained 
by a huge amount of work achieved by this group, which involved many, 
many real protocol issues on which it was hard to build the consensus. 
Now that the consenus has been pretty much achieved, it is important to 
complete OAuth 2.0, which means concentrating on real outstanding 
issues--Barry has dutifully documented and enumerated them.  I myself 
got beaten up unjustly for pushing the use cases, but in order to 
complete the protocol, I accepted the beating and agreed to wait until 
the next rechartering.  This is a matter of priorities. My opinion is 
that we just cannot go off on a tangent to deal with something that is 
not OAuth's concern.  Because, if we do, someone will bring the 
earthquakes, too.

Igor

On 9/6/2011 6:27 PM, Eran Hammer-Lahav wrote:
> On Sep 6, 2011, at 15:22, "Melinda Shore"<[email-masked]>  wrote:
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 10:26:26 -0700

On 09/07/2011 10:17 AM, Igor Faynberg wrote:
> +300 (if I can do that) to indicate my strong agreement.  But if 
> somehow it is decided to add a few sentences on saying that OAuth 
> cannot deal with key-logging, I will insist on adding two sentences 
> each on OAuth being unable to deal with 1) earthquakes, 2) certain 
> contageous diseases, etc., [...]

Please, enough of the hyperbole. It is not clear or obvious whether this is
a protocol issue or not. It brings into question whether the protocol is 
worth
deploying at all, and that is surely an issue. As far as I can tell, 
there is very
little upside to deploying OAuth in the general case over, say, 
Basic+TLS. In
fact, you guys have convinced me that OAuth gives inferior protection at
considerable expense for all concerned.

Mike

---

From: John Kemp <[email-masked]>
Date: Wed, 7 Sep 2011 13:49:03 -0400

Mike,

On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote:

>> +300 (if I can do that) to indicate my strong agreement.  But if somehow it is decided to add a few sentences on saying that OAuth cannot deal with key-logging, I will insist on adding two sentences each on OAuth being unable to deal with 1) earthquakes, 2) certain contageous diseases, etc., [...]
> 
> a protocol issue or not. It brings into question whether the protocol is worth
> deploying at all, and that is surely an issue. As far as I can tell, there is very
> little upside to deploying OAuth in the general case over, say, Basic+TLS. In

I'm sorry that you haven't received an easy introduction to the OAuth WG. But that's no reason to spout nonsense. OAuth seeks to replace something that was once rather common - the need for a user to type (and/or store) his password for site A at site B, to let site B get their content from site A. Now, site B gets a token in the common case, rather than the user's password for site A. This doesn't remove the need for a user to exercise common sense in deciding where to type her password. But it does, in the common case, mitigate the password being shared among websites, or across networks multiple times. 

You are right that OAuth doesn't mitigate key logging or other similar attacks on the client OS/platform itself. But that doesn't make it inferior to other methods of web authorization.

- John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 11:02:43 -0700

> You are right that OAuth doesn't mitigate key logging or other similar attacks on the client OS/platform itself. But that doesn't make it inferior to other methods of web authorization.

It's not nonsense:

1) App prompts me for my credentials to Facebook -- I wonder whether
     I trust the app.
2) App puts me in a Facebook login window -- I figure that it's secure and
     don't wonder whether I trust the app.

#2 sure looks worse than #1.

Mike

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Sep 2011 14:09:04 -0400

Good eye!  Seeing this now, I agree, but I admit I never fully 
understood what "embedded uses-agents" were before.

Igor

---

From: David Waite <[email-masked]>
Date: Wed, 7 Sep 2011 12:20:01 -0600

>    don't wonder whether I trust the app.
The assumption for #1 is that the app gave you a user experience for entering your facebook credentials that looks different than the actual facebook login window. If the app is malicious, this will most likely not be the case.

The advantage OAuth provides is that it can vet/ban clients which are doing malicious things. However, even a client with no oauth support at all is still capable of providing a realistic-looking login window using an embedded user agent, and capturing the real username/password.

-DW

---

From: Phil Hunt <[email-masked]>
Date: Wed, 7 Sep 2011 11:22:43 -0700

Michael,

You should read the threat model document. This document has more editorial on these kinds of issues.

The core spec deals in specific items implementors must do or not do from an inter-op perspective.

The threat model document goes into some details about the need for authenticating clients, etc and the counter-measures that should be considered. This is likely more in line with your concerns.

In my opinion, the issue of malware and of component "trust" is to me something that belongs in whitepapers, product manuals, etc and does not belong in the protocol specification.  In a sense the issue is the kind of thing a "consultant" would provide and thus this type of consultative information fits into broader best practices of desktops and servers management and has no direct relevance on OAuth.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 11:28:06 -0700

On 09/07/2011 11:20 AM, David Waite wrote:
> The assumption for #1 is that the app gave you a user experience for 
> entering your facebook credentials that looks different than the 
> actual facebook login window. If the app is malicious, this will most 
> likely not be the case.
>
> The advantage OAuth provides is that it can vet/ban clients which are 
> doing malicious things. However, even a client with no oauth support 
> at all is still capable of providing a realistic-looking login window 
> using an embedded user agent, and capturing the real username/password.
>
Absolutely. But before facebook started doing this oauth-like
authentication (from the UX standpoint), there wasn't any reason
why a user would expect to see that facebook-like authentication page.
But now users are getting taught to trust that facebook authentication
page inside untrusted apps. So it's the whole ecosystem that's problematic,
but it doesn't seem right to tout oauth as a solution which is
how it's coming across on the outside. Not wanting to very clearly
fess up in the protocol document makes it sound like some people
view that as a feature, not a bug.

Mike

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Sep 2011 10:34:36 -0800

> You should read the threat model document. This document has more editorial on these kinds of issues.

This seems reasonable to me, and thank you so much for departing
from what seems to be standard working group mode by dealing with
this like an adult.

It seems to me that there are some usability problems that while
not being unique to oauth, really aren't that much like what
we usually run into with on-the-wire protocols.  Documents in
the security area have typically not dealt with usability issues
even when, perhaps, they should, given their impact on how
secure a technology is in the field.  Getting that into a threat
model document sounds about right to me.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Sep 2011 12:42:11 -0600

> from what seems to be standard working group mode by dealing with

Is it really juvenile to point out that specs for widely-deployed
security technologies also don't cover threats like keyloggers?

> model document sounds about right to me.

Agreed. In fact, I hope that we'll all be able to turn more attention to
the threat-model document soon, because it's quite comprehensive and
useful. The usability issues are indeed a bit different here, although
usability is not exactly easy in the case of, say, TLS with PKI certs
issued by certification authorities (as witness recent events -- have
you scrubbed your root cert store lately?).

Peter

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Sep 2011 12:12:54 -0700

Michael,

I suggest you go back and read the entire thread again:

http://www.ietf.org/mail-archive/web/oauth/current/maillist.html

I don't think you have been listening to the 11 (!) people who all completely disagree with you and dismiss your suggestions (on technical grounds). The one person who supported your plea didn't actually make any technical contribution.

If anyone wants to make accusations about behaving like adults, that should be the 11 people who tried to explain why you are simply wrong and were completely ignored by you. Any perceived hostility is easily justified by having to explain the same thing over and over again to someone who refuses to list and insists on labeling this work as lacking and insecure. We take real security pretty seriously here.

You asked a question as someone "very new to thinking about this problem space" and was answered by experts. The fact that you refuse to accept their answers is while being , at this point, your problem. You were given multiple opportunities to present an alternative text and technical justification to support it, but refused to do so.
 
You might not like my tone, but I consider making a statement like this:

> In fact, you guys have convinced me that OAuth gives inferior protection at

an irresponsible and serious offense - the kind of baseless FUD that can cause real damage to important work.

EHL

---

From: Aiden Bell <[email-masked]>
Date: Wed, 7 Sep 2011 20:23:50 +0100

I'm gonna ditch the (lengthy) reply I was drafting and agree with the below.

Personally, my communication with the OAuth WG has been spot on. Warm
welcome, open minds
and a very good process to getting my requirements/concerns heard and
pragmatic change enacted.

All I saw here was foot stomping and a counter-productive approach to
communicating by those
not getting their way.

On 7 September 2011 20:12, Eran Hammer-Lahav <[email-masked]> wrote:

> I don't think you have been listening to the 11 (!) people who all
> completely disagree with you and dismiss your suggestions (on technical
> grounds). The one person who supported your plea didn't actually make any
> technical contribution.
>
> If anyone wants to make accusations about behaving like adults, that should
> be the 11 people who tried to explain why you are simply wrong and were
> completely ignored by you. Any perceived hostility is easily justified by
> having to explain the same thing over and over again to someone who refuses
> to list and insists on labeling this work as lacking and insecure. We take
> real security pretty seriously here.
>
> You asked a question as someone "very new to thinking about this problem
> space" and was answered by experts. The fact that you refuse to accept their
> answers is while being , at this point, your problem. You were given
> multiple opportunities to present an alternative text and technical
> justification to support it, but refused to do so.
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 12:24:49 -0700

On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:

[more browbeating elided]

> an irresponsible and serious offense - the kind of baseless FUD that can cause real damage to important work.

I have written down at least 3 or 4 times why I think it's inferior.
Nobody attacking the messenger including yourself has answered
it. There's FUD here, but not from me.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 12:27:22 -0700

I would ask the chairs to keep personal attacks in check.

Thank you.

Mike

On 09/07/2011 12:23 PM, Aiden Bell wrote:
> On 7 September 2011 20:12, Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Michael,
>
>     completely disagree with you and dismiss your suggestions (on
>     technical grounds). The one person who supported your plea didn't
>     actually make any technical contribution.
>
>     If anyone wants to make accusations about behaving like adults,
>     that should be the 11 people who tried to explain why you are
>     simply wrong and were completely ignored by you. Any perceived
>     hostility is easily justified by having to explain the same thing
>     over and over again to someone who refuses to list and insists on
>     labeling this work as lacking and insecure. We take real security
>     pretty seriously here.
>
>     You asked a question as someone "very new to thinking about this
>     problem space" and was answered by experts. The fact that you
>     refuse to accept their answers is while being , at this point,
>     your problem. You were given multiple opportunities to present an
>     alternative text and technical justification to support it, but
>     refused to do so.
>
>     an irresponsible and serious offense - the kind of baseless FUD
>     that can cause real damage to important work.
>
>     EHL
>

---

From: Aiden Bell <[email-masked]>
Date: Wed, 7 Sep 2011 20:30:55 +0100

> I have written down at least 3 or 4 times why I think it's inferior.
But no proposed solution or anything constructive past arguing with people
who understand and are only here to help.
Helping people who don't listen or appear to show any tact in the face of
opposing concensus is hard.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Sep 2011 13:32:25 -0600

> it. There's FUD here, but not from me.

Mike, did you propose text to address the concern? Per recent discussion
I think the threat-model document is the right place for it, so please
take a look at that spec to see where your proposed text can slot in.

Peter

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 12:40:03 -0700

> take a look at that spec to see where your proposed text can slot in.
Yes, I outlined what I think should be done at a minimum. I've
also been told by the editor that he won't consider it. Barry
has said that he won't consider it either. Unless the working
group is open to changes, I'm not going to waste my time crafting
the actual changes. So this is your call.

Here's what I wrote previously:

[...]

Second, I'd say that [section 9] is a good first step, but the text there

Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Sep 2011 13:03:06 -0700

Melinda,

We clearly have different views on what it means to "[deal] with this like an adult". I would like to address what I *think* were your two main points: the lack of civility in addressing the feedback provided by Mr. Thomas, and the alleged IETF process violation by me as editor. I have not seen any actual technical argument coming from you in support of this change other than 'why not'.

While the 11 people who replied to this thread did dismiss the claim and the need to address it, the conversation was pretty calm and polite. I suggest you go back and read the entire thread:

Any hints of hostility you find can be justly explained by the frustration of trying to talk to someone who refuses to listen and insists on making a change that everyone else objects to. Given that this is a technical working group, I can safely state that this objection was unanimous based on technical arguments.

Process-wise, we are operating under clear and explicit directions from the chairs to only consider changes to the document based on *proposed text* and consensus. As editor, it is completely within my authority to dismiss proposals and changes not matching the criteria set by the chairs, and it is my stated responsibility to reject changes where there clearly is no consensus. While the chairs can change their instructions, someone still has to provide text, which is the only way you can reach consensus.

And for the record, in this case, there is clear cut IETF consensus not to make any changes (1 in support, 11 against, and 1 'why not'). That's a close as the IETF gets to unanimity. I agree that the editor is not empowered to make such final declarations, but everyone is free to make that observation, including the editor. I have never refused to make a change in face of clear guidance from the chairs, nor have I ever suggested I have the authority to make such final calls. I find that suggestion disrespectful to my unparalleled contribution to this work over 4 years.

Your entire argument is basically 'why not, it's only a few lines in the introduction'. I find this both counter-productive and harmful. The suggested change boils down to explaining to the reader that installing untrusted clients on a user device can have wide repercussions to the security properties of this protocol. But such a claim is both obvious (to everyone but one) and incomplete.

It is the incompleteness part that most people objected to, and the fact that any attempt at a comprehensive text would mean significant and open-ended delay. The number of potential ways for malicious code to find its way onto a user device are practically unlimited, and every single one of them will lead to the same security degradation described in this thread.

There are certain things we have to take for granted when writing a specification like this. One of them is the reader's understanding that there are many factors outside the scope of the protocol, and malware is one of the most obvious factors. I am completely serious when I say that earthquakes (as suggested jokingly by others) present equal thread to the security model of this protocol because the user hand might shake when trying to deny client access and hitting the approve button instead.

So following your login, why not discuss the potential impact of a physical disruption to the user interaction with the authorization endpoint? I am dead serious as I consider the two threats to be of equal relevance to this document. There are many examples of over-specification causing more harm than good and this is clearly one of those cases. 'Why not' is never an acceptable argument for making changes, especially at this stage and for a security protocol. I would also note that every example you tried to give for why accommodating this is the right thing based on past protocols was proved to be misleading or misguided.

I would also note that the proposed changes (guessing based on the information provided in lieu of actual text) will not result in *any* actionable result by anyone, if only because there is nothing to do about it other than educate users not to install untrusted software of any kind on any device.

Trying to portray the answer below as a more adult response is interesting. If you note, no one actually suggested we change the security thread model document, only that it provides a comprehensive description of the protocol. I am pretty sure most WG participants will still object to this change made in that document for the same reasons.

As editor, I consider this matter closed and will not make any changes based on the information presented. You are free ask the chairs to open an issue block the progress of the draft until this is resolved to your satisfaction.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Melinda Shore
> Sent: Wednesday, September 07, 2011 11:35 AM
> To: [email-masked]
> This seems reasonable to me, and thank you so much for departing from
> what seems to be standard working group mode by dealing with this like an
> adult.
> 
> It seems to me that there are some usability problems that while not being
> unique to oauth, really aren't that much like what we usually run into with
> on-the-wire protocols.  Documents in the security area have typically not
> dealt with usability issues even when, perhaps, they should, given their
> impact on how secure a technology is in the field.  Getting that into a threat

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 13:17:13 -0700

On 09/07/2011 12:56 PM, Kristoph wrote:
> Mike,
>
> I am an implementer of this specification. I am struggling to understand what it is you are trying to communicate.
>
> The only thing I can discern is that you believe there is a large cadre of software architects / developers who you think have the skill to read and understand this specification, design and implement an OAuth 2.0 server, and yet not understand that a rogue embedded UA would compromise the end users credentials. Is that basically your concern?
>    

I think that the fine point of a rogue embedded UA will be lost on
people, yes. Especially those who are specing out the higher level
authentication service deployment. We have both Twitter and Facebook
out there in the wild who are subject to this attack right now. Are they
aware of  the attack? I really don't know.

Mike

> ]{
>
> On Sep 7, 2011, at 12:40 PM, Michael Thomas wrote:
>
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Sep 2011 12:20:08 -0800

On 09/07/2011 12:03 PM, Eran Hammer-Lahav wrote:
> We clearly have different views on what it means to "[deal] with this like an adult".

Very possibly.  What bothered me was the reflexive dismissal
of usability issues without consideration, and the nasty tone
of some of the responses.  When someone suggests that Mike
Thomas doesn't understand trusted third-party authentication
protocols, someone just blew it, big time.

But aside from the personal attacks, usability is a huge,
huge problem in security, and often protocols that are
"secure" under ideal circumstances are actually riddled
with vulnerabilities in the field.  While you can't prevent
users from making bad choices, you should probably try to
minimize their ability to do so or at least try to understand
where things can go wrong.  I think it's not *that* long since
entirely too many people were nailed by a MITM attack against
ssh on an IETF meeting wireless network, when they were presented
with a new host key and rather than wondering why the key had
changed they said "Gee, thanks!" and accepted it.  Even very
sophisticated users can make bad choices that lead directly to
compromise.

It's not possible to catalog every possible usability issue,
but I do think that it's a worthwhile exercise to give at least
some thought to what choices are being presented to users
that are peculiar to the technology in question, and I think
a threats document is an ideal place to do that.

Melinda

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 8 Sep 2011 01:19:05 +0100

Mike,

On 7 Sep 2011, at 21:17, Michael Thomas wrote:

> authentication service deployment.

I've been observing this thread as well as the OAuth mailing list without participating for some time and I think what you write above gets to the heart of the matter.

I have some sympathy for the issue you are trying to raise but it is a common issue across many security protocols and the document to discuss it in is not the protocol specification which (IME in IETF) is typically focussed on how to implement (inter-operably) the protocol itself, not on best practices for deploying an implementation of the protocol.

IMO articulating the concerns you have are best placed either in the "threats" document (which I will admit I have not read) or a separate informational document (or possibly a BCP if there is sufficient deployment experience).

Your original e-mail that started this thread was not targeted at a specific document and my interpretation is that some of the hostility you have experienced is due to a frustration that your request is seen as a potential obstacle to getting the protocol specification out the door because the issue you want to discuss is not directly related to how a developer might implement the protocol.

If I may be so bold, could I suggest that you propose some text that articulates the issue that you would like to see documented and then the group can assess that text on its merits and try to reach consensus on which document, if any, it is best placed to reside within.

At the risk of offending you or others, I would suggest that if you're not willing to propose text for whatever reason then I'd suggest we put an end to this thread as it is reminding me of this Dilbert cartoon: http://www.dilbert.com/2010-12-22/

Regards
Ben

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2011 18:03:58 -0700

> Your original e-mail that started this thread was not targeted at a specific document and my interpretation is that some of the hostility you have experienced is due to a frustration that your requ…

I had no idea where in the ietf process the protocol document is. I'm
still not sure whether it's been through wg last call, ietf last call, etc.

> If I may be so bold, could I suggest that you propose some text that articulates the issue that you would like to see documented and then the group can assess that text on its merits and try to rea…

Basically, in the protocol document's introduction I think it should
be clearly explained that the UA functionality is expected to be "trusted",
ie not be under the control of a potential attacker. I think that for the
uninitiated that is anything but obvious. There has been a sea-change
since 2007 making this an important point. Had that been in the
introduction, we would not be having  this conversation.

Mike

---

From: David Recordon <[email-masked]>
Date: Sat, 10 Sep 2011 10:29:05 -0700

Hey Mike, I think this has been said a few times by Eran and Peter but
you really need to propose actual sentences that you want to see
included in the specification at this point. Saying "I think it should
be clearly explained" isn't actionable text.

That said, I strongly don't believe this is an issue specific to OAuth.

--David

On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas <[email-masked]> wrote:
>> Your original e-mail that started this thread was not targeted at a
>> specific document and my interpretation is that some of the hostility you
>> have experienced is due to a frustration that your request is seen as a
>> potential obstacle to getting the protocol specification out the door
>> because the issue you want to discuss is not directly related to how a
>> developer might implement the protocol.
>>
>
>> If I may be so bold, could I suggest that you propose some text that
>> articulates the issue that you would like to see documented and then the
>> group can assess that text on its merits and try to reach consensus on which
>> document, if any, it is best placed to reside within.
>>
>

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 12 Sep 2011 13:58:51 -0400

> > be clearly explained that the UA functionality is expected to be
> > "trusted", ie not be under the control of a potential attacker. I
> > think that for the uninitiated that is anything but obvious. There has
> > been a sea-change since 2007 making this an important point. Had that
> > been in the introduction, we would not be having  this conversation.
> >
> > Mike

Mike,

I have found that the Security Considerations doc helps a lot in understanding the expected deployment conditions of OAUTH (see draft-lodderstedt-oauth-securityconsiderations-02.txt).

For example, Section 2.2 (about Malicious Client) goes a long way towards answering your concerns:

   Assumption: 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.  Based on this assumption, the following
   countermeasures are recommended.

Hope this helps.

/thomas/

__________________________________________

> Of David Recordon
> Sent: Saturday, September 10, 2011 1:29 PM
> To: Michael Thomas
> Cc: [email-masked]
> >> specific document and my interpretation is that some of the
> hostility
> >> you have experienced is due to a frustration that your request is
> >> seen as a potential obstacle to getting the protocol specification
> >> out the door because the issue you want to discuss is not directly
> >> related to how a developer might implement the protocol.
> >>
> >
> >> articulates the issue that you would like to see documented and then
> >> the group can assess that text on its merits and try to reach
> >> consensus on which document, if any, it is best placed to reside
> within.
> >>
> >
> > be clearly explained that the UA functionality is expected to be
> > "trusted", ie not be under the control of a potential attacker. I
> > think that for the uninitiated that is anything but obvious. There
> has
> > been a sea-change since 2007 making this an important point. Had that
> > been in the introduction, we would not be having  this conversation.
> >
> > Mike

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 Sep 2011 11:22:22 -0700

Note that the security considerations doc was replaced with the Threat Models WG draft,
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00

While that paragraph is not in the Threat Model document, there are numerous threats discussed regarding malicious clients and what the recommended counter measures are. I believe these threats go well beyond Michael's original concerns.

I invite Michael to take a look at the Threat Model spec and suggest whether he would either prefer to describe a new threat (and propose text), or whether new introductory text is warranted such as the assumption from the security considerations draft below.

Let us know if you have any specific comments on the Threat Model doc, in particular referencing sections/paragraphs which may need refinement to address the concerns.  The easiest way to do this, as always, is to suggest edits and proposed replacement text to this mature document.

Phil

@independentid
www.independentid.com
[email-masked]