draft-ietf-oauth-spop-11.txt   draft-ietf-oauth-spop-12.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: November 18, 2015 Ping Identity Expires: December 8, 2015 Ping Identity
N. Agarwal N. Agarwal
Google Google
May 17, 2015 June 6, 2015
Proof Key for Code Exchange by OAuth Public Clients Proof Key for Code Exchange by OAuth Public Clients
draft-ietf-oauth-spop-11 draft-ietf-oauth-spop-12
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 November 18, 2015. This Internet-Draft will expire on December 8, 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 30 skipping to change at page 2, line 30
4.5. Client sends the code and the secret to the token 4.5. Client sends the code and the secret to the token
endpoint . . . . . . . . . . . . . . . . . . . . . . . . 8 endpoint . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Server verifies code_verifier before returning the tokens 8 4.6. Server verifies code_verifier before returning the tokens 8
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9
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. Salting the code_challenge . . . . . . . . . . . . . . . 12
7.4. OAuth security considerations . . . . . . . . . . . . . . 12 7.4. OAuth security considerations . . . . . . . . . . . . . . 12
7.5. TLS 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 . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Notes on implementing base64url encoding without Appendix A. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . 18
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
TLS, such as inter-app communication within the operating system of TLS, such as inter-app communication within the operating system of
the client. the client.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
A number of pre-conditions need to hold in order for this attack to A number of pre-conditions need to hold in order for this attack to
work: work:
1) The attacker manages to register a malicious application on the 1) The attacker manages to register a malicious application on the
client device and registers a custom URI scheme that is also used client device and registers a custom URI scheme that is also used
by another application. by another application.
The operating systems must allow a custom URI schemes to be The operating systems must allow a custom URI schemes to be
registered by multiple applications. registered by multiple applications.
2) The OAuth 2.0 authorization code grant is used. 2) The OAuth 2.0 authorization code grant is used.
3) The attacker has access to the client id. All native app client- 3) The attacker has access to the OAuth 2.0 [RFC6749] client_id and
instances use the same client id. No client secret is used (since client_secret(if provisioned). All OAuth 2.0 native app client-
public clients cannot keep their secrets confidential.) instances use the same client_id. Secrets provisioned in client
binary applications cannot be considered 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. deployments.
While the OAuth 2.0 Threat Model Section 4.4.1 [RFC6819] describes While the OAuth 2.0 Threat Model Section 4.4.1 [RFC6819] describes
skipping to change at page 11, line 25 skipping to change at page 11, line 25
o Code Challenge Method Parameter Name: "plain" o Code Challenge Method Parameter Name: "plain"
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Code Challenge Method Parameter Name: "S256" o Code Challenge Method Parameter Name: "S256"
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
7. Security Considerations 7. Security Considerations
7.1. Entropy of the code verifier 7.1. Entropy of the code_verifier
The security model relies on the fact that the code verifier is not The security model relies on the fact that the code verifier is not
learned or guessed by the attacker. It is vitally important to learned or guessed by the attacker. It is vitally important to
adhere to this principle. As such, the code verifier has to be adhere to this principle. As such, the code verifier has to be
created in such a manner that it is cryptographically random and has created in such a manner that it is cryptographically random and has
high entropy that it is not practical for the attacker to guess. It high entropy that it is not practical for the attacker to guess.
is RECOMMENDED that the output of a suitable random number generator
be used to create a 32-octet sequence. The client SHOULD create a code_verifier with a minimum of 256bits of
entropy. This can be done by having a suitable random number
generator create a 32-octet sequence. The Octet sequence can then be
base64url encoded to produce a 43-octet URL safe string to use as a
code_challenge that has the required entropy.
7.2. Protection against eavesdroppers 7.2. Protection against eavesdroppers
Clients MUST NOT try down grading the algorithm after trying "S256" Clients MUST NOT try down grading the algorithm after trying "S256"
method. If the server is PKCE compliant, then "S256" method works. method. If the server is PKCE compliant, then "S256" method works.
If the server does not support PKCE, it does not generate error. If the server does not support PKCE, it does not generate error.
Only the time that the server returns that it does not support "S256" Only the time that the server returns that it does not support "S256"
is there is a MITM trying the algorithm downgrade attack. is there is a MITM trying the algorithm downgrade attack.
"S256" method protects against eavesdroppers observing or "S256" method protects against eavesdroppers observing or
intercepting the "code_challenge". If the "plain" method is used, intercepting the "code_challenge". If the "plain" method is used,
there is a chance that it will be observed by the attacker on the there is a chance that it will be observed by the attacker on the
device. The use of "S256" protects against it. device. The use of "S256" protects against it.
If "code_challenge" is to be returned inside authorization "code" to If "code_challenge" is to be returned inside authorization "code" to
achieve a stateless server, it has to be encrypted in such a manner achieve a stateless server, it has to be encrypted in such a manner
that only the server can decrypt and extract it. that only the server can decrypt and extract it.
7.3. Entropy of the code_verifier 7.3. Salting the code_challenge
The client SHOULD create a code_verifier with a minimum of 256bits of
entropy. This can be done by having a suitable random number
generator create a 32-octet sequence. The Octet sequence can then be
base64url encoded to produce a 43-octet URL safe string to use as a
code_challenge that has the required entropy.
Salting is not used in the production of the code_verifier, as the In order to reduce implementation complexity Salting is not used in
code_chalange contains sufficient entropy to prevent brute force the production of the code_challenge, as the code_verifier contains
attacks. Concatenating a publicly known value to a code_challenge sufficient entropy to prevent brute force attacks. Concatenating a
(with 256 bits of entropy) and then hashing it with SHA256 would publicly known value to a code_verifier (containing 256 bits of
actually reduce the entropy in the resulting code_verifier making it entropy) and then hashing it with SHA256 to produce a code_challenge
easier for an attacker to brute force. would not increase the number of attempts necessary to brute force a
valid value for code_verifier.
While the S256 transformation is like hashing a password there are While the S256 transformation is like hashing a password there are
important differences. Passwords tend to be relatively low entropy important differences. Passwords tend to be relatively low entropy
words that can be hashed offline and the hash looked up in a words that can be hashed offline and the hash looked up in a
dictionary. By concatenating a unique though public value to each dictionary. By concatenating a unique though public value to each
password prior to hashing, the dictionary space that an attacker password prior to hashing, the dictionary space that an attacker
needs to search is greatly expanded. needs to search is greatly expanded.
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
skipping to change at page 13, line 34 skipping to change at page 13, line 32
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
-12
o clarify that the client secret we are talking about in the
Introduction is a OAuth 2 client_secret.
o Update salting security consideration based on Ben's feedback
-11 -11
o add spanx for plain in sec 4.4 RE Kathleen's comment o add spanx for plain in sec 4.4 RE Kathleen's comment
o Add security consideration on TLS and reference BCP195 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
 End of changes. 13 change blocks. 
27 lines changed or deleted 33 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/