idnits 2.17.00 (12 Aug 2021) /tmp/idnits57917/draft-tschofenig-oauth-signature-thoughts-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-01) exists of draft-hardjono-oauth-kerberos-00 -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 B. Cook 5 Expires: April 21, 2011 BT 6 October 18, 2010 8 Thoughts about Digital Signatures for the Open Web Authentication 9 (OAuth) Protocol 10 draft-tschofenig-oauth-signature-thoughts-00.txt 12 Abstract 14 The initial version of the Open Web Authentication Protocol (OAuth 15 1.0), often referred to as the community addition, included an 16 mechanism for putting a digital signature (when using asymmetric 17 keys) or a keyed message digest (when using symmetric keys) to a 18 resource request when presenting the OAuth token. This cryptographic 19 mechanism has lead to lots of discussions, particularly about the 20 problems implementers had, the use cases it supports, and the 21 benefit-cost tradeoff. 23 This document tries to describe the use of the so-called 'OAuth 24 Signature' mechamism in an unbiased and less emotional way with the 25 main purpose to conclude the discussions. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 21, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Confidentiality Protection . . . . . . . . . . . . . . . . 7 66 4.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . . 8 68 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Operational Considerations . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 The initial version of the Open Web Authentication Protocol (OAuth 82 1.0) included an mechanism for putting a digital signature (when 83 using asymmetric keys) or a keyed message digest (when using 84 symmetric keys) to a resource request when presenting the OAuth 85 token. OAuth 2.0 generalized the structure a bit and the abstract 86 and simplified description of the protocol has the following 87 structure: 89 ,-. 90 (* *) 91 `+' User 92 ' 93 :------------ ---|--- ~~~~~~~~~~: 94 : Service / \ : Management 95 : Interaction / \ : of Resources 96 : : Consent : 97 : : : 98 : : : 99 : +---:-+ Carol : 100 : 1. |Carol| as : 101 : Obtain .'>| | Asserting : 102 : Access .' +-----+ Party : 103 : Token.' : 104 : .' : 105 : .' : 106 : v' : 107 +-:---+ +--:--+ Bob 108 |Alice|<------------------------->|Bob | as 109 | | 2. Authenticated | | Relying 110 +-----+ Request + +-----+ Party 111 Access Token 113 Figure 1: OAuth Simplified 115 We use symbolic names in Figure 1. A few remarks about the figure. 116 In addition to illustrating the message exchange between Alice, Bob, 117 and Carl it also highlights the importance of the user in the 118 exchange in providing consent, triggering the entire interaction as 119 part of invoking a service, and in managing a resource that is work 120 delegating access to. 122 From a cryptographic point of view the following aspects of the OAuth 123 1.0 specification are worth mentioning: 125 o The format and content of the Access Token is not specified. 127 o The authenticated request shown in (2) is essentially a basic HTTP 128 authentication mechanism that supports symmetric as well as 129 asymmetric credentials. The purpose is to authenticate Alice to 130 Bob; no mutual authentication. The procedure for obtaining these 131 credentials is outside the scope. To ensure liveness of the 132 authentication a timestamp and a nonce is included in the request 133 (and is included in the digital signature and the keyed message 134 digest). 136 o The authenticated request signing is optional to implement and 137 optional to use. When the authenticated request signature is 138 omitted (called bearer token) then TLS. Details about what 139 ciphersuite to use with TLS and what required features are needed 140 are not available. 142 OAuth 2.0 [I-D.ietf-oauth-v2] currently does not provide text for 143 authenticated requests in the specification nor does it mandate the 144 use of TLS. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 This document uses the terminology defined in RFC 4949 [RFC4949]. 153 The terms 'keyed hash' and 'keyed message digest' are used 154 interchangable. 156 All discussions in this document refer to the abstract names, namely 157 Alice, Bob, and Carol, shown in Figure 1. 159 3. Security Threats 161 The following list presents several common threats against protocols 162 utilizing some form of tokens. This list of threats is based on NIST 163 Special Publication 800-63 [NIST800-63]. We exclude a discussion of 164 threats related to any form of registration and authentication. 166 Token manufacture/modification: An attacker may generate a bogus 167 token or modify the token content (such as the authentication or 168 attribute statements) of an existing token, causing Bob to grant 169 inappropriate access to the Alice. For example, an attacker may 170 modify the token to extend the validity period; Alice may modify 171 the assertion to have access to information that they should not 172 be able to view. 174 Token disclosure: Tokens may contain authentication and attribute 175 statements that include sensitive information. 177 Token redirect: An attacker uses the token generated for consumption 178 by Bob to obtain access to a second Relying Party. 180 Token reuse: An attacker attempts to use a token that has already 181 been used once with Bob. 183 A Web authentication protocol must provide a consistent story on how 184 to deal with all these threats. We excluded one threat from the 185 list, namely 'token repudiation'. Token repudiation refers to a 186 property whereby Bob is given an assurance that Carol cannot deny to 187 have created a token for Alice. We believe that such a property is 188 interesting from theoretical point of view but most deployments 189 perfer to deal with the violation of this security property via 190 business actions rather than using cryptography. 192 4. Threat Mitigation 194 A large range of threats can be mitigated by protecting the content 195 of the token, using a digitial signature or a keyed message digest. 196 Alternatively, the content of the token could be passed by reference 197 rather than by value (requiring a separate message exchange to 198 resolve the reference to the token content). To simplify the 199 subsequent description we assume that the token itself is digitally 200 signed by Carol and therefore cannot be modified. This also provides 201 the basis for non-repudiation. 203 To deal with token redirect it is important for Carol to include the 204 identity of the intended recipient, namely Bob. Carol would have to 205 be told that Bob is the intended recipient. 207 To provide protection against token disclosure two approaches are 208 possible, namely (a) not to include sensitive information inside the 209 token or (b) to ensure confidentiality protection. The latter 210 feature requires at least the communication interaction between the 211 Alice and Carol as well as the interaction between Alice and Bob to 212 experience confidentiality protection. As an example, Transport 213 Layer Security with a ciphersuite that offers confidentiality 214 protection has to be applied. Encrypting the token content is 215 another alternative. 217 To deal with the last threat, namely token reuse, more choices are 218 available. First, it is highly advisable for Carol to restrict the 219 lifetime of the token by putting a validity time field inside the 220 protected part of the token. This is, however, largely independent 221 of the potential approaches described in the sub-sections below. 223 4.1. Confidentiality Protection 225 In this approach confidentiality protection of the exchange is 226 provided on the communication interfaces between Alice and Bob, and 227 Alice and Carol. No eavesdropper on the wire is able to observe the 228 token exchange. Consequently, a replay is not possible. Carol wants 229 to ensure that it only hands out tokens to entities it has 230 authenticated first and who are authorized. For this purpose, 231 authentication of Alice to Carol will be a requirement. This is, 232 however, true for the description in Section 4.2 and Section 4.3 as 233 well. Furthermore, Alice has to make sure it does not distribute the 234 token to entities other than Bob. For that purpose Alice will have to 235 authenticate Bob before transmitting the token. 237 4.2. Sender Constraint 239 Instead of providing confidentiality protection Carl could also put 240 the identity of Alice into the protected token with the following 241 semantic: 'This token is only valid when presented by Alice.' When 242 the token is then presented to Bob how does he know that it was 243 provided by Alice? He has to authenticate Alice! There are many 244 choices for authenticating Alice to Bob, such as, client-side 245 certificates in TLS [RFC5246], or pre-shared secrets within TLS 246 [RFC4279]. The choice of the preferred authentication mechanism and 247 credential type may depend on a number of factors, including 249 o security properties 251 o available infrastructure 253 o library support 255 o credential cost (financial) 257 o performance 259 o integration into the existing IT infrastructure 261 o operational overhead for configuration and distribution of 262 credentials 264 This long list hints to the challenge of selecting at least one 265 mandatory-to-implement mechanism. 267 4.3. Key Confirmation 269 A variation of the mechanism of sender authentication described in 270 Section 4.2 is to replace authentication with the proof-of-possession 271 of a specific key, i.e. key confirmation. In this model Bob would 272 not authenticate Alice but would rather verify whether Alice knows a 273 secret. This mechanism corresponds to the message signature approach 274 defined by the OAuth 1.0 signature mechanisms [RFC5849] or by 275 Kerberos [RFC4120] when utilizing the AP_REQ/AP_REP exchange (see 276 [I-D.hardjono-oauth-kerberos] for a comparision between Kerberos and 277 OAuth). 279 To illustrate key confirmation the first examples borrows from 280 Kerberos and symmetric key cryptography. Assume that Carol shares a 281 long-term secret with Bob, called K(Carol-Bob). This secret would be 282 established between them in an initial registration phase outside the 283 scope of the actual protocol run. When Alice requests a token Carol 284 creates a fresh and unique key Ks and places it into the token 285 encrypted with K(Carol-Bob). Additionally, Carol attaches Ks when it 286 sends the token to Alice over a confidentialy protected channel. 287 When Alice sends a request to Bob it has to use Ks to sign the 288 request (in whatever form or whatever layer). Bob, when receiving 289 the message, retrieves the token, verifies it and uses K(Carol-Bob) 290 to decrypt Ks and to verify the signature. 292 Note that in this example one could imagine that the mechanism to 293 protect the token itself is based on a symmetric key based mechanism 294 to avoid any form of public key infrastructure but this aspect is not 295 further eleborated in the scenario. 297 A similar mechanism can also be designed using asymmetric 298 cryptography. When Alice requests a token Carol creates an ephemeral 299 public / privacy key pair PK/SK and places the public key PK into the 300 protected token. When Carol returns the token to Alice it also 301 provides the PK/SK key pair over a confidentialy protected channel. 302 When Alice sends a request to Bob it has to use the privacy key SK to 303 sign the request. Again, the details are secondary. Bob, when 304 receiving the message, retrieves the token, verifies it and extracts 305 the public key PK. It uses this ephemeral public key to verify the 306 attached signature. 308 5. Summary 310 In the design of the OAuth security mechanisms the following design 311 decisions have to be made: 313 Threats: Section 3 lists a few security threats. Are these the 314 threats you care about? Are threats missing? 316 Threat Mitigation: Section 4 illustrates how to address the threats 317 listed in Section 3. Do you agree that these are the approaches 318 to address the threats? Do you agree that the three approaches to 319 address token re-use (see Section 4.1, Section 4.2, and 320 Section 4.3) are roughly equivalent from a security point of view 321 (even though they are not equivalent from an operational 322 perspective)? 324 Token Protection and Token Content: Do you agree that many security 325 properties are dependent on the token content and the token 326 protection? 328 6. Operational Considerations 330 It is worth pointing out that the operational aspects in the 331 deployment of OAuth have an impact on the design. While the authors 332 believe that the three approaches to address token re-use are 333 equivalent there are operational challenges with each of them. The 334 purpose of the discussion in this section is therefore to determine, 335 which approach encourages good practices that lead to better security 336 of the overall system based on the most likely behavior of its 337 actors. 339 The three approaches are: 341 Confidentiality Protection: The weak point with this approach, see 342 Section 4.1, is that Alice has to be careful to whom she discloses 343 the token. Everyone who is in possession of the token is granted 344 access to the data. Furthermore, Alice has to trust Bob to secure 345 the token at rest; unauthorized disclosure could be harmful 346 particularly when the token has a rather long lifetime. 347 Intiuitively, one would argue that tokens are easy to mint and 348 used for a small time duration only. 350 Sender Constraint: The weak point with this approach, see 351 Section 4.2, is to setup the authentication infrastructure such 352 that Alice can be authenticated towards Bob. Additionally, Carol 353 to correctly encode Alice's identity in the token for verification 354 by Bob. Depending on the chosen layer for providing client-side 355 authentication there may be additional challenges due Web server 356 load balancing, lack of API access to identity information, etc. 358 Key Confirmation: The weak point with this approach, see 359 Section 4.3, is the increased complexity: a key distribution 360 protocol has to be defined. 362 7. Security Considerations 364 The main focus of this document is on security. Nevertheless, the 365 authors would like to point out that the design of the stoken 366 encoding and token content is currently not standardized. While this 367 motivated by the current OAuth deployment environment and the desire 368 to offer flexibility there are concerns about the ability of those 369 deploying OAuth making reasonable design choices. We recommend to 370 consult 'How to Implement Secure (Mostly) Stateless Tokens' 371 [I-D.rescorla-stateless-tokens] before designing a custom token 372 format. 374 RFC 4962 [RFC4962] gives useful guidelines for designers of key 375 management protocols. While the document was written with the AAA 376 framework and network access authentication in mind the offered 377 suggestions are useful for the design of OAuth and particularly 378 interesting for solutions belonging to the 'key confirmation' class. 379 These requirements include 381 1. Cryptographic algorithm independent 383 2. Strong, fresh session keys 385 3. Limit key scope 387 4. Replay detection mechanism 389 5. Authenticate all parties 391 6. Keying material confidentiality and integrity 393 7. Confirm ciphersuite selection 395 8. Uniquely named keys 397 9. Prevent the Domino effect 399 10. Bind key to its context 401 11. Confidentiality of identity 403 12. Authorization restriction 405 The authors believe it is useful to consider these requirements in 406 the protocol design since the 'token' terminology seems to implicitly 407 suggest to hand out cryptographic keying material and meta-data for 408 usage in multiple, potentially unbounded contexts, with a (very) long 409 lifetime. 411 8. Conclusion 413 The authors argue that the best approach for providing security for 414 OAuth is to 416 1. describe security threats similar to the writeup in Section 3. 418 2. offer recommendations for the protection and the content of the 419 token. A document with a detailed description of the token 420 encoding and the token content (including security protection) is 421 likely to provide users with help in designing their own custom 422 extensions. This document does not need to be part of the OAuth 423 2.0 base specification. [I-D.rescorla-stateless-tokens] and the 424 Kerberos Token format [RFC4120] will provide valuable source of 425 inspiration. 427 3. define a mandatory-to-implement solution based on 'key 428 confirmation' (using symmetric keys) since it provides the fewest 429 number of operational drawbacks. A symmetric key based approach 430 was chosen because of performance reasons even though it requires 431 Carol and Bob to share a long-term secret. It is highly 432 recommended to compare the design against the requirements 433 outlined in [RFC4962]. 435 4. strongly recommend the usage of TLS between Alice and Bob mainly 436 for the additional security services TLS provides, such as 437 confidentiality protection. TLS will be useful for access to 438 protected resources for the exchange of sensitive information. 439 In case that server-side authentication is a concern the usage of 440 channel bindings [RFC5056] should be investigated since they 441 allow binding an anonymous Diffie-Hellman exchange during the TLS 442 handshake with the high-layer security exchange. 444 9. IANA Considerations 446 This document does not require actions by IANA. 448 10. Acknowledgments 450 The authors would like to thank the OAuth working group for their 451 discussion input. 453 11. References 455 11.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", March 1997. 460 [I-D.ietf-oauth-v2] 461 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 462 2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress), 463 July 2010. 465 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 466 RFC 4949, August 2007. 468 11.2. Informative References 470 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 471 for Transport Layer Security (TLS)", RFC 4279, 472 December 2005. 474 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 475 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 477 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 478 Kerberos Network Authentication Service (V5)", RFC 4120, 479 July 2005. 481 [I-D.hardjono-oauth-kerberos] 482 Hardjono, T., "OAuth 2.0 support for the Kerberos V5 483 Authentication Protocol", draft-hardjono-oauth-kerberos-00 484 (work in progress), June 2010. 486 [I-D.rescorla-stateless-tokens] 487 Rescorla, E., "How to Implement Secure (Mostly) Stateless 488 Tokens", draft-rescorla-stateless-tokens-01 (work in 489 progress), March 2007. 491 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 492 Authorization, and Accounting (AAA) Key Management", 493 BCP 132, RFC 4962, July 2007. 495 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 496 April 2010. 498 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 499 Channels", RFC 5056, November 2007. 501 [NIST800-63] 502 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 503 and E. Nabbus, "NIST Special Publication 800-63-1, 504 INFORMATION SECURITY", December 2008. 506 Authors' Addresses 508 Hannes Tschofenig 509 Nokia Siemens Networks 510 Linnoitustie 6 511 Espoo 02600 512 Finland 514 Phone: +358 (50) 4871445 515 Email: Hannes.Tschofenig@gmx.net 516 URI: http://www.tschofenig.priv.at 518 Blaine Cook 519 BT 520 Ireland 522 Email: romeda@gmail.com