Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Hi Michael Can you clearly word the threat for which this countermeasure (or lack of) applies thanks Mark Michael Thomas m...@mtcc.com wrote on 03/01/2012 23:52:54: From: Michael Thomas m...@mtcc.com To: Phillip Hunt phil.h...@oracle.com Cc: Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba barryle...@computer.org, oauth WG oauth@ietf.org, oauth- boun...@ietf.org oauth-boun...@ietf.org Date: 03/01/2012 23:53 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/03/2012 03:46 PM, Phillip Hunt wrote: -1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. My responsibility, such as it is, is to bring up that the document's threat mitigations suggested don't work. I am only a recent and reluctant participant, versus the principals of this working group who have been around for many years. But if you insist, here's my concise suggestion to that points that I raised objections to: No known mitigation exists. Mike Phil On 2012-01-03, at 15:18, Michael Thomasm...@mtcc.com wrote: Barry -- It's now been two weeks and I haven't heard anything to the objections I raised. It is not my responsibility to come up with mitigation that works, it's the working group's. If there is no reasonable mitigation it should just say that. Mike On 12/16/2011 06:55 AM, Michael Thomas wrote: On 12/16/2011 03:02 AM, Mark Mcgloin wrote: Michael, I will review the comments from Phil where he suggests some changes in section 4.1.4 of the threat model I am unclear exactly what you are proposing. If you want to propose a clearly worded revamp of that section in the next couple of days, I am willing to review and accept legitimate changes. Clearly worded means concise, technically accurate and devoid of alarmist phrases and words used out of context, such as existential. Can I suggest you review with a colleague before posting here. Barry -- I have gone through this section and made comments and was blown off seemingly without reading them at all, and now I'm being told to come up with text for which I can be blown off again: Can I suggest you review... The fact of the matter is that my comments say that the threats are understated and mitigations that are proposed do not work. It's not my job alone to fix this. It's the working group's. In fact if I were to propose text, it would be along the lines of can't be mitigated because I do not know how to fix them. If nobody else can come up with a better mitigation, then that *is* what should be there, not some hand waving nonsense that doesn't work. Mike, instruct users... feh Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: From: Michael Thomasm...@mtcc.com To: Phil Huntphil.h...@oracle.com Cc: Barry Leibabarryle...@computer.org, oauth WGoauth@ietf.org Date: 15/12/2011 18:16 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Sent by: oauth-boun...@ietf.org On 12/15/2011 09:54 AM, Phil Hunt wrote: Note: one change recommended below... With regards to 4.1.4… 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. [Phil] I don't think we need to really add much here. We could write whole essays on this topic and likely will. I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential). [/Phi] Remember: I came here not understanding whether this threat was real or not. A threat document that can't be
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 03:42 AM, Mark Mcgloin wrote: Hi Michael Can you clearly word the threat for which this countermeasure (or lack of) applies I've already done that in my original last call comments. Given that you rejected my comments out of hand, it doesn't appear that it was for lack of clarity. Mike, rather put off by the attitude of the editors in this wg thanks Mark Michael Thomasm...@mtcc.com wrote on 03/01/2012 23:52:54: From: Michael Thomasm...@mtcc.com To: Phillip Huntphil.h...@oracle.com Cc: Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba barryle...@computer.org, oauth WGoauth@ietf.org, oauth- boun...@ietf.orgoauth-boun...@ietf.org Date: 03/01/2012 23:53 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/03/2012 03:46 PM, Phillip Hunt wrote: -1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. My responsibility, such as it is, is to bring up that the document's threat mitigations suggested don't work. I am only a recent and reluctant participant, versus the principals of this working group who have been around for many years. But if you insist, here's my concise suggestion to that points that I raised objections to: No known mitigation exists. Mike Phil On 2012-01-03, at 15:18, Michael Thomasm...@mtcc.com wrote: Barry -- It's now been two weeks and I haven't heard anything to the objections I raised. It is not my responsibility to come up with mitigation that works, it's the working group's. If there is no reasonable mitigation it should just say that. Mike On 12/16/2011 06:55 AM, Michael Thomas wrote: On 12/16/2011 03:02 AM, Mark Mcgloin wrote: Michael, I will review the comments from Phil where he suggests some changes in section 4.1.4 of the threat model I am unclear exactly what you are proposing. If you want to propose a clearly worded revamp of that section in the next couple of days, I am willing to review and accept legitimate changes. Clearly worded means concise, technically accurate and devoid of alarmist phrases and words used out of context, such as existential. Can I suggest you review with a colleague before posting here. Barry -- I have gone through this section and made comments and was blown off seemingly without reading them at all, and now I'm being told to come up with text for which I can be blown off again: Can I suggest you review... The fact of the matter is that my comments say that the threats are understated and mitigations that are proposed do not work. It's not my job alone to fix this. It's the working group's. In fact if I were to propose text, it would be along the lines of can't be mitigated because I do not know how to fix them. If nobody else can come up with a better mitigation, then that *is* what should be there, not some hand waving nonsense that doesn't work. Mike, instruct users... feh Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: From: Michael Thomasm...@mtcc.com To: Phil Huntphil.h...@oracle.com Cc: Barry Leibabarryle...@computer.org, oauth WGoauth@ietf.org Date: 15/12/2011 18:16 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Sent by: oauth-boun...@ietf.org On 12/15/2011 09:54 AM, Phil Hunt wrote: Note: one change recommended below... With regards to 4.1.4… 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. [Phil] I don't think we need to really add much here. We could write whole essays on this topic and likely will. I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential). [/Phi]
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 11:47 AM, Peter Saint-Andre wrote: I've already done that in my original last call comments. Given that you rejected my comments out of hand, it doesn't appear that it was for lack of clarity. Mike, rather put off by the attitude of the editors in this wg Mike: In my experience, the IETF tradition is not to passively complain, but to actively contribute. Thus if I don't like the fact that there's no specification for some feature or protocol I care about, it's my responsibility to write an Internet-Draft to fill that gap. Similarly, if I have concerns about someone else's Internet-Draft, it's incumbent on me to propose new or alternative text. Sure, I could wait for the authors, editors, working group chairs, or area directors to take action, but you will have much greater success if you actively contribute. I am not an IETF noob. The problem here is that I DO NOT KNOW HOW TO MITIGATE THE THREATS I brought up as inadequately mitigated in the threat draft. I don't know how I can state that more plainly. I would *hope* that the participants of this working group who have been working on this for years could do a better job. But if they can't then the threat draft should just say that there is no known defense instead of feel-good things like educate users. And I completely disagree that this isn't active participation. It denigrates draft reviewers as being lesser participants. Nor does it match IETF reality: cross area reviewers typically just point out the problems and leave it to the working group participants to work it out. Same goes for an IESG DISCUSS. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
I have asked you to clearly describe the threat, not the mitigation. It obviously was either not clear or convincing the first time and I am not going to start digging through emails when you clearly understand it. To try to shortcut this: Mike did lay it out clearly, I think, in his first note (which I linked at the beginning of this thread), and that should be the only one that needs to be read to understand his point. The basic point is that the OAuth framework relies on both the end user and the authorization server being able to trust the user's UA. If that winds up being a compromised browser or a native application that the user perhaps unwisely installed, all the security in the framework goes out the window, because an untrustworthy UA can fiddle with pretty much everything. Mike's note said much more than that, but I think I've encapsulated things in an oversimplified version above. I agree that this is something that needs to be made very clear... and that I don't see any way to mitigate it -- it's basically an aspect of what we're working with here. I don't think this is a difficult issue to document, and perhaps two paragraphs should be enough to do it. Identifying the right place and the right two paragraphs should be something that a combination of Mike and the documnet editors can do, if you can do it without getting on each others' nerves. :-) Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 12:41 PM, Barry Leiba wrote: up being a compromised browser or a native application that the user perhaps unwisely installed, all the security in the framework goes out ^ the window, because an untrustworthy UA can fiddle with pretty much everything. I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
You are correct. the Core spec should include this. However for one reason or
another it is not in the core spec and probably will not be, given that it is
in last call.
One way or other we need to identify the correct answer.
John B.
On 2012-01-03, at 5:37 PM, William Mills wrote:
OK, then the core spec should.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Sorry, I should have been more precise. The Core spec doesn’t define how to
transmit these fields in the WWW-Authenticate response header field. The
Bearer spec does.
-- Mike
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly
has these as predefined registered parameters. If the definition there isn't
strong enough, or in that spec, we should fix that. That is where these
should be defined.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
The core spec doesn’t include these parameters.
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Why is Bearer dealing with this at all? the BNF for that stuff should be
part of the core spec, and additional values perhaps defined in Bearer.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From: Mike Jones michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus
with the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
On 2012-01-04 22:40, John Bradley wrote: You are correct. the Core spec should include this. However for one reason or another it is not in the core spec and probably will not be, given that it is in last call. ... The datatracker says: AD Evaluation::Revised ID Needed (https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/) As far as I recall, this includes other changes needed by the bearer spec. Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Don't get me wrong, I agree that it should be in core. I just don't want to hold up core for something that only bearer seems to care about. If there is consensus that it should be fixed in core then lets do that rather than leaving it up to bearer, MAC and token types not yet imagined to do it independently. John B. On 2012-01-04, at 7:01 PM, Julian Reschke wrote: On 2012-01-04 22:40, John Bradley wrote: You are correct. the Core spec should include this. However for one reason or another it is not in the core spec and probably will not be, given that it is in last call. ... The datatracker says: AD Evaluation::Revised ID Needed (https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/) As far as I recall, this includes other changes needed by the bearer spec. Best regards, Julian smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. The key question is: Why do we aim on keeping user credentials out of the hands of an untrusted third party? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. --- It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. --- wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? A typical mobile application consists of the app itself on the device and a corresponding backend service storing user data and implementing business and integration logic. Let's assume this application features address book import from other service providers. W/o OAuth, the app would gather the end-user's credential for a certain address book service and pass it to its backend service. This service in turn uses this credentials to access the service provider's API. So in such a scenario the following parties get in touch with the user credentials: - the app - the app's backend service - the address book resource server What threats do you see here? And which is most likely to occur? My favorite is an attack against the log files or the database of the backend service in order to obtain the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app installation on a device and the protective measure on the resource server might be more appropriate then on the client side (backend service). OAuth mitigates this kind of attack by reducing the number of parties handling user credentials to the authorization server and the user agent. So even if the app itself would be the user agent (which is not recommended), it would directly interact with the authorization server and the app's backend service would use tokens instead of end-user credentials. Moreover, the recommended way is to let the app delegate the flow to a trusted system component on the user's device, such as the system browser or an account manager. In that case, the 3rd party is not getting in touch with the user credentials at all. I think the key question is whether anyone expects OAuth to solve the phishing problem. I don't think this is its main purpose, but it could facilitate to overcome the habit to enter user credentials everywhere. And this in turn may contribute to the fight against phishing. regards, Torsten. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
There are actually two parts to this as I see it: 1. Defining the syntax for the acceptable contents of the scope, error, error_description, and error_uri parameters. 2. Defining the means by which these values are transmitted in WWW-Authenticate response header fields for Bearer tokens. I would be fine seeing part 1 added to the core spec. (In fact, there is a tracked issue OAuth ticket 27http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 requiring that this occur for the scope parameter.) Given that the core spec is, by design, agnostic of the method used to access protected resource (including being agnostic of the use of the WWW-Authenticate field by the Bearer spec), I believe that it would be inappropriate to add part 2 to the core spec. Cheers, -- Mike From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Wednesday, January 04, 2012 1:40 PM To: William Mills Cc: Mike Jones; Julian Reschke; Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? You are correct. the Core spec should include this. However for one reason or another it is not in the core spec and probably will not be, given that it is in last call. One way or other we need to identify the correct answer. John B. On 2012-01-03, at 5:37 PM, William Mills wrote: OK, then the core spec should. From: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, January 3, 2012 12:20 PM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Sorry, I should have been more precise. The Core spec doesn't define how to transmit these fields in the WWW-Authenticate response header field. The Bearer spec does. -- Mike From: William Mills [mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 03, 2012 12:14 PM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has these as predefined registered parameters. If the definition there isn't strong enough, or in that spec, we should fix that. That is where these should be defined. From: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, January 3, 2012 12:00 PM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? The core spec doesn't include these parameters. From: William Mills [mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 03, 2012 12:00 PM To: Mike Jones; Julian Reschke Cc: Mark Nottingham; Barry Leiba; OAuth WG Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Why is Bearer dealing with this at all? the BNF for that stuff should be part of the core spec, and additional values perhaps defined in Bearer. From: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, January 3, 2012 11:46 AM Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? This is about the syntax for the scope, error, and error_description parameters. The pertinent text from Section 3 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15#section-3 is: Producers of scope strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of error and error_description strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of error-uri strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
On 2012-01-04 23:17, Mike Jones wrote: There are actually two parts to “this” as I see it: 1. Defining the syntax for the acceptable contents of the scope, error, error_description, and error_uri parameters. 2. Defining the means by which these values are transmitted in WWW-Authenticate response header fields for Bearer tokens. I would be fine seeing part 1 added to the core spec. (In fact, there is a tracked issue OAuth ticket 27 http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 requiring that this occur for the scope parameter.) Given that the core spec is, by design, agnostic of the method used to access protected resource (including being agnostic of the use of the WWW-Authenticate field by the Bearer spec), I believe that it would be inappropriate to add part 2 to the core spec. ... +1 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. My concern is that putting on a veneer of security will lull people into thinking Oh, it's safe to enter my credentials here because this is really twitterbook, not evilapp!. When I had to ask them directly to put their twitterbook credentials into my app, there at least wasn't any confusion that I had access to them. Realistically, what you've done is protected the credentials from the good guys and not changed much for a motivated bad guy. Is that an improvement? I'll buy that it's generally bad practice for good guys with most likely bad security chops to be storing credentials, but I'm guessing that the original OAUTH motivation was more toward thwarting bad guys. The key question is: Why do we aim on keeping user credentials out of the hands of an untrusted third party? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. The draft says: o Client applications could be validated prior publication in a application market. I asked -- and didn't get a response -- about how exactly that might be done. I suspect that in practice for the twitterbook universe that there is no way that scales. So the reality here seems to be there isn't an answer for the Internet at large, and the threats document should just say that mitigation MAY be possible in very narrow use cases where code reviews, and other heavy handed analysis can be performed, but for the general case there is no mitigation. As far as 4.4.1.4 goes, I'd say that the counter measures really don't help except maybe for auditing. If that's what they're really about, the draft should make that explicit. Also on the subject of 4.4.1.4, this bullet: o If the authorization server automatically authenticates the end- user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs or user-specific secret like PIN codes. I'm very skeptical because a native environment is a social engineering nirvana. The CAPTCHA could easily be shown to the user and they'd blissfully solve it just like they do any other one. --- 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. --- I assume that it's in the authorization server's _interest_ to not divulge user credentials to potentially evil third parties. If it's not, why would you go to the trouble of implementing OAUTH at all? This is what's so troubling to me. The point is to keep user credentials away from bad guys, but when shown how OAUTH in widely deployed scenarios fails to do that, the response I get from the working group is Not Our Problem. Well it *is* your problem insofar as you are not advising the twitterbooks to disallow native apps as clients, for example. wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? A typical mobile application consists of the app itself on the device and a corresponding backend service
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
I think the threat draft should simply say, OAuth does not and can not protect the user against credential compromise as a result of phishing, malware, social engineering, or machine compromise. Get rid of the fancy rhetoric, we don't need to explain a lot more than this. I don't agree that OAuth purports to solve these problems. What it solves is limiting the credentials granted to allow the user more control and limited damage in the event of credential misuse. -bill From: Michael Thomas m...@mtcc.com To: Barry Leiba barryle...@computer.org Cc: oauth WG oauth@ietf.org Sent: Wednesday, January 4, 2012 1:06 PM Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/04/2012 12:41 PM, Barry Leiba wrote: up being a compromised browser or a native application that the user perhaps unwisely installed, all the security in the framework goes out ^ the window, because an untrustworthy UA can fiddle with pretty much everything. I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Then we need to make this a last call issue.
From: John Bradley ve7...@ve7jtb.com
To: William Mills wmi...@yahoo-inc.com
Cc: Mike Jones michael.jo...@microsoft.com; Julian Reschke
julian.resc...@gmx.de; Mark Nottingham m...@mnot.net; Barry Leiba
barryle...@computer.org; OAuth WG oauth@ietf.org
Sent: Wednesday, January 4, 2012 1:40 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
You are correct. the Core spec should include this. However for one reason or
another it is not in the core spec and probably will not be, given that it is
in last call.
One way or other we need to identify the correct answer.
John B.
On 2012-01-03, at 5:37 PM, William Mills wrote:
OK, then the core spec should.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Sorry, I should have been more precise. The Core spec doesn’t define how to
transmit these fields in the WWW-Authenticate response header field. The
Bearer spec does.
-- Mike
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has
these as predefined registered parameters. If the definition there isn't
strong enough, or in that spec, we should fix that. That is where these
should be defined.
From:Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
The core spec doesn’t include these parameters.
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Why is Bearer dealing with this at all? the BNF for that stuff should be part
of the core spec, and additional values perhaps defined in Bearer.
From:Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From:Mike Jones michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Does Bearer really have to go there? Can it simply be pulled form Bearer? From: John Bradley ve7...@ve7jtb.com To: Julian Reschke julian.resc...@gmx.de Cc: William Mills wmi...@yahoo-inc.com; Barry Leiba barryle...@computer.org; Mark Nottingham m...@mnot.net; OAuth WG oauth@ietf.org Sent: Wednesday, January 4, 2012 2:10 PM Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? Don't get me wrong, I agree that it should be in core. I just don't want to hold up core for something that only bearer seems to care about. If there is consensus that it should be fixed in core then lets do that rather than leaving it up to bearer, MAC and token types not yet imagined to do it independently. John B. On 2012-01-04, at 7:01 PM, Julian Reschke wrote: On 2012-01-04 22:40, John Bradley wrote: You are correct. the Core spec should include this. However for one reason or another it is not in the core spec and probably will not be, given that it is in last call. ... The datatracker says: AD Evaluation::Revised ID Needed (https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/) As far as I recall, this includes other changes needed by the bearer spec. Best regards, Julian___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
o Client applications could be validated prior publication in a application market. Should just be struck. Michael is correct that it's fluff, and unenforceable. There are too many app marketplaces, opensource projects, etc. to make this a useful suggestion. From: Michael Thomas m...@mtcc.com To: Torsten Lodderstedt tors...@lodderstedt.net Cc: Barry Leiba barryle...@computer.org; oauth WG oauth@ietf.org Sent: Wednesday, January 4, 2012 3:40 PM Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/04/2012 02:14 PM, Torsten Lodderstedt wrote: Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. My concern is that putting on a veneer of security will lull people into thinking Oh, it's safe to enter my credentials here because this is really twitterbook, not evilapp!. When I had to ask them directly to put their twitterbook credentials into my app, there at least wasn't any confusion that I had access to them. Realistically, what you've done is protected the credentials from the good guys and not changed much for a motivated bad guy. Is that an improvement? I'll buy that it's generally bad practice for good guys with most likely bad security chops to be storing credentials, but I'm guessing that the original OAUTH motivation was more toward thwarting bad guys. The key question is: Why do we aim on keeping user credentials out of the hands of an untrusted third party? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. The draft says: o Client applications could be validated prior publication in a application market. I asked -- and didn't get a response -- about how exactly that might be done. I suspect that in practice for the twitterbook universe that there is no way that scales. So the reality here seems to be there isn't an answer for the Internet at large, and the threats document should just say that mitigation MAY be possible in very narrow use cases where code reviews, and other heavy handed analysis can be performed, but for the general case there is no mitigation. As far as 4.4.1.4 goes, I'd say that the counter measures really don't help except maybe for auditing. If that's what they're really about, the draft should make that explicit. Also on the subject of 4.4.1.4, this bullet: o If the authorization server automatically authenticates the end- user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs or user-specific secret like PIN codes. I'm very skeptical because a native environment is a social engineering nirvana. The CAPTCHA could easily be shown to the user and they'd blissfully solve it just like they do any other one. --- 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. --- I assume that it's in the authorization server's _interest_ to not divulge user credentials to potentially evil third parties. If it's not, why would you go to the trouble
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 03:42 PM, William Mills wrote: I think the threat draft should simply say, OAuth does not and can not protect the user against credential compromise as a result of phishing, malware, social engineering, or machine compromise. I could live with something like this, but I think it needs to be much more explicit that it applies to any authentication service that allows native apps as clients with no form of strong app vetting. It may even be useful to point to a couple of large deployments who are at risk from this, like, oh say, twitterbook. If this draft doesn't take a strong stand against that practice, it's doing nothing more than giving a wink and a nod that what twitterbook is currently doing is safe. That's bad, but I suspect it's the elephant in the room. Mike Get rid of the fancy rhetoric, we don't need to explain a lot more than this. I don't agree that OAuth purports to solve these problems. What it solves is limiting the credentials granted to allow the user more control and limited damage in the event of credential misuse. -bill -- *From:* Michael Thomas m...@mtcc.com *To:* Barry Leiba barryle...@computer.org *Cc:* oauth WG oauth@ietf.org *Sent:* Wednesday, January 4, 2012 1:06 PM *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/04/2012 12:41 PM, Barry Leiba wrote: up being a compromised browser or a native application that the user perhaps unwisely installed, all the security in the framework goes out ^ the window, because an untrustworthy UA can fiddle with pretty much everything. I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? Mike ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
The below is unfortunately probably a no-go: Given these threats, authentication servers MUST NOT give clients access to authentication services -- and by extension to resource services -- unless the authentication service can thoroughly vet the trustworthiness of the client. How that vetting is achieved is outside of the scope of this document, but the current practice of freely giving client keys to any would-be OAUTH client is not sufficient. It's unfortunately not really a solved problem for widely distributed clients. I attack this by spoofing a known client and the resource server or auth server can't tell the difference. That's why I was falling back to the more brutal this doesn't protect you from ... statement. Native mobile clients where the default experience is likely to be not to spawn a browser for the interaction are going to be a real problem too. Auth servers (I think that's where you get the best control) can do their best to keep track of what clients a user has authenticated and prompt the user on a new client, but it's still up to the user to make sure they're not being lied to, and in practice this is only marginally effective (and tends in fact to slow adoption with a scary message, so product type folks don't like it). -bill From: Michael Thomas m...@mtcc.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth WG oauth@ietf.org; Barry Leiba barryle...@computer.org Sent: Wednesday, January 4, 2012 4:39 PM Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 On 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Michael Thomas Sent: Wednesday, January 04, 2012 3:40 PM My concern is that putting on a veneer of security will lull people into thinking Oh, it's safe to enter my credentials here because this is really twitterbook, not evilapp!. When I had to ask them directly to put their twitterbook credentials into my app, there at least wasn't any confusion that I had access to them. This is ridiculous (e.g. the fact we are still discussing this). First, end users know nothing about security or OAuth. Second, evil apps can create this veneer of security by faking a redirection flow with or without OAuth. Suggesting that OAuth (which is a de-facto web pattern for over a decade) makes anything worse is patently false. The only thing we can possibly add to the threat model document is to mention that OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed. That is accurate (and completely obvious to the target audience of this document). It is not very helpful but if it will make you feel better (since no one else here seems to share your concerns), I have no objection to such one line added. And again, to highlight the absurdity of your security claim, it is equally important to warn developers in earthquake-prone countries to put enough distance between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor. It's this kind of hostility and ad hominem that leads me to believe that you have forgotten some of your lessons in charm school. For one, I am not the only one and even if I were that would still not be a reason to shoot the messenger. Secondly it is *not* the sole responsibility of the end user: the authentication server absolutely has a part to play here too. They have to give out client keys, after all, and its their service that could be hacked. So they have as much if not more responsibility than the end user. So to Bill's request here is the text I would propose. Native apps, not limited to, but including apps which are available on popular mobile app stores, have the potential for gaining access to the end user's credentials. This can be accomplished by gaining access to browser UI components and key logging, spoofing the look and feel of an authentication server's authentication page, and potentially many other social engineering attacks. The potential for these attacks exist in many existing OAUTH2 deployments including but not limited to Facebook and Twitter. Given these threats, authentication servers MUST NOT give clients access to authentication services -- and by extension to resource services -- unless the authentication service can thoroughly vet the trustworthiness of the client. How that vetting is achieved is outside of the scope of this document, but the current practice of freely giving client keys to any would-be OAUTH client is not sufficient. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ OAuth mailing list OAuth@ietf.org
