draft-ietf-oauth-spop-08.txt   draft-ietf-oauth-spop-09.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: August 7, 2015 Ping Identity Expires: August 9, 2015 Ping Identity
N. Agarwal N. Agarwal
Google Google
February 03, 2015 February 05, 2015
Proof Key for Code Exchange by OAuth Public Clients Proof Key for Code Exchange by OAuth Public Clients
draft-ietf-oauth-spop-08 draft-ietf-oauth-spop-09
Abstract Abstract
OAuth 2.0 public clients utilizing the Authorization Code Grant are OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack. This susceptible to the authorization code interception attack. This
specification describes the attack as well as a technique to mitigate specification describes the attack as well as a technique to mitigate
against the threat. against the 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 August 7, 2015. This Internet-Draft will expire on August 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 19 skipping to change at page 4, line 19
instances use the same client id. No client secret is used (since instances use the same client id. No client secret is used (since
public clients cannot keep their secrets confidential.) public clients cannot keep their secrets confidential.)
4) The attacker (via the installed app) is able to observe responses 4) The attacker (via the installed app) is able to observe responses
from the authorization endpoint. As a more sophisticated attack from the authorization endpoint. As a more sophisticated attack
scenario the attacker is also able to observe requests (in scenario the attacker is also able to observe requests (in
addition to responses) to the authorization endpoint. The addition to responses) to the authorization endpoint. The
attacker is, however, not able to act as a man-in-the-middle. attacker is, however, not able to act as a man-in-the-middle.
While this is a long list of pre-conditions the described attack has While this is a long list of pre-conditions the described attack has
been observed in the wild and has to be considered in OAuth 2.0 been observed in the wild and has to be considered in OAuth 2.0
deployments. While Section 4.4.1 of [RFC6819] describes mitigation deployments.
techniques they are, unfortunately, not applicable since they rely on While the OAuth 2.0 Threat Model Section 4.4.1 [RFC6819] describes
a per-client instance secret or aper client instance redirect URI. mitigation techniques they are, unfortunately, not applicable since
they rely on a per-client instance secret or aper client instance
redirect URI.
To mitigate this attack, this extension utilizes a dynamically To mitigate this attack, this extension utilizes a dynamically
created cryptographically random key called 'code verifier'. A created cryptographically random key called 'code verifier'. A
unique code verifier is created for every authorization request and unique code verifier is created for every authorization request and
its transformed value, called 'code challenge', is sent to the its 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
skipping to change at page 6, line 34 skipping to change at page 6, line 34
3. Terminology 3. Terminology
In addition to the terms defined in OAuth 2.0 [RFC6749], this In addition to the terms defined in OAuth 2.0 [RFC6749], this
specification defines the following terms: specification defines the following terms:
code verifier A cryptographically random string that is used to code verifier A cryptographically random string that is used to
correlate the authorization request to the token request. correlate the authorization request to the token request.
code challenge A challenge derived from the code verifier that is code challenge A challenge derived from the code verifier that is
sent in the authorization request, to be verified against later. sent in the authorization request, to be verified against later.
Base64url Encoding Base64 encoding using the URL- and filename-safe Base64url Encoding Base64 encoding using the URL- and filename-safe
character set defined in Section 5 of RFC 4648 [RFC4648], with all character set defined in Section 5 of [RFC4648], with all trailing
trailing '=' characters omitted (as permitted by Section 3.2) and '=' characters omitted (as permitted by Section 3.2 of [RFC4648])
without the inclusion of any line breaks, whitespace, or other and without the inclusion of any line breaks, whitespace, or other
additional characters. (See Appendix A for notes on implementing additional characters. (See Appendix A for notes on implementing
base64url encoding without padding.) base64url encoding without padding.)
4. Protocol 4. Protocol
4.1. Client creates a code verifier 4.1. Client creates a code verifier
The client first creates a code verifier, "code_verifier", for each The client first creates a code verifier, "code_verifier", for each
OAuth 2.0 [RFC6749] Authorization Request, in the following manner: OAuth 2.0 [RFC6749] Authorization Request, in the following manner:
skipping to change at page 7, line 38 skipping to change at page 7, line 38
ABNF for "code_challenge" is as follows. ABNF for "code_challenge" is as follows.
code-challenge = 42*128unreserved code-challenge = 42*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39 DIGIT = %x30-39
4.3. Client sends the code challenge with the authorization request 4.3. Client sends the code challenge with the authorization request
The client sends the code challenge as part of the OAuth 2.0 The client sends the code challenge as part of the OAuth 2.0
[RFC6749] Authorization Request (Section 4.1.1.) using the following Authorization Request (Section 4.1.1 of [RFC6749].) using the
additional parameters: following additional parameters:
code_challenge REQUIRED. Code challenge. code_challenge REQUIRED. Code challenge.
code_challenge_method OPTIONAL, defaults to "plain". Code verifier code_challenge_method OPTIONAL, defaults to "plain". Code verifier
transformation method, "S256" or "plain". transformation method, "S256" or "plain".
4.4. Server returns the code 4.4. Server returns the code
When the server issues the "code" in the Authorization Response, it When the server issues the "code" in the Authorization Response, it
MUST associate the "code_challenge" and "code_challenge_method" MUST associate the "code_challenge" and "code_challenge_method"
skipping to change at page 8, line 38 skipping to change at page 8, line 38
nature of error, e.g., transform algorithm not supported. nature of error, e.g., transform algorithm not supported.
If the client is capable of using "S256", it MUST use "S256", as If the client is capable of using "S256", it MUST use "S256", as
"S256" is MTI on the server. Clients MAY use plain only if they "S256" is MTI on the server. Clients MAY use plain only if they
cannot support "S256" for some technical reason and knows that the cannot support "S256" for some technical reason and knows that the
server supports "plain". server supports "plain".
4.5. Client sends the code and the secret to the token endpoint 4.5. Client sends the code and the secret to the token endpoint
Upon receipt of the "code", the client sends the Access Token Request Upon receipt of the "code", the client sends the Access Token Request
to the token endpoint. In addition to the parameters defined in to the token endpoint. In addition to the parameters defined in the
OAuth 2.0 [RFC6749] Access Token Request (Section 4.1.3.), it sends OAuth 2.0 Access Token Request (Section 4.1.3 of [RFC6749]), it sends
the following parameter: the following parameter:
code_verifier REQUIRED. Code verifier code_verifier REQUIRED. Code verifier
4.6. Server verifies code_verifier before returning the tokens 4.6. Server verifies code_verifier before returning the tokens
Upon receipt of the request at the Access Token endpoint, the server Upon receipt of the request at the Access Token endpoint, the server
verifies it by calculating the code challenge from received verifies it by calculating the code challenge from received
"code_verifier" and comparing it with the previously associated "code_verifier" and comparing it with the previously associated
"code_challenge", after first transforming it according to the "code_challenge", after first transforming it according to the
skipping to change at page 9, line 20 skipping to change at page 9, line 20
DECODE("code_challenge"). DECODE("code_challenge").
If the "code_challenge_method" from Section 4.2 was "plain", they are If the "code_challenge_method" from Section 4.2 was "plain", they are
compared directly. i.e., compared directly. i.e.,
"code_challenge" == "code_verifier". "code_challenge" == "code_verifier".
If the values are equal, the Access Token endpoint MUST continue If the values are equal, the Access Token endpoint MUST continue
processing as normal (as defined by OAuth 2.0 [RFC6749]). If the processing as normal (as defined by OAuth 2.0 [RFC6749]). If the
values are not equal, an error response indicating "invalid_grant" as values are not equal, an error response indicating "invalid_grant" as
described in section 5.2 of OAuth 2.0 [RFC6749] MUST be returned. described in section 5.2 of [RFC6749] MUST be returned.
5. Compatibility 5. Compatibility
Server implementations of this specification MAY accept OAuth2.0 Server implementations of this specification MAY accept OAuth2.0
Clients that do not implement this extension. If the "code_verifier" Clients that do not implement this extension. If the "code_verifier"
is not received from the client in the Authorization Request, servers is not received from the client in the Authorization Request, servers
supporting backwards compatibility SHOULD revert to a normal OAuth supporting backwards compatibility SHOULD revert to a normal OAuth
2.0 [RFC6749] protocol. 2.0 [RFC6749] protocol.
As the OAuth 2.0 [RFC6749] server responses are unchanged by this As the OAuth 2.0 [RFC6749] server responses are unchanged by this
skipping to change at page 13, line 31 skipping to change at page 13, line 31
Prateek Mishra, Oracle Prateek Mishra, Oracle
Ryo Ito, mixi Ryo Ito, mixi
Scott Tomilson, Ping Identity Scott Tomilson, Ping Identity
Sergey Beryozkin Sergey Beryozkin
Takamichi Saito Takamichi Saito
Torsten Lodderstedt, Deutsche Telekom Torsten Lodderstedt, Deutsche Telekom
William Denniss, Google William Denniss, Google
9. Revision History 9. Revision History
-08
o clean up some external references so they don't point at internal
sections
-07 -07
o changed BASE64URL to BASE64URL-ENCODE to be more consistent with o changed BASE64URL to BASE64URL-ENCODE to be more consistent with
appendix A Fixed lowercase base64url in appendix B appendix A Fixed lowercase base64url in appendix B
o Added appendix B as an example of S256 processing o Added appendix B as an example of S256 processing
o Change reference for unreserved characters to RFC3986 from o Change reference for unreserved characters to RFC3986 from
base64URL base64URL
-07 -07
 End of changes. 10 change blocks. 
15 lines changed or deleted 22 lines changed or added

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