draft-ietf-rtcweb-security-05.txt   draft-ietf-rtcweb-security-06.txt 
RTC-Web E. Rescorla RTC-Web E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track July 15, 2013 Intended status: Standards Track January 22, 2014
Expires: January 16, 2014 Expires: July 26, 2014
Security Considerations for WebRTC Security Considerations for WebRTC
draft-ietf-rtcweb-security-05 draft-ietf-rtcweb-security-06
Abstract Abstract
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC". The major use cases between Web browsers, generally called "WebRTC". The major use cases
for WebRTC technology are real-time audio and/or video calls, Web for WebRTC technology are real-time audio and/or video calls, Web
conferencing, and direct data transfer. Unlike most conventional conferencing, and direct data transfer. Unlike most conventional
real-time systems (e.g., SIP-based soft phones) WebRTC communications real-time systems (e.g., SIP-based soft phones) WebRTC communications
are directly controlled by a Web server, which poses new security are directly controlled by a Web server, which poses new security
challenges. For instance, a Web browser might expose a JavaScript challenges. For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call. Unrestricted access API which allows a server to place a video call. Unrestricted access
to such an API would allow any site which a user visited to "bug" a to such an API would allow any site which a user visited to "bug" a
user's computer, capturing any activity which passed in front of user's computer, capturing any activity which passed in front of
their camera. This document defines the WebRTC threat model and their camera. This document defines the WebRTC threat model and
analyzes the security threats of WebRTC in that model. analyzes the security threats of WebRTC in that model.
Legal
THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON
AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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 January 16, 2014. This Internet-Draft will expire on July 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 9, line 31 skipping to change at page 9, line 31
be shared rather than having the user propose it. be shared rather than having the user propose it.
A less obvious threat involves the impact of screen sharing on the A less obvious threat involves the impact of screen sharing on the
Web security model. A key part of the Same Origin Policy is that Web security model. A key part of the Same Origin Policy is that
HTML or JS from site A can reference content from site B and cause HTML or JS from site A can reference content from site B and cause
the browser to load it, but (unless explicitly permitted) cannot see the browser to load it, but (unless explicitly permitted) cannot see
the result. However, if a web application from a site is screen the result. However, if a web application from a site is screen
sharing the browser, then this violates that invariant, with serious sharing the browser, then this violates that invariant, with serious
security consequences. For example, an attacker site might request security consequences. For example, an attacker site might request
screen sharing and then briefly open up a new Window to the user's screen sharing and then briefly open up a new Window to the user's
bank or Gmail account, using screen sharing to read the resulting bank or webmail account, using screen sharing to read the resulting
displayed content. A more sophisticated attack would be open up a displayed content. A more sophisticated attack would be open up a
source view window to a site and use the screen sharing result to source view window to a site and use the screen sharing result to
view anti cross-site request forgery tokens. view anti cross-site request forgery tokens.
These threats suggest that screen/application sharing might need a These threats suggest that screen/application sharing might need a
higher level of user consent than access to the camera or microphone. higher level of user consent than access to the camera or microphone.
4.1.2. Calling Scenarios and User Expectations 4.1.2. Calling Scenarios and User Expectations
While a large number of possible calling scenarios are possible, the While a large number of possible calling scenarios are possible, the
skipping to change at page 21, line 45 skipping to change at page 21, line 45
o Added a section about "malicious peers". o Added a section about "malicious peers".
o Added a section describing screen sharing threats. o Added a section describing screen sharing threats.
o Assorted editorial changes. o Assorted editorial changes.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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-06 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), February 2013. in progress), September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing". [CORS] van Kesteren, A., "Cross-Origin Resource Sharing".
[I-D.ietf-avtcore-6222bis] [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla, Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013. (work in progress), July 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "WebRTC Security Architecture",
draft-ietf-rtcweb-security-arch-06 (work in progress), draft-ietf-rtcweb-security-arch-07 (work in progress),
January 2013. July 2013.
[I-D.kaufman-rtcweb-security-ui] [I-D.kaufman-rtcweb-security-ui]
Kaufman, M., "Client Security User Interface Requirements Kaufman, M., "Client Security User Interface Requirements
for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
progress), June 2011. progress), June 2011.
[I-D.muthu-behave-consent-freshness] [I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., R, R., and H. Kaplan, "STUN Usage Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
for Consent Freshness", for Consent Freshness",
draft-muthu-behave-consent-freshness-03 (work in draft-muthu-behave-consent-freshness-04 (work in
progress), February 2013. progress), July 2013.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
 End of changes. 10 change blocks. 
25 lines changed or deleted 14 lines changed or added

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