idnits 2.17.1 draft-ietf-oauth-pop-key-distribution-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 24, 2017) is 2611 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: '15' is defined on line 739, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (ref. '4') (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bradley 3 Internet-Draft Ping Identity 4 Intended status: Standards Track P. Hunt 5 Expires: August 28, 2017 Oracle Corporation 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 ARM Limited 10 February 24, 2017 12 OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key 13 Distribution 14 draft-ietf-oauth-pop-key-distribution-03 16 Abstract 18 RFC 6750 specified the bearer token concept for securing access to 19 protected resources. Bearer tokens need to be protected in transit 20 as well as at rest. When a client requests access to a protected 21 resource it hands-over the bearer token to the resource server. 23 The OAuth 2.0 Proof-of-Possession security concept extends bearer 24 token security and requires the client to demonstrate possession of a 25 key when accessing a protected resource. 27 This document describes how the client obtains this keying material 28 from the authorization server. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 28, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Audience Parameter . . . . . . . . . . . . . . . . . . . 5 68 3.2. Processing Instructions . . . . . . . . . . . . . . . . . 5 69 4. Symmetric Key Transport . . . . . . . . . . . . . . . . . . . 6 70 4.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 6 71 4.2. Client-to-AS Response . . . . . . . . . . . . . . . . . . 7 72 5. Asymmetric Key Transport . . . . . . . . . . . . . . . . . . 9 73 5.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 9 74 5.2. Client-to-AS Response . . . . . . . . . . . . . . . . . . 11 75 6. Token Types and Algorithms . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 17 83 A.1. 'aud' Syntax . . . . . . . . . . . . . . . . . . . . . . 17 84 A.2. 'key' Syntax . . . . . . . . . . . . . . . . . . . . . . 18 85 A.3. 'alg' Syntax . . . . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The work on additional security mechanisms beyond OAuth 2.0 bearer 91 tokens [12] is motivated in [17], which also outlines use cases, 92 requirements and an architecture. This document defines the ability 93 for the client indicate support for this functionality and to obtain 94 keying material from the authorization server. As an outcome of the 95 exchange between the client and the authorization server is an access 96 token that is bound to keying material. Clients that access 97 protected resources then need to demonstrate knowledge of the secret 98 key that is bound to the access token. 100 To best describe the scope of this specification, the OAuth 2.0 101 protocol exchange sequence is shown in Figure 1. The extension 102 defined in this document piggybacks on the message exchange marked 103 with (C) and (D). 105 +--------+ +---------------+ 106 | |--(A)- Authorization Request ->| Resource | 107 | | | Owner | 108 | |<-(B)-- Authorization Grant ---| | 109 | | +---------------+ 110 | | 111 | | +---------------+ 112 | |--(C)-- Authorization Grant -->| Authorization | 113 | Client | | Server | 114 | |<-(D)----- Access Token -------| | 115 | | +---------------+ 116 | | 117 | | +---------------+ 118 | |--(E)----- Access Token ------>| Resource | 119 | | | Server | 120 | |<-(F)--- Protected Resource ---| | 121 +--------+ +---------------+ 123 Figure 1: Abstract OAuth 2.0 Protocol Flow 125 In OAuth 2.0 [2] access tokens can be obtained via authorization 126 grants and using refresh tokens. The core OAuth specification 127 defines four authorization grants, see Section 1.3 of [2], and [14] 128 adds an assertion-based authorization grant to that list. The token 129 endpoint, which is described in Section 3.2 of [2], is used with 130 every authorization grant except for the implicit grant type. In the 131 implicit grant type the access token is issued directly. 133 This document extends the functionality of the token endpoint, i.e., 134 the protocol exchange between the client and the authorization 135 server, to allow keying material to be bound to an access token. Two 136 types of keying material can be bound to an access token, namely 137 symmetric keys and asymmetric keys. Conveying symmetric keys from 138 the authorization server to the client is described in Section 4 and 139 the procedure for dealing with asymmetric keys is described in 140 Section 5. 142 2. Terminology 144 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 145 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 146 specification are to be interpreted as described in [1]. 148 Session Key: 150 The term session key refers to fresh and unique keying material 151 established between the client and the resource server. This 152 session key has a lifetime that corresponds to the lifetime of the 153 access token, is generated by the authorization server and bound 154 to the access token. 156 This document uses the following abbreviations: 158 JWA: JSON Web Algorithms (JWA) [7] 160 JWT: JSON Web Token (JWT) [9] 162 JWS: JSON Web Signature (JWS) [6] 164 JWK: JSON Web Key (JWK) [5] 166 JWE: JSON Web Encryption (JWE) [8] 168 3. Audience 170 When an authorization server creates an access token, according to 171 the PoP security architecture [17], it may need to know which 172 resource server will process it. This information is necessary when 173 the authorization server applies integrity protection to the JWT 174 using a symmetric key and has to selected the key of the resource 175 server that has to verify it. The authorization server also requires 176 this audience information if it has to encrypt a symmetric session 177 key inside the access token using a long-term symmetric key. 179 This section defines a new header that is used by the client to 180 indicate what protected resource at which resource server it wants to 181 access. This information may subsequently also communicated by the 182 authorization server securely to the resource server, for example 183 within the audience field of the access token. 185 QUESTION: A benefit of asymmetric cryptography is to allow clients to 186 request a PoP token for use with multiple resource servers. The 187 downside of that approach is linkability since different resource 188 servers will be able to link individual requests to the same client. 190 (The same is true if the a single public key is linked with PoP 191 tokens used with different resource servers.) Nevertheless, to 192 support the functionality the audience parameter could carry an array 193 of values. Is this desirable? 195 3.1. Audience Parameter 197 The client constructs the access token request to the token endpoint 198 by adding the 'aud' parameter using the "application/x-www-form- 199 urlencoded" format with a character encoding of UTF-8 in the HTTP 200 request entity-body. 202 The URI included in the aud parameter MUST be an absolute URI as 203 defined by Section 4.3 of [3]. It MAY include an "application/x-www- 204 form-urlencoded" formatted query component (Section 3.4 of [3] ). 205 The URI MUST NOT include a fragment component. 207 The ABNF syntax for the 'aud' element is defined in Appendix A. 209 3.2. Processing Instructions 211 Step (0): As an initial step the client typically determines the 212 resource server it wants to interact with. This may, for example, 213 happen as part of a discovery procedure or via manual 214 configuration. 216 Step (1): The client starts the OAuth 2.0 protocol interaction 217 based on the selected grant type. 219 Step (2): When the client interacts with the token endpoint to 220 obtain an access token it MUST populate the newly defined 221 'audience' parameter with the information obtained in step (0). 223 Step (2): The authorization server who obtains the request from 224 the client needs to parse it to determine whether the provided 225 audience value matches any of the resource servers it has a 226 relationship with. If the authorization server fails to parse the 227 provided value it MUST reject the request using an error response 228 with the error code "invalid_request". If the authorization 229 server does not consider the resource server acceptable it MUST 230 return an error response with the error code "access_denied". In 231 both cases additional error information may be provided via the 232 error_description, and the error_uri parameters. If the request 233 has, however, been verified successfully then the authorization 234 server MUST include the audience claim into the access token with 235 the value copied from the audience field provided by the client. 236 In case the access token is encoded using the JSON Web Token 237 format [9] the "aud" claim MUST be used. The access token, if 238 passed per value, MUST be protected against modification by either 239 using a digital signature or a keyed message digest. Access 240 tokens can also be passed by reference, which then requires the 241 token introspection endpoint (or a similiar, proprietary protocol 242 mechanism) to be used. The authorization server returns the 243 access token to the client, as specified in [2]. 245 Subsequent steps for the interaction between the client and the 246 resource server are beyond the scope of this document. 248 4. Symmetric Key Transport 250 4.1. Client-to-AS Request 252 In case a symmetric key shall be bound to an PoP token the following 253 procedure is applicable. In the request message from the OAuth 254 client to the OAuth authorization server the following parameters MAY 255 be included: 257 token_type: OPTIONAL. See Section 6 for more details. 259 alg: OPTIONAL. See Section 6 for more details. 261 These two new parameters are optional in the case where the 262 authorization server has prior knowledge of the capabilities of the 263 client otherwise these two parameters are required. This prior 264 knowledge may, for example, be set by the use of a dynamic client 265 registration protocol exchange. 267 QUESTION: Should we register these two parameters for use with the 268 dynamic client registration protocol? 270 For example, the client makes the following HTTP request using TLS 271 (extra line breaks are for display purposes only). 273 POST /token HTTP/1.1 274 Host: server.example.com 275 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 276 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 278 grant_type=authorization_code 279 &code=SplxlOBeZQQYbYS6WxSbIA 280 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 281 &token_type=pop 282 &alg=HS256 284 Example Request to the Authorization Server 286 4.2. Client-to-AS Response 288 If the access token request has been successfully verified by the 289 authorization server and the client is authorized to obtain a PoP 290 token for the indicated resource server, the authorization server 291 issues an access token and optionally a refresh token. If client 292 authentication failed or is invalid, the authorization server returns 293 an error response as described in Section 5.2 of [2]. 295 The authorization server MUST include an access token and a 'key' 296 element in a successful response. The 'key' parameter either 297 contains a plain JWK structure or a JWK encrypted with a JWE. The 298 difference between the two approaches is the following: 300 Plain JWK: If the JWK container is placed in the 'key' element then 301 the security of the overall PoP architecture relies on Transport 302 Layer Security (TLS) between the authorization server and the 303 client. Figure 2 illustrates an example response using a plain 304 JWK for key transport from the authorization server to the client. 306 JWK protected by a JWE: If the JWK container is protected by a JWE 307 then additional security protection at the application layer is 308 provided between the authorization server and the client beyond 309 the use of TLS. This approach is a reasonable choice, for 310 example, when a hardware security module is available on the 311 client device and confidentiality protection can be offered 312 directly to this hardware security module. 314 Note that there are potentially two JSON-encoded structures in the 315 response, namely the access token (with the recommended JWT encoding) 316 and the actual key transport mechanism itself. Note, however, that 317 the two structures serve a different purpose and are consumed by 318 different parites. The access token is created by the authorization 319 server and processed by the resource server (and opaque to the 320 client) whereas the key transport payload is created by the 321 authorization server and processed by the client; it is never 322 forwarded to the resource server. 324 HTTP/1.1 200 OK 325 Content-Type: application/json 326 Cache-Control: no-store 328 { 329 "access_token":"SlAV32hkKG ... 330 (remainder of JWT omitted for brevity; 331 JWT contains JWK in the cnf claim)", 332 "token_type":"pop", 333 "expires_in":3600, 334 "refresh_token":"8xLOxBtZp8", 335 "key":"eyJhbGciOiJSU0ExXzUi ... 336 (remainder of plain JWK omitted for brevity)" 337 } 339 Figure 2: Example: Response from the Authorization Server (Symmetric 340 Variant) 342 The content of the key parameter, which is a JWK in our example, is 343 shown in Figure 3. 345 { 346 "kty":"oct", 347 "kid":"id123", 348 "alg":"HS256", 349 "k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE" 350 } 352 Figure 3: Example: Key Transport to Client via a JWK 354 The content of the 'access_token' in JWT format contains the 'cnf' 355 (confirmation) claim, as shown in Figure 4. The confirmation claim 356 is defined in [10]. The digital signature or the keyed message 357 digest offering integrity protection is not shown in this example but 358 MUST be present in a real deployment to mitigate a number of security 359 threats. Those security threats are described in [17]. 361 The JWK in the key element of the response from the authorization 362 server, as shown in Figure 2, contains the same session key as the 363 JWK inside the access token, as shown in Figure 4. It is, in this 364 example, protected by TLS and transmitted from the authorization 365 server to the client (for processing by the client). 367 { 368 "iss": "https://server.example.com", 369 "sub": "24400320", 370 "aud": "s6BhdRkqt3", 371 "nonce": "n-0S6_WzA2Mj", 372 "exp": 1311281970, 373 "iat": 1311280970, 374 "cnf":{ 375 "jwk": 376 "JDLUhTMjU2IiwiY3R5Ijoi ... 377 (remainder of JWK protected by JWE omitted for brevity)" 378 } 379 } 381 Figure 4: Example: Access Token in JWT Format 383 Note: When the JWK inside the access token contains a symmetric key 384 it MUST be confidentiality protected using a JWE to maintain the 385 security goals of the PoP architecture, as described in [17] since 386 content is meant for consumption by the selected resource server 387 only. 389 Note: This document does not impose requirements on the encoding of 390 the access token. The examples used in this document make use of the 391 JWT structure since this is the only standardized format. 393 If the access token is only a reference then a look-up by the 394 resource server is needed, as described in the token introspection 395 specification [18]. 397 5. Asymmetric Key Transport 399 5.1. Client-to-AS Request 401 In case an asymmetric key shall be bound to an access token then the 402 following procedure is applicable. In the request message from the 403 OAuth client to the OAuth authorization server the request MAY 404 include the following parameters: 406 token_type: OPTIONAL. See Section 6 for more details. 408 alg: OPTIONAL. See Section 6 for more details. 410 key: OPTIONAL. This field contains information about the public key 411 the client would like to bind to the access token in the JWK 412 format. If the client does not provide a public key then the 413 authorization server MUST create an ephemeral key pair 414 (considering the information provided by the client) or 415 alternatively respond with an error message. The client may 416 also convey the fingerprint of the public key to the 417 authorization server instead of passing the entire public key 418 along (to conserve bandwidth). [11] defines a way to compute a 419 thumbprint for a JWK and to embedd it within the JWK format. 421 The 'token_type' and the 'alg' parameters are optional in the case 422 where the authorization server has prior knowledge of the 423 capabilities of the client otherwise these two parameters are 424 required. 426 For example, the client makes the following HTTP request using TLS 427 (extra line breaks are for display purposes only) shown in Figure 5. 429 POST /token HTTP/1.1 430 Host: server.example.com 431 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 432 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 434 grant_type=authorization_code 435 &code=SplxlOBeZQQYbYS6WxSbIA 436 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 437 &token_type=pop 438 &alg=RS256 439 &key=eyJhbGciOiJSU0ExXzUi ... 440 (remainder of JWK omitted for brevity) 442 Figure 5: Example Request to the Authorization Server (Asymmetric Key 443 Variant) 445 As shown in Figure 6 the content of the 'key' parameter contains the 446 RSA public key the client would like to associate with the access 447 token. 449 {"kty":"RSA", 450 "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 451 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 452 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 453 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 454 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 455 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 456 "e":"AQAB", 457 "alg":"RS256", 458 "kid":"id123"} 460 Figure 6: Client Providing Public Key to Authorization Server 462 5.2. Client-to-AS Response 464 If the access token request is valid and authorized, the 465 authorization server issues an access token and optionally a refresh 466 token. If the request client authentication failed or is invalid, 467 the authorization server returns an error response as described in 468 Section 5.2 of [2]. 470 The authorization server also places information about the public key 471 used by the client into the access token to create the binding 472 between the two. The new token type "public_key" is placed into the 473 'token_type' parameter. 475 An example of a successful response is shown in Figure 7. 477 HTTP/1.1 200 OK 478 Content-Type: application/json;charset=UTF-8 479 Cache-Control: no-store 480 Pragma: no-cache 482 { 483 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 484 "token_type":"pop", 485 "alg":"RS256", 486 "expires_in":3600, 487 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 488 } 490 Figure 7: Example: Response from the Authorization Server (Asymmetric 491 Variant) 493 The content of the 'access_token' field contains an encoded JWT with 494 the following structure, as shown in Figure 8. The digital signature 495 or the keyed message digest offering integrity protection is not 496 shown (but must be present). 498 { 499 "iss":"xas.example.com", 500 "aud":"http://auth.example.com", 501 "exp":"1361398824", 502 "nbf":"1360189224", 503 "cnf":{ 504 "jwk":{"kty":"RSA", 505 "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 506 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 507 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 508 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 509 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 510 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 511 "e":"AQAB", 512 "alg":"RS256", 513 "kid":"id123"} 514 } 515 } 517 Figure 8: Example: Access Token Structure (Asymmetric Variant) 519 Note: In this example there is no need for the authorization server 520 to convey further keying material to the client since the client is 521 already in possession of the private RSA key. 523 6. Token Types and Algorithms 525 To allow clients to indicate support for specific token types and 526 respective algorithms they need to interact with authorization 527 servers. They can either provide this information out-of-band, for 528 example, via pre-configuration or up-front via the dynamic client 529 registration protocol [16]. 531 The value in the 'alg' parameter together with value from the 532 'token_type' parameter allow the client to indicate the supported 533 algorithms for a given token type. The token type refers to the 534 specification used by the client to interact with the resource server 535 to demonstrate possession of the key. The 'alg' parameter provides 536 further information about the algorithm, such as whether a symmetric 537 or an asymmetric crypto-system is used. Hence, a client supporting a 538 specific token type also knows how to populate the values to the 539 'alg' parameter. 541 The value for the 'token_type' MUST be taken from the 'OAuth Access 542 Token Types' registry created by [2]. 544 This document does not register a new value for the OAuth Access 545 Token Types registry nor does it define values to be used for the 546 'alg' parameter since this is the responsibility of specifications 547 defining the mechanism for clients interacting with resource servers. 548 An example of such specification can be found in [19]. 550 The values in the 'alg' parameter are case-sensitive. If the client 551 supports more than one algorithm then each individual value MUST be 552 separated by a space. 554 7. Security Considerations 556 [17] describes the architecture for the OAuth 2.0 proof-of-possession 557 security architecture, including use cases, threats, and 558 requirements. This requirements describes one solution component of 559 that architecture, namely the mechanism for the client to interact 560 with the authorization server to either obtain a symmetric key from 561 the authorization server, to obtain an asymmetric key pair, or to 562 offer a public key to the authorization. In any case, these keys are 563 then bound to the access token by the authorization server. 565 To summarize the main security recommendations: A large range of 566 threats can be mitigated by protecting the contents of the access 567 token by using a digital signature or a keyed message digest. 568 Consequently, the token integrity protection MUST be applied to 569 prevent the token from being modified, particularly since it contains 570 a reference to the symmetric key or the asymmetric key. If the 571 access token contains the symmetric key (see Section 2.2 of [10] for 572 a description about how symmetric keys can be securely conveyed 573 within the access token) this symmetric key MUST be encrypted by the 574 authorization server with a long-term key shared with the resource 575 server. 577 To deal with token redirect, it is important for the authorization 578 server to include the identity of the intended recipient (the 579 audience), typically a single resource server (or a list of resource 580 servers), in the token. Using a single shared secret with multiple 581 authorization server to simplify key management is NOT RECOMMENDED 582 since the benefit from using the proof-of-possession concept is 583 significantly reduced. 585 Token replay is also not possible since an eavesdropper will also 586 have to obtain the corresponding private key or shared secret that is 587 bound to the access token. Nevertheless, it is good practice to 588 limit the lifetime of the access token and therefore the lifetime of 589 associated key. 591 The authorization server MUST offer confidentiality protection for 592 any interactions with the client. This step is extremely important 593 since the client will obtain the session key from the authorization 594 server for use with a specific access token. Not using 595 confidentiality protection exposes this secret (and the access token) 596 to an eavesdropper thereby making the OAuth 2.0 proof-of-possession 597 security model completely insecure. OAuth 2.0 [2] relies on TLS to 598 offer confidentiality protection and additional protection can be 599 applied using the JWK [5] offered security mechanism, which would add 600 an additional layer of protection on top of TLS for cases where the 601 keying material is conveyed, for example, to a hardware security 602 module. Which version(s) of TLS ought to be implemented will vary 603 over time, and depend on the widespread deployment and known security 604 vulnerabilities at the time of implementation. At the time of this 605 writing, TLS version 1.2 [4] is the most recent version. The client 606 MUST validate the TLS certificate chain when making requests to 607 protected resources, including checking the validity of the 608 certificate. 610 Similarly to the security recommendations for the bearer token 611 specification [12] developers MUST ensure that the ephemeral 612 credentials (i.e., the private key or the session key) is not leaked 613 to third parties. An adversary in possession of the ephemeral 614 credentials bound to the access token will be able to impersonate the 615 client. Be aware that this is a real risk with many smart phone app 616 and Web development environments. 618 Clients can at any time request a new proof-of-possession capable 619 access token. Using a refresh token to regularly request new access 620 tokens that are bound to fresh and unique keys is important. Keeping 621 the lifetime of the access token short allows the authorization 622 server to use shorter key sizes, which translate to a performance 623 benefit for the client and for the resource server. Shorter keys 624 also lead to shorter messages (particularly with asymmetric keying 625 material). 627 When authorization servers bind symmetric keys to access tokens then 628 they SHOULD scope these access tokens to a specific permissions. 630 8. IANA Considerations 632 This specification registers the following parameters in the OAuth 633 Parameters Registry established by [2]. 635 Parameter name: alg 636 Parameter usage location: token request, token response, 637 authorization response 639 Change controller: IETF 641 Specification document(s): [[ this document ]] 643 Related information: None 645 Parameter name: key 647 Parameter usage location: token request, token response, 648 authorization response 650 Change controller: IETF 652 Specification document(s): [[ this document ]] 654 Related information: None 656 Parameter name: aud 658 Parameter usage location: token request 660 Change controller: IETF 662 Specification document(s): [[This document.] 664 Related information: None 666 9. Acknowledgements 668 We would like to thank Chuck Mortimore for his review comments. 670 10. References 672 10.1. Normative References 674 [1] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, 676 DOI 10.17487/RFC2119, March 1997, 677 . 679 [2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 680 RFC 6749, DOI 10.17487/RFC6749, October 2012, 681 . 683 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 684 Resource Identifier (URI): Generic Syntax", STD 66, 685 RFC 3986, DOI 10.17487/RFC3986, January 2005, 686 . 688 [4] Dierks, T. and E. Rescorla, "The Transport Layer Security 689 (TLS) Protocol Version 1.2", RFC 5246, 690 DOI 10.17487/RFC5246, August 2008, 691 . 693 [5] Jones, M., "JSON Web Key (JWK)", RFC 7517, 694 DOI 10.17487/RFC7517, May 2015, 695 . 697 [6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 698 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 699 2015, . 701 [7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 702 DOI 10.17487/RFC7518, May 2015, 703 . 705 [8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 706 RFC 7516, DOI 10.17487/RFC7516, May 2015, 707 . 709 [9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 710 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 711 . 713 [10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 714 Possession Key Semantics for JSON Web Tokens (JWTs)", 715 RFC 7800, DOI 10.17487/RFC7800, April 2016, 716 . 718 [11] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 719 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 720 2015, . 722 10.2. Informative References 724 [12] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 725 Framework: Bearer Token Usage", RFC 6750, 726 DOI 10.17487/RFC6750, October 2012, 727 . 729 [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 730 Specifications: ABNF", STD 68, RFC 5234, 731 DOI 10.17487/RFC5234, January 2008, 732 . 734 [14] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 735 "Assertion Framework for OAuth 2.0 Client Authentication 736 and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, 737 May 2015, . 739 [15] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 740 for Code Exchange by OAuth Public Clients", RFC 7636, 741 DOI 10.17487/RFC7636, September 2015, 742 . 744 [16] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 745 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 746 RFC 7591, DOI 10.17487/RFC7591, July 2015, 747 . 749 [17] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 750 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 751 Architecture", draft-ietf-oauth-pop-architecture-08 (work 752 in progress), July 2016. 754 [18] Richer, J., Ed., "OAuth 2.0 Token Introspection", 755 RFC 7662, DOI 10.17487/RFC7662, October 2015, 756 . 758 [19] Richer, J., Bradley, J., and H. Tschofenig, "A Method for 759 Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- 760 http-request-03 (work in progress), August 2016. 762 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax 764 This section provides Augmented Backus-Naur Form (ABNF) syntax 765 descriptions for the elements defined in this specification using the 766 notation of [13]. 768 A.1. 'aud' Syntax 770 The ABNF syntax is defined as follows where by the "URI-reference" 771 definition is taken from [3]: 773 aud = URI-reference 775 A.2. 'key' Syntax 777 The "key" element is defined in Section 4 and Section 5: 779 key = 1*VSCHAR 781 A.3. 'alg' Syntax 783 The "alg" element is defined in Section 6: 785 alg = alg-token *( SP alg-token ) 787 alg-token = 1*NQCHAR 789 Authors' Addresses 791 John Bradley 792 Ping Identity 794 Email: ve7jtb@ve7jtb.com 795 URI: http://www.thread-safe.com/ 797 Phil Hunt 798 Oracle Corporation 800 Email: phil.hunt@yahoo.com 801 URI: http://www.indepdentid.com 803 Michael B. Jones 804 Microsoft 806 Email: mbj@microsoft.com 807 URI: http://self-issued.info/ 809 Hannes Tschofenig 810 ARM Limited 811 Austria 813 Email: Hannes.Tschofenig@gmx.net 814 URI: http://www.tschofenig.priv.at