draft-ietf-oauth-spop-02.txt   draft-ietf-oauth-spop-03.txt 
OAuth Working Group N. Sakimura, Ed. OAuth Working Group N. Sakimura, Ed.
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: April 27, 2015 Ping Identity Expires: May 14, 2015 Ping Identity
N. Agarwal N. Agarwal
Google Google
October 26, 2014 November 12, 2014
Symmetric Proof of Possession for the OAuth Authorization Code Grant Symmetric Proof of Possession for the OAuth Authorization Code Grant
draft-ietf-oauth-spop-02 draft-ietf-oauth-spop-03
Abstract Abstract
The OAuth 2.0 public client utilizing Authorization Code Grant (RFC The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
6749 - 4.1) is susceptible to the code interception attack. This 6749 - 4.1) is susceptible to the code interception attack. This
specification describes a mechanism that acts as a control against specification describes a mechanism that acts as a control against
this threat. this threat.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on May 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 2 1.1. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Client creates a code verifier . . . . . . . . . . . . . . 3 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Client creates the code challenge . . . . . . . . . . . . 4 4.1. Client creates a code verifier . . . . . . . . . . . . . . 4
4.2. Client creates the code challenge . . . . . . . . . . . . 5
4.3. Client sends the code challenge with the authorization 4.3. Client sends the code challenge with the authorization
request . . . . . . . . . . . . . . . . . . . . . . . . . 4 request . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Server returns the code . . . . . . . . . . . . . . . . . 4 4.4. Server returns the code . . . . . . . . . . . . . . . . . 5
4.5. Client sends the code and the secret to the token endpoint 5 4.5. Client sends the code and the secret to the token endpoint 6
4.6. Server verifies code_verifier before returning the tokens 5 4.6. Server verifies code_verifier before returning the tokens 6
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 6 6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Entropy of the code verifier . . . . . . . . . . . . . . . 6 7.1. Entropy of the code verifier . . . . . . . . . . . . . . . 7
7.2. Protection against eavesdroppers . . . . . . . . . . . . . 6 7.2. Protection against eavesdroppers . . . . . . . . . . . . . 7
7.3. Checking the Server support . . . . . . . . . . . . . . . 7 7.3. Checking the Server support . . . . . . . . . . . . . . . 7
7.4. OAuth security considerations . . . . . . . . . . . . . . 7 7.4. OAuth security considerations . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Revision History . . . . . . . . . . . . . . . . . . . . . . . 8 9. Revision History . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Notes on implementing base64url encoding without paddin 9 Appendix A. Notes on implementing base64url encoding without paddi 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Public clients in OAuth 2.0 [RFC6749] are susceptible to the Public clients in OAuth 2.0 [RFC6749] are susceptible to the
authorization "code" interception attack. A malicious client authorization "code" interception attack. A malicious client
intercepts the authorization code returned from the authorization intercepts the authorization code returned from the authorization
endpoint and uses it to obtain the access token. This is possible on endpoint and uses it to obtain the access token. This is possible on
a public client as there is no client secret associated for it to be a public client as there is no client secret associated for it to be
sent to the token endpoint. This is especially true on Smartphone sent to the token endpoint. This is especially true on Smartphone
applications where the authorization code can be returned through applications where the authorization code can be returned through
skipping to change at page 2, line 55 skipping to change at page 2, line 56
created cryptographically random key called 'code verifier'. The code created cryptographically random key called 'code verifier'. The code
verifier is created for every authorization request and its verifier is created for every authorization request and its
transformed value, called 'code challenge', is sent to the transformed value, called 'code challenge', is sent to the
authorization server to obtain the authorization code. The authorization server to obtain the authorization code. The
authorization "code" obtained is then sent to the token endpoint with authorization "code" obtained is then sent to the token endpoint with
the 'code verifier' and the server compares it with the previously the 'code verifier' and the server compares it with the previously
received request code so that it can perform the proof of possession received request code so that it can perform the proof of possession
of the 'code verifier' by the client. This works as the mitigation of the 'code verifier' by the client. This works as the mitigation
since the attacker would not know this one-time key. since the attacker would not know this one-time key.
1.1. Protocol Flow
+--------+ +---------------+
| |--(A)-- Authorization Request --->| |
| | + t(code_verifier), t | Resource |
| | | Owner |
| |<-(B)--- Authorization Grant -----| |
| | +---------------+
| Client |
| | +---------------+
| |--(C)--- Access Token Request --->| |
| | + code_verifier | Authorization |
| | | Server |
| |<-(D)------ Access Token ---------| |
+--------+ +---------------+
This specification adds additional parameters to the OAuth 2.0
Authorization and Access Token Requests, shown in abstract form in
Figure 1.
A. The client creates and records a secret named the "code_verifier",
and derives a transformed version "t(code_verifier)" (referred to
as the "code_challenge") which is sent in the OAuth 2.0
Authorization Request, along with the transformation method "t".
B. The resource owner responds as usual, but records
"t(code_verifier)" and the transformation method.
C. The client then sends the code to the Access Token Request as
usual, but includes the "code_verifier" secret generated at (A).
D. The authorization server transforms "code_verifier" and compares
it to "t(code_verifier)" from (B). Access is denied if they are
not equal.
An attacker who intercepts the Authorization Grant at (B) is unable
to redeem it for an Access Token, as they are not in possession of
the "code_verifier" secret.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in Key "OPTIONAL" in this document are to be interpreted as described in Key
words for use in RFCs to Indicate Requirement Levels [RFC2119]. If words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
these words are used without being spelled in uppercase then they are these words are used without being spelled in uppercase then they are
to be interpreted with their normal natural language meanings. to be interpreted with their normal natural language meanings.
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
skipping to change at page 8, line 4 skipping to change at page 8, line 46
o Phil Hunt, Oracle o Phil Hunt, Oracle
o Ryo Ito, mixi o Ryo Ito, mixi
o Michael B. Jones, Microsoft o Michael B. Jones, Microsoft
o Torsten Lodderstedt, Deutsche Telekom o Torsten Lodderstedt, Deutsche Telekom
o Breno de Medeiros, Google o Breno de Medeiros, Google
o Prateek Mishra, Oracle o Prateek Mishra, Oracle
o Anthony Nadalin, Microsoft o Anthony Nadalin, Microsoft
o Axel Nenker, Deutsche Telekom o Axel Nenker, Deutsche Telekom
o Nat Sakimura, Nomura Research Institute o Nat Sakimura, Nomura Research Institute
9. Revision History 9. Revision History
-03
o Added an abstract protocol diagram and explanation
-02
o Copy edits
-01 -01
o Specified exactly two supported transformations o Specified exactly two supported transformations
o Moved discovery steps to security considerations. o Moved discovery steps to security considerations.
o Incorporated readability comments by Eduardo Gueiros. o Incorporated readability comments by Eduardo Gueiros.
o Changed MUST in 3.1 to SHOULD. o Changed MUST in 3.1 to SHOULD.
 End of changes. 13 change blocks. 
25 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/