idnits 2.17.1 draft-tschofenig-oauth-security-00.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 date (September 6, 2012) is 4250 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-03 == 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-01 == Outdated reference: A later version (-03) exists of draft-tschofenig-oauth-hotk-01 Summary: 0 errors (**), 0 flaws (~~), 5 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: March 10, 2013 Oracle Corporation 6 September 6, 2012 8 OAuth 2.0 Security: Going Beyond Bearer Tokens 9 draft-tschofenig-oauth-security-00.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 March 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Security and Privacy Threats . . . . . . . . . . . . . . . . . 5 65 4. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Confidentiality Protection . . . . . . . . . . . . . . . . 7 67 4.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 8 68 4.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . . 8 69 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 7. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 OAuth 1.0 [RFC5849] included a mechanism for putting a digital 83 signature (when using asymmetric keys) and a keyed message digest 84 (when using symmetric keys) to a resource request when presenting the 85 OAuth access token. OAuth 2.0 [I-D.ietf-oauth-v2] generalized the 86 protocol and the Bearer Token security specification 87 [I-D.ietf-oauth-v2-bearer] is close to publication as an RFC. 89 Figure 1 shows the OAuth 2.0 exchange at an abstract level and 90 illustrates the main entities. For most parts of this document the 91 focus is on the interaction between the Client and the Authorization 92 Server and between the Client and the Resource Server. 94 +--------+ +---------------+ 95 | |--(A)- Authorization Request ->| Resource | 96 | | | Owner | 97 | |<-(B)-- Authorization Grant ---| | 98 | | +---------------+ 99 | | 100 | | +---------------+ 101 | |--(C)-- Authorization Grant -->| Authorization | 102 | Client | | Server | 103 | |<-(D)----- Access Token -------| | 104 | | +---------------+ 105 | | 106 | | +---------------+ 107 | |--(E)----- Access Token ------>| Resource | 108 | | | Server | 109 | |<-(F)--- Protected Resource ---| | 110 +--------+ +---------------+ 112 Figure 1: OAuth: Abstract Protocol Flow 114 From a security point of view the following aspects of the OAuth 2.0 115 specification are worth mentioning: 117 o Standardization of a JSON-based format and the content of the 118 access token are still work in progress 119 [I-D.ietf-oauth-json-web-token]. The same is true for the JSON- 120 based security mechanisms. 122 o The interaction to obtain an access token in step #1 mandates to 123 implement and to use TLS with server-side authentication to 124 protect the confidentiality of the transmitted information. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 This document uses the terminology defined in RFC 4949 [RFC4949]. 133 The terms 'keyed hash' and 'keyed message digest' are used 134 interchangable. For privacy related matters we utilize the 135 terminology defined in [I-D.iab-privacy-considerations]. 137 This document uses OAuth 2.0 terminology [I-D.ietf-oauth-v2]. In 138 particular, the terms Client, Resource Server, Authorization Server, 139 and Access Token are used. 141 3. Security and Privacy Threats 143 The following list presents several common threats against protocols 144 utilizing some form of tokens. This list of threats is based on NIST 145 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 146 threats related to any form of identity proofing and authentication 147 of the Resource Owner to the Authorization Server since these 148 procedures are not part of the OAuth 2.0 protocol specificaiton 149 itself. 151 Token manufacture/modification: 153 An attacker may generate a bogus tokens or modify the token 154 content (such as authentication or attribute statements) of an 155 existing token, causing Resource Server to grant inappropriate 156 access to the Client. For example, an attacker may modify the 157 token to extend the validity period. A Client may modify the 158 token to have access to information that they should not be able 159 to view. 161 Token disclosure: Tokens may contain personal data, such as real 162 name, age or birthday, payment information, etc. 164 Token redirect: 166 An attacker uses the token generated for consumption by the 167 Resource Server to obtain access to another Resource Server. 169 Token reuse: 171 An attacker attempts to use a token that has already been used 172 once with a Resource Server. The attacker may be an eavesdropper 173 who observes the communication exchange or, worse, one of the 174 communication end points. A Client may, for example, leak access 175 tokens because it cannot keep secrets confidential. A Client may 176 also re-use access tokens for some other Resource Servers. 177 Finally, a Resource Server may use a token it had obtained from a 178 Client and use it with another Resource Server that the Client 179 interacts with. A Resource Server, offering relatively 180 unimportant application services, may attempt to use an access 181 token obtained from a Client to access a high-value service, such 182 as a payment service, on behalf of the Client using the same 183 access token. 185 We excluded one threat from the list, namely 'token repudiation'. 186 Token repudiation refers to a property whereby a Resource Server is 187 given an assurance that the Authorization Server cannot deny to have 188 created a token for the Client. We believe that such a property is 189 interesting but most deployments prefer to deal with the violation of 190 this security property through business actions rather than by using 191 cryptography. 193 4. Threat Mitigation 195 The purpose of this section is to discuss ways to mitigate the 196 threats without taking the current working group status into 197 consideration. 199 A large range of threats can be mitigated by protecting the content 200 of the token, using a digital signature or a keyed message digest. 201 Alternatively, the content of the token could be passed by reference 202 rather than by value (requiring a separate message exchange to 203 resolve the reference to the token content). To simplify the 204 subsequent description we assume that the token itself is digitally 205 signed by the Authorization Server and therefore cannot be modified. 207 To deal with token redirect it is important for the Authorization 208 Server to include the identifier of the intended recipient - the 209 Resource Server. A Resource Server must not be allowed to accept 210 access tokens that are not meant for its consumption. 212 To provide protection against token disclosure two approaches are 213 possible, namely (a) not to include sensitive information inside the 214 token or (b) to ensure confidentiality protection. The latter 215 approach requires at least the communication interaction between the 216 Client and the Authorization Server as well as the interaction 217 between the Client and the Resource Server to experience 218 confidentiality protection. As an example, Transport Layer Security 219 with a ciphersuite that offers confidentiality protection has to be 220 applied. Encrypting the token content itself is another alternative. 221 In our scenario the Authorization Server would, for example, encrypt 222 the token content with a symmetric key shared with the Resource 223 Server. 225 To deal with token reuse more choices are available. 227 4.1. Confidentiality Protection 229 In this approach confidentiality protection of the exchange is 230 provided on the communication interfaces between the Client and the 231 Resource Server, and between the Client and the Authorization Server. 232 No eavesdropper on the wire is able to observe the token exchange. 233 Consequently, a replay by a third party is not possible. An 234 Authorization Server wants to ensure that it only hands out tokens to 235 Clients it has authenticated first and who are authorized. For this 236 purpose, authentication of the Client to the Authorization Server 237 will be a requirement to ensure adequate protection against a range 238 of attacks. This is, however, true for the description in 239 Section 4.2 and Section 4.3 as well. Furthermore, the Client has to 240 make sure it does not distribute the access token to entities other 241 than the intended the Resource Server. For that purpose the Client 242 will have to authenticate the Resource Server before transmitting the 243 access token. 245 4.2. Sender Constraint 247 Instead of providing confidentiality protection the Authorization 248 Server could also put the identifier of the Client into the protected 249 token with the following semantic: 'This token is only valid when 250 presented by a Client with the following identifer.' When the access 251 token is then presented to the Resource Server how does it know that 252 it was provided by the Client? It has to authenticate the Client! 253 There are many choices for authenticating the Client to the Resource 254 Server, for example by using client certificates in TLS [RFC5246], or 255 pre-shared secrets within TLS [RFC4279]. The choice of the preferred 256 authentication mechanism and credential type may depend on a number 257 of factors, including 259 o security properties 261 o available infrastructure 263 o library support 265 o credential cost (financial) 267 o performance 269 o integration into the existing IT infrastructure 271 o operational overhead for configuration and distribution of 272 credentials 274 This long list hints to the challenge of selecting at least one 275 mandatory-to-implement Client authentication mechanism. 277 4.3. Key Confirmation 279 A variation of the mechanism of sender authentication described in 280 Section 4.2 is to replace authentication with the proof-of-possession 281 of a specific (session) key, i.e. key confirmation. In this model 282 the Resource Server would not authenticate the Client itself but 283 would rather verify whether the Client knows the session key 284 associated with a specific access token. Examples of this approach 285 can be found with the OAuth 1.0 MAC token [RFC5849], Kerberos 286 [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see also 287 [I-D.hardjono-oauth-kerberos] for a comparison between Kerberos and 288 OAuth), the OAuth 2.0 MAC token [I-D.ietf-oauth-v2-http-mac], and the 289 Holder-of-the-Key approach [I-D.tschofenig-oauth-hotk]. 291 To illustrate key confirmation the first examples borrow from 292 Kerberos and use symmetric key cryptography. Assume that the 293 Authorization Server shares a long-term secret with the Resource 294 Server, called K(Authorization Server-Resource Server). This secret 295 would be established between them in an initial registration phase. 296 When the Client requests an access token the Authorization Server 297 creates a fresh and unique session key Ks and places it into the 298 token encrypted with the long term key K(Authorization Server- 299 Resource Server). Additionally, the Authorization Server attaches Ks 300 to the response message to the Client (in addition to the access 301 token itself) over a confidentiality protected channel. When the 302 Client sends a request to the Resource Server it has to use Ks to 303 compute a keyed message digest for the request (in whatever form or 304 whatever layer). The Resource Server, when receiving the message, 305 retrieves the access token, verifies it and extracts K(Authorization 306 Server-Resource Server) to obtain Ks. This key Ks is then used to 307 verify the keyed message digest of the request message. 309 Note that in this example one could imagine that the mechanism to 310 protect the token itself is based on a symmetric key based mechanism 311 to avoid any form of public key infrastructure but this aspect is not 312 further elaborated in the scenario. 314 A similar mechanism can also be designed using asymmetric 315 cryptography. When the Client requests an access token the 316 Authorization Server creates an ephemeral public / privacy key pair 317 (PK/SK) and places the public key PK into the protected token. When 318 the Authorization Server returns the access token to the Client it 319 also provides the PK/SK key pair over a confidentiality protected 320 channel. When the Client sends a request to the Resource Server it 321 has to use the privacy key SK to sign the request. The Resource 322 Server, when receiving the message, retrieves the access token, 323 verifies it and extracts the public key PK. It uses this ephemeral 324 public key to verify the attached signature. 326 4.4. Summary 328 As a high level message, there are various ways how the threats can 329 be mitigated and while the details of each solution is somewhat 330 different they all ultimately accomplish the goal. 332 The three approaches are: 334 Confidentiality Protection: 336 The weak point with this approach, which is briefly described in 337 Section 4.1, is that the Client has to be careful to whom it 338 discloses the access token. What can be done with the token 339 entirely depends on what rights the token entitles the presenter 340 and what constraints it contains. A token could encode the 341 identifier of the Client but there are scenarios where the Client 342 is not authenticated to the Resource Server or where the 343 identifier of the Client rather represents an application class 344 rather than a single application instance. As such, it is 345 possible that certain deployments choose a rather liberal approach 346 to security and that everyone who is in possession of the access 347 token is granted access to the data. 349 Sender Constraint: 351 The weak point with this approach, which is briefly described in 352 Section 4.2, is to setup the authentication infrastructure such 353 that Clients can be authenticated towards Resource Servers. 354 Additionally, Authorization Server must encode the identifier of 355 the Client in the token for later verification by the Resource 356 Server. Depending on the chosen layer for providing Client-side 357 authentication there may be additional challenges due Web server 358 load balancing, lack of API access to identity information, etc. 360 Key Confirmation: 362 The weak point with this approach, see Section 4.3, is the 363 increased complexity: a complete key distribution protocol has to 364 be defined. 366 In all cases above it has to be ensured that the Client is able to 367 keep the credentials secret. 369 5. Requirements 371 In an attempt to address the threats described in Section 3 the 372 Bearer Token, which corresponds to the description in Section 4.1, 373 was standardized and the work on a JSON-based token format has been 374 started [I-D.ietf-oauth-json-web-token]. The required capability to 375 protected the content of a JSON token using integrity and 376 confidentiality mechanisms is currently work in progress in the IETF 377 JOSE working group. 379 Consequently, the purpose of the remaining document is to provide 380 security that goes beyond the Bearer Token offered security 381 protection. 383 Luckily this is not the first security protocol that has been 384 designed. In trying to seek guidance the authors found RFC 4962 385 [RFC4962], which gives useful guidelines for designers of 386 authentication and key management protocols. While RFC 4962 was 387 written with the AAA framework used for network access authentication 388 in mind the offered suggestions are useful for the design of other 389 key management systems as well. The following requirements list 390 applies OAuth 2.0 terminology to the requirements outlined in RFC 391 4962. 393 These requirements include 395 Cryptographic Algorithm Independent: 397 The key management protocol MUST be cryptographic algorithm 398 independent. 400 Strong, fresh session keys: 402 Session keys MUST be strong and fresh. Each session deserves an 403 independent session key, i.e., one that is generated specifically 404 for the intended use. In context of OAuth this means that keying 405 material is created in such a way that can only be used by the 406 combination of a Client instance, protected resource, and 407 authorization scope. 409 Limit Key Scope: 411 Following the principle of least privilege, parties MUST NOT have 412 access to keying material that is not needed to perform their 413 role. Any protocol that is used to establish session keys MUST 414 specify the scope for session keys, clearly identifying the 415 parties to whom the session key is available. 417 Replay Detection Mechanism: 419 The key management protocol exchanges MUST be replay protected. 420 Replay protection allows a protocol message recipient to discard 421 any message that was recorded during a previous legitimate 422 dialogue and presented as though it belonged to the current 423 dialogue. 425 Authenticate All Parties: 427 Each party in the key management protocol MUST be authenticated to 428 the other parties with whom they communicate. Authentication 429 mechanisms MUST maintain the confidentiality of any secret values 430 used in the authentication process. Secrets MUST NOT be sent to 431 another party without confidentiality protection. 433 Authorization: 435 Client and Resource Server authorization MUST be performed. These 436 entities MUST demonstrate possession of the appropriate keying 437 material, without disclosing it. Authorization is REQUIRED 438 whenever a Client interacts with an Authorization Server. The 439 authorization checking prevents an elevation of privilege attack, 440 and it ensures that an unauthorized authorized is detected. 442 Keying Material Confidentiality and Integrity: 444 While preserving algorithm independence, confidentiality and 445 integrity of all keying material MUST be maintained. 447 Confirm Cryptographic Algorithm Selection: 449 The selection of the "best" cryptographic algorithms SHOULD be 450 securely confirmed. The mechanism SHOULD detect attempted roll- 451 back attacks. 453 Uniquely Named Keys: 455 Key management proposals require a robust key naming scheme, 456 particularly where key caching is supported. The key name 457 provides a way to refer to a key in a protocol so that it is clear 458 to all parties which key is being referenced. Objects that cannot 459 be named cannot be managed. All keys MUST be uniquely named, and 460 the key name MUST NOT directly or indirectly disclose the keying 461 material. 463 Prevent the Domino Effect: 465 Compromise of a single Client MUST NOT compromise keying material 466 held by any other Client within the system, including session keys 467 and long-term keys. Likewise, compromise of a single Resource 468 Server MUST NOT compromise keying material held by any other 469 Resource Server within the system. In the context of a key 470 hierarchy, this means that the compromise of one node in the key 471 hierarchy must not disclose the information necessary to 472 compromise other branches in the key hierarchy. Obviously, the 473 compromise of the root of the key hierarchy will compromise all of 474 the keys; however, a compromise in one branch MUST NOT result in 475 the compromise of other branches. There are many implications of 476 this requirement; however, two implications deserve highlighting. 477 First, the scope of the keying material must be defined and 478 understood by all parties that communicate with a party that holds 479 that keying material. Second, a party that holds keying material 480 in a key hierarchy must not share that keying material with 481 parties that are associated with other branches in the key 482 hierarchy. 484 Bind Key to its Context: 486 Keying material MUST be bound to the appropriate context. The 487 context includes the following. 489 * The manner in which the keying material is expected to be used. 491 * The other parties that are expected to have access to the 492 keying material. 494 * The expected lifetime of the keying material. Lifetime of a 495 child key SHOULD NOT be greater than the lifetime of its parent 496 in the key hierarchy. 498 Any party with legitimate access to keying material can determine 499 its context. In addition, the protocol MUST ensure that all 500 parties with legitimate access to keying material have the same 501 context for the keying material. This requires that the parties 502 are properly identified and authenticated, so that all of the 503 parties that have access to the keying material can be determined. 504 The context will include the Client and the Resource Server 505 identities in more than one form. 507 Authorization Restriction: 509 If Client authorization is restricted, then the Client SHOULD be 510 made aware of the restriction. 512 Client Identity Confidentiality: 514 A Client has identity confidentiality when any party other than 515 the Resource Server and the Authorization Server cannot 516 sufficiently identify the Client within the anonymity set. In 517 comparison to anonymity and pseudonymity, identity confidentiality 518 is concerned with eavesdroppers and intermediaries. A key 519 management protocol SHOULD provide this property. 521 Resource Owner Identity Confidentiality: 523 Resource servers SHOULD be prevented from knowing the real or 524 pseudonymous identity of the Resource Owner, since the 525 Authorization Server is the only entity involved in verifying the 526 Resource Owner's identity. 528 Collusion: 530 Resource Servers that collude can be prevented from using 531 information related to the Resource Owner to track the individual. 532 That is, two different Resource Servers can be prevented from 533 determining that the same Resource Owner has authenticated to both 534 of them. This requires that each Authorization Server obtains 535 different keying material as well as different access tokens with 536 content that does not allow identification of the Resource Owner. 538 AS-to-RS Relationship Anonymity: 540 The Authorization Server can be prevented from knowing which 541 Resource Servers a Resource Owner interacts with. This requires 542 avoiding direct communication between the Authorization Server and 543 the Resource Server at the time when access to a protected 544 resource by the Client is made. Additionally, the Client must not 545 provide information about the Resource Server in the access token 546 request. [QUESTION: Is this a desirable property given that it 547 has other implications for security?] 549 As an additional requirement a solution MUST enable support for 550 channel bindings. The concept of channel binding, as defined in 551 [RFC5056], allows applications to establish that the two end-points 552 of a secure channel at one network layer are the same as at a higher 553 layer by binding authentication at the higher layer to the channel at 554 the lower layer. 556 Furthermore, there are performance concerns specifically with the 557 usage of asymmetric cryptography. As such, the requirement can be 558 phrases as 'faster is better'. [QUESTION: How are we trading the 559 benefits of asymmetric cryptography against the performance impact?] 560 Finally, there are threats that relate to the experience of the 561 software developer as well as operational policies. For example, a 562 frequently raised concern is the absent of verifying that the 563 server's presented identity matches its reference identity so it can 564 authenticate the communication endpoint and authorize it. Verifying 565 the server identity in TLS is discussed at length in [RFC6125]. 566 There are also various guesses about what application developers are 567 able to implement correctly and easily and to what degree they can 568 rely on third party libraries.[QUESTION: How do we reflect these 569 requirements in the design?] 571 6. Security Considerations 573 The main focus of this document is on security. 575 7. Next Steps 577 From this description so far a few observations and next steps can be 578 derived: 580 1. Bearer Tokens are a viable solution for protecting against the 581 threats described in Section 3. Further standardization work on 582 OAuth security mechanisms needs to provide additional security 583 benefits on top of those provided by the bearer token solution. 585 2. The requirements listed in Section 5 aim to provide a starting 586 point for a discussion on a security solution that provides 587 additional security and privacy benefits for OAuth 2.0. 589 3. It is likely that implementers will find security solutions hard 590 to implement and hard to configure right. Additional guidance 591 and the availability to libraries may help to improve security on 592 the Internet for OAuth-based implementations. Fundamentally, 593 there is the question about a design that is based on symmetric 594 vs. asymmetric cryptography. Ideally, only a single solution 595 should be developed (or a very small number) since the 596 differences between different variations of such as protocol are 597 minor. 599 4. A standardized solution for the token format is needed to 600 mitigate a number of attacks and this work is already ongoing 601 under the name of JWT [I-D.ietf-oauth-json-web-token]. 603 To make progress with the above-mentioned items before the next IETF 604 meeting in Atlanta I therefore suggest to (a) solicit for document 605 reviews regarding the JWT document, and (b) progress the work on the 606 extended OAuth security mechanism. Regarding the latter aspect 607 consider the following questions: 609 Threats: 611 Section 3 lists a few security threats. Are these the threats you 612 care about? Which threats missing? 614 Requirements: 616 The working group has expressed interest to work on an extended 617 OAuth security mechanism. Assuming that the group wants to 618 develop a key distribution protocol (as described in Section 4.3) 619 are the requirements listed in Section 5 complete? Who is 620 interested to develop early prototypes of support the standards 621 development? 623 8. IANA Considerations 625 This document does not require actions by IANA. 627 9. Acknowledgments 629 The authors would like to thank the OAuth working group for their 630 discussion input. A group of regular OAuth participants met at the 631 IETF #82 meeting in Vancouver to discuss this topic in preparation 632 for the face-to-face meeting. The participants were: 634 o John Bradley 636 o Brian Campbell 638 o Phil Hunt 640 o Leif Johansson 642 o Mike Jones 644 o Lucy Lynch 646 o Tony Nadalin 648 o Klaas Wierenga 650 This document reuses content from [RFC4962] and the author would like 651 thank Russ Housely and Bernard Aboba for their work on that document. 653 Finally, I would like to thank Blaine Cook. This document was 654 derived from an earlier draft that Blaine and I wrote. 656 10. References 658 10.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", March 1997. 663 [I-D.ietf-oauth-v2] 664 Hardt, D., "The OAuth 2.0 Authorization Framework", 665 draft-ietf-oauth-v2-31 (work in progress), August 2012. 667 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 668 RFC 4949, August 2007. 670 [I-D.ietf-oauth-v2-bearer] 671 Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 672 Framework: Bearer Token Usage", 673 draft-ietf-oauth-v2-bearer-23 (work in progress), 674 August 2012. 676 [I-D.ietf-oauth-json-web-token] 677 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 678 (JWT)", draft-ietf-oauth-json-web-token-03 (work in 679 progress), July 2012. 681 10.2. Informative References 683 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 684 Authorization, and Accounting (AAA) Key Management", 685 BCP 132, RFC 4962, July 2007. 687 [I-D.iab-privacy-considerations] 688 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 689 Morris, J., Hansen, M., and R. Smith, "Privacy 690 Considerations for Internet Protocols", 691 draft-iab-privacy-considerations-03 (work in progress), 692 July 2012. 694 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 695 for Transport Layer Security (TLS)", RFC 4279, 696 December 2005. 698 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 699 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 701 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 702 Kerberos Network Authentication Service (V5)", RFC 4120, 703 July 2005. 705 [I-D.hardjono-oauth-kerberos] 706 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 707 Authentication Protocol", draft-hardjono-oauth-kerberos-01 708 (work in progress), December 2010. 710 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 711 April 2010. 713 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 714 Channels", RFC 5056, November 2007. 716 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 717 Verification of Domain-Based Application Service Identity 718 within Internet Public Key Infrastructure Using X.509 719 (PKIX) Certificates in the Context of Transport Layer 720 Security (TLS)", RFC 6125, March 2011. 722 [I-D.ietf-oauth-v2-http-mac] 723 Hammer-Lahav, E., "HTTP Authentication: MAC Access 724 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in 725 progress), February 2012. 727 [I-D.tschofenig-oauth-hotk] 728 Bradley, J., Hunt, P., Nadalin, A., and H. Tschofenig, 729 "The OAuth 2.0 Authorization Framework: Holder-of-the-Key 730 Token Usage", draft-tschofenig-oauth-hotk-01 (work in 731 progress), July 2012. 733 [NIST800-63] 734 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 735 and E. Nabbus, "NIST Special Publication 800-63-1, 736 INFORMATION SECURITY", December 2008. 738 Authors' Addresses 740 Hannes Tschofenig 741 Nokia Siemens Networks 742 Linnoitustie 6 743 Espoo 02600 744 Finland 746 Phone: +358 (50) 4871445 747 Email: Hannes.Tschofenig@gmx.net 748 URI: http://www.tschofenig.priv.at 750 Phil Hunt 751 Oracle Corporation 753 Email: phil.hunt@yahoo.com