idnits 2.17.00 (12 Aug 2021) /tmp/idnits57423/draft-tschofenig-secure-the-web-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 : ---------------------------------------------------------------------------- ** 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 (May 9, 2012) is 3663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5849' is defined on line 498, 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-01 == 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: November 10, 2012 Nokia Siemens Networks 6 S. Turner 7 IECA, Inc. 8 May 9, 2012 10 An Inquiry into the Nature and the Causes of Web Insecurity 11 draft-tschofenig-secure-the-web-01.txt 13 Abstract 15 The year 2011 has been quite exciting from a Web security point of 16 view: a number of high-profile security incidents have gotten a lot 17 of press attention but also new initiatives, such as the National 18 Strategy for Trusted Identities in Cyberspace (NSTIC), had been 19 launched to improve the Web identity eco-system. The NSTIC strategy 20 paper, for example, observes problems with Internet security due to 21 the widespread usage of low-entropy passwords and the lack of widely 22 deployed authentication and attribute assurance services. 24 With this memorandum we try to develop a shared vision for how to 25 deal with the most pressing Internet security problems. 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 November 10, 2012. 44 Copyright Notice 46 Copyright (c) 2012 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 1.1. From Documents to Mobile Code . . . . . . . . . . . . . . 4 63 1.2. Mashups and Data Sharing . . . . . . . . . . . . . . . . . 4 64 1.3. The Real-Time Web . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Roadmap for the Future . . . . . . . . . . . . . . . . . . . . 9 68 5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and 80 provides the core foundation of the browser-based platform but is 81 also widely used for non-browser-based applications. Like any other 82 specification in the IETF HTTP also comes with various security 83 mechanims. Digest authentication support in HTTP was published in 84 1997 with RFC 2069 [RFC2069] and later updated in 1999 by RFC 2617 85 [RFC2617]. The HTTP state management mechanism, namely cookies, was 86 initially published in 1997 with RFC 2109 [RFC2109], and re-written 87 in 2000 by RFC 2965 [RFC2965]. 89 For client side authentication two different solution tracks have 90 therefore been offered from the IETF, namely TLS client side 91 authenication (at that time using certificates) and also application 92 level authentication via HTTP basic and digest. TLS client 93 authentication was quite complex for users to configure (and still is 94 complex today). HTTP based authentication on the other hand did not 95 found widespread usage either for a number of reasons. First, the 96 user interface was rendered differently than in regular Web 97 application form making it less attractive for users. At that time 98 HTTP had a semantic that was closer to file system access control and 99 therefore the decision making process was binary, either the user was 100 granted access to the resource or it wasn't. With the HTTP 401 there 101 was no way for a user to, for example, recover from a lost password 102 or other forms of failure cases. The authentication and 103 authorization process was not seen as continuium but rather as a 104 binary decision. For these reasons form-based authentication 105 mechanisms had found widespread acceptance by the Web application 106 developer community. To add to this problem cookies were and still 107 are the most common mechanism for session management, i.e., a non- 108 cryptographic way to bind the initial authentication to the 109 subsequent HTTP protocol exchanges. Cookies introduce various 110 weaknesses into HTTP, including the ability for attackers to perform 111 session hijacking. 113 In the last few years a few other standardization efforts were 114 started: RFC 2965 HTTP state management specification was recently 115 revised to capture deployment reality [RFC6265]. HTTP Strict 116 Transport Layer Security (HSTS) 117 [I-D.ietf-websec-strict-transport-sec] allows Web sites to declare 118 themselves accessible only via secure connections, and the attemp to 119 clarify the Web Origin Concept [I-D.ietf-websec-origin], which covers 120 the principles that underlies the concept of origin as used to scope 121 of authority or privilege by user agents. The HTTPbis Working Group 122 [I-D.ietf-httpbis-p7-auth] revises RFC 2616 plus those parts from RFC 123 2617 that describe the authentication schemes. 125 A lot has changed over the last 10 years in the Web eco-system, as 126 briefly described in the sub-sections below, and various efforts are 127 still ongoing or have recently been started to provide make Web 128 applications even more powerful. Unfortunately, the underlying Web 129 platform had not been able to keep up with these changes and the 130 security weaknesses will only became more apparent. It is time to 131 tackle this problem and to develop a common understanding of the 132 problem and the desired design goals. 134 1.1. From Documents to Mobile Code 136 During the last 10 years the Web has changed quite fundamentally with 137 the widespread usage of JavaScript. While Web pages have for a long 138 time been dynamically generated the ever increasing capabilities of 139 JavaScript, with respect to functionality and performance, have 140 changed the security model. A typical Website collects content from 141 multiple other Web sites and delivers it to the user's browser and by 142 delivering code inside HTML new security challenges have emerged. 143 Also the standardization landscape had been challenged by this new 144 development and [I-D.tschofenig-post-standardization] documents 145 architectural implications. 147 1.2. Mashups and Data Sharing 149 With the increasing specialization of Web sites developers started to 150 outsource functionality to other sites. Partially this is a user- 151 convenience aspect (e.g., users do not want to create a new address 152 book with every site, publish their latest status on each and every 153 site again and again) but often also driven by business interestes. 154 In any case, the need to access resources hosted on other sites 155 emerged and often these resources were not visible to everyone. 156 Sharing long-term passwords is considered a bad habit and 157 consequently the Web Authorization (OAuth) protocol 158 [I-D.ietf-oauth-v2] started to become used widely. OAuth avoids the 159 need to share long-term credentials with random Web sites. 161 1.3. The Real-Time Web 163 As HTTP became the protocol of choice for many application 164 developers, also because of it's ability to go through firewalls and 165 NATs, requirements for asynchronous protocol communication had to be 166 addressed as well. HTTP, as a request/response protocol, was 167 initially not designed for pushing data from the server-side to the 168 client as soon as it is available. Long polling requests and other 169 tricks had been used to allow bi-directional communication between 170 the HTTP client and the HTTP server. More recently the BiDirectional 171 or Server-Initiated HTTP (hybi) working group was created, which only 172 concerns one aspect of real-time communication. To allow one Web 173 browser to communicate directly with another Web browser the same- 174 origin security framework utilized by the browser has to be bypassed 175 and the work on Real-Time Communication in WEB-browsers (rtcweb) was 176 chartered very recently to develop a architecture. More details can 177 be found in [I-D.ietf-rtcweb-security] and in 178 [I-D.ietf-rtcweb-overview]. Extending Web clients with real-time 179 communication capabilities opens the doors for a large number of 180 applications that had previously only been available for downloadable 181 applications. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 3. Passwords 191 Passwords present a number of challenges, including: 193 o Users re-use the same password at multiple sites. This allows a 194 rouge provider to attempt to impersonate users on other sites. 196 o Password are often stored in cleartext. In case of a data breach 197 account information, including the password, becomes accessible to 198 an attacker. 200 o Users are tricked in typing their password into a Website 201 maintained by the attacker. Furthermore, some Websites request 202 username and password for access to protected resources maintained 203 by other Websites for usability purposes. 205 o many password based authenication protocols are not secure against 206 eavesdropping, or allow easy ways for offline dictionary attacks. 208 So, why do we need passwords at all? It is easy to dream up 209 solutions that uses hardware-based mechanisms (e.g., such as hardware 210 tokens). There are, however, reasons why alternatives have not found 211 widespread deployment on the Internet, such as 213 o Passwords are cheap (at least the primary costs) for user's and 214 service providers. Hardware tokens on the other hand have a 215 certain amount of cost associated with them. 217 o Provisioning new users with passwords is easy. Tools and 218 processes exist and are widely accepted. 220 o Service providers have no external dependency when they manage 221 user accounts themselves (unlike with many third party identity 222 management solutions). 224 o Users are familiar with password-based systems and the acceptance 225 is good. 227 o Passwords can easily be delegated to others. 229 o Users typically feel quite secure when they are using shared 230 secrets and it fits into their mental model of self-securing. 232 o Passwords can easily be transferred to multiple devices used by a 233 single user. 235 Note that the credential question and the actual form of where these 236 credentials are stored (e.g., software, hardware) is orthogonal to 237 the actual identity proofing process. Stronger form of identity 238 proofing (e.g., in the form of in person identity proofing with a 239 passport) can be quite expensive. There are also secondary costs in 240 the form of support calls and education if credential provisioning is 241 more complicated, as it is often the case with client certificates. 243 Regardless how many disadvantages passwords have they will be with us 244 for a long time. As such, out attempt is therefore to start from the 245 currently deployment and to look towards a future where fewer of them 246 are used, and if they are used then in a more secure fashion. 248 4. Roadmap for the Future 250 It is our aim to accomplish three types of goals: 252 1. Reduce the number of passwords used 254 2. Increase the safety and security of how passwords are used 256 3. Broaden the use of other credentials 258 A non-goal of this document is to evaluate ways for improving 259 identity proofing, which is a requirement for accomplishing higher 260 levels of assurance. 262 We do not believe that the technical community should be attempting 263 to come up with the single and best solution to satisfy these three 264 goals. We would like to leave room for innovation and room for many 265 different solutions to co-exist. Therefore, we try to highlight a 266 few guiding principles that solutions should follow. 268 Move Authentication down into the Platform: 270 Exposing authentication protocol functionality to the user and 271 requiring Web application developers to write security related 272 code has proven to lead to various problems. Avoid user 273 interaction related to security whenever possible but keep in mind 274 that authorization decisions, particularly with regard to data 275 sharing, require a consent. Ensure that library support is 276 available for Web developers to allow them easy integration of 277 security functionality into their applications. Unfortunately a 278 protocol design also needs to consider the transition scenario 279 where the Web endpoints are not yet upgraded to support the new 280 functionality and that the authentication functionality is not yet 281 available. 283 Design for Growth: 285 No single authentication mechanism nor credential is able to 286 fulfill all use cases. Design for later extensions and develop 287 the protocol architecture in such a way that components are 288 interchangable. In particular, there are a number of 289 authentication mechanisms already in use in other deployment 290 environments. 292 Context Matters: 294 Users require context for all disclosures and the sequence of 295 interactions matters. A monolitic authentication protocol that 296 provides mutual authentication is less likely going to capture the 297 context related disclosures. Server-side authentication is the 298 first interaction that will have to be provided to guarantee 299 genuine content as well as the prerequisity of an early setup for 300 a confidentiality protected channel. Client side authentication 301 may, however, come at a much later stage of the application 302 interaction. It is often bundled with an authorization decision 303 where different application execution paths depend on the level of 304 authorization. 306 Discussion: Is it indeed given that client authentication will 307 have to happen at a later stage given that platform-level 308 authentication proliferates and "authenticated by default" 309 becomes the norm? If so, then strong signals in UIs of 310 authenticated status, identity selection, and anonymous/ 311 pseudonymous modes become more important. One could compare 312 this to the evolution in the telephony communication where 313 caller ID information was initially not provided but became the 314 norm later and blocking the caller ID instead became the 315 expection. 317 Transform Long-Term Passwords to Short-Term Credentials: 319 One of the function of authentication protocols is to transform 320 long-term credentials into short term secrets. Long-term 321 credentials, such as passwords, require substantial protection in 322 a protocol exchange and therefore this interaction often leads to 323 a computationally expensive, multi-roundtrip protocol exchange. 324 We do, however, encourage protocol designers to make heavier use 325 of this transformation step into short term credentials. 326 Furthermore, the initial step of entity authentication cannot be 327 seen in isolution of the ultimate purpose of application protocol 328 interaction that requires session management to take place. While 329 this session management today happens in most cases in a non- 330 cryptographic way (i.e., without data origin authentication) we 331 believe it is time revisit this practice. 333 Keep the User Experience in Mind: 335 Design your protocol stack in such a way that developers up the 336 stack can give good advice to users. The use case analysis should 337 include common failure scenarios since error paths need as much 338 expressiveness as success paths, whereby expressiveness refers to 339 the ability to communicate with the user about failure cases. 341 5. From Two-Party to N-Party 343 It would be short sighted to write about a topic like this without 344 touching a commonly desired way to reduce the number of long term 345 credentials: federated login 347 Federated login allows a user to utilize his credential obtained from 348 one organization, acting as the Identity Provider, for accessing a 349 resource at another, who acts as a Relying Party. While this 350 approach addresses some of our design goals it causes secondary 351 problems to appear; particularly related to privacy. 353 The following issues in this transition from a two-party to a three- 354 party model are to observe: 356 Introduction: 358 How do the three parties find each other? In particular, how does 359 the user (via his user agent) inform the relying party about the 360 identity provider it wants to use? How does the relying party 361 inform the user agent (and user) about the identity providers it 362 is able and willing to interact with? How does the relying party 363 find the identity provider for a given user? 365 Mutual Authentication: 367 How do we ensure that each party is authenticated to each other? 369 Authorization and Trust: 371 What information should the user share with the relying party and 372 how can he be reassured that the information is used in the way he 373 permitted? What information is needed by the Relying Party for 374 the application specific functionality? How is the identity 375 provider able to protect its users against misbehaving relying 376 parties? 378 Collusion: 380 How should a user be protected against identity providers and 381 relying parties conspiring? 383 Security: 385 How can it be ensured that the interactions between the three 386 parties are not manipulated or attacked? 388 Note: While this text talks about three parties there may well be 389 more parties involved in the exchange. The role of the identity 390 consists of a credential provider and an attribute provider that may 391 be provided by different parties. Furthermore, attributes associated 392 with personal data may be contributed by multiple attribute 393 providers, not just by a single entity. There may also be additional 394 parties involved in the communication between the identity provider 395 and the relying party the trust path from the identity provider to 396 the relying party. 398 6. IANA Considerations 400 This document does not require actions by IANA. 402 7. Acknowledgments 404 The content of this document has been created based on discussions 405 with a number of persons, including 407 o Jeff Hodges 409 o Michael Garcia 411 o Adam Barth 413 o Brad Hill 415 o Dan Mills 417 o Ed Felton 419 o Tara Whalen 421 o Andy Steingruebl 423 o Tim Polk 425 o Dirk Balfanz 427 o Nico Williams 429 o Tobias Gondrom 431 o Julian Reschke 433 We would like to thank them for their input. We would also like to 434 thank the participants of the May 2011 W3C Identity in the Browser 435 workshop for their discussion feedback. 437 8. Open Issues 439 This document version serves as a starting point for a discussion. 440 As such, there are several things not yet mentioned, such as 442 o The introduction section should also point to SPDY as recent 443 development in the are of HTTP evolution. 445 o The browser security model should be briefly described. As a 446 comparison, in the browser, we use cross-site communication 447 techniques (redirects, JavaScript) and SSL. In the OS/platform, 448 we use trusted APIs, e.g., signed code, OS-level APIs. In the 449 hardware, we use trusted computing bases (e.g., SIM cards or 450 locked-down platforms). 452 o The current document does not discuss how the relying party can 453 trust the information it receives from the identity provider nor 454 how the identity provider makes sure that the relying party adhere 455 to any privacy requirements it has. Various models for 456 accomplishing this trust have been mentioned in the past, 457 including trust frameworks as used by the General Services 458 Administration (GSA) Identity, Credential and Access Management 459 (ICAM), or the work envisioned by Application Bridging for 460 Federated Access Beyond web (abfab) [I-D.ietf-abfab-arch]. 462 o The document should also discuss the problems related to the PKI 463 as used by web browsers, the procedures for how trust anchors are 464 provisioned, and the lack of liability in the PKI. 466 9. References 468 9.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 474 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 475 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 477 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 478 Leach, P., Luotonen, A., and L. Stewart, "HTTP 479 Authentication: Basic and Digest Access Authentication", 480 RFC 2617, June 1999. 482 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 483 Mechanism", RFC 2109, February 1997. 485 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 486 April 2011. 488 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 489 Mechanism", RFC 2965, October 2000. 491 9.2. Informative References 493 [I-D.ietf-oauth-v2] 494 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 495 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 496 in progress), May 2012. 498 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 499 April 2010. 501 [I-D.ietf-websec-origin] 502 Barth, A., "The Web Origin Concept", 503 draft-ietf-websec-origin-06 (work in progress), 504 October 2011. 506 [I-D.ietf-websec-strict-transport-sec] 507 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 508 Transport Security (HSTS)", 509 draft-ietf-websec-strict-transport-sec-07 (work in 510 progress), May 2012. 512 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 513 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 514 HTTP : Digest Access Authentication", RFC 2069, 515 January 1997. 517 [I-D.ietf-abfab-arch] 518 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 519 "Application Bridging for Federated Access Beyond Web 520 (ABFAB) Architecture", draft-ietf-abfab-arch-01 (work in 521 progress), March 2012. 523 [I-D.ietf-httpbis-p7-auth] 524 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 525 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 526 progress), March 2012. 528 [I-D.tschofenig-post-standardization] 529 Aboba, B., McPherson, D., Tschofenig, H., and J. Peterson, 530 "Trends in Web Applications and the Implications on 531 Standardization", draft-tschofenig-post-standardization-01 532 (work in progress), October 2011. 534 [I-D.ietf-rtcweb-overview] 535 Alvestrand, H., "Overview: Real Time Protocols for Brower- 536 based Applications", draft-ietf-rtcweb-overview-03 (work 537 in progress), March 2012. 539 [I-D.ietf-rtcweb-security] 540 Rescorla, E., "Security Considerations for RTC-Web", 541 draft-ietf-rtcweb-security-02 (work in progress), 542 March 2012. 544 Authors' Addresses 546 Mike Hanson 547 Mozilla 549 Phone: 550 Email: mhanson@mozilla.com 552 Hannes Tschofenig 553 Nokia Siemens Networks 554 Linnoitustie 6 555 Espoo 02600 556 Finland 558 Phone: +358 (50) 4871445 559 Email: Hannes.Tschofenig@gmx.net 560 URI: http://www.tschofenig.priv.at 562 Sean Turner 563 IECA, Inc. 564 3057 Nutley Street, Suite 106 565 Fairfax, VA 22031 566 USA 568 Phone: 569 Email: turners@ieca.com