idnits 2.17.1 draft-hunt-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 (April 25, 2014) is 3647 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 820, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-jose-json-web-encryption' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'I-D.tschofenig-oauth-audience' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'NIST-FIPS-180-3' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC5929' is defined on line 940, 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-25 == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-19 == 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: October 27, 2014 The MITRE Corporation 6 W. Mills 7 Yahoo! Inc. 8 P. Mishra 9 Oracle Corporation 10 H. Tschofenig 11 ARM Limited 12 April 25, 2014 14 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture 15 draft-hunt-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 October 27, 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. Access to an 'Unprotected' Resource . . . . . . . . . . . 3 68 3.2. Offering Application Layer End-to-End Security . . . . . 4 69 3.3. Preventing Access Token Re-Use by the Resource Server . . 4 70 3.4. TLS Channel Binding Support . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 84 11.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 At the time of writing the OAuth 2.0 protocol family ([RFC6749], 90 [RFC6750], and [RFC6819]) offer a single standardized security 91 mechanism to access protected resources, namely the bearer token. 92 RFC 6750 [RFC6750] specifies the bearer token mechanism and defines 93 it as follows: 95 "A security token with the property that any party in possession 96 of the token (a "bearer") can use the token in any way that any 97 other party in possession of it can. Using a bearer token does 98 not require a bearer to prove possession of cryptographic key 99 material." 101 The bearer token meets the security needs of a number of use cases 102 the OAuth 2.0 protocol had originally been designed for. There are, 103 however, other scenarios that require stronger security properties 104 and ask for active participation of the OAuth client in form of 105 cryptographic computations when presenting an access token to a 106 resource server. 108 This document outlines additional use cases requiring stronger 109 security protection in Section 3, identifies threats in Section 4, 110 proposes different ways to mitigate those threats in Section 5, 111 outlines an architecture for a solution that builds on top of the 112 existing OAuth 2.0 framework in Section 6, and concludes with a 113 requirements list in Section 7. 115 2. Terminology 117 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 118 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 119 specification are to be interpreted as described in [RFC2119], with 120 the important qualification that, unless otherwise stated, these 121 terms apply to the design of the protocol, not its implementation or 122 application. 124 3. Use Cases 126 The main use case that motivates better-than-bearer token security is 127 the desire of resource servers to obtain additional assurance that 128 the client is indeed authorized to present this 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 or storing the access token 132 in combination with these credentials. 134 Additional use cases listed below provide further requirements for 135 the solution development. 137 3.1. Access to an 'Unprotected' Resource 139 This use case is for a web client that needs to access a resource 140 that makes data available (such as videos) without offering integrity 141 and confidentiality protection using TLS. Still, the initial 142 resource request using OAuth, which includes the access token, must 143 be protected against various threats (e.g., token replay, token 144 modification). 146 While it is possible to utilize bearer tokens in this scenario with 147 TLS protection when the request to the protected resource is made, as 148 described in [RFC6750], there may be the desire to avoid using TLS 149 between the client and the resource server at all. In such a case 150 the bearer token approach is not possible since it relies on TLS for 151 ensuring integrity and confidentiality protection of the access token 152 exchange since otherwise replay attacks are possible: First, an 153 eavesdropper may steal an access token and represent it at a 154 different resource server. Second, an eavesdropper may steal an 155 access token and replay it against the same resource server at a 156 later point in time. In both cases, if the attack is successful, the 157 adversary gets access to the resource owners data or may perform an 158 operation selected by the adversary (e.g., sending a message). Note 159 that the adversary may obtain the access token (if the 160 recommendations in [RFC6749] and [RFC6750] are not followed) using a 161 number of ways, including eavesdropping the communication on the 162 wireless link. 164 Consequently, the important assumption in this use case is that a 165 resource server does not have TLS support and the security solution 166 should work in such a scenario. Furthermore, it may not be necessary 167 to provide authentication of the resource server towards the client. 169 3.2. Offering Application Layer End-to-End Security 171 In Web deployments resource servers are often placed behind load 172 balancers, which are deployed by the same organization that operates 173 the resource servers. These load balancers may terminate the TLS 174 connection setup and HTTP traffic is transmitted in the clear from 175 the load balancer to the resource server. With application layer 176 security independent of the underlying TLS security it is possible to 177 allow application servers to perform cryptographic verification on an 178 end-to-end basis. 180 The key aspect in this use case is therefore to offer end-to-end 181 security in the presence of load balancers via application layer 182 security. 184 3.3. Preventing Access Token Re-Use by the Resource Server 186 Imagine a scenario where a resource server that receives a valid 187 access token re-uses it with other resource server. The reason for 188 re-use may be malicious or may well be legitimate. In a legitimate 189 use case consider chaining of computations whereby a resource server 190 needs to consult other third party resource servers to complete the 191 requested operation. In both cases it may be assumed that the scope 192 of the access token is sufficiently large that it allows such a re- 193 use. For example, imagine a case where a company operates email 194 services as well as picture sharing services and that company had 195 decided to issue access tokens with a scope that allows access to 196 both services. 198 With this use case the desire is to prevent such access token re-use. 199 This also implies that the legitimate use cases require additional 200 enhancements for request chaining. 202 3.4. TLS Channel Binding Support 204 In this use case we consider the scenario where an OAuth 2.0 request 205 to a protected resource is secured using TLS but the client and the 206 resource server demand that the underlying TLS exchange is bound to 207 additional application layer security to prevent cases where the TLS 208 connection is terminated at a TLS intermediary, which splits the TLS 209 connection into two separate connections. 211 In this use case additional information is conveyed to the resource 212 server to ensure that no entity entity has tampered with the TLS 213 connection. 215 4. Security and Privacy Threats 217 The following list presents several common threats against protocols 218 utilizing some form of tokens. This list of threats is based on NIST 219 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 220 threats related to any form of identity proofing and authentication 221 of the resource owner to the authorization server since these 222 procedures are not part of the OAuth 2.0 protocol specification 223 itself. 225 Token manufacture/modification: 227 An attacker may generate a bogus tokens or modify the token 228 content (such as authentication or attribute statements) of an 229 existing token, causing resource server to grant inappropriate 230 access to the client. For example, an attacker may modify the 231 token to extend the validity period. A client may modify the 232 token to have access to information that they should not be able 233 to view. 235 Token disclosure: Tokens may contain personal data, such as real 236 name, age or birthday, payment information, etc. 238 Token redirect: 240 An attacker uses the token generated for consumption by the 241 resource server to obtain access to another resource server. 243 Token reuse: 245 An attacker attempts to use a token that has already been used 246 once with a resource server. The attacker may be an eavesdropper 247 who observes the communication exchange or, worse, one of the 248 communication end points. A client may, for example, leak access 249 tokens because it cannot keep secrets confidential. A client may 250 also re-use access tokens for some other resource servers. 251 Finally, a resource server may use a token it had obtained from a 252 client and use it with another resource server that the client 253 interacts with. A resource server, offering relatively 254 unimportant application services, may attempt to use an access 255 token obtained from a client to access a high-value service, such 256 as a payment service, on behalf of the client using the same 257 access token. 259 We excluded one threat from the list, namely 'token repudiation'. 260 Token repudiation refers to a property whereby a resource server is 261 given an assurance that the authorization server cannot deny to have 262 created a token for the Client. We believe that such a property is 263 interesting but most deployments prefer to deal with the violation of 264 this security property through business actions rather than by using 265 cryptography. 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, Authorization Server must encode the identifier of 424 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. 455 With the JSON Web Token (JWT) a standardized format for access tokens 456 is available. The necessary elements to bind symmetric or asymmetric 457 keys to the JWT is described in 458 [I-D.jones-oauth-proof-of-possession]. 460 +---------------+ 461 ^| | 462 // | Authorization | 463 / | Server | 464 // | | 465 / | | 466 (I) // /+---------------+ 467 Access / // 468 Token / / 469 Request // // (II) Access Token 470 +Params / / +Symmetric Key 471 // // 472 / v 473 +-----------+ +------------+ 474 | | | | 475 | | | Resource | 476 | Client | | Server | 477 | | | | 478 | | | | 479 +-----------+ +------------+ 481 Figure 1: Interaction between the Client and the Authorization Server 482 (Symmetric Keys). 484 In order to request an access token the client interacts with the 485 authorization server as part of the a normal grant exchange, as shown 486 in Figure 1. However, it needs to include additional information 487 elements for use with the PoP security mechanism, as depicted in 488 message (I). In message (II) the authorization server then returns 489 the requested access token. In addition to the access token itself, 490 the symmetric key is communicated to the client. This symmetric key 491 is a unique and fresh session key with sufficient entropy for the 492 given lifetime. Furthermore, information within the access token 493 ties it to this specific symmetric key. 495 Note: For this security mechanism to work the client as well as the 496 resource server need to have access to the session key. While the 497 key transport mechanism from the authorization server to the client 498 has been explained in the previous paragraph there are three ways for 499 communicating this session key from the authorization server to the 500 resource server, namely 502 Embedding the symmetric key inside the access token itself. This 503 requires that the symmetric key is confidentiality protected. 505 The resource server queries the authorization server for the 506 symmetric key. This is an approach envisioned by the token 507 introspection endpoint [I-D.richer-oauth-introspection]. 509 The authorization server and the resource server both have access 510 to the same back-end database. This is case in smaller, tightly 511 coupled systems. 513 +---------------+ 514 ^| | 515 Access Token Req. // | Authorization | 516 +Parameters / | Server | 517 +[Fingerprint] // | | 518 / | | 519 (I) // /+---------------+ 520 / // 521 / / (II) 522 // // Access Token 523 / / +[ephemeral 524 // // asymmetric key pair] 525 / v 526 +-----------+ +------------+ 527 | | | | 528 | | | Resource | 529 | Client | | Server | 530 | | | | 531 | | | | 532 +-----------+ +------------+ 534 Figure 2: Interaction between the Client and the Authorization Server 535 (Asymmetric Keys). 537 The use of asymmetric keys is slightly different since the client or 538 the server could be involved in the generation of the ephemeral key 539 pair. This exchange is shown in Figure 1. If the client generates 540 the key pair it includes a fingerprint of the public key (of the 541 SubjectPublicKeyInfo structure, more precisely). The authorization 542 server would include this fingerprint in the access token and thereby 543 bind the asymmetric key pair to the token. If the client did not 544 provide a fingerprint in the request then the authorization server is 545 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 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 HTTP request by computing a keyed message 557 digest (i.e., a symmetric key-based cryptographic primitive) or a 558 digital signature (i.e., an asymmetric cryptographic primitive). 559 When the resource server receives the request it verifies it and 560 decides whether access to the protected resource can be granted. 561 This exchange is shown in Figure 3. 563 +---------------+ 564 | | 565 | Authorization | 566 | Server | 567 | | 568 | | 569 +---------------+ 571 HTTP Request 572 +-----------+ + Signature/MAC (a) +------------+ 573 | |---------------------->| | 574 | | [+Access Token] | Resource | 575 | Client | | Server | 576 | | HTTP 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 [Editor's Note: Description about token introspection needs to be 596 added as well. 598 7. Requirements 600 RFC 4962 [RFC4962] gives useful guidelines for designers of 601 authentication and key management protocols. While RFC 4962 was 602 written with the AAA framework used for network access authentication 603 in mind the offered suggestions are useful for the design of other 604 key management systems as well. The following requirements list 605 applies OAuth 2.0 terminology to the requirements outlined in RFC 606 4962. 608 These requirements include 610 Cryptographic Algorithm Independent: 612 The key management protocol MUST be cryptographic algorithm 613 independent. 615 Strong, fresh session keys: 617 Session keys MUST be strong and fresh. Each session deserves an 618 independent session key, i.e., one that is generated specifically 619 for the intended use. In context of OAuth this means that keying 620 material is created in such a way that can only be used by the 621 combination of a Client instance, protected resource, and 622 authorization scope. 624 Limit Key Scope: 626 Following the principle of least privilege, parties MUST NOT have 627 access to keying material that is not needed to perform their 628 role. Any protocol that is used to establish session keys MUST 629 specify the scope for session keys, clearly identifying the 630 parties to whom the session key is available. 632 Replay Detection Mechanism: 634 The key management protocol exchanges MUST be replay protected. 635 Replay protection allows a protocol message recipient to discard 636 any message that was recorded during a previous legitimate 637 dialogue and presented as though it belonged to the current 638 dialogue. 640 Authenticate All Parties: 642 Each party in the key management protocol MUST be authenticated to 643 the other parties with whom they communicate. Authentication 644 mechanisms MUST maintain the confidentiality of any secret values 645 used in the authentication process. Secrets MUST NOT be sent to 646 another party without confidentiality protection. 648 Authorization: 650 Client and Resource Server authorization MUST be performed. These 651 entities MUST demonstrate possession of the appropriate keying 652 material, without disclosing it. Authorization is REQUIRED 653 whenever a Client interacts with an Authorization Server. The 654 authorization checking prevents an elevation of privilege attack, 655 and it ensures that an unauthorized authorized is detected. 657 Keying Material Confidentiality and Integrity: 659 While preserving algorithm independence, confidentiality and 660 integrity of all keying material MUST be maintained. 662 Confirm Cryptographic Algorithm Selection: 664 The selection of the "best" cryptographic algorithms SHOULD be 665 securely confirmed. The mechanism SHOULD detect attempted roll- 666 back attacks. 668 Uniquely Named Keys: 670 Key management proposals require a robust key naming scheme, 671 particularly where key caching is supported. The key name 672 provides a way to refer to a key in a protocol so that it is clear 673 to all parties which key is being referenced. Objects that cannot 674 be named cannot be managed. All keys MUST be uniquely named, and 675 the key name MUST NOT directly or indirectly disclose the keying 676 material. 678 Prevent the Domino Effect: 680 Compromise of a single Client MUST NOT compromise keying material 681 held by any other Client within the system, including session keys 682 and long-term keys. Likewise, compromise of a single Resource 683 Server MUST NOT compromise keying material held by any other 684 Resource Server within the system. In the context of a key 685 hierarchy, this means that the compromise of one node in the key 686 hierarchy must not disclose the information necessary to 687 compromise other branches in the key hierarchy. Obviously, the 688 compromise of the root of the key hierarchy will compromise all of 689 the keys; however, a compromise in one branch MUST NOT result in 690 the compromise of other branches. There are many implications of 691 this requirement; however, two implications deserve highlighting. 692 First, the scope of the keying material must be defined and 693 understood by all parties that communicate with a party that holds 694 that keying material. Second, a party that holds keying material 695 in a key hierarchy must not share that keying material with 696 parties that are associated with other branches in the key 697 hierarchy. 699 Bind Key to its Context: 701 Keying material MUST be bound to the appropriate context. The 702 context includes the following. 704 * The manner in which the keying material is expected to be used. 706 * The other parties that are expected to have access to the 707 keying material. 709 * The expected lifetime of the keying material. Lifetime of a 710 child key SHOULD NOT be greater than the lifetime of its parent 711 in the key hierarchy. 713 Any party with legitimate access to keying material can determine 714 its context. In addition, the protocol MUST ensure that all 715 parties with legitimate access to keying material have the same 716 context for the keying material. This requires that the parties 717 are properly identified and authenticated, so that all of the 718 parties that have access to the keying material can be determined. 719 The context will include the Client and the Resource Server 720 identities in more than one form. 722 Authorization Restriction: 724 If Client authorization is restricted, then the Client SHOULD be 725 made aware of the restriction. 727 Client Identity Confidentiality: 729 A Client has identity confidentiality when any party other than 730 the Resource Server and the Authorization Server cannot 731 sufficiently identify the Client within the anonymity set. In 732 comparison to anonymity and pseudonymity, identity confidentiality 733 is concerned with eavesdroppers and intermediaries. A key 734 management protocol SHOULD provide this property. 736 Resource Owner Identity Confidentiality: 738 Resource servers SHOULD be prevented from knowing the real or 739 pseudonymous identity of the Resource Owner, since the 740 Authorization Server is the only entity involved in verifying the 741 Resource Owner's identity. 743 Collusion: 745 Resource Servers that collude can be prevented from using 746 information related to the Resource Owner to track the individual. 747 That is, two different Resource Servers can be prevented from 748 determining that the same Resource Owner has authenticated to both 749 of them. This requires that each Authorization Server obtains 750 different keying material as well as different access tokens with 751 content that does not allow identification of the Resource Owner. 753 AS-to-RS Relationship Anonymity: 755 This MAC Token security does not provide AAS-to-RS Relationship 756 Anonymity since the Client has to inform the resource server about 757 the Resource Server it wants to talk to. The Authorization Server 758 needs to know how to encrypt the session key the Client and the 759 Resource Server will be using. 761 As an additional requirement a solution MUST enable support for 762 channel bindings. The concept of channel binding, as defined in 763 [RFC5056], allows applications to establish that the two end-points 764 of a secure channel at one network layer are the same as at a higher 765 layer by binding authentication at the higher layer to the channel at 766 the lower layer. 768 There are performance concerns with the use of asymmetric 769 cryptography. Although symmetric key cryptography offers better 770 performance asymmetric cryptography offers additional security 771 properties. A solution MUST therefore offer the capability to 772 support both symmetric as well as asymmetric keys. 774 There are threats that relate to the experience of the software 775 developer as well as operational practices. Verifying the servers 776 identity in TLS is discussed at length in [RFC6125]. 778 A number of the threats listed in Section 4 demand protection of the 779 access token content and a standardized solution, in form of a JSON- 780 based format, is available with the JSON Web Token (JWT) 781 [I-D.ietf-oauth-json-web-token]. Hence, threat related to the 782 protection of the access token itself are deferred to the 783 [I-D.ietf-oauth-json-web-token]. 785 8. Security Considerations 787 The purpose of this document is to provide use cases, requirements, 788 and motivation for developing an OAuth security solution extending 789 Bearer Tokens. As such, this document is only about security. 791 9. IANA Considerations 793 This document does not require actions by IANA. 795 10. Acknowledgments 797 This document is the result of conference calls late 2012/early 2013 798 and in design team conference calls February 2013 of the IETF OAuth 799 working group. The following persons (in addition to the OAuth WG 800 chairs, Hannes Tschofenig, and Derek Atkins) provided their input 801 during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek 802 Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John 803 Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian 804 Campbell 806 In the appendix of this document we re-use content from [RFC4962] and 807 the authors would like thank Russ Housely and Bernard Aboba for their 808 work on RFC 4962. 810 11. References 812 11.1. Normative References 814 [I-D.bradley-oauth-pop-key-distribution] 815 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 816 "OAuth 2.0 Proof-of-Possession: Authorization Server to 817 Client Key Distribution", draft-bradley-oauth-pop-key- 818 distribution-00 (work in progress), April 2014. 820 [I-D.ietf-httpbis-p1-messaging] 821 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 822 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 823 httpbis-p1-messaging-26 (work in progress), February 2014. 825 [I-D.ietf-jose-json-web-encryption] 826 Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 827 draft-ietf-jose-json-web-encryption-25 (work in progress), 828 March 2014. 830 [I-D.ietf-oauth-json-web-token] 831 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 832 (JWT)", draft-ietf-oauth-json-web-token-19 (work in 833 progress), March 2014. 835 [I-D.jones-oauth-proof-of-possession] 836 Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- 837 Possession Semantics for JSON Web Tokens (JWTs)", draft- 838 jones-oauth-proof-of-possession-00 (work in progress), 839 April 2014. 841 [I-D.richer-oauth-introspection] 842 Richer, J., "OAuth Token Introspection", draft-richer- 843 oauth-introspection-04 (work in progress), May 2013. 845 [I-D.richer-oauth-introspection] 846 Richer, J., "OAuth Token Introspection", draft-richer- 847 oauth-introspection-04 (work in progress), May 2013. 849 [I-D.richer-oauth-signed-http-request] 850 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 851 Signing an HTTP Requests for OAuth", draft-richer-oauth- 852 signed-http-request-01 (work in progress), April 2014. 854 [I-D.tschofenig-oauth-audience] 855 Tschofenig, H., "OAuth 2.0: Audience Information", draft- 856 tschofenig-oauth-audience-00 (work in progress), February 857 2013. 859 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 860 Extensions (MIME) Part One: Format of Internet Message 861 Bodies", RFC 2045, November 1996. 863 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 864 Hashing for Message Authentication", RFC 2104, February 865 1997. 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, March 1997. 870 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 871 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 872 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 874 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 875 Leach, P., Luotonen, A., and L. Stewart, "HTTP 876 Authentication: Basic and Digest Access Authentication", 877 RFC 2617, June 1999. 879 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 880 Resource Identifier (URI): Generic Syntax", STD 66, RFC 881 3986, January 2005. 883 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 884 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 885 May 2008. 887 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 888 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 890 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 891 April 2011. 893 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 894 6749, October 2012. 896 [W3C.REC-html401-19991224] 897 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 898 Specification", World Wide Web Consortium Recommendation 899 REC-html401-19991224, December 1999, 900 . 902 11.2. Informative References 904 [I-D.hardjono-oauth-kerberos] 905 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 906 Authentication Protocol", draft-hardjono-oauth-kerberos-01 907 (work in progress), December 2010. 909 [NIST-FIPS-180-3] 910 National Institute of Standards and Technology, "Secure 911 Hash Standard (SHS). FIPS PUB 180-3, October 2008", 912 October 2008. 914 [NIST800-63] 915 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 916 and E. Nabbus, "NIST Special Publication 800-63-1, 917 INFORMATION SECURITY", December 2008. 919 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 920 Requirements for Security", BCP 106, RFC 4086, June 2005. 922 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 923 Kerberos Network Authentication Service (V5)", RFC 4120, 924 July 2005. 926 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 927 for Transport Layer Security (TLS)", RFC 4279, December 928 2005. 930 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 931 Authorization, and Accounting (AAA) Key Management", BCP 932 132, RFC 4962, July 2007. 934 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 935 Channels", RFC 5056, November 2007. 937 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 938 April 2010. 940 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 941 for TLS", RFC 5929, July 2010. 943 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 944 Verification of Domain-Based Application Service Identity 945 within Internet Public Key Infrastructure Using X.509 946 (PKIX) Certificates in the Context of Transport Layer 947 Security (TLS)", RFC 6125, March 2011. 949 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 950 Framework: Bearer Token Usage", RFC 6750, October 2012. 952 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 953 Threat Model and Security Considerations", RFC 6819, 954 January 2013. 956 Authors' Addresses 958 Phil Hunt (editor) 959 Oracle Corporation 961 Email: phil.hunt@yahoo.com 963 Justin Richer 964 The MITRE Corporation 966 Email: jricher@mitre.org 968 William Mills 969 Yahoo! Inc. 971 Email: wmills@yahoo-inc.com 972 Prateek Mishra 973 Oracle Corporation 975 Email: prateek.mishra@oracle.com 977 Hannes Tschofenig 978 ARM Limited 979 Austria 981 Email: Hannes.Tschofenig@gmx.net 982 URI: http://www.tschofenig.priv.at