< draft-tschofenig-secure-the-web-01.txt   draft-tschofenig-secure-the-web-02.txt >
Network Working Group M. Hanson Network Working Group H. Tschofenig
Internet-Draft Mozilla Internet-Draft Nokia Siemens Networks
Intended status: Informational H. Tschofenig Intended status: Informational S. Turner
Expires: November 10, 2012 Nokia Siemens Networks Expires: January 16, 2013 IECA, Inc.
S. Turner S. Farrell
IECA, Inc. Trinity College Dublin
May 9, 2012 M. Hanson
Mozilla
July 15, 2012
An Inquiry into the Nature and the Causes of Web Insecurity An Inquiry into the Nature and the Causes of Web Insecurity
draft-tschofenig-secure-the-web-01.txt draft-tschofenig-secure-the-web-02.txt
Abstract Abstract
The year 2011 has been quite exciting from a Web security point of 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 view: a number of high-profile security incidents have gotten a lot
of press attention but also new initiatives, such as the National of press attention but also new initiatives, such as the National
Strategy for Trusted Identities in Cyberspace (NSTIC), had been Strategy for Trusted Identities in Cyberspace (NSTIC), had been
launched to improve the Web identity eco-system. The NSTIC strategy launched to improve the Web identity eco-system. The NSTIC strategy
paper, for example, observes problems with Internet security due to paper, for example, observes problems with Internet security due to
the widespread usage of low-entropy passwords and the lack of widely the widespread usage of low-entropy passwords and the lack of widely
deployed authentication and attribute assurance services. deployed authentication and attribute assurance services.
With this memorandum we try to develop a shared vision for how to With this memorandum we try to develop a shared vision for how to
deal with the most pressing Internet security problems. deal with the most pressing Web security problems.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2012. This Internet-Draft will expire on January 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. From Documents to Mobile Code . . . . . . . . . . . . . . 4
1.2. Mashups and Data Sharing . . . . . . . . . . . . . . . . . 4
1.3. The Real-Time Web . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Roadmap for the Future . . . . . . . . . . . . . . . . . . . . 9 4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12 5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and
provides the core foundation of the browser-based platform but is provides the core foundation of the browser-based platform but is
also widely used for non-browser-based applications. Like any other also widely used for non-browser-based applications in smart phones
specification in the IETF HTTP also comes with various security and Internet tablets. Like any other specification in the IETF HTTP
mechanims. Digest authentication support in HTTP was published in also comes with various security mechanims. Digest authentication
1997 with RFC 2069 [RFC2069] and later updated in 1999 by RFC 2617 support in HTTP was published in 1997 with RFC 2069 [RFC2069] and
[RFC2617]. The HTTP state management mechanism, namely cookies, was later updated in 1999 by RFC 2617 [RFC2617]. The HTTP state
initially published in 1997 with RFC 2109 [RFC2109], and re-written management mechanism, namely cookies, was initially published in 1997
in 2000 by RFC 2965 [RFC2965]. with RFC 2109 [RFC2109], and re-written in 2000 by RFC 2965
[RFC2965].
For client side authentication two different solution tracks have For client side authentication two different solution tracks have
therefore been offered from the IETF, namely TLS client side therefore been offered from the IETF, namely TLS client side
authenication (at that time using certificates) and also application authenication (at that time the usage of client certificates was
level authentication via HTTP basic and digest. TLS client envisioned) and also application level authentication via HTTP basic
authentication was quite complex for users to configure (and still is and digest. TLS-based client authentication using certificates was
complex today). HTTP based authentication on the other hand did not quite complex for end users to configure (and still is complex
found widespread usage either for a number of reasons. First, the today). HTTP based authentication on the other hand did not found
user interface was rendered differently than in regular Web widespread usage either for a number of reasons. First, the user
application form making it less attractive for users. At that time interface was rendered differently than in regular Web application
HTTP had a semantic that was closer to file system access control and form making it less attractive for users. At that time HTTP had a
therefore the decision making process was binary, either the user was semantic that was closer to file system access control and therefore
granted access to the resource or it wasn't. With the HTTP 401 there the decision making process was binary, either the user was granted
was no way for a user to, for example, recover from a lost password access to the resource or it wasn't. With the HTTP 401 there was no
or other forms of failure cases. The authentication and way for a user to, for example, recover from a lost password or other
authorization process was not seen as continuium but rather as a forms of failure cases. The authentication and authorization process
binary decision. For these reasons form-based authentication was not seen as continuium but rather as a binary decision. For
mechanisms had found widespread acceptance by the Web application these reasons form-based authentication mechanisms had found
developer community. To add to this problem cookies were and still widespread acceptance by the Web application developer community.
are the most common mechanism for session management, i.e., a non- Additionally, many Web sites decided to deploy their own
cryptographic way to bind the initial authentication to the authentication infrastructure and to store cleartext credentials (in
subsequent HTTP protocol exchanges. Cookies introduce various most cases a username and a password) into a database. To add to
weaknesses into HTTP, including the ability for attackers to perform this problem cookies were and still are the most common mechanism for
session hijacking. 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. In the last few years we
have seen many press anouncements of password leakage due to
unauthorized access to these credential databases.
In the last few years a few other standardization efforts were In the last few years a few other standardization efforts were
started: RFC 2965 HTTP state management specification was recently started: RFC 2965 HTTP state management specification was recently
revised to capture deployment reality [RFC6265]. HTTP Strict revised to capture deployment reality [RFC6265]. HTTP Strict
Transport Layer Security (HSTS) Transport Layer Security (HSTS)
[I-D.ietf-websec-strict-transport-sec] allows Web sites to declare [I-D.ietf-websec-strict-transport-sec] allows Web sites to declare
themselves accessible only via secure connections, and the attemp to themselves accessible only via secure connections, and the attemp to
clarify the Web Origin Concept [I-D.ietf-websec-origin], which covers clarify the Web Origin Concept [I-D.ietf-websec-origin], which covers
the principles that underlies the concept of origin as used to scope the principles that underlies the concept of origin as used to scope
of authority or privilege by user agents. The HTTPbis Working Group of authority or privilege by user agents. The HTTPbis Working Group
skipping to change at page 4, line 14 skipping to change at page 4, line 19
A lot has changed over the last 10 years in the Web eco-system, as 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 briefly described in the sub-sections below, and various efforts are
still ongoing or have recently been started to provide make Web still ongoing or have recently been started to provide make Web
applications even more powerful. Unfortunately, the underlying Web applications even more powerful. Unfortunately, the underlying Web
platform had not been able to keep up with these changes and the platform had not been able to keep up with these changes and the
security weaknesses will only became more apparent. It is time to security weaknesses will only became more apparent. It is time to
tackle this problem and to develop a common understanding of the tackle this problem and to develop a common understanding of the
problem and the desired design goals. problem and the desired design goals.
1.1. From Documents to Mobile Code From Documents to Mobile Code During the last 10 years the Web has
changed quite fundamentally with the widespread usage of
During the last 10 years the Web has changed quite fundamentally with JavaScript. While Web pages have for a long time been dynamically
the widespread usage of JavaScript. While Web pages have for a long generated the ever increasing capabilities of JavaScript, with
time been dynamically generated the ever increasing capabilities of respect to functionality and performance, have changed the
JavaScript, with respect to functionality and performance, have security model. A typical Website collects content from multiple
changed the security model. A typical Website collects content from other Web sites and delivers it to the user's browser and by
multiple other Web sites and delivers it to the user's browser and by delivering code inside HTML new security challenges have emerged.
delivering code inside HTML new security challenges have emerged. Also the standardization landscape had been challenged by this new
Also the standardization landscape had been challenged by this new development and [I-D.tschofenig-post-standardization] documents
development and [I-D.tschofenig-post-standardization] documents architectural implications.
architectural implications.
1.2. Mashups and Data Sharing
With the increasing specialization of Web sites developers started to Mashups and Data Sharing With the increasing specialization of Web
outsource functionality to other sites. Partially this is a user- sites developers started to outsource functionality to other
convenience aspect (e.g., users do not want to create a new address sites. Partially this is a user-convenience aspect (e.g., users
book with every site, publish their latest status on each and every do not want to create a new address book with every site, publish
site again and again) but often also driven by business interestes. their latest status on each and every site again and again) but
In any case, the need to access resources hosted on other sites often also driven by business interestes. In any case, the need
emerged and often these resources were not visible to everyone. to access resources hosted on other sites emerged and often these
Sharing long-term passwords is considered a bad habit and resources were not visible to everyone. Sharing long-term
consequently the Web Authorization (OAuth) protocol passwords is considered a bad habit and consequently the Web
[I-D.ietf-oauth-v2] started to become used widely. OAuth avoids the Authorization (OAuth) protocol [I-D.ietf-oauth-v2] started to
need to share long-term credentials with random Web sites. become used widely. OAuth avoids the need to share long-term
credentials with random Web sites.
1.3. The Real-Time Web The Real-Time Web 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 [I-D.ietf-rtcweb-security] and in
[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.
As HTTP became the protocol of choice for many application While astonishing progress has been made in getting the Web
developers, also because of it's ability to go through firewalls and application eco-system on a par with native applications the
NATs, requirements for asynchronous protocol communication had to be foundation of the Web platform is still unable to address many of the
addressed as well. HTTP, as a request/response protocol, was most common security vulnerabilities; problems the Internet community
initially not designed for pushing data from the server-side to the had been fighting against for over a decade and had solved for other
client as soon as it is available. Long polling requests and other application protocol frameworks and Internet deployment environments.
tricks had been used to allow bi-directional communication between This document aims to provide an introduction to the problem that
the HTTP client and the HTTP server. More recently the BiDirectional will serve as input to an upcoming Web authentication workshop.
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 [I-D.ietf-rtcweb-security] and in
[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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Passwords 3. Passwords
Passwords present a number of challenges, including: Passwords have a long history in authentication protocols on the
Internet. They appear to be convient for users and are easy to
provision to users by many Web site. Still, passwords present a
number of challenges, including:
o Users re-use the same password at multiple sites. This allows a o Users re-use the same password at multiple sites. This allows a
rouge provider to attempt to impersonate users on other sites. rouge Website provider to attempt to impersonate users on other
sites. It also allows a hacker to use stolen passwords obtained
from one site to be used at a non-compromised site.
o Password are often stored in cleartext. In case of a data breach o Password are stored in cleartext in most cases. In case of a data
account information, including the password, becomes accessible to breach account information, including the password, becomes
an attacker. accessible to an attacker.
o Users are tricked in typing their password into a Website o Users are tricked in typing their password into a Website
maintained by the attacker. Furthermore, some Websites request maintained by phishing attempts. Furthermore, some Websites
username and password for access to protected resources maintained request username and password for access to protected resources
by other Websites for usability purposes. maintained by other Websites. While there are technical ways to
avoid the need for such long-term password sharing practice using
OAuth some Websites still ask users.
o many password based authenication protocols are not secure against o Many password based authenication protocols are not secure against
eavesdropping, or allow easy ways for offline dictionary attacks. eavesdropping, or allow easy ways for offline dictionary attacks.
So, why do we need passwords at all? It is easy to dream up o When end systems are compromised as well then a keyboard logger
solutions that uses hardware-based mechanisms (e.g., such as hardware can capture any password sequence a user enters.
tokens). There are, however, reasons why alternatives have not found
widespread deployment on the Internet, such as So, why do we need passwords at all? It is easy to come up with
solutions that use hardware-based mechanisms (e.g., such as OTP
tokens), mobile phones, etc. [Quest] lists some of these mechanisms
and makes an attempt to classify them. There are, however, reasons
why alternatives have not found widespread deployment on the
Internet, such as
o Passwords are cheap (at least the primary costs) for user's and o Passwords are cheap (at least the primary costs) for user's and
service providers. Hardware tokens on the other hand have a service providers. Hardware tokens on the other hand have a
certain amount of cost associated with them. certain amount of cost associated with them.
o Provisioning new users with passwords is easy. Tools and o Provisioning new users with passwords is easy. Tools and
processes exist and are widely accepted. processes exist and are widely accepted.
o Service providers have no external dependency when they manage o Service providers have no external dependency when they manage
user accounts themselves (unlike with many third party identity user accounts themselves (unlike with many third party identity
skipping to change at page 7, line 51 skipping to change at page 8, line 16
is good. is good.
o Passwords can easily be delegated to others. o Passwords can easily be delegated to others.
o Users typically feel quite secure when they are using shared o Users typically feel quite secure when they are using shared
secrets and it fits into their mental model of self-securing. secrets and it fits into their mental model of self-securing.
o Passwords can easily be transferred to multiple devices used by a o Passwords can easily be transferred to multiple devices used by a
single user. single user.
Note that the credential question and the actual form of where these Note that the credential type and the actual form of where these
credentials are stored (e.g., software, hardware) is orthogonal to credentials are stored (e.g., software, hardware) is orthogonal to
the actual identity proofing process. Stronger form of identity the actual identity proofing process. Stronger forms of identity
proofing (e.g., in the form of in person identity proofing with a proofing (e.g., requiring in-person passport verification) can be
passport) can be quite expensive. There are also secondary costs in quite expensive. There are also secondary costs in the form of
the form of support calls and education if credential provisioning is support calls and education if credential provisioning is more
more complicated, as it is often the case with client certificates. complicated, as it is often the case with client certificates.
Regardless how many disadvantages passwords have they will be with us 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 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 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. are used, and if they are used then in a more secure fashion.
4. Roadmap for the Future 4. Roadmap
It is our aim to accomplish three types of goals: It is our aim to accomplish three types of goals:
1. Reduce the number of passwords used 1. Reduce the number of passwords used on the Web
2. Increase the safety and security of how passwords are used 2. Increase security of how passwords are used
3. Broaden the use of other credentials 3. Broaden the use of other, non-password-based credentials
A non-goal of this document is to evaluate ways for improving A non-goal of this document is to evaluate ways for improving
identity proofing, which is a requirement for accomplishing higher identity proofing, which is a requirement for accomplishing higher
levels of assurance. levels of assurance.
We do not believe that the technical community should be attempting We do not believe that the technical community should be attempting
to come up with the single and best solution to satisfy these three 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 goals. We would like to leave room for innovation and allow many
different solutions to co-exist. Therefore, we try to highlight a different solutions to co-exist to best suite their deployment.
few guiding principles that solutions should follow.
Subsequently, we try to highlight a few guiding principles in an
attempt to come with a way forward.
Move Authentication down into the Platform: Move Authentication down into the Platform:
Exposing authentication protocol functionality to the user and Exposing authentication protocol functionality to the user and
requiring Web application developers to write security related requiring Web application developers to write security related
code has proven to lead to various problems. Avoid user code has proven to lead to problems. Avoid user interaction
interaction related to security whenever possible but keep in mind related to security whenever possible but keep in mind that
that authorization decisions, particularly with regard to data authorization decisions, particularly with regard to data sharing,
sharing, require a consent. Ensure that library support is require a consent. Ensure that library support is available for
available for Web developers to allow them easy integration of Web developers to allow them easy integration of security
security functionality into their applications. Unfortunately a functionality into their applications. Unfortunately a protocol
protocol design also needs to consider the transition scenario design also needs to consider the transition scenario where the
where the Web endpoints are not yet upgraded to support the new Web endpoints are not yet upgraded to support the new
functionality and that the authentication functionality is not yet functionality and that the authentication functionality is not yet
available. available.
Design for Growth: Design for Growth:
No single authentication mechanism nor credential is able to No single authentication mechanism nor credential type is able to
fulfill all use cases. Design for later extensions and develop fulfill all use cases. Design for later extensions and develop
the protocol architecture in such a way that components are the protocol architecture in such a way that components are
interchangable. In particular, there are a number of interchangable. In particular, there are a number of
authentication mechanisms already in use in other deployment authentication mechanisms already in use in other deployment
environments. environments.
Context Matters: Context Matters:
Users require context for all disclosures and the sequence of Users require context for all disclosures and the sequence of
interactions matters. A monolitic authentication protocol that interactions matters. A monolitic authentication protocol that
skipping to change at page 12, line 9 skipping to change at page 12, line 9
Design your protocol stack in such a way that developers up the Design your protocol stack in such a way that developers up the
stack can give good advice to users. The use case analysis should stack can give good advice to users. The use case analysis should
include common failure scenarios since error paths need as much include common failure scenarios since error paths need as much
expressiveness as success paths, whereby expressiveness refers to expressiveness as success paths, whereby expressiveness refers to
the ability to communicate with the user about failure cases. the ability to communicate with the user about failure cases.
5. From Two-Party to N-Party 5. From Two-Party to N-Party
It would be short sighted to write about a topic like this without 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 touching a commonly desired way to reduce the number of long term
credentials: federated login credentials: federated logins
Federated login allows a user to utilize his credential obtained from Federated login allows a user to utilize his credential obtained from
one organization, acting as the Identity Provider, for accessing a one organization, acting as the Identity Provider, for accessing a
resource at another, who acts as a Relying Party. While this resource at another entity, who acts as a Relying Party. While this
approach addresses some of our design goals it causes secondary approach addresses some of our design goals it causes secondary
problems to appear; particularly related to privacy. problems to appear - particularly related to privacy.
The following issues in this transition from a two-party to a three- The following issues in this transition from a two-party to a three-
party model are to observe: party model are to observe:
Introduction: Introduction:
How do the three parties find each other? In particular, how does How do the three parties find each other? In particular, how does
the user (via his user agent) inform the relying party about the the user (via his user agent) inform the relying party about the
identity provider it wants to use? How does the relying party identity provider it wants to use? How does the relying party
inform the user agent (and user) about the identity providers it inform the user agent (and user) about the identity providers it
skipping to change at page 17, line 33 skipping to change at page 17, line 33
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
9.2. Informative References 9.2. Informative References
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth Hardt, D. and D. Recordon, "The OAuth 2.0 Authorization
2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work Framework", draft-ietf-oauth-v2-29 (work in progress),
in progress), May 2012. July 2012.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
[I-D.ietf-websec-origin] [I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept", Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-06 (work in progress), draft-ietf-websec-origin-06 (work in progress),
October 2011. October 2011.
[I-D.ietf-websec-strict-transport-sec] [I-D.ietf-websec-strict-transport-sec]
Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", Transport Security (HSTS)",
draft-ietf-websec-strict-transport-sec-07 (work in draft-ietf-websec-strict-transport-sec-11 (work in
progress), May 2012. progress), July 2012.
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "An Extension to Luotonen, A., Sink, E., and L. Stewart, "An Extension to
HTTP : Digest Access Authentication", RFC 2069, HTTP : Digest Access Authentication", RFC 2069,
January 1997. January 1997.
[I-D.ietf-abfab-arch] [I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
"Application Bridging for Federated Access Beyond Web Schaad, "Application Bridging for Federated Access Beyond
(ABFAB) Architecture", draft-ietf-abfab-arch-01 (work in Web (ABFAB) Architecture", draft-ietf-abfab-arch-03 (work
progress), March 2012. in progress), July 2012.
[I-D.ietf-httpbis-p7-auth] [I-D.ietf-httpbis-p7-auth]
Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
progress), March 2012. progress), March 2012.
[I-D.tschofenig-post-standardization] [I-D.tschofenig-post-standardization]
Aboba, B., McPherson, D., Tschofenig, H., and J. Peterson, Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson,
"Trends in Web Applications and the Implications on "Trends in Web Applications and the Implications on
Standardization", draft-tschofenig-post-standardization-01 Standardization", draft-tschofenig-post-standardization-02
(work in progress), October 2011. (work in progress), May 2012.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-03 (work based Applications", draft-ietf-rtcweb-overview-04 (work
in progress), March 2012. in progress), June 2012.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-02 (work in progress), draft-ietf-rtcweb-security-03 (work in progress),
March 2012. June 2012.
Authors' Addresses
Mike Hanson [Quest] "The Quest to Replace Passwords: A Framework for
Mozilla Comparative Evaluation of Web Authentication Schemes, In
Proc. IEEE Symp. on Security and Privacy 2012 (Oakland
2012)", July 2012.
Phone: Authors' Addresses
Email: mhanson@mozilla.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Phone: Phone:
Email: turners@ieca.com Email: turners@ieca.com
Stephen Farrell
Trinity College Dublin
Dublin, 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Mike Hanson
Mozilla
Phone:
Email: mhanson@mozilla.com
 End of changes. 40 change blocks. 
147 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/