draft-ietf-perc-private-media-framework-09.txt		draft-ietf-perc-private-media-framework-10.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track D. Benham		Intended status: Standards Track D. Benham
	Expires: August 23, 2019 C. Groves		Expires: November 2, 2019 C. Groves
	Independent		Independent
	February 19, 2019		May 1, 2019
	A Solution Framework for Private Media in Privacy Enhanced RTP		A Solution Framework for Private Media in Privacy Enhanced RTP
	Conferencing		Conferencing
	draft-ietf-perc-private-media-framework-09		draft-ietf-perc-private-media-framework-10
	Abstract		Abstract
	This document describes a solution framework for ensuring that media		This document describes a solution framework for ensuring that media
	confidentiality and integrity are maintained end-to-end within the		confidentiality and integrity are maintained end-to-end within the
	context of a switched conferencing environment where media		context of a switched conferencing environment where media
	distributors are not trusted with the end-to-end media encryption		distributors are not trusted with the end-to-end media encryption
	keys. The solution aims to build upon existing security mechanisms		keys. The solution aims to build upon existing security mechanisms
	defined for the real-time transport protocol (RTP).		defined for the real-time transport protocol (RTP).
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 23, 2019.		This Internet-Draft will expire on November 2, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16		6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16
	6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17		6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17
	6.5. Summary of Key Types and Entity Possession . . . . . . . 17		6.5. Summary of Key Types and Entity Possession . . . . . . . 17
	7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18		7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19		8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19
	8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20		8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20
	8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20		8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20
	8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 21		8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 21
	8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21		8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21
	8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 21		8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 22
	8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 22		8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.1. Normative References . . . . . . . . . . . . . . . . . . 22		11.1. Normative References . . . . . . . . . . . . . . . . . . 22
	11.2. Informative References . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	for purposes of this framework (just as it acts as the endpoint for		for purposes of this framework (just as it acts as the endpoint for
	DTLS-SRTP [RFC5764] in one-to-one calls).		DTLS-SRTP [RFC5764] in one-to-one calls).
	Media Distributor (MD): An RTP middlebox that forwards endpoint media		Media Distributor (MD): An RTP middlebox that forwards endpoint media
	content (e.g., voice or video data) unaltered, either a subset or all		content (e.g., voice or video data) unaltered, either a subset or all
	of the flows at any given time, and is never allowed to have access		of the flows at any given time, and is never allowed to have access
	to E2E encryption keys. It operates according to the Selective		to E2E encryption keys. It operates according to the Selective
	Forwarding Middlebox RTP topologies [RFC7667] per the constraints		Forwarding Middlebox RTP topologies [RFC7667] per the constraints
	defined by the PERC system, which includes, but not limited to,		defined by the PERC system, which includes, but not limited to,
	having no access to RTP media unencrypted and having limits on what		having no access to RTP media unencrypted and having limits on what
	RTP header field it can alter. This header fields that may be		RTP header field it can alter. The header fields that may be
	modified by a Media Distributor are enumerated in Section 4 of the		modified by a Media Distributor are enumerated in Section 4 of the
	Double cryptographic transform specification [I-D.ietf-perc-double]		Double cryptographic transform specification [I-D.ietf-perc-double]
	and chosen with respect to utility and the security considerations		and chosen with respect to utility and the security considerations
	outlined in this document.		outlined in this document.
	Key Distributor: An entity that is a logical function which		Key Distributor: An entity that is a logical function which
	distributes keying material and related information to trusted		distributes keying material and related information to trusted
	endpoints and Media Distributor(s), only that which is appropriate		endpoints and Media Distributor(s), only that which is appropriate
	for each. The Key Distributor might be co-resident with another		for each. The Key Distributor might be co-resident with another
	entity trusted with E2E keying material.		entity trusted with E2E keying material.
	skipping to change at page 10, line 26 ¶		skipping to change at page 10, line 26 ¶
	endpoints to reconstruct the original RTP header also enables the		endpoints to reconstruct the original RTP header also enables the
	endpoints to authenticate RTP packets E2E. This design yields		endpoints to authenticate RTP packets E2E. This design yields
	flexibility to the Media Distributor to change certain RTP header		flexibility to the Media Distributor to change certain RTP header
	values as packets are forwarded. Which values the Media Distributor		values as packets are forwarded. Which values the Media Distributor
	can change in the RTP header are defined in [I-D.ietf-perc-double].		can change in the RTP header are defined in [I-D.ietf-perc-double].
	RTCP can only be encrypted hop-by-hop, giving the Media Distributor		RTCP can only be encrypted hop-by-hop, giving the Media Distributor
	the flexibility to forward RTCP content unchanged, transmit compound		the flexibility to forward RTCP content unchanged, transmit compound
	RTCP packets or to initiate RTCP packets for reporting statistics or		RTCP packets or to initiate RTCP packets for reporting statistics or
	conveying other information. Performing hop-by-hop authentication		conveying other information. Performing hop-by-hop authentication
	for all RTP and RTCP packets also helps provide replay protection		for all RTP and RTCP packets also helps provide replay protection
	(see Section 8).		(see Section 8). The use of the replay protection mechanism
			specified in Section 3.3.2 of [RFC3711] is REQUIRED at each hop.
	If there is a need to encrypt one or more RTP header extensions hop-		If there is a need to encrypt one or more RTP header extensions hop-
	by-hop, the endpoint derives an encryption key from the HBH SRTP		by-hop, the endpoint derives an encryption key from the HBH SRTP
	master key to encrypt header extensions as per [RFC6904]. This still		master key to encrypt header extensions as per [RFC6904]. This still
	gives the Media Distributor visibility into header extensions, such		gives the Media Distributor visibility into header extensions, such
	as the one used to determine audio level [RFC6464] of conference		as the one used to determine audio level [RFC6464] of conference
	participants. Note that when RTP header extensions are encrypted,		participants. Note that when RTP header extensions are encrypted,
	all hops need to decrypt and re-encrypt these encrypted header		all hops need to decrypt and re-encrypt these encrypted header
	extensions.		extensions.
	skipping to change at page 19, line 45 ¶		skipping to change at page 19, line 45 ¶
	| +- E2E Encrypted Portion E2E Authenticated Portion ---+|		| +- E2E Encrypted Portion E2E Authenticated Portion ---+|
	| |		| |
	+--- HBH Encrypted Portion HBH Authenticated Portion ----+		+--- HBH Encrypted Portion HBH Authenticated Portion ----+
	Figure 6: Encrypted Media Packet Format		Figure 6: Encrypted Media Packet Format
	8. Security Considerations		8. Security Considerations
	8.1. Third Party Attacks		8.1. Third Party Attacks
			Third party attacks are attacks attempted by an adversary that is not
			supposed to have access to keying material or is otherwise not an
			authorized participant in the conference.
	On-path attacks are mitigated by hop-by-hop integrity protection and		On-path attacks are mitigated by hop-by-hop integrity protection and
	encryption. The integrity protection mitigates packet modification		encryption. The integrity protection mitigates packet modification
	and encryption makes selective blocking of packets harder, but not		and encryption makes selective blocking of packets harder, but not
	impossible.		impossible.
	Off-path attackers could try connecting to different PERC entities		Off-path attackers could try connecting to different PERC entities
	and send specifically crafted packets. Endpoints and Media		and send specifically crafted packets. Endpoints and Media
	Distributors mitigate such an attack by performing hop-by-hop		Distributors mitigate such an attack by performing hop-by-hop
	authentication and discarding packets that fail authentication.		authentication and discarding packets that fail authentication.
	Another attack vector is a third party claiming to be a Media		Another attack vector is a third party claiming to be a Media
	Distributor, fooling endpoints into sending packets to the false		Distributor, fooling endpoints into sending packets to the false
	Media Distributor instead of the correct one. The deceived sending		Media Distributor instead of the correct one. The deceived sending
	endpoints could incorrectly assume their packets have been delivered		endpoints could incorrectly assume their packets have been delivered
	to endpoints when they in fact have not. While this attack is		to endpoints when they in fact have not. While this attack is
	possible, the result is a simple denial of service with no leakage of		possible, the result is a simple denial of service with no leakage of
	confidential information, since the false Media Distributor would not		confidential information, since the false Media Distributor would not
	have access to either HBH or E2E encryption keys.		have access to either HBH or E2E encryption keys.
	If mutual DTLS authentication is not employed, a false Media		Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures
	Distributor could cascade to another legitimate Media Distributor		that a false endpoint or false Media Distributor cannot interact with
	that is part of a larger conference. However, this scenario will		a legitimate Media Distributor or endpoint. While confidentiality
	also produce no positive results for the false Media Distributor		would not be compromised by failing to implement mutual
	since it would not have access to keying material.		authentication, employing it helps mitigate against denial of service
			attacks wherein a false entity sends a stream of packets that the
			would force a legitimate entity to spend time attempting to decrypt.
	A third party could cause a denial-of-service by transmitting many		A third party could cause a denial-of-service by transmitting many
	bogus or replayed packets toward receiving devices that ultimately		bogus or replayed packets toward receiving devices that ultimately
	degrade conference or device performance. Therefore, implementations		degrade conference or device performance. Therefore, implementations
	might wish to devise mechanisms to safeguard against such		might wish to devise mechanisms to safeguard against such
	illegitimate packets, such as utilizing rate-limiting or performing		illegitimate packets, such as utilizing rate-limiting or performing
	basic sanity-checks on packets (e.g., looking at packet length or		basic sanity-checks on packets (e.g., looking at packet length or
	expected sequence number ranges) before performing more expensive		expected sequence number ranges) before performing more expensive
	decryption operations.		decryption operations.
	skipping to change at page 21, line 20 ¶		skipping to change at page 21, line 25 ¶
	rate-limiting packets might help reduce the impact of such attacks.		rate-limiting packets might help reduce the impact of such attacks.
	8.2.2. Replay Attack		8.2.2. Replay Attack
	A replay attack is when an already received packet from a previous		A replay attack is when an already received packet from a previous
	point in the RTP stream is replayed as new packet. This could, for		point in the RTP stream is replayed as new packet. This could, for
	example, allow a Media Distributor to transmit a sequence of packets		example, allow a Media Distributor to transmit a sequence of packets
	identified as a user saying "yes", instead of the "no" the user		identified as a user saying "yes", instead of the "no" the user
	actually said.		actually said.
	The mitigation for a replay attack is to implement replay protection		A replay attack is mitigated by the requirement to implement replay
	as described in Section 3.3.2 of [RFC3711]. End-to-end replay		protection as described in Section 3.3.2 of [RFC3711]. End-to-end
	protection MUST be provided for the whole duration of the conference.		replay protection MUST be provided for the duration of the
			conference.
	8.2.3. Delayed Playout Attack		8.2.3. Delayed Playout Attack
	The delayed playout attack is a variant of the replay attack. This		A delayed playout attack is one where media is received and held by a
	attack is possible even if E2E replay protection is in place.		media distributor and then forwarded to endpoints at a later point in
			time.
			This attack is possible even if E2E replay protection is in place.
	However, due to fact that the Media Distributor is allowed to select		However, due to fact that the Media Distributor is allowed to select
	a subset of streams and not forward the rest to a receiver, such as		a subset of streams and not forward the rest to a receiver, such as
	in forwarding only the most active speakers, the receiver has to		in forwarding only the most active speakers, the receiver has to
	accept gaps in the E2E packet sequence. The issue with this is that		accept gaps in the E2E packet sequence. The issue with this is that
	a Media Distributor can select to not deliver a particular stream for		a Media Distributor can select to not deliver a particular stream for
	a while.		a while.
	Within the window from last packet forwarded to the receiver and the		Within the window from last packet forwarded to the receiver and the
	latest received by the Media Distributor, the Media Distributor can		latest received by the Media Distributor, the Media Distributor can
	select an arbitrary starting point when resuming forwarding packets.		select an arbitrary starting point when resuming forwarding packets.
	Thus what the media source said can be substantially delayed at the		Thus what the media source said can be substantially delayed at the
	receiver with the receiver believing that it is what was said just		receiver with the receiver believing that it is what was said just
	now, and only delayed due to transport delay.		now, and only delayed due to transport delay.
			While this attack cannot be eliminated entirely, its effectiveness
			can be reduced by re-keying the conference periodically since
			significantly-delayed media encrypted with expired keys would not be
			decrypted by endpoints.
	8.2.4. Splicing Attack		8.2.4. Splicing Attack
	A splicing attack is an attack where a Media Distributor receiving		A splicing attack is an attack where a Media Distributor receiving
	multiple media sources splices one media stream into the other. If		multiple media sources splices one media stream into the other. If
	the Media Distributor were able to change the SSRC without the		the Media Distributor were able to change the SSRC without the
	receiver having any method for verifying the original source ID, then		receiver having any method for verifying the original source ID, then
	the Media Distributor could first deliver stream A and then later		the Media Distributor could first deliver stream A and then later
	forward stream B under the same SSRC as stream A was previously		forward stream B under the same SSRC as stream A was previously
	using. By including the SSRC in the integrity check for each packet,		using. By including the SSRC in the integrity check for each packet,
	both HBH and E2E, PERC prevents splicing attacks.		both HBH and E2E, PERC prevents splicing attacks.
	skipping to change at page 23, line 24 ¶		skipping to change at page 23, line 40 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-perc-dtls-tunnel]		[I-D.ietf-perc-dtls-tunnel]
	Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel		Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
	between a Media Distributor and Key Distributor to		between a Media Distributor and Key Distributor to
	Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-04		Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05
	(work in progress), October 2018.		(work in progress), April 2019.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-18 (work in progress), February 2019.		rtcweb-security-arch-18 (work in progress), February 2019.
	[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,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
End of changes. 13 change blocks.
	19 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/