Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?
At 18:13 14-12-2011, Mike Jones wrote: Any objections to posting the updated Bearer draft incorporating the results of the APPS Area review and the TLS requirements? Mark Nottingham followed up on his review [1]. If this working group considers that the concerns raised have been addressed, I gather that it ok for me to raise them as issues during the Last Call for draft-ietf-oauth-v2-bearer. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/oauth/current/msg08052.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SAML Bearer Spec 09 - Refresh Clarification
Hey Phil, Your understanding is pretty much inline with how I understand it. That text actually originates from earlier versions of the core spec (I think -09 [1] was the last sighting). And I carried it over when the grant_type got generalized and the assertion pieces moved into the SAML/OAuth draft. The main idea was that the extension grants (or at least assertions) relied on some existing trust framework and that issuing a refresh token would effectually undermine that by giving the client a new way of getting access outside the established framework of trust. So, for example, with an RT a fired employee might still be able to access resources at a SaaS provider. That was the thinking anyway but I don't disagree that the wording in the draft could make that more clear and/or be a less restrictive. Regarding the text you've proposed, I'm not sure I know exactly what "lifetime of the authorization grant" means or how the AS would know. And I think it might be too ambiguous to have as normative language. Can you give a workable definition? Or was it intentionally left kind of vague? I'll should also note that that exact same text is in section 3.1 of the "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0" [2] draft. Whatever we decide, I can't think of any reason it would't apply to both drafts. And that suggests that it should be moved up into the "OAuth 2.0 Assertion Profile" - perhaps into section 4.1.3 [3]? Thanks, Brian P.S. My apologies for the extremely slow response - this one just slipped though the cracks for a while - I have no other excuse. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 [2] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03#section-3.1 [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.3 On Fri, Nov 4, 2011 at 2:40 PM, Phil Hunt wrote: > Section 4.5 of the OAuth Core spec provides that extension spec MAY issue > refresh tokens. Yet, section 3.1 of the OAuth2 SAML Bearer specification > currently says SHOULD NOT (from draft 09): > > Authorization servers SHOULD issue access tokens with a limited lifetime and > require clients to refresh them by requesting a new access token using the > same assertion, if it is still valid, or with a new assertion. The > authorization server SHOULD NOT issue a refresh token. > > > There has been some confusion as to why authorization servers SHOULD NOT > issue refresh tokens. Apparently this wording was put in place because a > SAML Bearer authorization might have a shorter life than typical refresh > token lifetime. Hence there was a concern that an authorization server would > inadvertently issue a long-lasting refresh token that outlives the original > SAML Bearer authorization. In order to make this concern clear I propose > the following text that makes clear the concern and makes refresh tokens > more permissive: > > Authorization servers SHOULD issue access tokens with a limited lifetime and > require clients to refresh them by requesting a new access token using the > same assertion, if it is still valid, or with a new assertion. The > authorization server SHOULD NOT issue a refresh token that has an expiry > longer than the lifetime of the authorization grant. > > I'm not aware of any other concerns regarding refresh tokens being issued in > conjunction with SAML Bearer assertions? Are there any concerns that > suggest we should keep the wording as generally SHOULD NOT? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > > ___ > 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/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 applications could be validated prior publication in a application market. [mat] How would this be done in practice? [
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
Andre You are right that the threat model does not cover this kind of issue related to client registration. Client registration is considered to be out of scope in the oauth spec but it is worth drawing developers attention to this. I can add a threat entitled something like "Client Registration of phishing clients". It kind of reminds me of the issues android market place has seen recently with malware apps due to no vetting of those apps. It is touched upon in the oauth 2 rfc: http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2 Regards Mark On 3 Nov 2011 17:09:39, "Andre DeMarre" wrote: You are right that they are similar, but there is a difference, and only one of the six countermeasures is relevant to the threat I described. http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4 seems to be about an attack where the malicious client impersonates a different (valid) client that is registered with the authorization server. In other words, the valid client is registered as client_id 123, and the malicious client does not have its own client_id but tries to pose as client 123. This corresponds to http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-10.2. In the threat I described, there is no valid client. The malicious client is properly registered with the authorization server and has its own client_id and client credentials. It can authenticate with the authorization server without trying to pose as a different client. As an attacker you might reason, "Why would I try to impersonate a valid client for which I don't know the client credentials and can't pass the redirect URI test, when I can just register my own client with my own redirect URI and be given my own credentials?" Imagine the attacker wants to impersonate Google with a popular web service called Foobar. The attacker registers his application with Foobar's auth server. It does not matter if the real Google has registered an authentic app with Foobar. The attacker has no reason to be interested in stealing or guessing client credentials when he can simply register his own app and call it "Google". The information the auth server shows to end users when asking them to grant authorization becomes very important. Regards,Andre DeMarre On Wed, Nov 2, 2011 at 2:27 PM, Torsten Lodderstedt wrote: > Hi Andre, > > how do you think differs the threat you descibed from > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4 ? > > regards, > Torsten. ___ 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. > > > > 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 resour
