draft-ietf-rtcweb-security-arch-07.txt		draft-ietf-rtcweb-security-arch-08.txt
	RTCWEB E. Rescorla		RTCWEB E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track July 14, 2013		Intended status: Standards Track January 22, 2014
	Expires: January 15, 2014		Expires: July 26, 2014
	WebRTC Security Architecture		WebRTC Security Architecture
	draft-ietf-rtcweb-security-arch-07		draft-ietf-rtcweb-security-arch-08
	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 (commonly		communications within user-agents using web technologies (commonly
	called "WebRTC"). This document defines the security architecture		called "WebRTC"). This document defines the security architecture
	for		for
	Legal
	THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON
	AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 15, 2014.		This Internet-Draft will expire on July 26, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 7		skipping to change at page 2, line 19
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 7		3.1. Authenticated Entities . . . . . . . . . . . . . . . . . . 6
	3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 7		3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . . 6
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 10		4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 9
	4.2. Media Consent Verification . . . . . . . . . . . . . . . . 12		4.2. Media Consent Verification . . . . . . . . . . . . . . . . 11
	4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 13		4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . . 12
	4.4. Communications and Consent Freshness . . . . . . . . . . . 13		4.4. Communications and Consent Freshness . . . . . . . . . . . 12
	5. Detailed Technical Description . . . . . . . . . . . . . . . . 14		5. Detailed Technical Description . . . . . . . . . . . . . . . . 13
	5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 14		5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 13
	5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 14		5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 13
	5.3. Communications Consent . . . . . . . . . . . . . . . . . . 16		5.3. Communications Consent . . . . . . . . . . . . . . . . . . 15
	5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17		5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 16
	5.5. Communications Security . . . . . . . . . . . . . . . . . 18		5.5. Communications Security . . . . . . . . . . . . . . . . . 17
	5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 19		5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 18
	5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 20		5.6.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . 19
	5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 22		5.6.2. Overview of Operation . . . . . . . . . . . . . . . . 21
	5.6.3. Items for Standardization . . . . . . . . . . . . . . 23		5.6.3. Items for Standardization . . . . . . . . . . . . . . 22
	5.6.4. Binding Identity Assertions to JSEP Offer/Answer		5.6.4. Binding Identity Assertions to JSEP Offer/Answer
	Transactions . . . . . . . . . . . . . . . . . . . . . 23		Transactions . . . . . . . . . . . . . . . . . . . . . 22
	5.6.4.1. Input to Assertion Generation Process . . . . . . 23		5.6.4.1. Input to Assertion Generation Process . . . . . . 22
	5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 24		5.6.4.2. Carrying Identity Assertions . . . . . . . . . . . 23
	5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 25		5.6.5. IdP Interaction Details . . . . . . . . . . . . . . . 24
	5.6.5.1. General Message Structure . . . . . . . . . . . . 25		5.6.5.1. General Message Structure . . . . . . . . . . . . 24
	5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 26		5.6.5.2. IdP Proxy Setup . . . . . . . . . . . . . . . . . 25
	5.7. Security Considerations . . . . . . . . . . . . . . . . . 30		5.7. Security Considerations . . . . . . . . . . . . . . . . . 29
	5.7.1. Communications Security . . . . . . . . . . . . . . . 30		5.7.1. Communications Security . . . . . . . . . . . . . . . 29
	5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 31		5.7.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 30
	5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 32		5.7.3. Denial of Service . . . . . . . . . . . . . . . . . . 31
	5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 33		5.7.4. IdP Authentication Mechanism . . . . . . . . . . . . . 32
	5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 33		5.7.4.1. PeerConnection Origin Check . . . . . . . . . . . 32
	5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 34		5.7.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . 33
	5.7.4.3. Privacy of IdP-generated identities and the		5.7.4.3. Privacy of IdP-generated identities and the
	hosting site . . . . . . . . . . . . . . . . . . . 34		hosting site . . . . . . . . . . . . . . . . . . . 33
	5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 35		5.7.4.4. Security of Third-Party IdPs . . . . . . . . . . . 34
	5.7.4.5. Web Security Feature Interactions . . . . . . . . 35		5.7.4.5. Web Security Feature Interactions . . . . . . . . 34
	5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 35		5.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 34
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
	7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36		7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 36		7.1. Changes since -06 . . . . . . . . . . . . . . . . . . . . 35
	7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 36		7.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 35
	7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36		7.3. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
	7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 36		7.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 35
	7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 37		7.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 36
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37		8.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 37		8.2. Informative References . . . . . . . . . . . . . . . . . . 37
	8.2. Informative References . . . . . . . . . . . . . . . . . . 38		Appendix A. Example IdP Bindings to Specific Protocols . . . . . 38
	Appendix A. Example IdP Bindings to Specific Protocols . . . . . 39		A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 38
	A.1. BrowserID . . . . . . . . . . . . . . . . . . . . . . . . 39		A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	A.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 42		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	The Real-Time Communications on the Web (WebRTC) working group is		The Real-Time Communications on the Web (WebRTC) 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 WebRTC technology are		between Web browsers. The major use cases for WebRTC 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) WebRTC communications are directly		based[RFC3261] soft phones) WebRTC communications are directly
	controlled by some Web server, via a JavaScript (JS) API as shown in		controlled by some Web server, via a JavaScript (JS) API as shown in
	skipping to change at page 10, line 5		skipping to change at page 9, line 5
	Figure 3: A call with IdP-based identity		Figure 3: A call with IdP-based identity
	Figure 4 shows essentially the same calling scenario but with a call		Figure 4 shows essentially the same calling scenario but with a call
	between two separate domains (i.e., a federated case), as in		between two separate domains (i.e., a federated case), as in
	Figure 2. As mentioned above, the domains communicate by some		Figure 2. As mentioned above, the domains communicate by some
	unspecified protocol and providing separate signaling and identity		unspecified protocol and providing separate signaling and identity
	allows for calls to be authenticated regardless of the details of the		allows for calls to be authenticated regardless of the details of the
	inter-domain protocol.		inter-domain protocol.
	+----------------+ Unspecified +----------------+		+----------------+ Unspecified +----------------+
	| | protocol | |		| | protocol | |
	| Signaling |<----------------->| Signaling |		| Signaling |<----------------->| Signaling |
	| Server | (SIP, XMPP, ...) | Server |		| Server | (SIP, XMPP, ...) | Server |
	| | | |		| | | |
	+----------------+ +----------------+		+----------------+ +----------------+
	^ ^		^ ^
	| |		| |
	HTTPS | | HTTPS		HTTPS | | HTTPS
	| |		| |
	| |		| |
	v v		v v
	JS API JS API		JS API JS API
	+-----------+ +-----------+		+-----------+ +-----------+
	| | Media | |		| | Media | |
	Alice | Browser |<--------------------------->| Browser | Bob		Alice | Browser |<--------------------------->| Browser | Bob
	| | DTLS+SRTP | |		| | DTLS+SRTP | |
	+-----------+ +-----------+		+-----------+ +-----------+
	^ ^--+ +--^ ^		^ ^--+ +--^ ^
	| | | |		| | | |
	v | | v		v | | v
	+-----------+ | | +-----------+		+-----------+ | | +-----------+
	| |<-------------------------+ | |		| |<-------------------------+ | |
	| IdP1 | | | IdP2 |		| IdP1 | | | IdP2 |
	| | +------------------------>| |		| | +------------------------>| |
	+-----------+ +-----------+		+-----------+ +-----------+
	Figure 4: A federated call with IdP-based identity		Figure 4: A federated call with IdP-based identity
	4.1. Initial Signaling		4.1. Initial Signaling
	For simplicity, assume the topology in Figure 3. Alice and Bob are		For simplicity, assume the topology in Figure 3. Alice and Bob are
	both users of a common calling service; they both have approved the		both users of a common calling service; they both have approved the
	calling service to make calls (we defer the discussion of device		calling service to make calls (we defer the discussion of device
	access permissions till later). They are both connected to the		access permissions till later). They are both connected to the
	calling service via HTTPS and so know the origin with some level of		calling service via HTTPS and so know the origin with some level of
	skipping to change at page 18, line 26		skipping to change at page 17, line 26
	5.5. Communications Security		5.5. Communications Security
	Implementations MUST implement SRTP [RFC3711]. Implementations MUST		Implementations MUST implement SRTP [RFC3711]. Implementations MUST
	implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP		implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
	keying. Implementations MUST implement		keying. Implementations MUST implement
	[I-D.ietf-tsvwg-sctp-dtls-encaps].		[I-D.ietf-tsvwg-sctp-dtls-encaps].
	All media channels MUST be secured via SRTP. Media traffic MUST NOT		All media channels MUST be secured via SRTP. Media traffic MUST NOT
	be sent over plain (unencrypted) RTP. DTLS-SRTP MUST be offered for		be sent over plain (unencrypted) RTP. DTLS-SRTP MUST be offered for
	every media channel and MUST be the default; i.e., if an		every media channel. WebRTC implements MUST NOT offer SDES or select
	implementation receives an offer for DTLS-SRTP and SDES, DTLS-SRTP		it if offered.
	MUST be selected.
	All data channels MUST be secured via DTLS.		All data channels MUST be secured via DTLS.
	[OPEN ISSUE: What should the settings be here? MUST?]		[[OPEN ISSUE: Are these the right cipher suites?]] All
	Implementations MAY support SDES for media traffic for backward		implementations MUST implement the following two cipher suites:
	compatibility purposes.		TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
			TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and the DTLS-SRTP protection
			profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor
			cipher suites which support PFS over non-PFS cipher suites.
	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. Unless the user specifically configures an		authentication. Unless the user specifically configures an
	external key pair, different key pairs MUST be used for each		external key pair, different key pairs MUST be used for each
	origin. (This avoids creating a super-cookie.)		origin. (This avoids creating a super-cookie.)
	skipping to change at page 24, line 29		skipping to change at page 23, line 29
	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.4.2. Carrying Identity Assertions
	Once an IdP has generated an assertion, it is attached to the JSEP		Once an IdP has generated an assertion, it is attached to the JSEP
	message. This is done by adding a new a-line to the SDP, of the form		message. This is 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		a=identity. The sole contents of this value are a base-64-encoded
	version of the identity assertion. For example:		version of the 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
	a=setup:actpass		a=setup:actpass
	a=fingerprint: SHA-1 \		a=fingerprint:sha-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=identity: \		a=identity:\
	ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n \		ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n\
	dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v \		dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v\
	cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs \		cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs\
	XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==		XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==
	t=0 0		t=0 0
	m=audio 6056 RTP/SAVP 0		m=audio 6056 RTP/SAVP 0
	a=sendrecv		a=sendrecv
			...
	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 it is RECOMMENDED that implementations not do this,		level, though it is RECOMMENDED that implementations not do this,
	because it becomes very unclear what security claim that they are		because it becomes very unclear what security claim that they are
	making and the UI guidelines above become unclear. Browsers MAY		making and the UI guidelines above become unclear. Browsers MAY
	choose refuse to display any identity indicators in the face of		choose refuse to display any identity indicators in the face of
	multiple identity attributes with different identities but SHOULD		multiple identity attributes with different identities but SHOULD
	process multiple attributes with the same identity as described		process multiple attributes with the same identity as described
	skipping to change at page 28, line 9		skipping to change at page 27, line 9
	only interpretable by the idp or its proxy.		only interpretable by the idp or its proxy.
	Figure 6 shows an example transaction, with the message "abcde..."		Figure 6 shows an example transaction, with the message "abcde..."
	(remember, the messages are opaque at this layer) being signed and		(remember, the messages are opaque at this layer) being signed and
	bound to identity "ekr@example.org". In this case, the message has		bound to identity "ekr@example.org". In this case, the message has
	presumably been digitally signed/MACed in some way that the IdP can		presumably been digitally signed/MACed in some way that the IdP can
	later verify it, but this is an implementation detail and out of		later verify it, but this is an implementation detail and out of
	scope of this document. Line breaks are inserted solely for		scope of this document. Line breaks are inserted solely for
	readability.		readability.
	PeerConnection -> IdP proxy:		PeerConnection -> IdP proxy:
	{		{
	"type":"SIGN",		"type":"SIGN",
	"id":1,
	"origin":"https://calling-service.example.com/",
	"message":"abcdefghijklmnopqrstuvwyz"
	}
	IdPProxy -> PeerConnection:
	{
	"type":"SUCCESS",
	"id":1,		"id":1,
	"message": {		"origin":"https://calling-service.example.com/",
	"idp":{		"message":"abcdefghijklmnopqrstuvwyz"
	"domain": "example.org"		}
	"protocol": "bogus"
	},		IdPProxy -> PeerConnection:
	"assertion":\"{\"identity\":\"bob@example.org\",		{
	\"contents\":\"abcdefghijklmnopqrstuvwyz\",		"type":"SUCCESS",
	\"request_origin\":\"rtcweb://peerconnection\",		"id":1,
	\"signature\":\"010203040506\"}"		"message": {
	}		"idp":{
	}		"domain": "example.org"
			"protocol": "bogus"
			},
			"assertion": "{\"identity\":\"bob@example.org\",
			\"contents\":\"abcdefghijklmnopqrstuvwyz\",
			\"request_origin\":\"rtcweb://peerconnection\",
			\"signature\":\"010203040506\"}"
			}
			}
	Figure 6: Example assertion request		Figure 6: Example assertion request
	The message structure is serialized, base64-encoded, and placed in an		The message structure is serialized, base64-encoded, and placed in an
	a=identity attribute.		a=identity attribute.
	5.6.5.2.3. Verifying Assertions		5.6.5.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
	skipping to change at page 29, line 26		skipping to change at page 28, line 26
	assertion. The receiving PeerConnection MUST verify that this		assertion. The receiving PeerConnection MUST verify that this
	value is "rtcweb://peerconnection" (which implies that		value is "rtcweb://peerconnection" (which implies that
	PeerConnection must arrange that its messages to the IdP proxy are		PeerConnection must arrange that its messages to the IdP proxy are
	from this origin.) See Section 5.7.4.1 for the security purpose		from this origin.) See Section 5.7.4.1 for the security purpose
	of this field. [[ OPEN ISSUE: Can a URI person help make a better		of this field. [[ OPEN ISSUE: Can a URI person help make a better
	URI.]]		URI.]]
	Figure 7 shows an example transaction. Line breaks are inserted		Figure 7 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/",		"origin":"https://calling-service.example.com/",
	"message":\"{\"identity\":\"bob@example.org\",		"message":\"{\"identity\":\"bob@example.org\",
	\"contents\":\"abcdefghijklmnopqrstuvwyz\",		\"contents\":\"abcdefghijklmnopqrstuvwyz\",
	\"request_origin\":\"rtcweb://peerconnection\",		\"request_origin\":\"rtcweb://peerconnection\",
	\"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"
	},		},
	"request_origin":"rtcweb://peerconnection",		"request_origin":"rtcweb://peerconnection",
	"contents":"abcdefghijklmnopqrstuvwyz"		"contents":"abcdefghijklmnopqrstuvwyz"
	}		}
	}		}
	Figure 7: Example verification request		Figure 7: Example verification request
	5.6.5.2.3.1. Identity Formats		5.6.5.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:
	skipping to change at page 37, line 27		skipping to change at page 36, line 27
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-avtcore-6222bis]		[I-D.ietf-avtcore-6222bis]
	Begen, A., Perkins, C., Wing, D., and E. Rescorla,		Begen, A., Perkins, C., Wing, D., and E. Rescorla,
	"Guidelines for Choosing RTP Control Protocol (RTCP)		"Guidelines for Choosing RTP Control Protocol (RTCP)
	Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06		Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
	(work in progress), July 2013.		(work in progress), July 2013.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for RTC-Web",		Rescorla, E., "Security Considerations for WebRTC",
	draft-ietf-rtcweb-security-04 (work in progress),		draft-ietf-rtcweb-security-05 (work in progress),
	January 2013.		July 2013.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS		Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
	Encapsulation of SCTP Packets for RTCWEB",		Encapsulation of SCTP Packets",
	draft-ietf-tsvwg-sctp-dtls-encaps-00 (work in progress),		draft-ietf-tsvwg-sctp-dtls-encaps-02 (work in progress),
	February 2013.		October 2013.
	[I-D.muthu-behave-consent-freshness]		[I-D.muthu-behave-consent-freshness]
	Perumal, M., Wing, D., R, R., and H. Kaplan, "STUN Usage		Perumal, M., Wing, D., R, R., and T. Reddy, "STUN Usage
	for Consent Freshness",		for Consent Freshness",
	draft-muthu-behave-consent-freshness-03 (work in		draft-muthu-behave-consent-freshness-04 (work in
	progress), February 2013.		progress), July 2013.
	[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.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, March 2004.
	skipping to change at page 38, line 51		skipping to change at page 37, line 51
	Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:		Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:
	Real-time Communication Between Browsers", October 2011.		Real-time Communication Between Browsers", October 2011.
	Available at		Available at
	http://dev.w3.org/2011/webrtc/editor/webrtc.html		http://dev.w3.org/2011/webrtc/editor/webrtc.html
	8.2. Informative References		8.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-03 (work		Establishment Protocol", draft-ietf-rtcweb-jsep-05 (work
	in progress), February 2013.		in progress), October 2013.
	[I-D.jennings-rtcweb-signaling]
	Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
	Answer Protocol (ROAP)",
	draft-jennings-rtcweb-signaling-01 (work in progress),
	October 2011.
	[I-D.kaufman-rtcweb-security-ui]
	Kaufman, M., "Client Security User Interface Requirements
	for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
	progress), June 2011.
	[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.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, March 2010.		Layer Security (TLS)", RFC 5705, March 2010.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	skipping to change at page 41, line 22		skipping to change at page 40, line 20
	The offer might look something like:		The offer might look something like:
	{		{
	"type":"OFFER",		"type":"OFFER",
	"sdp":		"sdp":
	"v=0\n		"v=0\n
	o=- 2890844526 2890842807 IN IP4 192.0.2.1\n		o=- 2890844526 2890842807 IN IP4 192.0.2.1\n
	s= \n		s= \n
	c=IN IP4 192.0.2.1\n		c=IN IP4 192.0.2.1\n
	t=2873397496 2873404696\n		t=2873397496 2873404696\n
	m=audio 49170 RTP/AVP 0\n		a=fingerprint:SHA-1 ...\n
	a=fingerprint: SHA-1 \		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n
	a=identity [[base-64 encoding of...		a=identity [[base-64 encoding of identity assertion:
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB\n",		{
	"identity":{		"idp":{ // Standardized
	"idp":{ // Standardized		"domain":"browserid.org",
	"domain":"browserid.org",		"method":"default"
	"method":"default"		},
	},		// Assertion contents are browserid-specific
	"assertion": // Contents are browserid-specific		"assertion": "{
	"\"assertion\": {		\"assertion\": {
	\"digest\":\"<hash of the contents from the browser>\",		\"digest\":\"<hash of the SIGN message>\",
	\"audience\": \"[TBD]\"		\"audience\": \"<audience>\"
	\"valid-until\": 1308859352261,		\"valid-until\": 1308859352261,
	},		},
	\"certificate\": {		\"certificate\": {
	\"email\": \"rescorla@example.org\",		\"email\": \"rescorla@example.org\",
	\"public-key\": \"<ekrs-public-key>\",		\"public-key\": \"<ekrs-public-key>\",
	\"valid-until\": 1308860561861,		\"valid-until\": 1308860561861,
	}" // certificate is signed by example.org		\"signature\": \"<signature from example.org>\"
	}]]"		},
	}		\"content\": \"<content of the SIGN message>\"
			}"
			}
			]]\n
			m=audio 49170 RTP/AVP 0\n
			..."
			}
	Note that while the IdP here is specified as "browserid.org", the		Note that while the IdP here is specified as "browserid.org", the
	actual certificate is signed by example.org. This is because		actual certificate is signed by example.org. This is because
	BrowserID is a combined authoritative/third-party system in which		BrowserID is a combined authoritative/third-party system in which
	browserid.org delegates the right to be authoritative (what BrowserID		browserid.org delegates the right to be authoritative (what BrowserID
	calls primary) to individual domains.		calls primary) to individual domains.
	On Bob's side, he receives the signed assertion as part of the call		On Bob's side, he receives the signed assertion as part of the call
	setup message and a similar procedure happens to verify it.		setup message and a similar procedure happens to verify it.
End of changes. 24 change blocks.
	203 lines changed or deleted		189 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/