idnits 2.17.00 (12 Aug 2021) /tmp/idnits58821/draft-tschofenig-secure-the-web-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 24, 2011) is 3861 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5849' is defined on line 497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) == Outdated reference: draft-ietf-websec-origin has been published as RFC 6454 == Outdated reference: draft-ietf-websec-strict-transport-sec has been published as RFC 6797 -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) == Outdated reference: draft-ietf-abfab-arch has been published as RFC 7831 == Outdated reference: draft-ietf-httpbis-p7-auth has been published as RFC 7235 == Outdated reference: A later version (-02) exists of draft-tschofenig-post-standardization-00 == Outdated reference: draft-ietf-rtcweb-overview has been published as RFC 8825 == Outdated reference: draft-ietf-rtcweb-security has been published as RFC 8826 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Hanson 3 Internet-Draft Mozilla 4 Intended status: Informational H. Tschofenig 5 Expires: April 26, 2012 Nokia Siemens Networks 6 S. Turner 7 October 24, 2011 9 An Inquiry into the Nature and the Causes of Web Insecurity 10 draft-tschofenig-secure-the-web-00.txt 12 Abstract 14 The year 2011 has been quite exciting from a Web security point of 15 view: a number of high-profile security incidents have gotten a lot 16 of press attention but also new initiatives, such as the National 17 Strategy for Trusted Identities in Cyberspace (NSTIC), had been 18 launched to improve the Web identity eco-system. The NSTIC strategy 19 paper, for example, observes problems with Internet security due to 20 the widespread usage of low-entropy passwords and the lack of widely 21 deployed authentication and attribute assurance services. 23 With this memorandum we try to develop a shared vision for how to 24 deal with the most pressing Internet security problems. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 26, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. From Documents to Mobile Code . . . . . . . . . . . . . . 4 62 1.2. Mashups and Data Sharing . . . . . . . . . . . . . . . . . 4 63 1.3. The Real-Time Web . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Roadmap for the Future . . . . . . . . . . . . . . . . . . . . 9 67 5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and 79 provides the core foundation of the browser-based platform but is 80 also widely used for non-browser-based applications. Like any other 81 specification in the IETF HTTP also comes with various security 82 mechanims. Digest authentication support in HTTP was published in 83 1997 with RFC 2069 [RFC2069] and later updated in 1999 by RFC 2617 84 [RFC2617]. The HTTP state management mechanism, namely cookies, was 85 initially published in 1997 with RFC 2109 [RFC2109], and re-written 86 in 2000 by RFC 2965 [RFC2965]. 88 For client side authentication two different solution tracks had 89 therefore been offered from the IETF, namely TLS client side 90 authenication (at that time using certificates) and also application 91 level authentication via HTTP basic and digest. TLS client 92 authentication was quite complex for users to configure (and still is 93 complex today). HTTP based authentication on the other hand did not 94 found widespread usage either for a number of reasons. First, the 95 user interface was rendered differently than the orginary Web 96 application form making it less attractive for users. At that time 97 HTTP had a semantic that was closer to file system access control and 98 therefore the decision making process was binary, either the user was 99 granted access to the resource or it wasn't. With the HTTP 401 there 100 was no way for a user to, for example, recover from a lost password 101 or other forms of failure cases. The authentication and 102 authorization process was not seen as continuium but rather as a 103 binary decision. For these reasons form-based authentication 104 mechanisms had found widespread acceptance by the Web application 105 developer community. To add to this problem cookies were and still 106 are the most common mechanism for session management, i.e., a non- 107 cryptographic way to bind the initial authentication to the 108 subsequent HTTP protocol exchanges. Cookies introduce various 109 weaknesses into HTTP, including the ability for attackers to perform 110 session hijacking. 112 In the last few years a few other standardization efforts were 113 started: RFC 2965 HTTP state management specification was recently 114 revised to capture deployment reality [RFC6265]. HTTP Strict 115 Transport Layer Security (HSTS) 116 [I-D.ietf-websec-strict-transport-sec] allows Web sites to declare 117 themselves accessible only via secure connections, and the attemp to 118 clarify the Web Origin Concept [I-D.ietf-websec-origin], which covers 119 the principles that underlies the concept of origin as used to scope 120 of authority or privilege by user agents. The HTTPbis Working Group 121 [I-D.ietf-httpbis-p7-auth] revises RFC 2616 plus those parts from RFC 122 2617 that describe the authentication schemes. 124 A lot has changed over the last 10 years in the Web eco-system, as 125 briefly described in the sub-sections below, and various efforts are 126 still ongoing or have recently been started to provide make Web 127 applications even more powerful. Unfortunately, the underlying Web 128 platform had not been able to keep up with these changes and the 129 security weaknesses will only became more apparent. It is time to 130 tackle this problem and to develop a common understanding of the 131 problem and the desired design goals. 133 1.1. From Documents to Mobile Code 135 During the last 10 years the Web has changed quite fundamentally with 136 the widespread usage of JavaScript. While Web pages have for a long 137 time been dynamically generated the ever increasing capabilities of 138 JavaScript, with respect to functionality and performance, have 139 changed the security model. A typical Website collects content from 140 multiple other Web sites and delivers it to the user's browser and by 141 delivering code inside HTML new security challenges have emerged. 142 Also the standardization landscape had been challenged by this new 143 development and [I-D.tschofenig-post-standardization] documents 144 architectural implications. 146 1.2. Mashups and Data Sharing 148 With the increasing specialization of Web sites developers started to 149 outsource functionality to other sites. Partially this is a user- 150 convenience aspect (e.g., users do not want to create a new address 151 book with every site, publish their latest status on each and every 152 site again and again) but often also driven by business interestes. 153 In any case, the need to access resources hosted on other sites 154 emerged and often these resources were not visible to everyone. 155 Sharing long-term passwords is considered a bad habit and 156 consequently the Web Authorization (OAuth) protocol 157 [I-D.ietf-oauth-v2] started to become used widely. OAuth avoids the 158 need to share long-term credentials with random Web sites. 160 1.3. The Real-Time Web 162 As HTTP became the protocol of choice for many application 163 developers, also because of it's ability to go through firewalls and 164 NATs, requirements for asynchronous protocol communication had to be 165 addressed as well. HTTP, as a request/response protocol, was 166 initially not designed for pushing data from the server-side to the 167 client as soon as it is available. Long polling requests and other 168 tricks had been used to allow bi-directional communication between 169 the HTTP client and the HTTP server. More recently the BiDirectional 170 or Server-Initiated HTTP (hybi) working group was created, which only 171 concerns one aspect of real-time communication. To allow one Web 172 browser to communicate directly with another Web browser the same- 173 origin security framework utilized by the browser has to be bypassed 174 and the work on Real-Time Communication in WEB-browsers (rtcweb) was 175 chartered very recently to develop a architecture. More details can 176 be found in [I-D.ietf-rtcweb-security] and in 177 [I-D.ietf-rtcweb-overview]. Extending Web clients with real-time 178 communication capabilities opens the doors for a large number of 179 applications that had previously only been available for downloadable 180 applications. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Passwords 190 Passwords present a number of challenges, including: 192 o Users re-use the same password at multiple sites. This allows a 193 rouge provider to attempt to impersonate users on other sites. 195 o Password are often stored in cleartext. In case of a data breach 196 account information, including the password, becomes accessible to 197 an attacker. 199 o Users are tricked in typing their password into a Website 200 maintained by the attacker. Furthermore, some Websites request 201 username and password for access to protected resources maintained 202 by other Websites for usability purposes. 204 o many password based authenication protocols are not secure against 205 eavesdropping, or allow easy ways for offline dictionary attacks. 207 So, why do we need passwords at all? It is easy to dream up 208 solutions that uses hardware-based mechanisms (e.g., such as hardware 209 tokens). There are, however, reasons why alternatives have not found 210 widespread deployment on the Internet, such as 212 o Passwords are cheap (at least the primary costs) for user's and 213 service providers. Hardware tokens on the other hand have a 214 certain amount of cost associated with them. 216 o Provisioning new users with passwords is easy. Tools and 217 processes exist and are widely accepted. 219 o Service providers have no external dependency when they manage 220 user accounts themselves (unlike with many third party identity 221 management solutions). 223 o Users are familiar with password-based systems and the acceptance 224 is good. 226 o Passwords can easily be delegated to others. 228 o Users typically feel quite secure when they are using shared 229 secrets and it fits into their mental model of self-securing. 231 o Passwords can easily be transferred to multiple devices used by a 232 single user. 234 Note that the credential question and the actual form of where these 235 credentials are stored (e.g., software, hardware) is orthogonal to 236 the actual identity proofing process. Stronger form of identity 237 proofing (e.g., in the form of in person identity proofing with a 238 passport) can be quite expensive. There are also secondary costs in 239 the form of support calls and education if credential provisioning is 240 more complicated, as it is often the case with client certificates. 242 Regardless how many disadvantages passwords have they will be with us 243 for a long time. As such, out attempt is therefore to start from the 244 currently deployment and to look towards a future where fewer of them 245 are used, and if they are used then in a more secure fashion. 247 4. Roadmap for the Future 249 It is our aim to accomplish three types of goals: 251 1. Reduce the number of passwords used 253 2. Increase the safety and security of how passwords are used 255 3. Broaden the use of other credentials 257 A non-goal of this document is to evaluate ways for improving 258 identity proofing, which is a requirement for accomplishing higher 259 levels of assurance. 261 We do not believe that the technical community should be attempting 262 to come up with the single and best solution to satisfy these three 263 goals. We would like to leave room for innovation and room for many 264 different solutions to co-exist. Therefore, we try to highlight a 265 few guiding principles that solutions should follow. 267 Move Authentication down into the Platform: 269 Exposing authentication protocol functionality to the user and 270 requiring Web application developers to write security related 271 code has proven to lead to various problems. Avoid user 272 interaction related to security whenever possible but keep in mind 273 that authorization decisions, particularly with regard to data 274 sharing, require a consent. Ensure that library support is 275 available for Web developers to allow them easy integration of 276 security functionality into their applications. Unfortunately a 277 protocol design also needs to consider the transition scenario 278 where the Web endpoints are not yet upgraded to support the new 279 functionality and that the authentication functionality is not yet 280 available. 282 Design for Growth: 284 No single authentication mechanism nor credential is able to 285 fulfill all use cases. Design for later extensions and develop 286 the protocol architecture in such a way that components are 287 interchangable. In particular, there are a number of 288 authentication mechanisms already in use in other deployment 289 environments. 291 Context Matters: 293 Users require context for all disclosures and the sequence of 294 interactions matters. A monolitic authentication protocol that 295 provides mutual authentication is less likely going to capture the 296 context related disclosures. Server-side authentication is the 297 first interaction that will have to be provided to guarantee 298 genuine content as well as the prerequisity of an early setup for 299 a confidentiality protected channel. Client side authentication 300 may, however, come at a much later stage of the application 301 interaction. It is often bundled with an authorization decision 302 where different application execution paths depend on the level of 303 authorization. 305 Discussion: Is it indeed given that client authentication will 306 have to happen at a later stage given that platform-level 307 authentication proliferates and "authenticated by default" 308 becomes the norm? If so, then strong signals in UIs of 309 authenticated status, identity selection, and anonymous/ 310 pseudonymous modes become more important. One could compare 311 this to the evolution in the telephony communication where 312 caller ID information was initially not provided but became the 313 norm later and blocking the caller ID instead became the 314 expection. 316 Transform Long-Term Passwords to Short-Term Credentials: 318 One of the function of authentication protocols is to transform 319 long-term credentials into short term secrets. Long-term 320 credentials, such as passwords, require substantial protection in 321 a protocol exchange and therefore this interaction often leads to 322 a computationally expensive, multi-roundtrip protocol exchange. 323 We do, however, encourage protocol designers to make heavier use 324 of this transformation step into short term credentials. 325 Furthermore, the initial step of entity authentication cannot be 326 seen in isolution of the ultimate purpose of application protocol 327 interaction that requires session management to take place. While 328 this session management today happens in most cases in a non- 329 cryptographic way (i.e., without data origin authentication) we 330 believe it is time revisit this practice. 332 Keep the User Experience in Mind: 334 Design your protocol stack in such a way that developers up the 335 stack can give good advice to users. The use case analysis should 336 include common failure scenarios since error paths need as much 337 expressiveness as success paths, whereby expressiveness refers to 338 the ability to communicate with the user about failure cases. 340 5. From Two-Party to N-Party 342 It would be short sighted to write about a topic like this without 343 touching a commonly desired way to reduce the number of long term 344 credentials: federated login 346 Federated login allows a user to utilize his credential obtained from 347 one organization, acting as the Identity Provider, for accessing a 348 resource at another, who acts as a Relying Party. While this 349 approach addresses some of our design goals it causes secondary 350 problems to appear; particularly related to privacy. 352 The following issues in this transition from a two-party to a three- 353 party model are to observe: 355 Introduction: 357 How do the three parties find each other? In particular, how does 358 the user (via his user agent) inform the relying party about the 359 identity provider it wants to use? How does the relying party 360 inform the user agent (and user) about the identity providers it 361 is able and willing to interact with? How does the relying party 362 find the identity provider for a given user? 364 Mutual Authentication: 366 How do we ensure that each party is authenticated to each other? 368 Authorization and Trust: 370 What information should the user share with the relying party and 371 how can he be reassured that the information is used in the way he 372 permitted? What information is needed by the Relying Party for 373 the application specific functionality? How is the identity 374 provider able to protect its users against misbehaving relying 375 parties? 377 Collusion: 379 How should a user be protected against identity providers and 380 relying parties conspiring? 382 Security: 384 How can it be ensured that the interactions between the three 385 parties are not manipulated or attacked? 387 Note: While this text talks about three parties there may well be 388 more parties involved in the exchange. The role of the identity 389 consists of a credential provider and an attribute provider that may 390 be provided by different parties. Furthermore, attributes associated 391 with personal data may be contributed by multiple attribute 392 providers, not just by a single entity. There may also be additional 393 parties involved in the communication between the identity provider 394 and the relying party the trust path from the identity provider to 395 the relying party. 397 6. IANA Considerations 399 This document does not require actions by IANA. 401 7. Acknowledgments 403 The content of this document has been created based on discussions 404 with a number of persons, including 406 o Jeff Hodges 408 o Michael Garcia 410 o Adam Barth 412 o Brad Hill 414 o Dan Mills 416 o Ed Felton 418 o Tara Whalen 420 o Andy Steingruebl 422 o Tim Polk 424 o Dirk Balfanz 426 o Nico Williams 428 o Tobias Gondrom 430 o Julian Reschke 432 We would like to thank them for their input. We would also like to 433 thank the participants of the May 2011 W3C Identity in the Browser 434 workshop for their discussion feedback. 436 8. Open Issues 438 This document version serves as a starting point for a discussion. 439 As such, there are several things not yet mentioned, such as 441 o The introduction section should also point to SPDY as recent 442 development in the are of HTTP evolution. 444 o The browser security model should be briefly described. As a 445 comparison, in the browser, we use cross-site communication 446 techniques (redirects, JavaScript) and SSL. In the OS/platform, 447 we use trusted APIs, e.g., signed code, OS-level APIs. In the 448 hardware, we use trusted computing bases (e.g., SIM cards or 449 locked-down platforms). 451 o The current document does not discuss how the relying party can 452 trust the information it receives from the identity provider nor 453 how the identity provider makes sure that the relying party adhere 454 to any privacy requirements it has. Various models for 455 accomplishing this trust have been mentioned in the past, 456 including trust frameworks as used by the General Services 457 Administration (GSA) Identity, Credential and Access Management 458 (ICAM), or the work envisioned by Application Bridging for 459 Federated Access Beyond web (abfab) [I-D.ietf-abfab-arch]. 461 o The document should also discuss the problems related to the PKI 462 as used by web browsers, the procedures for how trust anchors are 463 provisioned, and the lack of liability in the PKI. 465 9. References 467 9.1. Normative References 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 474 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 476 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 477 Leach, P., Luotonen, A., and L. Stewart, "HTTP 478 Authentication: Basic and Digest Access Authentication", 479 RFC 2617, June 1999. 481 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 482 Mechanism", RFC 2109, February 1997. 484 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 485 April 2011. 487 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 488 Mechanism", RFC 2965, October 2000. 490 9.2. Informative References 492 [I-D.ietf-oauth-v2] 493 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 494 2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work 495 in progress), September 2011. 497 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 498 April 2010. 500 [I-D.ietf-websec-origin] 501 Barth, A., "The Web Origin Concept", 502 draft-ietf-websec-origin-06 (work in progress), 503 October 2011. 505 [I-D.ietf-websec-strict-transport-sec] 506 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 507 Transport Security (HSTS)", 508 draft-ietf-websec-strict-transport-sec-02 (work in 509 progress), August 2011. 511 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 512 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 513 HTTP : Digest Access Authentication", RFC 2069, 514 January 1997. 516 [I-D.ietf-abfab-arch] 517 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 518 "Application Bridging for Federated Access Beyond Web 519 (ABFAB) Architecture", draft-ietf-abfab-arch-00 (work in 520 progress), July 2011. 522 [I-D.ietf-httpbis-p7-auth] 523 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 524 Masinter, L., Leach, P., Berners-Lee, T., Reschke, J., and 525 Y. Lafon, "HTTP/1.1, part 7: Authentication", 526 draft-ietf-httpbis-p7-auth-16 (work in progress), 527 August 2011. 529 [I-D.tschofenig-post-standardization] 530 Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 531 "Trends in Web Applications and the Implications on 532 Standardization", draft-tschofenig-post-standardization-00 533 (work in progress), March 2011. 535 [I-D.ietf-rtcweb-overview] 536 Alvestrand, H., "Overview: Real Time Protocols for Brower- 537 based Applications", draft-ietf-rtcweb-overview-02 (work 538 in progress), September 2011. 540 [I-D.ietf-rtcweb-security] 541 Rescorla, E., "Security Considerations for RTC-Web", 542 draft-ietf-rtcweb-security-00 (work in progress), 543 September 2011. 545 Authors' Addresses 547 Mike Hanson 548 Mozilla 550 Phone: 551 Email: mhanson@mozilla.com 553 Hannes Tschofenig 554 Nokia Siemens Networks 555 Linnoitustie 6 556 Espoo 02600 557 Finland 559 Phone: +358 (50) 4871445 560 Email: Hannes.Tschofenig@gmx.net 561 URI: http://www.tschofenig.priv.at 563 Sean Turner 565 Phone: 566 Email: turners@ieca.com