SlideShare a Scribd company logo

OAuth SPOP @ IETF 91

•
•
Nat Sakimura
Nat Sakimura

This document discusses Symmetric Proof of Possession for Code (SPOP), a proposed solution to mitigate code interception attacks in OAuth public clients. It describes the problem of attackers intercepting authorization codes instead of the client. The solution proposes having clients generate a cryptographic code challenge to send with authorization requests and verify later with a code verifier. The draft proposes support for plain or SHA256 challenges and defines error responses. It is in IETF last call and seeks comments to improve text clarifications and define error responses.

1 of 10
Download to read offline
IETF 91 OAuth SPOP (Symmetric Proof of Possession for Code) Nat Sakimura Nomura Research Institute, Ltd. John Bradley Ping Identity draft-ietf-oauth-spop-02 2014/11/12
Copyright（C） 2014 Nomura Research Institute,, CC-BY Problem Statement 1 Code interception attack (against public clients) A malicious client gets the code instead of the client via registering the same scheme as the client, etc. 2 Authz Server 2. Authz req. 3. code 1. Authz req. Browser client attacker 5. Token request (w/o client secret) 6. token 4. code The problem is not theoretical. A very large provider has been experiencing it.
Copyright（C） 2014 Nomura Research Institute,, CC-BY Solution 1 Have the client create a one-time-credential and send it with the Authz req. Based on the assumption that attacker cannot observe the request. 3 Authz Server 2. Authz req. w/ code_challenge 3. code 1.Authz req. w/ code_challenge Browser / App client attacker 5. Token request w/o code verifier 6. fail 4. code 0. Make code_verifier and code_challenge = code_verifier
Copyright（C） 2014 Nomura Research Institute,, CC-BY Problem Statement 2 Code interception attack (against public clients) + Authz req Observation In addition to the code interception, he can actually see the AuthZ request, so it can see the code_challenge. 4 Authz Server 2. Authz req. 3. code 1. Authz req. Browser / APP client attacker 5. Token request (w/o client secret) 6. token 4. code In some platform, it is possible for other apps to observe the inter-app communication.
Copyright（C） 2014 Nomura Research Institute,, CC-BY Solution 2 Have the client create a one-time-credential and send it with the Authz req. Based on the assumption that attacker cannot observe the request. 5 Authz Server 2. Authz req. w/ code_challenge 3. code 1.Authz req. w/ code_challenge Browser / App client attacker 5. Token request w/o code verifier 6. fail 4. code 0. Make code_verifier and code_challenge = SHA256(code_verifier)
Copyright（C） 2014 Nomura Research Institute,, CC-BY Current Proposal Server MUST: plain S256 (sha256) MAY support: none – plain OAuth ▪for compatibility with existing clients 6
Copyright（C） 2014 Nomura Research Institute,, CC-BY FAQ Why does it not use asymmetric crypto? Discovery of key and crypto algs, protocols, etc. . Complexity. Why not only support SHA256? Some client has no access to crypto libraries OR hard for them to use. Clients can select based on the risk profile of the OS. ▪Simplifies the code. (Graceful fallback and backward compatibility) Why not re-use the client secret field? It is not the transient client secret. It is a secret for code, so semantically, it is different and we should not overload the field. 7
Copyright（C） 2014 Nomura Research Institute,, CC-BY Draft is available as: https://tools.ietf.org/html/draft-ietf-oauth-spop-02 WG LAST CALL Send comments NOW! 8
Copyright（C） 2014 Nomura Research Institute,, CC-BY Todo: define error responses. Error response to authorization request Returns invalid_request with additional error param spop_error with the following values: ▪S256_unsupported ▪none_unsupported ▪invalid_code_challenge Error response to token request Returns invalid_request with additional error param spop_error with the following values: ▪invalid _code_verifier ▪verifier_challenge_mismatch Authorization server should return more descriptive information on error_description error_uri 9 clients MUST NOT accept the downgrade request through this as it may be a downgrade attack by a MITM.
Copyright（C） 2014 Nomura Research Institute,, CC-BY ToDo: text clarifications It should make it clear that it is trying to mitigate the communication that is not protected by TLS: the inter-app communication. It should make it clear that for the “request”, it is not about MITM but the “observer” that it is trying to protect. It should make it clear that it is about transient secret for “code”, that it is authenticating the “code”. 10

