Re: [OAUTH-WG] Auth Code Swap Attack
I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. value SHOULD enable) accomplishes nothing. Also, what does MUST be kept confidential mean? Confidential from what? Why specify an encoded value? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
I felt the argument provided was persuasive and that the current spec leaves implementers open to attack. I get concerned when the core spec says OPTIONAL for state and then Security Considerations says REQUIRED. The inconsistency seemed to be a flaw in draft 20. As to your comment about a tie vote, all that shows is a lack of consensus. Clearly we need to keep working on some more proposals. I think it is reasonable to determine whether MUST is appropriate in all cases. I agree with what you said earlier, we should have more specific language other then of sufficient complexity to describe the value of the state parameter. I saw a proposal by William Mills that I would like to see more discussion on. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way. To clarify – I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t sufficient. We use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what “state” was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
There was no argument made. You described a CSRF attack scenario which carries the exact same risk and uses the exact same solution as the CSRF attack already present in the specification. Then jumped from there to a new normative requirement. I have not seen any argument to justify the new MUST requirement - if I have missed it, please point me in the right direction. Also, -20 has no such inconsistencies. It is OPTIONAL in one place and RECOMMENDED in the other. However, -20 does not *require* CSRF protection which put it at odds with how we address every other attack vector, so we are in full agreement that CSRF prevention is a MUST. My text fixes that in a manner consistent with how you and the other security consideration section drafters approached many of the other sections (by requiring a solution but not limiting developers to a particular one). There are two open issues: - the quality of the prose (I agree that Bill's text is a good new starting point), and - whether we should dictate to developers the parameter name (and location) of the CSRF artifact. If we decide that we should mandate such a parameter, we then need to decide if 'state' is the right place and if it is, find a new way to describe it because using it for CSRF is a relative new use case for the parameter (which still have all the previous use cases). EHL From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Wednesday, August 17, 2011 11:41 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I felt the argument provided was persuasive and that the current spec leaves implementers open to attack. I get concerned when the core spec says OPTIONAL for state and then Security Considerations says REQUIRED. The inconsistency seemed to be a flaw in draft 20. As to your comment about a tie vote, all that shows is a lack of consensus. Clearly we need to keep working on some more proposals. I think it is reasonable to determine whether MUST is appropriate in all cases. I agree with what you said earlier, we should have more specific language other then of sufficient complexity to describe the value of the state parameter. I saw a proposal by William Mills that I would like to see more discussion on. Phil @independentid www.independentid.comhttp://www.independentid.com phil.h...@oracle.commailto:phil.h...@oracle.com On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.orgmailto:oauth@ietf.org)
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
But it's not really a counterfeit client but a real client with modified redirection uri. It is a counterfeit redirection endpoint. *I* understand exactly what you mean, but I fear new readers will get completely confused by the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]mailto:[mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
In my opinion, the counterfeit redirection endpoint is another client - the counterfeit client. The attacker must trick the victim into accessing this client and approving the authorization request. So I would assume the attacker would try to let his endpoint look like the real client. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 09:17 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) But it's not really a counterfeit client but a real client with modified redirection uri. It is a counterfeit redirection endpoint. *I* understand exactly what you mean, but I fear new readers will get completely confused by the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]mailto:[mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comments
1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, Refresh Token Not sure. What do others think? I put access token first because it is a more important term to get out of the way. I would rather consider to change order to Access Token, Refresh Token, Authorization Grant since the first two are the core OAuth concepts developers must become familiar with. Authorization grants are just an mean to an end to get the token for certain client types. Moreover, I expect the number of authorization grants to increase over time. 2.3: Should ... cannot be used alone be made into a normative, as ... MUST NOT be used alone? I'm ok with that. Anyone else? +1 regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived!
+1 -Ursprüngliche Nachricht- Von: Barry Leiba [mailto:barryle...@computer.org] Gesendet: Mittwoch, 17. August 2011 22:35 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived! I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled OAuth discovery and specification availability, dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: . Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. . Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. . IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. . Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. . For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header Field), the scope-v element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that access tokens are always short-lived or that refresh tokens will always be issued to native applications using this grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=codeclient_id=1234; redirect_uri=SOMEURIscope=SOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]allow=1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav e...@hueniverse.com wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comments
1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, Refresh Token Not sure. What do others think? I put access token first because it is a more important term to get out of the way. I would rather consider to change order to Access Token, Refresh Token, Authorization Grant since the first two are the core OAuth concepts developers must become familiar with. Authorization grants are just an mean to an end to get the token for certain client types. Moreover, I expect the number of authorization grants to increase over time. You have to use *some* kind of authorization grant to get any kind of token, and this part of the OAuth spec is all about how to get a token in a programmatic way. I agree that there will be many more types of auth grants in the future, and that's why I think it should be the first concept in the list. I can see the logic of putting both token types first (though I still prefer the auth grant first), but having the auth grant in between the two token types is definitely a bad idea. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comments
I can see the logic of putting both token types first (though I still prefer the auth grant first), but having the auth grant in between the two token types is definitely a bad idea. +1 -- Justin ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony,Barry) and all agree with it. Maybe my e-mail was lost, but I was and still am among those who have agreed with the text, as I am sure many others have What is also important is that no one has objected. I see neither the reason nor the right of an editor to remove the text. Igor On 8/18/2011 3:51 AM, Lodderstedt, Torsten wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can youprovide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow.This is especially true in the case of using OAuth for login which has to be practically transparent (oneclick). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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 ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
Thanks. You have a typo in #1 (the authorization endpoint belongs to the authorization server, not client). This is a textbook CSRF attack on the authorization endpoint. The right solution is for the authorization server to set or maintain a session cookie (or other same-origin-protected state in the browser) in #1 as well as some hidden CSRF token in the Accept form and not allow CORS calls to that endpoint. I don't see how the measures proposed in the new section are relevant here. EHL -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 5:49 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=codeclient_id=1234; redirect_uri=SOMEURIscope=SOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]allow=1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav e...@hueniverse.com wrote: I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hey Torsten, -Original Message- From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:52 AM To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. That's not an attack but a description of capabilities. The attack example provided by Niv is a *classic* CSRF attack on the authorization endpoint. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? I don't understand the attack and how the proposed solution address it. I'm really happy for everyone else who got it, but I need more information to process it. The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. True. But it was central in the list discussion and was promoted as strong defense to whatever this attack is. I think that CAPCHA is an impractical recommendation in general for the authorization endpoint. Can you point to any real world example of a large provider forcing CAPCHA on every login? That's what this amounts to. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. The text hints at a very dangerous attack vector of scripts doing 'really bad things'. But it doesn't show why this attack requires any kind of automation at all. If I am targeting just a small number of people, I can automate this by sending a message to a human who will break the CAPCHA and quickly return the link to approve access. The other measures either have the same properties, are just there to annoy the attacker, or provide some kind of after the fact notice (when it is clearly too late to prevent damage). I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? no one (except you) is an interesting statement... :-) This is not a process issue. New text has been proposed with the support of a few working group members. The working group has been largely silent about it (and the review you referenced above was done off list). I have read the new text and did not understand it, therefore, could not edit the text as I have done with every other proposed language. No new draft will be published until we resolve all open issues, which is exactly what I have stated above. To make it clearer: I am keeping this proposed text out of *my* working draft for -21 until the working group discusses the text further and addresses the issues I have raised about the text as a working group member (technical issues) and as an editor (clarity issues). As for IETF process, all it takes is one objection to block text from being *automatically* added to the specification. I have not implied anywhere that I have made any decision (or have the authority to) with regard to this text, only that I'm holding it back until the issues are resolved. And IETF process does not require full agreement to solve issues which is the role of the chairs to resolve. In this case, we're nowhere near needing help from the chairs - just the assistance of the text authors to do their job and explain it. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
Agree, against the removal of text -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland 1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that access tokens are always short-lived or that refresh tokens will always be issued to native applications using this grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. regards, Torsten. ___ 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] Partial set of last call comments on OAuth draft 20 from Yaron Goland
+1 (against the removal) On 8/18/2011 12:58 PM, Anthony Nadalin wrote: Agree, against the removal of text -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland 1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption thataccess tokens are always short-lived or that refresh tokens will always be issued to native applications usingthis grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. regards, Torsten. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland
Chairs - please open an issue for this: Clarifying reference to refresh tokens in section 1.4.3 of -20. -Original Message- From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland 1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that access tokens are always short-lived or that refresh tokens will always be issued to native applications using this grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. Since you felt it necessary to make this a process issue, I've asked the chairs to open a ticket. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. How about: This grant type can eliminates the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token. As for Yaron's original comment, I think this text is sufficient and no forward reference is needed to 1.5 (which is a few lines lower in the same page). Also, with the new organization proposed by Justin, the access token term isn't full defined yet either and it reads just fine. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) (thanks for the typo correction) Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint. If the client is not user-agent based, a full-fledged forgery of the whole process is possible, one in which CORS and sandboxes have no meaning. In a native client, unless some kind of human test is performed, the whole flow could be spoofed. Can you provide another example with the same level of detail as you provided below? A CAPTCHA and/or password entry are not bullet-proof, but they provide a steep obstacle for the attacker. CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*. Another option would be, for example, to email the resource owner an OTP, with the following message The application [...] requests access to [...]. Please use the number to allow it access etc... (similar to Google's and Facebook's two-step sign-in). Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized. The first attack described in my previous message takes the form of CSRF, while the above one may be bypassed by an attacker with the help of some sort of clickjacking or similar. Eventually this threat description is for a family of attacks which mimic the behavior of the resource owner in order to gain access to protected resources, and some possible countermeasures. I don't understand this family of attacks. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I'd like to ask the chairs to open an issue for this. http://trac.tools.ietf.org/wg/oauth/trac/ticket/24 I didn't realize how hyper sensitive this working group has become that every proposal being questioned needs a ticket to prove to people that they are not being dismissed. It's OK: tickets are cheap, and I don't mind... and if it helps people to know that discussions that aren't quickly resolved are being tracked, then that's what the issue tracker is there for. It makes sure things don't get forgotten, and reminds people what to look more closely at in the next doc rev. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint. General comment, not for this issue alone (and not specifically to the folks conversing here): There are a great many things we can say about threats and attacks, which is why we have the threats document by Torsten, et al. I'm generally in favour of putting more security considerations into the base document to describe threats that implementors need to be concerned about, and well-crafted text that the editors can drop in is a good thing. That said, the reason we decided to put highlights into the base doc's Security Considerations section, and then refer to the larger document for more details and a more complete threat analysis is that we wanted to strike a balance, keep the base doc for protocol details, and leave the threat descriptions in the base doc as general threat *classes*. As we debate the various attack descriptions and mitigations that we might like to add, please keep that balance in mind, and think carefully about whether the details of *this specific* attack should go into this document, or whether we just need to cover the general class of threats here and put the details of this attack into draft-ietf-oauth-v2-threatmodel. Otherwise, we might eventually merge the entire threat analysis document into the base, one paragraph at a time. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
The text for the answer below came from Mike, as the chairs asked for at the IETF 81 meeting. Mike, do you have a response to James's issue? Can we give a better response here? Should the bearer doc specify %-encoding explicitly? Barry On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H james.h.man...@team.telstra.com wrote: * For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header Field), the scope-v element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. This is a poor answer. A client app receiving a scope value in an WWW-Authenticate: Bearer scope=... response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect. OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter). Bearer restricts scopes to 93 ASCII chars. OMA are asking if this is intentional. If we really want to restrict scope values it would be better done in OAuth2 core. If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter). -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, to finally receive an access token/authorization code in the redirection. CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*. CAPTCHAs are used for human testing and passwords for identity testing, but in this case they both serve the same purpose of decreasing the likelihood that the flow is automated. Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized. You're right, sometimes there's a trade-off between better security and user experience. I think it should eventually be up to the implementer to choose what is right for their applications' security requirements. I think it is in the scope of the specification to bring this issue up for developers to consider. I don't understand this family of attacks. I don't know how to put it any differently than I already have; simply a class of attacks (the three scenarios described in this thread are examples thereof) in which a malicious client takes the role of both the client and the resource owner. -- Niv ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
+1 for Jame's feedback here. We need to solve this. From: Manger, James H james.h.man...@team.telstra.com To: Barry Leiba barryle...@computer.org; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:15 AM Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v * For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header Field), the scope-v element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. This is a poor answer. A client app receiving a scope value in an WWW-Authenticate: Bearer scope=... response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect. OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter). Bearer restricts scopes to 93 ASCII chars. OMA are asking if this is intentional. If we really want to restrict scope values it would be better done in OAuth2 core. If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter). -- James Manger ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. EHL [1] http://www.ibras.dk/montypython/episode34.htm ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. In order to automate the approval action, they attacker has to get the user-agent (embedded or not) to make a cross site request which will include some session state (cookies or otherwise). If the authorization page is CSRF protected, they attacker will not be able to construct such a link. The nature of the client does not matter. In either case, the client has to gain access somehow to the authorization server state stored in the browser. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
This is, in my opinion, another style of CSRF. I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me? That's a classic CSRF, how to fix it is interesting. I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential. Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary and somehow informing the user what they are doign is a bad thing). -bill From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the Allow button. [1] http://www.ibras.dk/montypython/episode34.htm +1 for more Monty Python references. -- Niv ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
We know how to fix CSRF attacks on form submission which this is. The UI questions about more about legitimate client interaction and how informed a user should be. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 12:27 PM To: Niv Steingarten; Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) This is, in my opinion, another style of CSRF. I the attacker present your browser (user agent) with a link, and your browser presents a credential automatically to the token endpoint, which automatically issues a token to be given back to me? That's a classic CSRF, how to fix it is interesting. I'm of the opinion that the user *should* be pesented with some UI at that point so they can make an informed choice about issuing a credential. Not everyone agrees with me though (mostly business folks that want to avoid user interaction because it's too scary and somehow informing the user what they are doign is a bad thing). -bill From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the Allow button. [1] http://www.ibras.dk/montypython/episode34.htm +1 for more Monty Python references. -- Niv ___ OAuth mailing list OAuth@ietf.orgmailto: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] TLS 1.2
On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote: -Original Message- From: Rob Richards [mailto:rricha...@cdatazone.org] Sent: Tuesday, August 16, 2011 1:34 PM The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY support additional transport-layer mechanisms meeting its security requirements. How about: The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future replacements, and MAY support additional transport-layer mechanisms meeting its security requirements. EHL That works Rob ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). -- Niv ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Huilan ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] TLS 1.2
+1 Huilan -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Rob Richards Sent: Thursday, August 18, 2011 3:46 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] TLS 1.2 On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote: -Original Message- From: Rob Richards [mailto:rricha...@cdatazone.org] Sent: Tuesday, August 16, 2011 1:34 PM The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY support additional transport-layer mechanisms meeting its security requirements. How about: The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future replacements, and MAY support additional transport- layer mechanisms meeting its security requirements. EHL That works Rob ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
-Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active authentication, and 2. The ability of the malicious client to make CSS calls using #1. Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue. This is why the client type does not matter when it comes to not using CORS. The authorization server MUST NOT allow CSS calls on the authorization endpoint because that's the actual attack you described - using local state (session cookie) to make a CSS call. If the client makes direct calls to the authorization endpoint, it cannot impersonate the resource owner. and launch it using the same HTTP framework/WebKit, simulating the Allow button. This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean
Re: [OAUTH-WG] treatment of client_id for authentication and identification
-Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] [oauth] #24: Resource Owner Impersonation
#24: Resource Owner Impersonation See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07225.html Torsten proposes text that describes the attack and suggests defenses. -- -+-- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major| Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document |Keywords: -+-- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/24 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [oauth] #22: WG last call complete; waiting for new revision (was: In final review before WG last call)
#22: WG last call complete; waiting for new revision Changes (by barryleiba@…): * severity: Active WG Document = In WG Last Call -- -+-- Reporter: barryleiba@… | Owner: barryleiba@… Type: state| Status: assigned Priority: information | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: In WG Last Call |Keywords: -+-- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/22#comment:3 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] [oauth] #25: Clarifying reference to refresh tokens in section 1.4.3 of -20
#25: Clarifying reference to refresh tokens in section 1.4.3 of -20 See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07309.html Yaron brings up a point in his review, to which Eran responds with a suggestion of removing (when combined with a refresh token). Several objections are raised to the removal. Eran proposes an alternative here: http://www.ietf.org/mail-archive/web/oauth/current/msg07322.html -- -+-- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major| Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document |Keywords: -+-- Ticket URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/25 oauth http://tools.ietf.org/oauth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
FWIW, I was okay with the text EHL had originally proposed for 21. client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL Here is my stab: Allowing unauthenticated access by public clients has security ramifications. So does the issuance of refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I just noticed that some words were missing in my previous post. Here is the full text that Eran requested: Allowing unauthenticated access to the token endpoint by public clients has security ramifications. So does issuing refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lu, Hui-Lan (Huilan) Sent: Thursday, August 18, 2011 5:47 PM To: 'Eran Hammer-Lahav'; Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL Here is my stab: Allowing unauthenticated access by public clients has security ramifications. So does the issuance of refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active authentication, and 2. The ability of the malicious client to make CSS calls using #1. Everything else is a red herring because the ability to automate this attack and make it more powerful is completely beside the point. If you deploy an effective CSRF protection, everything else is a non-issue. This is why the client type does not matter when
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said that about the first request. But since both requests (the one requesting the auth endpoint and the one simulating the allow) are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. That's not exactly right. This entire attack is based on: 1. The presence of some session cookie or other user-agent state to bypass active
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind of attack is happening in the second half. I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. That's what I said -- no access to cookies. You only said
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. From: Niv Steingarten nivst...@gmail.com To: William J. Mills wmi...@yahoo-inc.com Cc: Eran Hammer-Lahav e...@hueniverse.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Can you provide another example with the same level of detail as you provided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, SCENE MISSING [1] to finally receive an access token/authorization code in the redirection. You skipped the best part! What do you mean by dispatches it? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal fixes the first half, but not what kind
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
To reiterate Berry's earlier point, we are not going to cover everything in the v2 spec. We need to agree on new language for the CSRF section, and add the potential attacks on both endpoints. But beyond that, it will probably be best to add it to the threat model document - but I will leave that up to the editors of that document. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 9:21 PM To: Niv Steingarten Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com Cc: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com; oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com wrote: I proposed text that I think is more complete in a previous message... From: Niv Steingarten nivst...@gmail.commailto:nivst...@gmail.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Thursday, August 18, 2011 4:33 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The state request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The state request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 1:04 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 12:12 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 11:08 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: -Original Message- From: Niv Steingarten [mailto:nivst...@gmail.commailto:nivst...@gmail.com] Sent: Thursday, August 18, 2011 10:16 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource
