draft-ietf-rtcweb-security-arch-00.txt		draft-ietf-rtcweb-security-arch-01.txt
	RTCWEB E. Rescorla		RTCWEB E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track January 22, 2012		Intended status: Standards Track March 12, 2012
	Expires: July 25, 2012		Expires: September 13, 2012
	RTCWEB Security Architecture		RTCWEB Security Architecture
	draft-ietf-rtcweb-security-arch-00		draft-ietf-rtcweb-security-arch-01
	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. The major use cases for RTCWEB technology are		between Web browsers. The major use cases for RTCWEB technology are
	real-time audio and/or video calls, Web conferencing, and direct data		real-time audio and/or video calls, Web conferencing, and direct data
	transfer. Unlike most conventional real-time systems (e.g., SIP-		transfer. Unlike most conventional real-time systems (e.g., SIP-
	based soft phones) RTCWEB communications are directly controlled by		based soft phones) RTCWEB communications are directly controlled by
	some Web server, which poses new security challenges. For instance,		some Web server, which poses new security challenges. For instance,
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	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 July 25, 2012.		This Internet-Draft will expire on September 13, 2012.
	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
	skipping to change at page 3, line 28		skipping to change at page 3, line 28
	5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 10		5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 10
	5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 11		5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 11
	5.3. Communications Consent . . . . . . . . . . . . . . . . . . 12		5.3. Communications Consent . . . . . . . . . . . . . . . . . . 12
	5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 13		5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 13
	5.5. Communications Security . . . . . . . . . . . . . . . . . 13		5.5. Communications Security . . . . . . . . . . . . . . . . . 13
	5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 15		5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6.1. Communications Security . . . . . . . . . . . . . . . . . 16		6.1. Communications Security . . . . . . . . . . . . . . . . . 16
	6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17		6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	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. The major use cases for RTCWEB technology are		between Web browsers. The major use cases for RTCWEB technology are
	real-time audio and/or video calls, Web conferencing, and direct data		real-time audio and/or video calls, Web conferencing, and direct data
	transfer. Unlike most conventional real-time systems, (e.g., SIP-		transfer. Unlike most conventional real-time systems, (e.g., SIP-
	based[RFC3261] soft phones) RTCWEB communications are directly		based[RFC3261] soft phones) RTCWEB communications are directly
	skipping to change at page 8, line 24		skipping to change at page 8, line 24
	microphone. In this case, because Alice is a long-term user of the		microphone. In this case, because Alice is a long-term user of the
	calling service, she has made a permissions grant (i.e., a setting in		calling service, she has made a permissions grant (i.e., a setting in
	the browser) to allow the calling service to access her camera and		the browser) to allow the calling service to access her camera and
	microphone any time it wants. The browser checks this setting when		microphone any time it wants. The browser checks this setting when
	the camera and microphone requests are made and thus allows them.		the camera and microphone requests are made and thus allows them.
	In the current W3C API, once some streams have been added, Alice's		In the current W3C API, once some streams have been added, Alice's
	browser + JS generates a signaling message The format of this data is		browser + JS generates a signaling message The format of this data is
	currently undefined. It may be a complete message as defined by ROAP		currently undefined. It may be a complete message as defined by ROAP
	[I-D.jennings-rtcweb-signaling] or separate media description and		[I-D.jennings-rtcweb-signaling] or separate media description and
	transport messages as defined in JSEP [REF] or may be assembled		transport messages as defined in [I-D.ietf-rtcweb-jsep] or may be
	piecemeal by the JS. In either case, it will contain:		assembled piecemeal by the JS. In either case, it will contain:
	o Media channel information		o Media channel information
	o ICE candidates		o ICE candidates
	o A fingerprint attribute binding the communication to Alice's		o A fingerprint attribute binding the communication to Alice's
	public key [RFC5763]		public key [RFC5763]
	[Note that the above implies that this information should appear in		[Note that it is currently unclear where JSEP will eventually put
	JSEP's transport-level messages.] Prior to sending out the signaling		this information, in the SDP or in the transport info.] Prior to
	message, the PeerConnection code contacts the identity service and		sending out the signaling message, the PeerConnection code contacts
	obtains an assertion binding Alice's identity to her fingerprint.		the identity service and obtains an assertion binding Alice's
	The exact details depend on the identity service (though as discussed		identity to her fingerprint. The exact details depend on the
	in [I-D.rescorla-rtcweb-generic-idp] PeerConnection can be agnostic		identity service (though as discussed in
	to them), but for now it's easiest to think of as a BrowserID		[I-D.rescorla-rtcweb-generic-idp] PeerConnection can be agnostic to
	assertion. The assertion may bind other information to the identity		them), but for now it's easiest to think of as a BrowserID assertion.
	besides the fingerprint, but at minimum it needs to bind the		The assertion may bind other information to the identity besides the
	fingerprint.		fingerprint, but at minimum it needs to bind the fingerprint.
	This message is sent to the signaling server, e.g., by XMLHttpRequest		This message is sent to the signaling server, e.g., by XMLHttpRequest
	[XmlHttpRequest] or by WebSockets		[XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
	[I-D.ietf-hybi-thewebsocketprotocol]. The signaling server processes		processes the message from Alice's browser, determines that this is a
	the message from Alice's browser, determines that this is a call to		call to Bob and sends a signaling message to Bob's browser (again,
	Bob and sends a signaling message to Bob's browser (again, the format		the format is currently undefined). The JS on Bob's browser
	is currently undefined). The JS on Bob's browser processes it, and		processes it, and alerts Bob to the incoming call and to Alice's
	alerts Bob to the incoming call and to Alice's identity. In this		identity. In this case, Alice has provided an identity assertion and
	case, Alice has provided an identity assertion and so Bob's browser		so Bob's browser contacts Alice's identity provider (again, this is
	contacts Alice's identity provider (again, this is done in a generic		done in a generic way so the browser has no specific knowledge of the
	way so the browser has no specific knowledge of the IdP) to verity		IdP) to verity the assertion. This allows the browser to display a
	the assertion. This allows the browser to display a trusted element		trusted element indicating that a call is coming in from Alice. If
	indicating that a call is coming in from Alice. If Alice is in Bob's		Alice is in Bob's address book, then this interface might also
	address book, then this interface might also include her real name, a		include her real name, a picture, etc. The calling site will also
	picture, etc. The calling site will also provide some user interface		provide some user interface element (e.g., a button) to allow Bob to
	element (e.g., a button) to allow Bob to answer the call, though this		answer the call, though this is most likely not part of the trusted
	is most likely not part of the trusted UI.		UI.
	If Bob agrees [I am ignoring early media for now], a PeerConnection		If Bob agrees [I am ignoring early media for now], a PeerConnection
	is instantiated with the message from Alice's side. Then, a similar		is instantiated with the message from Alice's side. Then, a similar
	process occurs as on Alice's browser: Bob's browser verifies that		process occurs as on Alice's browser: Bob's browser verifies that
	the calling service is approved, the media streams are created, and a		the calling service is approved, the media streams are created, and a
	return signaling message containing media information, ICE		return signaling message containing media information, ICE
	candidates, and a fingerprint is sent back to Alice via the signaling		candidates, and a fingerprint is sent back to Alice via the signaling
	service. If Bob has a relationship with an IdP, the message will		service. If Bob has a relationship with an IdP, the message will
	also come with an identity assertion.		also come with an identity assertion.
	skipping to change at page 10, line 16		skipping to change at page 10, line 16
	Once the ICE checks have completed [more specifically, once some ICE		Once the ICE checks have completed [more specifically, once some ICE
	checks have completed], Alice and Bob can set up a secure channel.		checks have completed], Alice and Bob can set up a secure channel.
	This is performed via DTLS [RFC4347] (for the data channel) and DTLS-		This is performed via DTLS [RFC4347] (for the data channel) and DTLS-
	SRTP [RFC5763] for the media channel. Specifically, Alice and Bob		SRTP [RFC5763] for the media channel. Specifically, Alice and Bob
	perform a DTLS handshake on every channel which has been established		perform a DTLS handshake on every channel which has been established
	by ICE. The total number of channels depends on the amount of		by ICE. The total number of channels depends on the amount of
	muxing; in the most likely case we are using both RTP/RTCP mux and		muxing; in the most likely case we are using both RTP/RTCP mux and
	muxing multiple media streams on the same channel, in which case		muxing multiple media streams on the same channel, in which case
	there is only one DTLS handshake. Once the DTLS handshake has		there is only one DTLS handshake. Once the DTLS handshake has
	completed, the keys are extracted and used to key SRTP for the media		completed, the keys are exported [RFC5705] and used to key SRTP for
	channels.		the media channels.
	At this point, Alice and Bob know that they share a set of secure		At this point, Alice and Bob know that they share a set of secure
	data and/or media channels with keys which are not known to any		data and/or media channels with keys which are not known to any
	third-party attacker. If Alice and Bob authenticated via their IdPs,		third-party attacker. If Alice and Bob authenticated via their IdPs,
	then they also know that the signaling service is not attacking them.		then they also know that the signaling service is not attacking them.
	Even if they do not use an IdP, as long as they have minimal trust in		Even if they do not use an IdP, as long as they have minimal trust in
	the signaling service not to perform a man-in-the-middle attack, they		the signaling service not to perform a man-in-the-middle attack, they
	know that their communications are secure against the signaling		know that their communications are secure against the signaling
	service as well.		service as well.
	skipping to change at page 10, line 48		skipping to change at page 10, line 48
	to receive her communications. ICE specifies periodic STUN		to receive her communications. ICE specifies periodic STUN
	keepalizes but only if media is not flowing. Because the consent		keepalizes but only if media is not flowing. Because the consent
	issue is more difficult here, we require RTCWeb implementations to		issue is more difficult here, we require RTCWeb implementations to
	periodically send keepalives. If a keepalive fails and no new ICE		periodically send keepalives. If a keepalive fails and no new ICE
	channels can be established, then the session is terminated.		channels can be established, then the session is terminated.
	5. Detailed Technical Description		5. Detailed Technical Description
	5.1. Origin and Web Security Issues		5.1. Origin and Web Security Issues
	The basic unit of permissions for RTCWEB is the origin		The basic unit of permissions for RTCWEB is the origin [RFC6454].
	[I-D.abarth-origin]. Because the security of the origin depends on		Because the security of the origin depends on being able to
	being able to authenticate content from that origin, the origin can		authenticate content from that origin, the origin can only be
	only be securely established if data is transferred over HTTPS		securely established if data is transferred over HTTPS [RFC2818].
	[RFC2818]. Thus, clients MUST treat HTTP and HTTPS origins as		Thus, clients MUST treat HTTP and HTTPS origins as different
	different permissions domains and SHOULD NOT permit access to any		permissions domains. [Note: this follows directly from the origin
	RTCWEB functionality from scripts fetched over non-secure (HTTP)		security model and is stated here merely for clarity.]
	origins. If an HTTPS origin contains mixed active content
	(regardless of whether it is present on the specific page attempting		Many web browsers currently forbid by default any active mixed
	to access RTCWEB functionality), any access MUST be treated as if it		content on HTTPS pages. I.e., when JS is loaded from an HTTP origin
	came from the HTTP origin. For instance, if a		onto an HTTPS page, an error is displayed and the content is not
	https://www.example.com/example.html loads		executed unless the user overrides the error. Any browser which
	https://www.example.com/example.js and		enforces such a policy will also not permit access to RTCWEB
	http://www.example.org/jquery.js, any attempt by example.js to access		functionality from mixed content pages. It is RECOMMENDED that
	RTCWeb functionality MUST be treated as if it came from		browsers which allow active mixed content nevertheless disable RTCWEB
	http://www.example.com/. Note that many browsers already track mixed		functionality in mixed content settings. [[ OPEN ISSUE: Should this
	content and either forbid it by default or display a warning. [[ OPEN		be a 2119 MUST? It's not clear what set of conditions would make
	ISSUE: This seems to be wrong, but I'm not sure what's right yet. ]]		this OK, other than that browser manufacturers have traditionally
			been permissive here here.]] Note that it is possible for a page
			which was not mixed content to become mixed content during the
			duration of the call. Implementations MAY choose to terminate the
			call or display a warning at that point, but it is also permissible
			to ignore this condition. This is a deliberate implementation
			complexity versus security tradeoff.
	5.2. Device Permissions Model		5.2. Device Permissions Model
	Implementations MUST obtain explicit user consent prior to providing		Implementations MUST obtain explicit user consent prior to providing
	access to the camera and/or microphone. Implementations MUST at		access to the camera and/or microphone. Implementations MUST at
	minimum support the following two permissions models:		minimum support the following two permissions models:
	o Requests for one-time camera/microphone access.		o Requests for one-time camera/microphone access.
	o Requests for permanent access.		o Requests for permanent access.
	skipping to change at page 13, line 8		skipping to change at page 13, line 14
	document takes no position on the split between ICE in JS and ICE in		document takes no position on the split between ICE in JS and ICE in
	the browser. The above text is written the way it is for editorial		the browser. The above text is written the way it is for editorial
	convenience and will be modified appropriately if the WG decides on		convenience and will be modified appropriately if the WG decides on
	ICE in the JS.]		ICE in the JS.]
	Implementations MUST send keepalives no less frequently than every 30		Implementations MUST send keepalives no less frequently than every 30
	seconds regardless of whether traffic is flowing or not. If a		seconds regardless of whether traffic is flowing or not. If a
	keepalive fails then the implementation MUST either attempt to find a		keepalive fails then the implementation MUST either attempt to find a
	new valid path via ICE or terminate media for that ICE component.		new valid path via ICE or terminate media for that ICE component.
	Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding		Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding
	Indications which are one-way and therefore not sufficient. We will		Indications which are one-way and therefore not sufficient. Instead,
	need to define a new mechanism for this. [PROPOSED SOLUTION:		the consent freshness mechanism [I-D.muthu-behave-consent-freshness]
	Replace STUN Binding Indications with STUN Binding Requests and		MUST be used.
	require that a failed transaction causes the results above.]
	5.4. IP Location Privacy		5.4. IP Location Privacy
	A side effect of the default ICE behavior is that the peer learns		A side effect of the default ICE behavior is that the peer learns
	one's IP address, which leaks large amounts of location information,		one's IP address, which leaks large amounts of location information,
	especially for mobile devices. This has negative privacy		especially for mobile devices. This has negative privacy
	consequences in some circumstances. The following two API		consequences in some circumstances. The following two API
	requirements are intended to mitigate this issue:		requirements are intended to mitigate this issue:
	API Requirement: The API MUST provide a mechanism to suppress ICE		API Requirement: The API MUST provide a mechanism to suppress ICE
	skipping to change at page 13, line 41		skipping to change at page 13, line 46
	This prevents the peer from learning one's IP address at all. The		This prevents the peer from learning one's IP address at all. The
	API MUST provide a mechanism for the calling application to		API MUST provide a mechanism for the calling application to
	reconfigure an existing call to add non-TURN candidates. Taken		reconfigure an existing call to add non-TURN candidates. Taken
	together, these requirements allow ICE negotiation to start		together, these requirements allow ICE negotiation to start
	immediately on incoming call notification, thus reducing post-dial		immediately on incoming call notification, thus reducing post-dial
	delay, but also to avoid disclosing the user's IP address until		delay, but also to avoid disclosing the user's IP address until
	they have decided to answer.		they have decided to answer.
	5.5. Communications Security		5.5. Communications Security
	Implementations MUST implement DTLS and DTLS-SRTP. All data channels		Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP
	MUST be secured via DTLS. DTLS-SRTP MUST be offered for every media		[RFC5763][RFC5764]. All data channels MUST be secured via DTLS.
	channel and MUST be the default; i.e., if an implementation receives		DTLS-SRTP MUST be offered for every media channel and MUST be the
	an offer for DTLS-SRTP and SDES and/or plain RTP, DTLS-SRTP MUST be		default; i.e., if an implementation receives an offer for DTLS-SRTP
	selected.		and SDES and/or plain RTP, DTLS-SRTP MUST be selected.
	[OPEN ISSUE: What should the settings be here? MUST?]		[OPEN ISSUE: What should the settings be here? MUST?]
	Implementations MAY support SDES and RTP for media traffic for		Implementations MAY support SDES and RTP for media traffic for
	backward compatibility purposes.		backward compatibility purposes.
	API Requirement: The API MUST provide a mechanism to indicate that a		API Requirement: The API MUST provide a mechanism to indicate that a
	fresh DTLS key pair is to be generated for a specific call. This		fresh DTLS key pair is to be generated for a specific call. This
	is intended to allow for unlinkability. Note that there are also		is intended to allow for unlinkability. Note that there are also
	settings where it is attractive to use the same keying material		settings where it is attractive to use the same keying material
	repeatedly, especially those with key continuity-based		repeatedly, especially those with key continuity-based
	skipping to change at page 17, line 7		skipping to change at page 17, line 10
	However, these privacy protections come at a performance cost in		However, these privacy protections come at a performance cost in
	terms of using TURN relays and, in the latter case, delaying ICE.		terms of using TURN relays and, in the latter case, delaying ICE.
	Sites SHOULD make users aware of these tradeoffs.		Sites SHOULD make users aware of these tradeoffs.
	Note that the protections provided here assume a non-malicious		Note that the protections provided here assume a non-malicious
	calling service. As the calling service always knows the users		calling service. As the calling service always knows the users
	status and (absent the use of a technology like Tor) their IP		status and (absent the use of a technology like Tor) their IP
	address, they can violate the users privacy at will. Users who wish		address, they can violate the users privacy at will. Users who wish
	privacy against the calling sites they are using must use separate		privacy against the calling sites they are using must use separate
	privacy enhancing technologies such as Tor.		privacy enhancing technologies such as Tor. Combined RTCWEB/Tor
			implementations SHOULD arrange to route the media as well as the
			signaling through Tor. [Currently this will produce very suboptimal
			performance.]
	6.3. Denial of Service		6.3. Denial of Service
	The consent mechanisms described in this document are intended to		The consent mechanisms described in this document are intended to
	mitigate denial of service attacks in which an attacker uses clients		mitigate denial of service attacks in which an attacker uses clients
	to send large amounts of traffic to a victim without the consent of		to send large amounts of traffic to a victim without the consent of
	the victim. While these mechanisms are sufficient to protect victims		the victim. While these mechanisms are sufficient to protect victims
	who have not implemented RTCWEB at all, RTCWEB implementations need		who have not implemented RTCWEB at all, RTCWEB implementations need
	to be more careful.		to be more careful.
	skipping to change at page 17, line 40		skipping to change at page 17, line 46
	(which the attacker cannot control).		(which the attacker cannot control).
	Another related attack is for the signaling service to swap the ICE		Another related attack is for the signaling service to swap the ICE
	candidates for the audio and video streams, thus forcing a browser to		candidates for the audio and video streams, thus forcing a browser to
	send video to the sink that the other victim expects will contain		send video to the sink that the other victim expects will contain
	audio (perhaps it is only expecting audio!) potentially causing		audio (perhaps it is only expecting audio!) potentially causing
	overload. Muxing multiple media flows over a single transport makes		overload. Muxing multiple media flows over a single transport makes
	it harder to individually suppress a single flow by denying ICE		it harder to individually suppress a single flow by denying ICE
	keepalives. Media-level (RTCP) mechanisms must be used in this case.		keepalives. Media-level (RTCP) mechanisms must be used in this case.
			[TODO: Write up Magnus's ICE forking attack when we get some clarity
			on it.]
	Note that attacks based on confusing one end or the other about		Note that attacks based on confusing one end or the other about
	consent are possible primarily even in the face of the third-party		consent are possible primarily even in the face of the third-party
	identity mechanism as long as major parts of the signaling messages		identity mechanism as long as major parts of the signaling messages
	are not signed. On the other hand, signing the entire message		are not signed. On the other hand, signing the entire message
	severely restricts the capabilities of the calling application, so		severely restricts the capabilities of the calling application, so
	there are difficult tradeoffs here.		there are difficult tradeoffs here.
	7. Acknowledgements		7. Acknowledgements
	Bernard Aboba, Harald Alvestrand, Cullen Jennings, Hadriel Kaplan,		Bernard Aboba, Harald Alvestrand, Cullen Jennings, Hadriel Kaplan,
	Matthew Kaufman, Magnus Westerland.		Matthew Kaufman, Magnus Westerland.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.abarth-origin]
	Barth, A., "The Web Origin Concept",
	draft-abarth-origin-09 (work in progress), November 2010.
	[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-01 (work in progress),		draft-ietf-rtcweb-security-01 (work in progress),
	October 2011.		October 2011.
			[I-D.muthu-behave-consent-freshness]
			Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for
			Consent Freshness",
			draft-muthu-behave-consent-freshness-00 (work in
			progress), March 2012.
	[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.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
			[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security", RFC 4347, April 2006.
			[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
			(ICE): A Protocol for Network Address Translator (NAT)
			Traversal for Offer/Answer Protocols", RFC 5245,
			April 2010.
			[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
			for Establishing a Secure Real-time Transport Protocol
			(SRTP) Security Context Using Datagram Transport Layer
			Security (DTLS)", RFC 5763, May 2010.
			[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
			Security (DTLS) Extension to Establish Keys for the Secure
			Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
			[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
			December 2011.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-hybi-thewebsocketprotocol]		[I-D.ietf-rtcweb-jsep]
	Fette, I. and A. Melnikov, "The WebSocket protocol",		Uberti, J. and C. Jennings, "Javascript Session
	draft-ietf-hybi-thewebsocketprotocol-17 (work in		Establishment Protocol", draft-ietf-rtcweb-jsep-00 (work
	progress), September 2011.		in progress), March 2012.
	[I-D.jennings-rtcweb-signaling]		[I-D.jennings-rtcweb-signaling]
	Jennings, C., Rosenberg, J., Uberti, J., and R. Jesup,		Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
	"RTCWeb Offer/Answer Protocol (ROAP)",		Answer Protocol (ROAP)",
	draft-jennings-rtcweb-signaling-01 (work in progress),		draft-jennings-rtcweb-signaling-01 (work in progress),
	October 2011.		October 2011.
	[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.rescorla-rtcweb-generic-idp]		[I-D.rescorla-rtcweb-generic-idp]
	Rescorla, E., "RTCWeb Generic Identity Provider		Rescorla, E., "RTCWeb Generic Identity Provider
	Interface", draft-rescorla-rtcweb-generic-idp-00 (work in		Interface", draft-rescorla-rtcweb-generic-idp-00 (work in
	progress), January 2012.		progress), January 2012.
	[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.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Security", RFC 4347, April 2006.		Layer Security (TLS)", RFC 5705, March 2010.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245,
	April 2010.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	for Establishing a Secure Real-time Transport Protocol		RFC 6455, December 2011.
	(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, May 2010.
	[XmlHttpRequest]		[XmlHttpRequest]
	van Kesteren, A., "XMLHttpRequest Level 2".		van Kesteren, A., "XMLHttpRequest Level 2".
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
	RTFM, Inc.		RTFM, Inc.
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
End of changes. 22 change blocks.
	84 lines changed or deleted		110 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/