idnits 2.17.1 draft-tschofenig-oauth-security-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 == Line 157 has weird spacing: '...such as authe...' == Line 379 has weird spacing: '...tegrity and...' -- The document date (December 16, 2012) is 4120 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hardjono-oauth-kerberos' is defined on line 789, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-05 == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-03 -- Obsolete informational reference (is this intentional?): 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) == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-02 == Outdated reference: A later version (-03) exists of draft-tschofenig-oauth-hotk-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational P. Hunt 5 Expires: June 19, 2013 Oracle Corporation 6 December 16, 2012 8 OAuth 2.0 Security: Going Beyond Bearer Tokens 9 draft-tschofenig-oauth-security-01.txt 11 Abstract 13 The OAuth working group has finished work on the OAuth 2.0 core 14 protocol as well as the Bearer Token specification. The Bearer Token 15 is a TLS-based solution for ensuring that neither the interaction 16 with the Authorization Server (when requesting a token) nor the 17 interaction with the Resource Server (for accessing a protected 18 resource) leads to token leakage. There has, however, always been 19 the desire to develop a security solution that is "better" than 20 Bearer Tokens (or at least different) where the Client needs to show 21 possession of some keying material when accessing a Resource Server. 22 This document tries to capture the discussion and to come up with 23 requirements to process the work on solutions. 25 This document aims to discuss threats, security requirements and 26 desired design properties of an enhanced OAuth security mechanism. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 19, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Security and Privacy Threats . . . . . . . . . . . . . . . . . 3 65 4. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Confidentiality Protection . . . . . . . . . . . . . . . . 5 67 4.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.1. Access to an 'Unprotected' Resource . . . . . . . . . . . 12 73 6.2. Offering Application Layer End-to-End Security . . . . . . 13 74 6.3. Preventing Access Token Re-Use by the Resource Server . . 13 75 6.4. TLS Channel Binding Support . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 11.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 OAuth 1.0 [RFC5849] included a mechanism for putting a digital 88 signature (when using asymmetric keys) and a keyed message digest 89 (when using symmetric keys) to a resource request when presenting the 90 OAuth access token. OAuth 2.0 [RFC6749] generalized the protocol and 91 the Bearer Token security specification [RFC6750] is close to 92 publication as an RFC. 94 Figure 1 shows the OAuth 2.0 exchange at an abstract level and 95 illustrates the main entities. For most parts of this document the 96 focus is on the interaction between the Client and the Authorization 97 Server and between the Client and the Resource Server. 99 +--------+ +---------------+ 100 | |--(A)- Authorization Request ->| Resource | 101 | | | Owner | 102 | |<-(B)-- Authorization Grant ---| | 103 | | +---------------+ 104 | | 105 | | +---------------+ 106 | |--(C)-- Authorization Grant -->| Authorization | 107 | Client | | Server | 108 | |<-(D)----- Access Token -------| | 109 | | +---------------+ 110 | | 111 | | +---------------+ 112 | |--(E)----- Access Token ------>| Resource | 113 | | | Server | 114 | |<-(F)--- Protected Resource ---| | 115 +--------+ +---------------+ 117 Figure 1: OAuth: Abstract Protocol Flow 119 From a security point of view the following aspects of the OAuth 2.0 120 specification are worth mentioning: 122 o Standardization of a JSON-based format and the content of the 123 access token are still work in progress [I-D.ietf-oauth-json-web- 124 token]. The same is true for the JSON-based security mechanisms. 126 o The interaction to obtain an access token in step #1 mandates to 127 implement and to use TLS with server-side authentication to 128 protect the confidentiality of the transmitted information. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 This document uses the terminology defined in RFC 4949 [RFC4949]. 137 The terms 'keyed hash' and 'keyed message digest' are used 138 interchangable. For privacy related matters we utilize the 139 terminology defined in [I-D.iab-privacy-considerations]. 141 This document uses OAuth 2.0 terminology [RFC6749]. In particular, 142 the terms Client, Resource Server, Authorization Server, and Access 143 Token are used. 145 3. Security and Privacy Threats 146 The following list presents several common threats against protocols 147 utilizing some form of tokens. This list of threats is based on NIST 148 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 149 threats related to any form of identity proofing and authentication 150 of the Resource Owner to the Authorization Server since these 151 procedures are not part of the OAuth 2.0 protocol specificaiton 152 itself. 154 Token manufacture/modification: 156 An attacker may generate a bogus 157 tokens or modify the token content (such as authentication or 158 attribute statements) of an existing token, causing Resource 159 Server to grant inappropriate access to the Client. For example, 160 an attacker may modify the token to extend the validity period. A 161 Client may modify the token to have access to information that 162 they should not be able to view. 164 Token disclosure: Tokens may contain personal data, such as real 165 name, age or birthday, payment information, etc. 167 Token redirect: 169 An attacker uses the token generated for consumption 170 by the Resource Server to obtain access to another Resource 171 Server. 173 Token reuse: 175 An attacker attempts to use a token that has already 176 been used once with a Resource Server. The attacker may be an 177 eavesdropper who observes the communication exchange or, worse, 178 one of the communication end points. A Client may, for example, 179 leak access tokens because it cannot keep secrets confidential. A 180 Client may also re-use access tokens for some other Resource 181 Servers. Finally, a Resource Server may use a token it had 182 obtained from a Client and use it with another Resource Server 183 that the Client interacts with. A Resource Server, offering 184 relatively unimportant application services, may attempt to use an 185 access token obtained from a Client to access a high-value 186 service, such as a payment service, on behalf of the Client using 187 the same access token. 189 We excluded one threat from the list, namely 'token repudiation'. 190 Token repudiation refers to a property whereby a Resource Server is 191 given an assurance that the Authorization Server cannot deny to have 192 created a token for the Client. We believe that such a property is 193 interesting but most deployments prefer to deal with the violation of 194 this security property through business actions rather than by using 195 cryptography. 197 4. Threat Mitigation 198 The purpose of this section is to discuss ways to mitigate the 199 threats without taking the current working group status into 200 consideration. 202 A large range of threats can be mitigated by protecting the content 203 of the token, using a digital signature or a keyed message digest. 204 Alternatively, the content of the token could be passed by reference 205 rather than by value (requiring a separate message exchange to 206 resolve the reference to the token content). To simplify the 207 subsequent description we assume that the token itself is digitally 208 signed by the Authorization Server and therefore cannot be modified. 210 To deal with token redirect it is important for the Authorization 211 Server to include the identifier of the intended recipient - the 212 Resource Server. A Resource Server must not be allowed to accept 213 access tokens that are not meant for its consumption. 215 To provide protection against token disclosure two approaches are 216 possible, namely (a) not to include sensitive information inside the 217 token or (b) to ensure confidentiality protection. The latter 218 approach requires at least the communication interaction between the 219 Client and the Authorization Server as well as the interaction 220 between the Client and the Resource Server to experience 221 confidentiality protection. As an example, Transport Layer Security 222 with a ciphersuite that offers confidentiality protection has to be 223 applied. Encrypting the token content itself is another alternative. 224 In our scenario the Authorization Server would, for example, encrypt 225 the token content with a symmetric key shared with the Resource 226 Server. 228 To deal with token reuse more choices are available. 230 4.1. Confidentiality Protection 232 In this approach confidentiality protection of the exchange is 233 provided on the communication interfaces between the Client and the 234 Resource Server, and between the Client and the Authorization Server. 235 No eavesdropper on the wire is able to observe the token exchange. 236 Consequently, a replay by a third party is not possible. An 237 Authorization Server wants to ensure that it only hands out tokens to 238 Clients it has authenticated first and who are authorized. For this 239 purpose, authentication of the Client to the Authorization Server 240 will be a requirement to ensure adequate protection against a range 241 of attacks. This is, however, true for the description in Section 242 4.2 and Section 4.3 as well. Furthermore, the Client has to make 243 sure it does not distribute the access token to entities other than 244 the intended the Resource Server. For that purpose the Client will 245 have to authenticate the Resource Server before transmitting the 246 access token. 248 4.2. Sender Constraint 250 Instead of providing confidentiality protection the Authorization 251 Server could also put the identifier of the Client into the protected 252 token with the following semantic: 'This token is only valid when 253 presented by a Client with the following identifer.' When the access 254 token is then presented to the Resource Server how does it know that 255 it was provided by the Client? It has to authenticate the Client! 256 There are many choices for authenticating the Client to the Resource 257 Server, for example by using client certificates in TLS [RFC5246], or 258 pre-shared secrets within TLS [RFC4279]. The choice of the preferred 259 authentication mechanism and credential type may depend on a number 260 of factors, including 262 o security properties 264 o available infrastructure 266 o library support 268 o credential cost (financial) 270 o performance 272 o integration into the existing IT infrastructure 274 o operational overhead for configuration and distribution of 275 credentials 277 This long list hints to the challenge of selecting at least one 278 mandatory-to-implement Client authentication mechanism. 280 4.3. Key Confirmation 282 A variation of the mechanism of sender authentication described in 283 Section 4.2 is to replace authentication with the proof-of-possession 284 of a specific (session) key, i.e. key confirmation. In this model 285 the Resource Server would not authenticate the Client itself but 286 would rather verify whether the Client knows the session key 287 associated with a specific access token. Examples of this approach 288 can be found with the OAuth 1.0 MAC token [RFC5849], Kerberos 289 [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see also [I-D 290 .hardjono-oauth-kerberos] for a comparison between Kerberos and 291 OAuth), the OAuth 2.0 MAC token [I-D.ietf-oauth-v2-http-mac], and the 292 Holder-of-the-Key approach [I-D.tschofenig-oauth-hotk]. 294 To illustrate key confirmation the first examples borrow from 295 Kerberos and use symmetric key cryptography. Assume that the 296 Authorization Server shares a long-term secret with the Resource 297 Server, called K(Authorization Server-Resource Server). This secret 298 would be established between them in an initial registration phase. 299 When the Client requests an access token the Authorization Server 300 creates a fresh and unique session key Ks and places it into the 301 token encrypted with the long term key K(Authorization Server- 302 Resource Server). Additionally, the Authorization Server attaches Ks 303 to the response message to the Client (in addition to the access 304 token itself) over a confidentiality protected channel. When the 305 Client sends a request to the Resource Server it has to use Ks to 306 compute a keyed message digest for the request (in whatever form or 307 whatever layer). The Resource Server, when receiving the message, 308 retrieves the access token, verifies it and extracts K(Authorization 309 Server-Resource Server) to obtain Ks. This key Ks is then used to 310 verify the keyed message digest of the request message. 312 Note that in this example one could imagine that the mechanism to 313 protect the token itself is based on a symmetric key based mechanism 314 to avoid any form of public key infrastructure but this aspect is not 315 further elaborated in the scenario. 317 A similar mechanism can also be designed using asymmetric 318 cryptography. When the Client requests an access token the 319 Authorization Server creates an ephemeral public / privacy key pair 320 (PK/SK) and places the public key PK into the protected token. When 321 the Authorization Server returns the access token to the Client it 322 also provides the PK/SK key pair over a confidentiality protected 323 channel. When the Client sends a request to the Resource Server it 324 has to use the privacy key SK to sign the request. The Resource 325 Server, when receiving the message, retrieves the access token, 326 verifies it and extracts the public key PK. It uses this ephemeral 327 public key to verify the attached signature. 329 4.4. Summary 331 As a high level message, there are various ways how the threats can 332 be mitigated and while the details of each solution is somewhat 333 different they all ultimately accomplish the goal. 335 The three approaches are: 337 Confidentiality Protection: 339 The weak point with this approach, which 340 is briefly described in Section 4.1, is that the Client has to be 341 careful to whom it discloses the access token. What can be done 342 with the token entirely depends on what rights the token entitles 343 the presenter and what constraints it contains. A token could 344 encode the identifier of the Client but there are scenarios where 345 the Client is not authenticated to the Resource Server or where 346 the identifier of the Client rather represents an application 347 class rather than a single application instance. As such, it is 348 possible that certain deployments choose a rather liberal approach 349 to security and that everyone who is in possession of the access 350 token is granted access to the data. 352 Sender Constraint: 354 The weak point with this approach, which is 355 briefly described in Section 4.2, is to setup the authentication 356 infrastructure such that Clients can be authenticated towards 357 Resource Servers. Additionally, Authorization Server must encode 358 the identifier of the Client in the token for later verification 359 by the Resource Server. Depending on the chosen layer for 360 providing Client-side authentication there may be additional 361 challenges due Web server load balancing, lack of API access to 362 identity information, etc. 364 Key Confirmation: 366 The weak point with this approach, see Section 4.3, 367 is the increased complexity: a complete key distribution protocol 368 has to be defined. 370 In all cases above it has to be ensured that the Client is able to 371 keep the credentials secret. 373 5. Requirements 375 In an attempt to address the threats described in Section 3 the 376 Bearer Token, which corresponds to the description in Section 4.1, 377 was standardized and the work on a JSON-based token format has been 378 started [I-D.ietf-oauth-json-web-token]. The required capability to 379 protected the content of a JSON token using integrity and 380 confidentiality mechanisms is currently work in progress in the IETF 381 JOSE working group. 383 Consequently, the purpose of the remaining document is to provide 384 security that goes beyond the Bearer Token offered security 385 protection. 387 Luckily this is not the first security protocol that has been 388 designed. In trying to seek guidance the authors found RFC 4962 389 [RFC4962], which gives useful guidelines for designers of 390 authentication and key management protocols. While RFC 4962 was 391 written with the AAA framework used for network access authentication 392 in mind the offered suggestions are useful for the design of other 393 key management systems as well. The following requirements list 394 applies OAuth 2.0 terminology to the requirements outlined in RFC 395 4962. 397 These requirements include 399 Cryptographic Algorithm Independent: 401 The key management protocol MUST 402 be cryptographic algorithm independent. 404 Strong, fresh session keys: 406 Session keys MUST be strong and fresh. 407 Each session deserves an independent session key, i.e., one that 408 is generated specifically for the intended use. In context of 409 OAuth this means that keying material is created in such a way 410 that can only be used by the combination of a Client instance, 411 protected resource, and authorization scope. 413 Limit Key Scope: 415 Following the principle of least privilege, parties 416 MUST NOT have access to keying material that is not needed to 417 perform their role. Any protocol that is used to establish 418 session keys MUST specify the scope for session keys, clearly 419 identifying the parties to whom the session key is available. 421 Replay Detection Mechanism: 423 The key management protocol exchanges 424 MUST be replay protected. Replay protection allows a protocol 425 message recipient to discard any message that was recorded during 426 a previous legitimate dialogue and presented as though it belonged 427 to the current dialogue. 429 Authenticate All Parties: 431 Each party in the key management protocol 432 MUST be authenticated to the other parties with whom they 433 communicate. Authentication mechanisms MUST maintain the 434 confidentiality of any secret values used in the authentication 435 process. Secrets MUST NOT be sent to another party without 436 confidentiality protection. 438 Authorization: 440 Client and Resource Server authorization MUST be 441 performed. These entities MUST demonstrate possession of the 442 appropriate keying material, without disclosing it. Authorization 443 is REQUIRED whenever a Client interacts with an Authorization 444 Server. The authorization checking prevents an elevation of 445 privilege attack, and it ensures that an unauthorized authorized 446 is detected. 448 Keying Material Confidentiality and Integrity: 450 While preserving 451 algorithm independence, confidentiality and integrity of all 452 keying material MUST be maintained. 454 Confirm Cryptographic Algorithm Selection: 456 The selection of the 457 "best" cryptographic algorithms SHOULD be securely confirmed. The 458 mechanism SHOULD detect attempted roll-back attacks. 460 Uniquely Named Keys: 462 Key management proposals require a robust key 463 naming scheme, particularly where key caching is supported. The 464 key name provides a way to refer to a key in a protocol so that it 465 is clear to all parties which key is being referenced. Objects 466 that cannot be named cannot be managed. All keys MUST be uniquely 467 named, and the key name MUST NOT directly or indirectly disclose 468 the keying material. 470 Prevent the Domino Effect: 472 Compromise of a single Client MUST NOT 473 compromise keying material held by any other Client within the 474 system, including session keys and long-term keys. Likewise, 475 compromise of a single Resource Server MUST NOT compromise keying 476 material held by any other Resource Server within the system. In 477 the context of a key hierarchy, this means that the compromise of 478 one node in the key hierarchy must not disclose the information 479 necessary to compromise other branches in the key hierarchy. 480 Obviously, the compromise of the root of the key hierarchy will 481 compromise all of the keys; however, a compromise in one branch 482 MUST NOT result in the compromise of other branches. There are 483 many implications of this requirement; however, two implications 484 deserve highlighting. First, the scope of the keying material 485 must be defined and understood by all parties that communicate 486 with a party that holds that keying material. Second, a party 487 that holds keying material in a key hierarchy must not share that 488 keying material with parties that are associated with other 489 branches in the key hierarchy. 491 Bind Key to its Context: 493 Keying material MUST be bound to the 494 appropriate context. The context includes the following. 496 * The manner in which the keying material is expected to be used. 498 * The other parties that are expected to have access to the 499 keying material. 501 * The expected lifetime of the keying material. Lifetime of a 502 child key SHOULD NOT be greater than the lifetime of its parent 503 in the key hierarchy. 505 Any party with legitimate access to keying material can determine 506 its context. In addition, the protocol MUST ensure that all 507 parties with legitimate access to keying material have the same 508 context for the keying material. This requires that the parties 509 are properly identified and authenticated, so that all of the 510 parties that have access to the keying material can be determined. 511 The context will include the Client and the Resource Server 512 identities in more than one form. 514 Authorization Restriction: 516 If Client authorization is restricted, 517 then the Client SHOULD be made aware of the restriction. 519 Client Identity Confidentiality: 521 A Client has identity 522 confidentiality when any party other than the Resource Server and 523 the Authorization Server cannot sufficiently identify the Client 524 within the anonymity set. In comparison to anonymity and 525 pseudonymity, identity confidentiality is concerned with 526 eavesdroppers and intermediaries. A key management protocol 527 SHOULD provide this property. 529 Resource Owner Identity Confidentiality: 531 Resource servers SHOULD be 532 prevented from knowing the real or pseudonymous identity of the 533 Resource Owner, since the Authorization Server is the only entity 534 involved in verifying the Resource Owner's identity. 536 Collusion: 538 Resource Servers that collude can be prevented from using 539 information related to the Resource Owner to track the individual. 540 That is, two different Resource Servers can be prevented from 541 determining that the same Resource Owner has authenticated to both 542 of them. This requires that each Authorization Server obtains 543 different keying material as well as different access tokens with 544 content that does not allow identification of the Resource Owner. 546 AS-to-RS Relationship Anonymity: 548 The Authorization Server can be 549 prevented from knowing which Resource Servers a Resource Owner 550 interacts with. This requires avoiding direct communication 551 between the Authorization Server and the Resource Server at the 552 time when access to a protected resource by the Client is made. 553 Additionally, the Client must not provide information about the 554 Resource Server in the access token request. [QUESTION: Is this a 555 desirable property given that it has other implications for 556 security?] 558 As an additional requirement a solution MUST enable support for 559 channel bindings. The concept of channel binding, as defined in 560 [RFC5056], allows applications to establish that the two end-points 561 of a secure channel at one network layer are the same as at a higher 562 layer by binding authentication at the higher layer to the channel at 563 the lower layer. 565 Furthermore, there are performance concerns specifically with the 566 usage of asymmetric cryptography. As such, the requirement can be 567 phrases as 'faster is better'. [QUESTION: How are we trading the 568 benefits of asymmetric cryptography against the performance impact?] 570 Finally, there are threats that relate to the experience of the 571 software developer as well as operational policies. For example, a 572 frequently raised concern is the absent of verifying that the 573 server's presented identity matches its reference identity so it can 574 authenticate the communication endpoint and authorize it. Verifying 575 the server identity in TLS is discussed at length in [RFC6125]. 576 There are also various guesses about what application developers are 577 able to implement correctly and easily and to what degree they can 578 rely on third party libraries.[QUESTION: How do we reflect these 579 requirements in the design?] 581 6. Use Cases 583 This section lists use cases that provide additional requirements and 584 constrain the solution space. 586 6.1. Access to an 'Unprotected' Resource 588 This use case is for a web client that needs to access a resource 589 where no integrity and confidentiality protection is provided for the 590 exchange of data using TLS following the OAuth-based request. In 591 accessing the resource, the request, which includes the access token, 592 must be protected against replay, and modification. 594 While it is possible to utilize bearer tokens in this scenario, as 595 described in [RFC6750], with TLS protection when the request to the 596 protected resource is made there may be the desire to avoid using TLS 597 between the client and the resource server at all. In such a case 598 the bearer token approach is not possible since it relies on TLS for 599 ensuring integrity and confidentiality protection of the access token 600 exchange since otherwise replay attacks are possible: First, an 601 eavesdropper may steal an access token and represent it at a 602 different resource server. Second, an eavesdropper may steal an 603 access token and replay it against the same resource server at a 604 later point in time. In both cases, if the attack is successful, the 605 adversary gets access to the resource owners data or may perform an 606 operation selected by the adversary (e.g., sending a message). Note 607 that the adversary may obtain the access token (if the 608 recommendations in [RFC6749] and [RFC6750] are not followed) using a 609 number of ways, including eavesdropping the communication on the 610 wireless link. 612 Consequently, the important assumption in this use case is that a 613 resource server does not have TLS support and the security solution 614 should work in such a scenario. Furthermore, it may not be necessary 615 to provide authentication of the resource server towards the client. 617 6.2. Offering Application Layer End-to-End Security 619 In Web deployments resource servers are often placed behind load 620 balancers. Note that the load balancers are deployed by the same 621 organization that operates the resource servers. These load 622 balancers may terminate Transport Layer Security (TLS) and the 623 resulting HTTP traffic may be transmitted in clear from the load 624 balancer to the resource server. With application layer security 625 independent of the underlying TLS security it is possible to allow 626 application servers to perform cryptographic verification on an end- 627 to-end basis. 629 The key aspect in this use case is therefore to offer end-to-end 630 security in the presence of load balancers via application layer 631 security. 633 6.3. Preventing Access Token Re-Use by the Resource Server 635 Imagine a scenario where a resource server that receives a valid 636 access token re-uses it with other resource server. The reason for 637 re-use may be malicious or may well be legimiate. In a legimiate use 638 case consider a case where the resource server needs to consult third 639 party resource servers to complete the requested operation. In both 640 cases it may be assumed that the scope of the access token is 641 sufficiently large that it allows such a re-use. For example, 642 imagine a case where a company operates email services as well as 643 picture sharing services and that company had decided to issue access 644 tokens with a scope that allows access to both services. 646 With this use case the desire is to prevent such access token re-use. 647 This also implies that the legimiate use cases require additional 648 enhancements for request chaining. 650 6.4. TLS Channel Binding Support 652 In this use case we consider the scenario where an OAuth 2.0 request 653 to a protected resource is secured using TLS but the client and the 654 resource server demand that the underlying TLS exchange is bound to 655 additional application layer security to prevent cases where the TLS 656 connection is terminated at a load balancer or a TLS proxy is used 657 that splits the TLS connection into two separate connections. 659 In this use case additional information is conveyed to the resource 660 server to ensure that no entity entity has tampered with the TLS 661 connection. 663 7. Security Considerations 665 The main focus of this document is on security. 667 8. Next Steps 669 From this description so far a few observations and next steps can be 670 derived: 672 1. Bearer Tokens are a viable solution for protecting against the 673 threats described in Section 3. Further standardization work on 674 OAuth security mechanisms needs to provide additional security 675 benefits on top of those provided by the bearer token solution. 677 2. The requirements listed in Section 5 aim to provide a starting 678 point for a discussion on a security solution that provides 679 additional security and privacy benefits for OAuth 2.0. 681 3. It is likely that implementers will find security solutions hard 682 to implement and hard to configure right. Additional guidance 683 and the availability to libraries may help to improve security on 684 the Internet for OAuth-based implementations. Fundamentally, 685 there is the question about a design that is based on symmetric 686 vs. asymmetric cryptography. Ideally, only a single solution 687 should be developed (or a very small number) since the 688 differences between different variations of such as protocol are 689 minor. 691 4. A standardized solution for the token format is needed to 692 mitigate a number of attacks and this work is already ongoing 693 under the name of JWT [I-D.ietf-oauth-json-web-token]. 695 To make progress with the above-mentioned items before the next IETF 696 meeting in Atlanta I therefore suggest to (a) solicit for document 697 reviews regarding the JWT document, and (b) progress the work on the 698 extended OAuth security mechanism. Regarding the latter aspect 699 consider the following questions: 701 Threats: 703 Section 3 lists a few security threats. Are these the 704 threats you care about? Which threats missing? 706 Requirements: 708 The working group has expressed interest to work on an 709 extended OAuth security mechanism. Assuming that the group wants 710 to develop a key distribution protocol (as described in Section 711 4.3) are the requirements listed in Section 5 complete? Who is 712 interested to develop early prototypes of support the standards 713 development? 715 9. IANA Considerations 717 This document does not require actions by IANA. 719 10. Acknowledgments 721 The authors would like to thank the OAuth working group for their 722 discussion input. A group of regular OAuth participants met at the 723 IETF #82 meeting in Vancouver to discuss this topic in preparation 724 for the face-to-face meeting. The participants were: 726 o John Bradley 728 o Brian Campbell 730 o Phil Hunt 732 o Leif Johansson 734 o Mike Jones 736 o Lucy Lynch 738 o Tony Nadalin 740 o Klaas Wierenga 742 This document reuses content from [RFC4962] and the author would like 743 thank Russ Housely and Bernard Aboba for their work on that document. 745 Finally, I would like to thank Blaine Cook. This document was 746 derived from an earlier draft that Blaine and I wrote. 748 11. References 750 11.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", March 1997. 755 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 756 6749, October 2012. 758 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 759 4949, August 2007. 761 [I-D.ietf-oauth-json-web-token] 762 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 763 (JWT)", Internet-Draft draft-ietf-oauth-json-web-token-05, 764 November 2012. 766 11.2. Informative References 768 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 769 Authorization, and Accounting (AAA) Key Management", BCP 770 132, RFC 4962, July 2007. 772 [I-D.iab-privacy-considerations] 773 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 774 Morris, J., Hansen, M., and R. Smith, "Privacy 775 Considerations for Internet Protocols", Internet-Draft 776 draft-iab-privacy-considerations-03, July 2012. 778 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 779 for Transport Layer Security (TLS)", RFC 4279, December 780 2005. 782 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 783 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 785 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 786 Kerberos Network Authentication Service (V5)", RFC 4120, 787 July 2005. 789 [I-D.hardjono-oauth-kerberos] 790 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 791 Authentication Protocol", Internet-Draft draft-hardjono- 792 oauth-kerberos-01, December 2010. 794 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 795 April 2010. 797 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 798 Channels", RFC 5056, November 2007. 800 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 801 Framework: Bearer Token Usage", RFC 6750, October 2012. 803 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 804 Verification of Domain-Based Application Service Identity 805 within Internet Public Key Infrastructure Using X.509 806 (PKIX) Certificates in the Context of Transport Layer 807 Security (TLS)", RFC 6125, March 2011. 809 [I-D.ietf-oauth-v2-http-mac] 810 Richer, J., Mills, W., and H. Tschofenig, "OAuth 2.0 811 Message Authentication Code (MAC) Tokens", Internet-Draft 812 draft-ietf-oauth-v2-http-mac-02, November 2012. 814 [I-D.tschofenig-oauth-hotk] 815 Bradley, J., Hunt, P., Nadalin, A., and H. Tschofenig, 816 "The OAuth 2.0 Authorization Framework: Holder-of-the-Key 817 Token Usage", Internet-Draft draft-tschofenig-oauth- 818 hotk-01, July 2012. 820 [NIST800-63] 821 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 822 and E. Nabbus, "NIST Special Publication 800-63-1, 823 INFORMATION SECURITY", December 2008. 825 Authors' Addresses 827 Hannes Tschofenig 828 Nokia Siemens Networks 829 Linnoitustie 6 830 Espoo 02600 831 Finland 833 Phone: +358 (50) 4871445 834 Email: Hannes.Tschofenig@gmx.net 835 URI: http://www.tschofenig.priv.at 837 Phil Hunt 838 Oracle Corporation 840 Email: phil.hunt@yahoo.com