More Related Content

OAuth SPOP @ IETF 91

  • 1. IETF 91 OAuth SPOP (Symmetric Proof of Possession for Code) Nat Sakimura Nomura Research Institute, Ltd. John Bradley Ping Identity draft-ietf-oauth-spop-02 2014/11/12
  • 2. Copyright（C） 2014 Nomura Research Institute,, CC-BY Problem Statement 1 Code interception attack (against public clients) A malicious client gets the code instead of the client via registering the same scheme as the client, etc. 2 Authz Server 2. Authz req. 3. code 1. Authz req. Browser client attacker 5. Token request (w/o client secret) 6. token 4. code The problem is not theoretical. A very large provider has been experiencing it.
  • 3. Copyright（C） 2014 Nomura Research Institute,, CC-BY Solution 1 Have the client create a one-time-credential and send it with the Authz req. Based on the assumption that attacker cannot observe the request. 3 Authz Server 2. Authz req. w/ code_challenge 3. code 1.Authz req. w/ code_challenge Browser / App client attacker 5. Token request w/o code verifier 6. fail 4. code 0. Make code_verifier and code_challenge = code_verifier
  • 4. Copyright（C） 2014 Nomura Research Institute,, CC-BY Problem Statement 2 Code interception attack (against public clients) + Authz req Observation In addition to the code interception, he can actually see the AuthZ request, so it can see the code_challenge. 4 Authz Server 2. Authz req. 3. code 1. Authz req. Browser / APP client attacker 5. Token request (w/o client secret) 6. token 4. code In some platform, it is possible for other apps to observe the inter-app communication.
  • 5. Copyright（C） 2014 Nomura Research Institute,, CC-BY Solution 2 Have the client create a one-time-credential and send it with the Authz req. Based on the assumption that attacker cannot observe the request. 5 Authz Server 2. Authz req. w/ code_challenge 3. code 1.Authz req. w/ code_challenge Browser / App client attacker 5. Token request w/o code verifier 6. fail 4. code 0. Make code_verifier and code_challenge = SHA256(code_verifier)
  • 6. Copyright（C） 2014 Nomura Research Institute,, CC-BY Current Proposal Server MUST: plain S256 (sha256) MAY support: none – plain OAuth ▪for compatibility with existing clients 6
  • 7. Copyright（C） 2014 Nomura Research Institute,, CC-BY FAQ Why does it not use asymmetric crypto? Discovery of key and crypto algs, protocols, etc. . Complexity. Why not only support SHA256? Some client has no access to crypto libraries OR hard for them to use. Clients can select based on the risk profile of the OS. ▪Simplifies the code. (Graceful fallback and backward compatibility) Why not re-use the client secret field? It is not the transient client secret. It is a secret for code, so semantically, it is different and we should not overload the field. 7
  • 8. Copyright（C） 2014 Nomura Research Institute,, CC-BY Draft is available as: https://tools.ietf.org/html/draft-ietf-oauth-spop-02 WG LAST CALL Send comments NOW! 8
  • 9. Copyright（C） 2014 Nomura Research Institute,, CC-BY Todo: define error responses. Error response to authorization request Returns invalid_request with additional error param spop_error with the following values: ▪S256_unsupported ▪none_unsupported ▪invalid_code_challenge Error response to token request Returns invalid_request with additional error param spop_error with the following values: ▪invalid _code_verifier ▪verifier_challenge_mismatch Authorization server should return more descriptive information on error_description error_uri 9 clients MUST NOT accept the downgrade request through this as it may be a downgrade attack by a MITM.
  • 10. Copyright（C） 2014 Nomura Research Institute,, CC-BY ToDo: text clarifications It should make it clear that it is trying to mitigate the communication that is not protected by TLS: the inter-app communication. It should make it clear that for the “request”, it is not about MITM but the “observer” that it is trying to protect. It should make it clear that it is about transient secret for “code”, that it is authenticating the “code”. 10