idnits 2.17.1 draft-ietf-oauth-mix-up-mitigation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3629' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC7662' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC7591' is defined on line 560, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-09) exists of draft-bradley-oauth-jwt-encoded-state-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Bradley 5 Expires: January 7, 2017 Ping Identity 6 N. Sakimura 7 NRI 8 July 6, 2016 10 OAuth 2.0 Mix-Up Mitigation 11 draft-ietf-oauth-mix-up-mitigation-01 13 Abstract 15 This specification defines an extension to The OAuth 2.0 16 Authorization Framework that enables the authorization server to 17 dynamically provide the client using it with additional information 18 about the current protocol interaction that can be validated by the 19 client and that enables the client to dynamically provide the 20 authorization server with additional information about the current 21 protocol interaction that can be validated by the authorization 22 server. This additional information can be used by the client and 23 the authorization server to prevent classes of attacks in which the 24 client might otherwise be tricked into using inconsistent sets of 25 metadata from multiple authorization servers, including potentially 26 using a token endpoint that does not belong to the same authorization 27 server as the authorization endpoint used. Recent research 28 publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" 29 attacks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 7, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Notation and Conventions . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. The OAuth Issuer Identifier . . . . . . . . . . . . . . . . . 4 69 3. Mitigation Data Returned in Authorization Response . . . . . 5 70 3.1. Mitigation Data Returned in Authorization Response 71 Parameters . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Example Authorization Response using Response 73 Parameters . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Mitigation Data Returned in JWT . . . . . . . . . . . . . 6 75 3.2.1. Example Authorization Response using JWT . . . . . . 6 76 4. Validating the Authorization Response . . . . . . . . . . . . 7 77 5. Mitigation Data Sent to the Token Endpoint . . . . . . . . . 8 78 5.1. Example Token Request . . . . . . . . . . . . . . . . . . 8 79 6. Validating the Token Request . . . . . . . . . . . . . . . . 9 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7.1. IdP Mix-Up and Malicious Endpoint Attacks . . . . . . . . 9 82 7.2. Duplicate Information Attacks . . . . . . . . . . . . . . 9 83 7.3. Cut-and-Paste Attacks . . . . . . . . . . . . . . . . . . 10 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 8.1. OAuth Parameters Registration . . . . . . . . . . . . . . 11 86 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 13 91 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 92 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 14 93 Appendix D. Document History . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 OAuth 2.0 [RFC6749] clients use multiple authorization server 99 endpoints when using some OAuth response types. For instance, when 100 using the "code" response type, the client uses both the 101 authorization endpoint and the token endpoint. It is important that 102 endpoints belonging to the same authorization server always be used 103 together. Otherwise, information produced by one authorization 104 server could mistakenly be sent by the client to different 105 authorization server, resulting in some of the attacks described in 106 Section 7. Recent research publications refer to these specific 107 attacks as "IdP Mix-Up" [arXiv.1601.01229v2] and "Malicious Endpoint" 108 [arXiv.1508.04324v2] attacks. 110 The client obviously cannot be confused into using endpoints from 111 multiple authorization servers in an authorization flow if the client 112 is configured to use only a single authorization server. However, 113 the client can potentially be tricked into mixing endpoints if it is 114 configured to use more than one authorization server, whether the 115 configuration is dynamic or static. The client may be confused if it 116 has no way to determine whether the set of endpoints belongs to the 117 same authorization server. Or, a client may be confused simply 118 because it is receiving authorization responses from more than one 119 authorization server at the same redirection endpoint and the client 120 is insufficiently able to determine that the response received is 121 associated with the correct authorization server. 123 This specification enables the authorization server to dynamically 124 provide the client using it with additional information about the 125 current protocol interaction that can be validated by the client and 126 that enables the client to dynamically provide the authorization 127 server with additional information about the current protocol 128 interaction that can be validated by the authorization server. This 129 enables them to abort interactions in which endpoints from multiple 130 authorization servers would otherwise be used. 132 The mitigation data provided by the authorization server to the 133 client is an issuer identifier, which is used to identify the 134 authorization server, and a client ID, which is used to verify that 135 the response is from the correct authorization server and is intended 136 for this client. The issuer identifier is defined in Section 2 of 137 [OAuth.Discovery]. If supported by the authorization server, the 138 issuer identifier can also be used to obtain a consistent set of 139 metadata describing the authorization server configuration, as also 140 described in [OAuth.Discovery]. 142 This mitigation data is returned to the client in the authorization 143 response. The syntax for returning the mitigation data from the 144 authorization server is dependent upon the OAuth response type being 145 used. The syntax used with the existing response types registered in 146 the IANA "OAuth Authorization Endpoint Response Types" registry 147 [IANA.OAuth.Parameters] as of the time of this writing is defined by 148 this specification. Two of these response types are defined by RFC 149 6749 [RFC6749]; the rest are defined by [OAuth.Responses]. 151 The mitigation data provided by the client to the authorization 152 server is the existing "state" value defined by RFC 6749 [RFC6749], 153 but adding also sending it from the client to the token endpoint. 154 This is used by the authorization server to verify that the 155 authorization code and state both belong to the same protocol 156 interaction. 158 1.1. Requirements Notation and Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in RFC 163 2119 [RFC2119]. 165 1.2. Terminology 167 This specification uses the terms "Access Token", "Authorization 168 Code", "Authorization Endpoint", "Authorization Grant", 169 "Authorization Server", "Client", "Client Authentication", "Client 170 Identifier", "Client Secret", "Grant Type", "Protected Resource", 171 "Redirection URI", "Refresh Token", "Resource Owner", "Resource 172 Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 173 [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token 174 (JWT)" defined by JSON Web Token (JWT) [JWT]. 176 2. The OAuth Issuer Identifier 178 The OAuth issuer identifier serves as a concrete identifier for the 179 authorization server. As defined in [OAuth.Discovery], the issuer 180 identifier is a URL that uses the "https" scheme and has no query or 181 fragment components. Also as specified there, this is the location 182 where ".well-known" RFC 5785 [RFC5785] resources containing 183 information about the authorization server are published. In 184 particular, when discovery is supported, the authorization server's 185 metadata is retrieved as a JSON document [RFC7159] from a path 186 derived from this URL. This metadata document contains a consistent 187 set of metadata describing the authorization server configuration. 189 Implementations supporting this specification MAY also support 190 discovery or they MAY simply use the issuer identifier as a concrete 191 identifier for the authorization server. This specification does not 192 rely upon the authorization server publishing or the client 193 retrieving a discovery metadata document. 195 3. Mitigation Data Returned in Authorization Response 197 Mitigating the attacks relies on the authorization server returning 198 additional data about the interaction and the client checking that 199 data. The mitigation data returned is the client ID and the issuer 200 identifier. The syntax for returning the mitigation data from the 201 authorization server is dependent upon the OAuth response type being 202 used. 204 3.1. Mitigation Data Returned in Authorization Response Parameters 206 Some OAuth response types do not already return the issuer identifier 207 and client ID in the authorization response. When this is the case, 208 the mitigation data is returned as additional OAuth response 209 parameters. 211 These new response parameters are defined for this purpose: 213 client_id 214 Client that this response is intended for. It MUST contain the 215 OAuth 2.0 client ID of the client as its value. 217 iss 218 Issuer identifier for the authorization server issuing the 219 response. The "iss" value is a case-sensitive URL using the 220 "https" scheme that contains scheme, host, and optionally, port 221 number and path components and no query or fragment components. 223 As of the time of this writing, these are the existing response types 224 that are registered in the IANA "OAuth Authorization Endpoint 225 Response Types" registry [IANA.OAuth.Parameters] that do not already 226 return the issuer identifier and client ID in the authorization 227 response: "code", "code token", "none", and "token". Therefore, the 228 client ID and issuer are returned using the new authorization 229 response parameters when using these response types. To avoid 230 duplication, as discussed in Section 7.2, it is NOT RECOMMENDED to 231 also return them in this manner when the response type already 232 returns these values in the authorization response. 234 3.1.1. Example Authorization Response using Response Parameters 236 The following example authorization response is to a request that 237 used the "code" response type. It uses the "iss" and "client_id" 238 response parameters to return the mitigation information to the 239 client. 241 The example successful authorization response follows (with line 242 breaks within lines for display purposes only): 244 HTTP/1.1 302 Found 245 Location: https://client.example.org/cb? 246 code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk 247 &state=nrsz6AnHzPSVVBYRVTXV6ZTXQeg_eih7hdpewHNXmZ8 248 &iss=https://server.example.com 249 &client_id=5d9e8a36-569d-4c40-8d6b-6e279ac1c5f1 251 3.2. Mitigation Data Returned in JWT 253 As of the time of this writing, these are the existing response types 254 that are registered in the IANA "OAuth Authorization Endpoint 255 Response Types" registry [IANA.OAuth.Parameters] that already return 256 the issuer identifier and client ID in the authorization response: 257 "code id_token", "code id_token token", "id_token", and 258 "id_token token". All of these return these values as the "iss" 259 (issuer) claim value and as an "aud" (audience) claim value in a 260 signed ID Token, which is a JSON Web Token [JWT], as specified in 261 "OpenID Connect Core 1.0" [OpenID.Core]. When using these response 262 types, the client MUST use the client ID and issuer values returned 263 in the ID Token for validating the mitigation data. 265 3.2.1. Example Authorization Response using JWT 267 The following example authorization response is to a request that 268 used the "id_token token" response type. It uses the "iss" and "aud" 269 claims in the ID Token to return the mitigation information to the 270 client. 272 The example successful authorization response follows (with line 273 breaks within lines for display purposes only): 275 HTTP/1.1 302 Found 276 Location: https://client.example.org/cb# 277 access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y 278 &token_type=Bearer 279 &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ. 280 ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog 281 IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog 282 Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx 283 MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIKfQ. 284 kdqTmftlaXg5WBYBr1wkxhkqCGZPc0k8vTiV5g2jj67jQ7XkrDamYx2bOkZLdZrp 285 MPIzkdYB1nZI_G8vQGQuamRhJcEIt21kblGPZ-yhEhdkAiZIZLu38rChalDS2Mh0 286 glE_rke5XXRhmqqoEFFdziFdnO3p61-7y51co84OEAZvARSINQaOWIzvioRfs4zw 287 IFOaT33Vpxfqr8HDyh31zo9eBW2dSQuCa071z0ENWChWoPliK1JCo_Bk9eDg2uwo 288 2ZwhsvHzj6TMQ0lYOTzufSlSmXIKfjlOsb3nftQeR697_hA-nMZyAdL8_NRfaC37 289 XnAbW8WB9wCfECp7cuNuOg 290 &state=af0ifjsldkj 292 Decoding the ID Token in the response will yield the following 293 claims, which includes the mitigation information in the "iss" and 294 "aud" claims: 296 { 297 "iss": "https://server.example.com", 298 "sub": "248289761001", 299 "aud": "s6BhdRkqt3", 300 "nonce": "n-0S6_WzA2Mj", 301 "exp": 1311281970, 302 "iat": 1311280970, 303 "at_hash": "77QmUPtjPfzWtF2AnpK9RQ" 304 } 306 4. Validating the Authorization Response 308 Upon receiving the mitigation data in an authorization response, the 309 client MUST validate that the response was intended for it and that 310 the authorization server metadata that it obtained at client 311 registration time is consistent with the authorization server 312 metadata contained in the metadata referenced by the issuer 313 identifier. 315 The client MUST validate the authorization server configuration as 316 follows: 318 1. Compare the issuer identifier for the authorization server that 319 the client received when it registered at the authorization 320 server that it made the request to with the issuer value returned 321 in the "iss" response parameter or the "iss" claim in the ID 322 Token, depending upon the response type being used. If they do 323 not exactly match, the client MUST NOT proceed with the 324 authorization. 326 2. Verify that the response is intended for this client by 327 confirming that the client's client identifier for the 328 authorization server the request was made to matches the value of 329 the "client_id" response parameter or that the client's client 330 identifier is an audience value of the ID Token, depending upon 331 the response type being used. If not, the client MUST NOT 332 proceed with the authorization. 334 5. Mitigation Data Sent to the Token Endpoint 336 Mitigating the attacks also relies on the client sending additional 337 data about the interaction to the token endpoint, for response types 338 that use it, and the authorization server checking that data. The 339 mitigation data sent is the same state value that is sent in the 340 authorization request and returned in the authorization response. 341 This specification defines the new "state" token request parameter 342 for passing this additional information. 344 As of the time of this writing, these are the existing response types 345 that are registered in the IANA "OAuth Authorization Endpoint 346 Response Types" registry [IANA.OAuth.Parameters] that use the token 347 endpoint: "code", "code id_token", "code id_token token", and 348 "code token". The state value is to be sent in the "state" token 349 request parameter when using these response types, and any new 350 response types registered that use the token endpoint. 352 5.1. Example Token Request 354 The following example token request is part of a protocol interaction 355 that used the "code" response type. It uses the "state" request 356 parameter to send mitigation information to the authorization server. 358 The example of token request follows (with line breaks within lines 359 for display purposes only): 361 POST /token HTTP/1.1 362 Host: server.example.com 363 Content-Type: application/x-www-form-urlencoded 364 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 366 grant_type=authorization_code 367 &code=SplxlOBeZQQYbYS6WxSbIA 368 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 369 &state=ZSGXNBavNc-B3kU3DeJnZoWWOzYxsbvj7jp-S0x_z8U 371 6. Validating the Token Request 373 When the authorization server receives a token request at the token 374 endpoint that contains a value in the "state" parameter, it MUST 375 validate that the state value received exactly matches the state 376 value previously received in the corresponding authorization request. 377 If the recorded state value and the state value received do not 378 exactly match, the authorization server MUST NOT proceed with the 379 authorization. 381 7. Security Considerations 383 7.1. IdP Mix-Up and Malicious Endpoint Attacks 385 The attacks mitigated by this extension are described in detail in "A 386 Comprehensive Formal Security Analysis of OAuth 2.0" 387 [arXiv.1601.01229v2] and "On the security of modern Single Sign-On 388 Protocols: Second-Order Vulnerabilities in OpenID Connect" 389 [arXiv.1508.04324v2]. To mitigate these attacks, clients configured 390 to use more than one authorization server should use authorization 391 servers that return issuer and client ID information and should 392 validate that a consistent set of authorization server endpoints are 393 being used when using response types that utilize multiple endpoints. 395 When registering, clients SHOULD NOT allow multiple authorization 396 servers to return the same issuer value, and MUST NOT allow multiple 397 authorization servers to return the same issuer and client ID value 398 pair. 400 7.2. Duplicate Information Attacks 402 If a protocol is defined to return the same information in multiple 403 locations, this can create an additional attack surface. Knowing 404 that the information is supposed to be the same, recipients will 405 often be lazy and use the information from only one of the locations, 406 not validating that all the supposedly duplicate instances are the 407 same. This can enable attackers to create illegal protocol messages 408 that have different values in the multiple locations and those 409 illegal messages will not be detected or rejected by these lazy 410 recipients. 412 For this reason, if an OAuth profile is being used that returns the 413 mitigation information defined by this specification in one location, 414 it SHOULD NOT also be returned in another. In particular, if a JWT 415 containing the client ID and issuer values is being returned in the 416 authorization response, they SHOULD NOT also be returned as 417 individual authorization response parameters. 419 7.3. Cut-and-Paste Attacks 421 OAuth authorization responses are sent as redirects to redirection 422 URIs, with the response parameters typically passed as URI query 423 parameters or fragment values. A "cut-and-paste" attack is performed 424 by the attacker creating what appears to be a legitimate 425 authorization response, but that substitutes some of the response 426 parameter values with values of the attacker's choosing. Sometimes 427 this is done by copying or "cutting" some values out of a legitimate 428 response and replacing or "pasting" some of these values into a 429 different response, the original version of which may have also been 430 legitimate, creating a combination of response values that are not 431 legitimate and that may cause behaviors sought by the attacker. The 432 Code Substitution threat described in Section 4.4.1.13 of [RFC6819] 433 is one example of the use of a cut-and-paste attack. 435 A concern with returning the mitigation information as new individual 436 authorization response parameters whose values are not 437 cryptographically bound together is that cut-and-paste attacks 438 against their values will not be detected. A security analysis has 439 not been done of the effects of the new attacks that the use of cut- 440 and-paste against these new values will enable. 442 To prevent replay of the state in another browser instance by an 443 attacker, the state value MUST be tied to the browser instance in a 444 way that cannot be forged by an attacker. Section 4 of 445 [I-D.bradley-oauth-jwt-encoded-state] provides several examples of 446 how a client can accomplish this. 448 In the replay attack, the attacker can set cookies in the browser. 449 Using an unsigned cookie to bind state to the browser is not 450 sufficient. 452 8. IANA Considerations 454 8.1. OAuth Parameters Registration 456 This specification registers the following parameters in the IANA 457 "OAuth Parameters" registry [IANA.OAuth.Parameters] established by 458 RFC 6749 [RFC6749]. 460 8.1.1. Registry Contents 462 o Parameter name: "client_id" 463 o Parameter usage location: Authorization Response 464 o Change controller: IESG 465 o Specification document(s): Section 3.1 of [[ this specification ]] 466 o Related information: None 468 o Parameter name: "iss" 469 o Parameter usage location: Authorization Response 470 o Change controller: IESG 471 o Specification document(s): Section 3.1 of [[ this specification ]] 472 o Related information: None 474 o Parameter name: "state" 475 o Parameter usage location: Token Request 476 o Change controller: IESG 477 o Specification document(s): Section 5 of [[ this specification ]] 478 o Related information: None 480 9. References 482 9.1. Normative References 484 [IANA.OAuth.Parameters] 485 IANA, "OAuth Parameters", 486 . 488 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 489 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 490 . 492 [OAuth.Discovery] 493 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 494 Discovery", draft-ietf-oauth-discovery-02 (work in 495 progress), March 2016, . 498 [OAuth.Responses] 499 de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. 500 Jones, "OAuth 2.0 Multiple Response Type Encoding 501 Practices", February 2014, . 504 [OpenID.Core] 505 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 506 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 507 . 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, 511 DOI 10.17487/RFC2119, March 1997, 512 . 514 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 515 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 516 2003, . 518 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 519 Uniform Resource Identifiers (URIs)", RFC 5785, 520 DOI 10.17487/RFC5785, April 2010, 521 . 523 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 524 RFC 6749, DOI 10.17487/RFC6749, October 2012, 525 . 527 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 528 Threat Model and Security Considerations", RFC 6819, 529 DOI 10.17487/RFC6819, January 2013, 530 . 532 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 533 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 534 2014, . 536 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 537 RFC 7662, DOI 10.17487/RFC7662, October 2015, 538 . 540 9.2. Informative References 542 [arXiv.1508.04324v2] 543 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 544 of modern Single Sign-On Protocols: Second-Order 545 Vulnerabilities in OpenID Connect", arXiv 1508.04324v2, 546 January 2016, . 548 [arXiv.1601.01229v2] 549 Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive 550 Formal Security Analysis of OAuth 2.0", 551 arXiv 1601.01229v2, January 2016, 552 . 554 [I-D.bradley-oauth-jwt-encoded-state] 555 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 556 claims in the OAuth 2 state parameter using a JWT", draft- 557 bradley-oauth-jwt-encoded-state-05 (work in progress), 558 December 2015. 560 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 561 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 562 RFC 7591, DOI 10.17487/RFC7591, July 2015, 563 . 565 Appendix A. Implementation Notes 567 The authorization server can compare the two state values either by 568 recording the complete state value between the authorization request 569 and the token request, possibly in the same data structure in which 570 the authorization code issued was recorded, or by recording only a 571 cryptographic hash of the state value, possibly resulting in 572 substantial size savings. 574 Appendix B. Acknowledgements 576 Alfred Albrecht, John Bradley, Brian Campbell, Joerg Connotte, 577 William Denniss, Sebastian Ebling, Florian Feldmann, Daniel Fett, 578 Roland Hedberg, Phil Hunt, Ralf Kuesters, Torsten Lodderstedt, 579 Christian Mainka, Vladislav Mladenov, Anthony Nadalin, Justin Richer, 580 Nat Sakimura, Antonio Sanso, Guido Schmitz, Joerg Schwenk, Hannes 581 Tschofenig, and Hans Zandbelt all contributed to the discussions that 582 led to the creation of this specification. 584 This specification is partially based on the OpenID Connect Core 1.0 585 specification, which was produced by the OpenID Connect working group 586 of the OpenID Foundation. 588 Appendix C. Open Issues 590 o We need to do a security analysis of the cut-and-paste attacks 591 that may be enabled when mitigation information is returned to the 592 client using individual authorization response parameters. 594 Appendix D. Document History 596 [[ to be removed by the RFC Editor before publication as an RFC ]] 598 -01 600 o Changed terms "issuer URL" and "configuration information 601 location" to "issuer identifier" so that consistent terminology is 602 used for this. 604 -00 606 o Created the initial working group draft from draft-jones-oauth- 607 mix-up-mitigation-01 with no normative changes and adding Nat 608 Sakimura as an editor. 610 Authors' Addresses 612 Michael B. Jones 613 Microsoft 615 Email: mbj@microsoft.com 616 URI: http://self-issued.info/ 618 John Bradley 619 Ping Identity 621 Email: ve7jtb@ve7jtb.com 622 URI: http://www.thread-safe.com/ 624 Nat Sakimura 625 Nomura Research Institute, Ltd. 627 Email: n-sakimura@nri.co.jp 628 URI: http://nat.sakimura.org/