idnits 2.17.1 draft-ietf-oauth-pop-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 3, 2015) is 3335 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 862, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-jose-json-web-encryption' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'NIST-FIPS-180-3' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 980, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-oauth-introspection-05 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-00 == Outdated reference: A later version (-11) exists of draft-ietf-oauth-proof-of-possession-01 == Outdated reference: A later version (-03) exists of draft-ietf-oauth-signed-http-request-00 ** 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 (~~), 18 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: September 4, 2015 6 W. Mills 8 P. Mishra 9 Oracle Corporation 10 H. Tschofenig 11 ARM Limited 12 March 3, 2015 14 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture 15 draft-ietf-oauth-pop-architecture-01.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 September 4, 2015. 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 . . . . . . . . . . . . . . . . . . . 19 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 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: Tokens may contain personal data, such as real 238 name, age or birthday, payment information, etc. 240 Token redirect: 242 An attacker uses the token generated for consumption by the 243 resource server to obtain access to another resource server. 245 Token reuse: 247 An attacker attempts to use a token that has already been used 248 once with a resource server. The attacker may be an eavesdropper 249 who observes the communication exchange or, worse, one of the 250 communication end points. A client may, for example, leak access 251 tokens because it cannot keep secrets confidential. A client may 252 also re-use access tokens for some other resource servers. 253 Finally, a resource server may use a token it had obtained from a 254 client and use it with another resource server that the client 255 interacts with. A resource server, offering relatively 256 unimportant application services, may attempt to use an access 257 token obtained from a client to access a high-value service, such 258 as a payment service, on behalf of the client using the same 259 access token. 261 Token repudiation: 263 Token repudiation refers to a property whereby a resource server 264 is given an assurance that the authorization server cannot deny to 265 have created a token for the client. 267 5. Threat Mitigation 269 A large range of threats can be mitigated by protecting the content 270 of the token, for example using a digital signature or a keyed 271 message digest. Alternatively, the content of the token could be 272 passed by reference rather than by value (requiring a separate 273 message exchange to resolve the reference to the token content). To 274 simplify the subsequent description we assume that the token itself 275 is digitally signed by the authorization server and therefore cannot 276 be modified. 278 To deal with token redirect it is important for the authorization 279 server to include the identifier of the intended recipient - the 280 resource server. A resource server must not be allowed to accept 281 access tokens that are not meant for its consumption. 283 To provide protection against token disclosure two approaches are 284 possible, namely (a) not to include sensitive information inside the 285 token or (b) to ensure confidentiality protection. The latter 286 approach requires at least the communication interaction between the 287 client and the authorization server as well as the interaction 288 between the client and the resource server to experience 289 confidentiality protection. As an example, TLS with a ciphersuite 290 that offers confidentiality protection has to be applied (which is 291 currently true for all ciphersuites, except for one). Encrypting the 292 token content itself is another alternative. In our scenario the 293 authorization server would, for example, encrypt the token content 294 with a symmetric key shared with the resource server. 296 To deal with token reuse more choices are available. 298 5.1. Confidentiality Protection 300 In this approach confidentiality protection of the exchange is 301 provided on the communication interfaces between the client and the 302 resource server, and between the client and the authorization server. 303 No eavesdropper on the wire is able to observe the token exchange. 304 Consequently, a replay by a third party is not possible. An 305 authorization server wants to ensure that it only hands out tokens to 306 clients it has authenticated first and who are authorized. For this 307 purpose, authentication of the client to the authorization server 308 will be a requirement to ensure adequate protection against a range 309 of attacks. This is, however, true for the description in 310 Section 5.2 and Section 5.3 as well. Furthermore, the client has to 311 make sure it does not distribute (or leak) the access token to 312 entities other than the intended the resource server. For that 313 purpose the client will have to authenticate the resource server 314 before transmitting the access token. 316 5.2. Sender Constraint 318 Instead of providing confidentiality protection the authorization 319 server could also put the identifier of the client into the protected 320 token with the following semantic: 'This token is only valid when 321 presented by a client with the following identifier.' When the 322 access token is then presented to the resource server how does it 323 know that it was provided by the client? It has to authenticate the 324 client! There are many choices for authenticating the client to the 325 resource server, for example by using client certificates in TLS 326 [RFC5246], or pre-shared secrets within TLS [RFC4279]. The choice of 327 the preferred authentication mechanism and credential type may depend 328 on a number of factors, including 330 o security properties 332 o available infrastructure 334 o library support 335 o credential cost (financial) 337 o performance 339 o integration into the existing IT infrastructure 341 o operational overhead for configuration and distribution of 342 credentials 344 This long list hints to the challenge of selecting at least one 345 mandatory-to-implement client authentication mechanism. 347 5.3. Key Confirmation 349 A variation of the mechanism of sender authentication, described in 350 Section 5.2, is to replace authentication with the proof-of- 351 possession of a specific (session) key, i.e., key confirmation. In 352 this model the resource server would not authenticate the client 353 itself but would rather verify whether the client knows the session 354 key associated with a specific access token. Examples of this 355 approach can be found with the OAuth 1.0 MAC token [RFC5849], and 356 Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see 357 also [I-D.hardjono-oauth-kerberos] for a comparison between Kerberos 358 and OAuth). 360 To illustrate key confirmation the first examples borrow from 361 Kerberos and use symmetric key cryptography. Assume that the 362 authorization server shares a long-term secret with the resource 363 server, called K(Authorization Server-Resource Server). This secret 364 would be established between them out-of-band. When the client 365 requests an access token the authorization server creates a fresh and 366 unique session key Ks and places it into the token encrypted with the 367 long term key K(Authorization Server-Resource Server). Additionally, 368 the authorization server attaches Ks to the response message to the 369 client (in addition to the access token itself) over a 370 confidentiality protected channel. When the client sends a request 371 to the resource server it has to use Ks to compute a keyed message 372 digest for the request (in whatever form or whatever layer). The 373 resource server, when receiving the message, retrieves the access 374 token, verifies it and extracts K(Authorization Server-Resource 375 Server) to obtain Ks. This key Ks is then used to verify the keyed 376 message digest of the request message. 378 Note that in this example one could imagine that the mechanism to 379 protect the token itself is based on a symmetric key based mechanism 380 to avoid any form of public key infrastructure but this aspect is not 381 further elaborated in the scenario. 383 A similar mechanism can also be designed using asymmetric 384 cryptography. When the client requests an access token the 385 authorization server creates an ephemeral public / privacy key pair 386 (PK/SK) and places the public key PK into the protected token. When 387 the authorization server returns the access token to the client it 388 also provides the PK/SK key pair over a confidentiality protected 389 channel. When the client sends a request to the resource server it 390 has to use the privacy key SK to sign the request. The resource 391 server, when receiving the message, retrieves the access token, 392 verifies it and extracts the public key PK. It uses this ephemeral 393 public key to verify the attached signature. 395 5.4. Summary 397 As a high level message, there are various ways how the threats can 398 be mitigated and while the details of each solution is somewhat 399 different they all ultimately accomplish the goal. 401 The three approaches are: 403 Confidentiality Protection: 405 The weak point with this approach, which is briefly described in 406 Section 5.1, is that the client has to be careful to whom it 407 discloses the access token. What can be done with the token 408 entirely depends on what rights the token entitles the presenter 409 and what constraints it contains. A token could encode the 410 identifier of the client but there are scenarios where the client 411 is not authenticated to the resource server or where the 412 identifier of the client rather represents an application class 413 rather than a single application instance. As such, it is 414 possible that certain deployments choose a rather liberal approach 415 to security and that everyone who is in possession of the access 416 token is granted access to the data. 418 Sender Constraint: 420 The weak point with this approach, which is briefly described in 421 Section 5.2, is to setup the authentication infrastructure such 422 that clients can be authenticated towards resource servers. 423 Additionally, the authorization server must encode the identifier 424 of the client in the token for later verification by the resource 425 server. Depending on the chosen layer for providing client-side 426 authentication there may be additional challenges due Web server 427 load balancing, lack of API access to identity information, etc. 429 Key Confirmation: 431 The weak point with this approach, see Section 5.3, is the 432 increased complexity: a complete key distribution protocol has to 433 be defined. 435 In all cases above it has to be ensured that the client is able to 436 keep the credentials secret. 438 6. Architecture 440 The proof-of-possession security concept assumes that the 441 authorization server acts as a trusted third party that binds keys to 442 access tokens. These keys are then used by the client to demonstrate 443 the possession of the secret to the resource server when accessing 444 the resource. The resource server, when receiving an access token, 445 needs to verify that the key used by the client matches the one 446 included in the access token. 448 There are slight differences between the use of symmetric keys and 449 asymmetric keys when they are bound to the access token and the 450 subsequent interaction between the client and the authorization 451 server when demonstrating possession of these keys. Figure 1 shows 452 the symmetric key procedure and Figure 2 illustrates how asymmetric 453 keys are used. While symmetric cryptography provides better 454 performance properties the use of asymmetric cryptography allows the 455 client to keep the private key locally and never expose it to any 456 other party. 458 With the JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] a 459 standardized format for access tokens is available. The necessary 460 elements to bind symmetric or asymmetric keys to a JWT are described 461 in [I-D.ietf-oauth-proof-of-possession]. 463 Note: The negotiation of cryptographic algorithms between the client 464 and the authorization server is not shown in the examples below and 465 assumed to be present in a protocol solution to meet the requirements 466 for crypto-agility. 468 +---------------+ 469 ^| | 470 // | Authorization | 471 / | Server | 472 // | | 473 / | | 474 (I) // /+---------------+ 475 Access / // 476 Token / / 477 Request // // (II) Access Token 478 +Params / / +Symmetric Key 479 // // 480 / v 481 +-----------+ +------------+ 482 | | | | 483 | | | Resource | 484 | Client | | Server | 485 | | | | 486 | | | | 487 +-----------+ +------------+ 489 Figure 1: Interaction between the Client and the Authorization Server 490 (Symmetric Keys). 492 In order to request an access token the client interacts with the 493 authorization server as part of the a normal grant exchange, as shown 494 in Figure 1. However, it needs to include additional information 495 elements for use with the PoP security mechanism, as depicted in 496 message (I). In message (II) the authorization server then returns 497 the requested access token. In addition to the access token itself, 498 the symmetric key is communicated to the client. This symmetric key 499 is a unique and fresh session key with sufficient entropy for the 500 given lifetime. Furthermore, information within the access token 501 ties it to this specific symmetric key. 503 Note: For this security mechanism to work the client as well as the 504 resource server need to have access to the session key. While the 505 key transport mechanism from the authorization server to the client 506 has been explained in the previous paragraph there are three ways for 507 communicating this session key from the authorization server to the 508 resource server, namely 510 Embedding the symmetric key inside the access token itself. This 511 requires that the symmetric key is confidentiality protected. 513 The resource server queries the authorization server for the 514 symmetric key. This is an approach envisioned by the token 515 introspection endpoint [I-D.ietf-oauth-introspection]. 517 The authorization server and the resource server both have access 518 to the same back-end database. Smaller, tightly coupled systems 519 might prefer such a deployment strategy. 521 +---------------+ 522 ^| | 523 Access Token Req. // | Authorization | 524 +Parameters / | Server | 525 +[Fingerprint] // | | 526 / | | 527 (I) // /+---------------+ 528 / // 529 / / (II) 530 // // Access Token 531 / / +[ephemeral 532 // // asymmetric key pair] 533 / v 534 +-----------+ +------------+ 535 | | | | 536 | | | Resource | 537 | Client | | Server | 538 | | | | 539 | | | | 540 +-----------+ +------------+ 542 Figure 2: Interaction between the Client and the Authorization Server 543 (Asymmetric Keys). 545 The use of asymmetric keys is slightly different since the client or 546 the server could be involved in the generation of the ephemeral key 547 pair. This exchange is shown in Figure 1. If the client generates 548 the key pair it either includes a fingerprint of the public key or 549 the public key in the request to the authorization server. The 550 authorization server would include this fingerprint or public key in 551 the confirmation claim inside the access token and thereby bind the 552 asymmetric key pair to the token. If the client did not provide a 553 fingerprint or a public key in the request then the authorization 554 server is asked to create an ephemeral asymmetric key pair, binds the 555 fingerprint of the public key to the access token, and returns the 556 asymmetric key pair (public and private key) to the client. Note 557 that there is a strong preference for generating the private/public 558 key pair locally at the client rather than at the server. 560 The specification describing the interaction between the client and 561 the authorization server, as shown in Figure 1 and in Figure 2, can 562 be found in [I-D.ietf-oauth-pop-key-distribution]. 564 Once the client has obtained the necessary access token and keying 565 material it can start to interact with the resource server. To 566 demonstrate possession of the key bound to the access token it needs 567 to apply this key to the request by computing a keyed message digest 568 (i.e., a symmetric key-based cryptographic primitive) or a digital 569 signature (i.e., an asymmetric cryptographic computation). When the 570 resource server receives the request it verifies it and decides 571 whether access to the protected resource can be granted. This 572 exchange is shown in Figure 3. 574 +---------------+ 575 | | 576 | Authorization | 577 | Server | 578 | | 579 | | 580 +---------------+ 582 Request 583 +-----------+ + Signature/MAC (a) +------------+ 584 | |---------------------->| | 585 | | [+Access Token] | Resource | 586 | Client | | Server | 587 | | Response (b) | | 588 | |<----------------------| | 589 +-----------+ [+ Signature/MAC] +------------+ 591 ^ ^ 592 | | 593 | | 594 Symmetric Key Symmetric Key 595 or or 596 Asymmetric Key Pair Public Key (Client) 597 + + 598 Parameters Parameters 600 Figure 3: Client demonstrates PoP. 602 The specification describing the ability to sign the HTTP request 603 from the client to the resource server can be found in 604 [I-D.ietf-oauth-signed-http-request]. 606 So far the examples talked about access tokens that are passed by 607 value and allow the resource server to make authorization decisions 608 immediately after verifying the request from the client. In some 609 deployments a real-time interaction between the authorization server 610 and the resource server is envisioned that lowers the need to pass 611 self-contained access tokens around. In that case the access token 612 merely serves as a handle or a reference to state stored at the 613 authorization server. As a consequence, the resource server cannot 614 autonomously make an authorization decision when receiving a request 615 from a client but has to consult the authorization server. This can, 616 for example, be done using the token introspection endpoint (see 617 [I-D.ietf-oauth-introspection]). Figure 4 shows the protocol 618 interaction graphically. Despite the additional token exchange 619 previous descriptions about associating symmetric and asymmetric keys 620 to the access token are still applicable to this scenario. 622 +---------------+ 623 Access ^| | 624 Token Req. // | Authorization |^ 625 (I) / | Server | \ (IV) Token 626 // | | \ Introspection Req. 627 / | | \ +Access 628 // /+---------------+ \ Token 629 / // (II) \ \\ 630 / / Access \ \ 631 // // Token \ (V) \ 632 / / \Resp.\ 633 // // \ \ 634 / v V \ 635 +-----------+ Request +Signature/MAC+------------+ 636 | | (III) +Access Token | | 637 | |---------------------->| Resource | 638 | Client | (VI) Success or | Server | 639 | | Failure | | 640 | |<----------------------| | 641 +-----------+ +------------+ 643 Figure 4: Token Introspection and Access Token Handles. 645 7. Requirements 647 RFC 4962 [RFC4962] gives useful guidelines for designers of 648 authentication and key management protocols. While RFC 4962 was 649 written with the AAA framework used for network access authentication 650 in mind the offered suggestions are useful for the design of other 651 key management systems as well. The following requirements list 652 applies OAuth 2.0 terminology to the requirements outlined in RFC 653 4962. 655 These requirements include 657 Cryptographic Algorithm Independent: 659 The key management protocol MUST be cryptographic algorithm 660 independent. 662 Strong, fresh session keys: 664 Session keys MUST be strong and fresh. Each session deserves an 665 independent session key, i.e., one that is generated specifically 666 for the intended use. In context of OAuth this means that keying 667 material is created in such a way that can only be used by the 668 combination of a client instance, protected resource, and 669 authorization scope. 671 Limit Key Scope: 673 Following the principle of least privilege, parties MUST NOT have 674 access to keying material that is not needed to perform their 675 role. Any protocol that is used to establish session keys MUST 676 specify the scope for session keys, clearly identifying the 677 parties to whom the session key is available. 679 Replay Detection Mechanism: 681 The key management protocol exchanges MUST be replay protected. 682 Replay protection allows a protocol message recipient to discard 683 any message that was recorded during a previous legitimate 684 dialogue and presented as though it belonged to the current 685 dialogue. 687 Authenticate All Parties: 689 Each party in the key management protocol MUST be authenticated to 690 the other parties with whom they communicate. Authentication 691 mechanisms MUST maintain the confidentiality of any secret values 692 used in the authentication process. Secrets MUST NOT be sent to 693 another party without confidentiality protection. 695 Authorization: 697 Client and resource server authorization MUST be performed. These 698 entities MUST demonstrate possession of the appropriate keying 699 material, without disclosing it. Authorization is REQUIRED 700 whenever a client interacts with an authorization server. The 701 authorization checking prevents an elevation of privilege attack, 702 and it ensures that an unauthorized authorized is detected. 704 Keying Material Confidentiality and Integrity: 706 While preserving algorithm independence, confidentiality and 707 integrity of all keying material MUST be maintained. 709 Confirm Cryptographic Algorithm Selection: 711 The selection of the "best" cryptographic algorithms SHOULD be 712 securely confirmed. The mechanism SHOULD detect attempted roll- 713 back attacks. 715 Uniquely Named Keys: 717 Key management proposals require a robust key naming scheme, 718 particularly where key caching is supported. The key name 719 provides a way to refer to a key in a protocol so that it is clear 720 to all parties which key is being referenced. Objects that cannot 721 be named cannot be managed. All keys MUST be uniquely named, and 722 the key name MUST NOT directly or indirectly disclose the keying 723 material. 725 Prevent the Domino Effect: 727 Compromise of a single client MUST NOT compromise keying material 728 held by any other client within the system, including session keys 729 and long-term keys. Likewise, compromise of a single resource 730 server MUST NOT compromise keying material held by any other 731 Resource Server within the system. In the context of a key 732 hierarchy, this means that the compromise of one node in the key 733 hierarchy must not disclose the information necessary to 734 compromise other branches in the key hierarchy. Obviously, the 735 compromise of the root of the key hierarchy will compromise all of 736 the keys; however, a compromise in one branch MUST NOT result in 737 the compromise of other branches. There are many implications of 738 this requirement; however, two implications deserve highlighting. 739 First, the scope of the keying material must be defined and 740 understood by all parties that communicate with a party that holds 741 that keying material. Second, a party that holds keying material 742 in a key hierarchy must not share that keying material with 743 parties that are associated with other branches in the key 744 hierarchy. 746 Bind Key to its Context: 748 Keying material MUST be bound to the appropriate context. The 749 context includes the following. 751 * The manner in which the keying material is expected to be used. 753 * The other parties that are expected to have access to the 754 keying material. 756 * The expected lifetime of the keying material. Lifetime of a 757 child key SHOULD NOT be greater than the lifetime of its parent 758 in the key hierarchy. 760 Any party with legitimate access to keying material can determine 761 its context. In addition, the protocol MUST ensure that all 762 parties with legitimate access to keying material have the same 763 context for the keying material. This requires that the parties 764 are properly identified and authenticated, so that all of the 765 parties that have access to the keying material can be determined. 766 The context will include the client and the resource server 767 identities in more than one form. 769 Authorization Restriction: 771 If client authorization is restricted, then the client SHOULD be 772 made aware of the restriction. 774 Client Identity Confidentiality: 776 A client has identity confidentiality when any party other than 777 the resource server and the authorization server cannot 778 sufficiently identify the client within the anonymity set. In 779 comparison to anonymity and pseudonymity, identity confidentiality 780 is concerned with eavesdroppers and intermediaries. A key 781 management protocol SHOULD provide this property. 783 Resource Owner Identity Confidentiality: 785 Resource servers SHOULD be prevented from knowing the real or 786 pseudonymous identity of the resource owner, since the 787 authorization server is the only entity involved in verifying the 788 resource owner's identity. 790 Collusion: 792 Resource servers that collude can be prevented from using 793 information related to the resource owner to track the individual. 794 That is, two different resource servers can be prevented from 795 determining that the same resource owner has authenticated to both 796 of them. Authorization servers MUST bind different keying 797 material to access tokens used for resource servers from different 798 origins (or similar concepts in the app world). 800 AS-to-RS Relationship Anonymity: 802 For solutions using asymmetric key cryptography the client MAY 803 conceal information about the resource server it wants to interact 804 with. The authorization server MAY reject such an attempt since 805 it may not be able to enforce access control decisions. 807 Channel Binding: 809 A solution MUST enable support for channel bindings. The concept 810 of channel binding, as defined in [RFC5056], allows applications 811 to establish that the two end-points of a secure channel at one 812 network layer are the same as at a higher layer by binding 813 authentication at the higher layer to the channel at the lower 814 layer. 816 There are performance concerns with the use of asymmetric 817 cryptography. Although symmetric key cryptography offers better 818 performance asymmetric cryptography offers additional security 819 properties. A solution MUST therefore offer the capability to 820 support both symmetric as well as asymmetric keys. 822 There are threats that relate to the experience of the software 823 developer as well as operational practices. Verifying the servers 824 identity in TLS is discussed at length in [RFC6125]. 826 A number of the threats listed in Section 4 demand protection of the 827 access token content and a standardized solution, in form of a JSON- 828 based format, is available with the JWT 829 [I-D.ietf-oauth-json-web-token]. 831 8. Security Considerations 833 The purpose of this document is to provide use cases, requirements, 834 and motivation for developing an OAuth security solution extending 835 Bearer Tokens. As such, this document is only about security. 837 9. IANA Considerations 839 This document does not require actions by IANA. 841 10. Acknowledgments 843 This document is the result of conference calls late 2012/early 2013 844 and in design team conference calls February 2013 of the IETF OAuth 845 working group. The following persons (in addition to the OAuth WG 846 chairs, Hannes Tschofenig, and Derek Atkins) provided their input 847 during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek 848 Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John 849 Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian 850 Campbell 852 In the appendix of this document we re-use content from [RFC4962] and 853 the authors would like thank Russ Housely and Bernard Aboba for their 854 work on RFC 4962. 856 We would like to thank Reddy Tirumaleswar for his review. 858 11. References 860 11.1. Normative References 862 [I-D.ietf-httpbis-p1-messaging] 863 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 864 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 865 httpbis-p1-messaging-26 (work in progress), February 2014. 867 [I-D.ietf-jose-json-web-encryption] 868 Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 869 draft-ietf-jose-json-web-encryption-40 (work in progress), 870 January 2015. 872 [I-D.ietf-oauth-introspection] 873 ietf@justin.richer.org, i., "OAuth 2.0 Token 874 Introspection", draft-ietf-oauth-introspection-05 (work in 875 progress), February 2015. 877 [I-D.ietf-oauth-json-web-token] 878 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 879 (JWT)", draft-ietf-oauth-json-web-token-32 (work in 880 progress), December 2014. 882 [I-D.ietf-oauth-pop-key-distribution] 883 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 884 "OAuth 2.0 Proof-of-Possession: Authorization Server to 885 Client Key Distribution", draft-ietf-oauth-pop-key- 886 distribution-00 (work in progress), July 2014. 888 [I-D.ietf-oauth-proof-of-possession] 889 Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- 890 Possession Semantics for JSON Web Tokens (JWTs)", draft- 891 ietf-oauth-proof-of-possession-01 (work in progress), 892 January 2015. 894 [I-D.ietf-oauth-signed-http-request] 895 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 896 Signing an HTTP Requests for OAuth", draft-ietf-oauth- 897 signed-http-request-00 (work in progress), July 2014. 899 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 900 Extensions (MIME) Part One: Format of Internet Message 901 Bodies", RFC 2045, November 1996. 903 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 904 Hashing for Message Authentication", RFC 2104, February 905 1997. 907 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 908 Requirement Levels", BCP 14, RFC 2119, March 1997. 910 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 911 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 912 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 914 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 915 Leach, P., Luotonen, A., and L. Stewart, "HTTP 916 Authentication: Basic and Digest Access Authentication", 917 RFC 2617, June 1999. 919 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 920 Resource Identifier (URI): Generic Syntax", STD 66, RFC 921 3986, January 2005. 923 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 924 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 925 May 2008. 927 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 928 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 930 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 931 April 2011. 933 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 934 6749, October 2012. 936 [W3C.REC-html401-19991224] 937 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 938 Specification", World Wide Web Consortium Recommendation 939 REC-html401-19991224, December 1999, 940 . 942 11.2. Informative References 944 [I-D.hardjono-oauth-kerberos] 945 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 946 Authentication Protocol", draft-hardjono-oauth-kerberos-01 947 (work in progress), December 2010. 949 [NIST-FIPS-180-3] 950 National Institute of Standards and Technology, "Secure 951 Hash Standard (SHS). FIPS PUB 180-3, October 2008", 952 October 2008. 954 [NIST800-63] 955 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 956 and E. Nabbus, "NIST Special Publication 800-63-1, 957 INFORMATION SECURITY", December 2008. 959 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 960 Requirements for Security", BCP 106, RFC 4086, June 2005. 962 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 963 Kerberos Network Authentication Service (V5)", RFC 4120, 964 July 2005. 966 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 967 for Transport Layer Security (TLS)", RFC 4279, December 968 2005. 970 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 971 Authorization, and Accounting (AAA) Key Management", BCP 972 132, RFC 4962, July 2007. 974 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 975 Channels", RFC 5056, November 2007. 977 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 978 April 2010. 980 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 981 for TLS", RFC 5929, July 2010. 983 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 984 Verification of Domain-Based Application Service Identity 985 within Internet Public Key Infrastructure Using X.509 986 (PKIX) Certificates in the Context of Transport Layer 987 Security (TLS)", RFC 6125, March 2011. 989 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 990 Framework: Bearer Token Usage", RFC 6750, October 2012. 992 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 993 Threat Model and Security Considerations", RFC 6819, 994 January 2013. 996 Authors' Addresses 998 Phil Hunt (editor) 999 Oracle Corporation 1001 Email: phil.hunt@yahoo.com 1003 Justin Richer 1005 Email: ietf@justin.richer.org 1007 William Mills 1009 Email: wmills@yahoo-inc.com 1011 Prateek Mishra 1012 Oracle Corporation 1014 Email: prateek.mishra@oracle.com 1015 Hannes Tschofenig 1016 ARM Limited 1017 Hall in Tirol 6060 1018 Austria 1020 Email: Hannes.Tschofenig@gmx.net 1021 URI: http://www.tschofenig.priv.at