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