draft-ietf-rtcweb-security-arch-03.txt		draft-ietf-rtcweb-security-arch-04.txt
	RTCWEB E. Rescorla		RTCWEB E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track July 16, 2012		Intended status: Standards Track October 22, 2012
	Expires: January 17, 2013		Expires: April 25, 2013
	RTCWEB Security Architecture		RTCWEB Security Architecture
	draft-ietf-rtcweb-security-arch-03		draft-ietf-rtcweb-security-arch-04
	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 enabling real-time		tasked with standardizing protocols for enabling real-time
	communications within user-agents using web technologies (e.g		communications within user-agents using web technologies (e.g
	JavaScript). The major use cases for RTCWEB technology are real-time		JavaScript). The major use cases for RTCWEB technology are real-time
	audio and/or video calls, Web conferencing, and direct data transfer.		audio and/or video calls, Web conferencing, and direct data transfer.
	Unlike most conventional real-time systems (e.g., SIP-based soft		Unlike most conventional real-time systems (e.g., SIP-based soft
	phones) RTCWEB communications are directly controlled by some Web		phones) RTCWEB communications are directly controlled by some Web
	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 January 17, 2013.		This Internet-Draft will expire on April 25, 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
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 5		3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6
	3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 5		3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 7		4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8
	4.2. Media Consent Verification . . . . . . . . . . . . . . . . 9		4.2. Media Consent Verification . . . . . . . . . . . . . . . . 10
	4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 9		4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 11
	4.4. Communications and Consent Freshness . . . . . . . . . . . 10		4.4. Communications and Consent Freshness . . . . . . . . . . . 11
	5. Detailed Technical Description . . . . . . . . . . . . . . . . 10		5. Detailed Technical Description . . . . . . . . . . . . . . . . 11
	5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 10		5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 11
	5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 11		5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 12
	5.3. Communications Consent . . . . . . . . . . . . . . . . . . 12		5.3. Communications Consent . . . . . . . . . . . . . . . . . . 14
	5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 13		5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 14
	5.5. Communications Security . . . . . . . . . . . . . . . . . 14		5.5. Communications Security . . . . . . . . . . . . . . . . . 15
	5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 15		5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 16
	5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 16		5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 17
	5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 17		5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 19
	5.6.3. Items for Standardization . . . . . . . . . . . . . . 19		5.6.3. Binding Identity Assertions to JSEP Offer/Answer
	5.6.4. Binding Identity Assertions to JSEP Offer/Answer		Transactions . . . . . . . . . . . . . . . . . . . . . 20
	Transactions . . . . . . . . . . . . . . . . . . . . . 19		5.6.3.1. Input to Assertion Generation Process . . . . . . 20
	5.6.4.1. Input to Assertion Generation Process . . . . . . 19		5.6.3.2. Carrying Identity Assertions . . . . . . . . . . . 21
	5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 20		5.6.4. IdP Interaction Details . . . . . . . . . . . . . . . 21
	5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 20		5.6.4.1. General Message Structure . . . . . . . . . . . . 21
	5.6.5.1. General Message Structure . . . . . . . . . . . . 20		5.6.4.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 22
	5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 21		5.7. Security Considerations . . . . . . . . . . . . . . . . . 27
	5.7. Security Considerations . . . . . . . . . . . . . . . . . 26		5.7.1. Communications Security . . . . . . . . . . . . . . . 27
	5.7.1. Communications Security . . . . . . . . . . . . . . . 26		5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
	5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 27		5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 28
	5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 27		5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 29
	5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 28		5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 29
	5.7.4.1. IdP Well-known URI . . . . . . . . . . . . . . . . 29		5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 30
	5.7.4.2. Privacy of IdP-generated identities and the		5.7.4.3. Privacy of IdP-generated identities and the
	hosting site . . . . . . . . . . . . . . . . . . . 29		hosting site . . . . . . . . . . . . . . . . . . . 30
	5.7.4.3. Security of Third-Party IdPs . . . . . . . . . . . 29		5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 30
	5.7.4.4. Web Security Feature Interactions . . . . . . . . 29		5.7.4.5. Web Security Feature Interactions . . . . . . . . 30
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
	7. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 30		7. Changes since -03 . . . . . . . . . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30		8. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 31
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 30		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	8.2. Informative References . . . . . . . . . . . . . . . . . . 31		9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	Appendix A. Example IdP Bindings to Specific Protocols . . . . . 32		9.2. Informative References . . . . . . . . . . . . . . . . . . 32
	A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 32		Appendix A. Example IdP Bindings to Specific Protocols . . . . . 33
	A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 35		A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 33
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36		A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 36
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
	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
	controlled by some Web server, as shown in Figure 1.		controlled by some Web server, as shown in Figure 1.
	skipping to change at page 5, line 24		skipping to change at page 6, line 24
	have a functional system. Other network elements fall into two		have a functional system. Other network elements fall into two
	categories: those which can be authenticated by the browser and thus		categories: those which can be authenticated by the browser and thus
	are partly trusted--though to the minimum extent necessary--and those		are partly trusted--though to the minimum extent necessary--and those
	which cannot be authenticated and thus are untrusted. This is a		which cannot be authenticated and thus are untrusted. This is a
	natural extension of the end-to-end principle.		natural extension of the end-to-end principle.
	3.1. Authenticated Entities		3.1. Authenticated Entities
	There are two major classes of authenticated entities in the system:		There are two major classes of authenticated entities in the system:
	o Calling services: Web sites whose origin we can verify (optimally		o Calling services: Web sites whose origin we can verify (in
	via HTTPS, but in some cases because we are on a topologically		practice this means HTTPS).
	restricted network, such as behind a firewall).
	o Other users: RTCWEB peers whose origin we can verify		o Other users: RTCWEB peers whose origin we can verify
	cryptographically (optimally via DTLS-SRTP).		cryptographically (optimally via DTLS-SRTP).
	Note that merely being authenticated does not make these entities		Note that merely being authenticated does not make these entities
	trusted. For instance, just because we can verify that		trusted. For instance, just because we can verify that
	https://www.evil.org/ is owned by Dr. Evil does not mean that we can		https://www.evil.org/ is owned by Dr. Evil does not mean that we can
	trust Dr. Evil to access our camera and microphone. However, it		trust Dr. Evil to access our camera and microphone. However, it
	gives the user an opportunity to determine whether he wishes to trust		gives the user an opportunity to determine whether he wishes to trust
	Dr. Evil or not; after all, if he desires to contact Dr. Evil		Dr. Evil or not; after all, if he desires to contact Dr. Evil
	(perhaps to arrange for ransom payment), it's safe to temporarily		(perhaps to arrange for ransom payment), it's safe to temporarily
	skipping to change at page 8, line 21		skipping to change at page 9, line 21
	two MediaStreams, one connected to an audio input and one connected		two MediaStreams, one connected to an audio input and one connected
	to a video input. At this point the first security check is		to a video input. At this point the first security check is
	required: untrusted origins are not allowed to access the camera and		required: untrusted origins are not allowed to access the camera and
	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 [I-D.ietf-rtcweb-jsep]		browser + JS generates a signaling message The format of this data is
	contianing:		currently undefined. It may be a complete message as defined by ROAP
			[I-D.jennings-rtcweb-signaling] or separate media description and
			transport messages as defined in [I-D.ietf-rtcweb-jsep] or may be
			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]
	Prior to sending out the signaling message, the PeerConnection code		[Note that it is currently unclear where JSEP will eventually put
	contacts the identity service and obtains an assertion binding		this information, in the SDP or in the transport info.] Prior to
	Alice's identity to her fingerprint. The exact details depend on the		sending out the signaling message, the PeerConnection code contacts
			the identity service and obtains an assertion binding Alice's
			identity to her fingerprint. The exact details depend on the
	identity service (though as discussed in Section 5.6 PeerConnection		identity service (though as discussed in Section 5.6 PeerConnection
	can be agnostic to them), but for now it's easiest to think of as a		can be agnostic to them), but for now it's easiest to think of as a
	BrowserID assertion. The assertion may bind other information to the		BrowserID assertion. The assertion may bind other information to the
	identity besides the fingerprint, but at minimum it needs to bind the		identity besides the fingerprint, but at minimum it needs to bind the
	fingerprint.		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 [RFC6455] The signaling server		[XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
	processes the message from Alice's browser, determines that this is a		processes the message from Alice's browser, determines that this is a
	call to Bob and sends a signaling message to Bob's browser (again,		call to Bob and sends a signaling message to Bob's browser (again,
	skipping to change at page 10, line 33		skipping to change at page 11, line 41
	anticlimactic: Alice and Bob exchange data protected by the keys		anticlimactic: Alice and Bob exchange data protected by the keys
	negotiated by DTLS. Because of the security guarantees discussed in		negotiated by DTLS. Because of the security guarantees discussed in
	the previous sections, they know that the communications are		the previous sections, they know that the communications are
	encrypted and authenticated.		encrypted and authenticated.
	The one remaining security property we need to establish is "consent		The one remaining security property we need to establish is "consent
	freshness", i.e., allowing Alice to verify that Bob is still prepared		freshness", i.e., allowing Alice to verify that Bob is still prepared
	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. As described in Section 5.3, these
	channels can be established, then the session is terminated.		keepalives MUST be based on the consent freshness mechanism specified
			in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no
			new ICEchannels 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 [RFC6454].		The basic unit of permissions for RTCWEB is the origin [RFC6454].
	Because the security of the origin depends on being able to		Because the security of the origin depends on being able to
	authenticate content from that origin, the origin can only be		authenticate content from that origin, the origin can only be
	securely established if data is transferred over HTTPS [RFC2818].		securely established if data is transferred over HTTPS [RFC2818].
	Thus, clients MUST treat HTTP and HTTPS origins as different		Thus, clients MUST treat HTTP and HTTPS origins as different
	skipping to change at page 11, line 42		skipping to change at page 13, line 7
	refuse all permissions grants for HTTP origins, but it is RECOMMENDED		refuse all permissions grants for HTTP origins, but it is RECOMMENDED
	that currently they support one-time camera/microphone access.		that currently they support one-time camera/microphone access.
	In addition, they SHOULD support requests for access to a single		In addition, they SHOULD support requests for access to a single
	communicating peer. E.g., "Call customerservice@ford.com". Browsers		communicating peer. E.g., "Call customerservice@ford.com". Browsers
	servicing such requests SHOULD clearly indicate that identity to the		servicing such requests SHOULD clearly indicate that identity to the
	user when asking for permission.		user when asking for permission.
	API Requirement: The API MUST provide a mechanism for the requesting		API Requirement: The API MUST provide a mechanism for the requesting
	JS to indicate which of these forms of permissions it is		JS to indicate which of these forms of permissions it is
	requesting. This allows the browser to know what sort of user		requesting. This allows the client to know what sort of user
	interface experience to provide to the user, including what		interface experience to provide, i.e., to allow the client to
	permissions to request from the user and hence that to enforce		clearly indicate to the user what he is agreeing to. In
	later. For instance, browsers might display a non-invasive door		particular, browsers might display a non-invasive door hanger
	hanger ("some features of this site may not work..." when asking		("some features of this site may not work..." when asking for
	for long-term permissions) but a more invasive UI ("here is your		long-term permissions) but a more invasive UI ("here is your own
	own video") for single-call permissions. The API MAY grant weaker		video") for single-call permissions. The API MAY grant weaker
	permissions than the JS asked for if the user chooses to authorize		permissions than the JS asked for if the user chooses to authorize
	only those permissions, but if it intends to grant stronger ones		only those permissions, but if it intends to grant stronger ones
	it SHOULD display the appropriate UI for those permissions and		it SHOULD display the appropriate UI for those permissions and
	MUST clearly indicate what permissions are being requested.		MUST clearly indicate what permissions are being requested.
	API Requirement: The API MUST provide a mechanism for the requesting		API Requirement: The API MUST provide a mechanism for the requesting
	JS to relinquish the ability to see or modify the media (e.g., via		JS to relinquish the ability to see or modify the media (e.g., via
	MediaStream.record()). Combined with secure authentication of the		MediaStream.record()). Combined with secure authentication of the
	communicating peer, this allows a user to be sure that the calling		communicating peer, this allows a user to be sure that the calling
	site is not accessing or modifying their conversion.		site is not accessing or modifying their conversion.
	skipping to change at page 12, line 48		skipping to change at page 14, line 12
	address book (this only works with address book integration, of		address book (this only works with address book integration, of
	course).		course).
	Implementations SHOULD also provide a different user interface		Implementations SHOULD also provide a different user interface
	indication when calls are in progress to users whose identities are		indication when calls are in progress to users whose identities are
	directly verifiable. Section 5.5 provides more on this.		directly verifiable. Section 5.5 provides more on this.
	5.3. Communications Consent		5.3. Communications Consent
	Browser client implementations of RTCWEB MUST implement ICE. Server		Browser client implementations of RTCWEB MUST implement ICE. Server
	gateway implementations which operate only at public IP addresses		gateway implementations which operate only at public IP addresses may
	MUST implement either full ICE or ICE-Lite.		implement ICE-Lite instead of ICE but MUST implement one of the two.
	Browser implementations MUST verify reachability via ICE prior to		Browser implementations MUST verify reachability via ICE prior to
	sending any non-ICE packets to a given destination. Implementations		sending any non-ICE packets to a given destination. Implementations
	MUST NOT provide the ICE transaction ID to JavaScript during the		MUST NOT provide the ICE transaction ID to JavaScript during the
	lifetime of the transaction (i.e., during the period when the ICE		lifetime of the transaction (i.e., during the period when the ICE
	stack would accept a new response for that transaction). [Note:		stack would accept a new response for that transaction). [Note:
	this document takes no position on the split between ICE in JS and		this 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		ICE in the browser. The above text is written the way it is for
	editorial convenience and will be modified appropriately if the WG		editorial convenience and will be modified appropriately if the WG
	decides on ICE in the JS.] The JS MUST NOT be permitted to control		decides on ICE in the JS.]
	the local ufrag and password, though it of course knows it.
	While continuing consent is required, that ICE [RFC5245]; Section 10		Implementations MUST send keepalives no less frequently than every 30
	keepalives STUN Binding Indications are one-way and therefore not		seconds regardless of whether traffic is flowing or not. If a
	sufficient. The current WG consensus is to use ICE Binding Requests		keepalive fails then the implementation MUST either attempt to find a
	for continuing consent freshness. ICE already requires that		new valid path via ICE or terminate media for that ICE component.
	implementations respond to such requests, so this approach is		Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding
	maximally compatible. A separate document will profile the ICE		Indications which are one-way and therefore not sufficient. Instead,
	timers to be used [[TODO: insert REF here when available.]]		the consent freshness mechanism [I-D.muthu-behave-consent-freshness]
			MUST be used.
	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 API requirements in this		consequences in some circumstances. The API requirements in this
	section are intended to mitigate this issue. Note that these		section are intended to mitigate this issue. Note that these
	requirements are NOT intended to protect the user's IP address from a		requirements are NOT intended to protect the user's IP address from a
	malicious site. In general, the site will learn at least a user's		malicious site. In general, the site will learn at least a user's
	skipping to change at page 13, line 50		skipping to change at page 15, line 16
	suppress ICE negotiation (though perhaps to allow candidate		suppress ICE negotiation (though perhaps to allow candidate
	gathering) until the user has decided to answer the call [note:		gathering) until the user has decided to answer the call [note:
	determining when the call has been answered is a question for the		determining when the call has been answered is a question for the
	JS.] This enables a user to prevent a peer from learning their IP		JS.] This enables a user to prevent a peer from learning their IP
	address if they elect not to answer a call and also from learning		address if they elect not to answer a call and also from learning
	whether the user is online.		whether the user is online.
	API Requirement: The API MUST provide a mechanism for the calling		API Requirement: The API MUST provide a mechanism for the calling
	application JS to indicate that only TURN candidates are to be		application JS to indicate that only TURN candidates are to be
	used. This prevents the peer from learning one's IP address at		used. This prevents the peer from learning one's IP address at
	all.		all. The API MUST provide a mechanism for the calling application
			to reconfigure an existing call to add non-TURN candidates. Taken
	API Requirement: The API MUST provide a mechanism for the calling		together, these requirements allow ICE negotiation to start
	application to reconfigure an existing call to add non-TURN		immediately on incoming call notification, thus reducing post-dial
	candidates. Taken together, this and the previous requirement		delay, but also to avoid disclosing the user's IP address until
	allow ICE negotiation to start immediately on incoming call		they have decided to answer. They also allow users to completely
	notification, thus reducing post-dial delay, but also to avoid		hide their IP address for the duration of the call. Finally, they
	disclosing the user's IP address until they have decided to		allow a mechanism for the user to optimize performance by
	answer. They also allow users to completely hide their IP address		reconfiguring to allow non-TURN candidates during an active call
	for the duration of the call. Finally, they allow a mechanism for		if the user decides they no longer need to hide their IP address
	the user to optimize performance by reconfiguring to allow non-
	turn candidates during an active call if the user decides they no
	longer need to hide their IP address
	5.5. Communications Security		5.5. Communications Security
	Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP		Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP
	[RFC5763][RFC5764]. All data channels MUST be secured via DTLS.		[RFC5763][RFC5764]. All data channels MUST be secured via DTLS.
	DTLS-SRTP MUST be offered for every media channel and MUST be the		DTLS-SRTP MUST be offered for every media channel and MUST be the
	default; i.e., if an implementation receives an offer for DTLS-SRTP		default; i.e., if an implementation receives an offer for DTLS-SRTP
	and SDES, DTLS-SRTP MUST be selected. Media traffic MUST NOT be sent		and SDES, DTLS-SRTP MUST be selected. Media traffic MUST NOT be sent
	over plain (unencrypted) RTP.		over plain (unencrypted) RTP.
	[OPEN ISSUE: What should the settings be here? MUST?]		[OPEN ISSUE: What should the settings be here? MUST?]
	Implementations MAY support SDES for media traffic for backward		Implementations MAY support SDES and RTP for media traffic for
	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
	authentication.		authentication.
	API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the		API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the
	JS to obtain the negotiated keying material. This requirement		JS to obtain the negotiated keying material. This requirement
	skipping to change at page 15, line 16		skipping to change at page 16, line 26
	determine the security characteristics for transmissions of		determine the security characteristics for transmissions of
	their microphone audio and camera video.		their microphone audio and camera video.
	* The "security characteristics" MUST include an indication as to		* The "security characteristics" MUST include an indication as to
	whether the cryptographic keys were delivered out-of-band (from		whether the cryptographic keys were delivered out-of-band (from
	a server) or were generated as a result of a pairwise		a server) or were generated as a result of a pairwise
	negotiation.		negotiation.
	* If the far endpoint was directly verified, either via a third-		* If the far endpoint was directly verified, either via a third-
	party verifiable X.509 certificate or via a Web IdP mechanism		party verifiable X.509 certificate or via a Web IdP mechanism
	(see Section 5.6) the "security characteristics" MUST include		(see Section 5.6) the "security characteristics" MUST include
	the verified information.		the verified information.
	The following properties are more likely to require some "drill-		The following properties are more likely to require some "drill-
	down" from the user:		down" from the user:
	* The "security characteristics" MUST indicate the cryptographic		* The security characteristics MUST indicate the cryptographic
	algorithms in use (For example: "AES-CBC" or "Null Cipher".)		algorithms in use (For example: "AES-CBC" or "Null Cipher".)
	* The "security characteristics" MUST indicate whether PFS is		* The "security characteristics" MUST indicate whether PFS is
	provided.		provided.
	* The "security characteristics" MUST include some mechanism to		* The "security characteristics" MUST include some mechanism to
	allow an out-of-band verification of the peer, such as a		allow an out-of-band verification of the peer, such as a
	certificate fingerprint or an SAS.		certificate fingerprint or an SAS.
	5.6. Web-Based Peer Authentication		5.6. Web-Based Peer Authentication
	In a number of cases, it is desirable for the endpoint (i.e., the		In a number of cases, it is desirable for the endpoint (i.e., the
	skipping to change at page 15, line 42		skipping to change at page 16, line 51
	side without trusting only the signaling service to which they are		side without trusting only the signaling service to which they are
	connected. For instance, users may be making a call via a federated		connected. For instance, users may be making a call via a federated
	system where they wish to get direct authentication of the other		system where they wish to get direct authentication of the other
	side. Alternately, they may be making a call on a site which they		side. Alternately, they may be making a call on a site which they
	minimally trust (such as a poker site) but to someone who has an		minimally trust (such as a poker site) but to someone who has an
	identity on a site they do trust (such as a social network.)		identity on a site they do trust (such as a social network.)
	Recently, a number of Web-based identity technologies (OAuth,		Recently, a number of Web-based identity technologies (OAuth,
	BrowserID, Facebook Connect), etc. have been developed. While the		BrowserID, Facebook Connect), etc. have been developed. While the
	details vary, what these technologies share is that they have a Web-		details vary, what these technologies share is that they have a Web-
	based (i.e., HTTP/HTTPS) identity provider which attests to your		based (i.e., HTTP/HTTPS identity provider) which attests to your
	identity. For instance, if I have an account at example.org, I could		identity. For instance, if I have an account at example.org, I could
	use the example.org identity provider to prove to others that I was		use the example.org identity provider to prove to others that I was
	alice@example.org. The development of these technologies allows us		alice@example.org. The development of these technologies allows us
	to separate calling from identity provision: I could call you on		to separate calling from identity provision: I could call you on
	Poker Galaxy but identify myself as alice@example.org.		Poker Galaxy but identify myself as alice@example.org.
	Whatever the underlying technology, the general principle is that the		Whatever the underlying technology, the general principle is that the
	party which is being authenticated is NOT the signaling site but		party which is being authenticated is NOT the signaling site but
	rather the user (and their browser). Similarly, the relying party is		rather the user (and their browser). Similarly, the relying party is
	the browser and not the signaling site. Thus, the browser MUST		the browser and not the signaling site. Thus, the browser MUST
	securely generate the input to the IdP assertion process and MUST		securely generate the input to the IdP assertion process and MUST
	securely display the results of the verification process to the user		securely display the results of the verification process to the user
	in a way which cannot be imitated by the calling site.		in a way which cannot be imitated by the calling site.
	The mechanisms defined in this document do not require the browser to		In order to make this work, we must standardize the following items:
			o The precise information from the signaling message that must be
			cryptographically bound to the user's identity and a mechanism for
			carrying assertions in JSEP messages. Section 5.6.3
			o The interface to the IdP. Section 5.6.4 specifies a specific
			protocol mechanism which allows the use of any identity protocol
			without requiring specific further protocol support in the browser
			o The JavaScript interfaces which the calling application can use to
			specify the IdP to use to generate assertions and to discover what
			assertions were received.
			The first two items are defined in this document. The final one is
			defined in the companion W3C WebRTC API specification [TODO:REF]
			The mechanisms in this document do not require the browser to
	implement any particular identity protocol or to support any		implement any particular identity protocol or to support any
	particular IdP. Instead, this document provides a generic interface		particular IdP. Instead, this document provides a generic interface
	which any IdP can implement. Thus, new IdPs and protocols can be		which any IdP can implement. Thus, new IdPs and protocols can be
	introduced without change to either the browser or the calling		introduced without change to either the browser or the calling
	service. This avoids the need to make a commitment to any particular		service. This avoids the need to make a commitment to any particular
	identity protocol, although browsers may opt to directly implement		identity protocol, although browsers may opt to directly implement
	some identity protocols in order to provide superior performance or		some identity protocols in order to provide superior performance or
	UI properties.		UI properties.
	5.6.1. Trust Relationships: IdPs, APs, and RPs		5.6.1. Trust Relationships: IdPs, APs, and RPs
	skipping to change at page 19, line 5		skipping to change at page 20, line 22
	This approach allows us to decouple the browser from any particular		This approach allows us to decouple the browser from any particular
	identity provider; the browser need only know how to load the IdP's		identity provider; the browser need only know how to load the IdP's
	JavaScript--which is deterministic from the IdP's identity--and the		JavaScript--which is deterministic from the IdP's identity--and the
	generic protocol for requesting and verifying assertions. The IdP		generic protocol for requesting and verifying assertions. The IdP
	provides whatever logic is necessary to bridge the generic protocol		provides whatever logic is necessary to bridge the generic protocol
	to the IdP's specific requirements. Thus, a single browser can		to the IdP's specific requirements. Thus, a single browser can
	support any number of identity protocols, including being forward		support any number of identity protocols, including being forward
	compatible with IdPs which did not exist at the time the browser was		compatible with IdPs which did not exist at the time the browser was
	written.		written.
	5.6.3. Items for Standardization		5.6.3. Binding Identity Assertions to JSEP Offer/Answer Transactions
	In order to make this work, we must standardize the following items:
	o The precise information from the signaling message that must be
	cryptographically bound to the user's identity and a mechanism for
	carrying assertions in JSEP messages. Section 5.6.4
	o The interface to the IdP. Section 5.6.5 specifies a specific
	protocol mechanism which allows the use of any identity protocol
	without requiring specific further protocol support in the browser
	o The JavaScript interfaces which the calling application can use to
	specify the IdP to use to generate assertions and to discover what
	assertions were received.
	The first two items are defined in this document. The final one is
	defined in the companion W3C WebRTC API specification [TODO:REF]
	5.6.4. Binding Identity Assertions to JSEP Offer/Answer Transactions
	5.6.4.1. Input to Assertion Generation Process		5.6.3.1. Input to Assertion Generation Process
	As discussed above, an identity assertion binds the user's identity		As discussed above, an identity assertion binds the user's identity
	(as asserted by the IdP) to the JSEP offer/exchange transaction and		(as asserted by the IdP) to the JSEP offer/exchange transaction and
	specifically to the media. In order to achieve this, the		specifically to the media. In order to achieve this, the
	PeerConnection must provide the DTLS-SRTP fingerprint to be bound to		PeerConnection must provide the DTLS-SRTP fingerprint to be bound to
	the identity. This is provided in a JSON structure for		the identity. This is provided in a JSON structure for
	extensibility, as shown below:		extensibility, as shown below:
	{		{
	"fingerprint" :		"fingerprint" : {
	{		{
	"algorithm":"SHA-1",		"algorithm":"SHA-1",
	"digest":"4A:AD:B9:B1:3F:...:E5:7C:AB"		"digest":"4A:AD:B9:B1:3F:...:E5:7C:AB"
	}		}
	}		}
	The "algorithm" and digest values correspond directly to the		The "algorithm" and digest values correspond directly to the
	algorithm and digest in the a=fingerprint line of the SDP.		algorithm and digest in the a=fingerprint line of the SDP.
	Note: this structure does not need to be interpreted by the IdP or		Note: this structure does not need to be interpreted by the IdP or
	the IdP proxy. It is consumed solely by the RP's browser. The IdP		the IdP proxy. It is consumed solely by the RP's browser. The IdP
	merely treats it as an opaque value to be attested to. Thus, new		merely treats it as an opaque value to be attested to. Thus, new
	parameters can be added to the assertion without modifying the IdP.		parameters can be added to the assertion without modifying the IdP.
	5.6.4.2. Carrying Identity Assertions		5.6.3.2. Carrying Identity Assertions
	Once an IdP has generated an assertion, the JSEP message. This is		Once an IdP has generated an assertion, the JSEP message. This is
	done by adding a new a-line to the SDP, of the form a=identity. The		done by adding a new a-line to the SDP, of the form a=identity. The
	sole contents of this value are a base-64-encoded version of the		sole contents of this value are a base-64-encoded version of the
	identity assertion. For example:		identity assertion. For example:
	v=0		v=0
	o=- 1181923068 1181923196 IN IP4 ua1.example.com		o=- 1181923068 1181923196 IN IP4 ua1.example.com
	s=example1		s=example1
	c=IN IP4 ua1.example.com		c=IN IP4 ua1.example.com
	skipping to change at page 20, line 37		skipping to change at page 21, line 37
	a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP		a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
	a=pcfg:1 t=1		a=pcfg:1 t=1
	Each identity attribute should be paired (and attests to) with an		Each identity attribute should be paired (and attests to) with an
	a=fingerprint attribute and therefore can exist either at the session		a=fingerprint attribute and therefore can exist either at the session
	or media level. Multiple identity attributes may appear at either		or media level. Multiple identity attributes may appear at either
	level, though implementations are discouraged from doing this unless		level, though implementations are discouraged from doing this unless
	they have a clear idea of what security claim they intend to be		they have a clear idea of what security claim they intend to be
	making.		making.
	5.6.5. IdP Interaction Details		5.6.4. IdP Interaction Details
	5.6.5.1. General Message Structure		5.6.4.1. General Message Structure
	Messages between the PeerConnection object and the IdP proxy are		Messages between the PeerConnection object and the IdP proxy are
	formatted using JSON [RFC4627]. For instance, the PeerConnection		formatted using JSON [RFC4627]. For instance, the PeerConnection
	would request a signature with the following "SIGN" message:		would request a signature with the following "SIGN" message:
	{		{
	"type":"SIGN",		"type":"SIGN",
	"id": "1",		"id": "1",
	"origin":"https://calling-site.example.com",		"origin":"https://calling-site.example.com",
	"message":"012345678abcdefghijkl"		"message":"012345678abcdefghijkl"
	skipping to change at page 21, line 25		skipping to change at page 22, line 25
	the URL of the calling site). This origin value can be used by the		the URL of the calling site). This origin value can be used by the
	IdP to make access control decisions. For instance, an IdP might		IdP to make access control decisions. For instance, an IdP might
	only issue identity assertions for certain calling services in the		only issue identity assertions for certain calling services in the
	same way that some IdPs require that relying Web sites have an API		same way that some IdPs require that relying Web sites have an API
	key before learning user identity.		key before learning user identity.
	Any message-specific data is carried in a "message" field. Depending		Any message-specific data is carried in a "message" field. Depending
	on the message type, this may either be a string or a richer JSON		on the message type, this may either be a string or a richer JSON
	object.		object.
	5.6.5.1.1. Errors		5.6.4.1.1. Errors
	If an error occurs, the IdP sends a message of type "ERROR". The		If an error occurs, the IdP sends a message of type "ERROR". The
	message MAY have an "error" field containing freeform text data which		message MAY have an "error" field containing freeform text data which
	containing additional information about what happened. For instance:		containing additional information about what happened. For instance:
	{		{
	"type":"ERROR",		"type":"ERROR",
	"error":"Signature verification failed"		"error":"Signature verification failed"
	}		}
	Figure 3: Example error		Figure 3: Example error
	5.6.5.2. IdP Proxy Setup		5.6.4.2. IdP Proxy Setup
	In order to perform an identity transaction, the PeerConnection must		In order to perform an identity transaction, the PeerConnection must
	first create an IdP proxy. While the details of this are specified		first create an IdP proxy. As stated above, the details of this are
	in the W3C API document, from the perspective of this specification,		specified in the W3C API document. From the perspective of this
	however, the relevant facts are:		specification, however, the relevant facts are:
	o The JS runs in the IdP's security context with the base page		o The JS runs in the IdP's security context with the base page
	retrieved from the URL specified in Section 5.6.5.2.1		retrieved from the URL specified in Section 5.6.4.2.1
	o The usual browser sandbox isolation mechanisms MUST be enforced		o The usual browser sandbox isolation mechanisms MUST be enforced
	with respect to the IdP proxy.		with respect to the IdP proxy.
	o JS running in the IdP proxy MUST be able to send and receive		o JS running in the IdP proxy MUST be able to send and receive
	messages to the PeerConnection and the PC and IdP proxy are able		messages to the PeerConnection and the PC and IdP proxy are able
	to verify the source and destination of these messages.		to verify the source and destination of these messages.
	Initially the IdP proxy is in an unready state; the IdP JS must be		Initially the IdP proxy is in an unready state; the IdP JS must be
	loaded and there may be several round trips to the IdP server, for		loaded and there may be several round trips to the IdP server, for
	instance to log the user in. When the IdP proxy is ready to receive		instance to log the user in. When the IdP proxy is ready to receive
	commands, it delivers a "ready" message. As this message is		commands, it delivers a "ready" message. As this message is
	unsolicited, it simply contains:		unsolicited, it simply contains:
	{ "type":"READY" }		{ "type":"READY" }
	[[ OPEN ISSUE: if the W3C half of this converges on WebIntents, then
	the READY message will not be necessary.]]
	Once the PeerConnection object receives the ready message, it can		Once the PeerConnection object receives the ready message, it can
	send commands to the IdP proxy.		send commands to the IdP proxy.
	5.6.5.2.1. Determining the IdP URI		5.6.4.2.1. Determining the IdP URI
	Each IdP proxy instance is associated with two values:		Each IdP proxy instance is associated with two values:
	domain name: The IdP's domain name		domain name: The IdP's domain name
	protocol: The specific IdP protocol which the IdP is using. This is		protocol: The specific IdP protocol which the IdP is using. This is
	a completely IdP-specific string, but allows an IdP to implement		a completely IdP-specific string, but allows an IdP to implement
	two protocols in parallel. This value may be the empty string.		two protocols in parallel. This value may be the empty string.
	Each IdP MUST serve its initial entry page (i.e., the one loaded by		Each IdP MUST serve its initial entry page (i.e., the one loaded by
	the IdP proxy) from the well-known URI specified in "/.well-known/		the IdP proxy) from the well-known URI specified in "/.well-known/
	idp-proxy/<protocol>" on the IdP's web site. This URI MUST be loaded		idp-proxy/<protocol>" on the IdP's web site. This URI MUST be loaded
	via HTTPS [RFC2818]. For example, for the IdP "identity.example.com"		via HTTPS [RFC2818]. For example, for the IdP "identity.example.com"
	and the protocol "example", the URL would be:		and the protocol "example", the URL would be:
	https://example.com/.well-known/idp-proxy/example		https://example.com/.well-known/idp-proxy/example
	5.6.5.2.1.1. Authenticating Party		5.6.4.2.1.1. Authenticating Party
	How an AP determines the appropriate IdP domain is out of scope of		How an AP determines the appropriate IdP domain is out of scope of
	this specification. In general, however, the AP has some actual		this specification. In general, however, the AP has some actual
	account relationship with the IdP, as this identity is what the IdP		account relationship with the IdP, as this identity is what the IdP
	is attesting to. Thus, the AP somehow supplies the IdP information		is attesting to. Thus, the AP somehow supplies the IdP information
	to the browser. Some potential mechanisms include:		to the browser. Some potential mechanisms include:
	o Provided by the user directly.		o Provided by the user directly.
	o Selected from some set of IdPs known to the calling site. E.g., a		o Selected from some set of IdPs known to the calling site. E.g., a
	button that shows "Authenticate via Facebook Connect"		button that shows "Authenticate via Facebook Connect"
	5.6.5.2.1.2. Relying Party		5.6.4.2.1.2. Relying Party
	Unlike the AP, the RP need not have any particular relationship with		Unlike the AP, the RP need not have any particular relationship with
	the IdP. Rather, it needs to be able to process whatever assertion		the IdP. Rather, it needs to be able to process whatever assertion
	is provided by the AP. As the assertion contains the IdP's identity,		is provided by the AP. As the assertion contains the IdP's identity,
	the URI can be constructed directly from the assertion, and thus the		the URI can be constructed directly from the assertion, and thus the
	RP can directly verify the technical validity of the assertion with		RP can directly verify the technical validity of the assertion with
	no user interaction. Authoritative assertions need only be		no user interaction. Authoritative assertions need only be
	verifiable. Third-party assertions also MUST be verified against		verifiable. Third-party assertions also MUST be verified against
	local policy, as described in Section 5.6.5.2.3.1.		local policy, as described in Section 5.6.4.2.3.1.
	5.6.5.2.2. Requesting Assertions		5.6.4.2.2. Requesting Assertions
	In order to request an assertion, the PeerConnection sends a "SIGN"		In order to request an assertion, the PeerConnection sends a "SIGN"
	message. Aside from the mandatory fields, this message has a		message. Aside from the mandatory fields, this message has a
	"message" field containing a string. The contents of this string are		"message" field containing a string. The contents of this string are
	defined above, but are opaque from the perspective of the IdP.		defined above, but are opaque from the perspective of the IdP.
	A successful response to a "SIGN" message contains a message field		A successful response to a "SIGN" message contains a message field
	which is a JS dictionary dictionary consisting of two fields:		which is a JS dictionary dictionary consisting of two fields:
	idp: A dictionary containing the domain name of the provider and the		idp: A dictionary containing the domain name of the provider and the
	protocol string		protocol string
	assertion: An opaque field containing the assertion itself. This is		assertion: An opaque field containing the assertion itself. This is
	only interpretable by the idp or its proxy.		only interpretable by the idp or its proxy.
	Figure 4 shows an example transaction, with the message "abcde..."		Figure 4 shows an example transaction, with the message "abcde..."
	(remember, the messages are opaque at this layer) being signed and		being signed and bound to identity "ekr@example.org". In this case,
	bound to identity "ekr@example.org". In this case, the message has		the message has presumably been digitally signed/MACed in some way
	presumably been digitally signed/MACed in some way that the IdP can		that the IdP can later verify it, but this is an implementation
	later verify it, but this is an implementation detail and out of		detail and out of scope of this document. Line breaks are inserted
	scope of this document. Line breaks are inserted solely for		solely for readability.
	readability.
	PeerConnection -> IdP proxy:		PeerConnection -> IdP proxy:
	{		{
	"type":"SIGN",		"type":"SIGN",
	"id":1,		"id":1,
	"origin":"https://calling-service.example.com/",		"message":"abcdefghijklmnopqrstuvwyz"
	"message":"abcdefghijklmnopqrstuvwyz"
	}		}
	IdPProxy -> PeerConnection:		IdPProxy -> PeerConnection:
	{		{
	"type":"SUCCESS",		"type":"SUCCESS",
	"id":1,		"id":1,
	"message": {		"message": {
	"idp":{		"idp":{
	"domain": "example.org"		"domain": "example.org"
	"protocol": "bogus"		"protocol": "bogus"
	skipping to change at page 24, line 27		skipping to change at page 25, line 4
	"message": {		"message": {
	"idp":{		"idp":{
	"domain": "example.org"		"domain": "example.org"
	"protocol": "bogus"		"protocol": "bogus"
	},		},
	"assertion":\"{\"identity\":\"bob@example.org\",		"assertion":\"{\"identity\":\"bob@example.org\",
	\"contents\":\"abcdefghijklmnopqrstuvwyz\",		\"contents\":\"abcdefghijklmnopqrstuvwyz\",
	\"signature\":\"010203040506\"}"		\"signature\":\"010203040506\"}"
	}		}
	}		}
	Figure 4: Example assertion request		Figure 4: Example assertion request
	5.6.5.2.3. Verifying Assertions		5.6.4.2.3. Verifying Assertions
	In order to verify an assertion, an RP sends a "VERIFY" message to		In order to verify an assertion, an RP sends a "VERIFY" message to
	the IdP proxy containing the assertion supplied by the AP in the		the IdP proxy containing the assertion supplied by the AP in the
	"message" field.		"message" field.
	The IdP proxy verifies the assertion. Depending on the identity		The IdP proxy verifies the assertion. Depending on the identity
	protocol, this may require one or more round trips to the IdP. For		protocol, this may require one or more round trips to the IdP. For
	instance, an OAuth-based protocol will likely require using the IdP		instance, an OAuth-based protocol will likely require using the IdP
	as an oracle, whereas with BrowserID the IdP proxy can likely verify		as an oracle, whereas with BrowserID the IdP proxy can likely verify
	the signature on the assertion without contacting the IdP, provided		the signature on the assertion without contacting the IdP, provided
	that it has cached the IdP's public key.		that it has cached the IdP's public key.
	Regardless of the mechanism, if verification succeeds, a successful		Regardless of the mechanism, if verification succeeds, a successful
	response from the IdP proxy MUST contain a message field consisting		response from the IdP proxy MUST contain a message field consisting
	of a dictionary/hash with the following fields:		of a dictionary/hash with the following fields:
	identity The identity of the AP from the IdP's perspective. Details		identity The identity of the AP from the IdP's perspective. Details
	of this are provided in Section 5.6.5.2.3.1		of this are provided in Section 5.6.4.2.3.1
	contents The original unmodified string provided by the AP in the		contents The original unmodified string provided by the AP in the
	original SIGN request.		original SIGN request.
	Figure 5 shows an example transaction. Line breaks are inserted		Figure 5 shows an example transaction. Line breaks are inserted
	solely for readability.		solely for readability.
	PeerConnection -> IdP Proxy:		PeerConnection -> IdP Proxy:
	{		{
	"type":"VERIFY",		"type":"VERIFY",
	"id":2,		"id":2,
	"origin":"https://calling-service.example.com/",
	"message":\"{\"identity\":\"bob@example.org\",		"message":\"{\"identity\":\"bob@example.org\",
	\"contents\":\"abcdefghijklmnopqrstuvwyz\",		\"contents\":\"abcdefghijklmnopqrstuvwyz\",
	\"signature\":\"010203040506\"}"		\"signature\":\"010203040506\"}"
	}		}
	IdP Proxy -> PeerConnection:		IdP Proxy -> PeerConnection:
	{		{
	"type":"SUCCESS",		"type":"SUCCESS",
	"id":2,		"id":2,
	"message": {		"message": {
	"identity" : {		"identity" : {
	"name" : "bob@example.org",		"name" : "bob@example.org",
	"displayname" : "Bob"		"displayname" : "Bob"
	},		},
	"contents":"abcdefghijklmnopqrstuvwyz"		"contents":"abcdefghijklmnopqrstuvwyz"
	}		}
	}		}
	Figure 5: Example verification request		Figure 5: Example verification request
	5.6.5.2.3.1. Identity Formats		5.6.4.2.3.1. Identity Formats
	Identities passed from the IdP proxy to the PeerConnection are		Identities passed from the IdP proxy to the PeerConnection are
	structured as JSON dictionaries with one mandatory field: "name".		structured as JSON dictionaries with one mandatory field: "name".
	This field MUST consist of an RFC822-formatted string representing		This field MUST consist of an RFC822-formatted string representing
	the user's identity. [[ OPEN ISSUE: Would it be better to have a		the user's identity. [[ OPEN ISSUE: Would it be better to have a
	typed field? ]] The PeerConnection API MUST check this string as		typed field? ]] The PeerConnection API MUST check this string as
	follows:		follows:
	1. If the RHS of the string is equal to the domain name of the IdP		1. If the RHS of the string is equal to the domain name of the IdP
	proxy, then the assertion is valid, as the IdP is authoritative		proxy, then the assertion is valid, as the IdP is authoritative
	skipping to change at page 26, line 18		skipping to change at page 27, line 10
	(for instance, Facebook ids are simple numeric values) SHOULD convert		(for instance, Facebook ids are simple numeric values) SHOULD convert
	them to this form by appending their IdP domain (e.g.,		them to this form by appending their IdP domain (e.g.,
	12345@identity.facebook.com), thus ensuring that they are		12345@identity.facebook.com), thus ensuring that they are
	authoritative for the identity.		authoritative for the identity.
	The IdP proxy MAY also include a "displayname" field which contains a		The IdP proxy MAY also include a "displayname" field which contains a
	more user-friendly identity assertion. Browsers SHOULD take care in		more user-friendly identity assertion. Browsers SHOULD take care in
	the UI to distinguish the "name" assertion which is verifiable		the UI to distinguish the "name" assertion which is verifiable
	directly from the "displayname" which cannot be verified and thus		directly from the "displayname" which cannot be verified and thus
	relies on trust in the IdP. In future, we may define other fields to		relies on trust in the IdP. In future, we may define other fields to
	allow the IdP to provide more information to the browser. [[OPEN		allow the IdP to provide more information to the browser.
	ISSUE: Should this field exist? Is it confusing? ]]
	5.7. Security Considerations		5.7. Security Considerations
	Much of the security analysis of this problem is contained in		Much of the security analysis of this problem is contained in
	[I-D.ietf-rtcweb-security] or in the discussion of the particular		[I-D.ietf-rtcweb-security] or in the discussion of the particular
	issues above. In order to avoid repetition, this section focuses on		issues above. In order to avoid repetition, this section focuses on
	(a) residual threats that are not addressed by this document and (b)		(a) residual threats that are not addressed by this document and (b)
	threats produced by failure/misbehavior of one of the components in		threats produced by failure/misbehavior of one of the components in
	the system.		the system.
	skipping to change at page 27, line 10		skipping to change at page 27, line 49
	requirements in Section 5.5 are designed to provide such a mechanism		requirements in Section 5.5 are designed to provide such a mechanism
	for motivated/security conscious users, but are not suitable for		for motivated/security conscious users, but are not suitable for
	general use. The identity service mechanisms in Section 5.6 are more		general use. The identity service mechanisms in Section 5.6 are more
	suitable for general use. Note, however, that a malicious signaling		suitable for general use. Note, however, that a malicious signaling
	service can strip off any such identity assertions, though it cannot		service can strip off any such identity assertions, though it cannot
	forge new ones. Note that all of the third-party security mechanisms		forge new ones. Note that all of the third-party security mechanisms
	available (whether X.509 certificates or a third-party IdP) rely on		available (whether X.509 certificates or a third-party IdP) rely on
	the security of the third party--this is of course also true of your		the security of the third party--this is of course also true of your
	connection to the Web site itself. Users who wish to assure		connection to the Web site itself. Users who wish to assure
	themselves of security against a malicious identity provider can only		themselves of security against a malicious identity provider can only
	do so by verifying peer credentials directly, e.g., by checking the		do so by verifing peer credentials directly, e.g., by checking the
	peer's fingerprint against a value delivered out of band.		peer's fingerprint against a value delivered out of band.
	5.7.2. Privacy		5.7.2. Privacy
	The requirements in this document are intended to allow:		The requirements in this document are intended to allow:
	o Users to participate in calls without revealing their location.		o Users to participate in calls without revealing their location.
	o Potential callees to avoid revealing their location and even		o Potential callees to avoid revealing their location and even
	presence status prior to agreeing to answer a call.		presence status prior to agreeing to answer a call.
	skipping to change at page 28, line 16		skipping to change at page 29, line 7
	which are behaving badly, and especially to be prepared to remotely		which are behaving badly, and especially to be prepared to remotely
	throttle the data channel in the absence of plausible audio and video		throttle the data channel in the absence of plausible audio and video
	(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. Either media-level (RTCP) mechanisms must be used or the		keepalives. Media-level (RTCP) mechanisms must be used in this case.
	implementation must deny responses entirely, thus termnating the
	call.
	Yet another attack, suggested by Magnus Westerlund, is for the		Yet another attack, suggested by Magnus Westerlund, is for the
	attacker to cross-connect offers and answers as follows. It induces		attacker to cross-connect offers and answers as follows. It induces
	the victim to make a call and then uses its control of other users		the victim to make a call and then uses its control of other users
	browsers to get them to attempt a call to someone. It then		browsers to get them to attempt a call to someone. It then
	translates their offers into apparent answers to the victim, which		translates their offers into apparent answers to the victim, which
	looks like large-scale parallel forking. The victim still responds		looks like large-scale parallel forking. The victim still responds
	to ICE responses and now the browsers all try to send media to the		to ICE responses and now the browsers all try to send media to the
	victim. Implementations can defend themselves from this attack by		victim. [[ OPEN ISSUE: How do we address this? ]]
	only responding to ICE Binding Requests for a limited number of
	remote ufrags (this is the reason for the requirement that the JS not		[TODO: Should we have a mechanism for verifying total expected
	be able to control the ufrag and password).		bandwidth]
	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 even in the face of the third-party identity		consent are possible primarily even in the face of the third-party
	mechanism as long as major parts of the signaling messages are not		identity mechanism as long as major parts of the signaling messages
	signed. On the other hand, signing the entire message severely		are not signed. On the other hand, signing the entire message
	restricts the capabilities of the calling application, so there are		severely restricts the capabilities of the calling application, so
	difficult tradeoffs here.		there are difficult tradeoffs here.
	5.7.4. IdP Authentication Mechanism		5.7.4. IdP Authentication Mechanism
	This mechanism relies for its security on the IdP and on the		This mechanism relies for its security on the IdP and on the
	PeerConnection correctly enforcing the security invariants described		PeerConnection correctly enforcing the security invariants described
	above. At a high level, the IdP is attesting that the user		above. At a high level, the IdP is attesting that the user
	identified in the assertion wishes to be associated with the		identified in the assertion wishes to be associated with the
	assertion. Thus, it must not be possible for arbitrary third parties		assertion. Thus, it must not be possible for arbitrary third parties
	to get assertions tied to a user or to produce assertions that RPs		to get assertions tied to a user or to produce assertions that RPs
	will accept.		will accept.
	5.7.4.1. IdP Well-known URI		5.7.4.1. PeerConnection Origin Check
	As described in Section 5.6.5.2.1 the IdP proxy HTML/JS landing page		Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by
			the browser, so nothing stops a Web attacker o from creating their
			own IFRAME, loading the IdP proxy HTML/JS, and requesting a
			signature. In order to prevent this attack, we require that all
			signatures be tied to a specific origin ("rtcweb://...") which cannot
			be produced by a page tied to a Web attacker. Thus, while an
			attacker can instantiate the IdP proxy, they cannot send messages
			from an appropriate origin and so cannot create acceptable
			assertions. [[OPEN ISSUE: Where is this enforced? ]]
			5.7.4.2. IdP Well-known URI
			As described in Section 5.6.4.2.1 the IdP proxy HTML/JS landing page
	is located at a well-known URI based on the IdP's domain name. This		is located at a well-known URI based on the IdP's domain name. This
	requirement prevents an attacker who can write some resources at the		requirement prevents an attacker who can write some resources at the
	IdP (e.g., on one's Facebook wall) from being able to impersonate the		IdP (e.g., on one's Facebook wall) from being able to impersonate the
	IdP.		IdP.
	5.7.4.2. Privacy of IdP-generated identities and the hosting site		5.7.4.3. Privacy of IdP-generated identities and the hosting site
	Depending on the structure of the IdP's assertions, the calling site		Depending on the structure of the IdP's assertions, the calling site
	may learn the user's identity from the perspective of the IdP. In		may learn the user's identity from the perspective of the IdP. In
	many cases this is not an issue because the user is authenticating to		many cases this is not an issue because the user is authenticating to
	the site via the IdP in any case, for instance when the user has		the site via the IdP in any case, for instance when the user has
	logged in with Facebook Connect and is then authenticating their call		logged in with Facebook Connect and is then authenticating their call
	with a Facebook identity. However, in other case, the user may not		with a Facebook identity. However, in other case, the user may not
	have already revealed their identity to the site. In general, IdPs		have already revealed their identity to the site. In general, IdPs
	SHOULD either verify that the user is willing to have their identity		SHOULD either verify that the user is willing to have their identity
	revealed to the site (e.g., through the usual IdP permissions dialog)		revealed to the site (e.g., through the usual IdP permissions dialog)
	or arrange that the identity information is only available to known		or arrange that the identity information is only available to known
	RPs (e.g., social graph adjacencies) but not to the calling site.		RPs (e.g., social graph adjacencies) but not to the calling site.
	The "origin" field of the signature request can be used to check that		The "origin" field of the signature request can be used to check that
	the user has agreed to disclose their identity to the calling site;		the user has agreed to disclose their identity to the calling site;
	because it is supplied by the PeerConnection it can be trusted to be		because it is supplied by the PeerConnection it can be trusted to be
	correct.		correct.
	5.7.4.3. Security of Third-Party IdPs		5.7.4.4. Security of Third-Party IdPs
	As discussed above, each third-party IdP represents a new universal		As discussed above, each third-party IdP represents a new universal
	trust point and therefore the number of these IdPs needs to be quite		trust point and therefore the number of these IdPs needs to be quite
	limited. Most IdPs, even those which issue unqualified identities		limited. Most IdPs, even those which issue unqualified identities
	such as Facebook, can be recast as authoritative IdPs (e.g.,		such as Facebook, can be recast as authoritative IdPs (e.g.,
	123456@facebook.com). However, in such cases, the user interface		123456@facebook.com). However, in such cases, the user interface
	implications are not entirely desirable. One intermediate approach		implications are not entirely desirable. One intermediate approach
	is to have special (potentially user configurable) UI for large		is to have special (potentially user configurable) UI for large
	authoritative IdPs, thus allowing the user to instantly grasp that		authoritative IdPs, thus allowing the user to instantly grasp that
	the call is being authenticated by Facebook, Google, etc.		the call is being authenticated by Facebook, Google, etc.
	5.7.4.4. Web Security Feature Interactions		5.7.4.5. Web Security Feature Interactions
	A number of optional Web security features have the potential to		A number of optional Web security features have the potential to
	cause issues for this mechanism, as discussed below.		cause issues for this mechanism, as discussed below.
	5.7.4.4.1. Popup Blocking		5.7.4.5.1. Popup Blocking
	If the user is not already logged into the IdP, the IdP proxy may		If the user is not already logged into the IdP, the IdP proxy may
	need to pop up a top level window in order to prompt the user for		need to pop up a top level window in order to prompt the user for
	their authentication information (it is bad practice to do this in an		their authentication information (it is bad practice to do this in an
	IFRAME inside the window because then users have no way to determine		IFRAME inside the window because then users have no way to determine
	the destination for their password). If the user's browser is		the destination for their password). If the user's browser is
	configured to prevent popups, this may fail (depending on the exact		configured to prevent popups, this may fail (depending on the exact
	algorithm that the popup blocker uses to suppress popups). It may be		algorithm that the popup blocker uses to suppress popups). It may be
	necessary to provide a standardized mechanism to allow the IdP proxy		necessary to provide a standardized mechanism to allow the IdP proxy
	to request popping of a login window. Note that care must be taken		to request popping of a login window. Note that care must be taken
	here to avoid PeerConnection becoming a general escape hatch from		here to avoid PeerConnection becoming a general escape hatch from
	popup blocking. One possibility would be to only allow popups when		popup blocking. One possibility would be to only allow popups when
	the user has explicitly registered a given IdP as one of theirs (this		the user has explicitly registered a given IdP as one of theirs (this
	is only relevant at the AP side in any case). This is what		is only relevant at the AP side in any case). This is what
	WebIntents does, and the problem would go away if WebIntents is used.		WebIntents does, and the problem would go away if WebIntents is used.
	5.7.4.4.2. Third Party Cookies		5.7.4.5.2. Third Party Cookies
	Some browsers allow users to block third party cookies (cookies		Some browsers allow users to block third party cookies (cookies
	associated with origins other than the top level page) for privacy		associated with origins other than the top level page) for privacy
	reasons. Any IdP which uses cookies to persist logins will be broken		reasons. Any IdP which uses cookies to persist logins will be broken
	by third-party cookie blocking. One option is to accept this as a		by third-party cookie blocking. One option is to accept this as a
	limitation; another is to have the PeerConnection object disable		limitation; another is to have the PeerConnection object disable
	third-party cookie blocking for the IdP proxy.		third-party cookie blocking for the IdP proxy.
	6. Acknowledgements		6. Acknowledgements
	Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Hadriel		Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Hadriel
	Kaplan, Matthew Kaufman, Jim McEachem, Martin Thomson, Magnus		Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus
	Westerland.		Westerland.
	7. Changes since -02		7. Changes since -03
			The following changes have been made since the -02 draft.
			o Editorial changes
			8. Changes since -02
	The following changes have been made since the -02 draft.		The following changes have been made since the -02 draft.
	o Forbid persistent HTTP permissions.		o Forbid persistent HTTP permissions.
	o Clarified the text in S 5.4 to clearly refer to requirements on		o Clarified the text in S 5.4 to clearly refer to requirements on
	the API to provide functionality to the site.		the API to provide functionality to the site.
	o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp		o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp
	o Retarget the continuing consent section to assume Binding Requests
	o Editorial improvements
	8. References
	8.1. Normative References		9. References
			9.1. Normative References
	[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-03 (work in progress),		draft-ietf-rtcweb-security-03 (work in progress),
	June 2012.		June 2012.
	[I-D.muthu-behave-consent-freshness]		[I-D.muthu-behave-consent-freshness]
	Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for		Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for
	Consent Freshness and Session Liveness",		Consent Freshness and Session Liveness",
	draft-muthu-behave-consent-freshness-01 (work in		draft-muthu-behave-consent-freshness-01 (work in
	skipping to change at page 31, line 40		skipping to change at page 32, line 45
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, May 2010.		Security (DTLS)", RFC 5763, May 2010.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	December 2011.		December 2011.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J. and C. Jennings, "Javascript Session		Uberti, J. and C. Jennings, "Javascript Session
	Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work		Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work
	in progress), June 2012.		in progress), June 2012.
	[I-D.jennings-rtcweb-signaling]		[I-D.jennings-rtcweb-signaling]
	Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/		Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
	Answer Protocol (ROAP)",		Answer Protocol (ROAP)",
	draft-jennings-rtcweb-signaling-01 (work in progress),		draft-jennings-rtcweb-signaling-01 (work in progress),
End of changes. 60 change blocks.
	182 lines changed or deleted		188 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/