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/