[OAUTH-WG] problem statement

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 wh

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

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] problem statement

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 On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: > Mike, > > You've got

Re: [OAUTH-WG] problem statement

Michael, On Sep 6, 2011, at 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 > oa

Re: [OAUTH-WG] problem statement

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

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. How, exactly, is the user supposed to protect themselve

Re: [OAUTH-WG] problem statement

> How, exactly, is the user supposed to protect themselves against rogue apps? Don't install them. From: Michael Thomas To: Eran Hammer-Lahav Cc: "oauth@ietf.org" Sent: Tuesday, September 6, 2011 11:23 AM Subject: Re: [OAUTH-WG] problem statement Eran Hammer

Re: [OAUTH-WG] problem statement

John Kemp wrote: 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. One point I would mention first is that your question isn't dumb ;) But, as

Re: [OAUTH-WG] problem statement

William Mills wrote: > How, exactly, is the user supposed to protect themselves against rogue apps? Don't install them. Will they be marked with rfc 3514? Mike *From:* Michael Thomas *To:* Eran Hammer-Lahav *Cc:* "oauth@ietf.org" *Sent:* Tuesday, September 6, 2011 11:23 AM *Subject:*

Re: [OAUTH-WG] problem statement

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" wrote: > Eran Hammer-Lahav wrote: >> I agree. If you are going to ins

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] problem statement

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 inve

Re: [OAUTH-WG] problem statement

I'm dismissive of this being an OAuth problem. EHL On Sep 6, 2011, at 11:35, "Michael Thomas" 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. >> >> If there was a solution to this we would

Re: [OAUTH-WG] problem statement

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 appl

Re: [OAUTH-WG] problem statement

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. If you manage to solve this problem in a real way I'

Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote: 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

Re: [OAUTH-WG] problem statement

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 On Sep 6, 2011, at 11:50, "Michael Thomas" wrote: > William Mills wrote: >

Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote: Framing this as an OAuth issue is wrong. In your scenario: 1. Install bad app 2. Do protocol X 3. Bad things happen 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 yah

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] problem statement

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" wrote: > You are one making the argument that no one should be installing apps. > > There is no known way to stop users fro

Re: [OAUTH-WG] problem statement

On 09/06/2011 11:11 AM, Jill Burrows wrote: 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 discussi

Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote: 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

Re: [OAUTH-WG] problem statement

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 mailto:melinda.sh...@gmail.com>> Date: Tue, 6 Sep 2011 12:18:18 -0700 To: "oauth@ietf

Re: [OAUTH-WG] problem statement

Melinda Shore wrote: On 09/06/2011 11:11 AM, Jill Burrows wrote: 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 document

Re: [OAUTH-WG] problem statement

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 writin

Re: [OAUTH-WG] problem statement

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 dis

Re: [OAUTH-WG] problem statement

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 t

Re: [OAUTH-WG] problem statement

On 9/6/2011 2:23 PM, Michael Thomas wrote: ... How, exactly, is the user supposed to protect themselves against rogue apps? ... 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 thi

Re: [OAUTH-WG] problem statement

Q.E.D. Igor On 9/6/2011 2:57 PM, Eran Hammer-Lahav wrote: 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 On Sep 6, 2011,

Re: [OAUTH-WG] problem statement

Justin Richer wrote: 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

Re: [OAUTH-WG] problem statement

On 9/6/2011 3:36 PM, Justin Richer wrote: ... OAuth *does* work with phone apps, and it's a misnomer to say that it's 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 provid

Re: [OAUTH-WG] problem statement

On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: > > 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. It i

Re: [OAUTH-WG] problem statement

John Kemp wrote: On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: 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 assumpti

Re: [OAUTH-WG] problem statement

On Sep 6, 2011, at 4:10 PM, Michael Thomas wrote: > John Kemp wrote: >> On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: >>> 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

Re: [OAUTH-WG] problem statement

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 tha

Re: [OAUTH-WG] problem statement

John Kemp wrote: 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. I believe that both Apple and Google *do attempt* to prevent malware from getting into their st

Re: [OAUTH-WG] problem statement

On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote: […] > 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 possib

Re: [OAUTH-WG] problem statement

On 09/06/2011 12:59 PM, John Kemp wrote: 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 underscori

Re: [OAUTH-WG] problem statement

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.

Re: [OAUTH-WG] problem statement

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 some

Re: [OAUTH-WG] problem statement

On 09/06/2011 03:22 PM, Melinda Shore wrote: On 09/06/2011 12:59 PM, John Kemp wrote: 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 sente

Re: [OAUTH-WG] problem statement

On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: 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

Re: [OAUTH-WG] problem statement

Write content and ping me off list. To avoid confusion, note that oauth.net has nothing to do with this list and the IETF. EHL On Sep 6, 2011, at 16:12, "Aiden Bell" mailto:aiden...@gmail.com>> wrote: Perhaps a solution is to push OAuth.net as more of a "ev

Re: [OAUTH-WG] problem statement

On 09/06/2011 01:59 PM, John Kemp wrote: On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote: […] 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

Re: [OAUTH-WG] problem statement

Wg consensus is clearly to do nothing here. EHL On Sep 6, 2011, at 17:05, "Michael Thomas" wrote: > On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: >> 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

Re: [OAUTH-WG] problem statement

On 09/06/2011 04:09 PM, Eran Hammer-Lahav wrote: 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 edit

Re: [OAUTH-WG] problem statement

On 09/06/2011 05:09 PM, Eran Hammer-Lahav wrote: 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, "Michae

Re: [OAUTH-WG] problem statement

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 On Sep 6, 2011, at

Re: [OAUTH-WG] problem statement

On 9/6/11 4:22 PM, Melinda Shore wrote: > On 09/06/2011 12:59 PM, John Kemp wrote: >> 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

Re: [OAUTH-WG] problem statement

On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: 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

Re: [OAUTH-WG] problem statement

On 9/6/11 6:33 PM, Michael Thomas wrote: > On 09/06/2011 05:23 PM, Peter Saint-Andre wrote: >> On 9/6/11 4:22 PM, Melinda Shore wrote: >> >>> On 09/06/2011 12:59 PM, John Kemp wrote: >>> The point is that you have a point. >>> He does, and that's in some large part why I d

Re: [OAUTH-WG] problem statement

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 y

Re: [OAUTH-WG] problem statement

On 9/6/11 6:50 PM, Melinda Shore wrote: > On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: >> 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 say

Re: [OAUTH-WG] problem statement

On 09/06/2011 06:08 PM, Peter Saint-Andre wrote: Put me in the "may not have been avoided" camp. We can't legislate 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 co

Re: [OAUTH-WG] problem statement

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 On Sep 6, 2011, at 18:13, "Michael Thomas" wrote: > On 09/06/2011 06:08 PM

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] problem statement

On 09/06/2011 06:24 PM, Eran Hammer-Lahav wrote: 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. Didn't you just get done a

Re: [OAUTH-WG] problem statement

*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

Re: [OAUTH-WG] problem statement

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 th

Re: [OAUTH-WG] Auth Code Swap Attack

Eran, Just took a look at the text. This new version looks much improved. I think this is a good compromise. Thanks, Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-04, at 4:25 PM, Eran Hammer-Lahav wrote: > The corresponding 'state' parameter definition: > >

Re: [OAUTH-WG] problem statement

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

Re: [OAUTH-WG] Auth Code Swap Attack

Perfect. Thanks Phil. EHL On Sep 6, 2011, at 20:42, "Phil Hunt" wrote: > Eran, > > Just took a look at the text. This new version looks much improved. I think > this is a good compromise. > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011