idnits 2.17.1 draft-ietf-oauth-pop-architecture-04.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 (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-01 == Outdated reference: A later version (-11) exists of draft-ietf-oauth-proof-of-possession-04 == Outdated reference: A later version (-03) exists of draft-ietf-oauth-signed-http-request-01 -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth P. Hunt, Ed. 3 Internet-Draft Oracle Corporation 4 Intended status: Informational J. Richer 5 Expires: April 21, 2016 6 W. Mills 8 P. Mishra 9 Oracle Corporation 10 H. Tschofenig 11 ARM Limited 12 October 19, 2015 14 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture 15 draft-ietf-oauth-pop-architecture-04.txt 17 Abstract 19 The OAuth 2.0 bearer token specification, as defined in RFC 6750, 20 allows any party in possession of a bearer token (a "bearer") to get 21 access to the associated resources (without demonstrating possession 22 of a cryptographic key). To prevent misuse, bearer tokens must to be 23 protected from disclosure in transit and at rest. 25 Some scenarios demand additional security protection whereby a client 26 needs to demonstrate possession of cryptographic keying material when 27 accessing a protected resource. This document motivates the 28 development of the OAuth 2.0 proof-of-possession security mechanism. 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 April 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Preventing Access Token Re-Use by the Resource Server . . 3 68 3.2. TLS Channel Binding Support . . . . . . . . . . . . . . . 4 69 3.3. Access to a Non-TLS Protected Resource . . . . . . . . . 4 70 3.4. Offering Application Layer End-to-End Security . . . . . 5 71 4. Security and Privacy Threats . . . . . . . . . . . . . . . . 5 72 5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Confidentiality Protection . . . . . . . . . . . . . . . 7 74 5.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 7 75 5.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . 8 76 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 11.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 At the time of writing the OAuth 2.0 protocol family ([RFC6749], 90 [RFC6750], and [RFC6819]) offer a single standardized security 91 mechanism to access protected resources, namely the bearer token. 92 RFC 6750 [RFC6750] specifies the bearer token mechanism and defines 93 it as follows: 95 "A security token with the property that any party in possession 96 of the token (a "bearer") can use the token in any way that any 97 other party in possession of it can. Using a bearer token does 98 not require a bearer to prove possession of cryptographic key 99 material." 101 The bearer token meets the security needs of a number of use cases 102 the OAuth 2.0 protocol had originally been designed for. There are, 103 however, other scenarios that require stronger security properties 104 and ask for active participation of the OAuth client in form of 105 cryptographic computations when presenting an access token to a 106 resource server. 108 This document outlines additional use cases requiring stronger 109 security protection in Section 3, identifies threats in Section 4, 110 proposes different ways to mitigate those threats in Section 5, 111 outlines an architecture for a solution that builds on top of the 112 existing OAuth 2.0 framework in Section 6, and concludes with a 113 requirements list in Section 7. 115 2. Terminology 117 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 118 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 119 specification are to be interpreted as described in [RFC2119], with 120 the important qualification that, unless otherwise stated, these 121 terms apply to the design of the protocol, not its implementation or 122 application. 124 3. Use Cases 126 The main use case that motivates better-than-bearer token security is 127 the desire of resource servers to obtain additional assurance that 128 the client is indeed authorized to present an access token. The 129 expectation is that the use of additional credentials (symmetric or 130 asymmetric keying material) will encourage developers to take 131 additional precautions when transferring and storing access token in 132 combination with these credentials. 134 Additional use cases listed below provide further requirements for 135 the solution development. Note that a single solution does not 136 necessarily need to offer support for all use cases. 138 3.1. Preventing Access Token Re-Use by the Resource Server 140 Imagine a scenario where a resource server that receives a valid 141 access token re-uses it with other resource server. The reason for 142 re-use may be malicious or may well be legitimate. In a legitimate 143 use case consider chaining of computations whereby a resource server 144 needs to consult other third party resource servers to complete the 145 requested operation. In both cases it may be assumed that the scope 146 of the access token is sufficiently large that it allows such a re- 147 use. For example, imagine a case where a company operates email 148 services as well as picture sharing services and that company had 149 decided to issue access tokens with a scope that allows access to 150 both services. 152 With this use case the desire is to prevent such access token re-use. 153 This also implies that the legitimate use cases require additional 154 enhancements for request chaining. 156 3.2. TLS Channel Binding Support 158 In this use case we consider the scenario where an OAuth 2.0 request 159 to a protected resource is secured using TLS but the client and the 160 resource server demand that the underlying TLS exchange is bound to 161 additional application layer security to prevent cases where the TLS 162 connection is terminated at a TLS intermediary, which splits the TLS 163 connection into two separate connections. 165 In this use case additional information is conveyed to the resource 166 server to ensure that no entity entity has tampered with the TLS 167 connection. 169 3.3. Access to a Non-TLS Protected Resource 171 This use case is for a web client that needs to access a resource 172 that makes data available (such as videos) without offering integrity 173 and confidentiality protection using TLS. Still, the initial 174 resource request using OAuth, which includes the access token, must 175 be protected against various threats (e.g., token replay, token 176 modification). 178 While it is possible to utilize bearer tokens in this scenario with 179 TLS protection when the request to the protected resource is made, as 180 described in [RFC6750], there may be the desire to avoid using TLS 181 between the client and the resource server at all. In such a case 182 the bearer token approach is not possible since it relies on TLS for 183 ensuring integrity and confidentiality protection of the access token 184 exchange since otherwise replay attacks are possible: First, an 185 eavesdropper may steal an access token and represent it at a 186 different resource server. Second, an eavesdropper may steal an 187 access token and replay it against the same resource server at a 188 later point in time. In both cases, if the attack is successful, the 189 adversary gets access to the resource owners data or may perform an 190 operation selected by the adversary (e.g., sending a message). Note 191 that the adversary may obtain the access token (if the 192 recommendations in [RFC6749] and [RFC6750] are not followed) using a 193 number of ways, including eavesdropping the communication on the 194 wireless link. 196 Consequently, the important assumption in this use case is that a 197 resource server does not have TLS support and the security solution 198 should work in such a scenario. Furthermore, it may not be necessary 199 to provide authentication of the resource server towards the client. 201 3.4. Offering Application Layer End-to-End Security 203 In Web deployments resource servers are often placed behind load 204 balancers, which are deployed by the same organization that operates 205 the resource servers. These load balancers may terminate the TLS 206 connection setup and HTTP traffic is transmitted in the clear from 207 the load balancer to the resource server. With application layer 208 security in addition to the underlying TLS security it is possible to 209 allow application servers to perform cryptographic verification on an 210 end-to-end basis. 212 The key aspect in this use case is therefore to offer end-to-end 213 security in the presence of load balancers via application layer 214 security. Enterprise networks also deploy proxies that inspect 215 traffic and thereby break TLS. 217 4. Security and Privacy Threats 219 The following list presents several common threats against protocols 220 utilizing some form of tokens. This list of threats is based on NIST 221 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 222 threats related to any form of identity proofing and authentication 223 of the resource owner to the authorization server since these 224 procedures are not part of the OAuth 2.0 protocol specification 225 itself. 227 Token manufacture/modification: 229 An attacker may generate a bogus tokens or modify the token 230 content (such as authentication or attribute statements) of an 231 existing token, causing resource server to grant inappropriate 232 access to the client. For example, an attacker may modify the 233 token to extend the validity period. A client may modify the 234 token to have access to information that they should not be able 235 to view. 237 Token disclosure: 239 Tokens may contain personal data, such as real name, age or 240 birthday, payment information, etc. 242 Token redirect: 244 An attacker uses the token generated for consumption by the 245 resource server to obtain access to another resource server. 247 Token reuse: 249 An attacker attempts to use a token that has already been used 250 once with a resource server. The attacker may be an eavesdropper 251 who observes the communication exchange or, worse, one of the 252 communication end points. A client may, for example, leak access 253 tokens because it cannot keep secrets confidential. A client may 254 also re-use access tokens for some other resource servers. 255 Finally, a resource server may use a token it had obtained from a 256 client and use it with another resource server that the client 257 interacts with. A resource server, offering relatively 258 unimportant application services, may attempt to use an access 259 token obtained from a client to access a high-value service, such 260 as a payment service, on behalf of the client using the same 261 access token. 263 Token repudiation: 265 Token repudiation refers to a property whereby a resource server 266 is given an assurance that the authorization server cannot deny to 267 have created a token for the client. 269 5. Threat Mitigation 271 A large range of threats can be mitigated by protecting the content 272 of the token, for example using a digital signature or a keyed 273 message digest. Alternatively, the content of the token could be 274 passed by reference rather than by value (requiring a separate 275 message exchange to resolve the reference to the token content). To 276 simplify the subsequent description we assume that the token itself 277 is digitally signed by the authorization server and therefore cannot 278 be modified. 280 To deal with token redirect it is important for the authorization 281 server to include the identifier of the intended recipient - the 282 resource server. A resource server must not be allowed to accept 283 access tokens that are not meant for its consumption. 285 To provide protection against token disclosure two approaches are 286 possible, namely (a) not to include sensitive information inside the 287 token or (b) to ensure confidentiality protection. The latter 288 approach requires at least the communication interaction between the 289 client and the authorization server as well as the interaction 290 between the client and the resource server to experience 291 confidentiality protection. As an example, TLS with a ciphersuite 292 that offers confidentiality protection has to be applied (which is 293 currently true for all ciphersuites, except for one). Encrypting the 294 token content itself is another alternative. In our scenario the 295 authorization server would, for example, encrypt the token content 296 with a symmetric key shared with the resource server. 298 To deal with token reuse more choices are available. 300 5.1. Confidentiality Protection 302 In this approach confidentiality protection of the exchange is 303 provided on the communication interfaces between the client and the 304 resource server, and between the client and the authorization server. 305 No eavesdropper on the wire is able to observe the token exchange. 306 Consequently, a replay by a third party is not possible. An 307 authorization server wants to ensure that it only hands out tokens to 308 clients it has authenticated first and who are authorized. For this 309 purpose, authentication of the client to the authorization server 310 will be a requirement to ensure adequate protection against a range 311 of attacks. This is, however, true for the description in 312 Section 5.2 and Section 5.3 as well. Furthermore, the client has to 313 make sure it does not distribute (or leak) the access token to 314 entities other than the intended the resource server. For that 315 purpose the client will have to authenticate the resource server 316 before transmitting the access token. 318 5.2. Sender Constraint 320 Instead of providing confidentiality protection the authorization 321 server could also put the identifier of the client into the protected 322 token with the following semantic: 'This token is only valid when 323 presented by a client with the following identifier.' When the 324 access token is then presented to the resource server how does it 325 know that it was provided by the client? It has to authenticate the 326 client! There are many choices for authenticating the client to the 327 resource server, for example by using client certificates in TLS 328 [RFC5246], or pre-shared secrets within TLS [RFC4279]. The choice of 329 the preferred authentication mechanism and credential type may depend 330 on a number of factors, including 332 o security properties 334 o available infrastructure 335 o library support 337 o credential cost (financial) 339 o performance 341 o integration into the existing IT infrastructure 343 o operational overhead for configuration and distribution of 344 credentials 346 This long list hints to the challenge of selecting at least one 347 mandatory-to-implement client authentication mechanism. 349 5.3. Key Confirmation 351 A variation of the mechanism of sender authentication, described in 352 Section 5.2, is to replace authentication with the proof-of- 353 possession of a specific (session) key, i.e., key confirmation. In 354 this model the resource server would not authenticate the client 355 itself but would rather verify whether the client knows the session 356 key associated with a specific access token. Examples of this 357 approach can be found with the OAuth 1.0 MAC token [RFC5849], and 358 Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see 359 also [I-D.hardjono-oauth-kerberos] for a comparison between Kerberos 360 and OAuth). 362 To illustrate key confirmation the first examples borrow from 363 Kerberos and use symmetric key cryptography. Assume that the 364 authorization server shares a long-term secret with the resource 365 server, called K(Authorization Server-Resource Server). This secret 366 would be established between them out-of-band. When the client 367 requests an access token the authorization server creates a fresh and 368 unique session key Ks and places it into the token encrypted with the 369 long term key K(Authorization Server-Resource Server). Additionally, 370 the authorization server attaches Ks to the response message to the 371 client (in addition to the access token itself) over a 372 confidentiality protected channel. When the client sends a request 373 to the resource server it has to use Ks to compute a keyed message 374 digest for the request (in whatever form or whatever layer). The 375 resource server, when receiving the message, retrieves the access 376 token, verifies it and extracts K(Authorization Server-Resource 377 Server) to obtain Ks. This key Ks is then used to verify the keyed 378 message digest of the request message. 380 Note that in this example one could imagine that the mechanism to 381 protect the token itself is based on a symmetric key based mechanism 382 to avoid any form of public key infrastructure but this aspect is not 383 further elaborated in the scenario. 385 A similar mechanism can also be designed using asymmetric 386 cryptography. When the client requests an access token the 387 authorization server creates an ephemeral public / privacy key pair 388 (PK/SK) and places the public key PK into the protected token. When 389 the authorization server returns the access token to the client it 390 also provides the PK/SK key pair over a confidentiality protected 391 channel. When the client sends a request to the resource server it 392 has to use the privacy key SK to sign the request. The resource 393 server, when receiving the message, retrieves the access token, 394 verifies it and extracts the public key PK. It uses this ephemeral 395 public key to verify the attached signature. 397 5.4. Summary 399 As a high level message, there are various ways how the threats can 400 be mitigated and while the details of each solution is somewhat 401 different they all ultimately accomplish the goal. 403 The three approaches are: 405 Confidentiality Protection: 407 The weak point with this approach, which is briefly described in 408 Section 5.1, is that the client has to be careful to whom it 409 discloses the access token. What can be done with the token 410 entirely depends on what rights the token entitles the presenter 411 and what constraints it contains. A token could encode the 412 identifier of the client but there are scenarios where the client 413 is not authenticated to the resource server or where the 414 identifier of the client rather represents an application class 415 rather than a single application instance. As such, it is 416 possible that certain deployments choose a rather liberal approach 417 to security and that everyone who is in possession of the access 418 token is granted access to the data. 420 Sender Constraint: 422 The weak point with this approach, which is briefly described in 423 Section 5.2, is to setup the authentication infrastructure such 424 that clients can be authenticated towards resource servers. 425 Additionally, the authorization server must encode the identifier 426 of the client in the token for later verification by the resource 427 server. Depending on the chosen layer for providing client-side 428 authentication there may be additional challenges due Web server 429 load balancing, lack of API access to identity information, etc. 431 Key Confirmation: 433 The weak point with this approach, see Section 5.3, is the 434 increased complexity: a complete key distribution protocol has to 435 be defined. 437 In all cases above it has to be ensured that the client is able to 438 keep the credentials secret. 440 6. Architecture 442 The proof-of-possession security concept assumes that the 443 authorization server acts as a trusted third party that binds keys to 444 access tokens. These keys are then used by the client to demonstrate 445 the possession of the secret to the resource server when accessing 446 the resource. The resource server, when receiving an access token, 447 needs to verify that the key used by the client matches the one 448 included in the access token. 450 There are slight differences between the use of symmetric keys and 451 asymmetric keys when they are bound to the access token and the 452 subsequent interaction between the client and the authorization 453 server when demonstrating possession of these keys. Figure 1 shows 454 the symmetric key procedure and Figure 2 illustrates how asymmetric 455 keys are used. While symmetric cryptography provides better 456 performance properties the use of asymmetric cryptography allows the 457 client to keep the private key locally and never expose it to any 458 other party. 460 With the JSON Web Token (JWT) [RFC7519] a standardized format for 461 access tokens is available. The necessary elements to bind symmetric 462 or asymmetric keys to a JWT are described in 463 [I-D.ietf-oauth-proof-of-possession]. 465 Note: The negotiation of cryptographic algorithms between the client 466 and the authorization server is not shown in the examples below and 467 assumed to be present in a protocol solution to meet the requirements 468 for crypto-agility. 470 +---------------+ 471 ^| | 472 // | Authorization | 473 / | Server | 474 // | | 475 / | | 476 (I) // /+---------------+ 477 Access / // 478 Token / / 479 Request // // (II) Access Token 480 +Params / / +Symmetric Key 481 // // 482 / v 483 +-----------+ +------------+ 484 | | | | 485 | | | Resource | 486 | Client | | Server | 487 | | | | 488 | | | | 489 +-----------+ +------------+ 491 Figure 1: Interaction between the Client and the Authorization Server 492 (Symmetric Keys). 494 In order to request an access token the client interacts with the 495 authorization server as part of the a normal grant exchange, as shown 496 in Figure 1. However, it needs to include additional information 497 elements for use with the PoP security mechanism, as depicted in 498 message (I). In message (II) the authorization server then returns 499 the requested access token. In addition to the access token itself, 500 the symmetric key is communicated to the client. This symmetric key 501 is a unique and fresh session key with sufficient entropy for the 502 given lifetime. Furthermore, information within the access token 503 ties it to this specific symmetric key. 505 Note: For this security mechanism to work the client as well as the 506 resource server need to have access to the session key. While the 507 key transport mechanism from the authorization server to the client 508 has been explained in the previous paragraph there are three ways for 509 communicating this session key from the authorization server to the 510 resource server, namely 512 Embedding the symmetric key inside the access token itself. This 513 requires that the symmetric key is confidentiality protected. 515 The resource server queries the authorization server for the 516 symmetric key. This is an approach envisioned by the token 517 introspection endpoint [I-D.ietf-oauth-introspection]. 519 The authorization server and the resource server both have access 520 to the same back-end database. Smaller, tightly coupled systems 521 might prefer such a deployment strategy. 523 +---------------+ 524 ^| | 525 Access Token Req. // | Authorization | 526 +Parameters / | Server | 527 +[Fingerprint] // | | 528 / | | 529 (I) // /+---------------+ 530 / // 531 / / (II) 532 // // Access Token 533 / / +[ephemeral 534 // // asymmetric key pair] 535 / v 536 +-----------+ +------------+ 537 | | | | 538 | | | Resource | 539 | Client | | Server | 540 | | | | 541 | | | | 542 +-----------+ +------------+ 544 Figure 2: Interaction between the Client and the Authorization Server 545 (Asymmetric Keys). 547 The use of asymmetric keys is slightly different since the client or 548 the server could be involved in the generation of the ephemeral key 549 pair. This exchange is shown in Figure 1. If the client generates 550 the key pair it either includes a fingerprint of the public key or 551 the public key in the request to the authorization server. The 552 authorization server would include this fingerprint or public key in 553 the confirmation claim inside the access token and thereby bind the 554 asymmetric key pair to the token. If the client did not provide a 555 fingerprint or a public key in the request then the authorization 556 server is asked to create an ephemeral asymmetric key pair, binds the 557 fingerprint of the public key to the access token, and returns the 558 asymmetric key pair (public and private key) to the client. Note 559 that there is a strong preference for generating the private/public 560 key pair locally at the client rather than at the server. 562 The specification describing the interaction between the client and 563 the authorization server, as shown in Figure 1 and in Figure 2, can 564 be found in [I-D.ietf-oauth-pop-key-distribution]. 566 Once the client has obtained the necessary access token and keying 567 material it can start to interact with the resource server. To 568 demonstrate possession of the key bound to the access token it needs 569 to apply this key to the request by computing a keyed message digest 570 (i.e., a symmetric key-based cryptographic primitive) or a digital 571 signature (i.e., an asymmetric cryptographic computation). When the 572 resource server receives the request it verifies it and decides 573 whether access to the protected resource can be granted. This 574 exchange is shown in Figure 3. 576 +---------------+ 577 | | 578 | Authorization | 579 | Server | 580 | | 581 | | 582 +---------------+ 584 Request 585 +-----------+ + Signature/MAC (a) +------------+ 586 | |---------------------->| | 587 | | [+Access Token] | Resource | 588 | Client | | Server | 589 | | Response (b) | | 590 | |<----------------------| | 591 +-----------+ [+ Signature/MAC] +------------+ 593 ^ ^ 594 | | 595 | | 596 Symmetric Key Symmetric Key 597 or or 598 Asymmetric Key Pair Public Key (Client) 599 + + 600 Parameters Parameters 602 Figure 3: Client demonstrates PoP. 604 The specification describing the ability to sign the HTTP request 605 from the client to the resource server can be found in 606 [I-D.ietf-oauth-signed-http-request]. 608 So far the examples talked about access tokens that are passed by 609 value and allow the resource server to make authorization decisions 610 immediately after verifying the request from the client. In some 611 deployments a real-time interaction between the authorization server 612 and the resource server is envisioned that lowers the need to pass 613 self-contained access tokens around. In that case the access token 614 merely serves as a handle or a reference to state stored at the 615 authorization server. As a consequence, the resource server cannot 616 autonomously make an authorization decision when receiving a request 617 from a client but has to consult the authorization server. This can, 618 for example, be done using the token introspection endpoint (see 619 [I-D.ietf-oauth-introspection]). Figure 4 shows the protocol 620 interaction graphically. Despite the additional token exchange 621 previous descriptions about associating symmetric and asymmetric keys 622 to the access token are still applicable to this scenario. 624 +---------------+ 625 Access ^| | 626 Token Req. // | Authorization |^ 627 (I) / | Server | \ (IV) Token 628 // | | \ Introspection Req. 629 / | | \ +Access 630 // /+---------------+ \ Token 631 / // (II) \ \\ 632 / / Access \ \ 633 // // Token \ (V) \ 634 / / \Resp.\ 635 // // \ \ 636 / v V \ 637 +-----------+ Request +Signature/MAC+------------+ 638 | | (III) +Access Token | | 639 | |---------------------->| Resource | 640 | Client | (VI) Success or | Server | 641 | | Failure | | 642 | |<----------------------| | 643 +-----------+ +------------+ 645 Figure 4: Token Introspection and Access Token Handles. 647 7. Requirements 649 RFC 4962 [RFC4962] gives useful guidelines for designers of 650 authentication and key management protocols. While RFC 4962 was 651 written with the AAA framework used for network access authentication 652 in mind the offered suggestions are useful for the design of other 653 key management systems as well. The following requirements list 654 applies OAuth 2.0 terminology to the requirements outlined in RFC 655 4962. 657 These requirements include 659 Cryptographic Algorithm Independent: 661 The key management protocol MUST be cryptographic algorithm 662 independent. 664 Strong, fresh session keys: 666 Session keys MUST be strong and fresh. Each session deserves an 667 independent session key, i.e., one that is generated specifically 668 for the intended use. In context of OAuth this means that keying 669 material is created in such a way that can only be used by the 670 combination of a client instance, protected resource, and 671 authorization scope. 673 Limit Key Scope: 675 Following the principle of least privilege, parties MUST NOT have 676 access to keying material that is not needed to perform their 677 role. Any protocol that is used to establish session keys MUST 678 specify the scope for session keys, clearly identifying the 679 parties to whom the session key is available. 681 Replay Detection Mechanism: 683 The key management protocol exchanges MUST be replay protected. 684 Replay protection allows a protocol message recipient to discard 685 any message that was recorded during a previous legitimate 686 dialogue and presented as though it belonged to the current 687 dialogue. 689 Authenticate All Parties: 691 Each party in the key management protocol MUST be authenticated to 692 the other parties with whom they communicate. Authentication 693 mechanisms MUST maintain the confidentiality of any secret values 694 used in the authentication process. Secrets MUST NOT be sent to 695 another party without confidentiality protection. 697 Authorization: 699 Client and resource server authorization MUST be performed. These 700 entities MUST demonstrate possession of the appropriate keying 701 material, without disclosing it. Authorization is REQUIRED 702 whenever a client interacts with an authorization server. The 703 authorization checking prevents an elevation of privilege attack, 704 and it ensures that an unauthorized authorized is detected. 706 Keying Material Confidentiality and Integrity: 708 While preserving algorithm independence, confidentiality and 709 integrity of all keying material MUST be maintained. 711 Confirm Cryptographic Algorithm Selection: 713 The selection of the "best" cryptographic algorithms SHOULD be 714 securely confirmed. The mechanism SHOULD detect attempted roll- 715 back attacks. 717 Uniquely Named Keys: 719 Key management proposals require a robust key naming scheme, 720 particularly where key caching is supported. The key name 721 provides a way to refer to a key in a protocol so that it is clear 722 to all parties which key is being referenced. Objects that cannot 723 be named cannot be managed. All keys MUST be uniquely named, and 724 the key name MUST NOT directly or indirectly disclose the keying 725 material. 727 Prevent the Domino Effect: 729 Compromise of a single client MUST NOT compromise keying material 730 held by any other client within the system, including session keys 731 and long-term keys. Likewise, compromise of a single resource 732 server MUST NOT compromise keying material held by any other 733 Resource Server within the system. In the context of a key 734 hierarchy, this means that the compromise of one node in the key 735 hierarchy must not disclose the information necessary to 736 compromise other branches in the key hierarchy. Obviously, the 737 compromise of the root of the key hierarchy will compromise all of 738 the keys; however, a compromise in one branch MUST NOT result in 739 the compromise of other branches. There are many implications of 740 this requirement; however, two implications deserve highlighting. 741 First, the scope of the keying material must be defined and 742 understood by all parties that communicate with a party that holds 743 that keying material. Second, a party that holds keying material 744 in a key hierarchy must not share that keying material with 745 parties that are associated with other branches in the key 746 hierarchy. 748 Bind Key to its Context: 750 Keying material MUST be bound to the appropriate context. The 751 context includes the following. 753 * The manner in which the keying material is expected to be used. 755 * The other parties that are expected to have access to the 756 keying material. 758 * The expected lifetime of the keying material. Lifetime of a 759 child key SHOULD NOT be greater than the lifetime of its parent 760 in the key hierarchy. 762 Any party with legitimate access to keying material can determine 763 its context. In addition, the protocol MUST ensure that all 764 parties with legitimate access to keying material have the same 765 context for the keying material. This requires that the parties 766 are properly identified and authenticated, so that all of the 767 parties that have access to the keying material can be determined. 768 The context will include the client and the resource server 769 identities in more than one form. 771 Authorization Restriction: 773 If client authorization is restricted, then the client SHOULD be 774 made aware of the restriction. 776 Client Identity Confidentiality: 778 A client has identity confidentiality when any party other than 779 the resource server and the authorization server cannot 780 sufficiently identify the client within the anonymity set. In 781 comparison to anonymity and pseudonymity, identity confidentiality 782 is concerned with eavesdroppers and intermediaries. A key 783 management protocol SHOULD provide this property. 785 Resource Owner Identity Confidentiality: 787 Resource servers SHOULD be prevented from knowing the real or 788 pseudonymous identity of the resource owner, since the 789 authorization server is the only entity involved in verifying the 790 resource owner's identity. 792 Collusion: 794 Resource servers that collude can be prevented from using 795 information related to the resource owner to track the individual. 796 That is, two different resource servers can be prevented from 797 determining that the same resource owner has authenticated to both 798 of them. Authorization servers MUST bind different keying 799 material to access tokens used for resource servers from different 800 origins (or similar concepts in the app world). 802 AS-to-RS Relationship Anonymity: 804 For solutions using asymmetric key cryptography the client MAY 805 conceal information about the resource server it wants to interact 806 with. The authorization server MAY reject such an attempt since 807 it may not be able to enforce access control decisions. 809 Channel Binding: 811 A solution MUST enable support for channel bindings. The concept 812 of channel binding, as defined in [RFC5056], allows applications 813 to establish that the two end-points of a secure channel at one 814 network layer are the same as at a higher layer by binding 815 authentication at the higher layer to the channel at the lower 816 layer. 818 There are performance concerns with the use of asymmetric 819 cryptography. Although symmetric key cryptography offers better 820 performance asymmetric cryptography offers additional security 821 properties. A solution MUST therefore offer the capability to 822 support both symmetric as well as asymmetric keys. 824 There are threats that relate to the experience of the software 825 developer as well as operational practices. Verifying the servers 826 identity in TLS is discussed at length in [RFC6125]. 828 A number of the threats listed in Section 4 demand protection of the 829 access token content and a standardized solution, in form of a JSON- 830 based format, is available with the JWT [RFC7519]. 832 8. Security Considerations 834 The purpose of this document is to provide use cases, requirements, 835 and motivation for developing an OAuth security solution extending 836 Bearer Tokens. As such, this document is only about security. 838 9. IANA Considerations 840 This document does not require actions by IANA. 842 10. Acknowledgments 844 This document is the result of conference calls late 2012/early 2013 845 and in design team conference calls February 2013 of the IETF OAuth 846 working group. The following persons (in addition to the OAuth WG 847 chairs, Hannes Tschofenig, and Derek Atkins) provided their input 848 during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek 849 Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John 850 Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian 851 Campbell 853 In the appendix of this document we re-use content from [RFC4962] and 854 the authors would like thank Russ Housely and Bernard Aboba for their 855 work on RFC 4962. 857 We would like to thank Reddy Tirumaleswar for his review. 859 11. References 861 11.1. Normative References 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 865 RFC2119, March 1997, 866 . 868 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 869 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 870 RFC5246, August 2008, 871 . 873 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 874 RFC 6749, DOI 10.17487/RFC6749, October 2012, 875 . 877 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 878 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 879 . 881 11.2. Informative References 883 [I-D.hardjono-oauth-kerberos] 884 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 885 Authentication Protocol", draft-hardjono-oauth-kerberos-01 886 (work in progress), December 2010. 888 [I-D.ietf-oauth-introspection] 889 Richer, J., "OAuth 2.0 Token Introspection", draft-ietf- 890 oauth-introspection-11 (work in progress), July 2015. 892 [I-D.ietf-oauth-pop-key-distribution] 893 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 894 "OAuth 2.0 Proof-of-Possession: Authorization Server to 895 Client Key Distribution", draft-ietf-oauth-pop-key- 896 distribution-01 (work in progress), March 2015. 898 [I-D.ietf-oauth-proof-of-possession] 899 Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 900 Possession Key Semantics for JSON Web Tokens (JWTs)", 901 draft-ietf-oauth-proof-of-possession-04 (work in 902 progress), August 2015. 904 [I-D.ietf-oauth-signed-http-request] 905 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 906 Signing an HTTP Requests for OAuth", draft-ietf-oauth- 907 signed-http-request-01 (work in progress), March 2015. 909 [NIST800-63] 910 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 911 and E. Nabbus, "NIST Special Publication 800-63-1, 912 INFORMATION SECURITY", December 2008. 914 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 915 Kerberos Network Authentication Service (V5)", RFC 4120, 916 DOI 10.17487/RFC4120, July 2005, 917 . 919 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 920 Ciphersuites for Transport Layer Security (TLS)", RFC 921 4279, DOI 10.17487/RFC4279, December 2005, 922 . 924 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 925 Authorization, and Accounting (AAA) Key Management", BCP 926 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, 927 . 929 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 930 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 931 . 933 [RFC5849] Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849, 934 DOI 10.17487/RFC5849, April 2010, 935 . 937 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 938 Verification of Domain-Based Application Service Identity 939 within Internet Public Key Infrastructure Using X.509 940 (PKIX) Certificates in the Context of Transport Layer 941 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 942 2011, . 944 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 945 Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/ 946 RFC6750, October 2012, 947 . 949 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 950 Threat Model and Security Considerations", RFC 6819, DOI 951 10.17487/RFC6819, January 2013, 952 . 954 Authors' Addresses 956 Phil Hunt (editor) 957 Oracle Corporation 959 Email: phil.hunt@yahoo.com 961 Justin Richer 963 Email: ietf@justin.richer.org 965 William Mills 967 Email: wmills@yahoo-inc.com 969 Prateek Mishra 970 Oracle Corporation 972 Email: prateek.mishra@oracle.com 973 Hannes Tschofenig 974 ARM Limited 975 Hall in Tirol 6060 976 Austria 978 Email: Hannes.Tschofenig@gmx.net 979 URI: http://www.tschofenig.priv.at