draft-ietf-oauth-spop-10.txt   draft-ietf-oauth-spop-11.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 10, 2015 Ping Identity Expires: November 18, 2015 Ping Identity
N. Agarwal N. Agarwal
Google Google
February 06, 2015 May 17, 2015
Proof Key for Code Exchange by OAuth Public Clients Proof Key for Code Exchange by OAuth Public Clients
draft-ietf-oauth-spop-10 draft-ietf-oauth-spop-11
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 10, 2015. This Internet-Draft will expire on November 18, 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 2, line 34 skipping to change at page 2, line 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 9 6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 9
6.2. PKCE Code Challenge Method Registry . . . . . . . . . . . 10 6.2. PKCE Code Challenge Method Registry . . . . . . . . . . . 10
6.2.1. Registration Template . . . . . . . . . . . . . . . . 10 6.2.1. Registration Template . . . . . . . . . . . . . . . . 10
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 11 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Entropy of the code verifier . . . . . . . . . . . . . . 11 7.1. Entropy of the code verifier . . . . . . . . . . . . . . 11
7.2. Protection against eavesdroppers . . . . . . . . . . . . 11 7.2. Protection against eavesdroppers . . . . . . . . . . . . 11
7.3. Entropy of the code_verifier . . . . . . . . . . . . . . 12 7.3. Entropy of the code_verifier . . . . . . . . . . . . . . 12
7.4. OAuth security considerations . . . . . . . . . . . . . . 12 7.4. OAuth security considerations . . . . . . . . . . . . . . 12
7.5. TLS security considerations . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 9. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Notes on implementing base64url encoding without Appendix A. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . 15 padding . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Example for the S256 code_challenge_method . . . . . 16 Appendix B. Example for the S256 code_challenge_method . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
OAuth 2.0 [RFC6749] public clients are susceptible to the OAuth 2.0 [RFC6749] public clients are susceptible to the
authorization "code" interception attack. authorization "code" interception attack.
The attacker thereby intercepts the authorization code returned from The attacker thereby intercepts the authorization code returned from
the authorization endpoint within communication path not protected by the authorization endpoint within communication path not protected by
skipping to change at page 6, line 49 skipping to change at page 6, line 49
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:
code_verifier = high entropy cryptographic random STRING using the code_verifier = high entropy cryptographic random STRING using the
Unreserved Characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" Unreserved Characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
from Sec 2.3 of RFC 3986 [RFC3986], with a minimum length of 43 from Sec 2.3 of [RFC3986], with a minimum length of 43 characters and
characters and a maximum length of 128 characters. a maximum length of 128 characters.
ABNF for "code_verifier" is as follows. ABNF for "code_verifier" is as follows.
code-verifier = 43*128unreserved code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39 DIGIT = %x30-39
NOTE: code verifier SHOULD have enough entropy to make it impractical NOTE: code verifier SHOULD have enough entropy to make it impractical
to guess the value. It is RECOMMENDED that the output of a suitable to guess the value. It is RECOMMENDED that the output of a suitable
skipping to change at page 8, line 32 skipping to change at page 8, line 32
required. required.
If the server supporting PKCE does not support the requested If the server supporting PKCE does not support the requested
transform, the authorization endpoint MUST return the authorization transform, the authorization endpoint MUST return the authorization
error response with "error" value set to "invalid_request". The error response with "error" value set to "invalid_request". The
"error_description" or the response of "error_uri" SHOULD explain the "error_description" or the response of "error_uri" SHOULD explain the
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 Mandatory To Implement (MTI) on the server. Clients MAY "S256" is Mandatory To Implement (MTI) on the server. Clients MAY
use plain only if they cannot support "S256" for some technical use "plain" only if they cannot support "S256" for some technical
reason and knows that the server supports "plain". reason and knows that the 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 the to the token endpoint. In addition to the parameters defined in the
OAuth 2.0 Access Token Request (Section 4.1.3 of [RFC6749]), 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
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Modern graphics processors now allow attackers to calculate hashes in Modern graphics processors now allow attackers to calculate hashes in
real time faster than they could be looked up from a disk. This real time faster than they could be looked up from a disk. This
eliminates the value of the salt in increasing the complexity of a eliminates the value of the salt in increasing the complexity of a
brute force attack for even low entropy passwords. brute force attack for even low entropy passwords.
7.4. OAuth security considerations 7.4. OAuth security considerations
All the OAuth security analysis presented in [RFC6819] applies so All the OAuth security analysis presented in [RFC6819] applies so
readers SHOULD carefully follow it. readers SHOULD carefully follow it.
7.5. TLS security considerations
Curent security considerations can be found in Recommendations for
Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version
recommendations in OAuth 2.0 [RFC6749].
8. Acknowledgements 8. Acknowledgements
The initial draft of this specification was created by the OpenID AB/ The initial draft of this specification was created by the OpenID AB/
Connect Working Group of the OpenID Foundation. Connect Working Group of the OpenID Foundation.
This specification is the work of the OAuth Working Group, which This specification is the work of the OAuth Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that shaped and formed the final specification: that shaped and formed the final specification:
skipping to change at page 13, line 27 skipping to change at page 13, line 34
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
-11
o add spanx for plain in sec 4.4 RE Kathleen's comment
o Add security consideration on TLS and reference BCP195
-10 -10
o re #33 specify lower limit to code_verifier in prose o re #33 specify lower limit to code_verifier in prose
o remove base64url decode from draft, all steps now use encode only o remove base64url decode from draft, all steps now use encode only
o Expanded MTI o Expanded MTI
o re #33 change length of 32 octet base64url encoded string back to o re #33 change length of 32 octet base64url encoded string back to
43 octets 43 octets
-09 -09
skipping to change at page 15, line 16 skipping to change at page 15, line 25
o Changed MUST in 3.1 to SHOULD. o Changed MUST in 3.1 to SHOULD.
-00 -00
o Initial IETF version. o Initial IETF version.
10. References 10. References
10.1. Normative References 10.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
 End of changes. 12 change blocks. 
9 lines changed or deleted 26 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/