idnits 2.17.1 draft-tschofenig-secure-the-web-04.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 23, 2012) is 4200 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5849' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p7-auth' is defined on line 580, 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) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-21 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-04 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-03 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational S. Turner 5 Expires: April 26, 2013 IECA, Inc. 6 M. Hanson 7 Mozilla 8 October 23, 2012 10 An Inquiry into the Nature and the Causes of Web Insecurity 11 draft-tschofenig-secure-the-web-04.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 Web 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 April 26, 2013. 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 73 1. Introduction 75 HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and 76 provides the core foundation of the browser-based platform but is 77 also widely used for non-browser-based applications in smart phones 78 and Internet tablets. Like any other specification in the IETF HTTP 79 also comes with various security mechanims. Digest authentication 80 support in HTTP was published in 1997 with RFC 2069 [RFC2069] and 81 later updated in 1999 by RFC 2617 [RFC2617]. The HTTP state 82 management mechanism, namely cookies, was initially published in 1997 83 with RFC 2109 [RFC2109], revised in 2000 by RFC 2965 [RFC2965], and 84 obsoleted by RFC 6265 [RFC6265]. 86 For client side authentication for HTTP-based protocols two different 87 solution tracks have been offered from the IETF, namely TLS client 88 side authenication and also application level authentication via HTTP 89 basic and digest. TLS-based client authentication using certificates 90 was quite complex for end users to configure (and still is today). 91 HTTP based authentication on the other hand did not found widespread 92 usage either for a number of reasons. First, the user interface was 93 rendered differently than regular Web application forms making it 94 less attractive for Web developers and users. At that time HTTP had 95 a semantic that was closer to file system access control and 96 therefore the decision making process was binary, either the user was 97 granted access to the resource or it wasn't. With the HTTP 401 there 98 was no way for a user to, for example, recover from a lost password 99 or other forms of failure cases. The authentication and 100 authorization process was not seen as continuium but rather as a 101 binary decision. For these reasons form-based authentication 102 mechanisms had found widespread acceptance by the Web application 103 developer community. 105 Many Web sites decided to deploy their own authentication 106 infrastructure and to store cleartext credentials, since most of them 107 use password-based authentication. As reported in a New York Times 108 article from October 2012 [NYT-2Factor] a recent analysis of a leaked 109 large password database revealed that among 3.4 million passwords 110 (among the 30.3 million passwords) consisting of nothing but four 111 digits. The top 20 passwords account for nearly 27% of the total. 112 This even makes online guessing attacks feasible. Users also share 113 the same password across multiple sites making it easy for an 114 adversary to utilize credentials obtained from one site to also gain 115 access on other Web sites. 117 Breach notification laws forced companies to inform their customers 118 about incidents. Consequently, the community became aware of the 119 degree of password leakage due to unauthorized access to these 120 credential databases. For example, in April 2011 Sony experienced a 121 data breach within their PlayStation Network and 100 million users 122 accounts were compromised. This is only one out of thousands of data 123 breaches collected by the Privacy Rights Clearing House [DataBreach]. 124 In most cases these security vulnerabilities are due to 125 misconfiguration, security vulnerabilities in software which can be 126 exploited via buffer overflow attacks, and SQL injection due to 127 insufficient input parameter verification. 129 In addition, cookies are still the most common mechanism for session 130 management, i.e., a non-cryptographic way to bind the initial, often 131 better protected, authentication procedure to the subsequent protocol 132 exchanges. The non-cryptographic session management gives attackers 133 the ability to perform session hijacking. This is of particular 134 concern when users access Internet services using insecure WLAN 135 hotspots. Firesheep [FireSheep], a Firefox plugin that worked as a 136 packetsniffer demonstrated this vulnerability to the non-expert 137 community and made session hijacking 'friendly to use' for a broader 138 community. 140 A number of trends had been observed during the last couple of years, 141 as briefly summarized below. 143 From Documents to Mobile Code: During the last 10 years the Web has 144 changed quite fundamentally with the widespread usage of 145 JavaScript. While Web pages have for a long time been dynamically 146 generated the ever increasing capabilities of JavaScript, with 147 respect to functionality and performance, have changed the 148 security model. A typical Website collects content from multiple 149 other Web sites and delivers it to the user's browser and by 150 delivering code inside HTML new security challenges have emerged. 151 Also the standardization landscape had been challenged by this new 152 development and [I-D.tschofenig-post-standardization] documents 153 architectural implications. 155 Mashups and Data Sharing: With the increasing specialization of Web 156 sites developers started to outsource functionality to other 157 sites. Partially this is a user-convenience aspect (e.g., users 158 do not want to create a new address book with every site, publish 159 their latest status on each and every site again and again) but 160 often also driven by business interestes. In any case, the need 161 to access resources hosted on other sites emerged and often these 162 resources were not visible to everyone. Sharing long-term 163 passwords is considered a bad habit and consequently the Web 164 Authorization (OAuth) protocol [RFC6749] started to become used 165 widely. OAuth avoids the need to share long-term credentials with 166 random Web sites. 168 The Real-Time Web: As HTTP became the protocol of choice for many 169 application developers, also because of it's ability to go through 170 firewalls and NATs, requirements for asynchronous protocol 171 communication had to be addressed as well. HTTP, as a request/ 172 response protocol, was initially not designed for pushing data 173 from the server-side to the client as soon as it is available. 174 Long polling requests and other tricks had been used to allow bi- 175 directional communication between the HTTP client and the HTTP 176 server. The efforts in the BiDirectional or Server-Initiated HTTP 177 (hybi) working group improves the communication capabilities of 178 HTTP. To allow one Web browser to communicate directly with 179 another Web browser the same-origin security framework utilized by 180 the browser has to be bypassed and the work on Real-Time 181 Communication in WEB-browsers (rtcweb) was created to develop a 182 architecture [I-D.ietf-rtcweb-security] and in 183 [I-D.ietf-rtcweb-overview]. Extending Web clients with real-time 184 communication capabilities opens the doors for a large number of 185 applications that had previously only been available for 186 downloadable applications. 188 With the increasing number of security challenges and developments in 189 the Web application environment the standards community was 190 challenged to initiate activities. Examples include the development 191 of HTTP Strict Transport Layer Security (HSTS) 192 [I-D.ietf-websec-strict-transport-sec] that allows Web sites to 193 declare themselves accessible only via secure connections. The 194 attempt to clarify the Web Origin Concept [I-D.ietf-websec-origin], 195 which covers the principles that underlies the concept of origin as 196 used to scope of authority or privilege by user agents. The work 197 around Content Security Policy (CSP) [CSP] that allows Web 198 application developers to declare a set of content restrictions for a 199 web resources. The OAuth protocol that allows secure and privacy- 200 friendly sharing of resources. The work on Javascript Object Signing 201 and Encryption to give Web developers better ways to protect the 202 exchange of JSON data structures. The W3C Web Cryptography API that 203 defines JavaScript extensions that enables developers to implement 204 secure application protocols within Web applications. 206 A lot has changed over the last 10 years in the Web eco-system. 207 While astonishing progress has been made in getting the Web 208 application eco-system on a par with native applications the 209 foundation of the Web platform is still unable to address many of the 210 most common security vulnerabilities; problems the Internet community 211 had been fighting against for over a decade and had solved for other 212 application protocol frameworks and Internet deployment environments. 214 It is time to tackle this problem and to develop a common 215 understanding of the problem and the desired design goals. 217 2. Terminology 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 3. Passwords 225 Passwords have a long history in authentication protocols on the 226 Internet. They appear to be convient for users and are easy to 227 provision to users by many Web site. Still, passwords present a 228 number of challenges, including: 230 o Users re-use the same password at multiple sites. This allows a 231 rouge Website provider to attempt to impersonate users on other 232 sites. It also allows a hacker to use stolen passwords obtained 233 from one site to be used at a non-compromised site. 235 o Password are stored in cleartext in most cases. In case of a data 236 breach account information, including the password, becomes 237 accessible to an attacker. 239 o Users are tricked in typing their password into a Website 240 maintained by phishing attempts. Furthermore, some Websites 241 request username and password for access to protected resources 242 maintained by other Websites. While there are technical ways to 243 avoid the need for such long-term password sharing practice using 244 OAuth some Websites still ask users. 246 o Many password based authenication protocols are not secure against 247 eavesdropping, or allow easy ways for offline dictionary attacks. 249 o When end systems are compromised as well then a keyboard logger 250 can capture any password sequence a user enters. 252 So, why do we need passwords at all? It is easy to come up with 253 solutions that use hardware-based mechanisms (e.g., such as OTP 254 tokens), mobile phones, etc. [Quest] lists some of these mechanisms 255 and makes an attempt to classify them. Many of the analysed 256 authentication mechanisms provide additional security but have design 257 limitations regarding usability and incremental deployment. There 258 are, however, reasons why alternatives have not found widespread 259 deployment on the Internet, such as 261 o Passwords are cheap (at least the primary costs) for user's and 262 service providers. Hardware tokens on the other hand have a 263 certain amount of cost associated with them. 265 o Provisioning new users with passwords is easy. Tools and 266 processes exist and are widely accepted. 268 o Service providers have no external dependency when they manage 269 user accounts themselves (unlike with many third party identity 270 management solutions). 272 o Users are familiar with password-based systems and the acceptance 273 is good. 275 o Passwords can easily be delegated to others. 277 o Users typically feel quite secure when they are using shared 278 secrets and it fits into their mental model of self-securing. 280 o Passwords can easily be transferred to multiple devices used by a 281 single user. 283 Note that the credential type and the actual form of where these 284 credentials are stored (e.g., software, hardware) is orthogonal to 285 the actual identity proofing process. Stronger forms of identity 286 proofing (e.g., requiring in-person passport verification) can be 287 quite expensive. There are also secondary costs in the form of 288 support calls and education if credential provisioning is more 289 complicated, as it is often the case with client certificates. 291 Regardless how many disadvantages passwords have they will be with us 292 for a long time. As such, out attempt is therefore to start from the 293 currently deployment and to look towards a future where fewer of them 294 are used, and if they are used then in a more secure fashion. 296 4. Roadmap 298 It is our aim to accomplish three types of goals: 300 1. Reduce the number of passwords used on the Web 302 2. Increase security of how passwords are used (for example using 303 two-factor authentication). With the RSA patents for one-time 304 password based authentication expiring the usage of the work by 305 the Initiative for Open Authentication (OATH) with their HMAC- 306 Based One-time Password (HOTP) algorithm (RFC 4226 [RFC4226]) and 307 the Time-based One-time Password (TOTP) algorithm (RFC 6238 308 [RFC6238]) has increased. 310 3. Broaden the use of other, non-password-based credentials. The 311 weaknesses related to compromised password databases and the 312 unauthorized access to these stored credentials is difficult to 313 avoid entirely without switching to stronger credentials or 314 without outsourcing those functions to specifialized third party 315 identity providers. 317 A non-goal of this document is to evaluate ways for improving 318 identity proofing, which is a requirement for accomplishing higher 319 levels of assurance. 321 We do not believe that the technical community should be attempting 322 to come up with the single and best solution to satisfy these three 323 goals. We would like to leave room for innovation and allow many 324 different solutions to co-exist to best suite their deployment. 326 Subsequently, we try to highlight a few guiding principles in an 327 attempt to come with a way forward. 329 Move Authentication down into the Platform: 331 Exposing authentication protocol functionality to the user and 332 requiring Web application developers to write security related 333 code has proven to lead to problems. Avoid user interaction 334 related to security whenever possible but keep in mind that 335 authorization decisions, particularly with regard to data sharing, 336 require a consent. Ensure that library support is available for 337 Web developers to allow them easy integration of security 338 functionality into their applications. Unfortunately, a protocol 339 design also needs to consider the transition scenario where the 340 Web endpoints are not yet upgraded to support the new 341 functionality and that the authentication functionality is not yet 342 available. 344 Design for Growth: 346 No single authentication mechanism nor credential type is able to 347 fulfill all use cases. Design for later extensions and develop 348 the protocol architecture in such a way that components are 349 interchangable. In particular, there are a number of 350 authentication mechanisms already in use in other deployment 351 environments. 353 Context Matters: 355 Users require context for all disclosures and the sequence of 356 interactions matters. A monolitic authentication protocol that 357 provides mutual authentication is less likely going to capture the 358 context related disclosures. Server-side authentication is the 359 first interaction that will have to be provided to guarantee 360 genuine content as well as the prerequisity of an early setup for 361 a confidentiality protected channel. Client side authentication 362 may, however, come at a much later stage of the application 363 interaction. It is often bundled with an authorization decision 364 where different application execution paths depend on the level of 365 authorization. 367 Discussion: Is it indeed given that client authentication will 368 have to happen at a later stage given that platform-level 369 authentication proliferates (particularly or mobile phone 370 applications) and "authenticated by default" becomes the norm? 371 If so, then strong signals in UIs of authenticated status, 372 identity selection, and anonymous/pseudonymous modes become 373 more important. One could compare this to the evolution in the 374 telephony communication where caller ID information was 375 initially not provided but became the norm later and blocking 376 the caller ID instead became the expection. 378 Transform Long-Term Passwords to Short-Term Credentials: 380 One of the function of authentication protocols is to transform 381 long-term credentials into short term secrets. Long-term 382 credentials, such as passwords, require substantial protection in 383 a protocol exchange and therefore this interaction often leads to 384 a computationally expensive, multi-roundtrip protocol exchange. 385 We do, however, encourage protocol designers to make heavier use 386 of this transformation step into short term credentials. 388 Keep the User Experience in Mind: 390 Design your protocol stack in such a way that developers up the 391 stack can give good advice to users. The use case analysis should 392 include common failure scenarios since error paths need as much 393 expressiveness as success paths, whereby expressiveness refers to 394 the ability to communicate with the user about failure cases. 396 TLS Always: 398 The initial step of entity authentication cannot be seen in 399 isolution of the ultimate purpose of securing an entire applicatio 400 interaction that requires session management to take place. While 401 this session management today happens in most cases in a non- 402 cryptographic way (i.e., without data origin authentication) we 403 believe it is time revisit this practice. Designing a new 404 cryptographic session management concept is questionable given the 405 already available tools, such as TLS that provides a secure 406 session management using the TLS Record Layer. The usage of the 407 Record Layer is, compared to the TLS Handshake protocol, fairly 408 computationally less time-consuming 410 5. From Two-Party to N-Party 412 It would be short sighted to write about a topic like this without 413 touching a commonly desired way to reduce the number of long term 414 credentials: federated logins 416 Federated login allows a user to utilize his credential obtained from 417 one organization, acting as the Identity Provider, for accessing a 418 resource at another entity, who acts as a Relying Party. While this 419 approach addresses some of our design goals it causes secondary 420 problems to appear - particularly related to privacy. 422 The following issues in this transition from a two-party to a three- 423 party model are to observe: 425 Discovery: 427 How do the three parties find each other? In particular, how does 428 the user (via his or her user agent) inform the relying party 429 about the identity provider it wants to use? How does the relying 430 party inform the user agent (and user) about the identity 431 providers it is able and willing to interact with? Without any 432 changes to the end device relying parties often display icons of 433 identity providers: the more identity providers they support the 434 more icons are displayed to the user. This is also known as the 435 NASCAR problem. 437 Mutual Authentication: 439 How do we ensure that each party is authenticated to each other? 441 Trust and Permissions: 443 What information should the user share with the relying party and 444 how can he be reassured that the information is used in the way he 445 permitted? What information is needed by the Relying Party for 446 the application specific functionality? How is the identity 447 provider able to protect its users against misbehaving relying 448 parties? 450 Collusion: 452 There are three related properties systems should be tying to 453 provide: 455 Relying parties can be prevented from knowing the real or 456 pseudonymous identity of an individual, since the identity 457 provider is the only entity involved in verifying identity. 459 Relying parties that collude can be prevented from using an 460 individual's credentials to track the individual. That is, two 461 different relying parties can be prevented from determining that 462 the same individual has authenticated to both of them. This 463 requires that each relying party use a different means of 464 identifying individuals. 466 The identity provider can be prevented from knowing which relying 467 parties an individual interacted with. This requires avoiding 468 direct communication between the identity provider and the relying 469 party at the time when access to a resource by the initiator is 470 made. 472 Security: 474 Keeping data secure at rest and in transit is another important 475 component of security and privacy protection. How can it be 476 ensured that the interactions between the three parties are not 477 manipulated? An identity provider providing services to many 478 relying parties is exposed to increased risk of a at breach via an 479 nauthorized access to the credential database. How can this 480 increased security protection be provided? 482 Note: While this text talks about three parties there may well be 483 more parties involved in the exchange. The role of the identity 484 consists of a credential provider and an attribute provider that may 485 be provided by different parties. Furthermore, attributes associated 486 with personal data may be contributed by multiple attribute 487 providers, not just by a single entity. There may also be additional 488 parties involved in the communication between the identity provider 489 and the relying party the trust path from the identity provider to 490 the relying party. 492 6. IANA Considerations 494 This document does not require actions by IANA. 496 7. Acknowledgments 498 The content of this document has been created based on discussions 499 with a number of persons, including 501 o Jeff Hodges 503 o Michael Garcia 505 o Adam Barth 507 o Brad Hill 509 o Dan Mills 511 o Ed Felton 513 o Tara Whalen 515 o Andy Steingruebl 517 o Tim Polk 519 o Dirk Balfanz 521 o Nico Williams 523 o Tobias Gondrom 525 o Julian Reschke 527 We would like to thank them for their input. We would also like to 528 thank the participants of the May 2011 W3C Identity in the Browser 529 workshop for their discussion feedback. 531 8. References 533 8.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 539 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 540 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 542 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 543 Leach, P., Luotonen, A., and L. Stewart, "HTTP 544 Authentication: Basic and Digest Access Authentication", 545 RFC 2617, June 1999. 547 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 548 Mechanism", RFC 2109, February 1997. 550 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 551 April 2011. 553 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 554 Mechanism", RFC 2965, October 2000. 556 8.2. Informative References 558 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 559 RFC 6749, October 2012. 561 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 562 April 2010. 564 [I-D.ietf-websec-origin] 565 Barth, A., "The Web Origin Concept", 566 draft-ietf-websec-origin-06 (work in progress), 567 October 2011. 569 [I-D.ietf-websec-strict-transport-sec] 570 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 571 Transport Security (HSTS)", 572 draft-ietf-websec-strict-transport-sec-14 (work in 573 progress), September 2012. 575 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 576 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 577 HTTP : Digest Access Authentication", RFC 2069, 578 January 1997. 580 [I-D.ietf-httpbis-p7-auth] 581 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 582 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-21 583 (work in progress), October 2012. 585 [I-D.tschofenig-post-standardization] 586 Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 587 "Trends in Web Applications and the Implications on 588 Standardization", draft-tschofenig-post-standardization-02 589 (work in progress), May 2012. 591 [I-D.ietf-rtcweb-overview] 592 Alvestrand, H., "Overview: Real Time Protocols for Brower- 593 based Applications", draft-ietf-rtcweb-overview-04 (work 594 in progress), June 2012. 596 [I-D.ietf-rtcweb-security] 597 Rescorla, E., "Security Considerations for RTC-Web", 598 draft-ietf-rtcweb-security-03 (work in progress), 599 June 2012. 601 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 602 O. Ranen, "HOTP: An HMAC-Based One-Time Password 603 Algorithm", RFC 4226, December 2005. 605 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 606 Time-Based One-Time Password Algorithm", RFC 6238, 607 May 2011. 609 [CSP] "Content Security Policy 1.0", July 2012. 611 [FireSheep] 612 "FireSheep, available at 613 http://en.wikipedia.org/wiki/Firesheep", October 2012. 615 [NYT-2Factor] 616 "Doing the Two-Step, Beyond the A.T.M., New York Times, 617 available at http://www.nytimes.com/2012/10/14/technology/ 618 two-step-verification-is-inconvenient-but-more- 619 secure.html", October 2012. 621 [DataBreach] 622 "Privacy Rights Clearinghouse - Data Breaches, available 623 at https://www.privacyrights.org/data-breach", 624 October 2012. 626 [Quest] "The Quest to Replace Passwords: A Framework for 627 Comparative Evaluation of Web Authentication Schemes, In 628 Proc. IEEE Symp. on Security and Privacy 2012 (Oakland 629 2012)", July 2012. 631 Authors' Addresses 633 Hannes Tschofenig 634 Nokia Siemens Networks 635 Linnoitustie 6 636 Espoo 02600 637 Finland 639 Phone: +358 (50) 4871445 640 Email: Hannes.Tschofenig@gmx.net 641 URI: http://www.tschofenig.priv.at 643 Sean Turner 644 IECA, Inc. 645 3057 Nutley Street, Suite 106 646 Fairfax, VA 22031 647 USA 649 Phone: 650 Email: turners@ieca.com 652 Mike Hanson 653 Mozilla 655 Phone: 656 Email: mhanson@mozilla.com