One document matched: draft-tschofenig-secure-the-web-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY RFC2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml">
<!ENTITY RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY RFC5849 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5849.xml">
<!ENTITY RFC2965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2965.xml">
<!ENTITY I-D.ietf-httpbis-p7-auth SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-p7-auth.xml">
<!ENTITY I-D.ietf-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-arch.xml">
<!ENTITY RFC2069 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2069.xml">
<!ENTITY I-D.ietf-websec-origin SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-origin.xml">
<!ENTITY I-D.ietf-websec-strict-transport-sec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-strict-transport-sec.xml">
<!ENTITY I-D.ietf-oauth-v2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2.xml">
<!ENTITY I-D.tschofenig-post-standardization SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-post-standardization.xml">
<!ENTITY I-D.ietf-rtcweb-overview SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml">
<!ENTITY I-D.ietf-rtcweb-security SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security.xml">
]>
<rfc category="info" docName="draft-tschofenig-secure-the-web-01.txt" ipr="trust200902">
<front>
<title abbrev="Memo on Securing the Web">An Inquiry into the Nature and the Causes of Web Insecurity</title>
<author initials="M." surname="Hanson" fullname="Mike Hanson">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>mhanson@mozilla.com</email>
</address>
</author> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author fullname="Sean Turner" initials="S." surname="Turner">
<organization>IECA, Inc.</organization>
<address>
<postal>
<street>3057 Nutley Street, Suite 106</street>
<city>Fairfax</city>
<code>22031</code>
<region>VA</region>
<country>USA</country>
</postal>
<phone></phone>
<email>turners@ieca.com</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<keyword>Internet-Draft</keyword>
<keyword>Web Security</keyword>
<abstract>
<t>The year 2011 has been quite exciting from a Web security point of view: a number of high-profile security incidents have gotten a lot of press attention but also new initiatives, such as the National Strategy for Trusted Identities in Cyberspace (NSTIC), had been launched
to improve the Web identity eco-system. The NSTIC strategy paper, for example, observes problems with Internet security due to the widespread usage of low-entropy passwords and the lack of widely deployed authentication and attribute assurance services.</t>
<t>With this memorandum we try to develop a shared vision for how to deal with the most pressing Internet security problems.</t>
</abstract>
</front>
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="introduction" title="Introduction">
<t>HTTP is an IETF standard and documented in RFC 2616 <xref target="RFC2616"/> and provides the core foundation of the browser-based platform but is also widely used for non-browser-based applications. Like any other specification in the IETF HTTP also comes with various security mechanims. Digest authentication support in HTTP was published in 1997 with RFC 2069 <xref target="RFC2069"/> and later updated in 1999 by RFC 2617 <xref target="RFC2617"/>. The HTTP state management mechanism, namely cookies, was initially published in 1997 with RFC 2109 <xref target="RFC2109"/>, and re-written in 2000 by RFC 2965 <xref target="RFC2965"/>.</t>
<t>For client side authentication two different solution tracks have therefore been offered from the IETF, namely TLS client side authenication (at that time using certificates) and also application level authentication via HTTP basic and digest. TLS client authentication was quite complex for users to configure (and still is complex today). HTTP based authentication on the other hand did not found widespread usage either for a number of reasons. First, the user interface was rendered differently than in regular Web application form making it less attractive for users. At that time HTTP had a semantic that was closer to file system access control and therefore the decision making process was binary, either the user was granted access to the resource or it wasn't. With the HTTP 401 there was no way for a user to, for example, recover from a lost password or other forms of failure cases. The authentication and authorization process was not seen as continuium but rather as a binary decision. For these reasons form-based authentication mechanisms had found widespread acceptance by the Web application developer community. To add to this problem cookies were and still are the most common mechanism for session management, i.e., a non-cryptographic way to bind the initial authentication to the subsequent HTTP protocol exchanges. Cookies introduce various weaknesses into HTTP, including the ability for attackers to perform session hijacking.</t>
<!-- <t>In addition to these early developments around Web security a number of further trends had been observed during the last couple of years, as briefly summarized in the sub-sections below.</t>
-->
<t>In the last few years a few other standardization efforts were started: RFC 2965 HTTP state management specification was recently revised to capture deployment reality <xref target="RFC6265"/>. HTTP Strict Transport Layer Security (HSTS) <xref target="I-D.ietf-websec-strict-transport-sec"/> allows Web sites to declare themselves accessible only via secure connections, and the attemp to clarify the Web Origin Concept <xref target="I-D.ietf-websec-origin"/>, which covers the principles that underlies the concept of origin as used to scope of authority or privilege by user agents. The HTTPbis Working Group <xref target="I-D.ietf-httpbis-p7-auth"/> revises RFC 2616 plus those parts from RFC 2617 that describe the authentication schemes.</t>
<t>A lot has changed over the last 10 years in the Web eco-system, as briefly described in the sub-sections below, and various efforts are still ongoing or have recently been started to provide make Web applications even more powerful. Unfortunately, the underlying Web platform had not been able to keep up with these changes and the security weaknesses will only became more apparent. It is time to tackle this problem and to develop a common understanding of the problem and the desired design goals. </t>
<section title="From Documents to Mobile Code">
<t>During the last 10 years the Web has changed quite fundamentally with the widespread usage of JavaScript. While Web pages have for a long time been dynamically generated the ever increasing capabilities of JavaScript, with respect to functionality and performance, have changed the security model. A typical Website collects content from multiple other Web sites and delivers it to the user's browser and by delivering code inside HTML new security challenges have emerged. Also the standardization landscape had been challenged by this new development and <xref target="I-D.tschofenig-post-standardization"/> documents architectural implications.</t>
</section>
<section title="Mashups and Data Sharing">
<t>With the increasing specialization of Web sites developers started to outsource functionality to other sites. Partially this is a user-convenience aspect (e.g., users do not want to create a new address book with every site, publish their latest status on each and every site again and again) but often also driven by business interestes. In any case, the need to access resources hosted on other sites emerged and often these resources were not visible to everyone. Sharing long-term passwords is considered a bad habit and consequently the Web Authorization (OAuth) protocol <xref target="I-D.ietf-oauth-v2"/> started to become used widely. OAuth avoids the need to share long-term credentials with random Web sites.</t>
</section>
<section title="The Real-Time Web">
<t>As HTTP became the protocol of choice for many application developers, also because of it's ability to go through firewalls and NATs, requirements for asynchronous protocol communication had to be addressed as well. HTTP, as a request/response protocol, was initially not designed for pushing data from the server-side to the
client as soon as it is available. Long polling requests and other tricks had been used to allow bi-directional communication between the HTTP client and the HTTP server. More recently the BiDirectional or Server-Initiated HTTP (hybi) working group was created, which only concerns one aspect of real-time communication. To allow one Web browser to communicate directly with another Web browser the same-origin security framework utilized by the browser has to be bypassed and the work on Real-Time Communication in WEB-browsers (rtcweb) was chartered very recently to develop a architecture. More details can be found in <xref target="I-D.ietf-rtcweb-security"/> and in <xref target="I-D.ietf-rtcweb-overview"/>. Extending Web clients with real-time communication capabilities opens the doors for a large number of applications that had previously only been available for downloadable applications.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Passwords">
<t>Passwords present a number of challenges, including:
<list style="symbols">
<t>Users re-use the same password at multiple sites. This allows a rouge provider to attempt to impersonate users on other sites.
</t>
<t>Password are often stored in cleartext. In case of a data breach account information, including the password, becomes accessible to an attacker.
</t>
<t>Users are tricked in typing their password into a Website maintained by the attacker. Furthermore, some Websites request username and password for access to protected resources maintained by other Websites for usability purposes.
</t>
<t>many password based authenication protocols are not secure against eavesdropping, or allow easy ways for offline dictionary attacks.
</t>
</list>
</t>
<t>So, why do we need passwords at all? It is easy to dream up solutions that uses hardware-based mechanisms (e.g., such as hardware tokens). There are, however, reasons why alternatives have not found widespread deployment on the Internet, such as
<list style="symbols">
<t>Passwords are cheap (at least the primary costs) for user's and service providers. Hardware tokens on the other hand have a certain amount of cost associated with them.
</t>
<t>Provisioning new users with passwords is easy. Tools and processes exist and are widely accepted.
</t>
<t>Service providers have no external dependency when they manage user accounts themselves (unlike with many third party identity management solutions).
</t>
<t>Users are familiar with password-based systems and the acceptance is good.
</t>
<t>Passwords can easily be delegated to others.
</t>
<t>Users typically feel quite secure when they are using shared secrets and it fits into their mental model of self-securing.
</t>
<t>Passwords can easily be transferred to multiple devices used by a single user.
</t>
</list>
</t>
<t>Note that the credential question and the actual form of where these credentials are stored (e.g., software, hardware) is orthogonal to the actual identity proofing process. Stronger form of identity proofing (e.g., in the form of in person identity proofing with a passport) can be quite expensive. There are also secondary costs in the form of support calls and education if credential provisioning is more complicated, as it is often the case with client certificates.
</t>
<t>Regardless how many disadvantages passwords have they will be with us for a long time. As such, out attempt is therefore to start from the currently deployment and to look towards a future where fewer of them are used, and if they are used then in a more secure fashion.</t>
<!-- Open Issue: Do we want to talk about LoA and risk-based authentication? -->
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Roadmap for the Future">
<t>It is our aim to accomplish three types of goals:
<list style="numbers">
<t>Reduce the number of passwords used</t>
<t>Increase the safety and security of how passwords are used</t>
<t>Broaden the use of other credentials</t>
</list>
</t>
<t>A non-goal of this document is to evaluate ways for improving identity proofing, which is a requirement for accomplishing higher levels of assurance.</t>
<t>We do not believe that the technical community should be attempting to come up with the single and best solution to satisfy these three goals. We would like to leave room for innovation and room for many different solutions to co-exist. Therefore, we try to highlight a few guiding principles that solutions should follow.
</t>
<t>
<list style="hanging">
<t hangText="Move Authentication down into the Platform:"><vspace blankLines="1"/>
Exposing authentication protocol functionality to the user and requiring Web application developers to write security related code has proven to lead to various problems.
Avoid user interaction related to security whenever possible but keep in mind that authorization decisions, particularly with regard to data sharing, require a consent. Ensure that library support is available for Web developers to allow them easy integration of security functionality into their applications. Unfortunately a protocol design also needs to consider the transition scenario where the Web endpoints are not yet upgraded to support the new functionality and that the authentication functionality is not yet available. <vspace blankLines="1"/>
</t>
<t hangText="Design for Growth:"><vspace blankLines="1"/>
No single authentication mechanism nor credential is able to fulfill all use cases. Design for later extensions and develop the protocol architecture in such a way that components are interchangable. In particular, there are a number of authentication mechanisms already in use in other deployment environments. <vspace blankLines="1"/>
</t>
<t hangText="Context Matters:"> <vspace blankLines="1"/>
Users require context for all disclosures and the sequence of interactions matters. A monolitic authentication protocol that provides mutual authentication is less likely going to capture the context related disclosures. Server-side authentication is the first interaction that will have to be provided to guarantee genuine content as well as the prerequisity of an early setup for a confidentiality protected channel. Client side authentication may, however, come at a much later stage of the application interaction. It is often bundled with an authorization decision where different application execution paths depend on the level of authorization.<vspace blankLines="1"/>
<list style="empty">
<t>Discussion: Is it indeed given that client authentication will have to happen at a later stage given that platform-level authentication proliferates and "authenticated by default" becomes the norm? If so, then strong signals in UIs of authenticated status, identity selection, and anonymous/pseudonymous modes become more important. One could compare this to the evolution in the telephony communication where caller ID information was initially not provided but became the norm later and blocking the caller ID instead became the expection.</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Transform Long-Term Passwords to Short-Term Credentials:"> <vspace blankLines="1"/>
One of the function of authentication protocols is to transform long-term credentials into short term secrets. Long-term credentials, such as passwords, require substantial protection in a protocol exchange and therefore this interaction often leads to a computationally expensive, multi-roundtrip protocol exchange. We do, however, encourage protocol designers to make heavier use of this transformation step into short term credentials. Furthermore, the initial step of entity authentication cannot be seen in isolution of the ultimate purpose of application protocol interaction that requires session management to take place. While this session management today happens in most cases in a non-cryptographic way (i.e., without data origin authentication) we believe it is time revisit this practice. <vspace blankLines="1"/>
</t>
<t hangText="Keep the User Experience in Mind:"><vspace blankLines="1"/>
Design your protocol stack in such a way that developers up the stack can give good advice to users. The use case analysis should include common failure scenarios since error paths need as much expressiveness as success paths, whereby expressiveness refers to the ability to communicate with the user about failure cases.
</t>
</list>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="From Two-Party to N-Party">
<t>It would be short sighted to write about a topic like this without touching a commonly desired way to reduce the number of long term credentials: federated login</t>
<t>Federated login allows a user to utilize his credential obtained from one organization, acting as the Identity Provider, for accessing a resource at another, who acts as a Relying Party. While this approach addresses some of our design goals it causes secondary problems to appear; particularly related to privacy. </t>
<t>The following issues in this transition from a two-party to a three-party model are to observe:
<list style="hanging">
<t hangText="Introduction:"><vspace blankLines="1"/>
How do the three parties find each other? In particular, how does the user (via his user agent) inform the relying party about the identity provider it wants to use? How does the relying party inform the user agent (and user) about the identity providers it is able and willing to interact with? How does the relying party find the identity provider for a given user?<vspace blankLines="1"/></t>
<t hangText="Mutual Authentication:"><vspace blankLines="1"/>
How do we ensure that each party is authenticated to each other?<vspace blankLines="1"/></t>
<t hangText="Authorization and Trust:"><vspace blankLines="1"/>
What information should the user share with the relying party and how can he be reassured that the information is used in the way he permitted? What information is needed by the Relying Party for the application specific functionality? How is the identity provider able to protect its users against misbehaving relying parties? <vspace blankLines="1"/></t>
<t hangText="Collusion:"><vspace blankLines="1"/>
How should a user be protected against identity providers and relying parties conspiring? <vspace blankLines="1"/></t>
<t hangText="Security:"><vspace blankLines="1"/>
How can it be ensured that the interactions between the three parties are not manipulated or attacked?
<vspace blankLines="1"/></t>
</list>
</t>
<t>Note: While this text talks about three parties there may well be more parties involved in the exchange. The role of the identity consists of a credential provider and an attribute provider that may be provided by different parties. Furthermore, attributes associated with personal data may be contributed by multiple attribute providers, not just by a single entity. There may also be additional parties involved in the communication between the identity provider and the relying party the trust path from the identity provider to the relying party.</t>
<!--
State of the art:
* In the browser, we use cross-site communication techniques (redirects, JavaScript) and SSL
* In the OS/platform, we use trusted APIs, e.g. signed code, OS-level APIs
* In the hardware, we use trusted computing bases (e.g. SIM cards or locked-down platforms)
XXX need to think about this more. maybe this is all deployment decisions?
XXX this may be a place where governance matters more
-->
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="iana" title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>The content of this document has been created based on discussions with a number of persons, including
<list style="symbols">
<t>Jeff Hodges</t>
<t>Michael Garcia</t>
<t>Adam Barth</t>
<t>Brad Hill</t>
<t>Dan Mills</t>
<t>Ed Felton</t>
<t>Tara Whalen</t>
<t>Andy Steingruebl</t>
<t>Tim Polk</t>
<t>Dirk Balfanz</t>
<t>Nico Williams</t>
<t>Tobias Gondrom</t>
<t>Julian Reschke</t>
</list>
</t>
<t>We would like to thank them for their input. We would also like to thank the participants of the May 2011 W3C Identity in the Browser workshop for their discussion feedback. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="open-issues" title="Open Issues">
<t>This document version serves as a starting point for a discussion. As such, there are several things not yet mentioned, such as
<list style="symbols">
<t>The introduction section should also point to SPDY as recent development in the are of HTTP evolution.</t>
<t>The browser security model should be briefly described. As a comparison, in the browser, we use cross-site communication techniques (redirects, JavaScript) and SSL. In the OS/platform, we use trusted APIs, e.g., signed code, OS-level APIs. In the hardware, we use trusted computing bases (e.g., SIM cards or locked-down platforms).</t>
<t>The current document does not discuss how the relying party can trust the information it receives from the identity provider nor how the identity provider makes sure that the relying party adhere to any privacy requirements it has. Various models for accomplishing this trust have been mentioned in the past, including trust frameworks as used by the General Services Administration (GSA) Identity, Credential and Access Management (ICAM), or the work envisioned by Application Bridging for Federated Access Beyond web (abfab) <xref target="I-D.ietf-abfab-arch"/>.</t>
<t>The document should also discuss the problems related to the PKI as used by web browsers, the procedures for how trust anchors are provisioned, and the lack of liability in the PKI.</t>
</list>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<back>
<references title="Normative References">
&RFC2119;
&RFC2616;
&RFC2617;
&RFC2109;
&RFC6265;
&RFC2965;
</references>
<references title="Informative References">
&I-D.ietf-oauth-v2;
&RFC5849;
&I-D.ietf-websec-origin;
&I-D.ietf-websec-strict-transport-sec;
&RFC2069;
&I-D.ietf-abfab-arch;
&I-D.ietf-httpbis-p7-auth;
&I-D.tschofenig-post-standardization;
&I-D.ietf-rtcweb-overview;
&I-D.ietf-rtcweb-security;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 13:59:41 |