Of David Recordon
Sent: Saturday, September 10, 2011 1:29 PM
To: Michael Thomas
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] problem statement
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
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
On 09/06/2011 08:52 PM, Manger, James H wrote:
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
+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.,
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)
Mike,
On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote:
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
On 09/07/2011 10:49 AM, John Kemp wrote:
Mike,
On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote:
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
Good eye! Seeing this now, I agree, but I admit I never fully
understood what embedded uses-agents were before.
Igor
On 9/6/2011 11:52 PM, Manger, James H wrote:
A strange aspects of this thread is that the current draft already talks about
exactly this issue:
draft-ietf-oauth-v2-21
On Sep 7, 2011, at 12:02 PM, Michael Thomas wrote:
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.
The
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
On 09/07/2011 10:22 AM, Phil Hunt wrote:
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.
On 9/7/11 12:34 PM, Melinda Shore wrote:
On 09/07/2011 10:22 AM, Phil Hunt wrote:
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
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
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
On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:
[more browbeating elided]
In fact, you guys have convinced me that OAuth gives inferior
protection at
considerable expense for all concerned.
an irresponsible and serious offense - the kind of baseless FUD that can cause
real damage to
I would ask the chairs to keep personal attacks in check.
Thank you.
Mike
On 09/07/2011 12:23 PM, Aiden Bell wrote:
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
On 7 September 2011 20:24, Michael Thomas m...@mtcc.com wrote:
On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:
[more browbeating elided]
In fact, you guys have convinced me that OAuth gives inferior protection
at
considerable expense for all concerned.
an irresponsible and serious
On 9/7/11 1:24 PM, Michael Thomas wrote:
On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:
[more browbeating elided]
In fact, you guys have convinced me that OAuth gives inferior
protection at
considerable expense for all concerned.
an irresponsible and serious offense - the kind
On 09/07/2011 12:32 PM, Peter Saint-Andre wrote:
On 9/7/11 1:24 PM, Michael Thomas wrote:
On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:
[more browbeating elided]
In fact, you guys have convinced me that OAuth gives inferior
protection at
considerable expense for all
: [OAUTH-WG] problem statement
On 09/07/2011 10:22 AM, Phil Hunt wrote:
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
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
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
Mike,
On 7 Sep 2011, at 21:17, Michael Thomas wrote:
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
On 09/07/2011 05:19 PM, Ben Niven-Jenkins 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
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
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
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 igor.faynb...@alcatel-lucent.com
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
oauth,
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
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
: 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
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,
:* 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
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 m...@mtcc.com wrote:
Eran Hammer-Lahav wrote:
I agree. If you are
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 in
in
investing in your company.
From: Michael Thomas m...@mtcc.com
To: Eran Hammer-Lahav e...@hueniverse.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Tuesday, September 6, 2011 11:34 AM
Subject: Re: [OAUTH-WG] problem statement
Eran Hammer-Lahav wrote:
Don't install crap
I'm dismissive of this being an OAuth problem.
EHL
On Sep 6, 2011, at 11:35, Michael Thomas m...@mtcc.com 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
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
@ietf.org
*Sent:* Tuesday, September 6, 2011 11:34 AM
*Subject:* 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
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
@ietf.org
*Sent:* Tuesday, September 6, 2011 11:34 AM
*Subject:* 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
:* 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
...@hueniverse.com
*Cc:* oauth@ietf.org oauth@ietf.org
*Sent:* Tuesday, September 6, 2011 11:34 AM
*Subject:* 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
...@hueniverse.commailto:e...@hueniverse.com
Cc: igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com
igor.faynb...@alcatel-lucent.commailto:igor.faynb...@alcatel-lucent.com,
oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] problem statement
Eran
-lucent.com igor.faynb...@alcatel-lucent.commailto:
igor.faynb...@alcatel-lucent.com, oauth@ietf.orgmailto:oauth@ietf.org
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] problem statement
Eran Hammer-Lahav wrote:
I'm dismissive of this being an OAuth problem.
Which brings us back to my
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
oauth@ietf.org mailto:oauth@ietf.org
Subject: 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
-0700
To: oauth@ietf.orgmailto:oauth@ietf.org
oauth@ietf.orgmailto:oauth@ietf.org
Subject: 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
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
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
mailto:melinda.sh...@gmail.com
Date: Tue, 6 Sep 2011 12:18:18 -0700
To: oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org
mailto:oauth@ietf.org
Subject: 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
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
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
...@hueniverse.com
*Cc:* oauth@ietf.orgoauth@ietf.org
*Sent:* Tuesday, September 6, 2011 11:34 AM
*Subject:* 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
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
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
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 is? I
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
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 browsers
...@yahoo-inc.com
Cc: Eran Hammer-Lahav e...@hueniverse.com; oauth@ietf.org oauth@ietf.org
Sent: Tuesday, September 6, 2011 11:50 AM
Subject: 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
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
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 possible,
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
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
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
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
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
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
Wg consensus is clearly to do nothing here.
EHL
On Sep 6, 2011, at 17:05, Michael Thomas m...@mtcc.com 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
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,
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
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
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
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 don't
fully
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
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 says
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
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 m...@mtcc.com wrote:
On
: [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
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
*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
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
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
83 matches
Mail list logo
