idnits 2.17.1 draft-hunt-oauth-pop-architecture-02.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 (June 26, 2014) is 3590 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-httpbis-p1-messaging' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-jose-json-web-encryption' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'I-D.tschofenig-oauth-audience' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 920, but no explicit reference was found in the text == Unused Reference: 'NIST-FIPS-180-3' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 970, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-bradley-oauth-pop-key-distribution-00 == Outdated reference: A later version (-40) exists of draft-ietf-jose-json-web-encryption-29 == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-23 == Outdated reference: A later version (-02) exists of draft-jones-oauth-proof-of-possession-00 == Outdated reference: A later version (-06) exists of draft-richer-oauth-introspection-04 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- 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: 4 errors (**), 0 flaws (~~), 20 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: December 28, 2014 The MITRE Corporation 6 W. Mills 7 Yahoo! Inc. 8 P. Mishra 9 Oracle Corporation 10 H. Tschofenig 11 ARM Limited 12 June 26, 2014 14 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture 15 draft-hunt-oauth-pop-architecture-02.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 December 28, 2014. 47 Copyright Notice 49 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 independent of 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. 216 4. Security and Privacy Threats 218 The following list presents several common threats against protocols 219 utilizing some form of tokens. This list of threats is based on NIST 220 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 221 threats related to any form of identity proofing and authentication 222 of the resource owner to the authorization server since these 223 procedures are not part of the OAuth 2.0 protocol specification 224 itself. 226 Token manufacture/modification: 228 An attacker may generate a bogus tokens or modify the token 229 content (such as authentication or attribute statements) of an 230 existing token, causing resource server to grant inappropriate 231 access to the client. For example, an attacker may modify the 232 token to extend the validity period. A client may modify the 233 token to have access to information that they should not be able 234 to view. 236 Token disclosure: Tokens may contain personal data, such as real 237 name, age or birthday, payment information, etc. 239 Token redirect: 241 An attacker uses the token generated for consumption by the 242 resource server to obtain access to another resource server. 244 Token reuse: 246 An attacker attempts to use a token that has already been used 247 once with a resource server. The attacker may be an eavesdropper 248 who observes the communication exchange or, worse, one of the 249 communication end points. A client may, for example, leak access 250 tokens because it cannot keep secrets confidential. A client may 251 also re-use access tokens for some other resource servers. 252 Finally, a resource server may use a token it had obtained from a 253 client and use it with another resource server that the client 254 interacts with. A resource server, offering relatively 255 unimportant application services, may attempt to use an access 256 token obtained from a client to access a high-value service, such 257 as a payment service, on behalf of the client using the same 258 access token. 260 Token repudiation: 262 Token repudiation refers to a property whereby a resource server 263 is given an assurance that the authorization server cannot deny to 264 have created a token for the client. 266 5. Threat Mitigation 268 A large range of threats can be mitigated by protecting the content 269 of the token, for example using a digital signature or a keyed 270 message digest. Alternatively, the content of the token could be 271 passed by reference rather than by value (requiring a separate 272 message exchange to resolve the reference to the token content). To 273 simplify the subsequent description we assume that the token itself 274 is digitally signed by the authorization server and therefore cannot 275 be modified. 277 To deal with token redirect it is important for the authorization 278 server to include the identifier of the intended recipient - the 279 resource server. A resource server must not be allowed to accept 280 access tokens that are not meant for its consumption. 282 To provide protection against token disclosure two approaches are 283 possible, namely (a) not to include sensitive information inside the 284 token or (b) to ensure confidentiality protection. The latter 285 approach requires at least the communication interaction between the 286 client and the authorization server as well as the interaction 287 between the client and the resource server to experience 288 confidentiality protection. As an example, TLS with a ciphersuite 289 that offers confidentiality protection has to be applied (which is 290 currently true for all ciphersuites, except for one). Encrypting the 291 token content itself is another alternative. In our scenario the 292 authorization server would, for example, encrypt the token content 293 with a symmetric key shared with the resource server. 295 To deal with token reuse more choices are available. 297 5.1. Confidentiality Protection 299 In this approach confidentiality protection of the exchange is 300 provided on the communication interfaces between the client and the 301 resource server, and between the client and the authorization server. 302 No eavesdropper on the wire is able to observe the token exchange. 303 Consequently, a replay by a third party is not possible. An 304 authorization server wants to ensure that it only hands out tokens to 305 clients it has authenticated first and who are authorized. For this 306 purpose, authentication of the client to the authorization server 307 will be a requirement to ensure adequate protection against a range 308 of attacks. This is, however, true for the description in 309 Section 5.2 and Section 5.3 as well. Furthermore, the client has to 310 make sure it does not distribute (or leak) the access token to 311 entities other than the intended the resource server. For that 312 purpose the client will have to authenticate the resource server 313 before transmitting the access token. 315 5.2. Sender Constraint 317 Instead of providing confidentiality protection the authorization 318 server could also put the identifier of the client into the protected 319 token with the following semantic: 'This token is only valid when 320 presented by a client with the following identifier.' When the 321 access token is then presented to the resource server how does it 322 know that it was provided by the client? It has to authenticate the 323 client! There are many choices for authenticating the client to the 324 resource server, for example by using client certificates in TLS 325 [RFC5246], or pre-shared secrets within TLS [RFC4279]. The choice of 326 the preferred authentication mechanism and credential type may depend 327 on a number of factors, including 329 o security properties 331 o available infrastructure 333 o library support 334 o credential cost (financial) 336 o performance 338 o integration into the existing IT infrastructure 340 o operational overhead for configuration and distribution of 341 credentials 343 This long list hints to the challenge of selecting at least one 344 mandatory-to-implement client authentication mechanism. 346 5.3. Key Confirmation 348 A variation of the mechanism of sender authentication, described in 349 Section 5.2, is to replace authentication with the proof-of- 350 possession of a specific (session) key, i.e., key confirmation. In 351 this model the resource server would not authenticate the client 352 itself but would rather verify whether the client knows the session 353 key associated with a specific access token. Examples of this 354 approach can be found with the OAuth 1.0 MAC token [RFC5849], and 355 Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see 356 also [I-D.hardjono-oauth-kerberos] for a comparison between Kerberos 357 and OAuth). 359 To illustrate key confirmation the first examples borrow from 360 Kerberos and use symmetric key cryptography. Assume that the 361 authorization server shares a long-term secret with the resource 362 server, called K(Authorization Server-Resource Server). This secret 363 would be established between them out-of-band. When the client 364 requests an access token the authorization server creates a fresh and 365 unique session key Ks and places it into the token encrypted with the 366 long term key K(Authorization Server-Resource Server). Additionally, 367 the authorization server attaches Ks to the response message to the 368 client (in addition to the access token itself) over a 369 confidentiality protected channel. When the client sends a request 370 to the resource server it has to use Ks to compute a keyed message 371 digest for the request (in whatever form or whatever layer). The 372 resource server, when receiving the message, retrieves the access 373 token, verifies it and extracts K(Authorization Server-Resource 374 Server) to obtain Ks. This key Ks is then used to verify the keyed 375 message digest of the request message. 377 Note that in this example one could imagine that the mechanism to 378 protect the token itself is based on a symmetric key based mechanism 379 to avoid any form of public key infrastructure but this aspect is not 380 further elaborated in the scenario. 382 A similar mechanism can also be designed using asymmetric 383 cryptography. When the client requests an access token the 384 authorization server creates an ephemeral public / privacy key pair 385 (PK/SK) and places the public key PK into the protected token. When 386 the authorization server returns the access token to the client it 387 also provides the PK/SK key pair over a confidentiality protected 388 channel. When the client sends a request to the resource server it 389 has to use the privacy key SK to sign the request. The resource 390 server, when receiving the message, retrieves the access token, 391 verifies it and extracts the public key PK. It uses this ephemeral 392 public key to verify the attached signature. 394 5.4. Summary 396 As a high level message, there are various ways how the threats can 397 be mitigated and while the details of each solution is somewhat 398 different they all ultimately accomplish the goal. 400 The three approaches are: 402 Confidentiality Protection: 404 The weak point with this approach, which is briefly described in 405 Section 5.1, is that the client has to be careful to whom it 406 discloses the access token. What can be done with the token 407 entirely depends on what rights the token entitles the presenter 408 and what constraints it contains. A token could encode the 409 identifier of the client but there are scenarios where the client 410 is not authenticated to the resource server or where the 411 identifier of the client rather represents an application class 412 rather than a single application instance. As such, it is 413 possible that certain deployments choose a rather liberal approach 414 to security and that everyone who is in possession of the access 415 token is granted access to the data. 417 Sender Constraint: 419 The weak point with this approach, which is briefly described in 420 Section 5.2, is to setup the authentication infrastructure such 421 that clients can be authenticated towards resource servers. 422 Additionally, the authorization server must encode the identifier 423 of the client in the token for later verification by the resource 424 server. Depending on the chosen layer for providing client-side 425 authentication there may be additional challenges due Web server 426 load balancing, lack of API access to identity information, etc. 428 Key Confirmation: 430 The weak point with this approach, see Section 5.3, is the 431 increased complexity: a complete key distribution protocol has to 432 be defined. 434 In all cases above it has to be ensured that the client is able to 435 keep the credentials secret. 437 6. Architecture 439 The proof-of-possession security concept assumes that the 440 authorization server acts as a trusted third party that binds keys to 441 access tokens. These keys are then used by the client to demonstrate 442 the possession of the secret to the resource server when accessing 443 the resource. The resource server, when receiving an access token, 444 needs to verify that the key used by the client matches the one 445 included in the access token. 447 There are slight differences between the use of symmetric keys and 448 asymmetric keys when they are bound to the access token and the 449 subsequent interaction between the client and the authorization 450 server when demonstrating possession of these keys. Figure 1 shows 451 the symmetric key procedure and Figure 2 illustrates how asymmetric 452 keys are used. 454 With the JSON Web Token (JWT) a standardized format for access tokens 455 is available. The necessary elements to bind symmetric or asymmetric 456 keys to the JWT are described in 457 [I-D.jones-oauth-proof-of-possession]. 459 +---------------+ 460 ^| | 461 // | Authorization | 462 / | Server | 463 // | | 464 / | | 465 (I) // /+---------------+ 466 Access / // 467 Token / / 468 Request // // (II) Access Token 469 +Params / / +Symmetric Key 470 // // 471 / v 472 +-----------+ +------------+ 473 | | | | 474 | | | Resource | 475 | Client | | Server | 476 | | | | 477 | | | | 478 +-----------+ +------------+ 480 Figure 1: Interaction between the Client and the Authorization Server 481 (Symmetric Keys). 483 In order to request an access token the client interacts with the 484 authorization server as part of the a normal grant exchange, as shown 485 in Figure 1. However, it needs to include additional information 486 elements for use with the PoP security mechanism, as depicted in 487 message (I). In message (II) the authorization server then returns 488 the requested access token. In addition to the access token itself, 489 the symmetric key is communicated to the client. This symmetric key 490 is a unique and fresh session key with sufficient entropy for the 491 given lifetime. Furthermore, information within the access token 492 ties it to this specific symmetric key. 494 Note: For this security mechanism to work the client as well as the 495 resource server need to have access to the session key. While the 496 key transport mechanism from the authorization server to the client 497 has been explained in the previous paragraph there are three ways for 498 communicating this session key from the authorization server to the 499 resource server, namely 501 Embedding the symmetric key inside the access token itself. This 502 requires that the symmetric key is confidentiality protected. 504 The resource server queries the authorization server for the 505 symmetric key. This is an approach envisioned by the token 506 introspection endpoint [I-D.richer-oauth-introspection]. 508 The authorization server and the resource server both have access 509 to the same back-end database. Smaller, tightly coupled systems 510 might prefer such a deployment strategy. 512 +---------------+ 513 ^| | 514 Access Token Req. // | Authorization | 515 +Parameters / | Server | 516 +[Fingerprint] // | | 517 / | | 518 (I) // /+---------------+ 519 / // 520 / / (II) 521 // // Access Token 522 / / +[ephemeral 523 // // asymmetric key pair] 524 / v 525 +-----------+ +------------+ 526 | | | | 527 | | | Resource | 528 | Client | | Server | 529 | | | | 530 | | | | 531 +-----------+ +------------+ 533 Figure 2: Interaction between the Client and the Authorization Server 534 (Asymmetric Keys). 536 The use of asymmetric keys is slightly different since the client or 537 the server could be involved in the generation of the ephemeral key 538 pair. This exchange is shown in Figure 1. If the client generates 539 the key pair it either includes a fingerprint of the public key or 540 the public key in the request to the authorization server. The 541 authorization server would include this fingerprint or public key in 542 the confirmation claim inside the access token and thereby bind the 543 asymmetric key pair to the token. If the client did not provide a 544 fingerprint or a public key in the request then the authorization 545 server is asked to create an ephemeral asymmetric key pair, binds the 546 fingerprint of the public key to the access token, and returns the 547 asymmetric key pair (public and private key) to the client. 549 The specification describing the interaction between the client and 550 the authorization server, as shown in Figure 1 and in Figure 2, can 551 be found in [I-D.bradley-oauth-pop-key-distribution]. 553 Once the client has obtained the necessary access token and keying 554 material it can start to interact with the resource server. To 555 demonstrate possession of the key bound to the access token it needs 556 to apply this key to the request by computing a keyed message digest 557 (i.e., a symmetric key-based cryptographic primitive) or a digital 558 signature (i.e., an asymmetric cryptographic primitive). When the 559 resource server receives the request it verifies it and decides 560 whether access to the protected resource can be granted. This 561 exchange is shown in Figure 3. 563 +---------------+ 564 | | 565 | Authorization | 566 | Server | 567 | | 568 | | 569 +---------------+ 571 Request 572 +-----------+ + Signature/MAC (a) +------------+ 573 | |---------------------->| | 574 | | [+Access Token] | Resource | 575 | Client | | Server | 576 | | Response (b) | | 577 | |<----------------------| | 578 +-----------+ +------------+ 580 ^ ^ 581 | | 582 | | 583 Symmetric Key Symmetric Key 584 or or 585 Asymmetric Key Pair Public Key (Client) 586 + + 587 Parameters Parameters 589 Figure 3: Client demonstrates PoP. 591 The specification describing the ability to sign the HTTP request 592 from the client to the resource server can be found in 593 [I-D.richer-oauth-signed-http-request]. 595 So far the examples talked about access tokens that are passed by 596 value and allow the resource server to make authorization decisions 597 immediately after verifying the request from the client. In some 598 deployments a real-time interaction between the authorization server 599 and the resource server is envisioned that lowers the need to pass 600 self-contained access tokens around. In that case the access token 601 merely serves as a handle or a reference to state stored at the 602 authorization server. As a consequence, the resource server cannot 603 autonomously make an authorization decision when receiving a request 604 from a client but has to consult the authorization server. This can, 605 for example, be done using the token introspection endpoint (see 606 [I-D.richer-oauth-introspection]). Figure 4 shows the protocol 607 interaction graphically. Despite the additional token exchange 608 previous descriptions about associating symmetric and asymmetric keys 609 to the access token are still applicable to this scenario. 611 +---------------+ 612 Access ^| | 613 Token Req. // | Authorization |\ 614 (I) / | Server | \ (IV) Token 615 // | | \ Introspection 616 / | | \ +Access 617 // /+---------------+ \ Token 618 / // (II) \ \\ 619 / / Access \ \ 620 // // Token \ (V) \ 621 / / \Resp.\ 622 // // \ \ 623 / v \ \ 624 +-----------+ Request +Signature/MAC+------------+ 625 | | (III) +Access Token | | 626 | |---------------------->| Resource | 627 | Client | (VI) Success or | Server | 628 | | Failure | | 629 | |<----------------------| | 630 +-----------+ +------------+ 632 Figure 4: Token Introspection and Access Token Handles. 634 7. Requirements 636 RFC 4962 [RFC4962] gives useful guidelines for designers of 637 authentication and key management protocols. While RFC 4962 was 638 written with the AAA framework used for network access authentication 639 in mind the offered suggestions are useful for the design of other 640 key management systems as well. The following requirements list 641 applies OAuth 2.0 terminology to the requirements outlined in RFC 642 4962. 644 These requirements include 646 Cryptographic Algorithm Independent: 648 The key management protocol MUST be cryptographic algorithm 649 independent. 651 Strong, fresh session keys: 653 Session keys MUST be strong and fresh. Each session deserves an 654 independent session key, i.e., one that is generated specifically 655 for the intended use. In context of OAuth this means that keying 656 material is created in such a way that can only be used by the 657 combination of a client instance, protected resource, and 658 authorization scope. 660 Limit Key Scope: 662 Following the principle of least privilege, parties MUST NOT have 663 access to keying material that is not needed to perform their 664 role. Any protocol that is used to establish session keys MUST 665 specify the scope for session keys, clearly identifying the 666 parties to whom the session key is available. 668 Replay Detection Mechanism: 670 The key management protocol exchanges MUST be replay protected. 671 Replay protection allows a protocol message recipient to discard 672 any message that was recorded during a previous legitimate 673 dialogue and presented as though it belonged to the current 674 dialogue. 676 Authenticate All Parties: 678 Each party in the key management protocol MUST be authenticated to 679 the other parties with whom they communicate. Authentication 680 mechanisms MUST maintain the confidentiality of any secret values 681 used in the authentication process. Secrets MUST NOT be sent to 682 another party without confidentiality protection. 684 Authorization: 686 Client and resource server authorization MUST be performed. These 687 entities MUST demonstrate possession of the appropriate keying 688 material, without disclosing it. Authorization is REQUIRED 689 whenever a client interacts with an authorization server. The 690 authorization checking prevents an elevation of privilege attack, 691 and it ensures that an unauthorized authorized is detected. 693 Keying Material Confidentiality and Integrity: 695 While preserving algorithm independence, confidentiality and 696 integrity of all keying material MUST be maintained. 698 Confirm Cryptographic Algorithm Selection: 700 The selection of the "best" cryptographic algorithms SHOULD be 701 securely confirmed. The mechanism SHOULD detect attempted roll- 702 back attacks. 704 Uniquely Named Keys: 706 Key management proposals require a robust key naming scheme, 707 particularly where key caching is supported. The key name 708 provides a way to refer to a key in a protocol so that it is clear 709 to all parties which key is being referenced. Objects that cannot 710 be named cannot be managed. All keys MUST be uniquely named, and 711 the key name MUST NOT directly or indirectly disclose the keying 712 material. 714 Prevent the Domino Effect: 716 Compromise of a single client MUST NOT compromise keying material 717 held by any other client within the system, including session keys 718 and long-term keys. Likewise, compromise of a single resource 719 server MUST NOT compromise keying material held by any other 720 Resource Server within the system. In the context of a key 721 hierarchy, this means that the compromise of one node in the key 722 hierarchy must not disclose the information necessary to 723 compromise other branches in the key hierarchy. Obviously, the 724 compromise of the root of the key hierarchy will compromise all of 725 the keys; however, a compromise in one branch MUST NOT result in 726 the compromise of other branches. There are many implications of 727 this requirement; however, two implications deserve highlighting. 728 First, the scope of the keying material must be defined and 729 understood by all parties that communicate with a party that holds 730 that keying material. Second, a party that holds keying material 731 in a key hierarchy must not share that keying material with 732 parties that are associated with other branches in the key 733 hierarchy. 735 Bind Key to its Context: 737 Keying material MUST be bound to the appropriate context. The 738 context includes the following. 740 * The manner in which the keying material is expected to be used. 742 * The other parties that are expected to have access to the 743 keying material. 745 * The expected lifetime of the keying material. Lifetime of a 746 child key SHOULD NOT be greater than the lifetime of its parent 747 in the key hierarchy. 749 Any party with legitimate access to keying material can determine 750 its context. In addition, the protocol MUST ensure that all 751 parties with legitimate access to keying material have the same 752 context for the keying material. This requires that the parties 753 are properly identified and authenticated, so that all of the 754 parties that have access to the keying material can be determined. 755 The context will include the client and the resource server 756 identities in more than one form. 758 Authorization Restriction: 760 If client authorization is restricted, then the client SHOULD be 761 made aware of the restriction. 763 Client Identity Confidentiality: 765 A client has identity confidentiality when any party other than 766 the resource server and the authorization server cannot 767 sufficiently identify the client within the anonymity set. In 768 comparison to anonymity and pseudonymity, identity confidentiality 769 is concerned with eavesdroppers and intermediaries. A key 770 management protocol SHOULD provide this property. 772 Resource Owner Identity Confidentiality: 774 Resource servers SHOULD be prevented from knowing the real or 775 pseudonymous identity of the resource owner, since the 776 authorization server is the only entity involved in verifying the 777 resource owner's identity. 779 Collusion: 781 Resource servers that collude can be prevented from using 782 information related to the resource owner to track the individual. 783 That is, two different resource servers can be prevented from 784 determining that the same resource owner has authenticated to both 785 of them. This requires that each authorization server obtains 786 different keying material as well as different access tokens with 787 content that does not allow identification of the resource owner. 789 AS-to-RS Relationship Anonymity: 791 This MAC Token security does not provide AS-to-RS relationship 792 anonymity since the client has to inform the resource server about 793 the resource server it wants to talk to. The authorization server 794 needs to know how to encrypt the session key the client and the 795 resource server will be using. 797 As an additional requirement a solution MUST enable support for 798 channel bindings. The concept of channel binding, as defined in 799 [RFC5056], allows applications to establish that the two end-points 800 of a secure channel at one network layer are the same as at a higher 801 layer by binding authentication at the higher layer to the channel at 802 the lower layer. 804 There are performance concerns with the use of asymmetric 805 cryptography. Although symmetric key cryptography offers better 806 performance asymmetric cryptography offers additional security 807 properties. A solution MUST therefore offer the capability to 808 support both symmetric as well as asymmetric keys. 810 There are threats that relate to the experience of the software 811 developer as well as operational practices. Verifying the servers 812 identity in TLS is discussed at length in [RFC6125]. 814 A number of the threats listed in Section 4 demand protection of the 815 access token content and a standardized solution, in form of a JSON- 816 based format, is available with the JWT 817 [I-D.ietf-oauth-json-web-token]. 819 8. Security Considerations 821 The purpose of this document is to provide use cases, requirements, 822 and motivation for developing an OAuth security solution extending 823 Bearer Tokens. As such, this document is only about security. 825 9. IANA Considerations 827 This document does not require actions by IANA. 829 10. Acknowledgments 831 This document is the result of conference calls late 2012/early 2013 832 and in design team conference calls February 2013 of the IETF OAuth 833 working group. The following persons (in addition to the OAuth WG 834 chairs, Hannes Tschofenig, and Derek Atkins) provided their input 835 during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek 836 Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John 837 Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian 838 Campbell 840 In the appendix of this document we re-use content from [RFC4962] and 841 the authors would like thank Russ Housely and Bernard Aboba for their 842 work on RFC 4962. 844 11. References 846 11.1. Normative References 848 [I-D.bradley-oauth-pop-key-distribution] 849 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 850 "OAuth 2.0 Proof-of-Possession: Authorization Server to 851 Client Key Distribution", draft-bradley-oauth-pop-key- 852 distribution-00 (work in progress), April 2014. 854 [I-D.ietf-httpbis-p1-messaging] 855 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 856 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 857 httpbis-p1-messaging-26 (work in progress), February 2014. 859 [I-D.ietf-jose-json-web-encryption] 860 Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 861 draft-ietf-jose-json-web-encryption-29 (work in progress), 862 June 2014. 864 [I-D.ietf-oauth-json-web-token] 865 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 866 (JWT)", draft-ietf-oauth-json-web-token-23 (work in 867 progress), June 2014. 869 [I-D.jones-oauth-proof-of-possession] 870 Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- 871 Possession Semantics for JSON Web Tokens (JWTs)", draft- 872 jones-oauth-proof-of-possession-00 (work in progress), 873 April 2014. 875 [I-D.richer-oauth-introspection] 876 Richer, J., "OAuth Token Introspection", draft-richer- 877 oauth-introspection-04 (work in progress), May 2013. 879 [I-D.richer-oauth-signed-http-request] 880 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 881 Signing an HTTP Requests for OAuth", draft-richer-oauth- 882 signed-http-request-01 (work in progress), April 2014. 884 [I-D.tschofenig-oauth-audience] 885 Tschofenig, H., "OAuth 2.0: Audience Information", draft- 886 tschofenig-oauth-audience-00 (work in progress), February 887 2013. 889 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 890 Extensions (MIME) Part One: Format of Internet Message 891 Bodies", RFC 2045, November 1996. 893 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 894 Hashing for Message Authentication", RFC 2104, February 895 1997. 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, March 1997. 900 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 901 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 902 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 904 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 905 Leach, P., Luotonen, A., and L. Stewart, "HTTP 906 Authentication: Basic and Digest Access Authentication", 907 RFC 2617, June 1999. 909 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 910 Resource Identifier (URI): Generic Syntax", STD 66, RFC 911 3986, January 2005. 913 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 914 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 915 May 2008. 917 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 918 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 920 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 921 April 2011. 923 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 924 6749, October 2012. 926 [W3C.REC-html401-19991224] 927 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 928 Specification", World Wide Web Consortium Recommendation 929 REC-html401-19991224, December 1999, 930 . 932 11.2. Informative References 934 [I-D.hardjono-oauth-kerberos] 935 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 936 Authentication Protocol", draft-hardjono-oauth-kerberos-01 937 (work in progress), December 2010. 939 [NIST-FIPS-180-3] 940 National Institute of Standards and Technology, "Secure 941 Hash Standard (SHS). FIPS PUB 180-3, October 2008", 942 October 2008. 944 [NIST800-63] 945 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 946 and E. Nabbus, "NIST Special Publication 800-63-1, 947 INFORMATION SECURITY", December 2008. 949 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 950 Requirements for Security", BCP 106, RFC 4086, June 2005. 952 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 953 Kerberos Network Authentication Service (V5)", RFC 4120, 954 July 2005. 956 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 957 for Transport Layer Security (TLS)", RFC 4279, December 958 2005. 960 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 961 Authorization, and Accounting (AAA) Key Management", BCP 962 132, RFC 4962, July 2007. 964 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 965 Channels", RFC 5056, November 2007. 967 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 968 April 2010. 970 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 971 for TLS", RFC 5929, July 2010. 973 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 974 Verification of Domain-Based Application Service Identity 975 within Internet Public Key Infrastructure Using X.509 976 (PKIX) Certificates in the Context of Transport Layer 977 Security (TLS)", RFC 6125, March 2011. 979 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 980 Framework: Bearer Token Usage", RFC 6750, October 2012. 982 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 983 Threat Model and Security Considerations", RFC 6819, 984 January 2013. 986 Authors' Addresses 988 Phil Hunt (editor) 989 Oracle Corporation 991 Email: phil.hunt@yahoo.com 993 Justin Richer 994 The MITRE Corporation 996 Email: jricher@mitre.org 998 William Mills 999 Yahoo! Inc. 1001 Email: wmills@yahoo-inc.com 1003 Prateek Mishra 1004 Oracle Corporation 1006 Email: prateek.mishra@oracle.com 1007 Hannes Tschofenig 1008 ARM Limited 1009 Austria 1011 Email: Hannes.Tschofenig@gmx.net 1012 URI: http://www.tschofenig.priv.at