Re: [OAUTH-WG] Auth Code Swap Attack
Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 mailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.org mailto:oauth@ietf.org) oauth@ietf.org mailto: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 inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the state parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the state parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of state corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term is defined. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
+1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 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 inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the state parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the state parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of state corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term is defined. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth
Re: [OAUTH-WG] Auth Code Swap Attack
Again, the idea that you can produce a comprehensive description of security threat is impractical if you are going to include every browser-based attack and its remedies. OAuth use of browser redirection imports almost every possible attack vector on the web. That's my point. People constantly bring up these attack vectors, and in multiple flavors and variations, as if *anyone* can produce a complete list of these issues. Now, this doesn't mean we should not try to be comprehensive but this can go on forever. The changes to 10.12 seem reasonable with the exception of the new MUSTs. I disagree that we should mandate clients to use the state parameter as the only CSRF protection vector, especially in an evolving web environment. We can still include a MUST for verifying that the user redirected to the authorization server is the same user coming back, and highlight the state parameter as one way to accomplish that. How about: state: OPTIONAL. An opaque value used by the client to maintain state between the request and redirection. The authorization server includes this value when redirecting the user-agent back to the client. Use of the state parameter is RECOMMENDED for preventing cross-site request forgery as described in Section 10.12. Section 10.12 Cross-Site Request Forgery 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 inject their own authorization code or access token into the client, which can result in the client associating the attacker's protected resources to the victim's account on the client. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client MUST employ CSRF protection. It is strongly RECOMMENDED for the client to utilize the state request parameter with authorization requests to the authorization server. When used for CSRF prevention, the state request parameter MUST contain a non-guessable value, which the client MUST also store with the resource owner's user-agent in a location accessible only to the client or the resource owner's user-agent (i.e., protected by same-origin policy). For example, the client can using a DOM variable, HTTP cookie, or HTML5 client-side storage. When redirecting the resource owner's user-agent back to the client, the authorization server includes the value of the state parameter. Upon receiving the redirection request, the client MUST confirm that returned value of the state parameter matches the value stored with the resource owner's user-agent. EHL From: Torsten Lodderstedt tors...@lodderstedt.net Date: Fri, 12 Aug 2011 23:58:02 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: Anthony Nadalin tony...@microsoft.com, OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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
Re: [OAUTH-WG] Auth Code Swap Attack
All CSRF attacks are a against the client (confused deputy) yes. The defense is always in the server side. I agree that it's really worth covering. There are already good discussions of CSRF out there which I think we shoudl lean on rather than re-writing our own, i.e. http://www.rfc-editor.org/rfc/rfc6265.txt -bill From: Eran Hammer-Lahav e...@hueniverse.com To: Phil Hunt phil.h...@oracle.com; Torsten Lodderstedt tors...@lodderstedt.net Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org Sent: Saturday, August 13, 2011 7:30 AM Subject: Re: [OAUTH-WG] Auth Code Swap Attack All OAuth CSRF attacks are on the client. EHL From: Phil Hunt phil.h...@oracle.com Date: Sat, 13 Aug 2011 00:21:50 -0700 To: Torsten Lodderstedt tors...@lodderstedt.net Cc: Eran Hammer-lahav e...@hueniverse.com, OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.comphil.h...@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 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 inject their ownauthorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the state parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible
Re: [OAUTH-WG] Auth Code Swap Attack
There are two CSRF variations scenarios that I see. I can attack you and give my client access to your resources (original attack on the resource). I can attack you and give your client access to my resource (new attack on the client). Attack on the client vs. attack on the resource may be misleading here. Draft 20 only referred to attacks on the resource in its original CSRF description. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: All OAuth CSRF attacks are on the client. EHL From: Phil Hunt phil.h...@oracle.com Date: Sat, 13 Aug 2011 00:21:50 -0700 To: Torsten Lodderstedt tors...@lodderstedt.net Cc: Eran Hammer-lahav e...@hueniverse.com, OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 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 inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the state parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable,
Re: [OAUTH-WG] Auth Code Swap Attack
The defense is the same though, correct? From: Phil Hunt phil.h...@oracle.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org Sent: Saturday, August 13, 2011 4:41 PM Subject: Re: [OAUTH-WG] Auth Code Swap Attack There are two CSRF variations scenarios that I see. I can attack you and give my client access to your resources (original attack on the resource). I can attack you and give your client access to my resource (new attack on the client). Attack on the client vs. attack on the resource may be misleading here. Draft 20 only referred to attacks on the resource in its original CSRF description. Phil @independentid www.independentid.comphil.h...@oracle.com On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: All OAuth CSRF attacks are on the client. EHL From: Phil Hunt phil.h...@oracle.com Date: Sat, 13 Aug 2011 00:21:50 -0700 To: Torsten Lodderstedt tors...@lodderstedt.net Cc: Eran Hammer-lahav e...@hueniverse.com, OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.comphil.h...@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 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 inject their ownauthorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the
Re: [OAUTH-WG] Auth Code Swap Attack
No. I don't think so. In the new variant the client has to check the returned state to confirm it has not changed or associated with a different user. Previously the authz server had to do the checks. Phil On 2011-08-13, at 21:16, William J. Mills wmi...@yahoo-inc.com wrote: The defense is the same though, correct? From: Phil Hunt phil.h...@oracle.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: OAuth WG (oauth@ietf.org) oauth@ietf.org Sent: Saturday, August 13, 2011 4:41 PM Subject: Re: [OAUTH-WG] Auth Code Swap Attack There are two CSRF variations scenarios that I see. I can attack you and give my client access to your resources (original attack on the resource). I can attack you and give your client access to my resource (new attack on the client). Attack on the client vs. attack on the resource may be misleading here. Draft 20 only referred to attacks on the resource in its original CSRF description. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: All OAuth CSRF attacks are on the client. EHL From: Phil Hunt phil.h...@oracle.com Date: Sat, 13 Aug 2011 00:21:50 -0700 To: Torsten Lodderstedt tors...@lodderstedt.net Cc: Eran Hammer-lahav e...@hueniverse.com, OAuth WG (oauth@ietf.org) oauth@ietf.org Subject: Re: [OAUTH-WG] Auth Code Swap Attack +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: 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. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. 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 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
