draft-ietf-oauth-jwsreq-18.txt   draft-ietf-oauth-jwsreq-19.txt 
OAuth Working Group N. Sakimura OAuth Working Group N. Sakimura
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: November 17, 2019 Yubico Expires: December 12, 2019 Yubico
May 16, 2019 June 10, 2019
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR) (JAR)
draft-ietf-oauth-jwsreq-18 draft-ietf-oauth-jwsreq-19
Abstract Abstract
The authorization request in OAuth 2.0 described in RFC 6749 utilizes The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b) integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of the source of the communication is not authenticated. Because of
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 17, 2019. This Internet-Draft will expire on December 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 9 skipping to change at page 3, line 9
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16
11. TLS security considerations . . . . . . . . . . . . . . . . . 17 11. TLS security considerations . . . . . . . . . . . . . . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Collection limitation . . . . . . . . . . . . . . . . . 17 12.1. Collection limitation . . . . . . . . . . . . . . . . . 17
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18
12.2.2. Tracking using Request Object URI . . . . . . . . . 18 12.2.2. Tracking using Request Object URI . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Authorization Request in OAuth 2.0 [RFC6749] utilizes query The Authorization Request in OAuth 2.0 [RFC6749] utilizes query
parameter serialization and is typically sent through user agents parameter serialization and is typically sent through user agents
such as web browsers. such as web browsers.
For example, the parameters "response_type", "client_id", "state", For example, the parameters "response_type", "client_id", "state",
skipping to change at page 11, line 11 skipping to change at page 11, line 11
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
5.2.1. URI Referencing the Request Object 5.2.1. URI Referencing the Request Object
The Client stores the Request Object resource either locally or The Client stores the Request Object resource either locally or
remotely at a URI the Authorization Server can access. Such facility remotely at a URI the Authorization Server can access. Such facility
may be provided by the authorization server or a third party. For may be provided by the authorization server or a third party. For
example, the authorization server may provide a URL to which the example, the authorization server may provide a URL to which the
client POSTs the request object and obtains the Requiest URI. This client POSTs the request object and obtains the Request URI. This
URI is the Request Object URI, "request_uri". URI is the Request Object URI, "request_uri".
It is possible for the Request Object to include values that are to It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. For "request_uri" MUST have appropriate entropy for its lifetime. For
the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED
that it be removed after a reasonable timeout unless access control that it be removed after a reasonable timeout unless access control
measures are taken. measures are taken.
The following is an example of a Request Object URI value (with line The following is an example of a Request Object URI value (with line
skipping to change at page 14, line 25 skipping to change at page 14, line 25
in the subjectAltName extension) is REQUIRED. Certification in the subjectAltName extension) is REQUIRED. Certification
authorities which issue server certificates MUST support the DNS- authorities which issue server certificates MUST support the DNS-
ID identifier type, and the DNS-ID identifier type MUST be present ID identifier type, and the DNS-ID identifier type MUST be present
in server certificates. in server certificates.
o DNS names in server certificates MAY contain the wildcard o DNS names in server certificates MAY contain the wildcard
character "*". character "*".
o Clients MUST NOT use CN-ID identifiers; a CN field may be present o Clients MUST NOT use CN-ID identifiers; a CN field may be present
in the server certificate's subject name, but MUST NOT be used for in the server certificate's subject name, but MUST NOT be used for
authentication within the rules described in [BCP195] . authentication within the rules described in [BCP195].
o SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST o SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST
NOT be used for comparison. NOT be used for comparison.
9. IANA Considerations 9. IANA Considerations
This specification requests no actions by IANA. This specification requests no actions by IANA.
10. Security Considerations 10. Security Considerations
skipping to change at page 16, line 17 skipping to change at page 16, line 17
(d) Token Endpoint ("token_endpoint") (d) Token Endpoint ("token_endpoint")
Further, if dynamic discovery is used, then the discovery related Further, if dynamic discovery is used, then the discovery related
endpoints also come into question. endpoints also come into question.
In [RFC6749], while Redirection URI is included, others are not In [RFC6749], while Redirection URI is included, others are not
included in the Authorization Request. As the result, the same included in the Authorization Request. As the result, the same
applies to Authorization Request Object. applies to Authorization Request Object.
The lack of the link among those endpoints are sited as the cause of The lack of the link among those endpoints are cited as the cause of
Cross-Phase Attacks introduced in [FETT]. An extension specification Cross-Phase Attacks introduced in [FETT]. An extension specification
should be created as a measure to address the risk. should be created as a measure to address the risk.
10.4. Risks Associated with request_uri 10.4. Risks Associated with request_uri
The introduction of "request_uri" introduces several attack The introduction of "request_uri" introduces several attack
possibilities. possibilities.
10.4.1. DDoS Attack on the Authorization Server 10.4.1. DDoS Attack on the Authorization Server
skipping to change at page 17, line 13 skipping to change at page 17, line 13
of "request_uri" to be that of the victim. of "request_uri" to be that of the victim.
To prevent such attack to succeed, the server should (a) check that To prevent such attack to succeed, the server should (a) check that
the value of "request_uri" parameter does not point to an unexpected the value of "request_uri" parameter does not point to an unexpected
location, (b) check the content type of the response is "application/ location, (b) check the content type of the response is "application/
jwt" (c) implement a time-out for obtaining the content of jwt" (c) implement a time-out for obtaining the content of
"request_uri". "request_uri".
11. TLS security considerations 11. TLS security considerations
Curent security considerations can be found in Recommendations for Current security considerations can be found in Recommendations for
Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version
recommendations in OAuth 2.0 [RFC6749]. recommendations in OAuth 2.0 [RFC6749].
12. Privacy Considerations 12. Privacy Considerations
When the Client is being granted access to a protected resource When the Client is being granted access to a protected resource
containing personal data, both the Client and the Authorization containing personal data, both the Client and the Authorization
Server need to adhere to Privacy Principles. RFC 6973 Privacy Server need to adhere to Privacy Principles. RFC 6973 Privacy
Considerations for Internet Protocols [RFC6973] gives excellent Considerations for Internet Protocols [RFC6973] gives excellent
guidance on the enhancement of protocol design and implementation. guidance on the enhancement of protocol design and implementation.
skipping to change at page 19, line 29 skipping to change at page 19, line 29
Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer
(Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke
Shepard (Facebook). Shepard (Facebook).
14. Revision History 14. Revision History
Note to the RFC Editor: Please remove this section from the final Note to the RFC Editor: Please remove this section from the final
RFC. RFC.
-19
o AD cooments
o Section 5.2.1. s/Requiest URI/Request URI/
o Section 8 s/[BCP195] ./[BCP195]./
o Section 10.3. s/sited/cited/
o Section 11. Typo. s/Curent/Current/
-17 -17
o #78 Typos in content-type o #78 Typos in content-type
-16 -16
o Treated remaining Ben Campbell comments. o Treated remaining Ben Campbell comments.
-15 -15
 End of changes. 9 change blocks. 
9 lines changed or deleted 21 lines changed or added

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