[OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Working group last call begins today on the threat model document: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 Please review this version and post last call comments by 9 December. Barry, as chair ___ 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
> Working group last call begins today on the threat model document: > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 > > Please review this version and post last call comments by 9 December. Here's a reminder that we have about a week left for the working group last call on this, and I haven't seen any comments since WGLC started. That's OK, if it's because there are no comments. If you have something to say, say it now, please. If the document really is ready to go, then that's great. Barry, chairing ___ 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
> Working group last call begins today on the threat model document: > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 > > Please review this version and post last call comments by 9 December. Sorry, folks: I got a little behind here. Working-group last call is now over. There were no comments in response to this thread, so it looks like we're mostly done here. Mike Thomas pointed out to me that his message here: http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html ...was in reference to this document -- that might not have been clear because of the change in subject line. Torsten, et al, consider that message to be your only working-group last call comment, and handle it accordingly. When that's worked out and there's another version, we should be ready to send this up to the IESG. Barry, as chair ___ 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
Thanks Barry - I just responded to that thread. We will not be making any changes to the threat model based on that comment Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 14:30:02: > From: > > Barry Leiba > > To: > > oauth WG > > Date: > > 15/12/2011 14:30 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-boun...@ietf.org > > > Working group last call begins today on the threat model document: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 > > > > Please review this version and post last call comments by 9 December. > > Sorry, folks: I got a little behind here. > > Working-group last call is now over. There were no comments in > response to this thread, so it looks like we're mostly done here. > Mike Thomas pointed out to me that his message here: > >http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html > > ...was in reference to this document -- that might not have been clear > because of the change in subject line. Torsten, et al, consider that > message to be your only working-group last call comment, and handle it > accordingly. When that's worked out and there's another version, we > should be ready to send this up to the IESG. > > Barry, as chair > ___ > 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] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
This hasn't been addressed: http://www.ietf.org/mail-archive/web/oauth/current/msg07867.html Perhaps no one thinks it is a problem? There are several grammatical nits that should be fixed. I've had all the best intentions of reporting those last week but simply have not yet had the time. Regards, Andre DeMarre On Thu, Dec 15, 2011 at 6:30 AM, Barry Leiba wrote: >> Working group last call begins today on the threat model document: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 >> >> Please review this version and post last call comments by 9 December. > > Sorry, folks: I got a little behind here. > > Working-group last call is now over. There were no comments in > response to this thread, so it looks like we're mostly done here. > Mike Thomas pointed out to me that his message here: > > http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html > > ...was in reference to this document -- that might not have been clear > because of the change in subject line. Torsten, et al, consider that > message to be your only working-group last call comment, and handle it > accordingly. When that's worked out and there's another version, we > should be ready to send this up to the IESG. > > Barry, as chair > ___ > 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] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
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] [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the "lock" icon without announcement. When I found out, I had already been using it for some time and hadn't noticed. This counter measure should be changed to: o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow. [/Phil] o Client applications could be validated prior publication in a application market. [mat] How would this be done in practice? [Phil] I think this needs to change to: o Client applications could be validated for acceptable practices by the Resource Site provider prior to issuing production Client Credentials. [/Phil] o Client developers should not collect authentication information directly from users and should instead use redirects to and back from a trusted external system-browser. [mat] How would the resource/authentication server enforce such a thing? [Phil] This is a best practice for the client developer. [Phil] [snip] Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-12-15, at 6:30 AM, Barry Leiba wrote: >> Working group last call begins today on the threat model document: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01 >> >> Please review this version and post last call comments by 9 December. > > Sorry, folks: I got a little behind here. > > Working-group last call is now over. There were no comments in > response to this thread, so it looks like we're mostly done here. > Mike Thomas pointed out to me that his message here: > > http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html > > ...was in reference to this document -- that might not have been clear > because of the change in subject line. Torsten, et al, consider that > message to be your only working-group last call comment, and handle it > accordingly. When that's worked out and there's another version, we > should be ready to send this up to the IESG. > > Barry, as chair > ___ > 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] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 12/15/2011 09:54 AM, Phil Hunt wrote: Note: one change recommended below... With regards to 4.1.4… 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. [Phil] I don't think we need to really add much here. We could write whole essays on this topic and likely will. I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential). [/Phi] Remember: I came here not understanding whether this threat was real or not. A threat document that can't be bothered to elaborate on one of the biggest existential threats to the protocol is worthless. The way it is worded now does not make it crystal clear that, yes, this means UIWebView's in iPhone apps, etc too. It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH SERVER. [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the "lock" icon without announcement. When I found out, I had already been using it for some time and hadn't noticed. This counter measure should be changed to: o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow. [/Phil] The basic problem here is that the client app is not trusted. So if it's a bad actor this admonition will be ignored. If it's a good actor, there wasn't a threat in first place. So the mitigation completely misses the mark. o Client applications could be validated prior publication in a application market. [mat] How would this be done in practice? [Phil] I think this needs to change to: o Client applications could be validated for acceptable practices by the Resource Site provider prior to issuing production Client Credentials. When, exactly, can we expect to see this in the field? Neither Twitter or Facebook do this. And even if they were so inclined, the draft provides exactly zero guidance as to what exactly that "validated" might mean in practice. The way I read this is: "we don't know how to mitigate this". [/Phil] o Client developers should not collect authentication information directly from users and should instead use redirects to and back from a trusted external system-browser. [mat] How would the resource/authentication server enforce such a thing? [Phil] This is a best practice for the client developer. [Phil] I don't even know what that means in the context of embedded apps. Has anybody even tried this? At the very least, an example flow might be useful for the uninitiated client developer. Mike ___ OAuth mailing list 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
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. Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: > From: > > Michael Thomas > > To: > > Phil Hunt > > Cc: > > Barry Leiba , oauth WG > > 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 bothered to elaborate on one of the biggest > existential threats to the protocol is worthless. The way it is worded > now does > not make it crystal clear that, yes, this means UIWebView's in iPhone > apps, etc too. > It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH > SERVER. > > > > [snip] > > > > Countermeasures: > > > > o Client developers and end-user can be educated to trust an > >external System-Browser only. > > > > > > [mat] I assume that this is in here just for the amusement factor because > > it is not a credible countermeasure. > > > > [Phil] I agree, Firefox recently demonstrated how poorly users > recognize the security signals in the browser by dropping the "lock" > icon without announcement. When I found out, I had already been > using it for some time and hadn't noticed. This counter measure > should be changed to: > > > > o The OAuth flow is designed so that client applications never > need to know user passwords. Where possible Client applications > SHOULD avoid directly asking for user credentials during an > authorization flow. > > [/Phil] > > > > The basic problem here is that the client app is not trusted. So if it's > a bad > actor this admonition will be ignored. If it's a good actor, there > wasn't a threat > in first place. So the mitigation completely misses the mark. > > > o Client applications could be validated prior publication in a > >application market. > > > > [mat] How would this be done in practice? > > [Phil] I think this needs to change to: > > > > o Client applications could be validated for acceptable practices > by the Resource Site provider prior to issuing production Client Credentials. >
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
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 Thomas To: Phil Hunt Cc: Barry Leiba, oauth WG 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 bothered to elaborate on one of the biggest existential threats to the protocol is worthless. The way it is worded now does not make it crystal clear that, yes, this means UIWebView's in iPhone apps, etc too. It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH SERVER. [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the "lock" icon without announcement. When I found out, I had already been using it for some time and hadn't noticed. This counter measure should be changed to: o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow. [/Phil] The basic problem here is that the client app is not trusted. So if it's a bad actor this admonition will be ignored. If it's a good actor, there wasn't a threat in first place. So the mitigation completely misses the mark. o Client applicati
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
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 Thomas To: Phil Hunt Cc: Barry Leiba, oauth WG 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 bothered to elaborate on one of the biggest existential threats to the protocol is worthless. The way it is worded now does not make it crystal clear that, yes, this means UIWebView's in iPhone apps, etc too. It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH SERVER. [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the "lock" icon without announcement. When I found out, I had already been using it for some time and hadn't noticed. This counter measure should be changed to: o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow. [/Phil] The basic problem here is that the client app is not trusted. So if it's a bad actor this admonition will be ignored. If it's a good actor, there wasn't a threa
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
-1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. Phil On 2012-01-03, at 15:18, Michael Thomas 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 Thomas >>>> >>>> To: >>>> >>>> Phil Hunt >>>> >>>> Cc: >>>> >>>> Barry Leiba, oauth WG >>>> >>>> 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 t
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 Thomas 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 Thomas To: Phil Hunt Cc: Barry Leiba, oauth WG 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 bothered to elaborate on one of the biggest existential threats to the protocol is worthless. The way it is worded now does not make it crystal clear that, yes, this means UIWebView's in iPhone apps, etc too. It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH SERVER. [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the secur
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 wrote on 03/01/2012 23:52:54: > From: > > Michael Thomas > > To: > > Phillip Hunt > > Cc: > > Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba > , oauth WG , "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 Thomas 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 Thomas > >>>>> > >>>>> To: > >>>>> > >>>>> Phil Hunt > >>>>> > >>>>> Cc: > >>>>> > >>>>> Barry Leiba, oauth WG > >>>>> > >>>>> 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 app
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 Thomas wrote on 03/01/2012 23:52:54: From: Michael Thomas To: Phillip Hunt Cc: Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba , oauth WG, "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 Thomas 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 Thomas To: Phil Hunt Cc: Barry Leiba, oauth WG 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 he
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 1/4/12 12:38 PM, Michael Thomas wrote: > 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 Mike: In my experience, the IETF tradition is not to passively complain, but to actively contribute. Thus if I don't like the fact that there's no specification for some feature or protocol I care about, it's my responsibility to write an Internet-Draft to fill that gap. Similarly, if I have concerns about someone else's Internet-Draft, it's incumbent on me to propose new or alternative text. Sure, I could wait for the authors, editors, working group chairs, or area directors to take action, but you will have much greater success if you actively contribute. Just my gram of silver... Peter -- Peter Saint-Andre http://stpeter.im/ ___ 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 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
Hi Michael I have asked you to clearly describe the threat, not the mitigation. It obviously was either not clear or convincing the first time and I am not going to start digging through emails when you clearly understand it. Regards Mark Michael Thomas wrote on 04/01/2012 20:05:21: > From: > > Michael Thomas > > To: > > Peter Saint-Andre > > Cc: > > Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba > , oauth WG , "oauth- > boun...@ietf.org" > > Date: > > 04/01/2012 20:07 > > Subject: > > 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] 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] 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 backe
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 To: Barry Leiba Cc: oauth WG 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] 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 To: Torsten Lodderstedt Cc: Barry Leiba ; oauth WG 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 &g
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 *To:* Barry Leiba *Cc:* oauth WG *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
> -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. EHL ___ 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 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
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 To: Eran Hammer-Lahav Cc: oauth WG ; Barry Leiba 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
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/04/2012 05:16 PM, William Mills wrote: 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. So what you're saying is that it's even worse than what I wrote, which is pretty confining as to what clients an auth server should have a relationship with. I guess that's progress. A known client whose client keys are compromised is certainly a threat, but it at least requires one more step beyond just freely getting client keys from the auth service. On phone apps with no backend, for example, it's problematic to keep that key secret, but for clients that have backend servers it's not as bad. Part of the vetting process could be "clients MUST NOT store client keys in a program that can be disassembled trivially like a phone app". This may already be in this draft though, so apologies if I didn't see it. I guess I'd rather there not be a blanket MUST NOT -- I hope it doesn't come down to that -- but they way I'm reading you is that it will come down to just that. Mike 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 *To:* Eran Hammer-Lahav *Cc:* oauth WG ; Barry Leiba *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> [mailto: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 targ
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Having read the suggested wording from Eran, William and Michael, I think Eran's description is the most succinct and relevant: "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed" @William: The threat has been described in the context of installing malicious apps so the wording above it more applicable @Michael: It has been repeated many times that we should only address security issues specific to Oauth, and Oauth does not make things worse if a user installs a malicious client. If you want to continue the discussion, please email me directly and we can revert to this forum if you still think your point is relevant Section 4.1.4 of the threat model will be updated as below. Remember the threat model is just offering advice on best practices. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/password). Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. Regards Mark oauth-boun...@ietf.org wrote on 05/01/2012 00:05:04: > From: > > Eran Hammer-Lahav > > To: > > Michael Thomas , Torsten Lodderstedt > > Cc: > > Barry Leiba , oauth WG > > Date: > > 05/01/2012 00:05 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-boun...@ietf.org > > > > > -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. > > EHL > > > > > > ___ > 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] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Why do you think this William? Apple does it? Google android market had to pull 30 apps recently because they contained malware. There are automated tools that will do some sanity checks on apps and it is only advice, i.e. 'could' Mark > William Mills > > " 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 > To: Torsten Lodderstedt > Cc: Barry Leiba ; oauth WG > 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 threatdocument. > > 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
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
The wording you propose is unacceptable. It is a rehash of the same misleading nonsense that is in there now. In particular #1 and #3 that say in effect "bad guys really should be good" are silly and unhelpful. #2 has possibilities, but in its current form gives absolutely no guidance as to what might be done; mine at least explicitly said that the status quo is unacceptable. I also completely object to the notion that the authentication service has no part in protecting itself. It has complete control over who it allows to register as a client, and as written Eran's text contradicts #2's possibility of mitigation -- even if William thinks it's hopeless (as I read him). If William is right the appropriate guidance is that authentication services MUST NOT enroll clients that use untrusted browsers. Putting this on the end users shoulders is useless and should be a reason that the IESG should just reject the protocol. I also object to not *explicitly* pointing out that native apps mean apps from App stores, markets, etc. and the general problem that users cannot know a priori whether an app is malicious or not. I don't see why this is even controversial -- unless your aim is to hide that uncomfortable fact. This is a threat document, not a marketing puff piece. Downplaying threats does nobody any good. Except bad guys. Mike On 01/05/2012 06:01 AM, Mark Mcgloin wrote: Having read the suggested wording from Eran, William and Michael, I think Eran's description is the most succinct and relevant: "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed" @William: The threat has been described in the context of installing malicious apps so the wording above it more applicable @Michael: It has been repeated many times that we should only address security issues specific to Oauth, and Oauth does not make things worse if a user installs a malicious client. If you want to continue the discussion, please email me directly and we can revert to this forum if you still think your point is relevant Section 4.1.4 of the threat model will be updated as below. Remember the threat model is just offering advice on best practices. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/password). Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. Regards Mark oauth-boun...@ietf.org wrote on 05/01/2012 00:05:04: From: Eran Hammer-Lahav To: Michael Thomas, Torsten Lodderstedt Cc: Barry Leiba, oauth WG Date: 05/01/2012 00:05 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Sent by: oauth-boun...@ietf.org -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 sti
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
I'm OK with the threat document including a line this this, or Eran's proposed text, in the introduction to what OAuth can and can't do. It's important to set scope appropriately. (and I am very sorry for that pun) However, the contention about native apps that Mike brings up is misleading for one key reason: if the user's browser is compromised (which is the attack vector in question), then all OAuth-backed webapps will *also* be compromised, since the bad party can just grab the data on its way to the screen. And if the user downloads malware masquerading as a good app (which OAuth *can* protect against by using client secrets in some circumstances and trusted callback urls in others), and they approve the bad app, then they're hosed too. So, no, OAuth won't protect you against malware-infested browsers or against phishing. It significantly reduces but does not eliminate security threats, and (a point that hasn't been brought up) it significantly eases the cleanup burden on users and service providers in the case of a breach. If this really is a confusing point to people, we can say that in the threat document, and Bill's text would do that, without the addendum about native clients. I believe that the native client text that speaks about embedded vs. external browsers is already clear on this matter -- but if someone has better text (as in, "paragraph X should say the following exact words", not "it needs to be better"), then we can incorporate it. Even so, I do think it's clear from what text we already have. It would be superfluous but not burdensome to add extra text into the threat model document (not core) as has been proposed here by Bill and previously be Eran. -- Justin On 01/04/2012 06:58 PM, Michael Thomas wrote: 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 *To:* Barry Leiba *Cc:* oauth WG *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
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/05/2012 07:54 AM, Justin Richer wrote: However, the contention about native apps that Mike brings up is misleading for one key reason: if the user's browser is compromised (which is the attack vector in question), then all OAuth-backed webapps will *also* be compromised, since the bad party can just grab the data on its way to the screen. And if the user downloads malware masquerading as a good app (which OAuth *can* protect against by using client secrets in some circumstances and trusted callback urls in others), and they approve the bad app, then they're hosed too. There's a big difference between a compromised browser and a native app with an embedded browser. The first is considered harmful and browsers already take steps to insure they do not remain infected through updates, etc. The second is working as intended. | Even so, I do think it's clear from what text we already have. Remember: the reason that I am here at all is precisely because it was *not* clear. It's why I find the belligerence I've been afforded from the beginning so mystifying. Mike ___ 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
There's going to be a whole class of apps tat will be in violation of "Client applications SHOULD avoid directly asking users for the their credentials.". We know that already, because the password grant exists and we have real use cases for it. I think we should strikes that sentence and move that idea to #3 (soon to be #2) I think point 2 should be struck, it's pointless. What would matter here is whether the user can check that the app has been validated, and we're not defining that. I would change #3 (now #2?) to: 3. It is RECOMMENDED that client applications use the web based authentication flow, this takes advantage of a more trusted system component, e.g. the system browser, and provides a consistent authentication experience for the user across applications. The user is then always presenting their credential to a known and trusted web page. Collection and use of primary authentication from the user by client applications is NOT RECOMMENDED. Regards, -bill P.S. hit the wrong key earlier and replied only to Mark with this. Should have hit the list. Sorry Mark. From: Mark Mcgloin To: OAuth WG Sent: Thursday, January 5, 2012 6:01 AM Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Having read the suggested wording from Eran, William and Michael, I think Eran's description is the most succinct and relevant: "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed" @William: The threat has been described in the context of installing malicious apps so the wording above it more applicable @Michael: It has been repeated many times that we should only address security issues specific to Oauth, and Oauth does not make things worse if a user installs a malicious client. If you want to continue the discussion, please email me directly and we can revert to this forum if you still think your point is relevant Section 4.1.4 of the threat model will be updated as below. Remember the threat model is just offering advice on best practices. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/password). Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. Regards Mark oauth-boun...@ietf.org wrote on 05/01/2012 00:05:04: > From: > > Eran Hammer-Lahav > > To: > > Michael Thomas , Torsten Lodderstedt > > Cc: > > Barry Leiba , oauth WG > > Date: > > 05/01/2012 00:05 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-boun...@ietf.org > > > > > -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
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
It relies on the marketplace to do this. The current model is that apps are not validated first, they are pulled if found to be hostile. You're making a recommendation here about how an app marketplace should behave to be trustworthy, and I think that's beyond the scope of users and client developers here. We're already saying users should only install trustworthy applications. From: Mark Mcgloin To: William Mills Cc: Barry Leiba ; Michael Thomas ; oauth WG ; oauth-boun...@ietf.org; Torsten Lodderstedt Sent: Thursday, January 5, 2012 6:03 AM Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Why do you think this William? Apple does it? Google android market had to pull 30 apps recently because they contained malware. There are automated tools that will do some sanity checks on apps and it is only advice, i.e. 'could' Mark > William Mills > > " 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 > To: Torsten Lodderstedt > Cc: Barry Leiba ; oauth WG > 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 threatdocument. > > 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
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
On 01/05/2012 08:37 AM, William Mills wrote: It relies on the marketplace to do this. The current model is that apps are not validated first, they are pulled if found to be hostile. You're making a recommendation here about how an app marketplace should behave to be trustworthy, and I think that's beyond the scope of users and client developers here. We're already saying users should only install trustworthy applications. First, asking users to only install "trustworthy" application is a completely useless recommendation: how do they know? How does anybody on this list know, in fact? Second: I don't think that the suggestion should be that the markets do this vetting -- they won't because they aren't fate shared. The auth server, on the other hand, has the ability to not enroll clients. That at least is plausible rather than the completely implausible suggestion that billions of users educate themselves on millions of apps. Mike -- *From:* Mark Mcgloin *To:* William Mills *Cc:* Barry Leiba ; Michael Thomas ; oauth WG ; oauth-boun...@ietf.org; Torsten Lodderstedt *Sent:* Thursday, January 5, 2012 6:03 AM *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Why do you think this William? Apple does it? Google android market had to pull 30 apps recently because they contained malware. There are automated tools that will do some sanity checks on apps and it is only advice, i.e. 'could' Mark > William Mills mailto:wmi...@yahoo-inc.com>> > > " 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 mailto:m...@mtcc.com>> > To: Torsten Lodderstedt mailto:tors...@lodderstedt.net>> > Cc: Barry Leiba mailto:barryle...@computer.org>>; oauth WG mailto: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 > t
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
The problem is that even if the Authorization Server only gives out credentials to "trusted clients", those clients can be "hacked" and the credentials compromised allowing for impersonation of the "trusted client". Obviously, protecting the credentials is easier if the client is a web server with the appropriate security measures in place. However, that isn't the only use case that needs to be solved. Rich desktop applications and mobile applications also need access to the user's protected resources. The issue here is that clients (in the vast majority of cases) can't be trusted. This means that all rich desktop/mobile app models currently in the field are flawed (if we are trying to protect the user from a malicious client). OAuth is specifically NOT trying to solve the "client trustworthiness" problem. Personally, I don't see how to solve this problem without "trusted hardware" in the client and that isn't yet widely deployed. However, as others have pointed out, OAuth doesn't make the existing situation worse (i.e. users are just as likely without OAuth to download malicious code to their computers/devices and be phished). However, with more "good" applications moving to OAuth, the situation generally improves for the user, because their credentials are stored in fewer places. It might even push the "bad guys" to having to implement malicious apps as other methods of getting the user's credentials are significantly reduced. From a threat model perspective, while OAuth doesn't solve this specific threat, the use of OAuth overall improves the security of the user. My 2 cents:) On 1/5/12 11:48 AM, Michael Thomas wrote: Second: I don't think that the suggestion should be that the markets do this vetting -- they won't because they aren't fate shared. The auth server, on the other hand, has the ability to not enroll clients. That at least is plausible rather than the completely implausible suggestion that billions of users educate themselves on millions of apps. Mike --- - -- *From:* Mark Mcgloin *To:* William Mills *Cc:* Barry Leiba ; Michael Thomas ; oauth WG ; oauth-boun...@ietf.org; Torsten Lodderstedt *Sent:* Thursday, January 5, 2012 6:03 AM *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Why do you think this William? Apple does it? Google android market had to pull 30 apps recently because they contained malware. There are automated tools that will do some sanity checks on apps and it is only advice, i.e. 'could' Mark > William Mills mailto:wmi...@yahoo-inc.com>> > > " 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 mailto:m...@mtcc.com>> > To: Torsten Lodderstedt <mailto:tors...@lodderstedt.net>> > Cc: Barry Leiba <mailto:barryle...@computer.org>>; oauth WG <mailto: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 incl
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Hi William Sorry for slow response - comments inline below. I really would like to close out on this set of countermeasures. I think the differing opinions are subjective as this point and we all need to bear in mind that the threat model is intended to advise on best practices and not all of those will be applicable to all developers Regards Mark William Mills wrote on 05/01/2012 16:29:02: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > There's going to be a whole class of apps tat will be in violation > of "Client applications SHOULD avoid directly asking users for the > their credentials.". We know that already, because the password > grant exists and we have real use cases for it. I think we should > strikes that sentence and move that idea to #3 (soon to be #2) > The resource owner password credentials is intended for clients with trust relationships with the resource server, mainly intranet apps. For all other cases, client apps should use Oauth as it was intended, i.e. to avoid the anti-pattern of asking users for credentials. > I think point 2 should be struck, it's pointless. What would matter > here is whether the user can check that the app has been validated, > and we're not defining that. Agree that this countermeasure applies whether the app uses oauth or not and because this threat is getting side tracked into advising on non-oauth specific threats/countermeasures (i.e. user downloads malicious client) It is just a suggestion, i.e. 'could', and may not apply to all marketplaces. If the market place, such as apple, says the app has been validated, then the user knows. You state elsewhere: > "The current model is that apps are not validated first, they are pulled if found to be hostile. You're making a > recommendation here about how an app marketplace should behave to be trustworthy, and I think that's beyond the > scope of users and client developers here. We're already saying users should only install trustworthy applications." Again, it is just a suggestion. It may apply to some marketplaces more than others, e.g. where the clients are accessing resources also under control of the marketplace. Recommendations are aimed at resource server and authorization server developers too. > > I would change #3 (now #2?) to: > >3. It is RECOMMENDED that client applications use the web based > authentication >flow, this takes advantage of a more trusted system component, > e.g. the system >browser, and provides a consistent authentication experience for the user >across applications. The user is then always presenting their > credential to a >known and trusted web page. Collection and use of primary > authentication from >the user by client applications is NOT RECOMMENDED. > I don't agree that your wording clarifies anything > *From:* Mark Mcgloin Countermeasures: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. ___ 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/16/2012 05:52 AM, Mark Mcgloin wrote: Countermeasures: First off the title: it says Countermeasures. Therefore, anything here must be a real and meaningful "countermeasure". 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. This is not a countermeasure. It is a request that bad guys be good. Strike it entirely. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed This is not a credible countermeasure. End users know nothing about this, and I'd venture to say that includes you and me too. Strike it entirely. 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way This may be a valid countermeasure, but there needs to be some reason to believe that it is not just a hope and a prayer put here just to feel good. If it cannot be substantiated, strike it entirely. 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. This is not a valid countermeasure. It expects bad guys to be good. Strike it entirely. Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
